On Wed, Feb 10, 2021 at 7:41 PM Rob Herring <robh@xxxxxxxxxx> wrote: > On Mon, Feb 08, 2021 at 02:53:46PM +0100, Oleksij Rempel wrote: > > + interrupts: > > + maxItems: 1 > > + > > + gpios: > > + description: Optional diagnostic interface to measure signal level > > This description seems wrong in the case of only having a GPIO. > > Also, a GPIO only implies polled mode because if the GPIO is interrupt > capable, 'interrupts' should be required. For gpio-keys, we split the > compatible strings in this case. I leave it to you if you want to make > it more explicit. Ouch. This is a bit of semantic confusion where I see different things if I put my Linux hat on than if I put my DT hat on ... :/ Linux (or some other OS I suppose) has the ability to look up an interrupt resource for a GPIO line and that is used quite extensively. In this case it is certainly possible to write a Linux driver that only take a GPIO resource and looks up a corresponding interrupt without the involvement of any DT interrupt resources. This happens a lot. A typical example is cd-gpios in Documentation/devicetree/bindings/mmc/mmc-controller.yaml The operating system will take cd-gpios and infer the corresponding IRQ from the GPIO hardware by OS-internal mechanisms (in the Linux case simply using irqdomain) in almost cases, and that is how that is used today. It is an hardware interrupt that gets allocated and used but the DT is blissfully ignorant about. The reason is that GPIO is "general purpose" so they don't have very specific use cases and the interrupts are general purpose as well. A certain GPIO line may not even have a certain interrupt associated with it: there exist GPIO controllers with e.g. 32 GPIO lines but only 8 interrupts that can be assigned to GPIO lines on a first-come-first-serve basis so there could not be anything like a cell in the bindings pointing to a certain interrupt: it has to be resolved by software, at runtime. In many cases the corresponsing GPIO hardware will have both gpio-controller and interrupt-controller flags, but I bet there exist cases that are only flagged with gpio-controller and then the drivers in the OS goes and implement interrupts using its abstractions and assign them anyway. I don't know if this can be solved in a generic way (solved as in DT needs to know all about the systems interrupt resources, and the OS should not be handing out interrupts behind the back of the DT description for things that are not flagged as interrupt-controller) or if this ambiguity around GPIO chips just has to stay around forever. I think it may be one of those cases where DT bindings can't be all that imperialistic about controlling every resource, but there may be other views on this. Yours, Linus Walleij
