linux-kernel - Re: [PATCH v3 1/2] dt-bindings: input/touchscreen: add bindings for msg26xx

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <97ef97e996c2089cedb450f9aaac123208ca18e9.camel@mailoo.org>
Date:   Wed, 10 Feb 2021 18:48:55 +0100
From:   Vincent Knecht <vincent.knecht@...loo.org>
To:     Jeff LaBundy <jeff@...undy.com>
Cc:     Rob Herring <robh@...nel.org>,
        Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Henrik Rydberg <rydberg@...math.org>,
        Michael Srba <Michael.Srba@...nam.cz>,
        Linus Walleij <linus.walleij@...aro.org>,
        linux-input@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, ~postmarketos/upstreaming@...ts.sr.ht
Subject: Re: [PATCH v3 1/2] dt-bindings: input/touchscreen: add bindings for
 msg26xx

Le mardi 09 février 2021 à 21:10 -0600, Jeff LaBundy a écrit :
> Hi Vincent,
> 
> On Tue, Feb 09, 2021 at 07:58:33PM +0100, Vincent Knecht wrote:
> > Le mardi 09 février 2021 à 10:13 -0600, Rob Herring a écrit :
> > > On Thu, Jan 21, 2021 at 06:43:47PM +0100, Vincent Knecht wrote:
> > > > This adds dts bindings for the mstar msg26xx touchscreen.
> > > > 
> > > > Signed-off-by: Vincent Knecht <vincent.knecht@...loo.org>
> > > > ---
> > > > Changed in v3:
> > > > - added `touchscreen-size-x: true` and `touchscreen-size-y: true` properties
> > > > Changed in v2:
> > > > - changed M-Star to MStar in title line
> > > > - changed reset gpio to active-low in example section
> > > > ---
> > > >  .../input/touchscreen/mstar,msg26xx.yaml      | 69 +++++++++++++++++++
> > > >  1 file changed, 69 insertions(+)
> > > >  create mode 100644 Documentation/devicetree/bindings/input/touchscreen/mstar,msg26xx.yaml
> > > > 
> > > > diff --git a/Documentation/devicetree/bindings/input/touchscreen/mstar,msg26xx.yaml
> > > > b/Documentation/devicetree/bindings/input/touchscreen/mstar,msg26xx.yaml
> > > > new file mode 100644
> > > > index 000000000000..5d26a1008bf1
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/input/touchscreen/mstar,msg26xx.yaml
> > > > @@ -0,0 +1,69 @@
> > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > +%YAML 1.2
> > > > +---
> > > > +$id: http://devicetree.org/schemas/input/touchscreen/mstar,msg26xx.yaml#
> > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > +
> > > > +title: MStar msg26xx touchscreen controller Bindings
> > > > +
> > > > +maintainers:
> > > > +  - Vincent Knecht <vincent.knecht@...loo.org>
> > > > +
> > > > +allOf:
> > > > +  - $ref: touchscreen.yaml#
> > > > +
> > > > +properties:
> > > > +  compatible:
> > > > +    const: mstar,msg26xx
> > > 
> > > Don't use wildcards in compatible strings.
> > 
> > Thank you for the input...
> > 
> > Let's say I set it to "mstar,msg2638", is it better to rename the driver file and functions too ?
> > According to downstream source file naming, msg2638 is the model I have and test this driver with.
> 
> This is ultimately Dmitry's call, but it's fairly common to use wildcards
> for driver names and function calls if the driver is known to work across
> all devices that fit in the wildcard (see iqs5xx and many others).
> 
> The risk with wildcards, however, is that vendors can introduce different
> devices later with similar part numbers. Therefore, some subsystems (e.g.
> iio) tend to frown upon wildcards for that reason.
> 
> You should try and make the driver cover as many devices as possible. But
> if the driver is only known to work for one device then I don't think you
> can use a wildcard in the name unless you support all other devices (just
> my opinion).
> 
> In either case, however, compatible strings must be unique just as with a
> part number in a schematic or bill of materials. As such, it is perfectly
> fine to have multiple compatible strings in a single driver.
> 
> > 
> > 
> > There's a possibility this driver works as-is or with minor mods for msg2633 too,
> > and a more remote one for msg21xx and msg22xx...
> > 
> 
> Kind regards,
> Jeff LaBundy

Thank you Jeff for the insight.

Since I can't test it with any other model, I've renamed it to msg2638 in v4:
https://lore.kernel.org/linux-input/20210210173403.667482-1-vincent.knecht@mailoo.org/T/#t