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

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

On 13/11/2026 10:11:36-0800, Pathak, Asutosh wrote:
> Hi Sam,
> 
> Alexandre pointed me at this series. I'm working on a driver for the USB-I3C
> device class (USB class 0x3C) - a USB device that acts as an I3C controller,
> with a host-side tool (OpenIPC) that drives the bus from userspace. The master
> part registers normally, so its targets would show up as i3cdev nodes and we'd
> rather use I3C_IOC_XFER than carry our own ioctls. So +1 on the direction.
> 
> A few things we need that the current UAPI doesn't cover yet - wanted to raise
> them now rather than after it lands:
> 
> 1. IBIs to userspace. Our main use case is reacting to target interrupts, but
>    i3cdev is transfer-only today. We'd need a way to get IBIs (and ideally
>    hot-join) delivered to the fd - poll()/read() of an event, or similar.
>    This is the big one for us.
> 
> 2. Larger transfers. len/actual_len are u16 and I3C_IOC_XFER caps the count.
>    Our bulk flows go past 64K, so we'd want either a larger width or a
>    documented way to split without dropping the bus lock mid-sequence.
> 

Hum, seeing 1 and 2 now, shouldn't you rather have an actual kernel
driver to handle the devices present on the i3c bus? What are those
devices?

> 3. Explicit opt-in over auto-attach. For bring-up/validation we don't want a
>    node appearing just because a driver got unbound - Meagan's driver_override
>    approach fits us better, and it also answers Andy's HW-damage concern.
> 
> 4. CCCs from userspace. The union { rnw; cmd; } looks like it's meant for this -
>    just confirming direct/broadcast CCCs are in scope, since our tooling needs
>    them.
> 

Which CCCs do you need?


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