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: <ZDVJhN4vyK9ldurD@shell.armlinux.org.uk>
Date:   Tue, 11 Apr 2023 12:50:28 +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:16:09PM +0300, Vladimir Oltean wrote:
> On Tue, Apr 11, 2023 at 10:17:47AM +0100, Russell King (Oracle) wrote:
> > Since we can't manually control the tx and rx pause enables, I think
> > the only sensible way forward with this would be to either globally
> > disable pause on the device, and not report support for any pause
> > modes,
> 
> This implies restarting autoneg on all the other switch ports when one
> port's flow control mode is changed?

>From my reading of these global register descriptions, no it doesn't,
and even if we did restart aneg, it would have no overall system effect
because the advertisements for each port haven't been changed. It's
mad hardware.

What I was meaning above is that we configure the entire switch to
either do autonegotiated flow control at setup time, or we configure
the switch to never do flow control.

> > or report support for all pause modes, advertise '11' and
> > let the hardware control it (which means the ethtool configuration
> > for pause would not be functional.)
> > 
> > This needs to be commented in the driver so that in the future we
> > remember why this has been done.
> > 
> > Maybe Andrew and/or Vladimir also have an opinion to share about the
> > best approach here?
> 
> I don't object to documenting that manually forcing flow control off is
> broken and leaving it at that (and the way to force it off would be to
> not advertise any of the 2 bits).
> 
> But why advertise only 11 (Asym_Pause | Pause) when the PHYs integrated
> here have the advertisement configurable (presumably also through the
> micrel.c PHY driver)? They would advertise in accordance with ethtool, no?
> 
> I may have missed something.

I think you have. I'm only talking about the ability to control flow
control manually via ethtool -A. Changing it via the advertisement
(ethtool -s) would still work.

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