From: Jani Nikula <jani.nikula@linux.intel.com>
To: Easwar Hariharan <eahariha@linux.microsoft.com>,
Patrik Jakobsson <patrik.r.jakobsson@gmail.com>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
Tvrtko Ursulin <tursulin@ursulin.net>,
Zhenyu Wang <zhenyuw@linux.intel.com>,
Zhi Wang <zhi.wang.linux@gmail.com>,
dri-devel@lists.freedesktop.org,
open list <linux-kernel@vger.kernel.org>,
"open list:INTEL DRM DISPLAY FOR XE AND I915 DRIVERS"
<intel-gfx@lists.freedesktop.org>,
"open list:INTEL DRM DISPLAY FOR XE AND I915 DRIVERS"
<intel-xe@lists.freedesktop.org>,
"open list:INTEL GVT-g DRIVERS (Intel GPU Virtualization)"
<intel-gvt-dev@lists.freedesktop.org>
Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>,
"open list:RADEON and AMDGPU DRM DRIVERS"
<amd-gfx@lists.freedesktop.org>,
"open list:DRM DRIVER FOR NVIDIA GEFORCE/QUADRO GPUS"
<nouveau@lists.freedesktop.org>,
"open list:I2C SUBSYSTEM HOST DRIVERS"
<linux-i2c@vger.kernel.org>,
"open list:BTTV VIDEO4LINUX DRIVER" <linux-media@vger.kernel.org>,
"open list:FRAMEBUFFER LAYER" <linux-fbdev@vger.kernel.org>
Subject: Re: [PATCH v0 03/14] drm/gma500,drm/i915: Make I2C terminology more inclusive
Date: Tue, 02 Apr 2024 17:32:51 +0300 [thread overview]
Message-ID: <87ttkjesx8.fsf@intel.com> (raw)
In-Reply-To: <7d5e6ed0-ffe9-46c2-b3b4-a4a47c09532e@linux.microsoft.com>
On Tue, 02 Apr 2024, Easwar Hariharan <eahariha@linux.microsoft.com> wrote:
> On 4/2/2024 12:48 AM, Jani Nikula wrote:
>> On Fri, 29 Mar 2024, Easwar Hariharan <eahariha@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
next prev parent reply other threads:[~2024-04-02 14:33 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-29 17:00 [PATCH v0 00/14] Make I2C terminology more inclusive for I2C Algobit and consumers Easwar Hariharan
2024-03-29 17:00 ` [PATCH v0 01/14] IB/hfi1, IB/qib: Make I2C terminology more inclusive Easwar Hariharan
2024-04-03 8:30 ` Leon Romanovsky
2024-04-03 15:54 ` Dennis Dalessandro
2024-04-03 16:44 ` Easwar Hariharan
2024-03-29 17:00 ` [PATCH v0 02/14] drm/amdgpu,drm/radeon: " Easwar Hariharan
2024-03-29 17:16 ` Andi Shyti
2024-03-29 17:28 ` Easwar Hariharan
2024-03-29 17:38 ` Andi Shyti
2024-03-29 18:51 ` Easwar Hariharan
2024-03-29 17:38 ` Easwar Hariharan
2024-03-29 17:00 ` [PATCH v0 03/14] drm/gma500,drm/i915: " Easwar Hariharan
2024-03-29 17:00 ` [PATCH v0 03/14] drm/gma500, drm/i915: " Easwar Hariharan
2024-04-02 7:48 ` [PATCH v0 03/14] drm/gma500,drm/i915: " Jani Nikula
2024-04-02 11:59 ` Easwar Hariharan
2024-04-02 14:32 ` Jani Nikula [this message]
2024-04-02 16:20 ` Easwar Hariharan
2024-04-02 16:52 ` Jani Nikula
2024-04-02 18:19 ` Easwar Hariharan
2024-03-29 17:00 ` [PATCH v0 04/14] media: au0828: " Easwar Hariharan
2024-05-03 19:03 ` Mauro Carvalho Chehab
2024-03-29 17:00 ` [PATCH v0 05/14] media: cobalt: " Easwar Hariharan
2024-03-29 17:00 ` [PATCH v0 06/14] media: cx18: " Easwar Hariharan
2024-03-29 17:00 ` [PATCH v0 07/14] media: cx25821: " Easwar Hariharan
2024-03-29 17:00 ` [PATCH v0 08/14] media: ivtv: " Easwar Hariharan
2024-03-29 17:00 ` [PATCH v0 09/14] media: cx23885: " Easwar Hariharan
2024-03-29 17:00 ` [PATCH v0 10/14] sfc: falcon: " Easwar Hariharan
2024-04-02 8:29 ` Simon Horman
2024-04-04 19:17 ` Easwar Hariharan
2024-04-07 8:49 ` Simon Horman
2024-04-02 9:00 ` Martin Habets
2024-04-04 19:18 ` Easwar Hariharan
2024-04-08 8:35 ` Martin Habets
2024-03-29 17:00 ` [PATCH v0 11/14] fbdev/smscufx: " Easwar Hariharan
2024-03-29 17:00 ` [PATCH v0 12/14] fbdev/viafb: " Easwar Hariharan
2024-03-29 17:00 ` [PATCH v0 13/14] drm/nouveau: " Easwar Hariharan
2024-04-05 16:15 ` Danilo Krummrich
2024-04-05 16:30 ` Easwar Hariharan
2024-04-05 18:36 ` Lyude Paul
2024-03-29 17:00 ` [PATCH v0 14/14] i2c and treewide: " Easwar Hariharan
2024-04-05 10:18 ` [PATCH v0 00/14] Make I2C terminology more inclusive for I2C Algobit and consumers Wolfram Sang
2024-04-05 17:09 ` Easwar Hariharan
2024-04-07 17:50 ` Wolfram Sang
2024-04-08 7:48 ` Hans Verkuil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ttkjesx8.fsf@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=airlied@gmail.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=eahariha@linux.microsoft.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-gvt-dev@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=joonas.lahtinen@linux.intel.com \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=nouveau@lists.freedesktop.org \
--cc=patrik.r.jakobsson@gmail.com \
--cc=rodrigo.vivi@intel.com \
--cc=tursulin@ursulin.net \
--cc=tzimmermann@suse.de \
--cc=wsa+renesas@sang-engineering.com \
--cc=zhenyuw@linux.intel.com \
--cc=zhi.wang.linux@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).