Re: [PATCH v5 0/5] i3c: add i3cdev module to expose i3c dev in /dev

[Alexandre Belloni <alexandre.belloni@bootlin.com>]

On 22/10/2026 17:17:20-0700, Sam Agazaryan wrote:
> > On my side, I believe i3cdev can be added to the kernel and that it is
> > way safer than i2cdev but I agree that the ABI has to be properly
> > designed, maybe we need to version it or have a way to probe for
> > supported features so we can update safely later on. It is failry simple
> > right now but I feel like we are going to see people with more needs
> > than initiating transfers.
> 
> For feature probing and ABI extension, what do you think of:
> 
> 1. Adding an extensible I3C_IOC_GET_CAPS ioctl:
> 
>    struct i3c_ioc_caps {
>        __u32 size; /* sizeof(struct i3c_ioc_caps) */
>        __u32 pad;  /* must be 0 */
>        __u64 caps; /* Bitmask of supported I3C_CAP_* features */
>    };
> 
>    Today caps can report the transfer modes supported by the controller
>    and target (I3C_CAP_SDR, I3C_CAP_HDR_DDR, I3C_CAP_HDR_TSP,
>    I3C_CAP_HDR_TSL), and new bits in caps (or new fields appended to
>    the end of the struct) can advertise future capabilities beyond basic
>    transfers.

This works but my point was also that we need to expose the i3cdev
capabilities so userspace can discover what is available. I guess we can
assume .read and .write are going to always be available and so this is
fine for now.

> 
> 2. In struct i3c_ioc_xfer, we already have __u8 pad[2] at the end which
>    is strictly checked to be 0 (-EINVAL if non-zero), reserving 16 bits
>    for future per-transfer flags without changing the struct size.
> 
> > Also, I think this should not bind to any devices by default and make
> > binding explicit.
> 
> This seems to be the consensus so far. I can convert i3cdev from a bus
> notifier into a standard struct i3c_driver so it does not auto-attach
> to all unbound targets on boot or on unbind while dropping patches 1
> and 2.
> 
> Since Greg KH noted earlier [1] that driver_override / manual sysfs
> bind is only for debugging and will taint the kernel in the near
> future, what do you think of:
> 
> Matching explicit opt-in entries in i3cdev's i3c_device_id table (starting
> with 0xBD for OCP Secure Firmware Recovery), and optionally
> exposing a new_id sysfs attribute on the i3cdev driver for dynamically
> adding target IDs at runtime? That also keeps everything self-contained
> in i3cdev without needing cross-subsystem changes to hwmon/iio drivers.
> 

We can add new_id later if necessary.

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com