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. And we are hit this sequence with my patch that adds .set_config for gpio_chip [1]. Shawn [1] https://lore.kernel.org/linux-gpio/YEDVMpHyCGbZOrmF@xxxxxxxxxxxxxxxxxx/
