Devicetree + driver model for FMC memory-mapped 74HC574 latch outputs (GPIO expander?) on STM32F429 board

[lizhaoming634]

Hi, I’m working on upstreaming a custom STM32F429 board (Armfly STM32F429BIT6).

1. This board uses 4x 74HC574 latches to provide 32 latched output lines. The latches are connected to the STM32 FMC data bus (D0..D31). The latch clock (CP) is generated by FMC write strobe + address decode logic, so from software the only interface is a memory-mapped, write-only latch port at 0x64001000 (FMC Bank2). There is no hardware readback path for the latched outputs.

I’d like advice on the most upstream-friendly devicetree + driver model for this.

Current DT model (GPIO controller backed by MMIO write)

fmc_extio: gpio@64001000 {
    compatible = "armfly,fmc-hc574-gpio";
    reg = <0x64001000 0x4>;
    gpio-controller;
    #gpio-cells = <2>;
    ngpios = <32>;
    status = "okay";
};

leds {
    compatible = "gpio-leds";

    led0 { gpios = <&fmc_extio 8 GPIO_ACTIVE_LOW>; label = "LED0"; };
    led1 { gpios = <&fmc_extio 9 GPIO_ACTIVE_LOW>; label = "LED1"; };
    led2 { gpios = <&fmc_extio 10 GPIO_ACTIVE_LOW>; label = "LED2"; };
    led3 { gpios = <&fmc_extio 11 GPIO_ACTIVE_LOW>; label = "LED3"; };
}; 

Driver behavior

• Implements a GPIO controller for these outputs.
• Writes are performed by writing a 32-bit value to the MMIO window.
• Since the hardware is write-only, the driver keeps a software shadow and returns the shadow in port_get_raw().

Questions

1. Is this MMIO + write-only + software shadow GPIO controller model acceptable upstream?

   • Or would you prefer modeling it as a latch-based expander using *-gpios (e.g. latch-gpios, oe-gpios, data-gpios) even though those signals are not exposed as discrete GPIOs in this design?

2. If MMIO is acceptable, is there an existing upstream binding/driver pattern I should align with (for example extending an existing gpio-mmio style driver to support write-only), or is a dedicated drivers/gpio driver OK?

3. Where should the binding and driver live for upstream?

   • Binding under dts/bindings/gpio/
   • Driver under drivers/gpio/
   • (Right now I have them board-local while iterating.)

4. compatible naming: should this be vendor-specific (armfly,...) or something more generic given it's a 74HC574-based latch behind FMC glue logic?

[lizhaoming634]

[lizhaoming634]

https://github.com/lizhaoming634/armfly-zephyr-boards

[lizhaoming634]

Hi @gautierg-st — sorry to ping. I want to upstream a custom STM32F429 board.

It uses 4x 74HC574 latches driven via FMC (D0..D31) with address-decode generating the latch clock. From software it’s a write-only MMIO latch port at 0x64001000 (no readback), so I modeled it as an MMIO-backed gpio-controller with a software shadow.

Could you advise if this MMIO write-only + shadow GPIO model is acceptable upstream (vs. latch-style *-gpios), and where you’d expect the binding/driver to live (dts/bindings + drivers/gpio vs board-local)?
Thanks!

[henrikbrixandersen]

2. If MMIO is acceptable, is there an existing upstream binding/driver pattern I should align with (for example extending an existing gpio-mmio style driver to support write-only), or is a dedicated drivers/gpio driver OK?

I would go for something generic, similar to https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/gpio/gpio-mmio.yaml but likely using a more generic compatible string than what is used in the Linux kernel devicetree binding (e.g. "gpio-mmio" or something along those lines).