ACPI / gpio: do not fall back to parsing _CRS when we get a deferral
diff mbox

Message ID 20170323202138.GA11912@dtor-ws
State New
Headers show

Commit Message

Dmitry Torokhov March 23, 2017, 8:21 p.m. UTC
If, while locating GPIOs by name, we get probe deferral, we should
immediately report it to caller rather than trying to fall back to parsing
unnamed GPIOs from _CRS block.

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
 drivers/gpio/gpiolib-acpi.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

Comments

Linus Walleij March 28, 2017, 1:25 p.m. UTC | #1
On Thu, Mar 23, 2017 at 9:21 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:

> If, while locating GPIOs by name, we get probe deferral, we should
> immediately report it to caller rather than trying to fall back to parsing
> unnamed GPIOs from _CRS block.
>
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Can I get some indication from Mika/Rafael/Andy whether this is correct?

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Mika Westerberg March 28, 2017, 1:32 p.m. UTC | #2
On Tue, Mar 28, 2017 at 03:25:56PM +0200, Linus Walleij wrote:
> On Thu, Mar 23, 2017 at 9:21 PM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> 
> > If, while locating GPIOs by name, we get probe deferral, we should
> > immediately report it to caller rather than trying to fall back to parsing
> > unnamed GPIOs from _CRS block.
> >
> > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> 
> Can I get some indication from Mika/Rafael/Andy whether this is correct?

Sorry, I saw the patch but then forgot to ack it.

Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Andy Shevchenko March 28, 2017, 3:03 p.m. UTC | #3
On Tue, 2017-03-28 at 15:25 +0200, Linus Walleij wrote:
> On Thu, Mar 23, 2017 at 9:21 PM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> 
> > If, while locating GPIOs by name, we get probe deferral, we should
> > immediately report it to caller rather than trying to fall back to
> > parsing
> > unnamed GPIOs from _CRS block.
> > 
> > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> 
> Can I get some indication from Mika/Rafael/Andy whether this is
> correct?

While Mika agrees on the change, I would like nevertheless to hear Hans'
opinion or even Tested-by tag since it was his fix around those lines.
Andy Shevchenko March 28, 2017, 3:04 p.m. UTC | #4
On Thu, 2017-03-23 at 13:21 -0700, Dmitry Torokhov wrote:
> If, while locating GPIOs by name, we get probe deferral, we should
> immediately report it to caller rather than trying to fall back to
> parsing
> unnamed GPIOs from _CRS block.

+Cc: Hans.

Hans, do have any objections on this? Would you ideally give your
Tested-by?

> 
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> ---
>  drivers/gpio/gpiolib-acpi.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpio/gpiolib-acpi.c b/drivers/gpio/gpiolib-acpi.c
> index a3faefa44f68..d3f9f028a37b 100644
> --- a/drivers/gpio/gpiolib-acpi.c
> +++ b/drivers/gpio/gpiolib-acpi.c
> @@ -572,8 +572,10 @@ struct gpio_desc *acpi_find_gpio(struct device
> *dev,
>  		}
>  
>  		desc = acpi_get_gpiod_by_index(adev, propname, idx,
> &info);
> -		if (!IS_ERR(desc) || (PTR_ERR(desc) ==
> -EPROBE_DEFER))
> +		if (!IS_ERR(desc))
>  			break;
> +		if (PTR_ERR(desc) == -EPROBE_DEFER)
> +			return ERR_CAST(desc);
>  	}
>  
>  	/* Then from plain _CRS GPIOs */
> -- 
> 2.12.1.500.gab5fba24ee-goog
> 
>
Hans de Goede March 29, 2017, 4:33 p.m. UTC | #5
HI,

On 28-03-17 17:04, Andy Shevchenko wrote:
> On Thu, 2017-03-23 at 13:21 -0700, Dmitry Torokhov wrote:
>> If, while locating GPIOs by name, we get probe deferral, we should
>> immediately report it to caller rather than trying to fall back to
>> parsing
>> unnamed GPIOs from _CRS block.
>
> +Cc: Hans.
>
> Hans, do have any objections on this? Would you ideally give your
> Tested-by?

Looks good to me and also does not seem to break anything on my test
devices, so:

Acked-and-Tested-by: Hans de Goede <hdegoede@redhat.com>

Regards,

Hans


>
>>
>> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>> ---
>>  drivers/gpio/gpiolib-acpi.c | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpio/gpiolib-acpi.c b/drivers/gpio/gpiolib-acpi.c
>> index a3faefa44f68..d3f9f028a37b 100644
>> --- a/drivers/gpio/gpiolib-acpi.c
>> +++ b/drivers/gpio/gpiolib-acpi.c
>> @@ -572,8 +572,10 @@ struct gpio_desc *acpi_find_gpio(struct device
>> *dev,
>>  		}
>>
>>  		desc = acpi_get_gpiod_by_index(adev, propname, idx,
>> &info);
>> -		if (!IS_ERR(desc) || (PTR_ERR(desc) ==
>> -EPROBE_DEFER))
>> +		if (!IS_ERR(desc))
>>  			break;
>> +		if (PTR_ERR(desc) == -EPROBE_DEFER)
>> +			return ERR_CAST(desc);
>>  	}
>>
>>  	/* Then from plain _CRS GPIOs */
>> --
>> 2.12.1.500.gab5fba24ee-goog
>>
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Andy Shevchenko March 29, 2017, 4:42 p.m. UTC | #6
On Wed, 2017-03-29 at 18:33 +0200, Hans de Goede wrote:
> HI,
> 
> On 28-03-17 17:04, Andy Shevchenko wrote:
> > On Thu, 2017-03-23 at 13:21 -0700, Dmitry Torokhov wrote:
> > > If, while locating GPIOs by name, we get probe deferral, we should
> > > immediately report it to caller rather than trying to fall back to
> > > parsing
> > > unnamed GPIOs from _CRS block.
> > 
> > +Cc: Hans.
> > 
> > Hans, do have any objections on this? Would you ideally give your
> > Tested-by?
> 
> Looks good to me and also does not seem to break anything on my test
> devices, so:
> 
> Acked-and-Tested-by: Hans de Goede <hdegoede@redhat.com>

Thanks!

Linus, I'm fully satisfied :-)

> 
> Regards,
> 
> Hans
> 
> 
> > 
> > > 
> > > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > > ---
> > >  drivers/gpio/gpiolib-acpi.c | 4 +++-
> > >  1 file changed, 3 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpio/gpiolib-acpi.c b/drivers/gpio/gpiolib-
> > > acpi.c
> > > index a3faefa44f68..d3f9f028a37b 100644
> > > --- a/drivers/gpio/gpiolib-acpi.c
> > > +++ b/drivers/gpio/gpiolib-acpi.c
> > > @@ -572,8 +572,10 @@ struct gpio_desc *acpi_find_gpio(struct
> > > device
> > > *dev,
> > >  		}
> > > 
> > >  		desc = acpi_get_gpiod_by_index(adev, propname,
> > > idx,
> > > &info);
> > > -		if (!IS_ERR(desc) || (PTR_ERR(desc) ==
> > > -EPROBE_DEFER))
> > > +		if (!IS_ERR(desc))
> > >  			break;
> > > +		if (PTR_ERR(desc) == -EPROBE_DEFER)
> > > +			return ERR_CAST(desc);
> > >  	}
> > > 
> > >  	/* Then from plain _CRS GPIOs */
> > > --
> > > 2.12.1.500.gab5fba24ee-goog
> > > 
> > >
Linus Walleij March 30, 2017, 9:08 a.m. UTC | #7
On Thu, Mar 23, 2017 at 9:21 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:

> If, while locating GPIOs by name, we get probe deferral, we should
> immediately report it to caller rather than trying to fall back to parsing
> unnamed GPIOs from _CRS block.
>
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Patch applied and tagged for stable with all ACKs and Tested-by's.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch
diff mbox

diff --git a/drivers/gpio/gpiolib-acpi.c b/drivers/gpio/gpiolib-acpi.c
index a3faefa44f68..d3f9f028a37b 100644
--- a/drivers/gpio/gpiolib-acpi.c
+++ b/drivers/gpio/gpiolib-acpi.c
@@ -572,8 +572,10 @@  struct gpio_desc *acpi_find_gpio(struct device *dev,
 		}
 
 		desc = acpi_get_gpiod_by_index(adev, propname, idx, &info);
-		if (!IS_ERR(desc) || (PTR_ERR(desc) == -EPROBE_DEFER))
+		if (!IS_ERR(desc))
 			break;
+		if (PTR_ERR(desc) == -EPROBE_DEFER)
+			return ERR_CAST(desc);
 	}
 
 	/* Then from plain _CRS GPIOs */