2018-07-04 11:04 GMT+02:00 Sekhar Nori [off-list ref]:

On Wednesday 04 July 2018 01:59 PM, Bartosz Golaszewski wrote:

quoted

2018-07-04 9:09 GMT+02:00 Ladislav Michl [off-list ref]:

quoted

On Tue, Jul 03, 2018 at 09:39:51AM -0700, Florian Fainelli wrote:

quoted

On 06/29/2018 02:40 AM, Bartosz Golaszewski wrote:

quoted

From: Bartosz Golaszewski <redacted>

On da850-evm board we can read the MAC address from MTD. It's currently
done in the relevant board file, but we want to get rid of all the MAC
reading callbacks from the board file (SPI and NAND). Move the reading
of the MAC address from SPI to the emac driver's probe function.

This should be made something generic to all drivers, not just something
the davinci_emac driver does, something like this actually:

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

...and that's would also make it work when MAC address is stored
in 24c08 EEPROM, which is quite common.

This is what the second patch for davinci_emac in this series does. I
agree that this should become more generic at some point - we should
probably have a routine somewhere in net that would try to get the MAC
address from all possible sources (nvmem, of etc.). This is somewhat
related to the work I want to do on nvmem to make the at24 setup()
callback more generic.

Unfortunately we don't have it yet and I will not have time to work on
it before v4.20 so if there are no serious objections, I'd like to get
this series merged for v4.19 and then we can refactor the MAC reading
later.

How does it sound?

I don't think the series introduces any regressions. We need to have MTD
and SPI flash built into the kernel even today to get mac address on
DA850 EVM. So from that perspective, I don't have objections (I need to
actually test still).

OTOH, it will be nice to do the conversion once and not piecemeal. That
way there is less churn and scope for regressions.

So from a mach-davinci perspective, I don't have a very strong position
either way.

Thanks,
Sekhar

We're getting close to rc5 so I'd like to make a case for this series again.

I understand that there's more to do than just the changes introduced
here, but we shouldn't try to fix several problems in many different
places at once. There's just too many moving pieces. I'd rather start
merging small improvements right away.

The idea behind this series is to remove (almost) all users of
at24_platform_data. The davinci_emac patches are there only because we
need to remove some MAC adress reading stuff from the board files.
Having this code there and calling it back from EEPROM/MTD drivers is
already wrong and we should work towards using nvmem for that anyway.

Currently for MTD the nvmem support series seems to be dead and it's
going to take some time before anything gets upstream.

So I'd like to again ask you to consider picking up the patches from
this series to your respective trees or at the very least: I'd like to
ask Srinivas to pick up the nvmem patches and Sekhar to take the
first, non-controversial batch of davinci platform changes so that
we'll have less code to carry for the next release.

Best regards,
Bartosz Golaszewski