linux-kernel - Re: [PATCH 02/17] dt-bindings: auxdisplay: ht16k33: Document Adafruit segment displays

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: <CAMuHMdVZMtJ8nRZXWnNz9U0_GKkUQn2+gkvx+Q=+c5tcfEVHUQ@mail.gmail.com>
Date:   Wed, 19 May 2021 13:02:20 +0200
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Robin van der Gracht <robin@...tonic.nl>
Cc:     Rob Herring <robh+dt@...nel.org>, Miguel Ojeda <ojeda@...nel.org>,
        Paul Burton <paulburton@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        "open list:BROADCOM NVRAM DRIVER" <linux-mips@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 02/17] dt-bindings: auxdisplay: ht16k33: Document Adafruit
 segment displays

Hoi Robin,

On Wed, May 19, 2021 at 12:37 PM Robin van der Gracht <robin@...tonic.nl> wrote:
> On 2021-05-18 16:35, Geert Uytterhoeven wrote:
> > On Tue, Mar 23, 2021 at 10:12 AM robin <robin@...tonic.nl> wrote:
> >> On 2021-03-22 15:48, Geert Uytterhoeven wrote:
> >> > The Holtek HT16K33 LED controller is not only used for driving
> >> > dot-matrix displays, but also for driving segment displays.
> >> >
> >> > Document compatible values for the Adafruit 7-segment[1] and
> >> > 14-segment[2] FeatherWing expansion boards with red displays.
> >> > According
> >> > to the schematics, all other Adafruit 7-segment and 14-segment display
> >> > backpack and FeatherWing expansion boards (including bare boards and
> >> > boards fitted with displays) are compatible with these two boards.
> >> > Add a "color" property to support the different color variants.
> >> >
> >> > [1] https://www.adafruit.com/product/3108
> >> > [2] https://www.adafruit.com/product/3130
> >> >
> >> > Signed-off-by: Geert Uytterhoeven <geert@...ux-m68k.org>
> >
> >> > --- a/Documentation/devicetree/bindings/auxdisplay/holtek,ht16k33.yaml
> >> > +++ b/Documentation/devicetree/bindings/auxdisplay/holtek,ht16k33.yaml
> >> > @@ -14,14 +14,23 @@ allOf:
> >> >
> >> >  properties:
> >> >    compatible:
> >> > -    const: holtek,ht16k33
> >> > +    oneOf:
> >> > +      - items:
> >> > +          - const: adafruit,3108  # 0.56" 4-Digit 7-Segment
> >> > FeatherWing Display (Red)
> >> > +          - const: holtek,ht16k33
> >> > +
> >> > +      - items:
> >> > +          - const: adafruit,3130  # 0.54" Quad Alphanumeric
> >> > FeatherWing Display (Red)
> >> > +          - const: holtek,ht16k33
> >> > +
> >> > +      - const: holtek,ht16k33     # Generic 16*8 LED controller with
> >> > dot-matrix display
> >> >
> >> >    reg:
> >> >      maxItems: 1
> >> >
> >> >    refresh-rate-hz:
> >> >      maxItems: 1
> >> > -    description: Display update interval in Hertz
> >> > +    description: Display update interval in Hertz for dot-matrix
> >> > displays
> >>
> >> The above should be included in patch 16
> >
> > I disagree: bindings are independent from the driver implementation.
> >
> >> >    interrupts:
> >> >      maxItems: 1
> >> > @@ -41,10 +50,17 @@ properties:
> >> >      default: 16
> >> >      description: Initial brightness level
> >> >
> >> > +  color: true
> >> > +    description:
> >> > +      Color of the display.  Use one of the LED_COLOR_ID_* prefixed
> >> > definitions
> >> > +      from the header include/dt-bindings/leds/common.h.  The default
> >> > is red.
> >> > +    minimum: 0
> >> > +    maximum: 9
> >> > +    default: 1
> >> > +
> >>
> >> The above should be included in patch 17
> >
> > Same here.
>
> My thought was that one without the other makes no sense. But if it's common
> practice to create a separate patch for device tree bindings (it's a
> patch-set
> after all) than that's fine with me.

scripts/checkpatch.pl even has a check for that:

    WARN("DT_SPLIT_BINDING_PATCH",
         "DT binding docs and includes should be a separate patch.
See: Documentation/devicetree/bindings/submitting-patches.rst\n");

See also rule #5 in the doc referred above:

  5) The Documentation/ portion of the patch should come in the series before
     the code implementing the binding.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds