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

[Andy Shevchenko]

On Mon, Oct 19, 2026 at 12:45:11PM +0300, Andy Shevchenko wrote:
> On Sun, Oct 18, 2026 at 01:28:44PM -0700, Sam Agazaryan wrote:
> > > Yes and more as this bus (i3c) is still non-discoverable (am I mistaken?).
> > 
> > I3C is a dynamically discoverable bus. During DAA each I3C target reports a
> > Provisioned ID (PID), Bus Characteristic Register (BCR), and Device
> > Characteristic Register (DCR), and is assigned a dynamic address by the
> > controller.
> 
> Did I miss this in the initial explanation? If not, please add it next time.
> 
> > > This makes even less usefulness in my eyes. Immediate Q: if 4 already have the
> > > proper driver in the kernel, what's wrong to make it for the fifth one?
> > 
> > 1. The original use case was hardware bring-up, silicon validation, and debug
> > (i3ctransfer): Just like spidev, engineers need a debug interface
> > to issue ad-hoc SDR/HDR transfers during bring-up or hardware validation before
> > a driver exists.
> 
> Totally debug feature to me. Once you expose something in /dev (imply IOCTL),
> it will become an ABI. And I'm fully against this.
> 
> > 2. Userspace firmware recovery / update tools (OCP Secure Firmware
> > Recovery, Caliptra RoT):
> > The recovery protocol is purely a polled request/response transport
> > (no IBIs allowed per spec) used by userspace update tooling (fwupd / BMC
> > recovery daemons) to parse signed firmware manifests, stream recovery image
> > chunks to INDIRECT_FIFO_DATA, and poll RECOVERY_STATUS—similar to how
> > userspace firmware updaters operate over spidev, hidraw, or USB/NVMe ioctls
> > rather than putting firmware image parsing and update policy inside the
> > kernel. In my response to Wolfram above I discussed this some more.
> 
> Do we have such use cases IRL? Do we have tooling support (at least pending)
> somewhere? Why does it require user space interaction in _this_ way (meaning
> IOCTL and /dev node)?
> 
> > > What if the device needs more? Or if this is a multi-functional device that
> > > may have driver for only one part?
> > 
> > If a device needs more than basic transfers (such as IBIs,
> > hot-join handling, or integration with a subsystem like hwmon/iio/mctp),
> > it should use a dedicated kernel driver.
> > 
> > For multi-function devices, if the functions are exposed as MIPI I3C
> > Targets (e.g. a device exposing both an mctp-i3c interface and
> > an OCP recovery interface), each virtual target is assigned its own
> > dynamic address and DCR during ENTDAA and is enumerated as a distinct
> > i3c_device instance on the bus. Conversely, if multiple functions share
> > a single I3C target address and register map, i3cdev intentionally does
> > not allow userspace to access a target while a kernel driver is bound
> > to it (avoiding the I2C_SLAVE_FORCE problem where userspace can race
> > with a bound driver), so that case should be handled by an in-kernel
> > MFD driver - but that is not the use case being targeted here with OCP
> > recovery.
> 
> So, imagine that someone submits a kernel driver for a simple device, while
> another person already uses the driver for multi-functional device where the
> former one is driving only part of it. Strictly speaking the kernel driver
> submission becomes a user space regression. Which effectively means that whenever
> you open i3cdev, no other kernel drivers may appear. Yes, I understand that
> a poor victim of such an unlikely course of events may recompile the kernel,
> disable driver, et cetera, but this still raises the same question, why do
> we do that to the mere users?
> 
> > > What to do with the i2c devices connected to i3c bus in the compatible mode?
> > 
> > I3C master controllers register an i2c adapter for i2c devices running on an
> > i3c mixed mode bus - they are identified as i2c_bus_type, not i3c.

Forgot to ask, but do they interfere?

> P.S> Still not convinced, that this has to be an ABI. For debugfs and something
> like this, no objections, but ABI.

-- 
With Best Regards,
Andy Shevchenko