| Message ID | 20240322132619.6389-1-wsa+renesas@sang-engineering.com |
|---|---|
| Headers | show |
| Series | i2c: reword i2c_algorithm according to newest specification | expand |
On 22/03/2024 at 14:25, Wolfram Sang wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > Match the wording in i2c_algorithm in I2C drivers wrt. the newest I2C > v7, SMBus 3.2, I3C specifications and replace "master/slave" with more > appropriate terms. For some drivers, this means no more conversions are > needed. For the others more work needs to be done but this will be > performed incrementally along with API changes/improvements. All these > changes here are simple search/replace results. > > Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> > --- [..] > drivers/i2c/busses/i2c-at91-master.c | 2 +- > drivers/i2c/busses/i2c-at91-slave.c | 8 ++++---- [..] Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> # for at91 Probably file names themselves will need some care, in a second time. Thanks. Regards, Nicolas [..] > -- > 2.43.0 >
> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> # for at91 > Probably file names themselves will need some care, in a second time. Totally true. I am aware of that. But one step after the other...
On Fri, Mar 22, 2024 at 05:48:54PM +0100, Wolfram Sang wrote: > > > > static const struct i2c_algorithm at91_twi_algorithm = { > > > - .master_xfer = at91_twi_xfer, > > > + .xfer = at91_twi_xfer, > > > > Seems you made this by a script, can you check the indentations afterwards? > > Yes, I noticed as well. But other (not converted) drivers have issues > there as well, so this will be a seperate patch. The problem is that you add to a technical debt. We don't want that. If you have not introduced a new indentation issue, it obviously is not needed to be fixed in a separate patch. So, please consider this.
On Fri, Mar 22, 2024 at 9:47 AM Wolfram Sang <wsa+renesas@sang-engineering.com> wrote: > > > > Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> # for at91 > > Probably file names themselves will need some care, in a second time. > > Totally true. I am aware of that. But one step after the other... > Kind of odd though to change function names but not parameter names of those very same functions. Guenter
> Kind of odd though to change function names but not parameter names of > those very same functions. Ouch, this is definitely a valid point. Seems like this series will need a respin after all. Will wait for further comments, though. Thanks!
Hi Wolfram, On Fri, Mar 22, 2024 at 02:24:53PM +0100, Wolfram Sang wrote: > Okay, we need to begin somewhere... > > Start changing the wording of the I2C main header wrt. the newest I2C > v7, SMBus 3.2, I3C specifications and replace "master/slave" with more > appropriate terms. This first step renames the members of struct > i2c_algorithm. Once all in-tree users are converted, the anonymous union > will go away again. All this work will also pave the way for finally > seperating the monolithic header into more fine-grained headers like > "i2c/clients.h" etc. So, this is not a simple renaming-excercise but > also a chance to update the I2C core to recent Linux standards. yes, very good! It's clearly stated in all three documentations that Target replaces Slave and Controller replaces Master (i3c is at the 1.1.1 version). > My motivation is to improve the I2C core API, in general. My motivation > is not to clean each and every driver. I think this is impossible > because register names based on official documentation will need to stay > as they are. But the Linux-internal names should be updated IMO. Also because some drivers have been written based on previous specifications where master/slave was used. > That being said, I worked on 62 drivers in this series beyond plain > renames inside 'struct i2c_algorithm' because the fruits were so > low-hanging. Before this series, 112 files in the 'busses/' directory > contained 'master' and/or 'slave'. After the series, only 57. Why not? > > Next step is updating the drivers outside the 'i2c'-folder regarding > 'struct i2c_algorithm' so we can remove the anonymous union ASAP. To be > able to work on this with minimal dependencies, I'd like to apply this > series between -rc1 and -rc2. > > I hope this will work for you guys. The changes are really minimal. If > you are not comfortable with changes to your driver or need more time to > review, please NACK the patch and I will drop the patch and/or address > the issues separeately. > > @Andi: are you okay with this approach? It means you'd need to merge > -rc2 into your for-next branch. Or rebase if all fails. I think it's a good plan, I'll try to support you with it. > Speaking of Andi, thanks a lot to him taking care of the controller > drivers these days. His work really gives me the freedom to work on I2C > core issues again. Thank you, Wolfram! Andi
Hi Wolfram, > > @Andi: are you okay with this approach? It means you'd need to merge > > -rc2 into your for-next branch. Or rebase if all fails. > > I think it's a good plan, I'll try to support you with it. Do you feel more comfortable if I take the patches as soon as they are reviewd? So far I have tagged patch 1-4 and I can already merge 2,3,4 as long as you merge patch 1. Andi