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

[Meagan Lloyd]

On Thu, Sep 17, 2026 at 03:27:38PM -0700, Meagan Lloyd wrote:
> 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).

I made an assumption in my previous analysis. I assumed that the
notification would be dispatched in its own thread. Digging more,
bus_notify just invokes all the registered .notifier_call callbacks, so
i3cdev_detach would be guaranteed to run before call_driver_probe.

Please disregard my previous comment and apologies for the confusion.

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

FWIW, your solution will also work for me. I'm looking to query SKU
information over I3C and then configure I3C Hubs according to the
hardware path.

Thank you,
Meagan
 
> > 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