lkml.org 
[lkml]   [2021]   [Mar]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH v4 2/2] gpio: Add Realtek Otto GPIO support
On Mon, Mar 29, 2021 at 8:28 PM Sander Vanheule <sander@svanheule.net> 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@svanheule.net> 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

\
 
 \ /
  Last update: 2021-03-30 12:17    [W:0.048 / U:1.708 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site