On 13/11/18 7:31 PM, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski <bgolaszewski@xxxxxxxxxxxx> > > Now that nvmem has gained support for defining cells from board files and > looking them up from relevant drivers[1], it's time for a respin of the > previous series[2] that aims at removing struct at24_platform_data from > the tree. > > Since I took over maintainership of the at24 driver I've been working > towards removing at24_platform_data in favor for device properties. > > DaVinci is the only platform that's still using it - all other users > have already been converted. > > One of the obstacles in case of DaVinci is removing the setup() callback > from the pdata struct, the only user of which are some davinci boards. > > First we add support for nvmem to MTD in a way previously discussed with > Boris Brezillon and Srinivas Kandagatla. > > Then, since most boards use the EEPROM to store the MAC address, we register > relevant cells for all users, implement a function that allows to read > the MAC address from nvmem (and also replaces the previous DT-specific > variant) and make davinci_emac aware of it. > > Next we switch all davinci users to using at24 device properties instead > of platform data. While we're at it: we remove all other traces of the > setup callback and platform data from davinci. > > Finally we remove the at24 platform data structure. > > I kept the review tags in patches that haven't changed from the last > submission. > > As far as merging of this series goes: I'd like to avoid dragging it over > four releases. The series is logically split into five groups: > > patches 1-2: nvmem and mtd changes > patches 3-9: davinci arch-specific changes Applied patches 3-9 to davinci tree for v4.21 > patches 10-13: networking changes > patches 14-24: davinci specific again > patch 25: final at24 change > > With that I believe we can do the following: Greg KH could pick up the > first two patches into his char-misc tree. Sekhar would take the second > group and the third would go through the networking tree since the first > three sets are not linked in any way. This would be merged for 4.21. Then > for the next release Sekhar would pick up 14-24, provide an immutable > branch for me and I'd merge the final patch for at24 and send it upstream > through Wolfram's i2c tree (maybe we could even delay the i2c PR in the > merge window to avoid the immutable branch altogether). > > [1] https://lkml.org/lkml/2018/9/21/293 > [2] https://lkml.org/lkml/2018/8/8/528 Thanks, Sekhar
