netdev - Re: FWD: Re: [PATCH net-next v1 1/1] net: dsa: microchip: ksz8: Make flow control, speed, and duplex on CPU port configurable

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZDVL6we7LN/ApgwG@shell.armlinux.org.uk>
Date:   Tue, 11 Apr 2023 13:00:43 +0100
From:   "Russell King (Oracle)" <linux@...linux.org.uk>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     Oleksij Rempel <o.rempel@...gutronix.de>,
        Andrew Lunn <andrew@...n.ch>,
        Woojung Huh <woojung.huh@...rochip.com>,
        Arun Ramadoss <arun.ramadoss@...rochip.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        netdev@...r.kernel.org, UNGLinuxDriver@...rochip.com,
        Eric Dumazet <edumazet@...gle.com>, kernel@...gutronix.de,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        "David S. Miller" <davem@...emloft.net>
Subject: Re: FWD: Re: [PATCH net-next v1 1/1] net: dsa: microchip: ksz8: Make
 flow control, speed, and duplex on CPU port configurable

On Tue, Apr 11, 2023 at 02:35:16PM +0300, Vladimir Oltean wrote:
> On Tue, Apr 11, 2023 at 02:16:09PM +0300, Vladimir Oltean wrote:
> > I may have missed something.
> 
> Maybe I'm wrong, but my blind intuition says that when autoneg is
> disabled in the integrated PHYs, flow control _is_ by default forced off
> per port, unless the "Force Flow Control" bit from Port N Control 2
> registers is set. So that can be used to still support:
> - ethtool --pause swp0 autoneg off rx on tx on
> - ethtool --pause swp0 autoneg off rx off tx off
> - ethtool --pause swp0 autoneg on # asymmetric RX/TX combinations depend upon autoneg
> 
> I may be wrong; I don't have the hardware and the ethtool pause autoneg
> bit is not 100% clear to me.

Stage 1 (per port, force bit):
- If zero, the flow control result from aneg is used, and thus depends on
  what both ends advertise.
- If one, flow control is force-enabled.

Stage 2 (global):
Transmit and receive flow control can be masked off.

Basically, the best we could do is:

	ethtool --pause ... autoneg on

depends on the negotiation result (correct).

	ethtool --pause ... autoneg off rx off tx off

if we *only* program the local advertisement to 00, but leave the
force bit as 0, then this can work.

	ethtool --pause ... autoneg off rx on tx on

if we program the force bit to 1, then this can work, and it doesn't
matter what we do with the advertisement.

Anything else wouldn't give the result the user wants, because there's
no way to independently force rx and tx flow control per port.

That said, phylink doesn't give enough information to make the above
possible since the force bit depends on (tx && rx &&!permit_pause_to_mac)

So, because this hardware is that crazy, I suggest that it *doesn't*
even attempt to support ethtool --pause, and either is programmed
at setup time to use autonegotiated pause (with the negotiation state
programmed via ethtool -s) or it's programmed to have pause globally
disabled. Essentially, I'm saying the hardware is too broken in its
design to be worth bothering trying to work around its weirdness.

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