From mboxrd@z Thu Jan 1 00:00:00 1970 From: jason@lakedaemon.net (Jason Cooper) Date: Tue, 8 Jul 2014 08:10:10 -0400 Subject: [GIT PULL] ARM: mvebu: DT changes for v3.17 In-Reply-To: <53B116C6.80601@gmail.com> References: <20140627130129.GH23978@titan.lakedaemon.net> <20140627130430.GH32514@n2100.arm.linux.org.uk> <53AD724D.4020704@gmail.com> <20140627133933.GJ23978@titan.lakedaemon.net> <53AD7544.2060701@gmail.com> <53ADAB8C.6070609@gmail.com> <20140628145424.GK23978@titan.lakedaemon.net> <53B116C6.80601@gmail.com> Message-ID: <20140708121010.GT23978@titan.lakedaemon.net> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Sebastian, On Mon, Jun 30, 2014 at 09:50:30AM +0200, Sebastian Hesselbarth wrote: > On 06/28/2014 04:54 PM, Jason Cooper wrote: > > On Fri, Jun 27, 2014 at 07:36:12PM +0200, Sebastian Hesselbarth wrote: > >> On 06/27/2014 06:49 PM, Jason Cooper wrote: > >>>> On Jun 27, 2014, at 9:44, Sebastian Hesselbarth wrote: > >>> ... > >>>> And I am not sure, if we want to rely on some six numbers stored on > >>>> SPI flash, i.e. there is no magic nor header to be really sure, it > >>>> is a MAC address. > >>> > >>> It couldn't be compared with the MAC address of the nic? > >> > >> Sure, but if it is not equal it tells you nothing. > >> > >> You can change the NICs MAC in your bootloader, it will be different > >> from the numbers you read from SPI, and some mechanism will assume you > >> just made your production version into ES. > >> > >> We really want to introduce such a crutch? > > > > Well, we need to keep in mind distro's concerns, but we don't need to > > (and shouldn't) attempt to solve them. > > > > That's why I wanted to add a comment expressing the facts as best we > > know them. We could also now add a link to this thread to assist future > > distro maintainers. > > > > As this patch sits, it is an accurate description of the two variants of > > dove-based CuBoxes. The fact that SolidRun didn't leave a clear > > differentiator is unfortunate, but we can't magic a solution out of our > > ass. Nor should we block a patch because we can't. > > Ok, I'll look through my eMails and Web again to collect some > differences and prepare a "add comment" only patch for the CuBox DTSs. No rush, just a gentle ping. ;-) > > It also might be worth reaching out to Rabeeh one more time and asking > > explicitly if there is a programmatic way to differentiate the two > > boards on the board itself. > > Yeah, I remember someone said that there is a different SPI vendor on > production CuBox. That could be a way to tell them apart _if_ it is > used exclusively on production boxes. > > But I'll ask Rabeeh about it again. any word from Rabeeh? thx, Jason.