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: <20d4ac99-f40f-4526-96fe-ec3efeed57b7@lunn.ch>
Date:   Tue, 11 Apr 2023 14:16:19 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     "Russell King (Oracle)" <linux@...linux.org.uk>
Cc:     Vladimir Oltean <olteanv@...il.com>,
        Oleksij Rempel <o.rempel@...gutronix.de>,
        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 01:00:43PM +0100, Russell King (Oracle) wrote:
> 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

This hardware design does seem messed up. My experience reviewing
ethtool patches for flow control is that most developers also get it
wrong. Plus it is not very well documented. phylink has made that
better since it moves a lot of the code into the core.

I suggest you follow Russells suggestion, only support autoneg on.
Have ethtool set return -EOPNOTSUPP for anything else. And ethtool get
should return that autoneg is on, and the result of the autoneg, which
you should be able to get.

Only implementing a subset of ethtool is fine.  We have drivers
implementing various subsets, mostly when firmware is controlling the
hardware, and there are firmware limitations.

	  Andrew