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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250226160938.101be22d@fedora.home>
Date: Wed, 26 Feb 2025 16:09:38 +0100
From: Maxime Chevallier <maxime.chevallier@...tlin.com>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: davem@...emloft.net, Andrew Lunn <andrew@...n.ch>, Jakub Kicinski
 <kuba@...nel.org>, Eric Dumazet <edumazet@...gle.com>, Paolo Abeni
 <pabeni@...hat.com>, Heiner Kallweit <hkallweit1@...il.com>,
 netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
 thomas.petazzoni@...tlin.com, linux-arm-kernel@...ts.infradead.org,
 Christophe Leroy <christophe.leroy@...roup.eu>, Herve Codina
 <herve.codina@...tlin.com>, Florian Fainelli <f.fainelli@...il.com>,
 Vladimir Oltean <vladimir.oltean@....com>, Köry Maincent
 <kory.maincent@...tlin.com>, Oleksij Rempel <o.rempel@...gutronix.de>,
 Simon Horman <horms@...nel.org>, Romain Gantois
 <romain.gantois@...tlin.com>
Subject: Re: [PATCH net-next v2 11/13] net: phy: phylink: Add a mapping
 between MAC_CAPS and LINK_CAPS

Hello Russell,

On Wed, 26 Feb 2025 14:03:20 +0000
"Russell King (Oracle)" <linux@...linux.org.uk> wrote:

> On Wed, Feb 26, 2025 at 11:09:26AM +0100, Maxime Chevallier wrote:
> > phylink allows MAC drivers to report the capabilities in terms of speed,
> > duplex and pause support. This is done through a dedicated set of enum
> > values in the form of the MAC_ capabilities. They are very close to what
> > the LINK_CAPA_xxx can express, with the difference that LINK_CAPA don't
> > have any information about Pause/Asym Pause support.
> > 
> > To prepare converting phylink to using the phy_caps, add the mapping
> > between MAC capabilities and phy_caps. While doing so, we move the
> > phylink_caps_params array up a bit to simplify future commits.  
> 
> I still want to know why we need to do this type of thing -

Sorry not to have included more details on the why. The main reason is
for the phy_port work. In the previous phy_port series [1] I included an
attempt at making a first step forward with PHY-driven SFP, so that
phylib itself provides the sfp_upstream_ops and not individual PHY
drivers. That's to get a better handling for multi-port PHYs, which is
one of the end-goals.

[1]: https://lore.kernel.org/netdev/20250213101606.1154014-1-maxime.chevallier@bootlin.com/

As part of that PHY-sfp work, I find it very useful for PHY drivers to
be able to tell what phy_interface_t they can expose on their serdes
interfaces, and from then build a list of linkmodes to get an idea of
what we can support on that port. That's why I'm extracting that out of
phylink.

I did see that you suggested having phylink involved for PHY sfp maybe,
but TBH I don't even know where to start, so I took a safer approach
with phylib-driven SFPs.

> unfortunately I don't have time to review all your patches at the
> moment. I haven't reviewed all your patches since you've started
> posting them. Sorry.

No worries, I understand that that whole work is quite the mouthful and
implies some involved reviews. But even discussing higher level stuff,
like we do now, helps me steer that work in the right direction and
hopefully make it easier for you and the other PHY maintainers to
review that in the future.

Maxime

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ