On Wed, Jul 24, 2024 at 03:25:38PM +0200, Krzysztof Kozlowski wrote: > On 23/07/2024 13:27, Conor Dooley wrote: > > The microchip,mpfs-gpio binding suffered greatly due to being written > > with a narrow minded view of the controller, and the interrupt bits > > ended up incorrect. It was mistakenly assumed that the interrupt > > configuration was set by platform firmware, based on the FPGA > > configuration, and that the GPIO DT nodes were the only way to really > > communicate interrupt configuration to software. > > > > Instead, the mux should be a device in its own right, and the GPIO > > controllers should be connected to it, rather than to the PLIC. > > Now that a binding exists for that mux, try to fix the misconceptions > > in the GPIO controller binding. > > > > Firstly, it's not possible for this controller to have fewer than 14 > > GPIOs, and thus 14 interrupts also. There are three controllers, with > > 14, 24 & 32 GPIOs each. > > > > The example is wacky too - it follows from the incorrect understanding > > that the GPIO controllers are connected to the PLIC directly. They are > > not however, with a mux sitting in between. Update the example to use > > the mux as a parent, and the interrupt numbers at the mux for GPIO2 as > > the example - rather than the strange looking, repeated <53>. > > > > You make ngpios required, which could be an ABI break except that there > is no Linux user for this, so there is no ABI break, right? If so, would > be nice to mention it. Rest looks good: No upstream user at least, and I don't believe that there are any non-linux projects using the GPIO controllers via DT. I could, I suppose, not make it required and use 32 as a default - but that could cause problems with existing devicetrees where all 3 controllers omitted the property, despite having differing numbers of GPIOs. Now that I look again, the driver actually doesn't enforce the presence of the property and I think it should fail to probe if not present.
Attachment:
signature.asc
Description: PGP signature
