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]
Message-ID: <CADnq5_NpxPM-FTcCchdBMRng=6xdM03s93XEX2_8fx44MRVYag@mail.gmail.com>
Date: Wed, 8 May 2024 10:53:00 -0400
From: Alex Deucher <alexdeucher@...il.com>
To: Easwar Hariharan <eahariha@...ux.microsoft.com>
Cc: Christian König <christian.koenig@....com>, 
	David Airlie <airlied@...il.com>, Daniel Vetter <daniel@...ll.ch>, 
	Wolfram Sang <wsa+renesas@...g-engineering.com>, 
	"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: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>, "Pan, Xinhui" <Xinhui.Pan@....com>, 
	Harry Wentland <harry.wentland@....com>, Leo Li <sunpeng.li@....com>, 
	Rodrigo Siqueira <Rodrigo.Siqueira@....com>, Evan Quan <evan.quan@....com>, 
	Hawking Zhang <Hawking.Zhang@....com>, Candice Li <candice.li@....com>, 
	Ran Sun <sunran001@...suo.com>, Alexander Richards <electrodeyt@...il.com>, 
	Wolfram Sang <wsa@...nel.org>, Andi Shyti <andi.shyti@...ux.intel.com>, 
	Dmitry Baryshkov <dmitry.baryshkov@...aro.org>, Heiko Stuebner <heiko@...ech.de>, 
	Heiner Kallweit <hkallweit1@...il.com>, Hamza Mahfooz <hamza.mahfooz@....com>, 
	Ruan Jinjie <ruanjinjie@...wei.com>, Aurabindo Pillai <aurabindo.pillai@....com>, 
	Wayne Lin <wayne.lin@....com>, Samson Tam <samson.tam@....com>, Alvin Lee <alvin.lee2@....com>, 
	Sohaib Nadeem <sohaib.nadeem@....com>, Charlene Liu <charlene.liu@....com>, 
	Tom Chung <chiahsuan.chung@....com>, Alan Liu <haoping.liu@....com>, 
	Bhawanpreet Lakha <Bhawanpreet.Lakha@....com>, 
	Meenakshikumar Somasundaram <meenakshikumar.somasundaram@....com>, George Shen <george.shen@....com>, 
	Aric Cyr <aric.cyr@....com>, Nicholas Kazlauskas <nicholas.kazlauskas@....com>, 
	Qingqing Zhuo <Qingqing.Zhuo@....com>, Dillon Varone <dillon.varone@....com>, 
	Lijo Lazar <lijo.lazar@....com>, Asad kamal <asad.kamal@....com>, 
	Kenneth Feng <kenneth.feng@....com>, Ma Jun <Jun.Ma2@....com>, 
	Darren Powell <darren.powell@....com>, Yang Wang <kevinyang.wang@....com>, 
	Mario Limonciello <mario.limonciello@....com>, Yifan Zhang <yifan1.zhang@....com>, Le Ma <Le.Ma@....com>, 
	"open list:RADEON and AMDGPU DRM DRIVERS" <amd-gfx@...ts.freedesktop.org>, 
	"open list:DRM DRIVERS" <dri-devel@...ts.freedesktop.org>, Alex Deucher <alexander.deucher@....com>, 
	open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 01/12] drm/amdgpu, drm/radeon: Make I2C terminology
 more inclusive

On Tue, May 7, 2024 at 2:32 PM Easwar Hariharan
<eahariha@...ux.microsoft.com> wrote:
>
> On 5/3/2024 11:13 AM, Easwar Hariharan wrote:
> > I2C v7, SMBus 3.2, and I3C 1.1.1 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.
> >
> > Compile tested, no functionality changes intended
> >
> > [1]: https://lore.kernel.org/all/20240322132619.6389-1-wsa+renesas@sang-engineering.com/
> >
> > Signed-off-by: Easwar Hariharan <eahariha@...ux.microsoft.com>
> > ---
> >  .../gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c  |  8 +++---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c       | 10 +++----
> >  drivers/gpu/drm/amd/amdgpu/atombios_i2c.c     |  8 +++---
> >  drivers/gpu/drm/amd/amdgpu/atombios_i2c.h     |  2 +-
> >  drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c    | 20 ++++++-------
> >  .../gpu/drm/amd/display/dc/bios/bios_parser.c |  2 +-
> >  .../drm/amd/display/dc/bios/bios_parser2.c    |  2 +-
> >  .../drm/amd/display/dc/core/dc_link_exports.c |  4 +--
> >  drivers/gpu/drm/amd/display/dc/dc.h           |  2 +-
> >  drivers/gpu/drm/amd/display/dc/dce/dce_i2c.c  |  4 +--
> >  .../display/include/grph_object_ctrl_defs.h   |  2 +-
> >  drivers/gpu/drm/amd/include/atombios.h        |  2 +-
> >  drivers/gpu/drm/amd/include/atomfirmware.h    | 26 ++++++++---------
> >  .../powerplay/hwmgr/vega20_processpptables.c  |  4 +--
> >  .../amd/pm/powerplay/inc/smu11_driver_if.h    |  2 +-
> >  .../inc/pmfw_if/smu11_driver_if_arcturus.h    |  2 +-
> >  .../inc/pmfw_if/smu11_driver_if_navi10.h      |  2 +-
> >  .../pmfw_if/smu11_driver_if_sienna_cichlid.h  |  2 +-
> >  .../inc/pmfw_if/smu13_driver_if_aldebaran.h   |  2 +-
> >  .../inc/pmfw_if/smu13_driver_if_v13_0_0.h     |  2 +-
> >  .../inc/pmfw_if/smu13_driver_if_v13_0_7.h     |  2 +-
> >  .../gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c |  4 +--
> >  .../amd/pm/swsmu/smu11/sienna_cichlid_ppt.c   |  8 +++---
> >  drivers/gpu/drm/radeon/atombios.h             | 16 +++++------
> >  drivers/gpu/drm/radeon/atombios_i2c.c         |  4 +--
> >  drivers/gpu/drm/radeon/radeon_combios.c       | 28 +++++++++----------
> >  drivers/gpu/drm/radeon/radeon_i2c.c           | 10 +++----
> >  drivers/gpu/drm/radeon/radeon_mode.h          |  6 ++--
> >  28 files changed, 93 insertions(+), 93 deletions(-)
> >
>
> <snip>
>
> Hello Christian, Daniel, David, others,
>
> Could you re-review v2 since the feedback provided in v0 [1] has now been addressed? I can send v3 with
> all other feedback and signoffs from the other maintainers incorporated when I have something for amdgpu
> and radeon.

This seems like a lot of churn.  Additionally, a bunch of these
headers are shared with other OSes, so it's possible some of the
changes may end up getting reverted accidently when we sync up or we
may add new headers in new code with the old nomenclature and then
we'd need to make sure to adjust it to make sure everything was
aligned again.  I would just as soon leave things as is, but I'm open
to acking them if there is a strong desire to update things.

Alex

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ