[PATCH v2 01/15] dt-bindings: gpio: convert bindings for NXP PCA953x family to dtschema

Krzysztof Kozlowski krzk at kernel.org
Fri Sep 11 02:52:01 EDT 2020


On Fri, 11 Sep 2020 at 08:24, Joel Stanley <joel at jms.id.au> wrote:
>
> On Thu, 10 Sep 2020 at 17:57, Krzysztof Kozlowski <krzk at kernel.org> wrote:
> >
> > Convert the NXP PCA953x family of GPIO expanders bindings to device tree
> > schema.
> >
> > Signed-off-by: Krzysztof Kozlowski <krzk at kernel.org>
>
> > +patternProperties:
> > +  "^(hog-[0-9]+|.+-hog(-[0-9]+)?)$":
> > +    type: object
> > +    properties:
> > +      gpio-hog: true
> > +      gpios: true
> > +      input: true
> > +      output-high: true
> > +      output-low: true
> > +      line-name: true
> > +
> > +    required:
> > +      - gpio-hog
> > +      - gpios
> > +
>
> > +            usb3-sata-sel-hog {
> > +                gpio-hog;
> > +                gpios = <4 GPIO_ACTIVE_HIGH>;
> > +                output-low;
> > +                line-name = "usb3_sata_sel";
>
> I would prefer we didn't require the addition of hte -hog prefix. It's
> mostly just a matter of taste, but I can think of a few more concrete
> reasons:
>
> We don't require -high or -low prefixes, so the node name doesn't need
> to describe the properties that will be found below.

Thanks for the comments.

It is not about properties (high or low) but the role of a device
node. The node names should represent a generic class of device (ePAPR
and device tree spec) and "hog" is such class.

The Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml already
uses such naming so the best would be to unify.

>
> Changing around node names for existing boards carries with it the
> chance of userspace breakage (as sysfs paths change). I would prefer
> we avoid that if possible.

The impact on userspace is indeed important, but are you sure that
hogs are visible to user-space via sysfs and configurable? I guess you
think of deprecated CONFIG_GPIO_SYSFS?

Rob,
Any hints from you about hog-naming?

Best regards,
Krzysztof



More information about the linux-arm-kernel mailing list