linux-kernel - Re: [PATCH 2/4] of: DT quirks infrastructure

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: <20150218193238.GA32179@roeck-us.net>
Date:	Wed, 18 Feb 2015 11:32:38 -0800
From:	Guenter Roeck <linux@...ck-us.net>
To:	Mark Rutland <mark.rutland@....com>
Cc:	Pantelis Antoniou <pantelis.antoniou@...sulko.com>,
	Grant Likely <grant.likely@...retlab.ca>,
	Matt Porter <matt.porter@...aro.org>,
	Koen Kooi <koen@...inion.thruhere.net>,
	Ludovic Desroches <ludovic.desroches@...el.com>,
	Rob Herring <robherring2@...il.com>,
	Tony Lindgren <tony@...mide.com>,
	Nicolas Ferre <nicolas.ferre@...el.com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 2/4] of: DT quirks infrastructure

On Wed, Feb 18, 2015 at 05:31:16PM +0000, Mark Rutland wrote:
> > >> +While this may in theory work, in practice it is very cumbersome
> > >> +for the following reasons:
> > >> +
> > >> +1. The act of selecting a different boot device tree blob requires
> > >> +a reasonably advanced bootloader with some kind of configuration or
> > >> +scripting capabilities. Sadly this is not the case many times, the
> > >> +bootloader is extremely dumb and can only use a single dt blob.
> > > 
> > > You can have several bootloader builds, or even a single build with
> > > something like appended DTB to get an appropriate DTB if the same binary
> > > will otherwise work across all variants of a board.
> > > 
> > 
> > No, the same DTB will not work across all the variants of a board.
> 
> I wasn't on about the DTB. I was on about the loader binary, in the case
> the FW/bootloader could be common even if the DTB couldn't.
> 
> To some extent there must be a DTB that will work across all variants
> (albeit with limited utility) or the quirk approach wouldn't work...
> 

Not necessarily. I have another use case: A cpu card can be plugged into
multiple carrier card variants, each with different functionality.
At production time, it is not known which carrier card the CPU card
will be plugged in. It is not feasible for manufacturing to update
the dtb files after the cpu card has been plugged into the carrier,
since both are manufactured separately and plugged together at a
later step in the production process (and may be swapped around later).

External overlays do not work in this case because those have to be loaded
through the carrier card. A common dtb file as proposed here would be an
elegant solution for that problem.

Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/