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, 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.

[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

Meagan Lloyd (3):
  i3c: master: enable driver_override for I3C
  i3c: set i3c_xfer.actual_len in controller drivers
  i3c: add i3cdev character device module for user-space access

 Documentation/userspace-api/i3c/i3cdev.rst    | 152 ++++
 .../userspace-api/ioctl/ioctl-number.rst      |   1 +
 MAINTAINERS                                   |   7 +
 drivers/hwmon/lm75.c                          |   7 +-
 drivers/hwmon/tmp108.c                        |   2 +
 drivers/i3c/Kconfig                           |  12 +
 drivers/i3c/Makefile                          |   1 +
 drivers/i3c/i3cdev.c                          | 730 ++++++++++++++++++
 drivers/i3c/master.c                          |   6 +
 drivers/i3c/master/adi-i3c-master.c           |   5 +-
 drivers/i3c/master/dw-i3c-master.c            |   4 +-
 drivers/i3c/master/i3c-master-cdns.c          |   5 +-
 drivers/i3c/master/mipi-i3c-hci/core.c        |   5 +-
 drivers/i3c/master/renesas-i3c.c              |   3 +
 drivers/iio/adc/ad4062.c                      |  10 +-
 drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i3c.c   |   3 +
 include/uapi/linux/i3c/i3cdev.h               |  70 ++
 17 files changed, 1016 insertions(+), 7 deletions(-)
 create mode 100644 Documentation/userspace-api/i3c/i3cdev.rst
 create mode 100644 drivers/i3c/i3cdev.c
 create mode 100644 include/uapi/linux/i3c/i3cdev.h


base-commit: cab40cfc9e116acd4d60f95b4b1264cab78f3803
-- 
2.49.0

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

> 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

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

On Wed, Sep 16, 2026 at 12:28:57PM -0700, Meagan Lloyd wrote:
> 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.

Nope, the series fixes the bug and at the same time refactored to provide a
generalised solution. The driver_override as a concept exists for ages.

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

...

> > > 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

> 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

Nope, you are mistaken. As I explained the opaque 1.0.0 means nothing. The Git
SHA *is* the version of the code in question.

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

This is really orthogonal. But yes, keeping tools at the kernel source tree
makes sense for a better maintenance.

-- 
With Best Regards,
Andy Shevchenko