Commit daaef255dc96 ("driver: platform: Support parsing GpioInt 0 in
platform_get_irq()") broke the Embedded Controller driver on most LPC
Chromebooks (i.e., most x86 Chromebooks), because cros_ec_lpc expects
platform_get_irq() to return -ENXIO for non-existent IRQs.
Unfortunately, acpi_dev_gpio_irq_get() doesn't follow this convention
and returns -ENOENT instead. So we get this error from cros_ec_lpc:
couldn't retrieve IRQ number (-2)
I see a variety of drivers that treat -ENXIO specially, so rather than
fix all of them, let's fix up the API to restore its previous behavior.
I reported this on v2 of this patch:
https://lore.kernel.org/lkml/[email protected]/
but apparently the patch had already been merged before v3 got sent out:
https://lore.kernel.org/lkml/[email protected]/
and the result is that the bug landed and remains unfixed.
I differ from the v3 patch by:
* allowing for ret==0, even though acpi_dev_gpio_irq_get() specifically
documents (and enforces) that 0 is not a valid return value (noted on
the v3 review)
* adding a small comment
Reported-by: Brian Norris <[email protected]>
Reported-by: Salvatore Bellizzi <[email protected]>
Cc: Enrico Granata <[email protected]>
Cc: <[email protected]>
Fixes: daaef255dc96 ("driver: platform: Support parsing GpioInt 0 in platform_get_irq()")
Signed-off-by: Brian Norris <[email protected]>
---
Side note: it might have helped alleviate some of this pain if there
were email notifications to the mailing list when a patch gets applied.
I didn't realize (and I'm not sure if Enrico did) that v2 was already
merged by the time I noted its mistakes. If I had known, I would have
suggested a follow-up patch, not a v3.
I know some maintainers' "tip bots" do this, but not all apparently.
drivers/base/platform.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 506a0175a5a7..ec974ba9c0c4 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -157,8 +157,13 @@ int platform_get_irq(struct platform_device *dev, unsigned int num)
* the device will only expose one IRQ, and this fallback
* allows a common code path across either kind of resource.
*/
- if (num == 0 && has_acpi_companion(&dev->dev))
- return acpi_dev_gpio_irq_get(ACPI_COMPANION(&dev->dev), num);
+ if (num == 0 && has_acpi_companion(&dev->dev)) {
+ int ret = acpi_dev_gpio_irq_get(ACPI_COMPANION(&dev->dev), num);
+
+ /* Our callers expect -ENXIO for missing IRQs. */
+ if (ret >= 0 || ret == -EPROBE_DEFER)
+ return ret;
+ }
return -ENXIO;
#endif
--
2.22.0.709.g102302147b-goog
On Mon, Jul 29, 2019 at 1:50 PM Brian Norris <[email protected]> wrote:
>
> Commit daaef255dc96 ("driver: platform: Support parsing GpioInt 0 in
> platform_get_irq()") broke the Embedded Controller driver on most LPC
> Chromebooks (i.e., most x86 Chromebooks), because cros_ec_lpc expects
> platform_get_irq() to return -ENXIO for non-existent IRQs.
> Unfortunately, acpi_dev_gpio_irq_get() doesn't follow this convention
> and returns -ENOENT instead. So we get this error from cros_ec_lpc:
>
> couldn't retrieve IRQ number (-2)
>
> I see a variety of drivers that treat -ENXIO specially, so rather than
> fix all of them, let's fix up the API to restore its previous behavior.
>
> I reported this on v2 of this patch:
>
> https://lore.kernel.org/lkml/[email protected]/
>
> but apparently the patch had already been merged before v3 got sent out:
>
> https://lore.kernel.org/lkml/[email protected]/
>
> and the result is that the bug landed and remains unfixed.
>
> I differ from the v3 patch by:
> * allowing for ret==0, even though acpi_dev_gpio_irq_get() specifically
> documents (and enforces) that 0 is not a valid return value (noted on
> the v3 review)
> * adding a small comment
>
> Reported-by: Brian Norris <[email protected]>
> Reported-by: Salvatore Bellizzi <[email protected]>
> Cc: Enrico Granata <[email protected]>
> Cc: <[email protected]>
> Fixes: daaef255dc96 ("driver: platform: Support parsing GpioInt 0 in platform_get_irq()")
> Signed-off-by: Brian Norris <[email protected]>
> ---
> Side note: it might have helped alleviate some of this pain if there
> were email notifications to the mailing list when a patch gets applied.
> I didn't realize (and I'm not sure if Enrico did) that v2 was already
> merged by the time I noted its mistakes. If I had known, I would have
> suggested a follow-up patch, not a v3.
>
> I know some maintainers' "tip bots" do this, but not all apparently.
>
> drivers/base/platform.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index 506a0175a5a7..ec974ba9c0c4 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -157,8 +157,13 @@ int platform_get_irq(struct platform_device *dev, unsigned int num)
> * the device will only expose one IRQ, and this fallback
> * allows a common code path across either kind of resource.
> */
> - if (num == 0 && has_acpi_companion(&dev->dev))
> - return acpi_dev_gpio_irq_get(ACPI_COMPANION(&dev->dev), num);
> + if (num == 0 && has_acpi_companion(&dev->dev)) {
> + int ret = acpi_dev_gpio_irq_get(ACPI_COMPANION(&dev->dev), num);
> +
> + /* Our callers expect -ENXIO for missing IRQs. */
> + if (ret >= 0 || ret == -EPROBE_DEFER)
> + return ret;
> + }
>
> return -ENXIO;
> #endif
> --
> 2.22.0.709.g102302147b-goog
>
Acked-by: Enrico Granata <[email protected]>
On Mon, Jul 29, 2019 at 01:49:54PM -0700, Brian Norris wrote:
> Commit daaef255dc96 ("driver: platform: Support parsing GpioInt 0 in
> platform_get_irq()") broke the Embedded Controller driver on most LPC
> Chromebooks (i.e., most x86 Chromebooks), because cros_ec_lpc expects
> platform_get_irq() to return -ENXIO for non-existent IRQs.
> Unfortunately, acpi_dev_gpio_irq_get() doesn't follow this convention
> and returns -ENOENT instead. So we get this error from cros_ec_lpc:
>
> couldn't retrieve IRQ number (-2)
>
> I see a variety of drivers that treat -ENXIO specially, so rather than
> fix all of them, let's fix up the API to restore its previous behavior.
>
> I reported this on v2 of this patch:
>
> https://lore.kernel.org/lkml/[email protected]/
>
> but apparently the patch had already been merged before v3 got sent out:
>
> https://lore.kernel.org/lkml/[email protected]/
>
> and the result is that the bug landed and remains unfixed.
>
> I differ from the v3 patch by:
> * allowing for ret==0, even though acpi_dev_gpio_irq_get() specifically
> documents (and enforces) that 0 is not a valid return value (noted on
> the v3 review)
> * adding a small comment
Thank you for fixing this.
Reviewed-by: Andy Shevchenko <[email protected]>
>
> Reported-by: Brian Norris <[email protected]>
> Reported-by: Salvatore Bellizzi <[email protected]>
> Cc: Enrico Granata <[email protected]>
> Cc: <[email protected]>
> Fixes: daaef255dc96 ("driver: platform: Support parsing GpioInt 0 in platform_get_irq()")
> Signed-off-by: Brian Norris <[email protected]>
> ---
> Side note: it might have helped alleviate some of this pain if there
> were email notifications to the mailing list when a patch gets applied.
> I didn't realize (and I'm not sure if Enrico did) that v2 was already
> merged by the time I noted its mistakes. If I had known, I would have
> suggested a follow-up patch, not a v3.
>
> I know some maintainers' "tip bots" do this, but not all apparently.
>
> drivers/base/platform.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index 506a0175a5a7..ec974ba9c0c4 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -157,8 +157,13 @@ int platform_get_irq(struct platform_device *dev, unsigned int num)
> * the device will only expose one IRQ, and this fallback
> * allows a common code path across either kind of resource.
> */
> - if (num == 0 && has_acpi_companion(&dev->dev))
> - return acpi_dev_gpio_irq_get(ACPI_COMPANION(&dev->dev), num);
> + if (num == 0 && has_acpi_companion(&dev->dev)) {
> + int ret = acpi_dev_gpio_irq_get(ACPI_COMPANION(&dev->dev), num);
> +
> + /* Our callers expect -ENXIO for missing IRQs. */
> + if (ret >= 0 || ret == -EPROBE_DEFER)
> + return ret;
> + }
>
> return -ENXIO;
> #endif
> --
> 2.22.0.709.g102302147b-goog
>
--
With Best Regards,
Andy Shevchenko
On Mon, Jul 29, 2019 at 01:49:54PM -0700, Brian Norris wrote:
> Commit daaef255dc96 ("driver: platform: Support parsing GpioInt 0 in
> platform_get_irq()") broke the Embedded Controller driver on most LPC
> Chromebooks (i.e., most x86 Chromebooks), because cros_ec_lpc expects
> platform_get_irq() to return -ENXIO for non-existent IRQs.
> Unfortunately, acpi_dev_gpio_irq_get() doesn't follow this convention
> and returns -ENOENT instead. So we get this error from cros_ec_lpc:
>
> couldn't retrieve IRQ number (-2)
>
> I see a variety of drivers that treat -ENXIO specially, so rather than
> fix all of them, let's fix up the API to restore its previous behavior.
>
> I reported this on v2 of this patch:
>
> https://lore.kernel.org/lkml/[email protected]/
>
> but apparently the patch had already been merged before v3 got sent out:
>
> https://lore.kernel.org/lkml/[email protected]/
>
> and the result is that the bug landed and remains unfixed.
>
> I differ from the v3 patch by:
> * allowing for ret==0, even though acpi_dev_gpio_irq_get() specifically
> documents (and enforces) that 0 is not a valid return value (noted on
> the v3 review)
> * adding a small comment
>
> Reported-by: Brian Norris <[email protected]>
> Reported-by: Salvatore Bellizzi <[email protected]>
> Cc: Enrico Granata <[email protected]>
> Cc: <[email protected]>
> Fixes: daaef255dc96 ("driver: platform: Support parsing GpioInt 0 in platform_get_irq()")
> Signed-off-by: Brian Norris <[email protected]>
> Reviewed-by: Andy Shevchenko <[email protected]>
> Acked-by: Enrico Granata <[email protected]>
> ---
> Side note: it might have helped alleviate some of this pain if there
> were email notifications to the mailing list when a patch gets applied.
> I didn't realize (and I'm not sure if Enrico did) that v2 was already
> merged by the time I noted its mistakes. If I had known, I would have
> suggested a follow-up patch, not a v3.
>
> I know some maintainers' "tip bots" do this, but not all apparently.
We can't drown out mailing list traffic with a ton of "this patch was
applied" emails. We send them directly to the people involved in it.
Note, you can always set up your own "watch" for stuff like this by
pulling linux-next every day and sending yourself any new patches that
get applied for any specific files/directories you are concerned about.
thanks,
greg k-h
On Mon, Jul 29, 2019 at 1:50 PM Brian Norris <[email protected]> wrote:
> Side note: it might have helped alleviate some of this pain if there
> were email notifications to the mailing list when a patch gets applied.
> I didn't realize (and I'm not sure if Enrico did) that v2 was already
> merged by the time I noted its mistakes. If I had known, I would have
> suggested a follow-up patch, not a v3.
I guess I'll be the bot this time: 'twas applied by Greg on Tuesday,
July 30 UTC-07:00.
Thanks,
Brian