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 for Android: free password hash cracker in your pocket

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

Message-ID: <20191024014731.GA3731@goma>
Date:   Thu, 24 Oct 2019 10:47:33 +0900
From:   Daniel Palmer <daniel@...f.com>
To:     Rob Herring <robh@...nel.org>
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 06:45:29PM -0500, Rob Herring wrote:
> > 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.

Will do.

> 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.

You can take one chip off and swap it with the other without any PCB/component
changes but as I've been working on both chips there are a few differences
coming up that means you can't use the same DT for both configurations.
For example the ethernet phy needs to be configured differently, the i1
SoC has less instances of the DMA controller blocks and so on.

The version of the chip can be detected from a register and I had considered
patching over the differences based on that but I couldn't find an example
of doing it within the kernel. So I'm detecting the chip version in u-boot and
loading the right DT there.

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

I had initially done that when I thought i1 was the msc31e and i3 was the
msc313e. For the i1 the only part I have found so far is the msc313 but
the i3 is a series of around 4 or 5 different configurations of the same SoC 
with differing amounts of DDR and pins. This is like the AllWinner V3S and 
S3/S3L where the same V3 SoC is packaged differently. As there is no source
of this information that appears on a google search I've started documenting
it at http://linux-chenxing.org/

I think the only place the actual chip model will need to be used will be a
compatible string for the pinctrl driver to setup the right pin numbers.

Thanks,

Daniel