[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170518193453.GB13759@lunn.ch>
Date: Thu, 18 May 2017 21:34:53 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Florian Fainelli <f.fainelli@...il.com>,
Geert Uytterhoeven <geert+renesas@...der.be>,
Rob Herring <robh+dt@...nel.org>,
Frank Rowand <frowand.list@...il.com>,
Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
Sergei Shtylyov <sergei.shtylyov@...entembedded.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] of_mdio: Fix broken PHY IRQ in case of probe deferral
> > This most certainly works fine in the simple case where you have one PHY
> > hanging off the MDIO bus, now what happens if you have several?
> >
> > Presumably, the first PHY that returns EPROBE_DEFER will make the entire
> > bus registration return EPROB_DEFER as well, and so on, and so forth,
> > but I am not sure if we will be properly unwinding the successful
> > registration of PHYs that either don't have an interrupt, or did not
> > return EPROBE_DEFER.
> >
> > It should be possible to mimic this behavior by using the fixed PHY, and
> > possibly the dsa_loop.c driver which would create 4 ports, expecting 4
> > fixed PHYs to be present.
>
> mdiobus_unregister(), called from of_mdiobus_register() on failure,
> should do the unwinding, right?
>
> And when the driver is reprobed, all PHYs are reprobed, until they all
> succeed.
That is the theory. I looked at that while reviewing the patch. But
this has probably not been tested in anger. It would be good to test
this properly, with not just the first PHY returning -EPROBE_DEFER, to
really test the unwind.
Andrew
Powered by blists - more mailing lists