Dmitry Torokhov wrote:
On Thu, Nov 19, 2009 at 10:32:21AM -0600, Miguel Aguilar wrote:
Hi Dmitry,
+ if (pdata->device_enable) {
+ error = pdata->device_enable(dev);
+ if (error < 0) {
+ dev_dbg(dev, "device enable function failed\n");
+ return error;
+ }
+ }
+
Hi Miguel,
Does this need to live in the driver? Why can't platform code do this
for us?
Thanks.
The reason to invoke the device_enable function in the driver is because
in the testing process of the key scan driver a issue was found when the
key scan is built as a module.
There is a specific PINMUX configuration that only should be set if the
key scan driver is loaded in the kernel to avoid pin conflicts. So when
the key scan is built as a module the board file (or platform code)
doesn't know if the key scan is loaded or not, so that's why the driver
is the one who must invoke the device_enable function in the probe
function.
I see... What happens if PINMUX is set but there isn't a driver? Also,
what happens when you unload the module? Don't you need a similar call
to disable PINMUX configuration?
Dmitry,
If PINMUX is set and there isn't the driver, the PINMUX configuration can
overwrite the PINMUX configuration needed by other drivers which actually are
loaded. This situation happens in the DM365 EVM, because the hardware design
there are hardware modules that can't coexist, so handling the PINMUX
configuration calling a function pointer is a safe way to ensure that the PINMUX
is set only when the module is loaded.
Disable PINMUX configuration doesn't make sense, because there isn't a thing
such disable PINMUX configuration, there are a lot of possible PINMUX
combinations, and there is no combination that means disable, and also change
the PINMUX configuration to a different state would be risky.
Is the responsibility of the platform code or of the driver in the
initialization, like in the case of the key scan, to set the needed PINMUX
configuration for running the module properly.
Thanks,
Miguel Aguilar
--
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
