On Tue, Oct 14, 2025 at 12:44:15PM +0200, Linus Walleij wrote: > Hi Gary, > > thanks for your patch! > > On Tue, Oct 14, 2025 at 3:57 AM Gary Yang wrote: > > > > +# Client device subnode's properties > > +patternProperties: > > + 'pins$': > > + type: object > > + additionalProperties: false > > + patternProperties: > > + '(^pins|pins?$)': > > + type: object > > + additionalProperties: false > > + description: > > + A pinctrl node should contain at least one subnodes representing the > > + pinctrl groups available on the machine. Each subnode will list the > > + pins it needs, and how they should be configured, with regard to muxer > > + configuration, pullups, and drive strength. > > + > > + properties: > > + pinmux: > > + description: > > + Values are constructed from pin number and mux setting and are > > + defined as macros in arch/arm64/boot/dts/cix/sky1-pinfunc.h directly. > > + > > + bias-disable: true > > + > > + bias-pull-up: true > > + > > + bias-pull-down: true > > + > > + drive-strength: > > + description: > > + Can support 15 levels, from DS_LEVEL1 to DS_LEVEL15. > > + defined as macros in arch/arm64/boot/dts/cix/sky1-pinfunc.h. Isn't this wrong? drive-strength is in mA but you're just shoving register values in here. pw-bot: changes-requested > > + > > + required: > > + - pinmux > > Can't you just include both pinmux-node.yaml and pincfg-node.yaml > to get validation from the generic schemas? > > 'pins$': > type: object > additionalProperties: false > patternProperties: > '(^pins|pins?$)': Why does this pattern allow foopin but not pinfoo? Also seems overkill to have both suffix and prefix options, instead of just sticking to one! > type: object > $ref: /schemas/pinctrl/pinmux-node.yaml > $ref: /schemas/pinctrl/pincfg-node.yaml > additionalProperties: false > > Something like this, I never get this right before actually testcompiling... spacemit,k1-pinctrl has a node of this type, that can be copied from Gary. Essentially, you need an allOf: for the two references.