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

[Sam Agazaryan]

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

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

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

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


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

Thanks,
Sam