All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lars-Peter Clausen <lars@metafoo.de>
To: Lars Poeschel <poeschel@lemonage.de>
Cc: Lars Poeschel <larsi@wh2.tu-dresden.de>,
	sameo@linux.intel.com, linux-kernel@vger.kernel.org,
	jic23@cam.ac.uk, khali@linux-fr.org, ben-linux@fluff.org,
	w.sang@pengutronix.de, grant.likely@secretlab.ca,
	linus.walleij@linaro.org
Subject: Re: [PATCH v2 1/4] mfd: add viperboard driver
Date: Tue, 16 Oct 2012 12:58:48 +0200	[thread overview]
Message-ID: <507D3DE8.3040003@metafoo.de> (raw)
In-Reply-To: <201210161143.19619.poeschel@lemonage.de>

On 10/16/2012 11:43 AM, Lars Poeschel wrote:
> On Tuesday 16 October 2012 at 10:40:26, Lars-Peter Clausen wrote:
>> On 10/12/2012 04:34 PM, Lars Poeschel wrote:
>>> [...]
>>> +static void vprbrd_dev_release(struct device *dev)
>>> +{
>>> +	return;
>>
>> A empty release callback is usually a good indicator that something is
>> wrong. The release callback will be called once the last reference to the
>> device has been called, so the memory associated with the device should not
>> be freed before the release callback has been called, otherwise the memory
>> might be accessed after it has been freed...
>>
>>> +}
>>> +
>>> +static void vprbrd_free(struct vprbrd *dev)
>>> +{
>>> +	usb_put_dev(dev->usb_dev);
>>> +	kfree(dev);
>>
>> ..., so this kfree should be moved from here to the release callback.
> 
> Thank you for catching that one!
>  
>> Btw. I'm wondering why is the extra platform device required? Can't you not
>> just use the usb device as the parent device for the mfd cells?
> 
> This is what I first did, but this does not work. You can read about my first 
> thoughts why this is not working here: (To sum it up: The device is housed in 
> an usb_device, not a platform_device and This usb_device has no mfd_cell 
> member.)
> 
> https://lkml.org/lkml/2012/9/28/327
> 
> As I got a bit more deeper I also noticed, that mfd_add_devices (obviously) 
> adds the devices "as childs" to the parent device. mfd_remove_devices then 
> removes ALL "child" devices from the parent, not only those added by 
> mfd_add_devices before. This does not work in the case of the usb parent 
> device, because it has other childs that the usb layer added before (some 
> endpoints and stuff). So I had to construct an "empty" (in sense of childs) 
> mock platform_device between the usb and mfd.

Ah, ok that makes sense. I was a bit confused, because there are other mfd
drivers with for example i2c or spi devices as parents and these work fine,
but I guess this is because non of them registers any additional child
devices. I guess it makes sense to create a mfd cell device type and assign
this type to newly created mfd cells and only unregister a device in
mfd_remove_devices if it has the correct device type.

E.g. something along the lines of:


--- a/drivers/mfd/mfd-core.c
+++ b/drivers/mfd/mfd-core.c
@@ -21,6 +21,10 @@
 #include <linux/irqdomain.h>
 #include <linux/of.h>

+static struct device_type mfd_device_type = {
+	.name = "mfd-cell",
+};
+
 int mfd_cell_enable(struct platform_device *pdev)
 {
 	const struct mfd_cell *cell = mfd_get_cell(pdev);
@@ -91,6 +95,7 @@ static int mfd_add_device(struct device *parent, int id,
 		goto fail_device;

 	pdev->dev.parent = parent;
+	pdev->dev.type = &mfd_device_type;

 	if (parent->of_node && cell->of_compatible) {
 		for_each_child_of_node(parent->of_node, np) {
@@ -204,10 +209,16 @@ EXPORT_SYMBOL(mfd_add_devices);

 static int mfd_remove_devices_fn(struct device *dev, void *c)
 {
-	struct platform_device *pdev = to_platform_device(dev);
-	const struct mfd_cell *cell = mfd_get_cell(pdev);
+	struct platform_device *pdev;
+	const struct mfd_cell *cell;
 	atomic_t **usage_count = c;

+	if (dev->type != &mfd_device_type)
+		return 0;
+
+	pdev = to_platform_device(dev);
+	cell = mfd_get_cell(pdev);
+
 	/* find the base address of usage_count pointers (for freeing) */
 	if (!*usage_count || (cell->usage_count < *usage_count))
 		*usage_count = cell->usage_count;

  reply	other threads:[~2012-10-16 10:57 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-27 13:08 [PATCH] mfd: viperboard driver added larsi
2012-09-19 15:29 ` Samuel Ortiz
2012-09-24 16:46   ` Lars Poeschel
2012-09-25  8:55     ` Samuel Ortiz
2012-09-28 13:59       ` Lars Poeschel
2012-10-12 14:34       ` [PATCH v2 1/4] mfd: add viperboard driver Lars Poeschel
2012-10-12 14:34         ` [PATCH v2 2/4] gpio: add viperboard gpio driver Lars Poeschel
2012-10-15 13:00           ` Linus Walleij
2012-10-16  6:51             ` Lars Poeschel
2012-10-16 10:00               ` Linus Walleij
2012-10-16 13:38                 ` Lars Poeschel
2012-10-16 17:11                   ` Linus Walleij
2012-10-23 15:24                     ` Lars Poeschel
2012-10-24  7:53                       ` Linus Walleij
2012-10-24 16:31                         ` Mark Brown
2012-10-25 10:02                           ` Lars Poeschel
2012-10-25 14:00                             ` Mark Brown
2012-10-25 16:02                               ` Lars Poeschel
2012-10-25 16:06                                 ` Mark Brown
2012-10-26  9:16                                   ` Lars Poeschel
2012-10-27 16:14                                     ` Linus Walleij
2012-10-27 21:35                                       ` Mark Brown
2012-10-12 14:34         ` [PATCH v2 3/4] i2c: add viperboard i2c master driver Lars Poeschel
2012-10-12 14:34         ` [PATCH v2 4/4] iio: adc: add viperboard adc driver Lars Poeschel
2012-10-15 14:26           ` Lars-Peter Clausen
2012-10-16  7:11             ` Lars Poeschel
2012-10-15 17:09         ` [PATCH v2 1/4] mfd: add viperboard driver Peter Meerwald
2012-10-16  7:15           ` Lars Poeschel
2012-10-16  8:40         ` Lars-Peter Clausen
2012-10-16  9:43           ` Lars Poeschel
2012-10-16 10:58             ` Lars-Peter Clausen [this message]
2012-10-18  7:29               ` Lars Poeschel
2012-10-18 14:13                 ` Lars-Peter Clausen

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=507D3DE8.3040003@metafoo.de \
    --to=lars@metafoo.de \
    --cc=ben-linux@fluff.org \
    --cc=grant.likely@secretlab.ca \
    --cc=jic23@cam.ac.uk \
    --cc=khali@linux-fr.org \
    --cc=larsi@wh2.tu-dresden.de \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=poeschel@lemonage.de \
    --cc=sameo@linux.intel.com \
    --cc=w.sang@pengutronix.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.