linux-kernel - Re: [PATCH] gpio: max732x: Add IRQF

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJOTznXaqHOivrEXj6EiSuYPX_j6rD-zLShzSFgCbX9zGnVVDw@mail.gmail.com>
Date:	Thu, 23 Apr 2015 17:15:52 +0300
From:	Sam Protsenko <semen.protsenko@...ballogic.com>
To:	Vladimir Zapolskiy <vladimir_zapolskiy@...tor.com>
Cc:	Linus Walleij <linus.walleij@...aro.org>,
	Alexandre Courbot <gnurou@...il.com>,
	linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] gpio: max732x: Add IRQF_SHARED to irq flags

On Apr 22, 2015 at 10:53 PM, Vladimir Zapolskiy wrote:
> is it still the case that for shared interrupts a hard IRQ handler is
> mandatory to have?
>
> Here I rely on
> http://lists.kernelnewbies.org/pipermail/kernelnewbies/2011-March/001118.html
>
> With best wishes,
> Vladimir
>

Vladimir,

A hard IRQ handler is not mandatory to have for shared interrupts. It just can
make things a bit faster. In fact, there is a lot of drivers that implement the
same behavior as my patch proposes (requesting threaded interrupt with
IRQF_SHARED flag and default IRQ handler). Well, there *may* be some cases
when hard IRQ handler is mandatory, but it's definitely not this case.

Basically, what happens when interrupt arrives from the line that has multiple
devices on it -- is that all the interrupt handlers (for devices on that line)
are being executed. Then each handler reads interrupt register from associated
device and decides if interrupt was from it's device. In my case reading is
happening via I2C interface, which can take a while to finish, hence it's not
recommended to perform I2C operations in hard IRQ handlers.

The general approach for I2C drivers is to do request_threaded_irq() with
NULL specified for hard IRQ handler (so irq_default_primary_handler() will be
used, which just wakes bottom half handler). Driver should read interrupt
register (via I2C) in threaded IRQ handler, do corresponding actions and send
acknowledge to device, so device can release interrupt line. In my case
acknowledge is happening automatically on I2C read operation. Also it's
important to provide IRQF_ONESHOT flag when requesting threaded irq:
this way irq line will be disabled before running threaded handler.

Hope it answers your question.

Best regards,
  Sam Protsenko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/