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

[Andy Shevchenko <andriy.shevchenko@intel.com>]

On Tue, Oct 20, 2026 at 02:20:16PM -0700, Sam Agazaryan wrote:
> > Did I miss this in the initial explanation? If not, please add it next time.
> 
> That is just how the existing I3C core enumerates targets during DAA,
> not something added by this series. I will add a sentence to the
> cover letter and Patch 4 commit message in v6 contrasting it with
> i2c-dev to make that context clear.
> 
> > 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)?
> 
> Yes, this is used in real systems today:
> 
> 1. Tooling & production users:
> 
> - i3ctransfer (Patch 5/5 of this series, and carried out-of-tree in
> AspeedTech-BMC/i3c-tools and vendor OpenBMC BSPs for several
> years).

So, nothing in production, meaning we can design that in kernel differently.

> - OCP Secure Firmware Recovery (DCR 0xBD) [1] and Caliptra Root-of-Trust
> recovery agents on OpenBMC/gBMC platforms (e.g., AST2700 / Caliptra
> MCU recovery tooling and BMC recovery daemons). Because Vitor's
> original i3cdev series was not merged in 2019, multiple silicon
> vendors and OpenBMC trees have been carrying out-of-tree forks of i3cdev;
> upstreaming consolidates those diverging implementations.
> 
> 2. Why an ioctl is required over a read and write:
> 
> - In the OCP Secure Firmware Recovery v1.1 specification (Section
> 8.4, "Recovery I3C Interface Block Read via Private Write and
> Private Read"), every recovery command read is a combined transaction
> consisting of a Private Write with no STOP, followed by a Repeated START,
> followed by a Private Read, and finally a STOP.
> 
> - Because write() and read() only submit a single transfer at a time
> (nxfers = 1), the controller emits a STOP condition on the wire
> at the end of write() and drops the bus lock. Submitting multiple
> i3c_ioc_xfer descriptors in a single I3C_IOC_XFER(N) ioctl is
> required so i3c_device_do_xfers() queues them together under one
> bus lock acquisition and the controller emits a Repeated START
> between messages (as well as passing HDR mode/cmd parameters).

Thanks, probably I was unclear, my specific question was why this needs a user
space to issue those recovery flows. And why it needs to be IOCTL-based and not
some higher level one.

> [1] https://www.opencompute.org/documents/ocp-recovery-document-1p1-final-pdf
> 
> > 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?
> 
> Note that a user does not need to recompile the kernel if a kernel
> driver binds to a device they wish to access via i3cdev. Because i3cdev
> handles BUS_NOTIFY_UNBOUND_DRIVER, unbinding the kernel driver at
> runtime via sysfs:
> 
> echo <dev> > /sys/bus/i3c/devices/<dev>/driver/unbind
> 
> automatically triggers i3cdev_attach() and exposes /dev/bus/i3c/<dev>
> without rebuilding the kernel.

Oh, that's quite a dangerous "feature"! Can we avoid doing that? Otherwise it
means any missed guard against unbind for the system controller related chips
may lead to real HW damage. I'm totally against this feature to be in any way
of an ABI. If you want that, do it exclusively via debugfs with a big fat
warning that this may lead to HW damages.

> Also, I3C drivers match against a
> target's MIPI-assigned DCR or 48-bit PID (Manufacturer ID + Part ID),
> so a driver for a simple device will not accidentally match a different
> chip's PID or a dedicated DCR like 0xBD.

Yes, but we are talking about opening a Pandora's box in user space, aren't we?

> > P.S> Still not convinced, that this has to be an ABI. For debugfs and something
> > like this, no objections, but ABI.
> 
> Production BMC recovery daemons cannot rely on debugfs, which is
> optional and restricted or unmounted on production builds. A character
> device in /dev/bus/i3c/* provides the stable ioctl those tools need and
> integrates with udev so non-root daemons can be granted access to
> specific target nodes (e.g. matching on DCR 0xBD), similar to spidev
> and hidraw.

But why recovery mechanism can't be kernel-driven? With some sysfs
(just as an example) knobs to say "I want to run now a recovery flow
on this bus", et cetera.

> > Forgot to ask, but do they interfere?
> 
> Is this in reference to i2c devices on the i3c bus? No, I3C transfers
> and legacy I2C transfers on a mixed-mode bus do not interfere:
> 
> 1. Both i3c_device_do_xfers() and i3c_master_i2c_adapter_xfer() acquire
> i3c_bus_normaluse_lock(&master->bus), so I3C and I2C transactions on
> the same bus are serialized by the I3C core.
> 
> 2. Attached I2C client addresses are marked as I3C_ADDR_SLOT_I2C_DEV in
> the bus address slot table, preventing DAA from assigning an I2C
> device's address to an I3C target.

Can i2c device require an i2c recovery flow on the bus? If so, how would
it be combined together with the i3c recovery flow(s)?

-- 
With Best Regards,
Andy Shevchenko