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

[Sam Agazaryan]

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

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

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.

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



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

Thanks,
Sam