netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Tobias Waldekranz <tobias@waldekranz.com>
Cc: davem@davemloft.net, kuba@kernel.org, andrew@lunn.ch,
	f.fainelli@gmail.com, olteanv@gmail.com, netdev@vger.kernel.org,
	chris.packham@alliedtelesis.co.nz, pabeni@redhat.com
Subject: Re: [PATCH v2 net 3/4] net: dsa: mv88e6xxx: Never force link on in-band managed MACs
Date: Thu, 2 Jan 2025 10:31:59 +0000	[thread overview]
Message-ID: <Z3ZrH9yqtvu2-W7f@shell.armlinux.org.uk> (raw)
In-Reply-To: <20241219123106.730032-4-tobias@waldekranz.com>

On Thu, Dec 19, 2024 at 01:30:42PM +0100, Tobias Waldekranz wrote:
> NOTE: This issue was addressed in the referenced commit, but a
> conservative approach was chosen, where only 6095, 6097 and 6185 got
> the fix.
> 
> Before the referenced commit, in the following setup, when the PHY
> detected loss of link on the MDI, mv88e6xxx would force the MAC
> down. If the MDI-side link was then re-established later on, there was
> no longer any MII link over which the PHY could communicate that
> information back to the MAC.
> 
>         .-SGMII/USXGMII
>         |
> .-----. v .-----.   .--------------.
> | MAC +---+ PHY +---+ MDI (Cu/SFP) |
> '-----'   '-----'   '--------------'
> 
> Since this a generic problem on all MACs connected to a SERDES - which
> is the only time when in-band-status is used - move all chips to a
> common mv88e6xxx_port_sync_link() implementation which avoids forcing
> links on _all_ in-band managed ports.
> 
> Fixes: 4efe76629036 ("net: dsa: mv88e6xxx: Don't force link when using in-band-status")
> Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>

I'm feeling uneasy about this change.

The history of the patch you refer to is - original v1:

https://lore.kernel.org/r/20201013021858.20530-2-chris.packham@alliedtelesis.co.nz

When v3 was submitted, it was unchanged:

https://lore.kernel.org/r/20201020034558.19438-2-chris.packham@alliedtelesis.co.nz

Both of these applied the in-band-status thing to all Marvell DSA
switches, but as Marek states here:

https://lore.kernel.org/r/20201020165115.3ecfd601@nic.cz

doing so breaks last least one Marvell DSA switch (88E6390). Hence why
this approach is taken, rather than not forcing the link status on all
DSA switches.

Your patch appears to be reverting us back to what was effectively in
Chris' v1 patch from back then, so I don't think we can accept this
change. Sorry.

If you have a switch that needs your change, then I think you also need
to adopt the "conservative" approach and only fix the switch you're
working with - short of someone going through all the Marvell DSA
switch datasheets or testing on real hardware, I don't think it's a
good idea to change the behaviour of all Marvell switches like this.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

  parent reply	other threads:[~2025-01-02 10:32 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-19 12:30 [PATCH v2 net 0/4] net: dsa: mv88e6xxx: Amethyst (6393X) fixes Tobias Waldekranz
2024-12-19 12:30 ` [PATCH v2 net 1/4] net: dsa: mv88e6xxx: Improve I/O related error logging Tobias Waldekranz
2024-12-19 13:41   ` Andrew Lunn
2024-12-19 14:32   ` Vladimir Oltean
2024-12-19 12:30 ` [PATCH v2 net 2/4] net: dsa: mv88e6xxx: Give chips more time to activate their PPUs Tobias Waldekranz
2024-12-19 13:41   ` Andrew Lunn
2024-12-19 12:30 ` [PATCH v2 net 3/4] net: dsa: mv88e6xxx: Never force link on in-band managed MACs Tobias Waldekranz
2024-12-19 13:43   ` Andrew Lunn
2025-01-02 10:31   ` Russell King (Oracle) [this message]
2025-01-02 13:06     ` Tobias Waldekranz
2025-01-02 17:08       ` Russell King (Oracle)
2025-01-04 21:37         ` Tobias Waldekranz
2025-01-04 22:09           ` Russell King (Oracle)
2025-01-04 23:16             ` Tobias Waldekranz
2025-01-05 10:41               ` Russell King (Oracle)
2025-01-05 23:30                 ` Tobias Waldekranz
2025-01-06  8:20                   ` Russell King (Oracle)
2025-01-06 14:39                     ` Tobias Waldekranz
2024-12-19 12:30 ` [PATCH v2 net 4/4] net: dsa: mv88e6xxx: Limit rsvd2cpu policy to user ports on 6393X Tobias Waldekranz
2024-12-19 13:44   ` Andrew Lunn
2024-12-19 14:05   ` Vladimir Oltean
2024-12-19 14:14     ` Vladimir Oltean
2024-12-19 14:34     ` Tobias Waldekranz
2024-12-19 14:42       ` Vladimir Oltean
2024-12-19 14:52         ` Vladimir Oltean
2024-12-19 15:02           ` Tobias Waldekranz
2024-12-19 14:29   ` Vladimir Oltean

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z3ZrH9yqtvu2-W7f@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=andrew@lunn.ch \
    --cc=chris.packham@alliedtelesis.co.nz \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=pabeni@redhat.com \
    --cc=tobias@waldekranz.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).