[PATCH 01/26] Input: synaptics-rmi4 - embed the function modules in rmi_core

[PATCH 01/26] Input: synaptics-rmi4 - embed the function modules in rmi_core

[Andrew Duggan]

From: Benjamin Tissoires <benjamin.tissoires@redhat.com>

the function modules can not be auto-loaded by udev. So at boot, the
functions are not there and the device is not properly populated.
Force the functions to be embedded in rmi_core so that when the touchpad
is there, the functions are there too.

There is not much use of having the functions separate anyway

Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Andrew Duggan <aduggan@synaptics.com>
---
 drivers/input/rmi4/Kconfig      |  5 +----
 drivers/input/rmi4/Makefile     |  2 +-
 drivers/input/rmi4/rmi_bus.c    | 12 +++++++++++-
 drivers/input/rmi4/rmi_driver.h |  8 ++++++++
 drivers/input/rmi4/rmi_f11.c    | 14 ++++++++------
 5 files changed, 29 insertions(+), 12 deletions(-)

diff --git a/drivers/input/rmi4/Kconfig b/drivers/input/rmi4/Kconfig
index d0c7b6e..5e3890e 100644
--- a/drivers/input/rmi4/Kconfig
+++ b/drivers/input/rmi4/Kconfig
@@ -37,7 +37,7 @@ config RMI4_I2C
 	  This feature is not currently available as a loadable module.
 
 config RMI4_F11
-	tristate "RMI4 Function 11 (2D pointing)"
+	bool "RMI4 Function 11 (2D pointing)"
 	depends on RMI4_CORE
 	help
 	  Say Y here if you want to add support for RMI4 function 11.
@@ -46,9 +46,6 @@ config RMI4_F11
 	  touchpads.  For sensors that support relative pointing, F11 also
 	  provides mouse input.
 
-	  To compile this driver as a module, choose M here: the
-	  module will be called rmi-f11.
-
 config RMI4_F11_PEN
 	bool "RMI4 F11 Pen Support"
 	depends on RMI4_F11
diff --git a/drivers/input/rmi4/Makefile b/drivers/input/rmi4/Makefile
index 5c6bad5..63bc595 100644
--- a/drivers/input/rmi4/Makefile
+++ b/drivers/input/rmi4/Makefile
@@ -2,7 +2,7 @@ obj-$(CONFIG_RMI4_CORE) += rmi_core.o
 rmi_core-y := rmi_bus.o rmi_driver.o rmi_f01.o
 
 # Function drivers
-obj-$(CONFIG_RMI4_F11) += rmi_f11.o
+rmi_core-$(CONFIG_RMI4_F11) += rmi_f11.o
 
 # Transports
 obj-$(CONFIG_RMI4_I2C) += rmi_i2c.o
diff --git a/drivers/input/rmi4/rmi_bus.c b/drivers/input/rmi4/rmi_bus.c
index 6e0454a..bbc80e6 100644
--- a/drivers/input/rmi4/rmi_bus.c
+++ b/drivers/input/rmi4/rmi_bus.c
@@ -383,15 +383,24 @@ static int __init rmi_bus_init(void)
 		goto err_unregister_bus;
 	}
 
+	error = rmi_register_f11_handler();
+	if (error) {
+		pr_err("%s: error registering the RMI F11 handler: %d\n",
+			__func__, error);
+		goto err_unregister_f01;
+	}
+
 	error = rmi_register_physical_driver();
 	if (error) {
 		pr_err("%s: error registering the RMI physical driver: %d\n",
 			__func__, error);
-		goto err_unregister_f01;
+		goto err_unregister_f11;
 	}
 
 	return 0;
 
+err_unregister_f11:
+	rmi_unregister_f11_handler();
 err_unregister_f01:
 	rmi_unregister_f01_handler();
 err_unregister_bus:
@@ -409,6 +418,7 @@ static void __exit rmi_bus_exit(void)
 	 */
 
 	rmi_unregister_physical_driver();
+	rmi_unregister_f11_handler();
 	rmi_unregister_f01_handler();
 	rmi_bus_teardown_debugfs();
 	bus_unregister(&rmi_bus_type);
diff --git a/drivers/input/rmi4/rmi_driver.h b/drivers/input/rmi4/rmi_driver.h
index 34f7a7d..dda564f 100644
--- a/drivers/input/rmi4/rmi_driver.h
+++ b/drivers/input/rmi4/rmi_driver.h
@@ -113,4 +113,12 @@ void rmi_unregister_physical_driver(void);
 int rmi_register_f01_handler(void);
 void rmi_unregister_f01_handler(void);
 
+#ifdef CONFIG_RMI4_F11
+int rmi_register_f11_handler(void);
+void rmi_unregister_f11_handler(void);
+#else
+static inline int rmi_register_f11_handler(void) { return 0; }
+static inline void rmi_unregister_f11_handler(void) {}
+#endif
+
 #endif
diff --git a/drivers/input/rmi4/rmi_f11.c b/drivers/input/rmi4/rmi_f11.c
index 7af4f68..2e1d506 100644
--- a/drivers/input/rmi4/rmi_f11.c
+++ b/drivers/input/rmi4/rmi_f11.c
@@ -1537,10 +1537,12 @@ static struct rmi_function_handler rmi_f11_handler = {
 	.attention	= rmi_f11_attention,
 };
 
-module_rmi_driver(rmi_f11_handler);
+int __init rmi_register_f11_handler(void)
+{
+	return rmi_register_function_handler(&rmi_f11_handler);
+}
 
-MODULE_AUTHOR("Christopher Heiny <cheiny@synaptics.com");
-MODULE_AUTHOR("Andrew Duggan <aduggan@synaptics.com");
-MODULE_DESCRIPTION("RMI F11 module");
-MODULE_LICENSE("GPL");
-MODULE_VERSION(RMI_DRIVER_VERSION);
+void rmi_unregister_f11_handler(void)
+{
+	rmi_unregister_function_handler(&rmi_f11_handler);
+}
-- 
2.1.4

[PATCH 01/26] Input: synaptics-rmi4 - embed the function modules in rmi_core

[Andrew Duggan]

From: Benjamin Tissoires <benjamin.tissoires@redhat.com>

the function modules can not be auto-loaded by udev. So at boot, the
functions are not there and the device is not properly populated.
Force the functions to be embedded in rmi_core so that when the touchpad
is there, the functions are there too.

There is not much use of having the functions separate anyway

Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Andrew Duggan <aduggan@synaptics.com>
---
 drivers/input/rmi4/Kconfig      |  5 +----
 drivers/input/rmi4/Makefile     |  2 +-
 drivers/input/rmi4/rmi_bus.c    | 12 +++++++++++-
 drivers/input/rmi4/rmi_driver.h |  8 ++++++++
 drivers/input/rmi4/rmi_f11.c    | 14 ++++++++------
 5 files changed, 29 insertions(+), 12 deletions(-)

diff --git a/drivers/input/rmi4/Kconfig b/drivers/input/rmi4/Kconfig
index d0c7b6e..5e3890e 100644
--- a/drivers/input/rmi4/Kconfig
+++ b/drivers/input/rmi4/Kconfig
@@ -37,7 +37,7 @@ config RMI4_I2C
 	  This feature is not currently available as a loadable module.
 
 config RMI4_F11
-	tristate "RMI4 Function 11 (2D pointing)"
+	bool "RMI4 Function 11 (2D pointing)"
 	depends on RMI4_CORE
 	help
 	  Say Y here if you want to add support for RMI4 function 11.
@@ -46,9 +46,6 @@ config RMI4_F11
 	  touchpads.  For sensors that support relative pointing, F11 also
 	  provides mouse input.
 
-	  To compile this driver as a module, choose M here: the
-	  module will be called rmi-f11.
-
 config RMI4_F11_PEN
 	bool "RMI4 F11 Pen Support"
 	depends on RMI4_F11
diff --git a/drivers/input/rmi4/Makefile b/drivers/input/rmi4/Makefile
index 5c6bad5..63bc595 100644
--- a/drivers/input/rmi4/Makefile
+++ b/drivers/input/rmi4/Makefile
@@ -2,7 +2,7 @@ obj-$(CONFIG_RMI4_CORE) += rmi_core.o
 rmi_core-y := rmi_bus.o rmi_driver.o rmi_f01.o
 
 # Function drivers
-obj-$(CONFIG_RMI4_F11) += rmi_f11.o
+rmi_core-$(CONFIG_RMI4_F11) += rmi_f11.o
 
 # Transports
 obj-$(CONFIG_RMI4_I2C) += rmi_i2c.o
diff --git a/drivers/input/rmi4/rmi_bus.c b/drivers/input/rmi4/rmi_bus.c
index 6e0454a..bbc80e6 100644
--- a/drivers/input/rmi4/rmi_bus.c
+++ b/drivers/input/rmi4/rmi_bus.c
@@ -383,15 +383,24 @@ static int __init rmi_bus_init(void)
 		goto err_unregister_bus;
 	}
 
+	error = rmi_register_f11_handler();
+	if (error) {
+		pr_err("%s: error registering the RMI F11 handler: %d\n",
+			__func__, error);
+		goto err_unregister_f01;
+	}
+
 	error = rmi_register_physical_driver();
 	if (error) {
 		pr_err("%s: error registering the RMI physical driver: %d\n",
 			__func__, error);
-		goto err_unregister_f01;
+		goto err_unregister_f11;
 	}
 
 	return 0;
 
+err_unregister_f11:
+	rmi_unregister_f11_handler();
 err_unregister_f01:
 	rmi_unregister_f01_handler();
 err_unregister_bus:
@@ -409,6 +418,7 @@ static void __exit rmi_bus_exit(void)
 	 */
 
 	rmi_unregister_physical_driver();
+	rmi_unregister_f11_handler();
 	rmi_unregister_f01_handler();
 	rmi_bus_teardown_debugfs();
 	bus_unregister(&rmi_bus_type);
diff --git a/drivers/input/rmi4/rmi_driver.h b/drivers/input/rmi4/rmi_driver.h
index 34f7a7d..dda564f 100644
--- a/drivers/input/rmi4/rmi_driver.h
+++ b/drivers/input/rmi4/rmi_driver.h
@@ -113,4 +113,12 @@ void rmi_unregister_physical_driver(void);
 int rmi_register_f01_handler(void);
 void rmi_unregister_f01_handler(void);
 
+#ifdef CONFIG_RMI4_F11
+int rmi_register_f11_handler(void);
+void rmi_unregister_f11_handler(void);
+#else
+static inline int rmi_register_f11_handler(void) { return 0; }
+static inline void rmi_unregister_f11_handler(void) {}
+#endif
+
 #endif
diff --git a/drivers/input/rmi4/rmi_f11.c b/drivers/input/rmi4/rmi_f11.c
index 7af4f68..2e1d506 100644
--- a/drivers/input/rmi4/rmi_f11.c
+++ b/drivers/input/rmi4/rmi_f11.c
@@ -1537,10 +1537,12 @@ static struct rmi_function_handler rmi_f11_handler = {
 	.attention	= rmi_f11_attention,
 };
 
-module_rmi_driver(rmi_f11_handler);
+int __init rmi_register_f11_handler(void)
+{
+	return rmi_register_function_handler(&rmi_f11_handler);
+}
 
-MODULE_AUTHOR("Christopher Heiny <cheiny@synaptics.com");
-MODULE_AUTHOR("Andrew Duggan <aduggan@synaptics.com");
-MODULE_DESCRIPTION("RMI F11 module");
-MODULE_LICENSE("GPL");
-MODULE_VERSION(RMI_DRIVER_VERSION);
+void rmi_unregister_f11_handler(void)
+{
+	rmi_unregister_function_handler(&rmi_f11_handler);
+}
-- 
2.1.4

Re: [PATCH 01/26] Input: synaptics-rmi4 - embed the function modules in rmi_core

[Linus Walleij]

On Fri, Nov 6, 2015 at 12:36 AM, Andrew Duggan <aduggan@synaptics.com> wrote:

> From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
>
> the function modules can not be auto-loaded by udev. So at boot, the
> functions are not there and the device is not properly populated.
> Force the functions to be embedded in rmi_core so that when the touchpad
> is there, the functions are there too.
>
> There is not much use of having the functions separate anyway
>
> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> Tested-by: Andrew Duggan <aduggan@synaptics.com>

Tested-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

Re: [PATCH 01/26] Input: synaptics-rmi4 - embed the function modules in rmi_core

[Dmitry Torokhov]

On Thu, Nov 05, 2015 at 03:36:18PM -0800, Andrew Duggan wrote:
> From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> 
> the function modules can not be auto-loaded by udev. So at boot, the
> functions are not there and the device is not properly populated.
> Force the functions to be embedded in rmi_core so that when the touchpad
> is there, the functions are there too.

There is nothing inherently different in RMI compared to other buses.
kmod package simply needs to be aware of it.

Thanks.

-- 
Dmitry

Re: [PATCH 01/26] Input: synaptics-rmi4 - embed the function modules in rmi_core

[Benjamin Tissoires]

On Tue, Nov 10, 2015 at 12:06 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Thu, Nov 05, 2015 at 03:36:18PM -0800, Andrew Duggan wrote:
>> From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
>>
>> the function modules can not be auto-loaded by udev. So at boot, the
>> functions are not there and the device is not properly populated.
>> Force the functions to be embedded in rmi_core so that when the touchpad
>> is there, the functions are there too.
>
> There is nothing inherently different in RMI compared to other buses.
> kmod package simply needs to be aware of it.
>

I can't help but thinking that it is slightly different though. We
register one RMI bus like the others, but then, the only driver
(rmi-driver) on the bus needs to enumerate the device and attach other
kernel modules on demand. It looks as if the rmi device is an other
internal bus. But the current implementation only allows the functions
to be loaded during the probe of the rmi_device.

During this probe, we can't block to wait for userspace to load the
various modules, and so we are screwed. The solution would be to allow
deferring the loading of the various functions, which basically comes
down to create a sub-bus per device.

The way I see it is:
- for 90 % of the cases, RMI4 will be used for touchpads in general
laptops. Distributions will likely enable 2D sensors, F30, fingerprint
readers, and maybe a few others. I don't think we want to chase all
the initrd tools to include the various RMI modules or people will
have a non functional touchpad.
- for the rest (embedded, phones, etc,...), these projects usually
already configure their own kernels and they can decide whether or not
they want to include which function depending on the actual hardware.

I am not saying that having autoloading is a bad thing. I just can't
see the interest for the general use case, and I can see the nightmare
to maintain the autoloading :).

Cheers,
Benjamin

Re: [PATCH 01/26] Input: synaptics-rmi4 - embed the function modules in rmi_core

[Andrew Duggan]

On 11/10/2015 01:03 AM, Benjamin Tissoires wrote:
> On Tue, Nov 10, 2015 at 12:06 AM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
>> On Thu, Nov 05, 2015 at 03:36:18PM -0800, Andrew Duggan wrote:
>>> From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
>>>
>>> the function modules can not be auto-loaded by udev. So at boot, the
>>> functions are not there and the device is not properly populated.
>>> Force the functions to be embedded in rmi_core so that when the touchpad
>>> is there, the functions are there too.
>> There is nothing inherently different in RMI compared to other buses.
>> kmod package simply needs to be aware of it.
>>
> I can't help but thinking that it is slightly different though. We
> register one RMI bus like the others, but then, the only driver
> (rmi-driver) on the bus needs to enumerate the device and attach other
> kernel modules on demand. It looks as if the rmi device is an other
> internal bus. But the current implementation only allows the functions
> to be loaded during the probe of the rmi_device.
>
> During this probe, we can't block to wait for userspace to load the
> various modules, and so we are screwed. The solution would be to allow
> deferring the loading of the various functions, which basically comes
> down to create a sub-bus per device.
>
> The way I see it is:
> - for 90 % of the cases, RMI4 will be used for touchpads in general
> laptops. Distributions will likely enable 2D sensors, F30, fingerprint
> readers, and maybe a few others. I don't think we want to chase all
> the initrd tools to include the various RMI modules or people will
> have a non functional touchpad.
> - for the rest (embedded, phones, etc,...), these projects usually
> already configure their own kernels and they can decide whether or not
> they want to include which function depending on the actual hardware.
>
> I am not saying that having autoloading is a bad thing. I just can't
> see the interest for the general use case, and I can see the nightmare
> to maintain the autoloading :).
>
> Cheers,
> Benjamin

Conceptually, I like the idea of having functions as modules. That way 
you can only load the function drivers which match your device. But, as 
Benjamin points out supporting that really complicates initialization. 
Especially, when individual functions add capabilities to a single input 
device. If loading a module gets delayed then the input device can get 
registered with an incomplete set of capabilities which could cause 
userspace to misidentify the device. It looks like the input device's 
capabilities will get updated after the module has loaded. But, 
userspace doesn't seem to get a notification that those capabilities 
have changed. I guess one option would be to delete and recreate the 
input device if the capabilities change. Unless there is a better way to 
generate a notification?

I've been looking into getting modules working the last couple of days 
and I haven't really found a good solution. I tried adding the 
appropriate modalias and uevent entries to the function drivers and 
setting up the various fields in mod_devicetable.h and file2alias.c so 
that udev would automatically load the modules when the device is 
created. I haven't gotten this method to work so I am probably missing 
something. But, there is no guarantee that the module will be loaded 
before the input device is registered.

I also tried adding a call to request_module() to load the module just 
before registering the function driver. It works, but there is no 
guarantee that the module will be ready when we do the register. 
Especially, if we don't want to wait and use the _nowait version of 
request_module.

We could change the initialization process to be more asynchronous. We 
could record which functions have modules (based on the return value of 
request_module) and then register for notifications when the function 
driver modules load. Only after all of the modules have loaded do we 
register the input device.

But, these solutions add a lot of complexity and I'm not sure it is 
worth it given the size and number of function drivers. Like Benjamin 
said, on general laptops there will be a few extra function drivers in 
the core. While more resource constrained systems like phones usually 
don't support modules and will have only the function drivers enabled in 
the config which exist on the device. Unless there is a better approach 
I haven't found, I am inclined to just go ahead and include function 
drivers in the core. At least for now.

Andrew

[PATCH 01/26] Input: synaptics-rmi4 - embed the function modules in rmi_core

[Andrew Duggan]

From: Benjamin Tissoires <benjamin.tissoires@redhat.com>

the function modules can not be auto-loaded by udev. So at boot, the
functions are not there and the device is not properly populated.
Force the functions to be embedded in rmi_core so that when the touchpad
is there, the functions are there too.

There is not much use of having the functions separate anyway

Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Andrew Duggan <aduggan@synaptics.com>
---
 drivers/input/rmi4/Kconfig      |  5 +----
 drivers/input/rmi4/Makefile     |  2 +-
 drivers/input/rmi4/rmi_bus.c    | 12 +++++++++++-
 drivers/input/rmi4/rmi_driver.h |  8 ++++++++
 drivers/input/rmi4/rmi_f11.c    | 14 ++++++++------
 5 files changed, 29 insertions(+), 12 deletions(-)

diff --git a/drivers/input/rmi4/Kconfig b/drivers/input/rmi4/Kconfig
index d0c7b6e..5e3890e 100644
--- a/drivers/input/rmi4/Kconfig
+++ b/drivers/input/rmi4/Kconfig
@@ -37,7 +37,7 @@ config RMI4_I2C
 	  This feature is not currently available as a loadable module.
 
 config RMI4_F11
-	tristate "RMI4 Function 11 (2D pointing)"
+	bool "RMI4 Function 11 (2D pointing)"
 	depends on RMI4_CORE
 	help
 	  Say Y here if you want to add support for RMI4 function 11.
@@ -46,9 +46,6 @@ config RMI4_F11
 	  touchpads.  For sensors that support relative pointing, F11 also
 	  provides mouse input.
 
-	  To compile this driver as a module, choose M here: the
-	  module will be called rmi-f11.
-
 config RMI4_F11_PEN
 	bool "RMI4 F11 Pen Support"
 	depends on RMI4_F11
diff --git a/drivers/input/rmi4/Makefile b/drivers/input/rmi4/Makefile
index 5c6bad5..63bc595 100644
--- a/drivers/input/rmi4/Makefile
+++ b/drivers/input/rmi4/Makefile
@@ -2,7 +2,7 @@ obj-$(CONFIG_RMI4_CORE) += rmi_core.o
 rmi_core-y := rmi_bus.o rmi_driver.o rmi_f01.o
 
 # Function drivers
-obj-$(CONFIG_RMI4_F11) += rmi_f11.o
+rmi_core-$(CONFIG_RMI4_F11) += rmi_f11.o
 
 # Transports
 obj-$(CONFIG_RMI4_I2C) += rmi_i2c.o
diff --git a/drivers/input/rmi4/rmi_bus.c b/drivers/input/rmi4/rmi_bus.c
index 6e0454a..bbc80e6 100644
--- a/drivers/input/rmi4/rmi_bus.c
+++ b/drivers/input/rmi4/rmi_bus.c
@@ -383,15 +383,24 @@ static int __init rmi_bus_init(void)
 		goto err_unregister_bus;
 	}
 
+	error = rmi_register_f11_handler();
+	if (error) {
+		pr_err("%s: error registering the RMI F11 handler: %d\n",
+			__func__, error);
+		goto err_unregister_f01;
+	}
+
 	error = rmi_register_physical_driver();
 	if (error) {
 		pr_err("%s: error registering the RMI physical driver: %d\n",
 			__func__, error);
-		goto err_unregister_f01;
+		goto err_unregister_f11;
 	}
 
 	return 0;
 
+err_unregister_f11:
+	rmi_unregister_f11_handler();
 err_unregister_f01:
 	rmi_unregister_f01_handler();
 err_unregister_bus:
@@ -409,6 +418,7 @@ static void __exit rmi_bus_exit(void)
 	 */
 
 	rmi_unregister_physical_driver();
+	rmi_unregister_f11_handler();
 	rmi_unregister_f01_handler();
 	rmi_bus_teardown_debugfs();
 	bus_unregister(&rmi_bus_type);
diff --git a/drivers/input/rmi4/rmi_driver.h b/drivers/input/rmi4/rmi_driver.h
index 34f7a7d..dda564f 100644
--- a/drivers/input/rmi4/rmi_driver.h
+++ b/drivers/input/rmi4/rmi_driver.h
@@ -113,4 +113,12 @@ void rmi_unregister_physical_driver(void);
 int rmi_register_f01_handler(void);
 void rmi_unregister_f01_handler(void);
 
+#ifdef CONFIG_RMI4_F11
+int rmi_register_f11_handler(void);
+void rmi_unregister_f11_handler(void);
+#else
+static inline int rmi_register_f11_handler(void) { return 0; }
+static inline void rmi_unregister_f11_handler(void) {}
+#endif
+
 #endif
diff --git a/drivers/input/rmi4/rmi_f11.c b/drivers/input/rmi4/rmi_f11.c
index 7af4f68..2e1d506 100644
--- a/drivers/input/rmi4/rmi_f11.c
+++ b/drivers/input/rmi4/rmi_f11.c
@@ -1537,10 +1537,12 @@ static struct rmi_function_handler rmi_f11_handler = {
 	.attention	= rmi_f11_attention,
 };
 
-module_rmi_driver(rmi_f11_handler);
+int __init rmi_register_f11_handler(void)
+{
+	return rmi_register_function_handler(&rmi_f11_handler);
+}
 
-MODULE_AUTHOR("Christopher Heiny <cheiny@synaptics.com");
-MODULE_AUTHOR("Andrew Duggan <aduggan@synaptics.com");
-MODULE_DESCRIPTION("RMI F11 module");
-MODULE_LICENSE("GPL");
-MODULE_VERSION(RMI_DRIVER_VERSION);
+void rmi_unregister_f11_handler(void)
+{
+	rmi_unregister_function_handler(&rmi_f11_handler);
+}
-- 
2.1.4

[PATCH 01/26] Input: synaptics-rmi4 - embed the function modules in rmi_core

[Andrew Duggan]

From: Benjamin Tissoires <benjamin.tissoires@redhat.com>

the function modules can not be auto-loaded by udev. So at boot, the
functions are not there and the device is not properly populated.
Force the functions to be embedded in rmi_core so that when the touchpad
is there, the functions are there too.

There is not much use of having the functions separate anyway

Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Andrew Duggan <aduggan@synaptics.com>
---
 drivers/input/rmi4/Kconfig      |  5 +----
 drivers/input/rmi4/Makefile     |  2 +-
 drivers/input/rmi4/rmi_bus.c    | 12 +++++++++++-
 drivers/input/rmi4/rmi_driver.h |  8 ++++++++
 drivers/input/rmi4/rmi_f11.c    | 14 ++++++++------
 5 files changed, 29 insertions(+), 12 deletions(-)

diff --git a/drivers/input/rmi4/Kconfig b/drivers/input/rmi4/Kconfig
index d0c7b6e..5e3890e 100644
--- a/drivers/input/rmi4/Kconfig
+++ b/drivers/input/rmi4/Kconfig
@@ -37,7 +37,7 @@ config RMI4_I2C
 	  This feature is not currently available as a loadable module.
 
 config RMI4_F11
-	tristate "RMI4 Function 11 (2D pointing)"
+	bool "RMI4 Function 11 (2D pointing)"
 	depends on RMI4_CORE
 	help
 	  Say Y here if you want to add support for RMI4 function 11.
@@ -46,9 +46,6 @@ config RMI4_F11
 	  touchpads.  For sensors that support relative pointing, F11 also
 	  provides mouse input.
 
-	  To compile this driver as a module, choose M here: the
-	  module will be called rmi-f11.
-
 config RMI4_F11_PEN
 	bool "RMI4 F11 Pen Support"
 	depends on RMI4_F11
diff --git a/drivers/input/rmi4/Makefile b/drivers/input/rmi4/Makefile
index 5c6bad5..63bc595 100644
--- a/drivers/input/rmi4/Makefile
+++ b/drivers/input/rmi4/Makefile
@@ -2,7 +2,7 @@ obj-$(CONFIG_RMI4_CORE) += rmi_core.o
 rmi_core-y := rmi_bus.o rmi_driver.o rmi_f01.o
 
 # Function drivers
-obj-$(CONFIG_RMI4_F11) += rmi_f11.o
+rmi_core-$(CONFIG_RMI4_F11) += rmi_f11.o
 
 # Transports
 obj-$(CONFIG_RMI4_I2C) += rmi_i2c.o
diff --git a/drivers/input/rmi4/rmi_bus.c b/drivers/input/rmi4/rmi_bus.c
index 6e0454a..bbc80e6 100644
--- a/drivers/input/rmi4/rmi_bus.c
+++ b/drivers/input/rmi4/rmi_bus.c
@@ -383,15 +383,24 @@ static int __init rmi_bus_init(void)
 		goto err_unregister_bus;
 	}
 
+	error = rmi_register_f11_handler();
+	if (error) {
+		pr_err("%s: error registering the RMI F11 handler: %d\n",
+			__func__, error);
+		goto err_unregister_f01;
+	}
+
 	error = rmi_register_physical_driver();
 	if (error) {
 		pr_err("%s: error registering the RMI physical driver: %d\n",
 			__func__, error);
-		goto err_unregister_f01;
+		goto err_unregister_f11;
 	}
 
 	return 0;
 
+err_unregister_f11:
+	rmi_unregister_f11_handler();
 err_unregister_f01:
 	rmi_unregister_f01_handler();
 err_unregister_bus:
@@ -409,6 +418,7 @@ static void __exit rmi_bus_exit(void)
 	 */
 
 	rmi_unregister_physical_driver();
+	rmi_unregister_f11_handler();
 	rmi_unregister_f01_handler();
 	rmi_bus_teardown_debugfs();
 	bus_unregister(&rmi_bus_type);
diff --git a/drivers/input/rmi4/rmi_driver.h b/drivers/input/rmi4/rmi_driver.h
index 34f7a7d..dda564f 100644
--- a/drivers/input/rmi4/rmi_driver.h
+++ b/drivers/input/rmi4/rmi_driver.h
@@ -113,4 +113,12 @@ void rmi_unregister_physical_driver(void);
 int rmi_register_f01_handler(void);
 void rmi_unregister_f01_handler(void);
 
+#ifdef CONFIG_RMI4_F11
+int rmi_register_f11_handler(void);
+void rmi_unregister_f11_handler(void);
+#else
+static inline int rmi_register_f11_handler(void) { return 0; }
+static inline void rmi_unregister_f11_handler(void) {}
+#endif
+
 #endif
diff --git a/drivers/input/rmi4/rmi_f11.c b/drivers/input/rmi4/rmi_f11.c
index 7af4f68..2e1d506 100644
--- a/drivers/input/rmi4/rmi_f11.c
+++ b/drivers/input/rmi4/rmi_f11.c
@@ -1537,10 +1537,12 @@ static struct rmi_function_handler rmi_f11_handler = {
 	.attention	= rmi_f11_attention,
 };
 
-module_rmi_driver(rmi_f11_handler);
+int __init rmi_register_f11_handler(void)
+{
+	return rmi_register_function_handler(&rmi_f11_handler);
+}
 
-MODULE_AUTHOR("Christopher Heiny <cheiny@synaptics.com");
-MODULE_AUTHOR("Andrew Duggan <aduggan@synaptics.com");
-MODULE_DESCRIPTION("RMI F11 module");
-MODULE_LICENSE("GPL");
-MODULE_VERSION(RMI_DRIVER_VERSION);
+void rmi_unregister_f11_handler(void)
+{
+	rmi_unregister_function_handler(&rmi_f11_handler);
+}
-- 
2.1.4