From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: "Thomas Petazzoni" <thomas.petazzoni@free-electrons.com>,
"Sébastien SZYMANSKI" <sebastien.szymanski@armadeus.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"Wolfram Sang" <wsa@the-dreams.de>,
laurent.pinchart+renesas@ideasonboard.com,
linux-input@vger.kernel.org, linux-i2c@vger.kernel.org
Subject: Re: Bug in i2c-core?
Date: Fri, 27 Feb 2015 09:46:11 -0800 [thread overview]
Message-ID: <20150227174611.GC6679@dtor-ws> (raw)
In-Reply-To: <20150227170545.GS7789@pengutronix.de>
On Fri, Feb 27, 2015 at 06:05:45PM +0100, Uwe Kleine-König wrote:
> On Fri, Feb 27, 2015 at 07:29:30AM -0800, Dmitry Torokhov wrote:
> > On February 27, 2015 6:37:25 AM PST, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
> > >Dear Sébastien SZYMANSKI,
> > >
> > >On Fri, 27 Feb 2015 12:09:51 +0100, Sébastien SZYMANSKI wrote:
> > >
> > >> error = input_register_device(sx8654->input);
> > >> if (error)
> > >> return error;
> > >
> > >Where is your ->remove() function that unregisters the input device?
> >
> > Everything seems to be allocated with devm so remove is not needed.
> Everything is devm_* but input_register_device, right?
Input is allocated with devm_* and input_register_device knows how to
deal with that:
/**
* devm_input_allocate_device - allocate managed input device
* @dev: device owning the input device being created
*
* Returns prepared struct input_dev or %NULL.
*
* Managed input devices do not need to be explicitly unregistered or
* freed as it will be done automatically when owner device unbinds from
* 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,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
* 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.
*/
Thanks.
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: dmitry.torokhov@gmail.com (Dmitry Torokhov)
To: linux-arm-kernel@lists.infradead.org
Subject: Bug in i2c-core?
Date: Fri, 27 Feb 2015 09:46:11 -0800 [thread overview]
Message-ID: <20150227174611.GC6679@dtor-ws> (raw)
In-Reply-To: <20150227170545.GS7789@pengutronix.de>
On Fri, Feb 27, 2015 at 06:05:45PM +0100, Uwe Kleine-K?nig wrote:
> On Fri, Feb 27, 2015 at 07:29:30AM -0800, Dmitry Torokhov wrote:
> > On February 27, 2015 6:37:25 AM PST, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
> > >Dear S?bastien SZYMANSKI,
> > >
> > >On Fri, 27 Feb 2015 12:09:51 +0100, S?bastien SZYMANSKI wrote:
> > >
> > >> error = input_register_device(sx8654->input);
> > >> if (error)
> > >> return error;
> > >
> > >Where is your ->remove() function that unregisters the input device?
> >
> > Everything seems to be allocated with devm so remove is not needed.
> Everything is devm_* but input_register_device, right?
Input is allocated with devm_* and input_register_device knows how to
deal with that:
/**
* devm_input_allocate_device - allocate managed input device
* @dev: device owning the input device being created
*
* Returns prepared struct input_dev or %NULL.
*
* Managed input devices do not need to be explicitly unregistered or
* freed as it will be done automatically when owner device unbinds from
* 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,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
* 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.
*/
Thanks.
--
Dmitry
next prev parent reply other threads:[~2015-02-27 17:46 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-27 11:09 Bug in i2c-core? Sébastien SZYMANSKI
2015-02-27 11:09 ` Sébastien SZYMANSKI
2015-02-27 14:37 ` Thomas Petazzoni
2015-02-27 14:37 ` Thomas Petazzoni
2015-02-27 15:29 ` Dmitry Torokhov
2015-02-27 15:29 ` Dmitry Torokhov
2015-02-27 17:05 ` Uwe Kleine-König
2015-02-27 17:05 ` Uwe Kleine-König
2015-02-27 17:46 ` Dmitry Torokhov [this message]
2015-02-27 17:46 ` Dmitry Torokhov
2015-02-27 18:39 ` Uwe Kleine-König
2015-02-27 18:39 ` Uwe Kleine-König
2015-02-28 10:00 ` Thomas Petazzoni
2015-02-28 10:00 ` Thomas Petazzoni
[not found] ` <54F0507F.6030804-d2DlULPkwbNWk0Htik3J/w@public.gmane.org>
2015-02-27 16:59 ` Dmitry Torokhov
2015-02-27 16:59 ` Dmitry Torokhov
2015-02-27 17:01 ` Dmitry Torokhov
2015-02-27 17:01 ` Dmitry Torokhov
2015-03-03 22:03 ` Laurent Pinchart
2015-03-03 22:03 ` Laurent Pinchart
2015-03-04 6:47 ` Wolfram Sang
2015-03-04 6:47 ` Wolfram Sang
2015-03-04 8:22 ` Wolfram Sang
2015-03-04 8:22 ` Wolfram Sang
2015-03-08 8:26 ` Wolfram Sang
2015-03-08 8:26 ` Wolfram Sang
2015-03-10 0:21 ` Laurent Pinchart
2015-03-10 0:21 ` Laurent Pinchart
2015-03-12 9:35 ` Wolfram Sang
2015-03-12 9:35 ` Wolfram Sang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150227174611.GC6679@dtor-ws \
--to=dmitry.torokhov@gmail.com \
--cc=laurent.pinchart+renesas@ideasonboard.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=sebastien.szymanski@armadeus.com \
--cc=thomas.petazzoni@free-electrons.com \
--cc=u.kleine-koenig@pengutronix.de \
--cc=wsa@the-dreams.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.