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

[Chanhong Jung]

Hi Linus,

Thank you for the thoughtful review - this is exactly the kind of
pointer I was hoping for. Reusing 'lines-initial-states' is a much
cleaner fit than the new property I proposed, and it elegantly
resolves Krzysztof's concern in the same stroke: 'lines-initial-states'
is already documented under a sibling binding (nxp,pcf8575), so v2
only widens its applicability rather than introducing a generic,
non-vendor-prefixed property to a vendor-specific binding. Two
problems, one existing convention - that's a really nice call.

> 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.
>       ...
>       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.

You're absolutely right. I've reworked the series to drop
'registers-default' entirely and read 'lines-initial-states' as a
u32 bitmask, mapping bit N -> GPIO line N (matching the pcf8575
convention). For this output-only family the polarity falls out
naturally: bit=0 drives the line low and bit=1 drives it high. The
bitmask covers up to 32 lines (4-chip cascades), which fits all
current in-tree users of this binding; longer chains can extend the
property later without breaking the bit-N=line-N mapping.

> This also makes it possible for us to centralize the handling later on.

That's a great forward-looking point, and I really appreciate you
flagging it. Keeping the property name aligned with pcf8575 leaves
the door wide open for a future common helper without anyone having
to churn the binding to get there.

v2 will follow shortly in this thread (--in-reply-to of the v1
cover), and I've added

  Suggested-by: Linus Walleij <linus.walleij@xxxxxxxxxx>

to the driver patch in recognition of the much better direction you
pointed me to. Happy to move the attribution elsewhere or adjust the
form if you'd prefer.

Thanks again for the careful read and for steering this in a cleaner
direction.

Yours,
Chanhong