Message ID | 1400582523-22684-1-git-send-email-grygorii.strashko@ti.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
On Tue, 20 May 2014 13:42:02 +0300, Grygorii Strashko <grygorii.strashko@ti.com> wrote: > The commit 9ec36cafe43bf835f8f29273597a5b0cbc8267ef > "of/irq: do irq resolution in platform_get_irq" from Rob Herring - > moves resolving of the interrupt resources in platform_get_irq(). > But this solution isn't complete because platform_get_irq_byname() > need to be modified the same way. > > Hence, fix it by adding interrupt resolution code at the > platform_get_irq_byname() function too. > > Cc: Russell King <linux@arm.linux.org.uk> > Cc: Rob Herring <robh@kernel.org> > Cc: Tony Lindgren <tony@atomide.com> > Cc: Grant Likely <grant.likely@linaro.org> > Cc: Thierry Reding <thierry.reding@gmail.com> > > Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Applied, Thanks. g. > --- > Changes in v1: > - use of_property_match_string() to get IRQ index by name > - minor comments fixed > > RFC: > https://lkml.org/lkml/2014/5/19/325 > > drivers/base/platform.c | 7 +++++-- > drivers/of/irq.c | 22 ++++++++++++++++++++++ > include/linux/of_irq.h | 5 +++++ > 3 files changed, 32 insertions(+), 2 deletions(-) > > diff --git a/drivers/base/platform.c b/drivers/base/platform.c > index 5b47210..9e9227e 100644 > --- a/drivers/base/platform.c > +++ b/drivers/base/platform.c > @@ -131,9 +131,12 @@ EXPORT_SYMBOL_GPL(platform_get_resource_byname); > */ > int platform_get_irq_byname(struct platform_device *dev, const char *name) > { > - struct resource *r = platform_get_resource_byname(dev, IORESOURCE_IRQ, > - name); > + struct resource *r; > + > + if (IS_ENABLED(CONFIG_OF_IRQ) && dev->dev.of_node) > + return of_irq_get_byname(dev->dev.of_node, name); > > + r = platform_get_resource_byname(dev, IORESOURCE_IRQ, name); > return r ? r->start : -ENXIO; > } > EXPORT_SYMBOL_GPL(platform_get_irq_byname); > diff --git a/drivers/of/irq.c b/drivers/of/irq.c > index 5aeb894..3e06a69 100644 > --- a/drivers/of/irq.c > +++ b/drivers/of/irq.c > @@ -406,6 +406,28 @@ int of_irq_get(struct device_node *dev, int index) > } > > /** > + * of_irq_get_byname - Decode a node's IRQ and return it as a Linux irq number > + * @dev: pointer to device tree node > + * @name: irq name > + * > + * Returns Linux irq number on success, or -EPROBE_DEFER if the irq domain > + * is not yet created, or error code in case of any other failure. > + */ > +int of_irq_get_byname(struct device_node *dev, const char *name) > +{ > + int index; > + > + if (unlikely(!name)) > + return -EINVAL; > + > + index = of_property_match_string(dev, "interrupt-names", name); > + if (index < 0) > + return index; > + > + return of_irq_get(dev, index); > +} > + > +/** > * of_irq_count - Count the number of IRQs a node uses > * @dev: pointer to device tree node > */ > diff --git a/include/linux/of_irq.h b/include/linux/of_irq.h > index 6404253..bfec136 100644 > --- a/include/linux/of_irq.h > +++ b/include/linux/of_irq.h > @@ -45,6 +45,7 @@ extern void of_irq_init(const struct of_device_id *matches); > #ifdef CONFIG_OF_IRQ > extern int of_irq_count(struct device_node *dev); > extern int of_irq_get(struct device_node *dev, int index); > +extern int of_irq_get_byname(struct device_node *dev, const char *name); > #else > static inline int of_irq_count(struct device_node *dev) > { > @@ -54,6 +55,10 @@ static inline int of_irq_get(struct device_node *dev, int index) > { > return 0; > } > +static inline int of_irq_get_byname(struct device_node *dev, const char *name) > +{ > + return 0; > +} > #endif > > #if defined(CONFIG_OF) > -- > 1.7.9.5 >
On Fri, May 23, 2014 at 1:03 AM, Grant Likely <grant.likely@linaro.org> wrote: > On Tue, 20 May 2014 13:42:02 +0300, Grygorii Strashko <grygorii.strashko@ti.com> wrote: >> The commit 9ec36cafe43bf835f8f29273597a5b0cbc8267ef >> "of/irq: do irq resolution in platform_get_irq" from Rob Herring - >> moves resolving of the interrupt resources in platform_get_irq(). >> But this solution isn't complete because platform_get_irq_byname() >> need to be modified the same way. >> >> Hence, fix it by adding interrupt resolution code at the >> platform_get_irq_byname() function too. >> >> Cc: Russell King <linux@arm.linux.org.uk> >> Cc: Rob Herring <robh@kernel.org> >> Cc: Tony Lindgren <tony@atomide.com> >> Cc: Grant Likely <grant.likely@linaro.org> >> Cc: Thierry Reding <thierry.reding@gmail.com> >> >> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> > > Applied, Thanks. As of next-20150526, the ST u8500 Snowball board has been failing boot in linux-next, and was bisected down to this patch (commit ad69674e73a1 in -next). Full boot failure attached. I have not dug any deeper, but can confirm that next-20140526 with this patch reverted boots again on the snowball board. Kevin
On Tue, May 27, 2014 at 3:23 PM, Kevin Hilman <khilman@linaro.org> wrote: > On Fri, May 23, 2014 at 1:03 AM, Grant Likely <grant.likely@linaro.org> wrote: >> On Tue, 20 May 2014 13:42:02 +0300, Grygorii Strashko <grygorii.strashko@ti.com> wrote: >>> The commit 9ec36cafe43bf835f8f29273597a5b0cbc8267ef >>> "of/irq: do irq resolution in platform_get_irq" from Rob Herring - >>> moves resolving of the interrupt resources in platform_get_irq(). >>> But this solution isn't complete because platform_get_irq_byname() >>> need to be modified the same way. >>> >>> Hence, fix it by adding interrupt resolution code at the >>> platform_get_irq_byname() function too. >>> >>> Cc: Russell King <linux@arm.linux.org.uk> >>> Cc: Rob Herring <robh@kernel.org> >>> Cc: Tony Lindgren <tony@atomide.com> >>> Cc: Grant Likely <grant.likely@linaro.org> >>> Cc: Thierry Reding <thierry.reding@gmail.com> >>> >>> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> >> >> Applied, Thanks. > > As of next-20150526, the ST u8500 Snowball board has been failing boot > in linux-next, and was bisected down to this patch (commit > ad69674e73a1 in -next). Full boot failure attached. > > I have not dug any deeper, but can confirm that next-20140526 with > this patch reverted boots again on the snowball board. There's a patch on the list which fixes it. The problem is stmmac driver was expecting only one error code. Rob
On Tue, 27 May 2014, Rob Herring wrote: > On Tue, May 27, 2014 at 3:23 PM, Kevin Hilman <khilman@linaro.org> wrote: > > On Fri, May 23, 2014 at 1:03 AM, Grant Likely <grant.likely@linaro.org> wrote: > >> On Tue, 20 May 2014 13:42:02 +0300, Grygorii Strashko <grygorii.strashko@ti.com> wrote: > >>> The commit 9ec36cafe43bf835f8f29273597a5b0cbc8267ef > >>> "of/irq: do irq resolution in platform_get_irq" from Rob Herring - > >>> moves resolving of the interrupt resources in platform_get_irq(). > >>> But this solution isn't complete because platform_get_irq_byname() > >>> need to be modified the same way. > >>> > >>> Hence, fix it by adding interrupt resolution code at the > >>> platform_get_irq_byname() function too. > >>> > >>> Cc: Russell King <linux@arm.linux.org.uk> > >>> Cc: Rob Herring <robh@kernel.org> > >>> Cc: Tony Lindgren <tony@atomide.com> > >>> Cc: Grant Likely <grant.likely@linaro.org> > >>> Cc: Thierry Reding <thierry.reding@gmail.com> > >>> > >>> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> > >> > >> Applied, Thanks. > > > > As of next-20150526, the ST u8500 Snowball board has been failing boot > > in linux-next, and was bisected down to this patch (commit > > ad69674e73a1 in -next). Full boot failure attached. > > > > I have not dug any deeper, but can confirm that next-20140526 with > > this patch reverted boots again on the snowball board. > > There's a patch on the list which fixes it. The problem is stmmac > driver was expecting only one error code. Does Snowball even use stmmac?
On Wed, May 28, 2014 at 9:18 AM, Lee Jones <lee.jones@linaro.org> wrote: > On Tue, 27 May 2014, Rob Herring wrote: > >> On Tue, May 27, 2014 at 3:23 PM, Kevin Hilman <khilman@linaro.org> wrote: >> > On Fri, May 23, 2014 at 1:03 AM, Grant Likely <grant.likely@linaro.org> wrote: >> >> On Tue, 20 May 2014 13:42:02 +0300, Grygorii Strashko <grygorii.strashko@ti.com> wrote: >> >>> The commit 9ec36cafe43bf835f8f29273597a5b0cbc8267ef >> >>> "of/irq: do irq resolution in platform_get_irq" from Rob Herring - >> >>> moves resolving of the interrupt resources in platform_get_irq(). >> >>> But this solution isn't complete because platform_get_irq_byname() >> >>> need to be modified the same way. >> >>> >> >>> Hence, fix it by adding interrupt resolution code at the >> >>> platform_get_irq_byname() function too. >> >>> >> >>> Cc: Russell King <linux@arm.linux.org.uk> >> >>> Cc: Rob Herring <robh@kernel.org> >> >>> Cc: Tony Lindgren <tony@atomide.com> >> >>> Cc: Grant Likely <grant.likely@linaro.org> >> >>> Cc: Thierry Reding <thierry.reding@gmail.com> >> >>> >> >>> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> >> >> >> >> Applied, Thanks. >> > >> > As of next-20150526, the ST u8500 Snowball board has been failing boot >> > in linux-next, and was bisected down to this patch (commit >> > ad69674e73a1 in -next). Full boot failure attached. >> > >> > I have not dug any deeper, but can confirm that next-20140526 with >> > this patch reverted boots again on the snowball board. >> >> There's a patch on the list which fixes it. The problem is stmmac >> driver was expecting only one error code. > > Does Snowball even use stmmac? No. I don't get this... Yours, Linus Walleij
On Tue, 27 May 2014 19:37:00 -0500, Rob Herring <robh@kernel.org> wrote: > On Tue, May 27, 2014 at 3:23 PM, Kevin Hilman <khilman@linaro.org> wrote: > > On Fri, May 23, 2014 at 1:03 AM, Grant Likely <grant.likely@linaro.org> wrote: > >> On Tue, 20 May 2014 13:42:02 +0300, Grygorii Strashko <grygorii.strashko@ti.com> wrote: > >>> The commit 9ec36cafe43bf835f8f29273597a5b0cbc8267ef > >>> "of/irq: do irq resolution in platform_get_irq" from Rob Herring - > >>> moves resolving of the interrupt resources in platform_get_irq(). > >>> But this solution isn't complete because platform_get_irq_byname() > >>> need to be modified the same way. > >>> > >>> Hence, fix it by adding interrupt resolution code at the > >>> platform_get_irq_byname() function too. > >>> > >>> Cc: Russell King <linux@arm.linux.org.uk> > >>> Cc: Rob Herring <robh@kernel.org> > >>> Cc: Tony Lindgren <tony@atomide.com> > >>> Cc: Grant Likely <grant.likely@linaro.org> > >>> Cc: Thierry Reding <thierry.reding@gmail.com> > >>> > >>> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> > >> > >> Applied, Thanks. > > > > As of next-20150526, the ST u8500 Snowball board has been failing boot > > in linux-next, and was bisected down to this patch (commit > > ad69674e73a1 in -next). Full boot failure attached. > > > > I have not dug any deeper, but can confirm that next-20140526 with > > this patch reverted boots again on the snowball board. > > There's a patch on the list which fixes it. The problem is stmmac > driver was expecting only one error code. Can you send me a link to this patch? I cannot find it in my inbox. g.
On Wed, May 28, 2014 at 4:25 PM, Linus Walleij <linus.walleij@linaro.org> wrote: > On Wed, May 28, 2014 at 9:18 AM, Lee Jones <lee.jones@linaro.org> wrote: >> On Tue, 27 May 2014, Rob Herring wrote: >> >>> On Tue, May 27, 2014 at 3:23 PM, Kevin Hilman <khilman@linaro.org> wrote: >>> > On Fri, May 23, 2014 at 1:03 AM, Grant Likely <grant.likely@linaro.org> wrote: >>> >> On Tue, 20 May 2014 13:42:02 +0300, Grygorii Strashko <grygorii.strashko@ti.com> wrote: >>> >>> The commit 9ec36cafe43bf835f8f29273597a5b0cbc8267ef >>> >>> "of/irq: do irq resolution in platform_get_irq" from Rob Herring - >>> >>> moves resolving of the interrupt resources in platform_get_irq(). >>> >>> But this solution isn't complete because platform_get_irq_byname() >>> >>> need to be modified the same way. >>> >>> >>> >>> Hence, fix it by adding interrupt resolution code at the >>> >>> platform_get_irq_byname() function too. >>> >>> >>> >>> Cc: Russell King <linux@arm.linux.org.uk> >>> >>> Cc: Rob Herring <robh@kernel.org> >>> >>> Cc: Tony Lindgren <tony@atomide.com> >>> >>> Cc: Grant Likely <grant.likely@linaro.org> >>> >>> Cc: Thierry Reding <thierry.reding@gmail.com> >>> >>> >>> >>> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> >>> >> >>> >> Applied, Thanks. >>> > >>> > As of next-20150526, the ST u8500 Snowball board has been failing boot >>> > in linux-next, and was bisected down to this patch (commit >>> > ad69674e73a1 in -next). Full boot failure attached. >>> > >>> > I have not dug any deeper, but can confirm that next-20140526 with >>> > this patch reverted boots again on the snowball board. >>> >>> There's a patch on the list which fixes it. The problem is stmmac >>> driver was expecting only one error code. >> >> Does Snowball even use stmmac? > > No. > > I don't get this... Log says musb is wrestling control over some pins with some other driver: [ 1.441497] pinctrl-nomadik soc:pinctrl: pin GPIO256_AF28 already requested by a03e0000.usb_per5; cannot claim for musb-hdrc.0.auto [ 1.453369] pinctrl-nomadik soc:pinctrl: pin-256 (musb-hdrc.0.auto) status -22 [ 1.460571] pinctrl-nomadik soc:pinctrl: could not request pin 256 (GPIO256_AF28) from group usb_a_1 on device pinctrl-nomadik [ 1.472076] musb-hdrc musb-hdrc.0.auto: Error applying setting, reverse things back [ 1.479827] HS USB OTG: no transceiver configured [ 1.484558] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517 [ 1.492309] platform musb-hdrc.0.auto: Driver musb-hdrc requests probe deferral [ 1.500183] pinctrl-nomadik soc:pinctrl: pin GPIO256_AF28 already requested by a03e0000.usb_per5; cannot claim for musb-hdrc.0.auto [ 1.512023] pinctrl-nomadik soc:pinctrl: pin-256 (musb-hdrc.0.auto) status -22 [ 1.519226] pinctrl-nomadik soc:pinctrl: could not request pin 256 (GPIO256_AF28) from group usb_a_1 on device pinctrl-nomadik [ 1.530731] musb-ux500 musb-hdrc.0.auto: Error applying setting, reverse things back [ 1.539184] pinctrl-nomadik soc:pinctrl: pin GPIO256_AF28 already requested by a03e0000.usb_per5; cannot claim for musb-hdrc.1.auto [ 1.551025] pinctrl-nomadik soc:pinctrl: pin-256 (musb-hdrc.1.auto) status -22 [ 1.558258] pinctrl-nomadik soc:pinctrl: could not request pin 256 (GPIO256_AF28) from group usb_a_1 on device pinctrl-nomadik [ 1.569732] musb-hdrc musb-hdrc.1.auto: Error applying setting, reverse things back [ 1.577453] HS USB OTG: no transceiver configured [ .. repeats until the end .. ] I think this is not related to this patch. ChenYu
On Wed, May 28, 2014 at 9:49 AM, Chen-Yu Tsai <wens@csie.org> wrote: > On Wed, May 28, 2014 at 4:25 PM, Linus Walleij <linus.walleij@linaro.org> wrote: >> On Wed, May 28, 2014 at 9:18 AM, Lee Jones <lee.jones@linaro.org> wrote: >>> On Tue, 27 May 2014, Rob Herring wrote: >>> >>>> On Tue, May 27, 2014 at 3:23 PM, Kevin Hilman <khilman@linaro.org> wrote: >>>> > On Fri, May 23, 2014 at 1:03 AM, Grant Likely <grant.likely@linaro.org> wrote: >>>> >> On Tue, 20 May 2014 13:42:02 +0300, Grygorii Strashko <grygorii.strashko@ti.com> wrote: >>>> >>> The commit 9ec36cafe43bf835f8f29273597a5b0cbc8267ef >>>> >>> "of/irq: do irq resolution in platform_get_irq" from Rob Herring - >>>> >>> moves resolving of the interrupt resources in platform_get_irq(). >>>> >>> But this solution isn't complete because platform_get_irq_byname() >>>> >>> need to be modified the same way. >>>> >>> >>>> >>> Hence, fix it by adding interrupt resolution code at the >>>> >>> platform_get_irq_byname() function too. >>>> >>> >>>> >>> Cc: Russell King <linux@arm.linux.org.uk> >>>> >>> Cc: Rob Herring <robh@kernel.org> >>>> >>> Cc: Tony Lindgren <tony@atomide.com> >>>> >>> Cc: Grant Likely <grant.likely@linaro.org> >>>> >>> Cc: Thierry Reding <thierry.reding@gmail.com> >>>> >>> >>>> >>> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> >>>> >> >>>> >> Applied, Thanks. >>>> > >>>> > As of next-20150526, the ST u8500 Snowball board has been failing boot >>>> > in linux-next, and was bisected down to this patch (commit >>>> > ad69674e73a1 in -next). Full boot failure attached. >>>> > >>>> > I have not dug any deeper, but can confirm that next-20140526 with >>>> > this patch reverted boots again on the snowball board. >>>> >>>> There's a patch on the list which fixes it. The problem is stmmac >>>> driver was expecting only one error code. >>> >>> Does Snowball even use stmmac? >> >> No. >> >> I don't get this... > > Log says musb is wrestling control over some pins with some other driver: > > [ 1.441497] pinctrl-nomadik soc:pinctrl: pin GPIO256_AF28 already > requested by a03e0000.usb_per5; cannot claim for musb-hdrc.0.auto > [ 1.453369] pinctrl-nomadik soc:pinctrl: pin-256 (musb-hdrc.0.auto) > status -22 > [ 1.460571] pinctrl-nomadik soc:pinctrl: could not request pin 256 > (GPIO256_AF28) from group usb_a_1 on device pinctrl-nomadik > [ 1.472076] musb-hdrc musb-hdrc.0.auto: Error applying setting, > reverse things back > [ 1.479827] HS USB OTG: no transceiver configured > [ 1.484558] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed > with status -517 > [ 1.492309] platform musb-hdrc.0.auto: Driver musb-hdrc requests > probe deferral > [ 1.500183] pinctrl-nomadik soc:pinctrl: pin GPIO256_AF28 already > requested by a03e0000.usb_per5; cannot claim for musb-hdrc.0.auto > [ 1.512023] pinctrl-nomadik soc:pinctrl: pin-256 (musb-hdrc.0.auto) > status -22 > [ 1.519226] pinctrl-nomadik soc:pinctrl: could not request pin 256 > (GPIO256_AF28) from group usb_a_1 on device pinctrl-nomadik > [ 1.530731] musb-ux500 musb-hdrc.0.auto: Error applying setting, > reverse things back > [ 1.539184] pinctrl-nomadik soc:pinctrl: pin GPIO256_AF28 already > requested by a03e0000.usb_per5; cannot claim for musb-hdrc.1.auto > [ 1.551025] pinctrl-nomadik soc:pinctrl: pin-256 (musb-hdrc.1.auto) > status -22 > [ 1.558258] pinctrl-nomadik soc:pinctrl: could not request pin 256 > (GPIO256_AF28) from group usb_a_1 on device pinctrl-nomadik > [ 1.569732] musb-hdrc musb-hdrc.1.auto: Error applying setting, > reverse things back > [ 1.577453] HS USB OTG: no transceiver configured > > [ .. repeats until the end .. ] > > I think this is not related to this patch. The bisected patch causes platform_get_irq() to always parse the devicetree to obtain the irq instead of using a precalculated value in the platform_device. There are two possible scenarios for this problem that I can think of: 1) Platform_get_irq() is getting called multiple times (which would happen on a deferred probe) but the setup code isn't handling it properly, like trying to request the GPIO more than once 2) the platform_device was preloaded with an irq number that differs from what is determined when parsing the tree. This would happen if a platform_device was created manually. g.
Hi All, On 05/28/2014 03:37 AM, Rob Herring wrote: > On Tue, May 27, 2014 at 3:23 PM, Kevin Hilman <khilman@linaro.org> wrote: >> On Fri, May 23, 2014 at 1:03 AM, Grant Likely <grant.likely@linaro.org> wrote: >>> On Tue, 20 May 2014 13:42:02 +0300, Grygorii Strashko <grygorii.strashko@ti.com> wrote: >>>> The commit 9ec36cafe43bf835f8f29273597a5b0cbc8267ef >>>> "of/irq: do irq resolution in platform_get_irq" from Rob Herring - >>>> moves resolving of the interrupt resources in platform_get_irq(). >>>> But this solution isn't complete because platform_get_irq_byname() >>>> need to be modified the same way. >>>> >>>> Hence, fix it by adding interrupt resolution code at the >>>> platform_get_irq_byname() function too. >>>> >>>> Cc: Russell King <linux@arm.linux.org.uk> >>>> Cc: Rob Herring <robh@kernel.org> >>>> Cc: Tony Lindgren <tony@atomide.com> >>>> Cc: Grant Likely <grant.likely@linaro.org> >>>> Cc: Thierry Reding <thierry.reding@gmail.com> >>>> >>>> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> >>> >>> Applied, Thanks. >> >> As of next-20150526, the ST u8500 Snowball board has been failing boot >> in linux-next, and was bisected down to this patch (commit >> ad69674e73a1 in -next). Full boot failure attached. >> >> I have not dug any deeper, but can confirm that next-20140526 with >> this patch reverted boots again on the snowball board. > > There's a patch on the list which fixes it. The problem is stmmac > driver was expecting only one error code. > Seems root cause of problem is hidden inside MFD ab8500-core.c :( And it's related to simulations supporting of DT and non-DT devices. For example: ----- Log file contains lines [ 0.919677] ab8500-debug ab8500-debug.0: First irq not found, err -22 [ 0.926147] ab8500-debug: probe of ab8500-debug.0 failed with error -22 DT definition of ab8500-debug is specified as following (ste-dbx5x0.dtsi): ab8500-debugfs { compatible = "stericsson,ab8500-debug"; }; In code ab8500-debug is created using mfd_add_devices() API which fills device's resources manually, but, in same time, It links ab8500-debug device to DT node because MFD cell has of_compatible property set to: .of_compatible = "stericsson,ab8500-debug", Problem: both new versions of APIs platform_get_irq_byname() and platform_get_irq() will fail to get IRQ. Another problem is: [ 1.038909] abx5x0-usb ab8500-usb.0: Link status irq not found - looking on it now - it should work Best regards, -grygorii
On Wed, May 28, 2014 at 10:49 AM, Chen-Yu Tsai <wens@csie.org> wrote: > Log says musb is wrestling control over some pins with some other driver: > > [ 1.441497] pinctrl-nomadik soc:pinctrl: pin GPIO256_AF28 already > requested by a03e0000.usb_per5; cannot claim for musb-hdrc.0.auto > [ 1.453369] pinctrl-nomadik soc:pinctrl: pin-256 (musb-hdrc.0.auto) > status -22 > [ 1.460571] pinctrl-nomadik soc:pinctrl: could not request pin 256 > (GPIO256_AF28) from group usb_a_1 on device pinctrl-nomadik > [ 1.472076] musb-hdrc musb-hdrc.0.auto: Error applying setting, > reverse things back > [ 1.479827] HS USB OTG: no transceiver configured > [ 1.484558] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed > with status -517 > [ 1.492309] platform musb-hdrc.0.auto: Driver musb-hdrc requests > probe deferral > [ 1.500183] pinctrl-nomadik soc:pinctrl: pin GPIO256_AF28 already > requested by a03e0000.usb_per5; cannot claim for musb-hdrc.0.auto > [ 1.512023] pinctrl-nomadik soc:pinctrl: pin-256 (musb-hdrc.0.auto) > status -22 > [ 1.519226] pinctrl-nomadik soc:pinctrl: could not request pin 256 > (GPIO256_AF28) from group usb_a_1 on device pinctrl-nomadik > [ 1.530731] musb-ux500 musb-hdrc.0.auto: Error applying setting, > reverse things back > [ 1.539184] pinctrl-nomadik soc:pinctrl: pin GPIO256_AF28 already > requested by a03e0000.usb_per5; cannot claim for musb-hdrc.1.auto > [ 1.551025] pinctrl-nomadik soc:pinctrl: pin-256 (musb-hdrc.1.auto) > status -22 > [ 1.558258] pinctrl-nomadik soc:pinctrl: could not request pin 256 > (GPIO256_AF28) from group usb_a_1 on device pinctrl-nomadik > [ 1.569732] musb-hdrc musb-hdrc.1.auto: Error applying setting, > reverse things back > [ 1.577453] HS USB OTG: no transceiver configured > > [ .. repeats until the end .. ] > > I think this is not related to this patch. No that is fixed i this patch: http://marc.info/?l=linux-usb&m=140239049219096&w=2 Yours, Linus Walleij
diff --git a/drivers/base/platform.c b/drivers/base/platform.c index 5b47210..9e9227e 100644 --- a/drivers/base/platform.c +++ b/drivers/base/platform.c @@ -131,9 +131,12 @@ EXPORT_SYMBOL_GPL(platform_get_resource_byname); */ int platform_get_irq_byname(struct platform_device *dev, const char *name) { - struct resource *r = platform_get_resource_byname(dev, IORESOURCE_IRQ, - name); + struct resource *r; + + if (IS_ENABLED(CONFIG_OF_IRQ) && dev->dev.of_node) + return of_irq_get_byname(dev->dev.of_node, name); + r = platform_get_resource_byname(dev, IORESOURCE_IRQ, name); return r ? r->start : -ENXIO; } EXPORT_SYMBOL_GPL(platform_get_irq_byname); diff --git a/drivers/of/irq.c b/drivers/of/irq.c index 5aeb894..3e06a69 100644 --- a/drivers/of/irq.c +++ b/drivers/of/irq.c @@ -406,6 +406,28 @@ int of_irq_get(struct device_node *dev, int index) } /** + * of_irq_get_byname - Decode a node's IRQ and return it as a Linux irq number + * @dev: pointer to device tree node + * @name: irq name + * + * Returns Linux irq number on success, or -EPROBE_DEFER if the irq domain + * is not yet created, or error code in case of any other failure. + */ +int of_irq_get_byname(struct device_node *dev, const char *name) +{ + int index; + + if (unlikely(!name)) + return -EINVAL; + + index = of_property_match_string(dev, "interrupt-names", name); + if (index < 0) + return index; + + return of_irq_get(dev, index); +} + +/** * of_irq_count - Count the number of IRQs a node uses * @dev: pointer to device tree node */ diff --git a/include/linux/of_irq.h b/include/linux/of_irq.h index 6404253..bfec136 100644 --- a/include/linux/of_irq.h +++ b/include/linux/of_irq.h @@ -45,6 +45,7 @@ extern void of_irq_init(const struct of_device_id *matches); #ifdef CONFIG_OF_IRQ extern int of_irq_count(struct device_node *dev); extern int of_irq_get(struct device_node *dev, int index); +extern int of_irq_get_byname(struct device_node *dev, const char *name); #else static inline int of_irq_count(struct device_node *dev) { @@ -54,6 +55,10 @@ static inline int of_irq_get(struct device_node *dev, int index) { return 0; } +static inline int of_irq_get_byname(struct device_node *dev, const char *name) +{ + return 0; +} #endif #if defined(CONFIG_OF)
The commit 9ec36cafe43bf835f8f29273597a5b0cbc8267ef "of/irq: do irq resolution in platform_get_irq" from Rob Herring - moves resolving of the interrupt resources in platform_get_irq(). But this solution isn't complete because platform_get_irq_byname() need to be modified the same way. Hence, fix it by adding interrupt resolution code at the platform_get_irq_byname() function too. Cc: Russell King <linux@arm.linux.org.uk> Cc: Rob Herring <robh@kernel.org> Cc: Tony Lindgren <tony@atomide.com> Cc: Grant Likely <grant.likely@linaro.org> Cc: Thierry Reding <thierry.reding@gmail.com> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> --- Changes in v1: - use of_property_match_string() to get IRQ index by name - minor comments fixed RFC: https://lkml.org/lkml/2014/5/19/325 drivers/base/platform.c | 7 +++++-- drivers/of/irq.c | 22 ++++++++++++++++++++++ include/linux/of_irq.h | 5 +++++ 3 files changed, 32 insertions(+), 2 deletions(-)