linux-kernel - Re: [PATCH] net: mdio: force deassert MDIO reset signal

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: <CAJ=UCjXr=GBieTvUE7O2LqEg4Q_UpmOEAxUVwy2wuitfHT+2ow@mail.gmail.com>
Date:   Sun, 15 Jan 2023 21:34:57 +0100
From:   Pierluigi Passaro <pierluigi.passaro@...il.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     hkallweit1@...il.com, linux@...linux.org.uk, davem@...emloft.net,
        edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        eran.m@...iscite.com, nate.d@...iscite.com,
        francesco.f@...iscite.com, pierluigi.p@...iscite.com
Subject: Re: [PATCH] net: mdio: force deassert MDIO reset signal

On Sun, Jan 15, 2023 at 8:02 PM Andrew Lunn <andrew@...n.ch> wrote:
> > This behaviour is generally not visible, but easily reproducible with all NXP
> > platforms with dual fec (iMX28, iMX6UL, iMX7, iMX8QM, iMX8QXP)
> > where the MDIO bus is owned by the 1st interface but shared with the 2nd.
> > When the 1st interface is probed, this causes the probe of the MDIO bus
> > when the 2nd interface is not yet set up.
>
> This sounds like a different issue.
>
> We need to split the problem up into two.
>
> 1) Does probing the MDIO bus find both PHYs?
>
> 2) Do the MACs get linked to the PHYs.
>
> If the reset is asserted at the point the MDIO bus is probed, you
> probably don't find the PHY because it does not respond to register
> reads. Your patch probably ensures it is out of reset so it is
> enumerated.
>
You are perfectly right: this patch fixes only the 1st problem.
For the 2nd problem, I've already sent a dedicated patch:
https://lore.kernel.org/all/20230115174910.18353-1-pierluigi.p@variscite.com/
>
> For fec1, if the PHY is found during probe, connecting to the PHY will
> work without issues. However, fec2 can potentially have ordering
> issues. Has the MDIO bus finished being probed by the time fec2 looks
> for it? If it is not there you want to return -EPROBE_DEFERED so that
> the driver code will try again later.
>
> There have been patches to do with ordering recently, but they have
> been more to do with suspend/resume. So please make sure you are
> testing net-next, if ordering is your real problem. You also appear to
> be missing a lot of stable patches, so please bring you kernel up to
> date on the 5.15 branch, you are way out of date.
>
>      Andrew