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] [day] [month] [year] [list]
Message-ID: <CADnq5_PAr6GHEBuStcJ6KVBS+mg64koqJwTDcz+7UcaEy_P_qA@mail.gmail.com>
Date: Wed, 8 May 2024 17:12:26 -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 Wed, May 8, 2024 at 4:12 PM Easwar Hariharan
<eahariha@...ux.microsoft.com> wrote:
>
> On 5/8/2024 7:53 AM, Alex Deucher wrote:
> > 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
>
> The way I see it, this is a small downpayment on the debt we have built up so far. Internship
> programs like LF Outreachy to get more underrepresented groups involved in open source are trying to
> change the open source community culture to be more inclusive, but simultaneously rely on the culture
> being welcoming enough as well.
>
> I do see the challenge involved in preserving the changes and ensuring no new code is added with
> outdated nomenclature (but see [1]), but culture changes one person at a time, and I'd encourage the community
> to do the work needed so we can move past our (mostly) inadvertent role in perpetuating it.
>
> That's my 2c (or your sub-unit currency of choice).

Fair enough.
Acked-by: Aex Deucher <alexander.deucher@....com>

>
> Easwar
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=49decddd39e5f6132ccd7d9fdc3d7c470b0061bb

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ