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

[Andy Shevchenko]

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.

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