Re: [PATCH] Input: synaptics-rmi4 - make F03 a tristate symbol

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux