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

["Pathak, Asutosh" <asutosh.pathak@linux.intel.com>]

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.

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.

Happy to help with (1) if you want - it's the piece we care about most and I
suspect the recovery/BMC folks could use it too. Not trying to expand the scope
of v5, just flagging so the ABI leaves room.

Thanks,
Asutosh

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