netdev - RE: [PATCH net-next v2] net: macb: In shared MDIO usecase make MDIO producer ethernet node to probe first

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: <MN0PR12MB59531DFD084FA947084D91B6B7819@MN0PR12MB5953.namprd12.prod.outlook.com>
Date:   Tue, 5 Jul 2022 18:49:06 +0000
From:   "Pandey, Radhey Shyam" <radhey.shyam.pandey@....com>
To:     Andrew Lunn <andrew@...n.ch>
CC:     "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>,
        "saravanak@...gle.com" <saravanak@...gle.com>,
        "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

> -----Original Message-----
> From: Andrew Lunn <andrew@...n.ch>
> Sent: Friday, July 1, 2022 2:44 PM
> To: Pandey, Radhey Shyam <radhey.shyam.pandey@....com>
> Cc: nicolas.ferre@...rochip.com; claudiu.beznea@...rochip.com;
> davem@...emloft.net; edumazet@...gle.com; kuba@...nel.org;
> pabeni@...hat.com; hkallweit1@...il.com; linux@...linux.org.uk;
> gregkh@...uxfoundation.org; rafael@...nel.org; saravanak@...gle.com;
> netdev@...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 Fri, Jul 01, 2022 at 01:25:06AM +0530, Radhey Shyam Pandey wrote:
> > In shared MDIO suspend/resume usecase for ex. with MDIO producer
> > (0xff0c0000) eth1 and MDIO consumer(0xff0b0000) eth0 there is a
> > constraint that ethernet interface(ff0c0000) MDIO bus producer has to
> > be resumed before the consumer ethernet interface(ff0b0000).
> >
> > However above constraint is not met when GEM0(ff0b0000) is resumed first.
> > There is phy_error on GEM0 and interface becomes non-functional on
> resume.
> >
> > suspend:
> > [ 46.477795] macb ff0c0000.ethernet eth1: Link is Down [ 46.483058]
> > macb ff0c0000.ethernet: gem-ptp-timer ptp clock unregistered.
> > [ 46.490097] macb ff0b0000.ethernet eth0: Link is Down [ 46.495298]
> > macb ff0b0000.ethernet: gem-ptp-timer ptp clock unregistered.
> >
> > resume:
> > [ 46.633840] macb ff0b0000.ethernet eth0: configuring for phy/sgmii
> > link mode macb_mdio_read -> pm_runtime_get_sync(GEM1) it return -
> EACCES error.
> >
> > The suspend/resume is dependent on probe order so to fix this
> > dependency ensure that MDIO producer ethernet node is always probed
> > first followed by MDIO consumer ethernet node.
> >
> > During MDIO registration find out if MDIO bus is shared and check if
> > MDIO producer platform node(traverse by 'phy-handle' property) is
> > bound. If not bound then defer the MDIO consumer ethernet node probe.
> > Doing it ensures that in suspend/resume MDIO producer is resumed
> > followed by MDIO consumer ethernet node.
> 
> I don't think there is anything specific to MACB here. There are Freescale
> boards which have an MDIO bus shared by two interfaces etc.
> 
> Please try to solve this in a generic way, not specific to one MAC and MDIO
> combination.

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.

> 
>      Andrew