All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: "H. Nikolaus Schaller" <hns@goldelico.com>
Cc: Fabio Estevam <fabio.estevam@freescale.com>,
	Peter Ujfalusi <peter.ujfalusi@ti.com>,
	linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
	kernel@pyra-handheld.com, letux-kernel@openphoenux.org
Subject: Re: [PATCH 2/5] input: twl6040-vibra: add handler to unregister input if module is removed
Date: Tue, 19 Apr 2016 09:53:25 -0700	[thread overview]
Message-ID: <20160419165325.GA2881@dtor-ws> (raw)
In-Reply-To: <2C8A7B47-516D-4AA0-8231-16015387FA86@goldelico.com>

On Tue, Apr 19, 2016 at 10:05:08AM +0200, H. Nikolaus Schaller wrote:
> 
> > Am 19.04.2016 um 09:57 schrieb Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> > 
> > On Tue, Apr 19, 2016 at 09:33:10AM +0200, H. Nikolaus Schaller wrote:
> >> 
> >>> Am 18.04.2016 um 23:12 schrieb Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> >>> 
> >>> On Mon, Apr 18, 2016 at 09:55:38PM +0200, H. Nikolaus Schaller wrote:
> >>>> commit 1f9e1470ab34 ("Input: twl6040-vibra - use devm functions")
> >>>> 
> >>>> converted everything to devm but we still need to call
> >>>> input_unregister_device(info->input_dev)
> >>> 
> >>> No, this is not needed, because devm-managed input devices will be
> >>> unregistered automatically.
> >> 
> >> Well, it would, if the current driver would use devm for registration. But it appears not to do it that way (line 375):
> >> 
> >> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/input/misc/twl6040-vibra.c?id=refs/tags/v4.6-rc4#n375
> >> 
> >> So we either have to fix line 375 or add the proposed explicit unregister call.
> >> 
> >> Research shows me that you did propose devm_input_register_device() some years ago but this API was never included:
> >> 
> >> https://lkml.org/lkml/2012/10/29/855
> > 
> > That's because we have what I mentioned in _OR_ portion of that email:
> > 
> > /**
> > * 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.
> > */
> > 
> 
> Hm. If I remember correctly (it is a while ago) we had to add this explicit
> unregister mechanism because we got ugly kernel panics otherwise. Indicating
> that the input device was still registered and *not* unregistered automatically.

Ah, it is probably because we are messing up with input device's parent.
Can you please try the patch below?

Thanks.

-- 
Dmitry


Input: twl6040-vibra - do not reparent to grandparent

From: Dmitry Torokhov <dmitry.torokhov@gmail.com>

For devm-managed input devices we should not modify input device's parent,
otherwise automatic release of resources will not work properly.

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
 drivers/input/misc/twl6040-vibra.c |    1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/input/misc/twl6040-vibra.c b/drivers/input/misc/twl6040-vibra.c
index 0c853c2..53e33fa 100644
--- a/drivers/input/misc/twl6040-vibra.c
+++ b/drivers/input/misc/twl6040-vibra.c
@@ -357,7 +357,6 @@ static int twl6040_vibra_probe(struct platform_device *pdev)
 
 	info->input_dev->name = "twl6040:vibrator";
 	info->input_dev->id.version = 1;
-	info->input_dev->dev.parent = pdev->dev.parent;
 	info->input_dev->close = twl6040_vibra_close;
 	__set_bit(FF_RUMBLE, info->input_dev->ffbit);
 

  reply	other threads:[~2016-04-19 16:53 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-18 19:55 [PATCH 0/5] fixes for twl6040-vibra H. Nikolaus Schaller
2016-04-18 19:55 ` [PATCH 1/5] input: twl6040-vibra: fix DT node memory management H. Nikolaus Schaller
2016-04-18 21:22   ` Dmitry Torokhov
2016-04-19  7:43     ` H. Nikolaus Schaller
2016-04-19 17:06       ` Dmitry Torokhov
2016-04-20  9:03         ` H. Nikolaus Schaller
2016-05-08  6:49           ` [Kernel] " H. Nikolaus Schaller
2016-05-10  0:02             ` Dmitry Torokhov
2016-04-18 19:55 ` [PATCH 2/5] input: twl6040-vibra: add handler to unregister input if module is removed H. Nikolaus Schaller
2016-04-18 21:12   ` Dmitry Torokhov
2016-04-19  7:33     ` H. Nikolaus Schaller
2016-04-19  7:57       ` Dmitry Torokhov
2016-04-19  8:05         ` H. Nikolaus Schaller
2016-04-19 16:53           ` Dmitry Torokhov [this message]
2016-04-20  9:12             ` H. Nikolaus Schaller
2016-04-18 19:55 ` [PATCH 3/5] input: twl6040-vibra: fix NULL pointer dereference by removing workqueue H. Nikolaus Schaller
2016-04-18 21:47   ` Dmitry Torokhov
2016-04-18 19:55 ` [PATCH 4/5] input: twl6040-vibra: ignore return value of schedule_work H. Nikolaus Schaller
2016-04-18 21:47   ` Dmitry Torokhov
2016-04-18 19:55 ` [PATCH 5/5] input: twl6040-vibra: remove mutex H. Nikolaus Schaller
2016-04-18 21:20   ` Dmitry Torokhov
2016-04-19  7:49     ` H. Nikolaus Schaller
2016-04-19  8:01       ` Dmitry Torokhov
2016-04-19  8:08         ` H. Nikolaus Schaller
2016-04-20  9:22           ` [Letux-kernel] " H. Nikolaus Schaller
2016-04-20  9:22             ` H. Nikolaus Schaller
2016-04-20 17:49             ` Dmitry Torokhov
2016-04-20 18:10               ` H. Nikolaus Schaller
2016-04-20 18:15                 ` Dmitry Torokhov
2016-04-20 19:00                   ` H. Nikolaus Schaller

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=20160419165325.GA2881@dtor-ws \
    --to=dmitry.torokhov@gmail.com \
    --cc=fabio.estevam@freescale.com \
    --cc=hns@goldelico.com \
    --cc=kernel@pyra-handheld.com \
    --cc=letux-kernel@openphoenux.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peter.ujfalusi@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.