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: Thu, 18 Oct 2012 09:29:08 +0200 [thread overview]
Message-ID: <201210180929.08509.poeschel@lemonage.de> (raw)
In-Reply-To: <507D3DE8.3040003@metafoo.de>
On Tuesday 16 October 2012 at 12:58:48, Lars-Peter Clausen wrote:
> 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:
> >> 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;
I thought about this and I am not fully happy with it:
If we add the mfd devices to the usb_interface parent they are at the same
level in the device tree as the usb endpoints and stuff. I would consider this
logically wrong.
Is this something we should take care of ?
next prev parent reply other threads:[~2012-10-18 7:29 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
2012-10-18 7:29 ` Lars Poeschel [this message]
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=201210180929.08509.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.