linux-kernel - Re: [PATCH 2/3] i2c: designware: Enable transfer with different target addresses

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aPic0NtVkzpZJUuz@shikoro>
Date: Wed, 22 Oct 2025 10:58:56 +0200
From: Wolfram Sang <wsa+renesas@...g-engineering.com>
To: Benoît Monin <benoit.monin@...tlin.com>
Cc: Andi Shyti <andi.shyti@...nel.org>, Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Jarkko Nikula <jarkko.nikula@...ux.intel.com>,
	Mika Westerberg <mika.westerberg@...ux.intel.com>,
	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
	Jan Dabros <jsd@...ihalf.com>,
	Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
	Clark Williams <clrkwllms@...nel.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Hans Verkuil <hverkuil+cisco@...nel.org>,
	Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
	Gregory CLEMENT <gregory.clement@...tlin.com>,
	Théo Lebrun <theo.lebrun@...tlin.com>,
	Tawfik Bayouk <tawfik.bayouk@...ileye.com>,
	Vladimir Kondratiev <vladimir.kondratiev@...ileye.com>,
	Dmitry Guzman <dmitry.guzman@...ileye.com>,
	linux-i2c@...r.kernel.org, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-rt-devel@...ts.linux.dev
Subject: Re: [PATCH 2/3] i2c: designware: Enable transfer with different
 target addresses

Hi Benoît,

> This patch replaces a -EINVAL in the middle of the transfer by a
> STOP-then-START, but you are right, the expectation is to have a single
> STOP at the end of a combined transfer. I somehow overlooked that part.

Yes. Sadly, the designware controllers are broken in that regard, it
seems :(

> Maybe I could add support for the I2C_M_STOP flag instead? Or does an
> adapter has to support all the protocol mangling if flagged with
> I2C_FUNC_PROTOCOL_MANGLING?

It doesn't. It is a known weakness of I2C_FUNC_PROTOCOL_MANGLING. Maybe
we could extrapolate it like we did for I2C_FUNC_NOSTART? Just an idea,
I haven't really looked into it.

> That would still allow to group multiple accesses to device that support a
> STOP in a transaction when done via i2c_dev I2C_RDWR ioctl, in a single-master
> configuration.

I'd think such transfers are super rare but if you still want to
implement it, please do. Note that some devices will still not work
because they reset their state machine on STOP. See Hans' example.

Happy hacking,

   Wolfram


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