Hi Linus,

On Fri, May 21, 2021 at 12:04 PM Linus Walleij [off-list ref] wrote:

On Fri, May 21, 2021 at 9:54 AM Geert Uytterhoeven
[off-list ref] wrote:

quoted

Convert the PCF857x-compatible I/O expanders Device Tree binding
documentation to json-schema.

Document missing compatible values, properties, and gpio hogs.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>

(...)

quoted

Perhaps the "ti,pcf8575" construct should be removed, and the few users
fixed instead?

You would rather list it as deprecated I think?
It is ABI...

All DTS files use the "nxp,pcf8575" fallback, except for
arch/x86/platform/ce4100/falconfalls.dts.
The latter ain't working with Linux, as the Linux driver doesn't
match against "ti,pcf8575"...

quoted

+  gpio-controller: true

So this is implicitly using the generic schema in
/dtschema/schemas/gpio/gpio.yaml

if you leave it out:

    Documentation/devicetree/bindings/gpio/nxp,pcf8575.yaml: ignoring,
error in schema: properties
    warning: no schema found in file:
Documentation/devicetree/bindings/gpio/nxp,pcf8575.yaml
    Documentation/devicetree/bindings/gpio/nxp,pcf8575.yaml:
properties: 'gpio-controller' is a dependency of '#gpio-cells'
    from schema $id: http://devicetree.org/meta-schemas/gpios.yaml#

quoted

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

Is this something we standardized or something that should
actually be a custom "nxp," property we just missed it?
(Looks like the latter... oh well, now it is there.)

Too late for an "nxp," prefix.
See the NOTE in drivers/gpio/gpio-pcf857x.c:

        /* NOTE:  these chips have strange "quasi-bidirectional" I/O pins.
         * We can't actually know whether a pin is configured (a) as output
         * and driving the signal low, or (b) as input and reporting a low
         * value ... without knowing the last value written since the chip
         * came out of reset (if any).  We can't read the latched output.
         *
         * In short, the only reliable solution for setting up pin direction
         * is to do it explicitly.  The setup() method can do that, but it
         * may cause transient glitching since it can't know the last value
         * written (some pins may need to be driven low).
         *
         * Using n_latch avoids that trouble.  When left initialized to zero,
         * our software copy of the "latch" then matches the chip's all-ones
         * reset state.  Otherwise it flags pins to be driven low.
         */

quoted

+patternProperties:
+  "^(hog-[0-9]+|.+-hog(-[0-9]+)?)$":
+    type: object

But this is already in
/dtschema/schemas/gpio/gpio-hog.yaml
for nodename, isn't that where it properly belongs?

I'm however confused here Rob will know what to do.

If we leave this out, something still has to refer to it?
I see no other binding doing that...

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds