On 5/3/2024 12:39 AM, Thomas Zimmermann wrote: > Hi > > Am 03.05.24 um 00:26 schrieb Easwar Hariharan: >> On 5/2/2024 3:46 AM, Thomas Zimmermann wrote: >>> >>> Am 30.04.24 um 19:38 schrieb Easwar Hariharan: >>>> I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced >>>> "master/slave" >>>> with more appropriate terms. Inspired by and following on to Wolfram's >>>> series to fix drivers/i2c/[1], fix the terminology for users of >>>> I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists >>>> in the specification. >>>> >>>> Compile tested, no functionality changes intended >>>> >>>> [1]: >>>> https://lore.kernel.org/all/20240322132619.6389-1-wsa+rene...@sang-engineering.com/ >>>> >>>> Signed-off-by: Easwar Hariharan <eahar...@linux.microsoft.com> >>> Acked-by: Thomas Zimmermann <tzimmerm...@suse.de> >>> >> Thanks for the ack! I had been addressing feedback as I got it on the v0 >> series, and it seems >> I missed out on updating viafb and smscufx to spec-compliant >> controller/target terminology like >> the v0->v1 changelog calls out before posting v1. >> >> For smscufx, I feel phrasing the following line (as an example) >> >>> -/* sets up I2C Controller for 100 Kbps, std. speed, 7-bit addr, host, >>> +/* sets up I2C Controller for 100 Kbps, std. speed, 7-bit addr, >>> *controller*, >> would actually impact readability negatively, so I propose to leave smscufx >> as is. > > Why? I don't see much of a difference. > >> >> For viafb, I propose making it compliant with the spec using the >> controller/target terminology and >> posting a v2 respin (which I can send out as soon as you say) and ask you to >> review again. >> >> What do you think? > > I think we should adopt the spec's language everywhere. That makes it > possible to grep the spec for terms used in the source code. Using 'host' in > smscufx appears to introduce yet another term. If you are worried about using > 'I2C controller' and 'controller' in the same sentence, you can replace 'I2C > controller' with 'DDC channel'. That's even more precise about the purpose of > this code.
Great, thanks! That was exactly my concern, I will fix up smscufx and send a v2. Thanks, Easwar
