[PATCH v2 0/2] gpio: 74x164: seed the chain from DT at probe time

[Chanhong Jung <happycpu@gmail.com>]

This v2 reuses the existing lines-initial-states bitmask, as suggested
by Linus Walleij, instead of inventing a new property. That sidesteps
both the v1 review concerns at once: there is no vendor-specific
property to argue about, and the bit-N-equals-line-N convention is
already documented for nxp,pcf8575.

Background (carried over from v1):
The 74HC595 / 74LVC594 family is push-pull output only. There is no
read-back path, no defined power-on state for the parallel outputs, and
__gen_74x164_write_config() always shifts the full chain on every
transaction. The driver therefore publishes whatever sits in
chip->buffer on the very first ->set() call, and today that buffer is
fresh from kzalloc(), so all outputs come up low. On boards with active-
low indicators or other signals whose initial level matters, the 0x00
publish glitches the chain before user space (or gpio-leds default-state
walking) gets a chance to run.

gpio-hog is not a substitute here: each hog is applied sequentially and
forces an intermediate full-chain write per line, and on this board
gpio-leds already claims every output, leaving no free lines to hog.

Approach in v2:
Patch 1 documents the existing lines-initial-states property under the
fairchild,74hc595 binding, with the small wording change that on this
output-only family bit=0 drives the line low and bit=1 drives it high.

Patch 2 wires the driver to read that bitmask into chip->buffer before
the first __gen_74x164_write_config(), so the chain comes up in the
configured pattern atomically on the first SPI transaction. Property
absence keeps the existing zeroing behaviour.

The bitmask covers up to 32 lines (four cascaded chips), which fits all
existing in-tree users and the typical 1-4 chip cascades. If a longer
chain ever needs seeding, the property can be extended to a uint32-array
without breaking the bit-N-equals-line-N convention.

Tested on a 4-chip 74HC595 chain (32 outputs, active-low LEDs); the
0x00 glitch on first write goes away with lines-initial-states set to
the desired idle pattern, and absence of the property leaves behaviour
unchanged.

Changes since v1
[https://lore.kernel.org/linux-gpio/cover.1776872453.git.happycpu@gmail.com/]:
  - Drop the new 'registers-default' u8-array property; reuse the
    existing 'lines-initial-states' uint32 bitmask instead, as
    suggested by Linus Walleij. This also addresses Krzysztof
    Kozlowski's concern about adding a generic, non-vendor-prefixed
    property to a vendor-specific binding (the property is already
    documented for nxp,pcf8575).
  - Driver now reads a single u32 and maps bit N to GPIO line N,
    matching the nxp,pcf8575 convention. For this output-only device
    the polarity is the natural one: bit=0 drives the line low,
    bit=1 drives it high.
  - Binding example updated accordingly.

Chanhong Jung (2):
  dt-bindings: gpio: fairchild,74hc595: add lines-initial-states
    property
  gpio: 74x164: support lines-initial-states for boot-time output state

 .../bindings/gpio/fairchild,74hc595.yaml        | 13 +++++++++++++
 drivers/gpio/gpio-74x164.c                      | 17 ++++++++++++++++-
 2 files changed, 29 insertions(+), 1 deletion(-)

-- 
2.34.1