Re: [PATCH v2 15/16] wl1251: Add sysfs file address for setting permanent mac address

[Ivajlo Dimitrov <ivo.g.dimitrov.75@gmail.com>]

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