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

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Fri, Sep 18, 2026 at 11:59:02AM -0700, Meagan Lloyd wrote:
> 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.

Note that manually using bind will taint the kernel in the near future,
so NEVER rely on that to do anything that you rely on (i.e. normal
operations.)  The bind/unbind and driver_override stuff is there for
debugging stuff, not for normal hardware support.  Do it properly and
don't attempt to abuse that interface please.

thanks,

gre gk-h