[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170518163328.GD707@lunn.ch>
Date: Thu, 18 May 2017 18:33:28 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Geert Uytterhoeven <geert+renesas@...der.be>,
Florian Fainelli <f.fainelli@...il.com>,
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
> >> phy = get_phy_device(mdio, addr, is_c45);
> >> if (IS_ERR(phy))
> >> - return;
> >> + return PTR_ERR(phy);
> >>
> >> - rc = irq_of_parse_and_map(child, 0);
> >> + rc = of_irq_get(child, 0);
> >> + if (rc == -EPROBE_DEFER) {
> >> + phy_device_free(phy);
> >> + return rc;
> >> + }
> >
> > Maybe this should be consistent. All other places there is an error,
> > you return it. Here however, you only return the error if it is
> > EPROBE_DEFER.
>
> That's because of the "else" branch in the code below:
>
> if (rc > 0) {
> phy->irq = rc;
> mdio->irq[addr] = rc;
> } else {
> phy->irq = mdio->irq[addr];
> }
>
> cfr. the marked part of the patch description.
> I didn't want to change that behavior, as it's not clear to me why it's handled
> that way.
So there seems to be 3 conditions that need handling:
1) of_irq_get() gives us an interrupt number.
2) of_irq_get() indicates there is no irq in the device tree.
3) of_irq_get() indicates a real error
1) We have.
2) We should fall back to using the mdio busses irq for the
device. There are a couple of mdio drivers which do this, e.g.
stmicro/stmmac/stmmac_mdio.c. mdiobus_alloc() ensures it is set to
PHY_POLL, so if the driver does not set it, we poll.
3) This is new. We have two choices. Ignore the error and poll. Or
return the error. Historically we have ignored the error. But should
we? I would probably return the error, now that we can. But...
Florian?
Andrew
Powered by blists - more mailing lists