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

[Alexandre Belloni <alexandre.belloni@bootlin.com>]

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

-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c