Re: [PATCH 0/3] I3C character device driver using driver_override

[Meagan Lloyd <meaganlloyd@linux.microsoft.com>]

On Sat, Sep 12, 2026 at 04:26:28PM +0300, Andy Shevchenko wrote:
> On Fri, Sep 11, 2026 at 02:09:32PM -0700, Meagan Lloyd wrote:
> > This is a rework and revival option for Vitor Soares' I3C character
> > device driver patch series from 2020 [1] that I've been exploring for a
> > few months.  Recently there was a revival posted to the list [2], so I
> > wanted to share this design option as well.
> > 
> > In [1] and [2], the i3cdev driver automatically attaches and detaches
> > depending whether another driver has attached/not. In [1], Boris was
> > suggesting we explore a more straightforward and traditional binding
> > method aligning with the Linux driver model. At the time, there wasn't
> > a way to auto-bind while keeping manual binding possible as they shared
> > the same match() hook. Now with the new driver_override feature,
> 
> Where is it new? It's quite an old mechanism in the driver core...

My understanding is that this support was added in March 2026 here:
https://lore.kernel.org/all/20260303115720.48783-1-dakr@kernel.org/

Some busses had their own version of this, but the above series made
a general, re-usable solution available.

> 
> > the auto-binding of i3cdev on boot can be avoided if the i3cdev driver has
> > an empty match ID table. After boot, where specialized drivers would have
> > already bound, user-space can explicitly opt-in by setting the
> > driver_override sysfs file with 'i3cdev' and manually binding via sysfs
> > (or by simply loading the driver if it's loadable). This can also be
> > easily automated with udev rules that run whenever the I3C core exposes
> > a new device.
> > 
> > One downside of the automatic attach/de-attach is that if a different
> > driver is loaded later, the first driver could have altered something
> > on the device, breaking any assumptions of the subsequent driver.
> > 
> > My series builds on [1] through:
> > 0. Addressing code review feedback in [1] from Greg, Boris, and Randy.
> > 1. Using actual_len for accurate read response reporting. The kernel
> > will report actual_len received from the core to user-space via the
> > uapi i3cdev_xfer struct.
> > 2. Placing limits on the number of transfers and bytes in requests to
> > prevent unlimited-sized transfers or kernel memory allocation
> > 3. Checking inputs and descriptive return codes as guard-rails
> > for user-space and to ease use of the i3cdev driver
> > 4. Checking on MWL to ensure that we respect device limits
> > 5. Proper lifetime management of i3cdev_data and underlying device
> > 6. Addressing dangling fops in the event we have an open file descriptor
> > when a device gets unbound.
> > 7. Fast-path locking to ensure transfers complete before a device is
> > unbound.
> > 8. Allowing only one file descriptor per I3C device to avoid bugs
> > around multiple processes interacting with the device and altering
> > the device underneath the other. For example, without this, one process
> > could change the device's page or address pointer register underneath
> > the other process.
> > 9. copy_struct_from_user to ensure struct i3cdev_xfer could be extended
> > in a compatible way. This is to be forward-looking towards potential
> > HDR mode expansion and code reuse.
> > 10. Reserving the IOCTL number formally
> > 11. Updating the Documentation to be a syntax correct example program
> > template.
> > 12. Preserving /dev/bus/i3c/<bus id>-<Provisional ID> naming while
> > allowing sysfs path to be neatly named i3cdev-<minor>. This avoids
> > repeated <bus id>-<Provisional ID> in the sysfs paths which can be
> > confusing/circular-looking.
> >     e.g. /sys/bus/i3c/devices/0-deadbeef001/i3cdev/0-deadbeef001 ->
> >          /sys/bus/i3c/devices/0-deadbeef001/i3cdev/i3cdev-0
> > 13. Updating all naming references related to i3c_priv_xfer to align
> > with new i3c_xfer struct
> > 14. Updating the MAINTAINERS file for the new pieces of code
> > 
> > Note that i3c-tools [3] or a fork of it will need small updates:
> > 1. Update include/uapi/linux/i3c/i3cdev.h to match updated uapi structs
> > 2. In i3ctransfer.c, use actual_len for reads
> 
> > I've added MODULE_VERSION("1.0.0") in the i3cdev driver, so i3c-tools
> > could use that to determine whether to use the old out-of-tree uapi or this one.
> 
> Absolutely no. This is legacy macro which has no need since Git era. In Git
> the module version is the Git SHA hash of the tip of the used tree. Nobody will
> understand what 1.0.0 means and how it maps to the applied patches (if any of
> them affects the behaviour of the feature in question).
> 
> On top of that, upstream has no clue what and how many possible custom ABIs /
> UAPIs exists, and we do not care, to be honest.
> 
> > [1] https://lore.kernel.org/linux-i3c/cover.1582069402.git.vitor.soares@synopsys.com/
> > [2] https://lore.kernel.org/linux-i3c/ap_1-gFF7S821xJT@ninjato/T/#m9107c1785a4a16b1b3cb84c3269d17fac35819c8
> > [3] https://github.com/vitor-soares-snps/i3c-tools
> 
> -- 
> With Best Regards,
> Andy Shevchenko
>

My reasoning was that i3c-tools has been around for years now and it may
be in-use assuming the UAPI from [1]. Adding MODULE_VERSION was a low
effort, compatible, and reliable way to keep using the same i3c-tools
repo (and accommodate a changed UAPI).

In any case, in Sam's thread [2], there is talk of moving i3c-tools into
the kernel's tools directory. That's the better solution, so I can drop
the MODULE_VERSION in future revisions.

Thank you,
Meagan