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

[Benjamin Tissoires <benjamin.tissoires@redhat.com>]

On Jan 11 2017 or thereabouts, Arnd Bergmann wrote:
> 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.
> 

I agree, but we never managed to make it properly working for RMI4. See
https://lkml.org/lkml/2015/11/5/726 where we decided to switch to a
static list of functions. Maybe we did not try hard enough, but we kept
the current bus/functions_as_drivers to be able to switch back to the
modular option,

> > 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.

Agree, though that means we won't be able to switch back. In the current
form it's overly engineered.

> 
> 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

I think you have this right.

> 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.
> 

Agree, that would simplify the code a lot. I just don't know how
important it is for other users of RMI4 to have a modular solution or if
the monolithic approach is a consensus now. The modular solution is
currently disabled, but we can "always" switch back with a small effort.

My opinion on this matter is that there is no need for the modular
functions, but others might have a different opinion.

Cheers,
Benjamin