netdev - 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]

Date:   Sun, 15 Jan 2023 20:02:36 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Pierluigi Passaro <pierluigi.passaro@...il.com>
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

> 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.

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