Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754871AbaBRRCS (ORCPT ); Tue, 18 Feb 2014 12:02:18 -0500 Received: from mail-wi0-f171.google.com ([209.85.212.171]:41157 "EHLO mail-wi0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752979AbaBRRCP (ORCPT ); Tue, 18 Feb 2014 12:02:15 -0500 From: Grant Likely Subject: Re: [PATCH] of_mdio: fix phy interrupt passing To: Ben Dooks Cc: linux-kernel@lists.codethink.co.uk, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, linux-sh@vger.kernel.org, sergei.shtylyov@cogentembedded.com In-Reply-To: <53032A97.8050201@codethink.co.uk> References: <1392654580-3706-1-git-send-email-ben.dooks@codethink.co.uk> < 20140218093024.D0E94C403C8@trevor.secretlab.ca> <53032A97.8050201@codethink .co.uk> Date: Tue, 18 Feb 2014 17:02:02 +0000 Message-Id: <20140218170202.424D7C40517@trevor.secretlab.ca> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 18 Feb 2014 09:40:39 +0000, Ben Dooks wrote: > On 18/02/14 09:30, Grant Likely wrote: > > On Mon, 17 Feb 2014 16:29:40 +0000, Ben Dooks wrote: > >> The of_mdiobus_register_phy() is not setting phy->irq this causing > >> some drivers to incorrectly assume that the PHY does not have an > >> IRQ associated with it or install an interrupt handler for the > >> PHY. > >> > >> Simplify the code setting irq and set the phy->irq at the same > >> time so that the case if mdio->irq is not NULL is easier to read. > >> > >> This fixes the issue: > >> net eth0: attached PHY 1 (IRQ -1) to driver Micrel KSZ8041RNLI > >> > >> to the correct: > >> net eth0: attached PHY 1 (IRQ 416) to driver Micrel KSZ8041RNLI > >> > >> Signed-off-by: Ben Dooks > >> --- > >> drivers/of/of_mdio.c | 12 ++++++------ > >> 1 file changed, 6 insertions(+), 6 deletions(-) > >> > >> diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c > >> index 875b7b6..7b3e7b0 100644 > >> --- a/drivers/of/of_mdio.c > >> +++ b/drivers/of/of_mdio.c > >> @@ -44,7 +44,7 @@ static int of_mdiobus_register_phy(struct mii_bus *mdio, struct device_node *chi > >> { > >> struct phy_device *phy; > >> bool is_c45; > >> - int rc, prev_irq; > >> + int rc; > >> u32 max_speed = 0; > >> > >> is_c45 = of_device_is_compatible(child, > >> @@ -55,11 +55,11 @@ static int of_mdiobus_register_phy(struct mii_bus *mdio, struct device_node *chi > >> return 1; > >> > >> if (mdio->irq) { > >> - prev_irq = mdio->irq[addr]; > >> - mdio->irq[addr] = > >> - irq_of_parse_and_map(child, 0); > >> - if (!mdio->irq[addr]) > >> - mdio->irq[addr] = prev_irq; > > > > I cannot for the life for me remeber why the code was structured that > > way. Your change is better. > > > >> + rc = irq_of_parse_and_map(child, 0); > >> + if (rc > 0) { > >> + mdio->irq[addr] = rc; > >> + phy->irq = rc; > >> + } > >> } > > > > The outer if is merely protecting against no irq array being allocated > > for the bus. Would not the following be better: > > > > rc = irq_of_parse_and_map(child, 0); > > if (rc > 0) { > > phy->irq = rc; > > if (mdio->irq) > > mdio->irq[addr] = rc; > > } > > Thanks, that makes sense, although we've both failed to work > out if mdio->irq is set, and rc <= 0 case, so: > > rc = irq_of_parse_and_map(child, 0); > if (rc > 0) { > phy->irq = rc; > if (mdio->irq) > mdio->irq[addr] = rc; > } else { > if (mdio->irq) > phy->irq = mdio->irq[addr]; > } Is this actually a valid thing to do? I think the only time mdio->irq[] is non-zero is when it is set to PHY_POLL. Is it valid to set phy->irq to PHY_POLL? I didn't think it was. g. > > I think that covers all cases. This does rely on mdio->irq > being initialised to PHY_POLL if allocated. > > Once this is in, it may be easier then to not allocate > mdio->irq for the OF case by default unless the driver > registering the PHY knows it has the interrupt number(s) > for the PHY already. > > -- > Ben Dooks http://www.codethink.co.uk/ > Senior Engineer Codethink - Providing Genius -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/