On Tue, 2016-10-25 at 20:20 +0200, Linus Walleij wrote:

On Tue, Oct 25, 2016 at 5:31 PM, Jerome Brunet [off-list ref]
wrote:

quoted

On Tue, 2016-10-25 at 15:47 +0100, Marc Zyngier wrote:

quoted

quoted

Is gpio_to_irq() supposed to allocate an interrupt? Or merely to
report the existence of a mapping?

It should provide an IRQ corresponding to the gpio line, if possible.

However the semantic is such, that it is not necessary to call
to_irq()
before using an IRQ: the irqchip and gpiochip abstractions should be
orthogonal.

Linus,

They are?orthogonal. You can request an irq from the irqchip controller
without the gpiochip, like any other irq controller.

This goes especially when using device tree or ACPI, where you
may reference an IRQ from something modeled as irqchip, which
is simultaneously a gpiochip.

quoted

Linus, please correct me if I'm wrong,
.to_irq gets the linux gpio number and returns the linux virtual
irq
numbers, 0 if there is no interrupt.

Yes. But it may *or may not* be called before using the IRQ.

So it should look up or try to create a mapping on request, but not
assume to have been called before using some line as IRQ.

The only thing you should assume to be called before an interrupt
is put to use is the stuff in irqchip. So you have to do your
dynamic irqdomain mapping elsewhere than .to_irq().

irq_create_mapping (and irq_create_fwspec_mapping) internally calls
irq_find_mapping. So if the mapping already exist (the irq is already
used before calling to_irq), the existing mapping will be returned. The
mapping will be actually created only if needed. It seems to be in line
with your explanation, no ?

There is really a *lot* of gpio drivers which use irq_create_mapping in
the to_irq callback, are these all wrong ?
If this should not be used, what should we all do instead ??

Yours,
Linus Walleij