* [PATCH] Input: wm97xx - use EBUSY instead of EINVAL
@ 2009-06-03 5:45 Joonyoung Shim
2009-06-03 10:01 ` Mark Brown
0 siblings, 1 reply; 6+ messages in thread
From: Joonyoung Shim @ 2009-06-03 5:45 UTC (permalink / raw)
To: linux-input; +Cc: dmitry.torokhov, broonie
If request_irq() fails, we have to return -EBUSY instead of -EINVAL.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
---
drivers/input/touchscreen/wm97xx-core.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/input/touchscreen/wm97xx-core.c b/drivers/input/touchscreen/wm97xx-core.c
index 2957d48..06cc8cf 100644
--- a/drivers/input/touchscreen/wm97xx-core.c
+++ b/drivers/input/touchscreen/wm97xx-core.c
@@ -375,7 +375,7 @@ static int wm97xx_init_pen_irq(struct wm97xx *wm)
dev_err(wm->dev,
"Failed to register pen down interrupt, polling");
wm->pen_irq = 0;
- return -EINVAL;
+ return -EBUSY;
}
/* Configure GPIO as interrupt source on WM971x */
--
1.6.0.4
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] Input: wm97xx - use EBUSY instead of EINVAL
2009-06-03 5:45 [PATCH] Input: wm97xx - use EBUSY instead of EINVAL Joonyoung Shim
@ 2009-06-03 10:01 ` Mark Brown
2009-06-03 14:19 ` Dmitry Torokhov
2009-06-04 1:26 ` Joonyoung Shim
0 siblings, 2 replies; 6+ messages in thread
From: Mark Brown @ 2009-06-03 10:01 UTC (permalink / raw)
To: Joonyoung Shim; +Cc: linux-input, dmitry.torokhov
On Wed, Jun 03, 2009 at 02:45:15PM +0900, Joonyoung Shim wrote:
> If request_irq() fails, we have to return -EBUSY instead of -EINVAL.
Could you provide a bit more explanation for this one, please? -EBUSY
seems to give entirely the wrong impression to applications since in the
systems where this driver will be deployed a failure to acquire the IRQ
is most likely to be due to incorrect platform data and it is highly
unlikely to resolve itself.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] Input: wm97xx - use EBUSY instead of EINVAL
2009-06-03 10:01 ` Mark Brown
@ 2009-06-03 14:19 ` Dmitry Torokhov
2009-06-03 14:40 ` Mark Brown
2009-06-04 1:26 ` Joonyoung Shim
1 sibling, 1 reply; 6+ messages in thread
From: Dmitry Torokhov @ 2009-06-03 14:19 UTC (permalink / raw)
To: Mark Brown; +Cc: Joonyoung Shim, linux-input
On Wed, Jun 03, 2009 at 11:01:21AM +0100, Mark Brown wrote:
> On Wed, Jun 03, 2009 at 02:45:15PM +0900, Joonyoung Shim wrote:
> > If request_irq() fails, we have to return -EBUSY instead of -EINVAL.
>
> Could you provide a bit more explanation for this one, please? -EBUSY
> seems to give entirely the wrong impression to applications since in the
> systems where this driver will be deployed a failure to acquire the IRQ
> is most likely to be due to incorrect platform data and it is highly
> unlikely to resolve itself.
The "most correct" thing would be to propagate the value returned by
request_irq() I think but since nobidy actually uses result of
wm97xx_init_pen_irq() I just would not bother at all.
--
Dmitry
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] Input: wm97xx - use EBUSY instead of EINVAL
2009-06-03 14:19 ` Dmitry Torokhov
@ 2009-06-03 14:40 ` Mark Brown
2009-06-03 14:48 ` Dmitry Torokhov
0 siblings, 1 reply; 6+ messages in thread
From: Mark Brown @ 2009-06-03 14:40 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Joonyoung Shim, linux-input
On Wed, Jun 03, 2009 at 07:19:14AM -0700, Dmitry Torokhov wrote:
> The "most correct" thing would be to propagate the value returned by
> request_irq() I think but since nobidy actually uses result of
> wm97xx_init_pen_irq() I just would not bother at all.
Yeah, I was looking at that - the driver can run in polling mode so it's
fine as-is. I could change the code to return void, I suppose.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] Input: wm97xx - use EBUSY instead of EINVAL
2009-06-03 14:40 ` Mark Brown
@ 2009-06-03 14:48 ` Dmitry Torokhov
0 siblings, 0 replies; 6+ messages in thread
From: Dmitry Torokhov @ 2009-06-03 14:48 UTC (permalink / raw)
To: Mark Brown; +Cc: Joonyoung Shim, linux-input
On Wednesday 03 June 2009 07:40:24 Mark Brown wrote:
> On Wed, Jun 03, 2009 at 07:19:14AM -0700, Dmitry Torokhov wrote:
> > The "most correct" thing would be to propagate the value returned by
> > request_irq() I think but since nobidy actually uses result of
> > wm97xx_init_pen_irq() I just would not bother at all.
>
> Yeah, I was looking at that - the driver can run in polling mode so it's
> fine as-is. I could change the code to return void, I suppose.
Yes, I think that would be the best.
--
Dmitry
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] Input: wm97xx - use EBUSY instead of EINVAL
2009-06-03 10:01 ` Mark Brown
2009-06-03 14:19 ` Dmitry Torokhov
@ 2009-06-04 1:26 ` Joonyoung Shim
1 sibling, 0 replies; 6+ messages in thread
From: Joonyoung Shim @ 2009-06-04 1:26 UTC (permalink / raw)
To: Mark Brown; +Cc: linux-input, dmitry.torokhov
On 6/3/2009 7:01 PM, Mark Brown wrote:
> On Wed, Jun 03, 2009 at 02:45:15PM +0900, Joonyoung Shim wrote:
>> If request_irq() fails, we have to return -EBUSY instead of -EINVAL.
>
> Could you provide a bit more explanation for this one, please? -EBUSY
> seems to give entirely the wrong impression to applications since in the
> systems where this driver will be deployed a failure to acquire the IRQ
> is most likely to be due to incorrect platform data and it is highly
> unlikely to resolve itself.
-EBUSY is used in many touchscreen drivers currently, but i agree dmitry
opinion to propagate what request_irq() returned because request_irq() can
return different errnos.
Thanks.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2009-06-04 1:26 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-06-03 5:45 [PATCH] Input: wm97xx - use EBUSY instead of EINVAL Joonyoung Shim
2009-06-03 10:01 ` Mark Brown
2009-06-03 14:19 ` Dmitry Torokhov
2009-06-03 14:40 ` Mark Brown
2009-06-03 14:48 ` Dmitry Torokhov
2009-06-04 1:26 ` Joonyoung Shim
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).