linux-kernel - Re: [PATCH v1 2/2] arm: dts: mt2701: add nor flash node

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: <20170119085303.24b8d462@bbrezillon>
Date:   Thu, 19 Jan 2017 08:53:03 +0100
From:   Boris Brezillon <boris.brezillon@...e-electrons.com>
To:     Rob Herring <robh@...nel.org>
Cc:     Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
        Marek Vasut <marek.vasut@...il.com>,
        Mark Rutland <mark.rutland@....com>,
        devicetree@...r.kernel.org, Guochun Mao <guochun.mao@...iatek.com>,
        Richard Weinberger <richard@....at>,
        Russell King <linux@...linux.org.uk>,
        linux-kernel@...r.kernel.org, linux-mtd@...ts.infradead.org,
        Matthias Brugger <matthias.bgg@...il.com>,
        linux-mediatek@...ts.infradead.org,
        Cyrille Pitchen <cyrille.pitchen@...el.com>,
        Brian Norris <computersforpeace@...il.com>,
        David Woodhouse <dwmw2@...radead.org>,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v1 2/2] arm: dts: mt2701: add nor flash node

On Wed, 18 Jan 2017 16:20:10 -0600
Rob Herring <robh@...nel.org> wrote:

> On Tue, Jan 17, 2017 at 02:36:50PM +1100, Thomas Petazzoni wrote:
> > Hello,
> > 
> > (Side note: you guys should learn about stripping irrelevant parts of
> > an e-mail when replying!)
> >
> > On Mon, 16 Jan 2017 09:40:32 +0100, Boris Brezillon wrote:
> >   
> > > > Well this is OK I guess, but then you can also use "mediatek,mt8173-nor"
> > > > as the oldest supported compatible and be done with it, no ? It looks a
> > > > bit crappy though, I admit that ...  
> > > 
> > > Let's stop bikeshedding and wait for DT maintainers feedback
> > > before taking a decision ;-).
> > > 
> > > Rob, Mark, any opinion?  
> >  
> 
> Sigh, is how to do compatibles really not yet understood?

Apparently not, and I fear this is not the last misunderstanding on my
side ;-).

>  
> > I agree that a clarification would be good. There are really two
> > options:
> > 
> >  1. Have two compatible strings in the DT, the one that matches the
> >     exact SoC where the IP is found (first compatible string) and the
> >     one that matches some other SoC where the same IP is found (second
> >     compatible string). Originally, Linux only supports the second
> >     compatible string in its device driver, but if it happens that a
> >     difference is found between two IPs that we thought were the same,
> >     we can add support for the first compatible string in the driver,
> >     with a slightly different behavior.  
> 
> This. And no wildcards in the compatible string. 
> 
> >  2. Have a single compatible string in the DT, matching the exact SoC
> >     where the IP is found. This involves adding immediately this
> >     compatible string in the corresponding driver.  
> 
> I wouldn't object to this from a DT perspective as I have no clue 
> generally if IP blocks are "the same" or not. Subsystem maintainers will 
> object though.
> 
> > I've not really been able to figure out which of the two options is the
> > most future-proof/appropriate.  
> 
> They are both future-proof. #2 has the disadvantage of requiring a 
> kernel update for a new SoC. 
> 
> Rob