linux-kernel - Re: [PATCH 00/12] i2c: add and start using i2c

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMRc=MeDZf=J4L8M9QTAP+JXGNUFfs1_HyD3fbMOQ18AR29GYw@mail.gmail.com>
Date: Wed, 14 Jan 2026 14:36:42 +0100
From: Bartosz Golaszewski <brgl@...nel.org>
To: Wolfram Sang <wsa+renesas@...g-engineering.com>
Cc: Bartosz Golaszewski <bartosz.golaszewski@....qualcomm.com>, 
	Andi Shyti <andi.shyti@...nel.org>, Chen-Yu Tsai <wens@...nel.org>, 
	Jernej Skrabec <jernej.skrabec@...il.com>, Samuel Holland <samuel@...lland.org>, 
	Khalil Blaiech <kblaiech@...dia.com>, Asmaa Mnebhi <asmaa@...dia.com>, Jean Delvare <jdelvare@...e.com>, 
	Madhavan Srinivasan <maddy@...ux.ibm.com>, Michael Ellerman <mpe@...erman.id.au>, 
	Nicholas Piggin <npiggin@...il.com>, "Christophe Leroy (CS GROUP)" <chleroy@...nel.org>, 
	Andreas Färber <afaerber@...e.de>, 
	Manivannan Sadhasivam <mani@...nel.org>, linux-i2c@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-arm-kernel@...ts.infradead.org, linux-sunxi@...ts.linux.dev, 
	linuxppc-dev@...ts.ozlabs.org, linux-actions@...ts.infradead.org
Subject: Re: [PATCH 00/12] i2c: add and start using i2c_adapter-specific
 printk helpers

On Tue, Jan 13, 2026 at 11:45 AM Wolfram Sang
<wsa+renesas@...g-engineering.com> wrote:
>
> Hi Bart,
>
> > can be *revoked*. To that end we need to hide all dereferences of
> > adap->dev in drivers.
>
> I haven't actually tested the code yet (but will do so this week). But I
> already want to feed back that I approve of the general concept of
> abstracting away drivers access to the struct device by something we can
> then convert to SRCU in a central place.
>
> This mail is to discuss the timeline of these series. My preferred
> solution is to aim for inclusion right after 7.0-rc1 is released. That
> gives me enough time to test and you some more time to address review
> comments. Bold wish, but maybe we can even get dependencies into 6.19
> before (like the i2c_dbg rename for the saa7134 driver. Is there a patch
> for it already?).
>

FYI: I think the road-map will look something like this: v7.1 will get
new interfaces and most controllers under drivers/i2c/ converted as
this can be done within your tree exclusively. For v7.2 (with the new
interfaces upstream) we can think about converting all i2c controller
drivers treewide to the new helpers. Once v7.2-rc1 is tagged, I would
try to remove struct device from struct i2c_adapter locally and send
it to autobuilders for testing. If that goes well, we could create
struct i2c_adapter_private or something like this and store its
address in struct i2c_adapter. This new struct would be controlled by
i2c core and contain struct device. With that out of the way, for v7.4
we could think about adding SRCU into the mix (possibly using the
then-available revocable).

If all goes well, we should be done in early 2027. :)

Bartosz