| Message ID | 20230428102015.810686-1-tomas.mudrunka@gmail.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [v4] Fix freeze in lm8333 i2c keyboard driver | expand |
Hi Tomas, On Fri, Apr 28, 2023 at 12:20:15PM +0200, Tomas Mudrunka wrote: > LM8333 uses gpio interrupt line which is triggered by falling edge. > When button is pressed before driver is loaded, > driver will miss the edge and never respond again. > To fix this we run the interrupt handler after registering IRQ > to clear the interrupt via i2c command. > > Signed-off-by: Tomas Mudrunka <tomas.mudrunka@gmail.com> > --- > drivers/input/keyboard/lm8333.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/input/keyboard/lm8333.c b/drivers/input/keyboard/lm8333.c > index 7457c3220..9a810ca00 100644 > --- a/drivers/input/keyboard/lm8333.c > +++ b/drivers/input/keyboard/lm8333.c > @@ -184,6 +184,8 @@ static int lm8333_probe(struct i2c_client *client) > if (err) > goto free_mem; > > + lm8333_irq_thread(client->irq, lm8333); Just to clarify, my stance is that this call should go _before_ the handler is registered. Your earlier statement that doing so would steal any pending status from the handler is correct; however, it is a moot point because the handler cannot do anything with that status until the input device has been registered anyway. Any events that come before then are off the table, and this is OK because user space isn't going to start consuming key events until well after this driver has probed anyway. The reason behind my assertion is that as a matter of best practice, you should not have two asynchronous threads that can in theory access the same register. You are correct that the handler would simply return IRQ_NONE in such a race, but it sets a bad precedent and opens room for bugs in case this driver is modified in the future. It also creates one unnecessary I2C read. This is why it is much more common to register the handler _after_ manually accessing read-to-clear registers; the register access remains synchronous. In case you feel I have misunderstood, please let me know. > + > err = input_register_device(input); > if (err) > goto free_irq; > -- > 2.40.0 Kind regards, Jeff LaBundy
> Just to clarify, my stance is that this call should go _before_ the handler > is registered. Ok, i will fix the patch later today. > Any events that come before then are off the table, and this is OK because > user space isn't going to start consuming key events until well after this > driver has probed anyway. Well, that was never my point. I don't care about capturing events that happen before driver was properly loaded. My only concern was to limit possibility of deadlock which happened previously. Because that makes device unusable till the IC is power cycled. Which might be especially annoying on devices that have power button implemented using this exact IC :-) > The reason behind my assertion is that as a matter of best practice, you > should not have two asynchronous threads that can in theory access the same > register. Yeah, this makes bit more sense now. Didn't realized IRQ might interrupt that lm8333_irq_thread() call immediately. While not very likely to cause problems like deadlock of the driver, i think it's a valid point. After all this is what happens with IRQF_ONESHOT anyway right? Each time the IRQ is triggered it's disabled, lm8333_irq_thread() is run and then it's enabled immediately after that. So i guess the behaviour on each keypress is very similar to calling lm8333_irq_thread() before registering the IRQ handler, which gives me some confidence there might not be huge chance for deadlock under normal circumstances. Though i wonder what would happen if some EMI burst would create rapid train of randomly timed keypresses, that might just hit the unfortunate sweetspot after while... Might test that later in the lab, since i really need the software to remain operational after such condition had passed.
diff --git a/drivers/input/keyboard/lm8333.c b/drivers/input/keyboard/lm8333.c index 7457c3220..9a810ca00 100644 --- a/drivers/input/keyboard/lm8333.c +++ b/drivers/input/keyboard/lm8333.c @@ -184,6 +184,8 @@ static int lm8333_probe(struct i2c_client *client) if (err) goto free_mem; + lm8333_irq_thread(client->irq, lm8333); + err = input_register_device(input); if (err) goto free_irq;
LM8333 uses gpio interrupt line which is triggered by falling edge. When button is pressed before driver is loaded, driver will miss the edge and never respond again. To fix this we run the interrupt handler after registering IRQ to clear the interrupt via i2c command. Signed-off-by: Tomas Mudrunka <tomas.mudrunka@gmail.com> --- drivers/input/keyboard/lm8333.c | 2 ++ 1 file changed, 2 insertions(+)