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

[Andy Shevchenko]

On Thu, Oct 22, 2026 at 01:23:10PM -0700, Sam Agazaryan wrote:
> > > 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.

Okay, but they are not (obviously) use the upstream solutions for that.

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

A-ha, so this is a device programming protocol on the top of the i3c 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.

But it's still unclear to me why this can't be moved to the kernel space?
There is no user space that communicates with upstream kernel in the way
you described, they should have used a custom (out-of-tree) solutions, right?

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

But how it will do if the i2c device blocks the i3c bus in mixed mode?
I mean, how will it affect the i3c transfers on the wire?

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

Good to know, thanks!

-- 
With Best Regards,
Andy Shevchenko