From: Peter Hurley <peter@hurleysoftware.com> To: Guenter Roeck <linux@roeck-us.net> Cc: Pantelis Antoniou <pantelis.antoniou@konsulko.com>, frowand.list@gmail.com, Mark Rutland <mark.rutland@arm.com>, "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>, Tony Lindgren <tony@atomide.com>, Koen Kooi <koen@dominion.thruhere.net>, Nicolas Ferre <nicolas.ferre@atmel.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Grant Likely <grant.likely@secretlab.ca>, Ludovic Desroches <ludovic.desroches@atmel.com>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, Matt Porter <matt.porter@linaro.org> Subject: Re: [PATCH 2/4] of: DT quirks infrastructure Date: Fri, 20 Feb 2015 13:09:58 -0500 [thread overview] Message-ID: <54E77876.9020500@hurleysoftware.com> (raw) In-Reply-To: <20150220164753.GC22752@roeck-us.net> 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. 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. I'm not naysaying; I just want to elicit enough information so the community can make informed decisions. > I assume you might suggest that manufacturing should (re-)program the EEPROM > on the CPU card after it was inserted into the carrier. > > Problem is though that the CPU card may be inserted into ts carrier outside > manufacturing, at the final stages of assembly or in product repair. Those > groups would typically not even have the means to (re-)program the eeprom. > Besides, manufacturing would, quite understandably, go ballistic if we demand > that they start programming EEPROMs after insertion into carrier, and no longer > use pre-programmed EEPROMs. I agree; that would be The Wrong Way. > Note that it is not feasible to put the necessary EEPROM onto the carrier > either. Maybe in a later design. Maybe that makes sense, and we will go along > that route at some point. However, forcing a specific hardware solution > due to software limitations, ie lack of ability by core software to handle > the different carries, seems to be not the right decision to make on an > OS level. Agreed; hardware is what it is. > In the PCI world it has long since been accepted that the world is not perfect. > The argument here is pretty much equivalent to demanding that PCI drop its > quirks mechanism, to force the HW manufacturers to finally get it right from > the beginning. I somehow suspect that this won't happen. I was thinking back to the introductions of fast DEVSEL# and AGP :( > Instead of questioning the need for a mechanism such as the one proposed by > Pantelis, I think our time would be better spent arguing if it is the right > mechanism and, if not, how it can be improved. My thoughts exactly. Apologies if something I wrote came across as "You Shall Not Pass" :) One issue seems to be the moving target that is the compelling use case(s). The initial submission implied it was the Beaglebone, which comes with 4GB eMMC/microSD so naturally the argument for space-savings with DTBs doesn't fly. That has since been clarified so no need to rehash that. Regards, Peter Hurley
WARNING: multiple messages have this Message-ID (diff)
From: peter@hurleysoftware.com (Peter Hurley) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH 2/4] of: DT quirks infrastructure Date: Fri, 20 Feb 2015 13:09:58 -0500 [thread overview] Message-ID: <54E77876.9020500@hurleysoftware.com> (raw) In-Reply-To: <20150220164753.GC22752@roeck-us.net> 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. 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. I'm not naysaying; I just want to elicit enough information so the community can make informed decisions. > I assume you might suggest that manufacturing should (re-)program the EEPROM > on the CPU card after it was inserted into the carrier. > > Problem is though that the CPU card may be inserted into ts carrier outside > manufacturing, at the final stages of assembly or in product repair. Those > groups would typically not even have the means to (re-)program the eeprom. > Besides, manufacturing would, quite understandably, go ballistic if we demand > that they start programming EEPROMs after insertion into carrier, and no longer > use pre-programmed EEPROMs. I agree; that would be The Wrong Way. > Note that it is not feasible to put the necessary EEPROM onto the carrier > either. Maybe in a later design. Maybe that makes sense, and we will go along > that route at some point. However, forcing a specific hardware solution > due to software limitations, ie lack of ability by core software to handle > the different carries, seems to be not the right decision to make on an > OS level. Agreed; hardware is what it is. > In the PCI world it has long since been accepted that the world is not perfect. > The argument here is pretty much equivalent to demanding that PCI drop its > quirks mechanism, to force the HW manufacturers to finally get it right from > the beginning. I somehow suspect that this won't happen. I was thinking back to the introductions of fast DEVSEL# and AGP :( > Instead of questioning the need for a mechanism such as the one proposed by > Pantelis, I think our time would be better spent arguing if it is the right > mechanism and, if not, how it can be improved. My thoughts exactly. Apologies if something I wrote came across as "You Shall Not Pass" :) One issue seems to be the moving target that is the compelling use case(s). The initial submission implied it was the Beaglebone, which comes with 4GB eMMC/microSD so naturally the argument for space-savings with DTBs doesn't fly. That has since been clarified so no need to rehash that. Regards, Peter Hurley
next prev parent reply other threads:[~2015-02-20 18:10 UTC|newest] Thread overview: 150+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-02-18 14:59 [PATCH 0/4] Device Tree Quirks & the Beaglebone Pantelis Antoniou 2015-02-18 14:59 ` Pantelis Antoniou 2015-02-18 14:59 ` Pantelis Antoniou 2015-02-18 14:59 ` [PATCH 1/4] arm: of: Add a DT quirk method after unflattening Pantelis Antoniou 2015-02-18 14:59 ` Pantelis Antoniou 2015-02-18 14:59 ` [PATCH 2/4] of: DT quirks infrastructure Pantelis Antoniou 2015-02-18 14:59 ` Pantelis Antoniou 2015-02-18 15:41 ` Mark Rutland 2015-02-18 15:41 ` Mark Rutland 2015-02-18 15:41 ` Mark Rutland 2015-02-18 15:53 ` Pantelis Antoniou 2015-02-18 15:53 ` Pantelis Antoniou 2015-02-18 15:53 ` Pantelis Antoniou 2015-02-18 16:32 ` Ludovic Desroches 2015-02-18 16:32 ` Ludovic Desroches 2015-02-18 16:32 ` Ludovic Desroches 2015-02-18 16:39 ` Pantelis Antoniou 2015-02-18 16:39 ` Pantelis Antoniou 2015-02-18 16:39 ` Pantelis Antoniou 2015-02-18 16:47 ` Ludovic Desroches 2015-02-18 16:47 ` Ludovic Desroches 2015-02-18 16:47 ` Ludovic Desroches 2015-02-18 16:46 ` Matt Porter 2015-02-18 16:46 ` Matt Porter 2015-02-18 16:46 ` Matt Porter 2015-02-18 17:31 ` Mark Rutland 2015-02-18 17:31 ` Mark Rutland 2015-02-18 17:31 ` Mark Rutland 2015-02-18 19:32 ` Guenter Roeck 2015-02-18 19:32 ` Guenter Roeck 2015-02-18 19:32 ` Guenter Roeck 2015-02-19 14:29 ` Pantelis Antoniou 2015-02-19 14:29 ` Pantelis Antoniou 2015-02-19 14:29 ` Pantelis Antoniou 2015-02-19 16:48 ` Frank Rowand 2015-02-19 16:48 ` Frank Rowand 2015-02-19 16:48 ` Frank Rowand 2015-02-19 17:00 ` Pantelis Antoniou 2015-02-19 17:00 ` Pantelis Antoniou 2015-02-19 17:00 ` Pantelis Antoniou 2015-02-19 17:30 ` Frank Rowand 2015-02-19 17:30 ` Frank Rowand 2015-02-19 17:30 ` Frank Rowand 2015-02-19 17:38 ` Pantelis Antoniou 2015-02-19 17:38 ` Pantelis Antoniou 2015-02-19 17:38 ` Pantelis Antoniou 2015-02-19 18:01 ` Maxime Bizon 2015-02-19 18:01 ` Maxime Bizon 2015-02-19 18:01 ` Maxime Bizon 2015-02-19 18:12 ` Sylvain Rochet 2015-02-19 18:12 ` Sylvain Rochet 2015-02-19 18:12 ` Sylvain Rochet 2015-02-19 18:22 ` Maxime Bizon 2015-02-19 18:22 ` Maxime Bizon 2015-02-19 18:22 ` Maxime Bizon 2015-02-20 14:21 ` Peter Hurley 2015-02-20 14:21 ` Peter Hurley 2015-02-20 14:21 ` Peter Hurley 2015-02-20 14:35 ` Ludovic Desroches 2015-02-20 14:35 ` Ludovic Desroches 2015-02-20 14:35 ` Ludovic Desroches 2015-02-20 15:00 ` Peter Hurley 2015-02-20 15:00 ` Peter Hurley 2015-02-20 15:00 ` Peter Hurley 2015-02-20 15:02 ` Pantelis Antoniou 2015-02-20 15:02 ` Pantelis Antoniou 2015-02-20 15:02 ` Pantelis Antoniou 2015-02-20 15:24 ` Peter Hurley 2015-02-20 15:24 ` Peter Hurley 2015-02-20 15:24 ` Peter Hurley 2015-02-20 15:38 ` Pantelis Antoniou 2015-02-20 15:38 ` Pantelis Antoniou 2015-02-20 15:38 ` Pantelis Antoniou 2015-02-20 16:34 ` Peter Hurley 2015-02-20 16:34 ` Peter Hurley 2015-02-20 16:34 ` Peter Hurley 2015-02-20 16:49 ` Pantelis Antoniou 2015-02-20 16:49 ` Pantelis Antoniou 2015-02-20 16:49 ` Pantelis Antoniou 2015-02-20 17:30 ` Rob Herring 2015-02-20 17:30 ` Rob Herring 2015-02-20 17:30 ` Rob Herring 2015-02-20 17:37 ` Pantelis Antoniou 2015-02-20 17:37 ` Pantelis Antoniou 2015-02-20 17:37 ` Pantelis Antoniou 2015-02-23 7:00 ` Ludovic Desroches 2015-02-23 7:00 ` Ludovic Desroches 2015-02-23 7:00 ` Ludovic Desroches 2015-02-20 14:38 ` Pantelis Antoniou 2015-02-20 14:38 ` Pantelis Antoniou 2015-02-20 14:38 ` Pantelis Antoniou 2015-02-20 16:47 ` Guenter Roeck 2015-02-20 16:47 ` Guenter Roeck 2015-02-20 16:47 ` Guenter Roeck 2015-02-20 18:09 ` Peter Hurley [this message] 2015-02-20 18:09 ` Peter Hurley 2015-02-20 18:09 ` Peter Hurley 2015-02-20 18:48 ` Guenter Roeck 2015-02-20 18:48 ` Guenter Roeck 2015-02-20 18:48 ` Guenter Roeck 2015-02-23 7:30 ` Ludovic Desroches 2015-02-23 7:30 ` Ludovic Desroches 2015-02-23 7:30 ` Ludovic Desroches 2015-02-20 8:04 ` Ludovic Desroches 2015-02-20 8:04 ` Ludovic Desroches 2015-02-20 8:04 ` Ludovic Desroches 2015-02-19 2:08 ` Frank Rowand 2015-02-19 2:08 ` Frank Rowand 2015-02-19 14:41 ` Pantelis Antoniou 2015-02-19 14:41 ` Pantelis Antoniou 2015-02-19 16:40 ` Frank Rowand 2015-02-19 16:40 ` Frank Rowand 2015-02-19 16:51 ` Frank Rowand 2015-02-19 16:51 ` Frank Rowand 2015-02-19 16:51 ` Frank Rowand 2015-02-20 13:23 ` Peter Hurley 2015-02-20 13:23 ` Peter Hurley 2015-02-19 18:01 ` Rob Herring 2015-02-19 18:01 ` Rob Herring 2015-02-19 18:01 ` Rob Herring 2015-02-19 18:12 ` Guenter Roeck 2015-02-19 18:12 ` Guenter Roeck 2015-02-19 18:12 ` Guenter Roeck 2015-02-20 8:16 ` Ludovic Desroches 2015-02-20 8:16 ` Ludovic Desroches 2015-02-20 8:16 ` Ludovic Desroches 2015-02-18 14:59 ` [PATCH 3/4] arm: am33xx: DT quirks for am33xx based beaglebone variants Pantelis Antoniou 2015-02-18 14:59 ` Pantelis Antoniou 2015-02-19 18:16 ` Tony Lindgren 2015-02-19 18:16 ` Tony Lindgren 2015-02-19 18:16 ` Tony Lindgren 2015-02-19 18:28 ` Pantelis Antoniou 2015-02-19 18:28 ` Pantelis Antoniou 2015-02-19 18:36 ` Tony Lindgren 2015-02-19 18:36 ` Tony Lindgren 2015-02-19 18:36 ` Tony Lindgren 2015-02-19 18:44 ` Pantelis Antoniou 2015-02-19 18:44 ` Pantelis Antoniou 2015-02-19 18:44 ` Pantelis Antoniou 2015-02-23 18:39 ` Peter Hurley 2015-02-23 18:39 ` Peter Hurley 2015-02-23 18:48 ` Pantelis Antoniou 2015-02-23 18:48 ` Pantelis Antoniou 2015-02-19 18:57 ` Guenter Roeck 2015-02-19 18:57 ` Guenter Roeck 2015-02-20 16:13 ` Jon Hunter 2015-02-20 16:13 ` Jon Hunter 2015-02-18 14:59 ` [PATCH 4/4] arm: dts: Common Black/White Beaglebone DTS using quirks Pantelis Antoniou 2015-02-18 14:59 ` Pantelis Antoniou 2015-02-18 14:59 ` Pantelis Antoniou
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=54E77876.9020500@hurleysoftware.com \ --to=peter@hurleysoftware.com \ --cc=devicetree@vger.kernel.org \ --cc=frowand.list@gmail.com \ --cc=grant.likely@secretlab.ca \ --cc=koen@dominion.thruhere.net \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux@roeck-us.net \ --cc=ludovic.desroches@atmel.com \ --cc=mark.rutland@arm.com \ --cc=matt.porter@linaro.org \ --cc=nicolas.ferre@atmel.com \ --cc=pantelis.antoniou@konsulko.com \ --cc=tony@atomide.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.