linux-kernel - Re: [PATCH v0 03/14] drm/gma500,drm/i915: Make I2C terminology more inclusive

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Tue, 2 Apr 2024 11:19:03 -0700
From: Easwar Hariharan <eahariha@...ux.microsoft.com>
To: Jani Nikula <jani.nikula@...ux.intel.com>,
 Patrik Jakobsson <patrik.r.jakobsson@...il.com>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
 David Airlie <airlied@...il.com>, Daniel Vetter <daniel@...ll.ch>,
 Rodrigo Vivi <rodrigo.vivi@...el.com>,
 Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>,
 Tvrtko Ursulin <tursulin@...ulin.net>, Zhenyu Wang
 <zhenyuw@...ux.intel.com>, Zhi Wang <zhi.wang.linux@...il.com>,
 dri-devel@...ts.freedesktop.org, open list <linux-kernel@...r.kernel.org>,
 "open list:INTEL DRM DISPLAY FOR XE AND I915 DRIVERS"
 <intel-gfx@...ts.freedesktop.org>,
 "open list:INTEL DRM DISPLAY FOR XE AND I915 DRIVERS"
 <intel-xe@...ts.freedesktop.org>,
 "open list:INTEL GVT-g DRIVERS (Intel GPU Virtualization)"
 <intel-gvt-dev@...ts.freedesktop.org>
Cc: Wolfram Sang <wsa+renesas@...g-engineering.com>,
 "open list:RADEON and AMDGPU DRM DRIVERS" <amd-gfx@...ts.freedesktop.org>,
 "open list:DRM DRIVER FOR NVIDIA GEFORCE/QUADRO GPUS"
 <nouveau@...ts.freedesktop.org>,
 "open list:I2C SUBSYSTEM HOST DRIVERS" <linux-i2c@...r.kernel.org>,
 "open list:BTTV VIDEO4LINUX DRIVER" <linux-media@...r.kernel.org>,
 "open list:FRAMEBUFFER LAYER" <linux-fbdev@...r.kernel.org>
Subject: Re: [PATCH v0 03/14] drm/gma500,drm/i915: Make I2C terminology more
 inclusive

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

Got it. I'll send the split out in v1 (not v2 as mentioned earlier) since this is v0.

Thanks,
Easwar