All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org>
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	santosh.shilimkar-l0cyMroinI0@public.gmane.org,
	linux-input-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Sourav Poddar <sourav.poddar-l0cyMroinI0@public.gmane.org>,
	linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCHv5] Input: keypad: Add smsc ece1099 keypad driver
Date: Mon, 29 Oct 2012 13:45:20 -0700	[thread overview]
Message-ID: <20121029204520.GC13256@core.coreip.homeip.net> (raw)
In-Reply-To: <20121029190516.GA29230-S8G//mZuvNWo5Im9Ml3/Zg@public.gmane.org>

On Mon, Oct 29, 2012 at 09:05:53PM +0200, Felipe Balbi wrote:
> Hi,
> 
> On Mon, Oct 29, 2012 at 10:06:33AM -0700, Dmitry Torokhov wrote:
> 
> [ big snip ]
> 
> > > > +static int __devexit smsc_remove(struct platform_device *pdev)
> > > > +{
> > > 
> > > shouldn't you unregister the input device here ??
> > 
> > And that is why I do not like devm_* interface myself... But no, since
> > input device was allocated with devm_input_allocate_device() it does not
> > need to be explicitly freed or unregistered.
> 
> IMHO, that's a fragility on current devm implementation for input
> devices, then.
> 
> devm_input_allocate_device() is *only* allocating the input device (at
> least judging by the name). Looks like you should introduce
> devm_input_register_device() ? What happens if I
> devm_input_allocate_device() but don't go as far as
> input_register_device() (some error happens in-between) ?
> 

It will be freed automatically.

> I'm sure you have some proper handling for it, but it's quite misleading
> the way this was implemented.

Well, I could add devm_input_register_device(),
devm_input_unregister_device(), devm_input_free_device() and then add
checks to "normal" input_register_device(), input_unregister_device()
and input_free_device() to throw warnings and errors if they are used
with managed resources, and similarly add checks to devm_* API so that
they are not called with unmanaged devices and make a big mess out of
it.

_OR_ I could just add one new call devm_input_allocate_device() to
create managed input devices and make the rest of old API work with both
managed and unmanaged input devices. I think the latter is much better.

Thanks.

-- 
Dmitry

WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Felipe Balbi <balbi@ti.com>
Cc: Sourav Poddar <sourav.poddar@ti.com>,
	linux-input@vger.kernel.org, linux-omap@vger.kernel.org,
	b-cousson@ti.com, santosh.shilimkar@ti.com,
	devicetree-discuss@lists.ozlabs.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCHv5] Input: keypad: Add smsc ece1099 keypad driver
Date: Mon, 29 Oct 2012 13:45:20 -0700	[thread overview]
Message-ID: <20121029204520.GC13256@core.coreip.homeip.net> (raw)
In-Reply-To: <20121029190516.GA29230@arwen.pp.htv.fi>

On Mon, Oct 29, 2012 at 09:05:53PM +0200, Felipe Balbi wrote:
> Hi,
> 
> On Mon, Oct 29, 2012 at 10:06:33AM -0700, Dmitry Torokhov wrote:
> 
> [ big snip ]
> 
> > > > +static int __devexit smsc_remove(struct platform_device *pdev)
> > > > +{
> > > 
> > > shouldn't you unregister the input device here ??
> > 
> > And that is why I do not like devm_* interface myself... But no, since
> > input device was allocated with devm_input_allocate_device() it does not
> > need to be explicitly freed or unregistered.
> 
> IMHO, that's a fragility on current devm implementation for input
> devices, then.
> 
> devm_input_allocate_device() is *only* allocating the input device (at
> least judging by the name). Looks like you should introduce
> devm_input_register_device() ? What happens if I
> devm_input_allocate_device() but don't go as far as
> input_register_device() (some error happens in-between) ?
> 

It will be freed automatically.

> I'm sure you have some proper handling for it, but it's quite misleading
> the way this was implemented.

Well, I could add devm_input_register_device(),
devm_input_unregister_device(), devm_input_free_device() and then add
checks to "normal" input_register_device(), input_unregister_device()
and input_free_device() to throw warnings and errors if they are used
with managed resources, and similarly add checks to devm_* API so that
they are not called with unmanaged devices and make a big mess out of
it.

_OR_ I could just add one new call devm_input_allocate_device() to
create managed input devices and make the rest of old API work with both
managed and unmanaged input devices. I think the latter is much better.

Thanks.

-- 
Dmitry

  parent reply	other threads:[~2012-10-29 20:45 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-29 10:38 [PATCHv5] Input: keypad: Add smsc ece1099 keypad driver Sourav Poddar
2012-10-29 10:38 ` Sourav Poddar
2012-10-29 16:20 ` Felipe Balbi
2012-10-29 16:20   ` Felipe Balbi
     [not found]   ` <20121029162045.GK27566-S8G//mZuvNWo5Im9Ml3/Zg@public.gmane.org>
2012-10-29 17:06     ` Dmitry Torokhov
2012-10-29 17:06       ` Dmitry Torokhov
2012-10-29 19:05       ` Felipe Balbi
2012-10-29 19:05         ` Felipe Balbi
     [not found]         ` <20121029190516.GA29230-S8G//mZuvNWo5Im9Ml3/Zg@public.gmane.org>
2012-10-29 20:45           ` Dmitry Torokhov [this message]
2012-10-29 20:45             ` Dmitry Torokhov
2012-10-30  5:31   ` Sourav
2012-10-30  5:31     ` Sourav

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=20121029204520.GC13256@core.coreip.homeip.net \
    --to=dmitry.torokhov-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
    --cc=balbi-l0cyMroinI0@public.gmane.org \
    --cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
    --cc=linux-input-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=santosh.shilimkar-l0cyMroinI0@public.gmane.org \
    --cc=sourav.poddar-l0cyMroinI0@public.gmane.org \
    /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.