i3c: USB-I3C (class 0x3C) master + userspace access - which way do you want it?

RFC Pathak, Asutosh 2 participants 2 messages Nov 12

Subsystems (2)

USB I3C

lore

Share & tools

lore

Pathak, Asutosh

author

2026-11-12 23:22 UTC #0 lore raw

Hi Alexandre,

Before I send a real series I want to settle one design question, because the answer decides whether half of this is even worth submitting.

We have an out-of-tree driver for the USB-I3C device class (USB class 0x3C) - a USB device that bridges the host to an I3C bus. It's two modules:

- a controller driver: USB class driver that also calls i3c_master_register() and implements the usual master ops (do_daa, send_ccc_cmd, priv xfers, IBI). It's a normal I3C master that just happens to talk over USB. I think this belongs in drivers/i3c/master/ and goes upstream the usual way.

- a target driver: binds the I3C devices behind it and hands a char dev + ioctls to userspace (OpenIPC and similar tools) so they can drive the bus.

The whole reason this hardware exists is userspace-driven I3C from a host PC. But as far as I can tell the I3C subsystem has no userspace interface at all - no i3c-dev, no uapi header - so anything we add there is new ABI you'd have to live with. Hence the RFC instead of a patch bomb.

So, which of these do you want?

a) nothing in userspace upstream - we only send the master, keep the ioctls out of tree.
b) a generic i3c-dev (like i2c-dev), proper include/uapi/linux/i3c-dev.h, usable by any master. Happy to do it, but I'm not going to design that ABI without you on board.
c) what we already have: the controller stays a pure master with no userspace ABI, and the target side is a normal I3C device driver (drivers/i3c/device.c) where each bound target exposes its own char dev + ioctl and reaches the bus through the standard priv-xfer path. It's the least churn for us and matches our architecture doc - so if you're fine with a per-target ioctl node living inside the USB-I3C driver (not a generic subsystem ABI), we'll run with it.

I'll build whichever one you pick.

Rough plan either way: master in drivers/i3c/master/ first (useful on its own, no userspace ABI), then the userspace piece separately, then docs + MAINTAINERS.

Mainly I'd like your call on (a)/(b)/(c), and confirmation that a USB-transport master is OK in drivers/i3c/master/. For what it's worth (c) is our preference, since it's already working and keeps the ABI contained. Would rather get this right now than argue about it at v3.

Thanks,
Asutosh

Alexandre Belloni

maintainer

2026-11-12 23:35 UTC #1 lore raw

Quoted 37 lines · Asutosh

Hi Alexandre,
Before I send a real series I want to settle one design question, because the answer decides whether half of this is even worth submitting.
We have an out-of-tree driver for the USB-I3C device class (USB class 0x3C) - a USB device that bridges the host to an I3C bus. It's two modules:
- a controller driver: USB class driver that also calls i3c_master_register() and implements the usual master ops (do_daa, send_ccc_cmd, priv xfers, IBI). It's a normal I3C master that just happens to talk over USB. I think this belongs in drivers/i3c/master/ and goes upstream the usual way.
- a target driver: binds the I3C devices behind it and hands a char dev + ioctls to userspace (OpenIPC and similar tools) so they can drive the bus.
The whole reason this hardware exists is userspace-driven I3C from a host PC. But as far as I can tell the I3C subsystem has no userspace interface at all - no i3c-dev, no uapi header - so anything we add there is new ABI you'd have to live with. Hence the RFC instead of a patch bomb.
So, which of these do you want?
a) nothing in userspace upstream - we only send the master, keep the ioctls out of tree.
b) a generic i3c-dev (like i2c-dev), proper include/uapi/linux/i3c-dev.h, usable by any master. Happy to do it, but I'm not going to design that ABI without you on board.
c) what we already have: the controller stays a pure master with no userspace ABI, and the target side is a normal I3C device driver (drivers/i3c/device.c) where each bound target exposes its own char dev + ioctl and reaches the bus through the standard priv-xfer path. It's the least churn for us and matches our architecture doc - so if you're fine with a per-target ioctl node living inside the USB-I3C driver (not a generic subsystem ABI), we'll run with it.
I'll build whichever one you pick.

Quoted 8 lines

Rough plan either way: master in drivers/i3c/master/ first (useful on its own, no userspace ABI), then the userspace piece separately, then docs + MAINTAINERS.
Mainly I'd like your call on (a)/(b)/(c), and confirmation that a USB-transport master is OK in drivers/i3c/master/. For what it's worth (c) is our preference, since it's already working and keeps the ABI contained. Would rather get this right now than argue about it at v3.

USB-transport master is not an issue and you can submit it. For the i3c-dev related question, you should probably have a look at the current threads so you can add your use case:

https://lore.kernel.org/linux-i3c/[email protected]/T/#mb42d9b2785f8508d39eaf782b3d29189226b8029

https://lore.kernel.org/linux-i3c/[email protected]/

Regards,

Signature · 3 lines

Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com