On Tue, 02 Apr 2024, Easwar Hariharan <eahariha@xxxxxxxxxxxxxxxxxxx> wrote: > On 4/2/2024 7:32 AM, Jani Nikula wrote: >> On Tue, 02 Apr 2024, Easwar Hariharan <eahariha@xxxxxxxxxxxxxxxxxxx> wrote: >>> On 4/2/2024 12:48 AM, Jani Nikula wrote: >>>> On Fri, 29 Mar 2024, Easwar Hariharan <eahariha@xxxxxxxxxxxxxxxxxxx> wrote: >>>>> I2C v7, SMBus 3.2, and I3C 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. >>>> >>>> gma500 and i915 changes should be split. See MAINTAINERS. >>>> >>>> Might also split the i915 changes to smaller pieces, it's kind of >>>> random. And the changes here are not strictly related to I2C AFAICT, so >>>> the commit message should be updated. >>>> >>>> BR, >>>> Jani. >>>> >>>> >>> >>> <snip> >>> >>> I will split gma500 and i915 into their respective patches if possible in v2. >>> >>> Can you say more about the changes being "not strictly related to I2C"? My >>> heuristic was to grep for master/slave, and look in the surrounding context for >>> i2c-related terminology (i2c_pin, 7-bit address, struct i2c_adapter, i2c_bus, etc) >>> to confirm that they are i2c-related, then following the references around to >>> make the compiler happy. For e.g., I did not change the many references to bigjoiner >>> master and slave because I understood from context they were not i2c references. >>> >>> A couple examples would help me restrict the changes to I2C, since as mentioned in the >>> discussion on Wolfram's thread, there are places where migrating away from master/slave >>> terms in the code would conflict with the original technical manuals and reduce correlation >>> and understanding of the code. >> >> I guess I was looking at the VBT changes in intel_bios.c. Granted, they >> do end up being used as i2c addresses. No big deal. >> >> I think I'd expect the treewide i2c adapter changes to land first, via >> i2c, and subsequent cleanups to happen next, via individual driver >> trees. There's quite a bit of conflict potential merging this outside of >> drm-intel-next, and there's really no need for that. >> >> BR, >> Jani. >> > > Great! Just so I'm clear, do you still want the i915 changes split up more, along with them being > split off from gma500? If we can merge the i915 changes via drm-intel-next, it's probably fine as a big i915 patch. Just the gma500 separated. (The struct i2c_algorithm change etc. necessarily has to go via I2C tree of course.) BR, Jani. > > Thanks, > Easwar -- Jani Nikula, Intel
