[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <279dd87a-bbc4-685d-b557-7914e4132b15@web.de>
Date: Fri, 10 Apr 2020 07:45:40 +0200
From: Markus Elfring <Markus.Elfring@....de>
To: Dmitry Torokhov <dmitry.torokhov@...il.com>,
linux-input@...r.kernel.org
Cc: 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>,
Tang Bin <tangbin@...s.chinamobile.com>,
LKML <linux-kernel@...r.kernel.org>,
kernel-janitors@...r.kernel.org, linux-doc@...r.kernel.org
Subject: Re: Input: ep93xx_keypad: Checking for a failed platform_get_irq()
call in ep93xx_keypad_probe()
> 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
Powered by blists - more mailing lists