[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 12 Dec 2013 22:24:18 +0200
From: Ivajlo Dimitrov <ivo.g.dimitrov.75@...il.com>
To: Ben Hutchings <bhutchings@...arflare.com>,
Dan Williams <dcbw@...hat.com>
CC: Ivajlo Dimitrov <ivo.g.dimitrov.75@...il.com>,
Pali Rohár
<pali.rohar@...il.com>, Kalle Valo <kvalo@...rom.com>,
Luciano Coelho <luca@...lho.fi>,
"John W. Linville" <linville@...driver.com>,
linux-wireless@...r.kernel.org, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, freemangordon@....bg,
aaro.koskinen@....fi, pavel@....cz, sre@...g0.de,
joni.lapilainen@...il.com,
Johannes Berg <johannes@...solutions.net>,
Felipe Contreras <felipe.contreras@...il.com>
Subject: Re: [PATCH v2 15/16] wl1251: Add sysfs file address for setting permanent
mac address
On 12.12.2013 21:55, Ben Hutchings wrote:
> On Wed, 2013-12-11 at 16:53 -0600, Dan Williams wrote:
>> On Wed, 2013-12-11 at 22:15 +0000, Ben Hutchings wrote:
>>> On Wed, 2013-12-11 at 23:35 +0200, Ivajlo Dimitrov wrote:
>>>> On 11.12.2013 23:17, Ben Hutchings wrote:
>>>>> I think that's an even worse idea. This is not firmware and it already
>>>>> exists in separate storage.
>>>>>
>>>>> I think that rx51_init_wl1251() in
>>>>> arch/arm/mach-omap2/board-rx51-peripherals.c should either copy the MAC
>>>>> address out of NVRAM, or if it's too early to do that, then schedule a
>>>>> function to run later and only then set up wl1251 platform data.
>>>>>
>>>>> Ben.
>>>>>
>>>> And how will that work with DT when board files will be in the history?
>>> 1. Boot loader reads the MAC address from NVRAM and puts it in the DT
>>> node.
>>> or
>>> 2. NVRAM reading is done by a tiny driver that is loaded based on the
>>> platform name and updates the DT node in memory. (But I don't know how
>>> wl1251 should decide to defer probing if it's probed before that other
>>> driver.)
>> I'm uncomfortable with it too, and yes the permanent MAC should really
>> be known before the interface is even registered, but...
>>
>> Imagine if the MAC address for your ethernet device was stored
>> in /etc/my-mac-addr.txt, except that /etc was a read-only protected
>> partition from a very small SSD. That's essentially the N900; it's
>> stored in a file in a normal ext2/ext3 (?) filesystem on a partition of
>> the internal flash.
> Oh, from my quick look I got the impression that this 'CAL' was stored
> directly in a specific flash partition.
>
>> It seems like overkill to write a small driver that
>> duplicates the ext3 + MTD drivers just to read the MAC.
> [...]
>
> I don't see that anything would need to be duplicated. But reading
> files from the kernel is really ugly, and deciding when to read the file
> would be another problem (as you noted).
>
> Ben
>
Yes, CAL is stored in /dev/mtd1, a dedicated partition in the NAND
flash. But reading the data stored in it from the kernel is not a
trivial task, as it uses its own pseudo-fs format etc. Not impossible (I
RE-ed libcal a while ago [0], so there is a code that could be reused,
calvaria works too afaik), but still doesn't sound like a very good idea.
[0]
https://gitorious.org/community-ssu/libcal/source/d4c5fd9293ddb693c9b032b4c084cd0343b3ea26:
Ivo
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists