On Monday 16 July 2018 02:26 PM, Srinivas Kandagatla wrote:

On 16/07/18 09:50, Sekhar Nori wrote:

quoted

On Friday 13 July 2018 11:30 PM, Bartosz Golaszewski wrote:

quoted

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.

I think those are patches 3-7. I can take those if I get an immutable
commit over v4.18-rc1 from Srinivas with patches 1 & 2 applied.

nvmem patches go via Greg KH char-misc tree, if it makes things easy I
can provide Ack on nvmem patches, so that you can take these patches via
your tree?

There is a lot of follow-up traffic on how exactly to develop the needed
interfaces for reading mac address in mtd and/or network subsystem.

But, I don't think any of that negates the need for nvmem lookups that
work for non-device-tree and populating the lookups in mach-davinci
board code.

I am going to send patches 1-7 to ARM-SoC soon, so please do say if
there is any disagreement on this.

Thanks,
Sekhar

Let me know.

--srini

quoted

Thanks,
Sekhar