Hello Russell,

On Wed, 26 Feb 2025 14:03:20 +0000
"Russell King (Oracle)" [off-list ref] wrote:

On Wed, Feb 26, 2025 at 11:09:26AM +0100, Maxime Chevallier wrote:

quoted

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/ (local)

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