gpio hogging fails with pinctrl gpio drivers
Hi Linus,
It seems that sometime between 4.20 and 5.5, something has broken the ability to specify gpio-hogs in DT for GPIOs that are written around pinctrl drivers.
For example:
gpio6: sx1503@20 {
compatible = "semtech,sx1503q";
...
phy_rst {
gpio-hog;
gpios = <9 GPIO_ACTIVE_HIGH>;
output-high;
line-name = "10g-rstn";
};
};fails with:
gpio gpiochip7: (sx1503q): setup of own GPIO 10g-rstn failed requesting hog GPIO 10g-rstn (chip sx1503q, offset 9) failed, -517 gpiochip_add_data_with_key: GPIOs 480..495 (sx1503q) failed to register, -517
It appears that the reason for this failure is that the hogs are requested in gpiochip_add_data_with_key(), called from devm_gpiochip_add_data(), but as the set_config method points to gpiochip_generic_config, it wants to look up the pinctrl pin range via pinctrl_get_device_gpio_range(). However, that has not been setup yet, as the following call to gpiochip_add_pin_range() has not been reached:
ret = devm_gpiochip_add_data(dev, &pctl->gpio, pctl);
if (ret)
return ret;
ret = gpiochip_add_pin_range(&pctl->gpio, dev_name(dev),
0, 0, pctl->data->npins);and so pinctrl_get_device_gpio_range() returns -EPROBE_DEFER.
Consequently, adding a gpio-hog to DT for this driver results in the driver endlessly returning -EPROBE_DEFER.
Signature · 8 lines
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up _______________________________________________ linux-arm-kernel mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Quoted 3 lines · Russell King - ARM Linux admin
It seems that sometime between 4.20 and 5.5, something has broken the ability to specify gpio-hogs in DT for GPIOs that are written around pinctrl drivers.
(explanation that makes perfect sense)
Quoted 2 lines
Consequently, adding a gpio-hog to DT for this driver results in the driver endlessly returning -EPROBE_DEFER.
I suspect this is sx150x-specific and suspect these two commits:
1a1d39e1b8dd pinctrl: sx150x: Register pinctrl before adding the gpiochip b930151e5b55 pinctrl: sx150x: Add a static gpio/pinctrl pin range mapping
I suppose people weren't using hogs very much with the sx150x and it didn't turn up in testing so far.
I don't think for example pinctrl-stmfx.c has this problem, as it registers the pin ranges from the device tree as part of the core code. But other drivers calling gpiochip_add_pin_range() may be experiencing this.
Peter/Andrey, do you have some idea? Have you tested this usecase (hogs) with the sx150x?
Yours,
Linus Walleij
Quoted 18 lines · Linus Walleij
Quoted 3 lines · Russell King - ARM Linux admin
It seems that sometime between 4.20 and 5.5, something has broken the ability to specify gpio-hogs in DT for GPIOs that are written around pinctrl drivers.
(explanation that makes perfect sense)
Quoted 2 lines
Consequently, adding a gpio-hog to DT for this driver results in the driver endlessly returning -EPROBE_DEFER.
I suspect this is sx150x-specific and suspect these two commits:
1a1d39e1b8ddpinctrl: sx150x: Register pinctrl before adding the gpiochipb930151e5b55pinctrl: sx150x: Add a static gpio/pinctrl pin range mappingI suppose people weren't using hogs very much with the sx150x and it didn't turn up in testing so far.
Quoted 7 lines
I don't think for example
pinctrl-stmfx.chas this problem, as it registers the pin ranges from the device tree as part of the core code. But other drivers callinggpiochip_add_pin_range()may be experiencing this.Peter/Andrey, do you have some idea? Have you tested this usecase (hogs) with the sx150x?
I have never created gpio hogs myself, so no, I haven't done any testing with that. Sorry. I could of course spend some time looking at this, but I don't know all that much about the wrinkles of the interactions between pinctrl och gpio. Or plain gpio/pinctrl for that matter. Sure, I extended this driver, but I haven't really looked at those sub-systems since. I think others will come up with a solution for this with much less effort and with less risk of introducing new problems...
Cheers,
Peter
Quoted 19 lines · Linus Walleij
Quoted 3 lines · Russell King - ARM Linux admin
It seems that sometime between 4.20 and 5.5, something has broken the ability to specify gpio-hogs in DT for GPIOs that are written around pinctrl drivers.
(explanation that makes perfect sense)
Quoted 2 lines
Consequently, adding a gpio-hog to DT for this driver results in the driver endlessly returning -EPROBE_DEFER.
I suspect this is sx150x-specific and suspect these two commits:
1a1d39e1b8ddpinctrl: sx150x: Register pinctrl before adding the gpiochipb930151e5b55pinctrl: sx150x: Add a static gpio/pinctrl pin range mappingI suppose people weren't using hogs very much with the sx150x and it didn't turn up in testing so far.
Quoted 8 lines
I don't think for example
pinctrl-stmfx.chas this problem, as it registers the pin ranges from the device tree as part of the core code. But other drivers callinggpiochip_add_pin_range()may be experiencing this.Peter/Andrey, do you have some idea? Have you tested this usecase (hogs) with the sx150x?
Haven't done any GPIO hogging on sx150x, unfortunately. My use-cases were:
and
which didn't have any hogs so far (there's a chance Russell is using the former for his experiments, so maybe that'll change). I don't any useful input on this regression, sorry. I do have Rev C. board readily available, so I can provide Tested-by's if I am CC'd on fixes.
Thanks,
Andrey Smirnov
Quoted 33 lines · Andrey Smirnov
Quoted 19 lines · Linus Walleij
Quoted 3 lines · Russell King - ARM Linux admin
It seems that sometime between 4.20 and 5.5, something has broken the ability to specify gpio-hogs in DT for GPIOs that are written around pinctrl drivers.
(explanation that makes perfect sense)
Quoted 2 lines
Consequently, adding a gpio-hog to DT for this driver results in the driver endlessly returning -EPROBE_DEFER.
I suspect this is sx150x-specific and suspect these two commits:
1a1d39e1b8ddpinctrl: sx150x: Register pinctrl before adding the gpiochipb930151e5b55pinctrl: sx150x: Add a static gpio/pinctrl pin range mappingI suppose people weren't using hogs very much with the sx150x and it didn't turn up in testing so far.
Quoted 8 lines
I don't think for example
pinctrl-stmfx.chas this problem, as it registers the pin ranges from the device tree as part of the core code. But other drivers callinggpiochip_add_pin_range()may be experiencing this.Peter/Andrey, do you have some idea? Have you tested this usecase (hogs) with the sx150x?
Haven't done any GPIO hogging on sx150x, unfortunately. My use-cases were:
Quoted 8 lines
and
which didn't have any hogs so far (there's a chance Russell is using the former for his experiments, so maybe that'll change). I don't any useful input on this regression, sorry. I do have Rev C. board readily available, so I can provide Tested-by's if I am CC'd on fixes.
The ZII dev rev C is where I had the hog as a means of kicking the 88x3310 PHY out of reset.
I've now converted it to a proper MDIO bus-level reset, so I no longer have the hog, and I no longer care about the regression - but that's not to say it shouldn't be fixed, as the code is wrong.
Signature · 3 lines
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up