All of lore.kernel.org
 help / color / mirror / Atom feed
From: Felipe Balbi <balbi@ti.com>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Felipe Balbi <balbi@ti.com>, 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 21:05:53 +0200	[thread overview]
Message-ID: <20121029190516.GA29230@arwen.pp.htv.fi> (raw)
In-Reply-To: <20121029170633.GA11558@core.coreip.homeip.net>

[-- Attachment #1: Type: text/plain, Size: 938 bytes --]

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) ?

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

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Felipe Balbi <balbi@ti.com>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Felipe Balbi <balbi@ti.com>, 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 21:05:53 +0200	[thread overview]
Message-ID: <20121029190516.GA29230@arwen.pp.htv.fi> (raw)
In-Reply-To: <20121029170633.GA11558@core.coreip.homeip.net>

[-- Attachment #1: Type: text/plain, Size: 938 bytes --]

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) ?

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

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2012-10-29 19:11 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 [this message]
2012-10-29 19:05         ` Felipe Balbi
     [not found]         ` <20121029190516.GA29230-S8G//mZuvNWo5Im9Ml3/Zg@public.gmane.org>
2012-10-29 20:45           ` Dmitry Torokhov
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=20121029190516.GA29230@arwen.pp.htv.fi \
    --to=balbi@ti.com \
    --cc=b-cousson@ti.com \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=santosh.shilimkar@ti.com \
    --cc=sourav.poddar@ti.com \
    /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.