Re: [PATCH] of_net: add mtd-mac-address support to of_get_mac_address()

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

 



On Wed, Apr 17, 2019 at 06:06:00PM +0200, Petr Štetiar wrote:
> Maxime Ripard <maxime.ripard@xxxxxxxxxxx> [2019-04-17 10:06:14]:
>
> > NVMEM is supported by of_net already
>
> Well, not anymore:
>
>  commit afa64a72b862a7a9d04f8d07fba632eaf06b23f8
>  Author: Bartosz Golaszewski <bgolaszewski@xxxxxxxxxxxx>
>  Date:   Fri Nov 30 09:20:59 2018 +0100
>
>     of: net: kill of_get_nvmem_mac_address()
>
> Now, I'm really confused.
>
> Documentation/devicetree/bindings/net/ethernet.txt states following:
>
>  - nvmem-cells: phandle, reference to an nvmem node for the MAC address;
>  - nvmem-cell-names: string, should be "mac-address" if nvmem is to be used;
>
> which is actually misleading and confusing. There are only two ethernet
> drivers in the tree cadence and davinci which support this properties. Well
> there's nixge, but this one is special, because it has renamed `mac-address`
> to `address` with it's own implementation in `nixge_get_nvmem_address`.
>
> All other ethernet drivers (and few others) simply use `of_get_mac_address`
> which doesn't support NVMEM and the documented nvmem-cells* properties.
>
> > so it doesn't look really necessary to create additional properties that
> > cover the same use case.
>
> NVMEM could be reused for this purpose and it seems like a way to go, probably
> if we could wire `nvmem_get_mac_address` into `of_get_mac_address` and find a
> way how to handle the remaining use cases currently not handled in NVMEM:
>
>  * MAC address (octet/byte) incrementation (already handled by the proposed patch)
>  * MAC address stored as ascii/text (0090FEC9CBE4 and 00:90:FE:C9:CB:E4
>    formats) which is currently missing but would be nice to have
>
> I can prepare patches for that, just don't want to waste more time then really
> necessary, so it would really help me if someone could tell me how this should
> be implemented in NVMEM and I'll simply do it in this acceptable way and call
> it a day.

Just send whatever you have in mind with the nvmem developpers as
recepients. They are not in this thread, so I'm not sure we can point
you in the direction they want

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Attachment: signature.asc
Description: PGP signature


[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