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: <20180125153520.lxcfvh3yvi36uiux@flea.lan>
Date:   Thu, 25 Jan 2018 16:35:20 +0100
From:   Maxime Ripard <maxime.ripard@...e-electrons.com>
To:     Icenowy Zheng <icenowy@...c.io>
Cc:     linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
        linux-sunxi@...glegroups.com, Marc Zyngier <marc.zyngier@....com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        Russell King <linux@...linux.org.uk>,
        linux-kernel@...r.kernel.org, linux-gpio@...r.kernel.org,
        Chen-Yu Tsai <wens@...e.org>, linux-clk@...r.kernel.org
Subject: Re: [RFC PATCH 0/9] initial support for "suniv" Allwinner new ARM9
 SoC

Hi,

On Wed, Jan 24, 2018 at 09:10:34PM +0800, Icenowy Zheng wrote:
> 在 2018年1月22日星期一 CST 下午8:14:35,Maxime Ripard 写道:
> > On Sat, Jan 20, 2018 at 07:17:26AM +0800, Icenowy Zheng wrote:
> > > This is the RFC initial patchset for the "new" Allwinner SUNIV ARM9 SoC.
> > > 
> > > The same die is packaged differently, come with different co-packaged
> > > DRAM or shipped with different SDK; and then made many model names: F23,
> > > F25, F1C100A, F1C100S, F1C200S, F1C500, F1C600, R6, etc. These SoCs all
> > > share a common feature set and are packaged similarly (eLQFP128 for SoCs
> > > without co-packaged DRAM, QFN88 for with DRAM). As their's no
> > > functionality hidden on the QFN88 models (except DRAM interface not
> > > exported), it's not clever to differentiate them. So I will use suniv as
> > > common name of all these SoCs.
> > 
> > Where is that suniv prefix coming from?
> 
> The BSP (Melis and Linux). (e.g. "libs/suniv" directory of the Melis SDK and 
> "arch/arm/boot/dts/sunivw1p1.dtsi" in the Linux SDK)

Do you have a link to that BSP?

> > You should really answer two questions here:
> >   - Are you able to predict whether you'll find an SoC part of that
> >     family in the future that derives a bit and will need a compatible
> >     of its own?
> >   - Are you able to predict which quirks we'll need along the way to
> >     support all the SoCs you've listed there?
> > 
> > If you can't answer yes to both these questions, with a 100%
> > certainty, then you'll need a SoC name in the compatible.
> > 
> > Which doesn't prevent you from sharing as much as possible the DT like
> > we did between the A10s and the A13 for example.
> 
> So the suniv-f1c100s.dtsi will still be kept empty and all peripherals known 
> should go through suniv.dtsi.

Sorry if I wasn't really clear. You can totally keep the current DT
structure if that makes sense (and judging by what you're saying, it
does.), but the compatibles should have the SoC name in it.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ