Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230115161006.16431-1-pierluigi.p@variscite.com>
 <Y8QzI2VUY6//uBa/@lunn.ch> <CAJ=UCjX0YzVgedO1hDu_NsFAGhxe8HouUmHmbO6AXZqT=OUYLg@mail.gmail.com>
 <Y8RNzIuiNdAi0dnV@lunn.ch>
In-Reply-To: <Y8RNzIuiNdAi0dnV@lunn.ch>
From:   Pierluigi Passaro <pierluigi.passaro@gmail.com>
Date:   Sun, 15 Jan 2023 21:34:57 +0100
Message-ID: <CAJ=UCjXr=GBieTvUE7O2LqEg4Q_UpmOEAxUVwy2wuitfHT+2ow@mail.gmail.com>
Subject: Re: [PATCH] net: mdio: force deassert MDIO reset signal
To:     Andrew Lunn <andrew@lunn.ch>
Cc:     hkallweit1@gmail.com, linux@armlinux.org.uk, davem@davemloft.net,
        edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
        netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
        eran.m@variscite.com, nate.d@variscite.com,
        francesco.f@variscite.com, pierluigi.p@variscite.com
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Sun, Jan 15, 2023 at 8:02 PM Andrew Lunn <andrew@lunn.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