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

[Sam Agazaryan]

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

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.


[1] https://lore.kernel.org/linux-i3c/2026091834-bats-palpitate-5614@gregkh/


Thanks,
Sam