Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230425130054.591007-1-tomas.mudrunka@gmail.com>
 <ZEf0RYdD5jhE9JEk@nixie71> <ZEmwsViIjUVPZ4Cd@google.com> <ZEnBZs9VYxriT1Or@nixie71>
In-Reply-To: <ZEnBZs9VYxriT1Or@nixie71>
From:   =?UTF-8?B?VG9tw6HFoSBNdWRydcWIa2E=?= <tomas.mudrunka@gmail.com>
Date:   Thu, 27 Apr 2023 10:19:38 +0200
Message-ID: <CAH2-hcJa_vL9iWTARUAD+adrvQAjzr1N4bQ=cN+8kbE0arVwZw@mail.gmail.com>
Subject: Re: [PATCH] Fix freeze in lm8333 i2c keyboard driver
To:     Jeff LaBundy <jeff@labundy.com>
Cc:     Dmitry Torokhov <dmitry.torokhov@gmail.com>,
        linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

> Yes that's correct; what I mean to say is that depending on the nature of
> the read-to-clear mechanism in the part, there is a chance that the IRQ
> has not been deasserted by the time the threaded handler returns. On some
> devices for example, the IRQ is not deasserted until some time after the
> read's stop condition.
>
> For these cases, I consider it best practice to measure the I2C and IRQ
> lines on a scope and if necessary, add a small delay before the interrupt
> handler returns. This is especially true for open-drain interrupts that
> may need a few hundred extra us for the pin to rise.

Well before posting the patch i did some testing.
I was watching the /proc/interrupts and checked that IRQ counter for
lm8333 matches number of keypresses.
Which i've only tested for like 20-30 times, but haven't seem any glitch.

But i still recognize the fact that the gpio line getting stuck for
some reason (short circuit on PCB?) might cause troubles by
unnecessarily loading the CPU, while with edge trigger it's more
likely to affect only the function of keyboard itself rather than
bringing down whole system. But i am not sure if this case is supposed
to be expected and handled in SW.