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

From: Alexandre Belloni <alexandre.belloni@bootlin.com>
To: Sam Agazaryan <samagazaryan@google.com>
Cc: Andy Shevchenko <andriy.shevchenko@intel.com>,
	Wolfram Sang <wsa+renesas@sang-engineering.com>,
	linux-i3c@lists.infradead.org, Frank Li <Frank.Li@nxp.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Meagan Lloyd <meaganlloyd@linux.microsoft.com>,
	Vitor Soares <vitor.soares@toradex.com>,
	Oleksandr Shulzhenko <oleksandr.shulzhenko.viktorovych@intel.com>,
	Boris Brezillon <boris.brezillon@collabora.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 0/5] i3c: add i3cdev module to expose i3c dev in /dev
Date: Thu, 12 Nov 2026 10:41:37 +0100	[thread overview]
Message-ID: <202611120941378508d6e0@mail.local> (raw)
In-Reply-To: <CAHreonH0maC6iU1fkwv9VvWzZfh=W_ybB8R6CLbXQmKQL+x-=g@mail.gmail.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

-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c