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
| ||
|
Date: Fri, 15 Jul 2022 12:06:39 -0700 From: Saravana Kannan <saravanak@...gle.com> To: Andrew Lunn <andrew@...n.ch> Cc: "Pandey, Radhey Shyam" <radhey.shyam.pandey@....com>, "nicolas.ferre@...rochip.com" <nicolas.ferre@...rochip.com>, "claudiu.beznea@...rochip.com" <claudiu.beznea@...rochip.com>, "davem@...emloft.net" <davem@...emloft.net>, "edumazet@...gle.com" <edumazet@...gle.com>, "kuba@...nel.org" <kuba@...nel.org>, "pabeni@...hat.com" <pabeni@...hat.com>, "hkallweit1@...il.com" <hkallweit1@...il.com>, "linux@...linux.org.uk" <linux@...linux.org.uk>, "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>, "rafael@...nel.org" <rafael@...nel.org>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "git (AMD-Xilinx)" <git@....com> Subject: Re: [PATCH net-next v2] net: macb: In shared MDIO usecase make MDIO producer ethernet node to probe first On Tue, Jul 5, 2022 at 12:49 PM Andrew Lunn <andrew@...n.ch> wrote: > > > > Thanks for the review. I want to get your thoughts on the outline of > > > the generic solution. Is the current approach fine and we can extend it > > > for all shared MDIO use cases/ or do we see any limitations? > > > > > > a) Figure out if the MDIO bus is shared. (new binding or reuse existing) > > > b) If the MDIO bus is shared based on DT property then figure out if the > > > MDIO producer platform device is probed. If not, defer MDIO consumer > > > MDIO bus registration. > > > > Radhey, > > > > I think Andrew added me because he's pointing you towards fw_devlink. > > > > Andrew, > > > > I have intentionally not added phy-handle support to fw_devlink > > because it would also prevent the generic driver from binding/cause > > issues with DSA. I have some high level ideas on fixing that but > > haven't gotten around to it yet. > > I took a quick look at macb, and i think it is actually broken in > other ways. If you where to use NFS root, i suspect it would also > fail. > > This also has nothing to do with shared MDIO busses as such. All it > requires is some other MDIO bus, not the MACs own MDIO bus. > > It is also that we cannot return -EPROBE_DEFER when trying to connect > the PHY, because it is not performed in the context of the probe, but > the open. > > fw_dewlink might help solve this, bit it is not going to be easy. We > can also split this into two problems; > > 1) probe time > 2) suspend/resume > > macb does seem to probe, for most use cases. So we can probably ignore > that for now. So we can concentrate on suspend/resume. You say > suspend/resume is based on probe order. So it must build some sort of > tree. Can we make phy_attach_direct add an additional link to this > tree when a MAC device is link to a PHY? Is this what > device_link_add() is about? Based on the flags you pass, you can tell device link to only enforce suspend/resume ordering or also enforce probe ordering. -Saravana
Powered by blists - more mailing lists