Re: [PATCH v2] of_net: Implement of_get_nvmem_mac_address helper

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 26-03-18 19:05, Florian Fainelli wrote:
On 03/26/2018 09:58 AM, David Miller wrote:
From: Mike Looijmans <mike.looijmans@xxxxxxxx>
Date: Mon, 26 Mar 2018 08:41:29 +0200

It's common practice to store MAC addresses for network interfaces into
nvmem devices. However the code to actually do this in the kernel lacks,
so this patch adds of_get_nvmem_mac_address() for drivers to obtain the
address from an nvmem cell provider.

This is particulary useful on devices where the ethernet interface cannot
be configured by the bootloader, for example because it's in an FPGA.

Tested by adapting the cadence macb driver to call this instead of
of_get_mac_address().

Signed-off-by: Mike Looijmans <mike.looijmans@xxxxxxxx>
---
v2: Use of_nvmem_cell_get to avoid needing the assiciated device
     Use void* instead of char*
     Add devicetree binding doc

Like Andrew, I think you should add a new interface for getting the MAC
address from nvmem.

And drivers can call both of them if they want OF device tree and
NVMEM probing for MAC addresses.

Later you can add a consolidated interface, if necessary, which does
both and also take a reference to the MAC address buffer of the driver
in order to deal with the resource allocation issues.

Agreed, also, how does this fit with Alban's patch series here:

Ok, makes sense. I'll cook up a v3.


https://lkml.org/lkml/2018/3/24/312

do you depend on those changes at all?


As far as I can tell, there's no dependency, I'm adding an nvmem "consumer" while Alban's patch adds a "provider". I'm mainly interested in storing the MAC address into an I2C EEPROM, which you can also buy with a pre-programmed MAC address in the first 6 bytes, so there's no production cost for managing that.


Alban's patch might some day collide with my idea of making hardware that has some unique ID into nvmem providers, like 1-wire chips, some NOR flash chips (there's the conflict) and various other devices. That would allow a board to obtain a random yet constant MAC address without any additional hardware. I'll cross that bridge when I find it.


--
Mike Looijmans
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux