# Re: \[PATCH\] input: replace request\_irq by request\_any\_context\_irq in keyboard GPIO driver

- From: Trilok Soni \<hidden\>
- Date: 2011-01-20 08:56:43 
- List: linux-input
- Page: https://ratatoskr.run/linux-input/2011/01/8915892
- Thread: https://ratatoskr.run/linux-input/2011/01/8915845/t.md

```text
Hi Dmitry,

On 1/20/2011 1:43 PM, Dmitry Torokhov wrote:
>>>
>>> No, this it not correct. request_any_context_irq() means that you could
>>> either get a hardirq or a treaded one. However above you are changing to
>>> gpio_get_value_cansleep() which indicates that you can sleep.
>>>
>>> You need to either revert to gpio_get_value() or explicitly request
>>> threaded IRQ.
>>
>> This could be problem. Say, we are doing request_any_context_irq(..) and gpio is over slow-bus,
>> so we naturally get into the threaded code, and in the thread handler we are calling gpio_get_value(..),
>> but in this case gpio_get_value could throw a warning that we should call gpio_get_value_cansleep(...)
>> because sleep attribute is added into the gpiolib hook implementation for these gpios.
>>
>> Now suppose gpio is memory mapped and we enter into the hardirq and calling sleep variant into the 
>> handler code will be naturally bad. 
>>
>> How about checking maysleep explicitly here while using the request_any_context_irq() call though
>> the semantics of gpiolib framework discourages that. 
>>
> 
> Any drawbacks for explicitly switching to threaded IRQ and keeping
> gpio_get_value_cansleep()? (That was the 2nd option I mentioned BTW).
> 

Only drawback is that you get "dedicated thread" in case the irqs are not chained handler. In worst-case
it would introduce the latencies otherwise fine.

---Trilok Soni

-- 
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
```