From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753261AbbBRTdZ (ORCPT ); Wed, 18 Feb 2015 14:33:25 -0500 Received: from bh-25.webhostbox.net ([208.91.199.152]:52568 "EHLO bh-25.webhostbox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752505AbbBRTdX (ORCPT ); Wed, 18 Feb 2015 14:33:23 -0500 Date: Wed, 18 Feb 2015 11:32:38 -0800 From: Guenter Roeck To: Mark Rutland Cc: Pantelis Antoniou , Grant Likely , Matt Porter , Koen Kooi , Ludovic Desroches , Rob Herring , Tony Lindgren , Nicolas Ferre , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" Subject: Re: [PATCH 2/4] of: DT quirks infrastructure Message-ID: <20150218193238.GA32179@roeck-us.net> References: <1424271576-1952-1-git-send-email-pantelis.antoniou@konsulko.com> <1424271576-1952-3-git-send-email-pantelis.antoniou@konsulko.com> <20150218154106.GC29429@leverpostej> <20150218173115.GG29429@leverpostej> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150218173115.GG29429@leverpostej> User-Agent: Mutt/1.5.23 (2014-03-12) X-Authenticated_sender: guenter@roeck-us.net X-OutGoing-Spam-Status: No, score=-1.0 X-CTCH-PVer: 0000001 X-CTCH-Spam: Unknown X-CTCH-VOD: Unknown X-CTCH-Flags: 0 X-CTCH-RefID: str=0001.0A020206.54E4E903.0045,ss=1,re=0.001,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0 X-CTCH-Score: 0.001 X-CTCH-ScoreCust: 0.000 X-CTCH-Rules: C_4847, X-CTCH-SenderID: linux@roeck-us.net X-CTCH-SenderID-Flags: 0 X-CTCH-SenderID-TotalMessages: 11 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-TotalRecipients: 0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - bh-25.webhostbox.net X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - roeck-us.net X-Get-Message-Sender-Via: bh-25.webhostbox.net: mailgid no entry from get_relayhosts_entry X-Source: X-Source-Args: X-Source-Dir: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Guenter Roeck Subject: Re: [PATCH 2/4] of: DT quirks infrastructure Date: Wed, 18 Feb 2015 11:32:38 -0800 Message-ID: <20150218193238.GA32179@roeck-us.net> References: <1424271576-1952-1-git-send-email-pantelis.antoniou@konsulko.com> <1424271576-1952-3-git-send-email-pantelis.antoniou@konsulko.com> <20150218154106.GC29429@leverpostej> <20150218173115.GG29429@leverpostej> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20150218173115.GG29429@leverpostej> Sender: linux-kernel-owner@vger.kernel.org To: Mark Rutland Cc: Pantelis Antoniou , Grant Likely , Matt Porter , Koen Kooi , Ludovic Desroches , Rob Herring , Tony Lindgren , Nicolas Ferre , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" List-Id: devicetree@vger.kernel.org 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: linux@roeck-us.net (Guenter Roeck) Date: Wed, 18 Feb 2015 11:32:38 -0800 Subject: [PATCH 2/4] of: DT quirks infrastructure In-Reply-To: <20150218173115.GG29429@leverpostej> References: <1424271576-1952-1-git-send-email-pantelis.antoniou@konsulko.com> <1424271576-1952-3-git-send-email-pantelis.antoniou@konsulko.com> <20150218154106.GC29429@leverpostej> <20150218173115.GG29429@leverpostej> Message-ID: <20150218193238.GA32179@roeck-us.net> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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