netdev - RE: [PATCH net] net: phy: add device link between MAC device and MDIO device

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:
 <PAXPR04MB851017585749D3523D4A516B889FA@PAXPR04MB8510.eurprd04.prod.outlook.com>
Date: Fri, 30 Jan 2026 08:45:25 +0000
From: Wei Fang <wei.fang@....com>
To: Maxime Chevallier <maxime.chevallier@...tlin.com>, Russell King
	<linux@...linux.org.uk>, Jakub Kicinski <kuba@...nel.org>
CC: "andrew@...n.ch" <andrew@...n.ch>, "hkallweit1@...il.com"
	<hkallweit1@...il.com>, "florian.fainelli@...adcom.com"
	<florian.fainelli@...adcom.com>, xiaolei.wang <xiaolei.wang@...driver.com>,
	"davem@...emloft.net" <davem@...emloft.net>, "edumazet@...gle.com"
	<edumazet@...gle.com>, "pabeni@...hat.com" <pabeni@...hat.com>,
	"quic_abchauha@...cinc.com" <quic_abchauha@...cinc.com>,
	"quic_sarohasa@...cinc.com" <quic_sarohasa@...cinc.com>,
	"imx@...ts.linux.dev" <imx@...ts.linux.dev>, "netdev@...r.kernel.org"
	<netdev@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH net] net: phy: add device link between MAC device and MDIO
 device

> >>> Anyone willing to venture a review tag?
> >>
> >> No, I don't agrew with the patch.
> >>
> >
> > Is it because of SFP? If so, would the following modification be more
> > reasonable, while SFP still follows the previous logic? I'm not sure
> > if
> > phydev->sfp_bus_attached can be used to distinguish between SFP
> > PHYs and non-SFP PHYs.
>
> If you want to know if the PHY is in an SFP module, you should use
> phy_on_sfp() instead :
>
> https://elixir.boo/
> tlin.com%2Flinux%2Fv6.18.6%2Fsource%2Finclude%2Flinux%2Fphy.h%23L1766
> &data=05%7C02%7Cwei.fang%40nxp.com%7C94dbe2fb454c4a8fd96708de5fd9
> b94a%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6390535858824
> 03531%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLj
> AuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%
> 7C%7C&sdata=FqnLEaC8Jt0zIgVQpIkbp0fg7WCrBuJjJFkCExRQKoc%3D&reserved
> =0
>
> It's set for this kind of setups :
>
>
>                SFP module
> +-----+      +-----------+
> | MAC | ---- | PHY       |
> +-----+      +--\--------+
>                  \
>                   \_ phy_on_sfp(phydev) == true
>
>
> phydev->sfp_bus_attached is for the media converter user-case :
>
>                             SFP Module
> +-----+      +-----+      +------------+
> | MAC | ---- | PHY | ---- |   ???      |
> +-----+      +--\--+      +------------+
>                  \
>                   \_ phydev->sfp_bus_attached == true

Thank you very much for your explanation and the diagram. I also noticed
phydev->is_on_sfp_module, which is also used in phy_attach_direct(), but
I didn't know the difference between them.

> >
> > Anyway, this problem has existed for a long time, and I think we
> > should find a way to solve it in upstream. If there's a better
> > approach, I can help verify it.
>
> Sorry I wasn't available for most part of yesterday for that discussion.
>
> I'll give a try to this patch today, with the above change and let you know how
> this goes.
>

Thanks again. This problem has been bothering us for a long time, it would be
great if this problem could be solved.