On Mon, Jul 27, 2015 at 12:19:08PM +0200, Linus Walleij wrote:

On Thu, Jul 16, 2015 at 7:19 PM, Richard Cochran

quoted

This happens with every DT discussion that tries to make things
logical for the end user.

Are you assuming bad faith?

No, I was reacting to the NAK (which I can accept) that does not
address or even acknowledge the problem (which I cannot accept so
easily).

But now that a solution has appeared, I am happy again.

I think Michael made a very very nice patch series trying to make
things logical for end users, please participate in that discussion.

Yes, I read it, and it sounds like it will solve the problem.  I will
give the series a try...
 

quoted

Isn't there a mapping interface for irq numbers?

I don't see what you mean here. The numbers that appear in
say /proc/interrupts may seem stable but they are not.
They depend on things like probe order between irqchips
and can change between two boots.

The reason users don't have an issue with it is that there is
(thank god) no userspace ABI for interrupts.

I was talking about CONFIG_IRQ_DOMAIN_DEBUG.
 

The problem is for example if I have a SoC with a GPIO expander:
both have a GPIO line named "0". Which one wins? The SoC
because it is "more important"? This issue is all over the place
in any modern chipset. In Ux500 I have sometimes three GPIO
expanders, all three with GPIO line 0, and also a GPIO 0 on
the SoC of course. So we need to express this complexity to
userspace, not try to simplify the world.

Thanks for the explanation.  Of course I don't want an arbitrarily
simplified interface, but I can't understand why the simple case of
built-in SoC GPIOs must have such a weird and variable numbering
patterns.

But once user space can call GPIOs by name, then it doesn't matter
anymore what the kernel numbers are.

Thanks,
Richard