On Fri 05 Mar 19:28 CST 2021, Shawn Guo wrote: > On Fri, Mar 05, 2021 at 03:43:08PM -0600, Bjorn Andersson wrote: > > On Tue 02 Mar 21:31 CST 2021, Shawn Guo wrote: > > > > > The last cell of 'gpio-ranges' should be number of GPIO pins, and in > > > case of qcom platform it should match msm_pinctrl_soc_data.ngpio rather > > > than msm_pinctrl_soc_data.ngpio - 1. > > > > > > > This is a historical artifact, SDM845 has 150 GPIO pins. In addition to > > this there's an output-only pin for UFS, which I exposed as an GPIO as > > well - but it's only supposed to be used as a reset-gpio for the UFS > > device. > > > > Perhaps that still mandates that gpio-ranges should cover it? > > I think the number in DT gpio-ranges should match msm_pinctrl_soc_data.ngpio. > Otherwise, kernel will be confused and be running into the issue like > below in some case. > > > > > > This fixes the problem that when the last GPIO pin in the range is > > > configured with the following call sequence, it always fails with > > > -EPROBE_DEFER. > > > > > > pinctrl_gpio_set_config() > > > pinctrl_get_device_gpio_range() > > > pinctrl_match_gpio_range() > > > > When do we hit this sequence? I didn't think operations on the UFS > > GP(I)O would ever take this code path? > > It will, if we have UFS driver booting from ACPI and requesting reset > GPIO. But does the UFS driver somehow request GPIO 190 on SC8180x? I made up the idea that this is a GPIO, there really only is 190 (0-189) GPIOs on thie SoC. Downstream they use a pinconf node with "output-high"/"output-low" to toggle the reset pin and I don't find any references in the Flex 5G DSDT. > And we are hit this sequence with my patch that adds .set_config > for gpio_chip [1]. > What's calling pinctrl_gpio_set_config() in this case? Regards, Bjorn > Shawn > > [1] https://lore.kernel.org/linux-gpio/YEDVMpHyCGbZOrmF@xxxxxxxxxxxxxxxxxx/
