[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <55fdfd83-dc4f-36e9-b8a7-96ad4881a2ce@cmss.chinamobile.com>
Date: Fri, 10 Apr 2020 10:52:50 +0800
From: Tang Bin <tangbin@...s.chinamobile.com>
To: Dmitry Torokhov <dmitry.torokhov@...il.com>,
Markus Elfring <Markus.Elfring@....de>
Cc: linux-input@...r.kernel.org, Allison Randal <allison@...utok.net>,
Arnd Bergmann <arnd@...db.de>,
H Hartley Sweeten <hsweeten@...ionengravers.com>,
Olof Johansson <olof@...om.net>,
Thomas Gleixner <tglx@...utronix.de>,
LKML <linux-kernel@...r.kernel.org>,
kernel-janitors@...r.kernel.org
Subject: Re: Input: ep93xx_keypad: Checking for a failed
platform_get_irq()call in ep93xx_keypad_probe()
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
>
Powered by blists - more mailing lists