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

[Sam Agazaryan]

Hey Wolfram and Andy,


Andy:

> I do not know how we end up here. The not-settled yet discussion is in
> thread with aqt_dCazxTDR4cpk@ashevche-desk.local.

There has been some back and forth but I originally uploaded this
patch set using
notifiers for binding looking for comments on the revival of a
potential upstream
i3cdev driver - Meagan had been working on a similar effort with i3cdev
using a different approach for binding and as of right now the bus notifier
approach seems to be more favored, but not approved nor decided on yet.

> But I have a big concern about exposing i3c to user space in the way we have it
> in i2c. Taking into account that i2c is an odd bus and might lead even to HW
> *physical* breakage, I would thing 100 times before making the same mistake
> in i3c. If you ever want to do this, this must not be user visible feature
> (hidden under expert and debug and maybe even more guards for the starter).
>

Just to make sure we're on the same page here about this - is your concern that
we can arbitrarily address any device on the i3c bus at-will as is the case
with i2c-dev?

FWIW, i3cdev as it exists in this patchset does not have as much free reign
over the i3c bus as i2c-dev does over an i2c bus:

1. i3cdev attaches to discrete target devices rather than exposing the
bus as a whole.
This means if I have 5 devices on my electrical bus that are up and operational
and 4 of them have a proper i3c driver to bind to (E.G. mctp-i3c) then
i3cdev will
not touch those devices, only the 5th device without a bound driver and
that would be via the i3cdev instance created specifically for that
device. A matching
kernel driver being found for a device later means i3cdev
automatically detaches itself
and makes way for a compatible client driver to bind.

2. Master controllers are also not a binding option for the driver, so
no free access to
send out arbitrary CCCs, perform bus scans, do DAA work, etc.

CONFIG_I3CDEV defaults to n and only creates root-owned character
devices for unbound targets, though if i3c maintainers prefer adding
"depends on EXPERT" or expanding the Kconfig help text, I am happy to do
that in v6.

Wolfram:

> >> Userspace access to I3C targets is needed for devices that do not have a
> >> kernel driver bound to them, such as targets in ROM/bootloader recovery
> >> mode (e.g., OCP Secure Firmware Recovery v1.1 and Caliptra Silicon Root of
> >> Trust recovery flows), as well as hardware bring-up and diagnostics.
>
> I don't know anything about these recovery mechanisms and their needs. I
> might have time to look into I3C things after all the conferences in
> Prague, but no promises...

Targets such as Caliptra (Silicon Root of
Trust), SoCs, and accelerators implement the OCP Secure Firmware
Recovery specification over I3C. When a target's runtime firmware is
corrupted, unprovisioned, or fails secure boot, its ROM/bootloader
exposes an I3C target endpoint implementing the OCP Recovery register
interface (PROT_CAP, DEVICE_ID, DEVICE_STATUS, RECOVERY_CTRL,
INDIRECT_FIFO_DATA) over standard I3C private transfers.

Per Section 8.4 of the OCP Secure Firmware Recovery v1.1 spec [1],
because I3C does not have native SMBus-style block transfers, the
recovery protocol emulates them over I3C using framed Private Write
transfers and combined Private Write + Repeated START Private Read
transfers (with PEC) to poll status/reason registers, pull crash logs
from Component Memory Spaces (CMS), stream signed recovery images into
the FIFO, and trigger activation.

The spec defines this same command set across SMBus, USB EP0, and I3C so
that a userspace Recovery Agent on a BMC can drive the recovery,
diagnostic log extraction, and attestation workflow across transports
(using i2c-dev for SMBus, usbfs/libusb for USB EP0, and i3cdev for I3C),
alongside general hardware bring-up and vendor-specific provisioning.

[1] https://www.opencompute.org/documents/ocp-recovery-document-1p1-final-pdf/

Thanks,
Sam