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

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

[Pathak, 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.

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

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

[Alexandre Belloni]

On 12/11/2026 15:22:44-0800, Pathak, Asutosh wrote:
> 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.
> 

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/ati3c2JBNLGRnPen@ashevche-desk.local/T/#mb42d9b2785f8508d39eaf782b3d29189226b8029

https://lore.kernel.org/linux-i3c/20260911210935.1353126-1-meaganlloyd@linux.microsoft.com/

Regards,

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