From: Lars Poeschel <poeschel@lemonage.de>
To: "Lars-Peter Clausen" <lars@metafoo.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 11:43:19 +0200 [thread overview]
Message-ID: <201210161143.19619.poeschel@lemonage.de> (raw)
In-Reply-To: <507D1D7A.4040205@metafoo.de>
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.
next prev parent reply other threads:[~2012-10-16 9:43 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 [this message]
2012-10-16 10:58 ` Lars-Peter Clausen
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=201210161143.19619.poeschel@lemonage.de \
--to=poeschel@lemonage.de \
--cc=ben-linux@fluff.org \
--cc=grant.likely@secretlab.ca \
--cc=jic23@cam.ac.uk \
--cc=khali@linux-fr.org \
--cc=lars@metafoo.de \
--cc=larsi@wh2.tu-dresden.de \
--cc=linus.walleij@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--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.