Re: [PATCH] pinctrl: amd: Add support for additional GPIO

[Linus Walleij <linus.walleij@xxxxxxxxxx>]

On Tue, Nov 22, 2016 at 11:19 AM, Shah, Nehal-bakulchandra
<Nehal-Bakulchandra.shah@xxxxxxx> wrote:

> I understood that chained irq and devm_irq can't be used together. Surely,
> I will rework on the patch.

OK! :)

We have a case where devm_request_threaded_irq() is used like this,
that is called *nested* irqs, when an interrupt-handling thread is called
from within another interrupt-handling thread.

But since this handler is not threaded, but rather a hardirq, it is not
a viable option.

> The reason behind using devm_irq is that in our
> upcoming platform bios may report two gpio controllers. Both will have same IRQs.
> In my understanding if I use chained irq handler, it will not be clear interrupt
> is due to which gpio controller.It may lead to serve irq twice.

This is a shared IRQ line.

How stressful that it is shared between two cascaded irqchips!

Shared IRQs should nominally be handled by the leafs of the interrupt
handlers returning IRQ_HANDLED and the ones that did not
trigger an IRQ returning IRQ_NONE.

With a chained handler the assumption is that the flow handler
is not really returning anything, just dispatching down to the
consumer (device etc) to return IRQ_HANDLED if it was
their IRQ.

If you want to "bail out" of the chained handler (in your
case what you pass to gpiochip_set_chained_irqchip())
just check if the IRQ status register happens to be zero,
and in that case return; before even calling
chained_irq_enter().

I do not know if there is a way to mark a line as shared
in a chained flow handler!

The current assumption is that gpiochip_set_chained_irqchip()
is called for one or many *different* IRQs. That will work.
But if it is called twice for the *same* IRQ, we might need
some special work inside gpiochip_set_chained_irqchip()
to make this work properly with shared IRQs...

> Please let me know if anything is incorrect in my understanding or if there is
> a better way to handle this situation.

I think reading a bit in kernel/irq/chip.c to see what is really
happening with chained IRQs help a lot. If there are unclarities,
it needs to be discussed with the IRQchip maintainers
(Marc & Thomas).

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html