[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <52FD1BC0.1050009@synaptics.com>
Date: Thu, 13 Feb 2014 11:23:44 -0800
From: Christopher Heiny <cheiny@...aptics.com>
To: Dmitry Torokhov <dmitry.torokhov@...il.com>
CC: Andrew Duggan <aduggan@...aptics.com>,
Vincent Huang <vincent.huang@...synaptics.com>,
Vivian Ly <vly@...aptics.com>,
Daniel Rosenberg <daniel.rosenberg@...aptics.com>,
Linus Walleij <linus.walleij@...ricsson.com>,
Benjamin Tissoires <benjamin.tissoires@...hat.com>,
Courtney Cavin <courtney.cavin@...ymobile.com>,
Linux Input <linux-input@...r.kernel.org>,
Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 03/11] Input: synaptics-rmi4 - do not update configuration
in rmi_f01_probe()
On 02/12/2014 09:27 PM, Dmitry Torokhov wrote:
> Do not write configuration data in probe(), we have config() for that.
Then we should call config() in rmi_function_probe() to ensure that
any platform data or device tree configuration settings get written
to the device.
Thinking about that, it looks like it's not fatal if the config
write fails in that situation. The device might not function as
intended, but you can hopefully get some use out of it (for
instance, a phone's touchscreen sensitivity might be wacky, but
the user will still be able to dial tech support).
For example:
static int rmi_function_probe(struct device *dev)
{
struct rmi_function *fn = to_rmi_function(dev);
struct rmi_function_handler *handler =
to_rmi_function_handler(dev->driver);
int error;
if (handler->probe) {
error = handler->probe(fn);
if (error)
return error;
}
if (handler->config) {
error = handler->config(fn);
if (error)
dev_warn(dev, "Driver config failed.\n");
}
return 0;
}
>
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@...il.com>
> ---
> drivers/input/rmi4/rmi_f01.c | 18 ------------------
> 1 file changed, 18 deletions(-)
>
> diff --git a/drivers/input/rmi4/rmi_f01.c b/drivers/input/rmi4/rmi_f01.c
> index 897d8ac..976aba3 100644
> --- a/drivers/input/rmi4/rmi_f01.c
> +++ b/drivers/input/rmi4/rmi_f01.c
> @@ -303,12 +303,6 @@ static int rmi_f01_initialize(struct rmi_function *fn)
> if (pdata->power_management.doze_interval) {
> data->device_control.doze_interval =
> pdata->power_management.doze_interval;
> - error = rmi_write(rmi_dev, data->doze_interval_addr,
> - data->device_control.doze_interval);
> - if (error < 0) {
> - dev_err(&fn->dev, "Failed to configure F01 doze interval register.\n");
> - return error;
> - }
> } else {
> error = rmi_read(rmi_dev, data->doze_interval_addr,
> &data->device_control.doze_interval);
> @@ -324,12 +318,6 @@ static int rmi_f01_initialize(struct rmi_function *fn)
> if (pdata->power_management.wakeup_threshold) {
> data->device_control.wakeup_threshold =
> pdata->power_management.wakeup_threshold;
> - error = rmi_write(rmi_dev, data->wakeup_threshold_addr,
> - data->device_control.wakeup_threshold);
> - if (error < 0) {
> - dev_err(&fn->dev, "Failed to configure F01 wakeup threshold register.\n");
> - return error;
> - }
> } else {
> error = rmi_read(rmi_dev, data->wakeup_threshold_addr,
> &data->device_control.wakeup_threshold);
> @@ -347,12 +335,6 @@ static int rmi_f01_initialize(struct rmi_function *fn)
> if (pdata->power_management.doze_holdoff) {
> data->device_control.doze_holdoff =
> pdata->power_management.doze_holdoff;
> - error = rmi_write(rmi_dev, data->doze_holdoff_addr,
> - data->device_control.doze_holdoff);
> - if (error < 0) {
> - dev_err(&fn->dev, "Failed to configure F01 doze holdoff register.\n");
> - return error;
> - }
> } else {
> error = rmi_read(rmi_dev, data->doze_holdoff_addr,
> &data->device_control.doze_holdoff);
>
--
Christopher Heiny
Senior Staff Firmware Engineer
Synaptics Incorporated
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists