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

[Meagan Lloyd <meaganlloyd@linux.microsoft.com>]

On Fri, Sep 11, 2026 at 05:12:40PM -0700, Sam Agazaryan wrote:
> 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().

I think the bus notifier approach has the potential to hit some race
conditions with other drivers.

For example, drivers/base/dd.c, really_probe is the only spot in the
source code that BUS_NOTIFY_BIND_DRIVER event occurs:
    really_probe
        driver_sysfs_add <- where BUS_NOTIFY_BIND_DRIVER occurs
        call_driver_probe

If a specialized driver's probe sets dev->driver_data, and i3cdev_detach
gets to run afterwards, wouldn't it overwrite driver_data with
NULL and clobber the driver_data?

Similarly, a driver setting dev->driver_data could cause you to lose
your i3cdev_data pointer - which you need for teardown in i3cdev_detach.

The use of the dev->driver_data field when i3cdev isn't a registered 
device driver was one of the feedback points flagged in v3 (2020).

>  2. No cross-subsystem changes needed. The bus notifier avoids touching other
>     subsystems entirely.

That's true and certainly a plus!

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

Why can't you use udev rules?

You can use them to automatically set driver_override & bind to i3cdev.
Once the rules are in-place, the setup of character device files in
/dev/bus/i3c/<device> will be immediate and automatic on-boot and for any
devices that join later.

You can also do it for all I3C devices if that's what you want.

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

Yeah, I am up for that! :)

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

Sure. I should have mentioned is that I only have a Designware I3C controller,
so hopefully we can source help to test actual_len for other controller drivers.

Thanks,
Meagan