On Mon, Mar 29, 2021 at 8:28 PM Sander Vanheule <sander@xxxxxxxxxxxxx> wrote: > On Mon, 2021-03-29 at 13:26 +0300, Andy Shevchenko wrote: > > On Fri, Mar 26, 2021 at 11:11 PM Sander Vanheule < > > sander@xxxxxxxxxxxxx> wrote: ... > > 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
