linux-kernel - Re: [PATCH 1/4] dt-bindings: arm: Initial MStar vendor prefixes and compatible strings

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]

Date:   Wed, 23 Oct 2019 18:45:29 -0500
From:   Rob Herring <robh@...nel.org>
To:     Daniel Palmer <daniel@...f.com>
Cc:     "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" 
        <linux-arm-kernel@...ts.infradead.org>, devicetree@...r.kernel.org,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/4] dt-bindings: arm: Initial MStar vendor prefixes and
 compatible strings

On Wed, Oct 23, 2019 at 5:44 PM Daniel Palmer <daniel@...f.com> wrote:
>
> On Wed, Oct 23, 2019 at 03:02:28PM -0500, Rob Herring wrote:
> > > +# SPDX-License-Identifier: (GPL-2.0+ OR X11)
> >
> > (GPL-2.0-only OR BSD-2-Clause) is preferred. Any reason to differ?
>
> I used the sunxi file as a template and thought they had some
> reason to do that. I'll change it to just GPL-2.0.

That wasn't a choice, but dual license it please.

> > > +      - description: thingy.jp BreadBee
> > > +        items:
> > > +          - const: thingyjp,breadbee
> > > +          - const: mstar,infinity
> > > +          - const: mstar,infinity3
> >
> > infinity vs. infinity3? What's the difference? It's generally sufficient
> > to just list a board compatible and a SoC compatible.
>
> Apart from some very slight differences (max clock speed, different PWM block)
> they are the same and the PCB for the BreadBee can take either the msc313(i1) or
> msc313e(i3). My v2 patch will remove the mstar,infinity line from there and move
> it to a second board called the breadbee-crust to handle the i1 configuration.

Sounds like you want:

items:
 - const: thingyjp,breadbee
 - enum:
     - mstar,infinity
     - mstar,infinity3

If one board can do both chips. Though if the same PCB is populated
differently beyond the SoC, then maybe 2 board compatibles makes
sense.

Why not use the part numbers (msc313...)?

Rob