On Mon, Jan 27, 2025 at 7:17 PM Rob Herring <robh@xxxxxxxxxx> wrote: > [Olof] > > It seems worse to me to misdescribe the hardware as separate blocks > > with a device-tree binding that no longer describes the actual hardware, > > but it's not up to me. > > I agree. It's clearly 1 block given the first 3 banks are interleaved. > > If Linux can't handle 1 node for N gpio_chip's, then that's a Linux > problem. Maybe it can, IDK. The lookup from a DT node to gpio_chip just > needs to match on more than just DT node pointer, but look at the node > ptr and arg cells. Any operating system benefits from modeling the GPIOs such that one set of 32bit registers [r0, r1 .. rn] becomes a discrete entity for the OS. Reasoning: any OS will want to be able to control several lines in a single hardware operation, such as a register write, for example to shake a clock and data line with a single write_to_register() operation. If the hardware is described in chunks of 32 bit registers, this is easy - Data Out Register, Data In Register, Direction Register n bits, if an multiple-write/read operation hits this entity, we know it can be handled with a single register write or read. Yes, the same can be achieved by hardcoding this split into the driver. But having the binding like such encourages it. foo-gpios = <&gpio2 0>, <&gpio2 7>; both need to be set high at outset, well they are in the same entity and controlled by a single register, so (+/- overhead): fooreg = fooreg | (1 << 0) | (1 << 7); I agree this hardware is harder to classify as such since the blocks share a single IRQ line - if they had individual IRQ lines it would be a done deal, they are subblocks - yet shared IRQ lines are not *that* uncommon. Does this modeling reflect how the hardware actually looks? Likely. The way GPIOs are built up from silicon io-cells are not that complex. All the 32 bits from the set of registers will be routed to consecutive pins, looking at the pin layout of the SoC would confirm if subsequent bits map to subsequent pins. Yours, Linus Walleij