On Wed, Feb 22, 2017 at 1:57 PM, Alexander Sverdlin <alexander.sverdlin@xxxxxxxxx> wrote: >> - If the component has 8 IRQ lines, create a hierarchical IRQdomain >> and chip using a gpiolib core helper. > > This was an option of course, the only this is, PL061 spec says, there is > GPIOINTR and if someone has forgot it, we can support it with a quirk. I don't know about that. The PL061 manual says: "The contents of this register are made available externally through the intra-chip (or on-chip) GPIOMIS[7:0] signals." They don't say why, but it is reasonable to assume that this is an either-or not both-and integration point. EITHER you route GPIOMIS[7:0] to individual IRQ lines to the CPU OR you route GPIOINTR to the CPU. The first approach is in a sense more efficient, because you do not need a second level read to figure out what IRQ was fired. > It's not specified to work this way at all, so why spend any resources > and add second implementation to the driver? It's not specified at all how it's supposed to work. But can you really see any other reason to make both GPIOMIS[7:0] and GPIOINTR available that what I describe above? >> - If not 1 or 8 lines, bail out with an error. > > Well, I'd divide it into "1" and "!= 1" cases... Who knows, maybe > only 4 GPIOs will be implemented... If you mean that the hardware engineer only route 4 of the signals, then the ngpio property of the device tree node must be specified. That is exactly what that property is for, see: Documentation/devicetree/bindings/gpio/gpio.txt If that is not specified, it should be 1 using GPIOINTR, 8 and using GPIOMIS[7:0] or error. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html