On Tue, Jan 13, 2026 at 11:45 AM Wolfram Sang <[email protected]> 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
