[PATCH] gpio: pxa: propagate pxa_gpio_probe_dt() error code

[PATCH] gpio: pxa: propagate pxa_gpio_probe_dt() error code

[Haotian Zhang]

pxa_gpio_probe_dt() returns the negative errno produced by
devm_irq_alloc_descs(), which may be -ENOMEM, -EINVAL or -EEXIST. The
caller in pxa_gpio_probe() overwrites that value with a fixed -EINVAL, so
the actual reason for the failure is lost.

Return irq_base so that the original error code is propagated.

Fixes: 384ca3c6a28d ("gpio: pxa: change the interrupt management")
Assisted-by: DeepSeek-V4.1-Flash
Signed-off-by: Haotian Zhang <vulab@iscas.ac.cn>
---
 drivers/gpio/gpio-pxa.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-pxa.c b/drivers/gpio/gpio-pxa.c
index 2b5da973f51f..ef3f21723b09 100644
--- a/drivers/gpio/gpio-pxa.c
+++ b/drivers/gpio/gpio-pxa.c
@@ -632,7 +632,7 @@ static int pxa_gpio_probe(struct platform_device *pdev)
 	} else {
 		irq_base = pxa_gpio_probe_dt(pdev, pchip);
 		if (irq_base < 0)
-			return -EINVAL;
+			return irq_base;
 	}
 
 	if (!pxa_last_gpio)
-- 
2.25.1

Re: [PATCH] gpio: pxa: propagate pxa_gpio_probe_dt() error code

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] gpio: pxa: probe returns -EPERM (-1) when CONFIG_OF is disabled
--

commit e354788ab87bb0e86721190d9d799a35572742ca
Author: Haotian Zhang <vulab@iscas.ac.cn>

gpio: pxa: propagate pxa_gpio_probe_dt() error code

pxa_gpio_probe_dt() returns the negative errno produced by
devm_irq_alloc_descs(), which may be -ENOMEM, -EINVAL or -EEXIST. The
caller in pxa_gpio_probe() overwrites that value with a fixed -EINVAL, so
the actual reason for the failure is lost. Return irq_base so that the
original error code is propagated.

> diff --git a/drivers/gpio/gpio-pxa.c b/drivers/gpio/gpio-pxa.c
> index 3ff21e8992788..7d513932d09f0 100644
> --- a/drivers/gpio/gpio-pxa.c
> +++ b/drivers/gpio/gpio-pxa.c
> @@ -632,7 +632,7 @@ static int pxa_gpio_probe(struct platform_device *pdev)
>  	} else {
>  		irq_base = pxa_gpio_probe_dt(pdev, pchip);
>  		if (irq_base < 0)
> -			return -EINVAL;
> +			return irq_base;

[Severity: Low]
Does this unintentionally return -EPERM when CONFIG_OF is disabled?

When CONFIG_OF is not enabled, pxa_gpio_probe_dt() is defined as a stub that
returns -1:

#else
#define pxa_gpio_probe_dt(pdev, pchip)		(-1)
#endif

With this patch, pxa_gpio_probe() will now directly propagate that -1, which
translates to -EPERM. This seems like a misleading error code for missing
platform data or device tree configuration compared to the previous -EINVAL.

>  	}
>  
>  	if (!pxa_last_gpio)

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261009050604.3128124-1-vulab@iscas.ac.cn?part=1

Re: [PATCH] gpio: pxa: propagate pxa_gpio_probe_dt() error code

[Krzysztof Kozlowski]

On Fri, 09 Oct 2026 13:06:04 +0800, Haotian Zhang wrote:
> pxa_gpio_probe_dt() returns the negative errno produced by
> devm_irq_alloc_descs(), which may be -ENOMEM, -EINVAL or -EEXIST. The
> caller in pxa_gpio_probe() overwrites that value with a fixed -EINVAL, so
> the actual reason for the failure is lost.
> 
> Return irq_base so that the original error code is propagated.
> 
> Fixes: 384ca3c6a28d ("gpio: pxa: change the interrupt management")
> Assisted-by: DeepSeek-V4.1-Flash
> Signed-off-by: Haotian Zhang <vulab@iscas.ac.cn>
> ---
>  drivers/gpio/gpio-pxa.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 



Multiple things here:
1. Your team ignored completely previous feedback.

2. You use multiple identities with this email, thus I actually doubt we speak
   with actual person.

3. Finally, same feedback:
You sent multiple independent patches, to multiple independent
subsystems. The amount of these patches clearly suggest this was
AI generated and most likely not tested.

More importantly, you sent all this work without properly organizing
relevant patches into patchsets. This makes reviewing difficult
and might cause multiple reviewers to address the same issue.
Replying to the entire set is impossible and requires handling each
patch independently, instead of applying or discarding the set.
Maintainers also won't see the bigger picture of your work. Quite
worrying.

This is on the verge of hostile patch: bomb us with so many
contributions, we won't be able to handle them in efficient manner,
like responding ONCE to ask you to slow down.  Considering all this
is untested and LLM generated, I have even more doubts whether this
should be considered for review.

Please read kernel documentation BEFORE posting more work. It will
explain you how to identify subsystems, how to organize your work per
subsystem (so a patchset grouping multiple patches with a short cover
letter), how to document usage of LLM and how what you should not do
if this was posted in a good faith.

Best regards,
Krzysztof