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

[Sam Agazaryan]

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

In hindsight I should have ordered that list differently, the second bullet
right below that is the production use case: production BMC firmware update
and recovery daemons running in OpenBMC server fleets (managing Caliptra
Root-of-Trust and SoC recovery targets over I3C), as well as production
server accelerator management daemons.

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

To make sure we're talking about the same thing: "OCP Secure Firmware
Recovery" is not electrical bus recovery (like recovering an i2c or
i3c bus itself by bit-banging to unstick a hung bus). It is device
firmware recovery and provisioning (similar in concept to USB DFU) to
recover and boot a target device that sits on the bus.

This lives in userspace because it is part of the BMC's Redfish/RoT
firmware management stack (handling network image streaming, signing/key
management, and chassis-level recovery policies), rather than a single
"recover this bus" hardware toggle. And it uses I3C_IOC_XFER because
each protocol register read/write requires combined Write + Repeated
START + Read transfers (or HDR transfers) to that specific target node.

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

Agreed -- as Alexandre also suggested in his reply, it sounds like
automatic binding isn't favored here due to risk of hardware damage.

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

If you mean electrical bus recovery, i3cdev doesn't perform
bus-level electrical recovery. It only submits normal target-addressed
transfers via i3c_device_do_xfers().

If you mean OCP device firmware recovery on a mixed bus:

An I2C recovery target on a mixed bus uses standard SMBus Block
Read/Write transactions through the controller's i2c_adapter (not
i3cdev) while an I3C recovery target uses I3C Private Write/Read
transfers via i3cdev. On a mixed bus, the Linux I3C core already
configures the bus mode/SCL rate according to the I2C targets' LVR
spike-filter capabilities and serializes both paths via
i3c_bus_normaluse_lock(&master->bus).


Thanks,
Sam