[lkml]   [2017]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] Input: synaptics-rmi4 - make F03 a tristate symbol
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

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.


 \ /
  Last update: 2017-01-11 17:54    [W:0.070 / U:2.168 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site