Nouveau - Apr 2024 - [PATCH v0 03/14] drm/gma500,drm/i915: Make I2C terminology more inclusive

On Tue, 02 Apr 2024, Easwar Hariharan <eahariha at linux.microsoft.com>
wrote:
> On 4/2/2024 12:48 AM, Jani Nikula wrote:
>> On Fri, 29 Mar 2024, Easwar Hariharan <eahariha at
linux.microsoft.com> 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.



>
> Thanks,
> Easwar
>
-- 
Jani Nikula, Intel

On 4/2/2024 7:32 AM, Jani Nikula wrote:
> On Tue, 02 Apr 2024, Easwar Hariharan <eahariha at
linux.microsoft.com> wrote:
>> On 4/2/2024 12:48 AM, Jani Nikula wrote:
>>> On Fri, 29 Mar 2024, Easwar Hariharan <eahariha at
linux.microsoft.com> 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?

Thanks,
Easwar

On Tue, 02 Apr 2024, Easwar Hariharan <eahariha at linux.microsoft.com>
wrote:
> On 4/2/2024 7:32 AM, Jani Nikula wrote:
>> On Tue, 02 Apr 2024, Easwar Hariharan <eahariha at
linux.microsoft.com> wrote:
>>> On 4/2/2024 12:48 AM, Jani Nikula wrote:
>>>> On Fri, 29 Mar 2024, Easwar Hariharan <eahariha at
linux.microsoft.com> 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