linux-kernel - Re: [PATCH v2 3/6] i2c: designware: Combine some of the common functions

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: <aVPeQmagzL-QEbIV@kuha>
Date: Tue, 30 Dec 2025 16:14:26 +0200
From: Heikki Krogerus <heikki.krogerus@...ux.intel.com>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: Andi Shyti <andi.shyti@...nel.org>,
	Mika Westerberg <mika.westerberg@...ux.intel.com>,
	Jan Dabros <jsd@...ihalf.com>, Raag Jadav <raag.jadav@...el.com>,
	linux-i2c@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 3/6] i2c: designware: Combine some of the common
 functions

Hi Andy,

> > -	snprintf(adap->name, sizeof(adap->name),
> > -		 "Synopsys DesignWare I2C Slave adapter");
> 
> This patch changes the user visible strings (via `i2cdetect`) or module names
> in case we want to find it by name (note, we already have such precedents for
> other adapters). Currently we have three variants if I not miss anything:
> Generic for master (as in this change), Generic for slave, and AMD platform
> driver case. If you think this is okay change, then just drop the AMD case
> as well, and hence remove the no more needed conditional. Otherwise I would
> somehow group this naming in one place, if possible.

The only thing that this will change is, it removes the common
slave/target only description, because after this that setup is no
longer possible - master mode is now always supported. So this is the
correct thing to do.

I don't think the user space should ever rely on a description like
this except possibly with some customised/non-common systems that the
user space really has to handle in some specific way, but if something
really did rely on this common "target only" description, it could
have only used it to determine that it basically can't use the device
for anything as it's slave/target only - so basically to use it to
check the functionality (same as i2cdetect -F). But as said, this is
no longer a problem.

As for the AMD case, if I understood what you are proposing, I
disagree with you. The glue drivers should always be allowed to assign
the name (these would be the "non-common" systems that the user space
may actually need to know about). I'm also against grouping the
naming. The glue drivers must handle the platform specifics including
the naming if needed, not the core.

thanks,

-- 
heikki