Re: Order in which kernel decides binding device driver

[Hritik Vijay <hritikxx8@gmail.com>]

On Sun, May 16, 2021 at 10:41:18AM -0400, Alan Stern wrote:
> Please use Reply-To-All so that your responses show up on the mailing 
> list.
> 
> On Sun, May 16, 2021 at 10:38:14AM +0530, Hritik Vijay wrote:
> > On Sat, May 15, 2021 at 09:01:54PM -0400, Alan Stern wrote:
> > > I believe this happens in the order that the drivers are registered.  
> > > For drivers in modules, this will be the order in which the modules are 
> > > loaded.
> > Can you please reference the code snippet with this ? If it happens in
> 
> There is no such snippet.  This is an emergent effect; it happens 
> because __device_attach in drivers/base/dd.c calls bus_for_each_drv to 
> try to match drivers with a new device, bus_for_each_drv in bus.c uses 
> next_driver to iterate through the list of drivers on a bus, next_driver 
> uses klist_next to follow the klist of driver knodes, and bus_add_driver 
> calls klist_add_tail to add a new driver knode to the end of the klist 
> of drivers for a bus.
> 
> > the order in which the modules are loaded then I suppose its the
> > responsibility of the hot-plugging daemon (udev here) to take care of
> > the load order.
> 
> No; load order is nobody's responsibility.  Making sure the system works 
> correctly is the responsibility of the programmers who wrote the device 
> drivers (is that you in this case?).  Drivers are supposed to work as 
> desired no matter what order they get probed in.
> 
> > > driver will be able to manage a particular device.  For cases where 
> > > there are two drivers capable of handling the same device, people 
> > > usually have some sort of priority scheme to decide.  For example, many 
> > > USB mass-storage devices can be handled by either the usb-storage or the 
> > > uas driver, but uas has higher priority.
> > > 
> > > Alan Stern
> > I'm curious about the case where no particular priority is defined.
> 
> In that case there is no definite requirement.  Either driver may be 
> probed first and consequently may end up binding to the device; the 
> result is more or less random.  It may even differ from one boot to the 
> next.
> 
> > Hrtk
> 
> Alan Stern

Thank you so much for the detailed reply. Having looked at dd.c and
bus.c, it now makes much more sense to me.

Hrtk