On Wednesday, January 11, 2017 5:28:28 PM CET Benjamin Tissoires wrote: > Yep, it was initially written that way, and IIRC there was some issues > depending on how the drivers were compiled. For example, if rmi4_core is > Y and some functions are m, you can't load the device initially, so you > send a -EPROBE_DEFER, but how can you be sure that the function will > ever be loaded? I'm not sure if I understand your problem correctly, but normally the way it's done is that the bus driver notifies user space that a new device has appeared on the bus, and udev looks for the right driver for the device, using a MODULE_DEVICE_TABLE list. Once the driver gets loaded, it binds to the device. > Given that we need to have all the functions loaded during probe, we > decided to switch to a monolithic rmi4_core driver that has everything > it needs inside. If everything is in one module, you can probably get rid of at least part of the bus abstraction as well and just call the functions directly. Looking through the driver some more, I also find the 'rmi_driver rmi_physical_driver' concept very odd, you seem to have a device on the bus that is actually just another representation of the parent device and that creates another set of devices for the functions. Either I misunderstand what this is for, or you have a candidate for cleanup there and once you remove it (by calling rmi_driver_probe() instead of rmi_register_transport_device() to oversimplify the idea), the actual probing for the function drivers becomes much easier to do right. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
