From: Petr Štetiar <ynezz@xxxxxxx> Sent: Friday, May 10, 2019 7:28 PM > Andy Duan <fugang.duan@xxxxxxx> [2019-05-10 08:23:58]: > > Hi Andy, > > you've probably forget to Cc some maintainers and mailing lists, so I'm adding > them now to the Cc loop. This patch series should be posted against net-next > tree as per netdev FAQ[0], but you've to wait little bit as net-next is currently > closed for the new submissions and you would need to resend it anyway. > > 0. > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > kernel.org%2Fdoc%2Fhtml%2Flatest%2Fnetworking%2Fnetdev-FAQ.html&am > p;data=02%7C01%7Cfugang.duan%40nxp.com%7Cdc1bcd43f3bd41701eed08 > d6d53a9dee%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63693 > 0845065526608&sdata=QQItI08aTcR%2Bl4k%2FCqPCEPwT9o4GfzpZSM > gf37ollWc%3D&reserved=0 Thanks for your reminder. ^_^ > > > ethernet controller driver call .of_get_mac_address() to get the mac > > address from devictree tree, if these properties are not present, then > > try to read from nvmem. i.MX6x/7D/8MQ/8MM platforms ethernet MAC > > address read from nvmem ocotp eFuses, but it requires to swap the six > > bytes order. > > Thanks for bringing up this topic, as I would like to extend the functionality as > well, but I'm still unsure how to tackle this and where, so I'll (ab)use this > opportunity to bring other use cases I would like to cover in the future, so we > could better understand the needs. > > This reverse byte order format/layout is one of a few other storage formats > currently used by vendors, some other (creative) vendors are currently > providing MAC addresses in NVMEMs as ASCII text in following two formats > (hexdump -C /dev/mtdX): > > a) 0090FEC9CBE5 - MAC address stored as ASCII without colon between > octets > > 00000090 57 2e 4c 41 4e 2e 4d 41 43 2e 41 64 64 72 65 73 > |W.LAN.MAC.Addres| > 000000a0 73 3d 30 30 39 30 46 45 43 39 43 42 45 35 00 48 > |s=0090FEC9CBE5.H| > 000000b0 57 2e 4c 41 4e 2e 32 47 2e 30 2e 4d 41 43 2e 41 > |W.LAN.2G.0.MAC.A| > > (From > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub. > com%2Fopenwrt%2Fopenwrt%2Fpull%2F1448%23issuecomment-442476695 > &data=02%7C01%7Cfugang.duan%40nxp.com%7Cdc1bcd43f3bd41701e > ed08d6d53a9dee%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6 > 36930845065526608&sdata=VGzzDGMRrt6f%2FHZE%2BX4%2FieOkMQ > EBC%2BiKNgKpu9Loltk%3D&reserved=0) > > b) D4:EE:07:33:6C:20 - MAC address stored as ASCII with colon between > octets > > 00000180 66 61 63 5f 6d 61 63 20 3d 20 44 34 3a 45 45 3a |fac_mac > = D4:EE:| > 00000190 30 37 3a 33 33 3a 36 43 3a 32 30 0a 42 44 49 4e > |07:33:6C:20.BDIN| > > (From > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub. > com%2Fopenwrt%2Fopenwrt%2Fpull%2F1906%23issuecomment-483881911 > &data=02%7C01%7Cfugang.duan%40nxp.com%7Cdc1bcd43f3bd41701e > ed08d6d53a9dee%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6 > 36930845065526608&sdata=y5%2F4e6tuEub%2Fj9fqOQXM3as%2BbKA > vw6O3VY9oPE1qinU%3D&reserved=0) > > > The patch set is to add property "nvmem_macaddr_swap" to swap macaddr > > bytes order. > > so it would allow following DT construct (simplified): > > ð0 { > nvmem-cells = <ð0_addr>; > nvmem-cell-names = "mac-address"; > nvmem_macaddr_swap; > }; > > I'm not sure about the `nvmem_macaddr_swap` property name, as currently > there are no other properties with underscores, so it should be probably > named as `nvmem-macaddr-swap`. DT specs permits use of the underscores, > but the estabilished convention is probably prefered. > Yes, `nvmem-macaddr-swap` like is better. It just to let i.MX series platform nvmem work for of_get_mac_address. Not consider others' use cases like blew your mentioned since I am not familiar with others platforms. Your consider a more comprehensive cases, it is great. > In order to cover all above mentioned use cases, it would make more sense to > add a description of the MAC address layout to the DT and use this > information to properly postprocess the NVMEM content into usable MAC > address? > > Something like this? > > - 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 > - nvmem-mac-address-layout: string, specifies MAC address storage layout. > Supported values are: "binary", "binary-swapped", "ascii", > "ascii-delimited". > "binary" is the default. > > Or perhaps something like this? > > - nvmem-cells: phandle, reference to an nvmem node for the MAC address > - nvmem-cell-names: string, should be any of the supported values. > Supported values are: "mac-address", "mac-address-swapped", > "mac-address-ascii", "mac-address-ascii-delimited". > > I'm more inclined towards the first proposed solution, as I would like to > propose MAC address octet incrementation feature in the future, so it would > become: > > - 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 > - nvmem-mac-address-layout: string, specifies MAC address storage layout. > Supported values are: "binary", "binary-swapped", "ascii", > "ascii-delimited". > "binary" is the default. > - nvmem-mac-address-increment: number, value by which should be > incremented MAC address octet, could be negative value as well. > - nvmem-mac-address-increment-octet: number, valid values 0-5, default is > 5. > Specifies MAC address octet used for `nvmem-mac-address-increment`. > > What do you think? The last one is better. > > Cheers, > > Petr
