Re: [PATCH v4 3/3] i3c: add i3cdev module to expose i3c dev in /dev

[Sam Agazaryan]

Hey Meagan,

Thanks for sharing your patch series.

 The reason we have the bus notifier system here is
 1. Dynamic module loading is handled automatically: if i3cdev is built-in and
    a specialized driver module loads later, the bus notifier receives
    BUS_NOTIFY_BIND_DRIVER and immediately calls i3cdev_detach().
 2. No cross-subsystem changes needed. The bus notifier avoids touching other
    subsystems entirely.
 3. Boot-time recovery flows: For OCP Secure Firmware Recovery
    devices come up unbound and need /dev/bus/i3c/<device> available
    immediately without requiring udev rules or sysfs writes first.

Let me know what you think about that and if there's something I may be missing.

It looks like we're both going in the same direction for UAPI integration too.

If you're open to collaborating, I think we can combine and converge on a single
i3cdev driver - adopting all necessary fixes and ensuring the UAPI and features
cover both of our use cases so we have one unified series (and any
other use cases
or desires we may want out of an i3cdev driver).

I'd like to know what everyone thinks about taking that approach also
if there are any
other use cases we may be missing here, regardless of which patch set we choose.

I guess just to get things moving, if we go one way and choose to go
forward with
the bus notifier approach, Meagan would you be okay with me incorporating your
Patch 2/3 for actual_len for the i3c controller drivers? Of course
with your authorship.


Thanks,
Sam