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: <aWe0qYCOFNww_wSL@ninjato>
Date: Wed, 14 Jan 2026 16:22:17 +0100
From: Wolfram Sang <wsa+renesas@...g-engineering.com>
To: Bartosz Golaszewski <brgl@...nel.org>
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


> 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. :)

With this plan, what could possibly go wrong? :)


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ