linux-kernel - Re: [PATCH v0 00/14] Make I2C terminology more inclusive for I2C Algobit and consumers

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: <20240407175039.za3eg7la7i2jwvun@kunai>
Date: Sun, 7 Apr 2024 19:50:39 +0200
From: Wolfram Sang <wsa+renesas@...g-engineering.com>
To: Easwar Hariharan <eahariha@...ux.microsoft.com>
Cc: "open list:RADEON and AMDGPU DRM DRIVERS" <amd-gfx@...ts.freedesktop.org>,
	"open list:DRM DRIVERS" <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: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 00/14] Make I2C terminology more inclusive for I2C
 Algobit and consumers

Hi Easwar,

> Sorry, got excited. :) There were drivers I'd been part of that I specifically
> wanted to fixup, but then the scope grew to other users of algobit.

Well, you got some positive feedback, so that is good.

> > It is true that I changed quite some controller drivers within the i2c
> > realm. I did this to gain experience. As you also noticed quite some
> > questions came up. We need to agree on answers first. And once we are
> > happy with the answers we found, then IMO we can go outside of the i2c
> > realm and send patches to other subsystems referencing agreed
> > precedence. I intentionally did not go outside i2c yet. Since your
> > patches are already there, you probably want to foster them until they
> > are ready for inclusion.
> 
> Sorry, I don't quite follow what you mean by foster in this context. Are
> you asking me to hold off on merging the series, or to follow through on
> getting it merged?

I think they are your patches, so this is up to you to decide. With
"foster", I meant you keep working on them until everyone is happy. I
haven't looked at the drivers you modify. I can't tell if they can be
converted right away or if they use a lot of I2C API calls, so that it
makes sense to wait until the core is converted. I trust you to decide
this.

Happy hacking,

   Wolfram

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)