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

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

On Mon, Sep 21, 2026 at 11:05:58PM +0000, Sam Agazaryan wrote:
> This patch series introduces the i3cdev module, exposing unbound I3C
> target devices to userspace via character device nodes (/dev/bus/i3c/*),
> along with the i3ctransfer userspace utility in tools/i3c/.
> 
> 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.
> 
> When a kernel driver later binds to an I3C device (for example via
> dynamic module loading), i3cdev automatically detaches via the
> BUS_NOTIFY_BIND_DRIVER notifier so kernel drivers always take
> precedence.
> 
> Testing status:
> This v5 series has been compile-tested across all modified I3C controller
> drivers with W=1. Posting v5 now so collaborators and controller owners
> can test the unified UAPI and actual_len updates on their respective
> hardware and provide Tested-by tags while we complete final hardware
> verification of the v5 updates on our platform.

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

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

Personally from my perspective this is no go, but I'm not a maintainer here.

P.S.
And you need to gather the opinion of Wolfram as well.

-- 
With Best Regards,
Andy Shevchenko