On Mon, Mar 29, 2021 at 8:28 PM Sander Vanheule [off-list ref] wrote:

On Mon, 2021-03-29 at 13:26 +0300, Andy Shevchenko wrote:

quoted

On Fri, Mar 26, 2021 at 11:11 PM Sander Vanheule <
sander@svanheule.net> wrote:

...

quoted

AFAICS all, except one have this flag, I suggest you to do other way
around, i.e. check compatible string in the code. Or do something more
clever. What happens if you have this flag enabled for the fallback
node?

If two people ask the same, it might be a smoking gun.

Testing for the fallback wouldn't work, since of_device_is_compatible()
would always match. Setting the (inverse) flag only on the fallback
would indeed reduce the clutter.

If the port order is reversed w.r.t. to the current implementation,
enabling a GPIO+IRQ would enable the same pin on a different port. I
don't think the result would be catastrophical, but it would result in
unexpected behaviour. When A0 and C0 are then enabled, A0 interrupts
would actually come from C0, and vice versa.

   Intended port | A | B | C | D
-----------------+---+---+---+---
Actual GPIO port | D | C | B | A
 Actual IRQ port | B | A | D | C

If only the actual GPIO ports change, at least you can still use a
modified GPIO line number and polling. The user could just leave out
the optional irq-controller from the devicetree, but I would rather
have it enforced in some way.

OK! Thanks for clarification.

-- 
With Best Regards,
Andy Shevchenko