This is a follow-up to a series I posted a while ago the goal of which
was to replace the at24 platform data with device properties. To do so
we need to somehow remove reading the MAC address from relevant board
files.
In my patches I used nvmem and MTD to read the MAC address from within
the davinci emac driver. It was suggested that we generalize it further
but since MTD doesn't support nvmem yet, the best we can do is to move
this code over to net core code.
The following patches modify the eth_platform_get_mac_address()
function which seems to be the best candidate for this code.
The first patch splits the function into two subroutines.
The last two patches add nvmem and MTD support to the function. In
order to stay compatible with existing users, nvmem and MTD will be
tried last - after device tree and arch-specific callback.
If this series gets accepted I will modify my previous patches to
use it instead of handcoding the same operations in davinci_emac.
v1 -> v2:
- dropped patches 1 & 2
- improved the MAC address verification and fixed a potential buffer
overflow in patch 2/3
v2 -> v3:
- in patch 1: split the function into subroutines in preparation
for nvmem and MTD support
- modify patches 2 & 3 so that they have a separate function for
each new MAC address source
Bartosz Golaszewski (3):
net: split eth_platform_get_mac_address() into subroutines
net: add support for nvmem to eth_platform_get_mac_address()
net: add MTD support to eth_platform_get_mac_address()
net/ethernet/eth.c | 117 ++++++++++++++++++++++++++++++++++++++++-----
1 file changed, 106 insertions(+), 11 deletions(-)
--
2.17.1
From: Bartosz Golaszewski <redacted>
MTD doesn't support nvmem yet. Some platforms use MTD to read the MAC
address from SPI flash. If we want this function to generalize reading
the MAC address, we need to separately try to use MTD.
Signed-off-by: Bartosz Golaszewski <redacted>
---
net/ethernet/eth.c | 33 ++++++++++++++++++++++++++++++++-
1 file changed, 32 insertions(+), 1 deletion(-)
From: Bartosz Golaszewski <redacted>
We want do add more sources from which to read the MAC address. In
order to avoid bloating this function too much, start by splitting it
into subroutines, each of which takes care of reading the MAC from
one source.
Signed-off-by: Bartosz Golaszewski <redacted>
---
net/ethernet/eth.c | 48 +++++++++++++++++++++++++++++++++++-----------
1 file changed, 37 insertions(+), 11 deletions(-)
From: Bartosz Golaszewski <redacted>
Many non-DT platforms read the MAC address from EEPROM. Usually it's
either done with callbacks defined in board files or from SoC-specific
ethernet drivers.
In order to generalize this, try to read the MAC from nvmem in
eth_platform_get_mac_address() using a standard lookup name:
"mac-address".
Signed-off-by: Bartosz Golaszewski <redacted>
---
net/ethernet/eth.c | 38 ++++++++++++++++++++++++++++++++++++++
1 file changed, 38 insertions(+)
From: Andrew Lunn <andrew@lunn.ch> Date: 2018-07-20 14:29:20
On Thu, Jul 19, 2018 at 05:32:43PM +0200, Bartosz Golaszewski wrote:
From: Bartosz Golaszewski <redacted>
MTD doesn't support nvmem yet. Some platforms use MTD to read the MAC
address from SPI flash. If we want this function to generalize reading
the MAC address, we need to separately try to use MTD.
How many board files are doing this? It is only worth generlizing if
there are a number of board files, all just pulling 6 bytes out from
the beginning of an MTD partition.
It is also normal to actually add a user of a new feature at the same
time as the new feature. It can be messy when it is across subsystem
boundaries, but please at least try.
Andrew