Re: [PATCH v1 1/2] dt-bindings: gpio: fairchild,74hc595: add registers-default property

From: Rob Herring

Date: Tue May 05 2026 - 16:26:33 EST


On Wed, Apr 29, 2026 at 11:03:46AM +0200, Bartosz Golaszewski wrote:
> On Tue, Apr 28, 2026 at 11:07 AM Linus Walleij <linusw@xxxxxxxxxx> wrote:
> >
> > On Wed, Apr 22, 2026 at 6:05 PM Chanhong Jung <happycpu@xxxxxxxxx> wrote:
> >
> > > The 74HC595 and 74LVC594 shift registers latch their outputs until the
> > > first serial write, so boards that depend on a specific power-on pattern
> > > (for example active-low indicators, reset lines, or other signals that
> > > must come up non-zero) have no way to express that today: the Linux
> > > driver always writes zeros from its zero-initialised buffer during
> > > probe.
> > >
> > > Describe a new optional 'registers-default' property that carries a u8
> > > array - one byte per cascaded register, in the same order used by the
> > > driver's internal buffer (first byte targets the last register in the
> > > chain). The Linux driver change that consumes this property follows.
> > >
> > > This property is already recognised by the corresponding U-Boot driver
> > > (drivers/gpio/74x164_gpio.c), so documenting it here brings the two
> > > bindings back in sync and allows boards to initialise the chain once
> > > from the bootloader DT and keep the same value after the kernel takes
> > > over.
> > >
> > > Signed-off-by: Chanhong Jung <happycpu@xxxxxxxxx>
> >
> > See
> > Documentation/devicetree/bindings/gpio/nxp,pcf8575.yaml
> >
> > lines-initial-states:
> > $ref: /schemas/types.yaml#/definitions/uint32
> > description:
> > Bitmask that specifies the initial state of each line.
> > When a bit is set to zero, the corresponding line will be initialized to
> > the input (pulled-up) state.
> > When the bit is set to one, the line will be initialized to the
> > low-level output state.
> > If the property is not specified all lines will be initialized to the
> > input state.
> >
> > If you want to set up initial states, use this property.
> >
> > This also makes it possible for us to centralize the handling later on.
> >
>
> Ah, the old initial/default GPIO values problem strikes again. :(
>
> IMO this is software configuration, not HW description. I think the
> driver should do it based on the compatible and/or machine. It should
> not be a property but if Krzysztof is fine with it, I'll queue it.

Sounds like h/w configuration to me. It's the board design dicating the
config rather than the user.

Rob