linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff LaBundy <jeff@labundy.com>
To: "Tomáš Mudruňka" <tomas.mudrunka@gmail.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Fix freeze in lm8333 i2c keyboard driver
Date: Thu, 27 Apr 2023 13:54:07 -0500	[thread overview]
Message-ID: <ZErEz57E1amWtxa7@nixie71> (raw)
In-Reply-To: <CAH2-hcJa_vL9iWTARUAD+adrvQAjzr1N4bQ=cN+8kbE0arVwZw@mail.gmail.com>

Hi Tomas,

On Thu, Apr 27, 2023 at 10:19:38AM +0200, Tomáš Mudruňka wrote:
> > 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.

In the case of short circuit, the hardware has failed and there is nothing
we can do.

My point is that different devices deassert their IRQ at different points
in the read-to-clear operation. For some devices, the IRQ is deasserted
immediately after the register address is latched, so we can be confident
that the IRQ has already gone high by the time the I2C read operation and
hence the interrupt handler return.

On others however, the IRQ may still remain low for 10's or even 100's of
us after the read is complete. In some cases, the threaded handler could
have already returned by then. Since you did not find any unexplained IRQ
counts, perhaps that is not the case for this device.

Kind regards,
Jeff LaBundy

      reply	other threads:[~2023-04-27 18:54 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-25 13:00 [PATCH] Fix freeze in lm8333 i2c keyboard driver Tomas Mudrunka
2023-04-25 15:39 ` Jeff LaBundy
2023-04-25 16:49   ` [PATCH v2] " Tomas Mudrunka
2023-04-27  0:41     ` Jeff LaBundy
2023-04-27  8:13       ` Tomáš Mudruňka
2023-04-27 18:47         ` Jeff LaBundy
2023-04-28 10:09       ` [PATCH v3] " Tomas Mudrunka
2023-04-28 10:20       ` [PATCH v4] " Tomas Mudrunka
2023-05-03  3:02         ` Jeff LaBundy
2023-05-03  8:54           ` Tomáš Mudruňka
2023-05-03 15:32             ` [PATCH v5] " Tomas Mudrunka
2023-05-04  1:44               ` Jeff LaBundy
2023-05-11 23:44                 ` Dmitry Torokhov
2023-05-12 16:54                   ` Jeff LaBundy
2023-05-12 16:55                   ` Tomáš Mudruňka
2023-05-12 17:28                     ` Jeff LaBundy
2023-11-14 12:30                       ` [PATCH v6] " Tomas Mudrunka
2023-12-14  2:24                         ` Jeff LaBundy
2023-12-15 15:56                           ` [PATCH v7] " Tomas Mudrunka
2025-02-19 14:51                             ` Tomas Mudrunka
2023-04-26 23:16   ` [PATCH] " Dmitry Torokhov
2023-04-27  0:27     ` Jeff LaBundy
2023-04-27  8:19       ` Tomáš Mudruňka
2023-04-27 18:54         ` Jeff LaBundy [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZErEz57E1amWtxa7@nixie71 \
    --to=jeff@labundy.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tomas.mudrunka@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).