On Sat, Jan 28, 2023 at 05:16:13PM +0100, Uwe Kleine-König wrote: > Hello, > > On Sat, Jan 28, 2023 at 10:14:09PM +0800, Jianhua Lu wrote: > > On Sat, Jan 28, 2023 at 02:32:39PM +0100, Uwe Kleine-König wrote: > > > On Sat, Jan 28, 2023 at 08:36:28AM +0800, Jianhua Lu wrote: > > > > I prefer that you pack this commit to the i2c-tree commit that drops > > > > old .probe(). > > > > > > That's fine for me. Can I interpret this as an Ack for this patch? > > > > Yes, but can't get my A-b directly, this patch should be ignored and > > resend it within the i2c-tree patch series or split it to two patch > > series. > > I'm not sure if I understand you correctly. Up to know I though you want > the patch as is go in together with the patch that modifies struct > i2c_driver such that the PR has in two separate commits: > > i2c: Modify .probe() to not take an id parameter > backlight: ktz8866: Convert to i2c's .probe_new() This is case 1, the case 2 should be: Patch 1: i2c: Modify .probe() to not take an id parameter Patch 2: backlight: ktz8866: Convert to i2c's .probe_new() 'subsystem': 'i2c driver name': Convert to i2c's .probe_new() ... > > Did I understand that right? > > In that case an Ack by you would be fine and welcome. > > I don't want to squash the changes to the ktz8866 driver into the patch > that modifies struct i2c_driver, as this needlessly clutters the commit, > if it's that what you wanted. (There are more than 1000 i2c drivers and > the others are not converted in a single lockstep, too.) Do't squash this patch, I'd like you send a series patch instead of a single patch. > > Best regards > Uwe > > -- > Pengutronix e.K. | Uwe Kleine-König | > Industrial Linux Solutions | https://www.pengutronix.de/ |
