linux-kernel - Re: [PATCH RESEND v2] dt-bindings: pinctrl: Convert ingenic,pinctrl.txt to YAML

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAL_Jsq+nHZsbOMPpXC7NWp1etgVL57Q+o=gr6BJ6ijAq1pLJUw@mail.gmail.com>
Date:   Tue, 14 Jul 2020 08:05:37 -0600
From:   Rob Herring <robh@...nel.org>
To:     Paul Cercueil <paul@...pouillou.net>
Cc:     Linus Walleij <linus.walleij@...aro.org>, od@...c.me,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        devicetree@...r.kernel.org,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH RESEND v2] dt-bindings: pinctrl: Convert
 ingenic,pinctrl.txt to YAML

On Mon, Jul 13, 2020 at 9:36 AM Paul Cercueil <paul@...pouillou.net> wrote:
>
> Hi Rob,
>
> Le lun. 13 juil. 2020 à 9:32, Rob Herring <robh@...nel.org> a écrit :
> > On Mon, Jun 22, 2020 at 01:37:40PM +0200, Paul Cercueil wrote:
> >>  Convert the ingenic,pinctrl.txt doc file to ingenic,pinctrl.yaml.
> >>
> >>  In the process, some compatible strings now require a fallback, as
> >> the
> >>  corresponding SoCs are pin-compatible with their fallback variant.
> >>
> >>  Signed-off-by: Paul Cercueil <paul@...pouillou.net>
> >>  ---
> >>
> >>  Notes:
> >>      v2: - Use 'pinctrl' instead of 'pin-controller' as the node name
> >>          - remove 'additionalProperties: false' since we will have
> >> pin conf nodes
> >
> > What do those look like? They need to be described, but that can be a
> > follow-up.
>
> These are generic conf nodes that are handled by the pinctrl core.

No such thing. There's a set of common properties, but that is all.
You still need to document which properties apply because it is
doubtful they all do.

> Nothing specific to the hardware described here. The subnodes don't
> have any specific pattern so it is not possible to represent them in
> devicetree (we'd need a 'catch them all' wildcard pattern property).

Ideally, the nodes should be named something we can match on like
"-pins$", but if not you can do:

additionalProperties:
  type: object
  $ref: pincfg-node.yaml#
  properties:
    bias-disable: true
    ...
  additionalProperties: false


Rob