diff mbox series

net: dsa: mv88e6xxx: Skip cmode writable for mv88e6*41 if unchanged

Message ID 20220423132035.238704-1-nathan@nathanrossi.com (mailing list archive)
State Changes Requested
Delegated to: Netdev Maintainers
Headers show
Series net: dsa: mv88e6xxx: Skip cmode writable for mv88e6*41 if unchanged | expand

Checks

Context Check Description
netdev/tree_selection success Guessed tree name to be net-next
netdev/fixes_present success Fixes tag not required for -next series
netdev/subject_prefix warning Target tree name not specified in the subject
netdev/cover_letter success Single patches do not need cover letters
netdev/patch_count success Link
netdev/header_inline success No static functions without inline keyword in header files
netdev/build_32bit success Errors and warnings before: 0 this patch: 0
netdev/cc_maintainers success CCed 8 of 8 maintainers
netdev/build_clang success Errors and warnings before: 0 this patch: 0
netdev/module_param success Was 0 now: 0
netdev/verify_signedoff success Signed-off-by tag matches author and committer
netdev/verify_fixes success No Fixes tag
netdev/build_allmodconfig_warn success Errors and warnings before: 0 this patch: 0
netdev/checkpatch success total: 0 errors, 0 warnings, 0 checks, 30 lines checked
netdev/kdoc success Errors and warnings before: 0 this patch: 0
netdev/source_inline success Was 0 now: 0

Commit Message

Nathan Rossi April 23, 2022, 1:20 p.m. UTC 
The mv88e6341_port_set_cmode function always calls the set writable
regardless of whether the current cmode is different from the desired
cmode. This is problematic for specific configurations of the mv88e6341
and mv88e6141 (in single chip adddressing mode?) where the hidden
registers are not accessible. This causes the set_cmode_writable to
fail, and causes teardown of the switch despite the cmode already being
configured in the correct mode (via external configuration).

This change adds checking of the current cmode compared to the desired
mode and returns if already in the desired mode. This skips the
set_cmode_writable setup if the port is already configured in the
desired mode, avoiding any issues with access of hidden registers.

Signed-off-by: Nathan Rossi <nathan@nathanrossi.com>
---
 drivers/net/dsa/mv88e6xxx/port.c | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

---
2.35.2

Comments

Marek Behún April 23, 2022, 1:25 p.m. UTC | #1 
On Sat, 23 Apr 2022 13:20:35 +0000
Nathan Rossi <nathan@nathanrossi.com> wrote:

> The mv88e6341_port_set_cmode function always calls the set writable
> regardless of whether the current cmode is different from the desired
> cmode. This is problematic for specific configurations of the mv88e6341
> and mv88e6141 (in single chip adddressing mode?) where the hidden
> registers are not accessible.

I don't have a problem with skipping setting cmode writable if cmode is
not being changed. But hidden registers should be accessible regardless
of whether you are using single chip addressing mode or not. You need
to find why it isn't working for you, this is a bug.

Marek
Nathan Rossi April 23, 2022, 1:59 p.m. UTC | #2 
On Sat, 23 Apr 2022 at 23:25, Marek Behún <kabel@kernel.org> wrote:
>
> On Sat, 23 Apr 2022 13:20:35 +0000
> Nathan Rossi <nathan@nathanrossi.com> wrote:
>
> > The mv88e6341_port_set_cmode function always calls the set writable
> > regardless of whether the current cmode is different from the desired
> > cmode. This is problematic for specific configurations of the mv88e6341
> > and mv88e6141 (in single chip adddressing mode?) where the hidden
> > registers are not accessible.
>
> I don't have a problem with skipping setting cmode writable if cmode is
> not being changed. But hidden registers should be accessible regardless
> of whether you are using single chip addressing mode or not. You need
> to find why it isn't working for you, this is a bug.

I did try to debug the hidden register access, unfortunately with the
device I have the hidden registers do not behave correctly. It simply
times out waiting for the busy bit to change. I was not sure the
reason why and suspected it was something specific to the single mode,
and unfortunately the only information I have regarding these
registers is the kernel code itself. Perhaps it is specific to some
other pin configuration or the specific chip revision? If you have any
additional information for these hidden registers it would be very
helpful in debugging. For reference the device is a MV88E6141,
manufactured in 2019 week 47 (in a Netgate SG-3100).

Thanks,
Nathan

>
> Marek
Paolo Abeni April 26, 2022, 7:50 a.m. UTC | #3 
Hello,

On Sat, 2022-04-23 at 15:25 +0200, Marek Behún wrote:
> On Sat, 23 Apr 2022 13:20:35 +0000
> Nathan Rossi <nathan@nathanrossi.com> wrote:
> 
> > The mv88e6341_port_set_cmode function always calls the set writable
> > regardless of whether the current cmode is different from the desired
> > cmode. This is problematic for specific configurations of the mv88e6341
> > and mv88e6141 (in single chip adddressing mode?) where the hidden
> > registers are not accessible.
> 
> I don't have a problem with skipping setting cmode writable if cmode is
> not being changed. But hidden registers should be accessible regardless
> of whether you are using single chip addressing mode or not. You need
> to find why it isn't working for you, this is a bug.

For the records, I read the above as requiring a fix the root cause, so
I'm not applying this patch. Please correct me if I'm wrong.

Thanks,

Paolo
Nathan Rossi April 26, 2022, 10:45 a.m. UTC | #4 
On Tue, 26 Apr 2022 at 17:50, Paolo Abeni <pabeni@redhat.com> wrote:
>
> Hello,
>
> On Sat, 2022-04-23 at 15:25 +0200, Marek Behún wrote:
> > On Sat, 23 Apr 2022 13:20:35 +0000
> > Nathan Rossi <nathan@nathanrossi.com> wrote:
> >
> > > The mv88e6341_port_set_cmode function always calls the set writable
> > > regardless of whether the current cmode is different from the desired
> > > cmode. This is problematic for specific configurations of the mv88e6341
> > > and mv88e6141 (in single chip adddressing mode?) where the hidden
> > > registers are not accessible.
> >
> > I don't have a problem with skipping setting cmode writable if cmode is
> > not being changed. But hidden registers should be accessible regardless
> > of whether you are using single chip addressing mode or not. You need
> > to find why it isn't working for you, this is a bug.
>
> For the records, I read the above as requiring a fix the root cause, so
> I'm not applying this patch. Please correct me if I'm wrong.

You are correct. Sorry I forgot to reply to this thread after posting
the root cause fix.

For reference the root cause fix to the issue mentioned by this patch
is https://lore.kernel.org/netdev/20220425070454.348584-1-nathan@nathanrossi.com/.

Thanks,
Nathan

>
> Thanks,
>
> Paolo
>
diff mbox series

Patch

diff --git a/drivers/net/dsa/mv88e6xxx/port.c b/drivers/net/dsa/mv88e6xxx/port.c
index 795b312876..f2e9c8cae3 100644
--- a/drivers/net/dsa/mv88e6xxx/port.c
+++ b/drivers/net/dsa/mv88e6xxx/port.c
@@ -713,6 +713,7 @@  int mv88e6341_port_set_cmode(struct mv88e6xxx_chip *chip, int port,
 			     phy_interface_t mode)
 {
 	int err;
+	u8 cmode = chip->ports[port].cmode;
 
 	if (port != 5)
 		return -EOPNOTSUPP;
@@ -724,6 +725,23 @@  int mv88e6341_port_set_cmode(struct mv88e6xxx_chip *chip, int port,
 	case PHY_INTERFACE_MODE_XAUI:
 	case PHY_INTERFACE_MODE_RXAUI:
 		return -EINVAL;
+
+	/* Check before setting writable. Such that on devices that are already
+	 * correctly configured, no attempt is made to make the cmode writable
+	 * as it may fail.
+	 */
+	case PHY_INTERFACE_MODE_1000BASEX:
+		if (cmode == MV88E6XXX_PORT_STS_CMODE_1000BASEX)
+			return 0;
+		break;
+	case PHY_INTERFACE_MODE_SGMII:
+		if (cmode == MV88E6XXX_PORT_STS_CMODE_SGMII)
+			return 0;
+		break;
+	case PHY_INTERFACE_MODE_2500BASEX:
+		if (cmode == MV88E6XXX_PORT_STS_CMODE_2500BASEX)
+			return 0;
+		break;
 	default:
 		break;
 	}