Message ID | 20240503181333.2336999-1-eahariha@linux.microsoft.com |
---|---|
Headers | show |
Series | Make I2C terminology more inclusive for I2C Algobit and consumers | expand |
On Fri, 03 May 2024, Rodrigo Vivi <rodrigo.vivi@intel.com> wrote: > On Fri, May 03, 2024 at 02:04:15PM -0700, Easwar Hariharan wrote: >> On 5/3/2024 12:34 PM, Rodrigo Vivi wrote: >> > On Fri, May 03, 2024 at 06:13:24PM +0000, 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/ >> >> >> >> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> >> >> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> >> > >> > It looks like the ack is not needed since we are merging this through >> > drm-intel-next. But I'm planing to merge this only after seeing the >> > main drivers/i2c accepting the new terminology. So we don't have a >> > risk of that getting push back and new names there and we having >> > to rename it once again. >> >> Just to be explicit, did you want me to remove the Acked-by in v3, or will you when you pull >> the patch into drm-intel-next? >> >> > >> > (more below) >> > >> >> Acked-by: Zhi Wang <zhiwang@kernel.org> >> >> Signed-off-by: Easwar Hariharan <eahariha@linux.microsoft.com> >> > >> > Cc: Jani Nikula <jani.nikula@intel.com> >> > >> > Jani, what bits were you concerned that were not necessarily i2c? >> > I believe although not necessarily/directly i2c, I believe they >> > are related and could benefit from the massive single shot renable. >> > or do you have any better split to suggest here? >> > >> > (more below) >> > >> >> --- >> >> drivers/gpu/drm/i915/display/dvo_ch7017.c | 14 ++++----- >> >> drivers/gpu/drm/i915/display/dvo_ch7xxx.c | 18 +++++------ >> >> drivers/gpu/drm/i915/display/dvo_ivch.c | 16 +++++----- >> >> drivers/gpu/drm/i915/display/dvo_ns2501.c | 18 +++++------ >> >> drivers/gpu/drm/i915/display/dvo_sil164.c | 18 +++++------ >> >> drivers/gpu/drm/i915/display/dvo_tfp410.c | 18 +++++------ >> >> drivers/gpu/drm/i915/display/intel_bios.c | 22 +++++++------- >> >> drivers/gpu/drm/i915/display/intel_ddi.c | 2 +- >> >> .../gpu/drm/i915/display/intel_display_core.h | 2 +- >> >> drivers/gpu/drm/i915/display/intel_dsi.h | 2 +- >> >> drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 20 ++++++------- >> >> drivers/gpu/drm/i915/display/intel_dvo.c | 14 ++++----- >> >> drivers/gpu/drm/i915/display/intel_dvo_dev.h | 2 +- >> >> drivers/gpu/drm/i915/display/intel_gmbus.c | 4 +-- >> >> drivers/gpu/drm/i915/display/intel_sdvo.c | 30 +++++++++---------- >> >> drivers/gpu/drm/i915/display/intel_vbt_defs.h | 4 +-- >> >> drivers/gpu/drm/i915/gvt/edid.c | 28 ++++++++--------- >> >> drivers/gpu/drm/i915/gvt/edid.h | 4 +-- >> >> drivers/gpu/drm/i915/gvt/opregion.c | 2 +- >> >> 19 files changed, 119 insertions(+), 119 deletions(-) >> >> >> >> <snip> >> >> >> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c b/drivers/gpu/drm/i915/display/intel_ddi.c >> >> index c17462b4c2ac..64db211148a8 100644 >> >> --- a/drivers/gpu/drm/i915/display/intel_ddi.c >> >> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c >> >> @@ -4332,7 +4332,7 @@ static int intel_ddi_compute_config_late(struct intel_encoder *encoder, >> >> connector->tile_group->id); >> >> >> >> /* >> >> - * EDP Transcoders cannot be ensalved >> >> + * EDP Transcoders cannot be slaves >> > >> > ^ here >> > perhaps you meant 'targeted' ? >> > >> >> * make them a master always when present >> >> <snip> >> >> This is not actually I2C related as far as I could tell when I was making the change, so this was more of a typo fix. >> >> If we want to improve this, a quick check with the eDP v1.5a spec suggests using primary/secondary instead, >> though in a global fashion rather than specifically for eDP transcoders. There is also source/sink terminology >> in the spec related to DP encoders. >> >> Which would be a more acceptable change here? > > hmmm probably better to split the patches and align with the spec naming where it applies. > and with i2c name where it applies. Yeah this one is completely unrelated to i2c and aux, and what the eDP spec says is irrelevant here. This should follow Intel hw specs. BR, Jani.
Hi, On Fri, May 03, 2024 at 03:34:12PM -0400, Rodrigo Vivi wrote: > On Fri, May 03, 2024 at 06:13:24PM +0000, 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/ > > > > Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> > > Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> > > It looks like the ack is not needed since we are merging this through > drm-intel-next. But I'm planing to merge this only after seeing the > main drivers/i2c accepting the new terminology. So we don't have a > risk of that getting push back and new names there and we having > to rename it once again. I basically agree with this patch (without the eDP part). But the documentation is still not update and I think we need to hold until Wolfram has done that. In any case, it's good to anticipate the reviews. Thanks Easwar, Andi
Am 03.05.24 um 20:13 schrieb Easwar Hariharan: > 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@linux.microsoft.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> > --- > drivers/video/fbdev/smscufx.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/video/fbdev/smscufx.c b/drivers/video/fbdev/smscufx.c > index 35d682b110c4..5f0dd01fd834 100644 > --- a/drivers/video/fbdev/smscufx.c > +++ b/drivers/video/fbdev/smscufx.c > @@ -1292,7 +1292,7 @@ static int ufx_realloc_framebuffer(struct ufx_data *dev, struct fb_info *info) > return 0; > } > > -/* sets up I2C Controller for 100 Kbps, std. speed, 7-bit addr, master, > +/* sets up DDC channel for 100 Kbps, std. speed, 7-bit addr, controller mode, > * restart enabled, but no start byte, enable controller */ > static int ufx_i2c_init(struct ufx_data *dev) > { > @@ -1321,7 +1321,7 @@ static int ufx_i2c_init(struct ufx_data *dev) > /* 7-bit (not 10-bit) addressing */ > tmp &= ~(0x10); > > - /* enable restart conditions and master mode */ > + /* enable restart conditions and controller mode */ > tmp |= 0x21; > > status = ufx_reg_write(dev, 0x1000, tmp);
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@linux.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. Thanks, Easwar [1] https://lore.kernel.org/all/53f3afba-4759-4ea1-b408-8a929b26280c@amd.com/
On Tue, May 7, 2024 at 2:32 PM Easwar Hariharan <eahariha@linux.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@linux.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
On 5/8/2024 7:53 AM, Alex Deucher wrote: > On Tue, May 7, 2024 at 2:32 PM Easwar Hariharan > <eahariha@linux.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@linux.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). Easwar [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=49decddd39e5f6132ccd7d9fdc3d7c470b0061bb
On Wed, May 8, 2024 at 4:12 PM Easwar Hariharan <eahariha@linux.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@linux.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@linux.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@amd.com> > > Easwar > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=49decddd39e5f6132ccd7d9fdc3d7c470b0061bb