| Message ID | 20180808153150.23444-1-brgl@bgdev.pl (mailing list archive) |
|---|---|
| Headers | show |
| Series | at24: remove at24_platform_data | expand |
On Wed, Aug 08, 2018 at 05:31:22PM +0200, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski <bgolaszewski@baylibre.com> > > This is a follow-up to the previously rejected series[1] which partially > removed the at24_platform_data structure. After further development and > taking reviews into account, this series finally removes that struct > completely but not without touching many different parts of the code > base. > > Since I took over maintainership of the at24 driver I've been working > towards removing at24_platform_data in favor for device properties. Wooha, nice work. I can't really comment on it but wondered how you want to upstream it (after reviews)? Pull request of an immutable branch for nvmem-tree sounds best to me. Then I could also pull it in if i2c needs it. Probably same situation for arm-soc...
2018-08-08 17:55 GMT+02:00 Wolfram Sang <wsa@the-dreams.de>: > On Wed, Aug 08, 2018 at 05:31:22PM +0200, Bartosz Golaszewski wrote: >> From: Bartosz Golaszewski <bgolaszewski@baylibre.com> >> >> This is a follow-up to the previously rejected series[1] which partially >> removed the at24_platform_data structure. After further development and >> taking reviews into account, this series finally removes that struct >> completely but not without touching many different parts of the code >> base. >> >> Since I took over maintainership of the at24 driver I've been working >> towards removing at24_platform_data in favor for device properties. > > Wooha, nice work. I can't really comment on it but wondered how you want > to upstream it (after reviews)? Pull request of an immutable branch for > nvmem-tree sounds best to me. Then I could also pull it in if i2c needs > it. Probably same situation for arm-soc... > I initially wanted to merge small parts of it starting with v4.18, but there were some voices against merging APIs without users. I'm not sure how it should go in. There'll be a need for multiple immutable branches most probably... Bart -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Aug 08, 2018 at 06:27:25PM +0200, Bartosz Golaszewski wrote: > 2018-08-08 17:55 GMT+02:00 Wolfram Sang <wsa@the-dreams.de>: > > On Wed, Aug 08, 2018 at 05:31:22PM +0200, Bartosz Golaszewski wrote: > >> From: Bartosz Golaszewski <bgolaszewski@baylibre.com> > >> > >> This is a follow-up to the previously rejected series[1] which partially > >> removed the at24_platform_data structure. After further development and > >> taking reviews into account, this series finally removes that struct > >> completely but not without touching many different parts of the code > >> base. > >> > >> Since I took over maintainership of the at24 driver I've been working > >> towards removing at24_platform_data in favor for device properties. > > > > Wooha, nice work. I can't really comment on it but wondered how you want > > to upstream it (after reviews)? Pull request of an immutable branch for > > nvmem-tree sounds best to me. Then I could also pull it in if i2c needs > > it. Probably same situation for arm-soc... > > > > I initially wanted to merge small parts of it starting with v4.18, but > there were some voices against merging APIs without users. I'm not > sure how it should go in. There'll be a need for multiple immutable > branches most probably... Hi Bartosz What this series does is show all the different parts are now available, and can be reviewed as a whole. Once that review is completed, merging in parts then becomes possible. It looks like you could probably merge the nvmem, mtd and net parts independently via there maintainers for 4.20, since i don't think there are any dependencies. The arm-soc changes in 4.21, and the removal of the platform data in 4.22? Andrew -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
2018-08-08 18:44 GMT+02:00 Andrew Lunn <andrew@lunn.ch>: > On Wed, Aug 08, 2018 at 06:27:25PM +0200, Bartosz Golaszewski wrote: >> 2018-08-08 17:55 GMT+02:00 Wolfram Sang <wsa@the-dreams.de>: >> > On Wed, Aug 08, 2018 at 05:31:22PM +0200, Bartosz Golaszewski wrote: >> >> From: Bartosz Golaszewski <bgolaszewski@baylibre.com> >> >> >> >> This is a follow-up to the previously rejected series[1] which partially >> >> removed the at24_platform_data structure. After further development and >> >> taking reviews into account, this series finally removes that struct >> >> completely but not without touching many different parts of the code >> >> base. >> >> >> >> Since I took over maintainership of the at24 driver I've been working >> >> towards removing at24_platform_data in favor for device properties. >> > >> > Wooha, nice work. I can't really comment on it but wondered how you want >> > to upstream it (after reviews)? Pull request of an immutable branch for >> > nvmem-tree sounds best to me. Then I could also pull it in if i2c needs >> > it. Probably same situation for arm-soc... >> > >> >> I initially wanted to merge small parts of it starting with v4.18, but >> there were some voices against merging APIs without users. I'm not >> sure how it should go in. There'll be a need for multiple immutable >> branches most probably... > > Hi Bartosz > > What this series does is show all the different parts are now > available, and can be reviewed as a whole. Once that review is > completed, merging in parts then becomes possible. > > It looks like you could probably merge the nvmem, mtd and net parts > independently via there maintainers for 4.20, since i don't think > there are any dependencies. The arm-soc changes in 4.21, and the > removal of the platform data in 4.22? > > Andrew We need the first batch of SoC changes for the net part and then the second batch depends on those net changes. Also: dragging the merge for this over a year is a bit overkill. Sekhar: I know you're usually provided with immutable branches from framework maintainers for the SoC changes - is it ok for you to provide the net maintainers with an immutable branch after applying the first part of davinci board file changes? Bart -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Bart, On Wednesday 08 August 2018 10:22 PM, Bartosz Golaszewski wrote: > 2018-08-08 18:44 GMT+02:00 Andrew Lunn <andrew@lunn.ch>: >> On Wed, Aug 08, 2018 at 06:27:25PM +0200, Bartosz Golaszewski wrote: >>> 2018-08-08 17:55 GMT+02:00 Wolfram Sang <wsa@the-dreams.de>: >>>> On Wed, Aug 08, 2018 at 05:31:22PM +0200, Bartosz Golaszewski wrote: >>>>> From: Bartosz Golaszewski <bgolaszewski@baylibre.com> >>>>> >>>>> This is a follow-up to the previously rejected series[1] which partially >>>>> removed the at24_platform_data structure. After further development and >>>>> taking reviews into account, this series finally removes that struct >>>>> completely but not without touching many different parts of the code >>>>> base. >>>>> >>>>> Since I took over maintainership of the at24 driver I've been working >>>>> towards removing at24_platform_data in favor for device properties. >>>> >>>> Wooha, nice work. I can't really comment on it but wondered how you want >>>> to upstream it (after reviews)? Pull request of an immutable branch for >>>> nvmem-tree sounds best to me. Then I could also pull it in if i2c needs >>>> it. Probably same situation for arm-soc... >>>> >>> >>> I initially wanted to merge small parts of it starting with v4.18, but >>> there were some voices against merging APIs without users. I'm not >>> sure how it should go in. There'll be a need for multiple immutable >>> branches most probably... >> >> Hi Bartosz >> >> What this series does is show all the different parts are now >> available, and can be reviewed as a whole. Once that review is >> completed, merging in parts then becomes possible. >> >> It looks like you could probably merge the nvmem, mtd and net parts >> independently via there maintainers for 4.20, since i don't think >> there are any dependencies. The arm-soc changes in 4.21, and the >> removal of the platform data in 4.22? >> >> Andrew > > We need the first batch of SoC changes for the net part and then the > second batch depends on those net changes. Also: dragging the merge > for this over a year is a bit overkill. > > Sekhar: I know you're usually provided with immutable branches from > framework maintainers for the SoC changes - is it ok for you to > provide the net maintainers with an immutable branch after applying > the first part of davinci board file changes? Yeah, sure. I will be happy to do that to speed merging. Will take a look at v2 you posted. Thanks, Sekhar
From: Bartosz Golaszewski <bgolaszewski@baylibre.com> This is a follow-up to the previously rejected series[1] which partially removed the at24_platform_data structure. After further development and taking reviews into account, this series finally removes that struct completely but not without touching many different parts of the code base. 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. Most boards use the EEPROM to store the MAC address. This series adds support for cell lookups to the nvmem framework, registers relevant cells for all users, adds nvmem support to eth_platform_get_mac_address(), converts davinci_emac driver to using it and replaces at24_platform_data with device properties. There's also one board (da850-evm) which uses MTD for reading the MAC address. I used the patch from Alban Bedel's previous submission[2] to add support for nvmem to the MTD framework. Since this user doesn't need device tree, I dropped Alban's patches modifying the DT bindings. We can add that later once an agreement is reached. For the time being MTD devices are registered as nvmem devices and we're registering the mac-address cell using the cell lookup mechanism. This series adds a blocking notifier chain to the nvmem framework, so that we can keep the EEPROM reading code in the mityomapl138 board file with only slight modifications. I also included some minor fixes to the modified code. Tested on da850-evm & dm365-evm. [1] https://lkml.org/lkml/2018/6/29/153 [2] https://lkml.org/lkml/2018/3/24/312 Alban Bedel (1): mtd: Add support for reading MTD devices via the nvmem API Bartosz Golaszewski (27): nvmem: add support for cell lookups Documentation: nvmem: document lookup entries nvmem: add a notifier chain nvmem: provide nvmem_device_name() nvmem: remove the name field from struct nvmem_device ARM: davinci: dm365-evm: use nvmem lookup for mac address ARM: davinci: dm644-evm: use nvmem lookup for mac address ARM: davinci: dm646x-evm: use nvmem lookup for mac address ARM: davinci: da830-evm: use nvmem lookup for mac address ARM: davinci: mityomapl138: add nvmem cells lookup entries ARM: davinci: da850-evm: use nvmem lookup for mac address ARM: davinci: da850-evm: remove unnecessary include net: split eth_platform_get_mac_address() into subroutines net: add support for nvmem to eth_platform_get_mac_address() net: davinci_emac: use eth_platform_get_mac_address() ARM: davinci: da850-evm: remove dead MTD code ARM: davinci: mityomapl138: don't read the MAC address from machine code ARM: davinci: dm365-evm: use device properties for at24 eeprom ARM: davinci: da830-evm: use device properties for at24 eeprom ARM: davinci: dm644x-evm: use device properties for at24 eeprom ARM: davinci: dm646x-evm: use device properties for at24 eeprom ARM: davinci: sffsdr: fix the at24 eeprom device name ARM: davinci: sffsdr: use device properties for at24 eeprom ARM: davinci: remove dead code related to MAC address reading ARM: davinci: mityomapl138: use nvmem notifiers ARM: davinci: mityomapl138: use device properties for at24 eeprom eeprom: at24: kill at24_platform_data Documentation/nvmem/nvmem.txt | 28 +++++ MAINTAINERS | 1 - arch/arm/mach-davinci/board-da830-evm.c | 25 ++-- arch/arm/mach-davinci/board-da850-evm.c | 45 +++----- arch/arm/mach-davinci/board-dm365-evm.c | 25 ++-- arch/arm/mach-davinci/board-dm644x-evm.c | 24 ++-- arch/arm/mach-davinci/board-dm646x-evm.c | 25 ++-- arch/arm/mach-davinci/board-mityomapl138.c | 59 +++++++--- arch/arm/mach-davinci/board-sffsdr.c | 13 +-- arch/arm/mach-davinci/common.c | 15 --- drivers/misc/eeprom/at24.c | 127 +++++++++------------ drivers/mtd/Kconfig | 1 + drivers/mtd/mtdcore.c | 50 ++++++++ drivers/net/ethernet/ti/davinci_emac.c | 12 +- drivers/nvmem/core.c | 106 ++++++++++++++++- include/linux/davinci_emac.h | 2 - include/linux/mtd/mtd.h | 2 + include/linux/nvmem-consumer.h | 31 +++++ include/linux/nvmem-provider.h | 10 ++ include/linux/platform_data/at24.h | 60 ---------- net/ethernet/eth.c | 86 ++++++++++++-- 21 files changed, 492 insertions(+), 255 deletions(-) delete mode 100644 include/linux/platform_data/at24.h