Message-ID: <87ttkjesx8.fsf@intel.com>
Date: Tue, 02 Apr 2024 17:32:51 +0300
From: Jani Nikula <jani.nikula@...ux.intel.com>
To: Easwar Hariharan <eahariha@...ux.microsoft.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 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.




>
> Thanks,
> Easwar
>

-- 
Jani Nikula, Intel

Powered by blists - more mailing lists