[PATCH v1] of/irq: do irq resolution in platform_get_irq_byname()

[Chen-Yu Tsai]

On Wed, May 28, 2014 at 4:25 PM, Linus Walleij <linus.walleij at linaro.org> wrote:
> On Wed, May 28, 2014 at 9:18 AM, Lee Jones <lee.jones at linaro.org> wrote:
>> On Tue, 27 May 2014, Rob Herring wrote:
>>
>>> On Tue, May 27, 2014 at 3:23 PM, Kevin Hilman <khilman at linaro.org> wrote:
>>> > On Fri, May 23, 2014 at 1:03 AM, Grant Likely <grant.likely at linaro.org> wrote:
>>> >> On Tue, 20 May 2014 13:42:02 +0300, Grygorii Strashko <grygorii.strashko at 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 at arm.linux.org.uk>
>>> >>> Cc: Rob Herring <robh at kernel.org>
>>> >>> Cc: Tony Lindgren <tony at atomide.com>
>>> >>> Cc: Grant Likely <grant.likely at linaro.org>
>>> >>> Cc: Thierry Reding <thierry.reding at gmail.com>
>>> >>>
>>> >>> Signed-off-by: Grygorii Strashko <grygorii.strashko at 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