Re: [PATCH v7 1/3] dt-bindings: pinctrl: Add aspeed,ast2700-soc0-pinctrl

[Conor Dooley <conor@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 8325 bytes --]

Billy, Linus,

On Tue, Apr 21, 2026 at 06:15:44AM +0000, Billy Tsai wrote:
> > > > > > > +    properties:
> > > > > > > +      function:
> > > > > > > +        enum:
> > > > > > > +          - EMMC
> > > > > > > +          - JTAGDDR
> > > > > > > +          - JTAGM0
> > > > > > > +          - JTAGPCIEA
> > > > > > > +          - JTAGPCIEB
> > > > > > > +          - JTAGPSP
> > > > > > > +          - JTAGSSP
> > > > > > > +          - JTAGTSP
> > > > > > > +          - JTAGUSB3A
> > > > > > > +          - JTAGUSB3B
> > > > > > > +          - PCIERC0PERST
> > > > > > > +          - PCIERC1PERST
> > > > > > > +          - TSPRSTN
> > > > > > > +          - UFSCLKI
> > > > > > > +          - USB2AD0
> > > > > > > +          - USB2AD1
> > > > > > > +          - USB2AH
> > > > > > > +          - USB2AHP
> > > > > > > +          - USB2AHPD0
> > > > > > > +          - USB2AXH
> > > > > > > +          - USB2AXH2B
> > > > > > > +          - USB2AXHD1
> > > > > > > +          - USB2AXHP
> > > > > > > +          - USB2AXHP2B
> > > > > > > +          - USB2AXHPD1
> > > > > > > +          - USB2BD0
> > > > > > > +          - USB2BD1
> > > > > > > +          - USB2BH
> > > > > > > +          - USB2BHP
> > > > > > > +          - USB2BHPD0
> > > > > > > +          - USB2BXH
> > > > > > > +          - USB2BXH2A
> > > > > > > +          - USB2BXHD1
> > > > > > > +          - USB2BXHP
> > > > > > > +          - USB2BXHP2A
> > > > > > > +          - USB2BXHPD1
> > > > > > > +          - USB3AXH
> > > > > > > +          - USB3AXH2B
> > > > > > > +          - USB3AXHD
> > > > > > > +          - USB3AXHP
> > > > > > > +          - USB3AXHP2B
> > > > > > > +          - USB3AXHPD
> > > > > > > +          - USB3BXH
> > > > > > > +          - USB3BXH2A
> > > > > > > +          - USB3BXHD
> > > > > > > +          - USB3BXHP
> > > > > > > +          - USB3BXHP2A
> > > > > > > +          - USB3BXHPD
> > > > > > > +          - VB
> > > > > > > +          - VGADDC
> > > > > > > +
> > > > > > > +      groups:
> > > > > > > +        enum:
> > > > > > > +          - EMMCCDN
> > > > > > > +          - EMMCG1
> > > > > > > +          - EMMCG4
> > > > > > > +          - EMMCG8
> > > > > > > +          - EMMCWPN
> > > > > > > +          - JTAG0
> > > > > > > +          - PCIERC0PERST
> > > > > > > +          - PCIERC1PERST
> > > > > > > +          - TSPRSTN
> > > > > > > +          - UFSCLKI
> > > > > > > +          - USB2A
> > > > > > > +          - USB2AAP
> > > > > > > +          - USB2ABP
> > > > > > > +          - USB2ADAP
> > > > > > > +          - USB2AH
> > > > > > > +          - USB2AHAP
> > > > > > > +          - USB2B
> > > > > > > +          - USB2BAP
> > > > > > > +          - USB2BBP
> > > > > > > +          - USB2BDBP
> > > > > > > +          - USB2BH
> > > > > > > +          - USB2BHBP
> > > > > > > +          - USB3A
> > > > > > > +          - USB3AAP
> > > > > > > +          - USB3ABP
> > > > > > > +          - USB3B
> > > > > > > +          - USB3BAP
> > > > > > > +          - USB3BBP
> > > > > > > +          - VB0
> > > > > > > +          - VB1
> > > > > > > +          - VGADDC
> > > > > > > +      pins:
> > > > > > > +        enum:
> > > > > > > +          - AB13
> > > > > > > +          - AB14
> > > > > > > +          - AC13
> > > > > > > +          - AC14
> > > > > > > +          - AD13
> > > > > > > +          - AD14
> > > > > > > +          - AE13
> > > > > > > +          - AE14
> > > > > > > +          - AE15
> > > > > > > +          - AF13
> > > > > > > +          - AF14
> > > > > > > +          - AF15
> 
> > > > > > Why do you have groups and pins?
> > > > > > Is it valid in your device to have groups and pins in the same node?
> 
> > > > > The intent is to support both group-based mux selection and
> > > > > configuration, as well as per-pin configuration.
> 
> > > > > In our hardware:
> > > > > - `function` + `groups` are used for pinmux selection.
> > > > > - `pins` is used for per-pin configuration (e.g. drive strength,
> > > > >   bias settings).
> > > > > - `groups` may also be used for group-level configuration.
> 
> > > > > As a result, both `groups` and `pins` may appear in the same node,
> > > > > but they serve different purposes and do not conflict:
> > > > > - `groups` selects the mux function and may apply configuration to
> > > > >   the entire group.
> > > > > - `pins` allows overriding or specifying configuration for individual
> > > > >   pins.
> 
> > > > > In most cases, only one of them is needed, but both are allowed when
> > > > > both group-level and per-pin configuration are required.
> 
> > > > To be honest, that sounds like your groups are not sufficiently
> > > > granular and should be reduced such that you can use them for pin
> > > > settings.
> 
> > > The intent was to keep the binding flexible, but in practice the mixed
> > > use of `groups` and `pins` in the same node is not expected to be used.
> > > 
> > > Given that, I agree this flexibility is unnecessary and makes the
> > > binding semantics less clear. I'll rework the binding to make the
> > > expected usage explicit rather than allowing combinations that do not
> > > correspond to a real use case.
> > > 
> > > In particular, I'll split the constraints as follows:
> > > 
> > > - For pinmux, the presence of `function` will require `groups`, and
> > >   `pins` will not be allowed. This reflects the hardware design, where
> > >   the groups are defined by the pins affected by a given mux expression
> > > 
> > > - For pin configuration, exactly one of `groups` or `pins` will be
> > >   required (using oneOf), so that configuration is applied either at
> > >   group level or per-pin, but not both.
> > > 
> > > 
> > > - if:
> > >     required:
> > >       - function
> > >   then:
> > >     required:
> > >       - groups
> > >     not:
> > >       required:
> > >         - pins
> > >   else:
> > >     oneOf:
> > >       - required:
> > >           - groups
> > >         not:
> > >           required:
> > >             - pins
> > >       - required:
> > >           - pins
> > >         not:
> > >           required:
> > >             - groups
> > > Does this match what you had in mind?
> 
> > It's an improvement I think, but I am wondering why you cannot do
> > without pins entirely and apply pinconf stuff at the group level?
> > Of course that may not be possible with the current groups, but if you
> > made the groups more granular, would it be possible?
> 
> Within a given group, it is not always the case that all pins share the
> same configuration requirements (e.g. drive strength or bias settings),
> so applying pinconf purely at the group level would be too restrictive.

Right. That's pretty normal.

> Making the groups more granular to match all possible configuration
> combinations would not reflect the actual mux granularity and would
> significantly increase the number of groups.

> 
> For example, we have encountered a timing issue due to the PCB layout,
> where only the eMMC clock pin requires a different drive strength:
> 
>   # The EMMCG4 group includes pins AC14, AE15, AD14, AE14, AF14, AB13
>   # AC14: clock
>   # AE15: command
>   # AD14–AB13: data
> 
>   pinconf_emmc_clk: emmc-clk-pinconf {
>       pins = "AC14";
>       drive-strength = <8>;
>   };
> 
> In this case, applying pin configuration at the group level would affect
> all pins in the group, which is not desirable. Allowing per-pin
> configuration via `pins` is therefore necessary.
> 
> For this reason, `groups` is used for mux selection, while `pins` is
> required to express per-pin configuration where needed.

Right, yeah, I figured your objection to it was because of how
annoyingly small it would make the groups. I suppose the alternative is
going without groups and always using pins.
Having groups and pins seems really suboptimal to me, but there are
some other bindings where this is done. Linus, what is your take on
nodes supporting both? I'm biased towards having a more straightforward
binding but if you think this mix makes sense then I'll defer to your
vastly greater experience with these devices.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]