From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752895AbbBTSsm (ORCPT ); Fri, 20 Feb 2015 13:48:42 -0500 Received: from bh-25.webhostbox.net ([208.91.199.152]:43303 "EHLO bh-25.webhostbox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751005AbbBTSsk (ORCPT ); Fri, 20 Feb 2015 13:48:40 -0500 Date: Fri, 20 Feb 2015 10:48:18 -0800 From: Guenter Roeck To: Peter Hurley Cc: Pantelis Antoniou , frowand.list@gmail.com, Mark Rutland , "devicetree@vger.kernel.org" , Tony Lindgren , Koen Kooi , Nicolas Ferre , "linux-kernel@vger.kernel.org" , Grant Likely , Ludovic Desroches , "linux-arm-kernel@lists.infradead.org" , Matt Porter Subject: Re: [PATCH 2/4] of: DT quirks infrastructure Message-ID: <20150220184818.GC26698@roeck-us.net> References: <20150218173115.GG29429@leverpostej> <76BD1B22-BAED-4205-9B34-186907CE0217@konsulko.com> <54E613E7.2020405@gmail.com> <670D0881-DBF0-45E8-A502-A6DB2B77A750@konsulko.com> <54E61DD2.3060002@gmail.com> <53F2F94C-0C43-4A54-B8CD-EEC454A0AC19@konsulko.com> <54E742F2.80506@hurleysoftware.com> <20150220164753.GC22752@roeck-us.net> <54E77876.9020500@hurleysoftware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54E77876.9020500@hurleysoftware.com> 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.0A020201.54E78187.02EA,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: 9 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 Fri, Feb 20, 2015 at 01:09:58PM -0500, Peter Hurley wrote: > Hi Guenter, > > On 02/20/2015 11:47 AM, Guenter Roeck wrote: > > [...] > > > I am open to hearing your suggestions for our use case, where the CPU card with > > the eeprom is manufactured separately from its carier cards. > > I think your use case may be more compelling than two flavors of Beaglebone > (one of which is pretty much a dead stick), but it's also less clear what your > design constraints are (not that I really want to know, 'cause I don't). > > But the logical extension of this is an N-way dtb that supports unrelated SOCs, > and I think most would agree that's not an acceptable outcome. > With this logic you can pretty much refuse to accept anything new, anywhere. Including everything old, for that matter. Food can be abused to poison people, therefore no one should be permitted to distribute food. Houses can be abused to falsely imprison people, therefore no one should live in houses. And don't even start talking about guns. Everything can be abused, therefore we should not do anything. Discussions about possible abuse are for sure valid, and reducing the potential for abuse is a worthy goal, but not as argument to reject a solution for an existing and real roblem outright. > My thought was that every design that can afford an EEPROM to probe can afford > a bootloader to select the appropriate dtb, and can afford the extra space > required for multiple dtbs. > There are many more use cases where this is simply not the case. Another one, for example, is a system where the devicetree is loaded through u-boot using tftp. In this case, u-boot would have some information about the hardware to request the correct devicetree file, but it may not know about hardware variants. Sure, one could solve that problem by making u-boot aware of such variants and maintaining a large number of dtb files as you suggest. That means, however, that there would be that need to maintain all those dtb files just to address minor differences, and having modify every piece of the system for each new variant. In essence you put a lot of burden on pretty much everyone from software to manufacturing to testing, plus possibly hardware, just for the purpose of rejecting a relatively simple solution for the problem Pantelis' patch set is trying to address. Ultimately, no matter what the kernel community ends up doing, Pantelis' solution or something similar _will_ find its way into our system. I would very much prefer to have the code upstream, but we will carry his patches along in our vendor branch if necessary. The functionality and its benefits for our development, manufacturing, and testing process are way too valuable to ignore, and it actually solves problems for which we don't have an acceptable solution today. I would be quite surprised if other vendors would not end up doing the same. Guenter From mboxrd@z Thu Jan 1 00:00:00 1970 From: Guenter Roeck Subject: Re: [PATCH 2/4] of: DT quirks infrastructure Date: Fri, 20 Feb 2015 10:48:18 -0800 Message-ID: <20150220184818.GC26698@roeck-us.net> References: <20150218173115.GG29429@leverpostej> <76BD1B22-BAED-4205-9B34-186907CE0217@konsulko.com> <54E613E7.2020405@gmail.com> <670D0881-DBF0-45E8-A502-A6DB2B77A750@konsulko.com> <54E61DD2.3060002@gmail.com> <53F2F94C-0C43-4A54-B8CD-EEC454A0AC19@konsulko.com> <54E742F2.80506@hurleysoftware.com> <20150220164753.GC22752@roeck-us.net> <54E77876.9020500@hurleysoftware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <54E77876.9020500-WaGBZJeGNqdsbIuE7sb01tBPR1lH4CV8@public.gmane.org> Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Peter Hurley Cc: Pantelis Antoniou , frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, Mark Rutland , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Tony Lindgren , Koen Kooi , Nicolas Ferre , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Grant Likely , Ludovic Desroches , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" , Matt Porter List-Id: devicetree@vger.kernel.org On Fri, Feb 20, 2015 at 01:09:58PM -0500, Peter Hurley wrote: > Hi Guenter, > > On 02/20/2015 11:47 AM, Guenter Roeck wrote: > > [...] > > > I am open to hearing your suggestions for our use case, where the CPU card with > > the eeprom is manufactured separately from its carier cards. > > I think your use case may be more compelling than two flavors of Beaglebone > (one of which is pretty much a dead stick), but it's also less clear what your > design constraints are (not that I really want to know, 'cause I don't). > > But the logical extension of this is an N-way dtb that supports unrelated SOCs, > and I think most would agree that's not an acceptable outcome. > With this logic you can pretty much refuse to accept anything new, anywhere. Including everything old, for that matter. Food can be abused to poison people, therefore no one should be permitted to distribute food. Houses can be abused to falsely imprison people, therefore no one should live in houses. And don't even start talking about guns. Everything can be abused, therefore we should not do anything. Discussions about possible abuse are for sure valid, and reducing the potential for abuse is a worthy goal, but not as argument to reject a solution for an existing and real roblem outright. > My thought was that every design that can afford an EEPROM to probe can afford > a bootloader to select the appropriate dtb, and can afford the extra space > required for multiple dtbs. > There are many more use cases where this is simply not the case. Another one, for example, is a system where the devicetree is loaded through u-boot using tftp. In this case, u-boot would have some information about the hardware to request the correct devicetree file, but it may not know about hardware variants. Sure, one could solve that problem by making u-boot aware of such variants and maintaining a large number of dtb files as you suggest. That means, however, that there would be that need to maintain all those dtb files just to address minor differences, and having modify every piece of the system for each new variant. In essence you put a lot of burden on pretty much everyone from software to manufacturing to testing, plus possibly hardware, just for the purpose of rejecting a relatively simple solution for the problem Pantelis' patch set is trying to address. Ultimately, no matter what the kernel community ends up doing, Pantelis' solution or something similar _will_ find its way into our system. I would very much prefer to have the code upstream, but we will carry his patches along in our vendor branch if necessary. The functionality and its benefits for our development, manufacturing, and testing process are way too valuable to ignore, and it actually solves problems for which we don't have an acceptable solution today. I would be quite surprised if other vendors would not end up doing the same. Guenter -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 From: linux@roeck-us.net (Guenter Roeck) Date: Fri, 20 Feb 2015 10:48:18 -0800 Subject: [PATCH 2/4] of: DT quirks infrastructure In-Reply-To: <54E77876.9020500@hurleysoftware.com> References: <20150218173115.GG29429@leverpostej> <76BD1B22-BAED-4205-9B34-186907CE0217@konsulko.com> <54E613E7.2020405@gmail.com> <670D0881-DBF0-45E8-A502-A6DB2B77A750@konsulko.com> <54E61DD2.3060002@gmail.com> <53F2F94C-0C43-4A54-B8CD-EEC454A0AC19@konsulko.com> <54E742F2.80506@hurleysoftware.com> <20150220164753.GC22752@roeck-us.net> <54E77876.9020500@hurleysoftware.com> Message-ID: <20150220184818.GC26698@roeck-us.net> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Fri, Feb 20, 2015 at 01:09:58PM -0500, Peter Hurley wrote: > Hi Guenter, > > On 02/20/2015 11:47 AM, Guenter Roeck wrote: > > [...] > > > I am open to hearing your suggestions for our use case, where the CPU card with > > the eeprom is manufactured separately from its carier cards. > > I think your use case may be more compelling than two flavors of Beaglebone > (one of which is pretty much a dead stick), but it's also less clear what your > design constraints are (not that I really want to know, 'cause I don't). > > But the logical extension of this is an N-way dtb that supports unrelated SOCs, > and I think most would agree that's not an acceptable outcome. > With this logic you can pretty much refuse to accept anything new, anywhere. Including everything old, for that matter. Food can be abused to poison people, therefore no one should be permitted to distribute food. Houses can be abused to falsely imprison people, therefore no one should live in houses. And don't even start talking about guns. Everything can be abused, therefore we should not do anything. Discussions about possible abuse are for sure valid, and reducing the potential for abuse is a worthy goal, but not as argument to reject a solution for an existing and real roblem outright. > My thought was that every design that can afford an EEPROM to probe can afford > a bootloader to select the appropriate dtb, and can afford the extra space > required for multiple dtbs. > There are many more use cases where this is simply not the case. Another one, for example, is a system where the devicetree is loaded through u-boot using tftp. In this case, u-boot would have some information about the hardware to request the correct devicetree file, but it may not know about hardware variants. Sure, one could solve that problem by making u-boot aware of such variants and maintaining a large number of dtb files as you suggest. That means, however, that there would be that need to maintain all those dtb files just to address minor differences, and having modify every piece of the system for each new variant. In essence you put a lot of burden on pretty much everyone from software to manufacturing to testing, plus possibly hardware, just for the purpose of rejecting a relatively simple solution for the problem Pantelis' patch set is trying to address. Ultimately, no matter what the kernel community ends up doing, Pantelis' solution or something similar _will_ find its way into our system. I would very much prefer to have the code upstream, but we will carry his patches along in our vendor branch if necessary. The functionality and its benefits for our development, manufacturing, and testing process are way too valuable to ignore, and it actually solves problems for which we don't have an acceptable solution today. I would be quite surprised if other vendors would not end up doing the same. Guenter