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
