From patchwork Tue Jan 8 17:25:29 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dmitry Torokhov X-Patchwork-Id: 1947051 Return-Path: X-Original-To: patchwork-linux-input@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork1.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork1.kernel.org (Postfix) with ESMTP id A396D3FED4 for ; Tue, 8 Jan 2013 18:14:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756897Ab3AHSOe (ORCPT ); Tue, 8 Jan 2013 13:14:34 -0500 Received: from mail-pa0-f52.google.com ([209.85.220.52]:49272 "EHLO mail-pa0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756893Ab3AHSOe (ORCPT ); Tue, 8 Jan 2013 13:14:34 -0500 Received: by mail-pa0-f52.google.com with SMTP id fb1so482828pad.11 for ; Tue, 08 Jan 2013 10:14:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=M6pLIyf+l3ykO7IW0OFOYrRiOOKHxbjG/YzLnnHniP8=; b=d7yVyV3ii1m18ze1lmOVg9bVVzjLfjQjyXnMAXduIMeLspqAaPdb91f73uZh8ePf2v L3aysV8dh/SPIvYuOPGtz72MNyPeF+hkkniv9jozPZzuljI7WiPPrphXhW8SqVPtL8df nyam+4fSZlk6iBAgxhqT6cXhMg6ej3wG24SAVclZdsFbfetMjiCzcg5dhBVyAS8HKjpL pQ4LYgHJKAsfwOu5jlZR8OyttWFFbhptbx2QipumcZfqL/xh+39NRy3xS4SFPr7LQ74n ZfXA8rCQADu19H4tcV5qRKRWDzOl8mApZMwusnwE3Wjho/gJVGtKIYeancMvkgn8hxNR iiJA== X-Received: by 10.66.88.198 with SMTP id bi6mr181657039pab.54.1357668873858; Tue, 08 Jan 2013 10:14:33 -0800 (PST) Received: from mailhub.coreip.homeip.net (c-67-188-112-76.hsd1.ca.comcast.net. [67.188.112.76]) by mx.google.com with ESMTPS id d1sm41150812pav.6.2013.01.08.10.14.32 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 Jan 2013 10:14:33 -0800 (PST) Date: Tue, 8 Jan 2013 09:25:29 -0800 From: Dmitry Torokhov To: Sachin Kamat Cc: Laxman Dewangan , "linux-input@vger.kernel.org" , "patches@linaro.org" , Joonyoung Shim Subject: Re: [PATCH 1/1] Input: mms114: Use devm_* APIs Message-ID: <20130108172529.GA6746@core.coreip.homeip.net> References: <1357639508-15645-1-git-send-email-sachin.kamat@linaro.org> <50EBFE23.7070401@nvidia.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-input-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-input@vger.kernel.org Hi Sachin, On Tue, Jan 08, 2013 at 05:08:12PM +0530, Sachin Kamat wrote: > Hi Laxman, > > Thank you for your suggestion. > > On 8 January 2013 16:38, Laxman Dewangan wrote: > > On Tuesday 08 January 2013 03:35 PM, Sachin Kamat wrote: > >> > >> devm_* APIs are device managed and make the exit and clean up code > >> simpler. > >> > >> Signed-off-by: Sachin Kamat > >> Cc: Joonyoung Shim > >> --- > >> Compile tested against linux-next tree (20130108). > >> --- > >> drivers/input/touchscreen/mms114.c | 41 > >> +++++++++++------------------------ > >> 1 files changed, 13 insertions(+), 28 deletions(-) > > > > > >> static int mms114_remove(struct i2c_client *client) > >> { > >> struct mms114_data *data = i2c_get_clientdata(client); > >> - free_irq(client->irq, data); > >> - regulator_put(data->io_reg); > >> - regulator_put(data->core_reg); > >> input_unregister_device(data->input_dev); > > > > > > Because you are using devm_input_allocate_device() for allocating input > > device, you need not to have the input_unregister_device() and so you can > > get rid of remove() callback at all. > > This is what I learnt from Dmitry on similar patch for Tegra KBC. > > input_free_device() is the one which is not required when you use > devm_input_allocate_device(). > Unregister call, AFAIK, is required since we are registering using > input_register_device(). > > Dmitry, please let me know if my understanding is right. Laxman is correct, neither of the calls is normally needed for managed input devices. I am considering applying the patch below clarifying this fact. Thanks. diff --git a/drivers/input/input.c b/drivers/input/input.c index ce01332f..c044699 100644 --- a/drivers/input/input.c +++ b/drivers/input/input.c @@ -1785,12 +1785,13 @@ static void devm_input_device_release(struct device *dev, void *res) * its driver (or binding fails). Once managed input device is allocated, * it is ready to be set up and registered in the same fashion as regular * input device. There are no special devm_input_device_[un]register() - * variants, regular ones work with both managed and unmanaged devices. + * variants, regular ones work with both managed and unmanaged devices, + * should you need them. In most cases however, managed input device need + * not be explicitly unregistered or freed. * * NOTE: the owner device is set up as parent of input device and users * should not override it. */ - struct input_dev *devm_input_allocate_device(struct device *dev) { struct input_dev *input; @@ -2004,6 +2005,17 @@ static void devm_input_device_unregister(struct device *dev, void *res) * Once device has been successfully registered it can be unregistered * with input_unregister_device(); input_free_device() should not be * called in this case. + * + * Note that this function is also used to register managed input devices + * (ones allocated with devm_input_allocate_device()). Such managed input + * devices need not be explicitly unregistered or freed, their tear down + * is controlled by the devres infrastructure. It is also worth noting + * that tear down of managed input devices is internally a 2-step process: + * registered managed input device is first unregistered, but stays in + * memory and can still handle input_event() calls (although events will + * not be delivered anywhere). The freeing of managed input device will + * happen later, when devres stack is unwound to the point where device + * allocation was made. */ int input_register_device(struct input_dev *dev) {