Re: [PATCH 00/28] at24: remove at24_platform_data
Hi Bart, On Wednesday 08 August 2018 10:22 PM, Bartosz Golaszewski wrote: > 2018-08-08 18:44 GMT+02:00 Andrew Lunn : >> On Wed, Aug 08, 2018 at 06:27:25PM +0200, Bartosz Golaszewski wrote: >>> 2018-08-08 17:55 GMT+02:00 Wolfram Sang : On Wed, Aug 08, 2018 at 05:31:22PM +0200, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski > > 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
Re: [PATCH 00/28] at24: remove at24_platform_data
Hi Bart, On Wednesday 08 August 2018 10:22 PM, Bartosz Golaszewski wrote: > 2018-08-08 18:44 GMT+02:00 Andrew Lunn : >> On Wed, Aug 08, 2018 at 06:27:25PM +0200, Bartosz Golaszewski wrote: >>> 2018-08-08 17:55 GMT+02:00 Wolfram Sang : On Wed, Aug 08, 2018 at 05:31:22PM +0200, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski > > 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
Re: [PATCH 00/28] at24: remove at24_platform_data
On Wed, Aug 08, 2018 at 05:31:22PM +0200, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski > > 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... signature.asc Description: PGP signature
Re: [PATCH 00/28] at24: remove at24_platform_data
On Wed, Aug 08, 2018 at 05:31:22PM +0200, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski > > 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... signature.asc Description: PGP signature
