[PATCH 0/4] Fix number of pins in 'gpio-ranges'

[PATCH 0/4] Fix number of pins in 'gpio-ranges'

[Shawn Guo]

The fixes are split per SoC to ease the stable kernel pick-up.

Shawn Guo (4):
  arm64: dts: qcom: sdm845: fix number of pins in 'gpio-ranges'
  arm64: dts: qcom: sm8150: fix number of pins in 'gpio-ranges'
  arm64: dts: qcom: sm8250: fix number of pins in 'gpio-ranges'
  arm64: dts: qcom: sm8350: fix number of pins in 'gpio-ranges'

 arch/arm64/boot/dts/qcom/sdm845.dtsi | 2 +-
 arch/arm64/boot/dts/qcom/sm8150.dtsi | 2 +-
 arch/arm64/boot/dts/qcom/sm8250.dtsi | 2 +-
 arch/arm64/boot/dts/qcom/sm8350.dtsi | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

-- 
2.17.1

[PATCH 1/4] arm64: dts: qcom: sdm845: fix number of pins in 'gpio-ranges'

[Shawn Guo]

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 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()

Fixes: bc2c806293c6 ("arm64: dts: qcom: sdm845: Add gpio-ranges to TLMM node")
Cc: Evan Green <evgreen@chromium.org>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
 arch/arm64/boot/dts/qcom/sdm845.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 454f794af547..6a2ed02d383d 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -2382,7 +2382,7 @@
 			#gpio-cells = <2>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
-			gpio-ranges = <&tlmm 0 0 150>;
+			gpio-ranges = <&tlmm 0 0 151>;
 			wakeup-parent = <&pdc_intc>;
 
 			cci0_default: cci0-default {
-- 
2.17.1

Re: [PATCH 1/4] arm64: dts: qcom: sdm845: fix number of pins in 'gpio-ranges'

[Bjorn Andersson]

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?

> 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?

Regards,
Bjorn

> 
> Fixes: bc2c806293c6 ("arm64: dts: qcom: sdm845: Add gpio-ranges to TLMM node")
> Cc: Evan Green <evgreen@chromium.org>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> ---
>  arch/arm64/boot/dts/qcom/sdm845.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index 454f794af547..6a2ed02d383d 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -2382,7 +2382,7 @@
>  			#gpio-cells = <2>;
>  			interrupt-controller;
>  			#interrupt-cells = <2>;
> -			gpio-ranges = <&tlmm 0 0 150>;
> +			gpio-ranges = <&tlmm 0 0 151>;
>  			wakeup-parent = <&pdc_intc>;
>  
>  			cci0_default: cci0-default {
> -- 
> 2.17.1
> 

Re: [PATCH 1/4] arm64: dts: qcom: sdm845: fix number of pins in 'gpio-ranges'

[Shawn Guo]

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@smile.fi.intel.com/

Re: [PATCH 1/4] arm64: dts: qcom: sdm845: fix number of pins in 'gpio-ranges'

[Bjorn Andersson]

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@smile.fi.intel.com/

Re: [PATCH 1/4] arm64: dts: qcom: sdm845: fix number of pins in 'gpio-ranges'

[Shawn Guo]

On Fri, Mar 05, 2021 at 07:56:02PM -0600, Bjorn Andersson wrote:
> 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.

Right now, I do not have to request and configure this UFS GPIO for
getting UFS work with ACPI kernel.  And the immediate problem we have is
that with gpio_chip .set_config patch, devm_gpiod_get_optional() call
from UFS driver always gets -EPROBE_DEFER.

> 
> > 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?

  ufs_qcom_probe
    ufshcd_pltfrm_init
      ufshcd_init
        ufs_qcom_init
          devm_gpiod_get_optional
            devm_gpiod_get_index
              gpiod_get_index
                gpiod_configure_flags
                  gpiod_direction_output
                    gpiochip_generic_config

Shawn

Re: [PATCH 1/4] arm64: dts: qcom: sdm845: fix number of pins in 'gpio-ranges'

[Bjorn Andersson]

On Sat 06 Mar 02:00 CST 2021, Shawn Guo wrote:

> On Fri, Mar 05, 2021 at 07:56:02PM -0600, Bjorn Andersson wrote:
> > 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.
> 
> Right now, I do not have to request and configure this UFS GPIO for
> getting UFS work with ACPI kernel.  And the immediate problem we have is
> that with gpio_chip .set_config patch, devm_gpiod_get_optional() call
> from UFS driver always gets -EPROBE_DEFER.
> 

But we don't have a "reset" GPIO specified in the ACPI node, or you mean
with the introduction of .set_config DT no longer works?

Regards,
Bjorn

> > 
> > > 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?
> 
>   ufs_qcom_probe
>     ufshcd_pltfrm_init
>       ufshcd_init
>         ufs_qcom_init
>           devm_gpiod_get_optional
>             devm_gpiod_get_index
>               gpiod_get_index
>                 gpiod_configure_flags
>                   gpiod_direction_output
>                     gpiochip_generic_config
> 
> Shawn

Re: [PATCH 1/4] arm64: dts: qcom: sdm845: fix number of pins in 'gpio-ranges'

[Shawn Guo]

On Wed, Mar 10, 2021 at 12:22:32PM -0600, Bjorn Andersson wrote:
> On Sat 06 Mar 02:00 CST 2021, Shawn Guo wrote:
> 
> > On Fri, Mar 05, 2021 at 07:56:02PM -0600, Bjorn Andersson wrote:
> > > 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.
> > 
> > Right now, I do not have to request and configure this UFS GPIO for
> > getting UFS work with ACPI kernel.  And the immediate problem we have is
> > that with gpio_chip .set_config patch, devm_gpiod_get_optional() call
> > from UFS driver always gets -EPROBE_DEFER.
> > 
> 
> But we don't have a "reset" GPIO specified in the ACPI node, or you mean
> with the introduction of .set_config DT no longer works?

Yes, DT stops working because of the mismatch between
msm_pinctrl_soc_data.ngpio and gpio-ranges.

Shawn

Re: [PATCH 1/4] arm64: dts: qcom: sdm845: fix number of pins in 'gpio-ranges'

[Bjorn Andersson]

On Wed 10 Mar 19:19 CST 2021, Shawn Guo wrote:

> On Wed, Mar 10, 2021 at 12:22:32PM -0600, Bjorn Andersson wrote:
> > On Sat 06 Mar 02:00 CST 2021, Shawn Guo wrote:
> > 
> > > On Fri, Mar 05, 2021 at 07:56:02PM -0600, Bjorn Andersson wrote:
> > > > 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.
> > > 
> > > Right now, I do not have to request and configure this UFS GPIO for
> > > getting UFS work with ACPI kernel.  And the immediate problem we have is
> > > that with gpio_chip .set_config patch, devm_gpiod_get_optional() call
> > > from UFS driver always gets -EPROBE_DEFER.
> > > 
> > 
> > But we don't have a "reset" GPIO specified in the ACPI node, or you mean
> > with the introduction of .set_config DT no longer works?
> 
> Yes, DT stops working because of the mismatch between
> msm_pinctrl_soc_data.ngpio and gpio-ranges.
> 

So what you're saying is that when Linus merged the .set_config patch
yesterday he broke storage on every single Qualcomm device?

Regards,
Bjorn

Re: [PATCH 1/4] arm64: dts: qcom: sdm845: fix number of pins in 'gpio-ranges'

[Shawn Guo]

On Thu, Mar 11, 2021 at 10:53:49AM -0600, Bjorn Andersson wrote:
> On Wed 10 Mar 19:19 CST 2021, Shawn Guo wrote:
> > Yes, DT stops working because of the mismatch between
> > msm_pinctrl_soc_data.ngpio and gpio-ranges.
> > 
> 
> So what you're saying is that when Linus merged the .set_config patch
> yesterday he broke storage on every single Qualcomm device?

Better than that.  Only the ones that have mismatching between
msm_pinctrl_soc_data.ngpio and gpio-ranges.  More specifically, the ones
that the series are fixing.

I didn't realize this break when I was working on the .set_config change
for ACPI.  It was a surprise when I tested DT later.  You can ask Linus
to drop .set_config patch, if you do not like this break.  But I think
the mismatch issue still needs to be resolved in some way.

Shawn

Re: [PATCH 1/4] arm64: dts: qcom: sdm845: fix number of pins in 'gpio-ranges'

[Bjorn Andersson]

On Thu 11 Mar 17:09 CST 2021, Shawn Guo wrote:

> On Thu, Mar 11, 2021 at 10:53:49AM -0600, Bjorn Andersson wrote:
> > On Wed 10 Mar 19:19 CST 2021, Shawn Guo wrote:
> > > Yes, DT stops working because of the mismatch between
> > > msm_pinctrl_soc_data.ngpio and gpio-ranges.
> > > 
> > 
> > So what you're saying is that when Linus merged the .set_config patch
> > yesterday he broke storage on every single Qualcomm device?
> 
> Better than that.  Only the ones that have mismatching between
> msm_pinctrl_soc_data.ngpio and gpio-ranges.  More specifically, the ones
> that the series are fixing.
> 
> I didn't realize this break when I was working on the .set_config change
> for ACPI.  It was a surprise when I tested DT later.  You can ask Linus
> to drop .set_config patch, if you do not like this break.  But I think
> the mismatch issue still needs to be resolved in some way.
> 

We're exposing the UFS as a gpio and I think that these patches
therefore are correct, so I've picked them up.

But I don't think we should break backwards compatibility will all
existing DTBs...

Regards,
Bjorn

Re: [PATCH 1/4] arm64: dts: qcom: sdm845: fix number of pins in 'gpio-ranges'

[Linus Walleij]

On Thu, Mar 11, 2021 at 5:53 PM Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
> On Wed 10 Mar 19:19 CST 2021, Shawn Guo wrote:

> > > But we don't have a "reset" GPIO specified in the ACPI node, or you mean
> > > with the introduction of .set_config DT no longer works?
> >
> > Yes, DT stops working because of the mismatch between
> > msm_pinctrl_soc_data.ngpio and gpio-ranges.
> >
>
> So what you're saying is that when Linus merged the .set_config patch
> yesterday he broke storage on every single Qualcomm device?

I took out that patch for now.

Maybe we can keep all the stuff in one series if it has strict
dependencies?

Yours,
Linus Walleij

[PATCH 2/4] arm64: dts: qcom: sm8150: fix number of pins in 'gpio-ranges'

[Shawn Guo]

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 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()

Fixes: e13c6d144fa0 ("arm64: dts: qcom: sm8150: Add base dts file")
Cc: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
 arch/arm64/boot/dts/qcom/sm8150.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi b/arch/arm64/boot/dts/qcom/sm8150.dtsi
index e5bb17bc2f46..778613d3410b 100644
--- a/arch/arm64/boot/dts/qcom/sm8150.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8150.dtsi
@@ -914,7 +914,7 @@
 			      <0x0 0x03D00000 0x0 0x300000>;
 			reg-names = "west", "east", "north", "south";
 			interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
-			gpio-ranges = <&tlmm 0 0 175>;
+			gpio-ranges = <&tlmm 0 0 176>;
 			gpio-controller;
 			#gpio-cells = <2>;
 			interrupt-controller;
-- 
2.17.1

[PATCH 3/4] arm64: dts: qcom: sm8250: fix number of pins in 'gpio-ranges'

[Shawn Guo]

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 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()

Fixes: 16951b490b20 ("arm64: dts: qcom: sm8250: Add TLMM pinctrl node")
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
 arch/arm64/boot/dts/qcom/sm8250.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi b/arch/arm64/boot/dts/qcom/sm8250.dtsi
index 947e1accae3a..e7edb2593ba1 100644
--- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
@@ -2689,7 +2689,7 @@
 			#gpio-cells = <2>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
-			gpio-ranges = <&tlmm 0 0 180>;
+			gpio-ranges = <&tlmm 0 0 181>;
 			wakeup-parent = <&pdc>;
 
 			pri_mi2s_active: pri-mi2s-active {
-- 
2.17.1

[PATCH 4/4] arm64: dts: qcom: sm8350: fix number of pins in 'gpio-ranges'

[Shawn Guo]

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 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()

Fixes: b7e8f433a673 ("arm64: dts: qcom: Add basic devicetree support for SM8350 SoC")
Cc: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
 arch/arm64/boot/dts/qcom/sm8350.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/sm8350.dtsi b/arch/arm64/boot/dts/qcom/sm8350.dtsi
index 5ef460458f5c..fab211298c35 100644
--- a/arch/arm64/boot/dts/qcom/sm8350.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8350.dtsi
@@ -382,7 +382,7 @@
 			#gpio-cells = <2>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
-			gpio-ranges = <&tlmm 0 0 203>;
+			gpio-ranges = <&tlmm 0 0 204>;
 
 			qup_uart3_default_state: qup-uart3-default-state {
 				rx {
-- 
2.17.1

Re: [PATCH 0/4] Fix number of pins in 'gpio-ranges'

[patchwork-bot+linux-arm-msm]

Hello:

This series was applied to qcom/linux.git (refs/heads/for-next):

On Wed,  3 Mar 2021 11:31:02 +0800 you wrote:
> The fixes are split per SoC to ease the stable kernel pick-up.
> 
> Shawn Guo (4):
>   arm64: dts: qcom: sdm845: fix number of pins in 'gpio-ranges'
>   arm64: dts: qcom: sm8150: fix number of pins in 'gpio-ranges'
>   arm64: dts: qcom: sm8250: fix number of pins in 'gpio-ranges'
>   arm64: dts: qcom: sm8350: fix number of pins in 'gpio-ranges'
> 
> [...]

Here is the summary with links:
  - [1/4] arm64: dts: qcom: sdm845: fix number of pins in 'gpio-ranges'
    https://git.kernel.org/qcom/c/c0590924525a
  - [2/4] arm64: dts: qcom: sm8150: fix number of pins in 'gpio-ranges'
    https://git.kernel.org/qcom/c/dca9464b366c
  - [3/4] arm64: dts: qcom: sm8250: fix number of pins in 'gpio-ranges'
    https://git.kernel.org/qcom/c/126195a71c04
  - [4/4] arm64: dts: qcom: sm8350: fix number of pins in 'gpio-ranges'
    https://git.kernel.org/qcom/c/0d37f5077ffb

You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html