Re: [PATCH v5 3/4] dt-bindings: pps: pps-gpio: document optional pinctrl states

[Rob Herring <robh@kernel.org>]

On Wed, Sep 23, 2026 at 01:13:10PM +0000, Farber, Eliav wrote:
> On Wed, Sep 23, 2026 at 07:36:05AM -0500, Rob Herring wrote:
> > On Tue, Sep 22, 2026 at 02:46:40PM +0200, Rodolfo Giometti wrote:
> > > On Tue, Sep 22, 2026 at 10:30:50AM +0000, Eliav Farber wrote:
> > > > +    minItems: 1
> > > > +    items:
> > > > +      - const: default
> > > > +      - const: inactive
> > >
> > > One observation while testing the series, entirely a devicetree call:
> > > dtschema derives maxItems from the items list, so this also caps
> > > pinctrl-names at two and fixes the order --
> >
> > Yes, that's exactly what was said was needed here.
> >
> > >   "default", "inactive", "sleep"   ->  'is too long'
> > >   "default", "sleep"               ->  'inactive' was expected
> >
> > Well, that's something different.
> >
> > items:
> >   - const: default
> >   - enum: [ inactive, sleep ]
> >   - const: sleep
> >
> > The common pinctrl-names schema should require unique names so 'sleep'
> > can't be repeated.
> 
> Thanks. Just so I pick the right thing for v6 -- do you want me to
> change patch 3 to that form, or is the current
> 
>     minItems: 1
>     items:
>       - const: default
>       - const: inactive
> 
> fine as-is?

Yes.


> This binding only defines "default" and "inactive"; the driver looks
> both up by name and does not use a "sleep" state, so I had deliberately
> capped the list at those two. Your snippet reads to me as how the common
> pinctrl-names schema would accommodate a "sleep" state in general,
> rather than something this binding needs -- but I would rather confirm
> than guess.
> 
> If you would prefer the more permissive form so a board can also declare
> "sleep", I will switch to it (with unique-name enforcement) in v6.
> Otherwise I will keep the two-entry list.
> 
> > We don't even require pinctrl properties to be documented. They are
> > implicitly allowed, but good to document what users (drivers)
> > expect/require.
> 
> Right -- documenting the two names the driver actually consumes was the
> intent here.

I have no clue why "sleep" was added to the discussion...

Rob