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

[Sam Agazaryan]

> > An in-kernel driver would need new sysfs ABI for this, and that ABI
> > would have to grow as the spec evolves: v1.1 alone added multi-stage
> > activation, flashless boot and the indirect FIFO interface. With a
> > target-scoped transfer interface, none of that needs kernel changes.
> > fw_upload and lib/pldmfw fit well where a kernel driver already owns
> > the device; here the only consumer is the BMC's management stack.
>
> Yes, and I see no issues with that. Opening the whole i3cdev just for the same
> reason sounds like an overkill. Especially if we do *not* expect any more users.

OCP recovery isn't the only user. In her thread, Meagan described a
separate one [1]: accelerator cards that plug into different server
SKUs, where the I3C hubs and devices on the bus can differ per SKU, so
the hub setup has to be discovered and programmed from userspace at
runtime instead of being fixed in devicetree. She posted her own i3cdev
series and can speak to the details better than I can.

Also, with the explicit binding planned for v6, i3cdev would not open
the whole bus. It would only bind device classes listed in its ID
table, starting with the OCP recovery DCR, and any other class would
have to be added there deliberately, with its own justification.

> If there are success stories, those examples might help to justify your
> approach. It makes sense to mention that in the cover letter with the
> summary on their designs (and split).

Will do. I'll summarize in the v6 cover letter.

[1] https://lore.kernel.org/linux-i3c/20260924-86692413bdae0e78a12c1425@xxxxxxxxxxxxxxxxxxx/

Thanks,
Sam