Input: ep93xx_keypad: Checking for a failed platform_get_irq() call in ep93xx_keypad_probe()

Input: ep93xx_keypad: Checking for a failed platform_get_irq() call in ep93xx_keypad_probe()

[Markus Elfring]

Hello,

I have taken another look at the implementation of the function “ep93xx_keypad_probe”.
A software analysis approach points the following source code out for
further development considerations.
https://elixir.bootlin.com/linux/v5.6.3/source/drivers/input/keyboard/ep93xx_keypad.c#L252
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/input/keyboard/ep93xx_keypad.c?id=f5e94d10e4c468357019e5c28d48499f677b284f#n252

 	keypad->irq = platform_get_irq(pdev, 0);
 	if (!keypad->irq) {
 		err = -ENXIO;
 		goto failed_free;
 	}


The software documentation is providing the following information
for the used programming interface.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/base/platform.c?id=f5e94d10e4c468357019e5c28d48499f677b284f#n221
https://elixir.bootlin.com/linux/v5.6.3/source/drivers/base/platform.c#L202

“…
 * Return: IRQ number on success, negative error number on failure.
…”

Would you like to reconsider the shown condition check?

Regards,
Markus

Re: Input: ep93xx_keypad: Checking for a failed platform_get_irq() call in ep93xx_keypad_probe()

[Dmitry Torokhov]

Hi Markus,

On Wed, Apr 08, 2020 at 06:52:31PM +0200, Markus Elfring wrote:
> Hello,
> 
> I have taken another look at the implementation of the function “ep93xx_keypad_probe”.
> A software analysis approach points the following source code out for
> further development considerations.
> https://elixir.bootlin.com/linux/v5.6.3/source/drivers/input/keyboard/ep93xx_keypad.c#L252
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/input/keyboard/ep93xx_keypad.c?id=f5e94d10e4c468357019e5c28d48499f677b284f#n252
> 
>  	keypad->irq = platform_get_irq(pdev, 0);
>  	if (!keypad->irq) {
>  		err = -ENXIO;
>  		goto failed_free;
>  	}
> 
> 
> The software documentation is providing the following information
> for the used programming interface.
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/base/platform.c?id=f5e94d10e4c468357019e5c28d48499f677b284f#n221
> https://elixir.bootlin.com/linux/v5.6.3/source/drivers/base/platform.c#L202
> 
> “…
>  * Return: IRQ number on success, negative error number on failure.
> …”
> 
> Would you like to reconsider the shown condition check?

Platform code historically allowed creating IRQ resources with IRQ
number 0 to indicate "no interrupt assigned", so this driver tries to
filter out such conditions. The negative IRQs (errors) will be rejected
by request_irq() but I guess we can lose -EPROBE_DEFER. We could do

	if (keypad->irq <= 0) {
		err = keypad->irq ?: -ENXIO : keypad->irq;
		goto failed_free;
	}


or, maybe we should take a look at platform_get_irq() and see if we can
stop it returning 0 interrupt numbers and clean up the drivers.

Thanks.

-- 
Dmitry

Re: Input: ep93xx_keypad: Checking for a failed platform_get_irq()call in ep93xx_keypad_probe()

[Tang Bin]

Hi Dmitry:

On 2020/4/10 4:48, Dmitry Torokhov wrote:
> Platform code historically allowed creating IRQ resources with IRQ
> number 0 to indicate "no interrupt assigned", so this driver tries to
> filter out such conditions. The negative IRQs (errors) will be rejected
> by request_irq() but I guess we can lose -EPROBE_DEFER. We could do
>
> 	if (keypad->irq <= 0) {
> 		err = keypad->irq ?: -ENXIO : keypad->irq;
> 		goto failed_free;
> 	}
>
>
I have been aware of this problem for a few days, and by doing 
experiments on the hardware, I have found the following ways that maybe 
suitable：

     if (keypad->irq <= 0) {
         err = keypad->irq ? : -ENXIO;
         goto failed_free;
     }
     or
     if (keypad->irq <= 0) {
         err = keypad->irq < 0 ? keypad->irq : -ENXIO;
         goto failed_free;
     }

If you think it's usefull, I will send this patch to fix it.

Thanks

Tang Bin


>

Re: Input: ep93xx_keypad: Checking for a failed platform_get_irq()call in ep93xx_keypad_probe()

[Tang Bin]

Hi Dmitry:

On 2020/4/10 4:48, Dmitry Torokhov wrote:
> Platform code historically allowed creating IRQ resources with IRQ
> number 0 to indicate "no interrupt assigned", so this driver tries to
> filter out such conditions. The negative IRQs (errors) will be rejected
> by request_irq() but I guess we can lose -EPROBE_DEFER. We could do
>
> 	if (keypad->irq <= 0) {
> 		err = keypad->irq ?: -ENXIO : keypad->irq;
> 		goto failed_free;
> 	}

I have been aware of this problem for several days, and by doing 
experiments on the hardware, I have found the following ways that maybe 
suitable：

     if (keypad->irq <= 0) {
         err = keypad->irq ? : -ENXIO;
         goto failed_free;
     }
     or
     if (keypad->irq <= 0) {
         err = keypad->irq < 0 ? keypad->irq : -ENXIO;
         goto failed_free;
     }

If you think it's usefull, I will send this patch to fix this problem.

Thanks

Tang Bin

Re: Input: ep93xx_keypad: Checking for a failed platform_get_irq() call in ep93xx_keypad_probe()

[Markus Elfring]

> Platform code historically allowed creating IRQ resources with IRQ
> number 0 to indicate "no interrupt assigned", so this driver tries to
> filter out such conditions. The negative IRQs (errors) will be rejected
> by request_irq() but I guess we can lose -EPROBE_DEFER.

Thanks for this explanation.

* Should such information be better represented in the description for
  these programming interfaces?

* Can the software documentation become clearer anyhow?


> or, maybe we should take a look at platform_get_irq() and see if we can
> stop it returning 0 interrupt numbers and clean up the drivers.

Will further collateral evolution become interesting?

Regards,
Markus