From: Lee Jones <lee.jones@linaro.org>
To: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: Darren Hart <dvhart@linux.intel.com>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Al Stone <al.stone@linaro.org>, Olof Johansson <olof@lixom.net>,
Matthew Garrett <matthew.garrett@nebula.com>,
Matt Fleming <matt.fleming@intel.com>,
David Woodhouse <dwmw2@infradead.org>,
"H. Peter Anvin" <hpa@zytor.com>,
Jacob Pan <jacob.jun.pan@linux.intel.com>,
Josh Triplett <josh@joshtriplett.org>,
Aaron Lu <aaron.lu@intel.com>,
Max Eliaser <max.eliaser@intel.com>,
Robert Moore <robert.moore@intel.com>,
Len Brown <lenb@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Linus Walleij <linus.walleij@linaro.org>,
Alexandre Courbot <gnurou@gmail.com>,
Mark Brown <broonie@linaro.org>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
Bryan Wu <cooloney@gmail.com>, Richard Purdie <rpurdie@rpsys.net>,
Samuel Ortiz <sameo@linux.intel.com>,
Grant Likely <grant.likely@linaro.org>R
Subject: Re: [RFC PATCH 5/9] mfd: Add ACPI support
Date: Wed, 20 Aug 2014 16:54:59 +0100 [thread overview]
Message-ID: <20140820155459.GM4266@lee--X1> (raw)
In-Reply-To: <1408172039-32513-6-git-send-email-mika.westerberg@linux.intel.com>
On Sat, 16 Aug 2014, Mika Westerberg wrote:
> If an MFD device is backed by ACPI namespace, we should allow subdevice
> drivers to access their corresponding ACPI companion devices through normal
> means (e.g using ACPI_COMPANION()).
>
> This patch adds such support to the MFD core. If the MFD parent device
> doesn't specify any ACPI _HID/_CID for the child device, the child device
> will share the parent ACPI companion device. Otherwise the child device
> will be assigned with the corresponding ACPI companion, if found in the
> namespace below the parent.
>
> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> Reviewed-by: Darren Hart <dvhart@linux.intel.com>
> ---
> Documentation/acpi/enumeration.txt | 27 +++++++++++++++++++++++++
> drivers/mfd/mfd-core.c | 41 ++++++++++++++++++++++++++++++++++++++
> include/linux/mfd/core.h | 3 +++
> 3 files changed, 71 insertions(+)
>
> diff --git a/Documentation/acpi/enumeration.txt b/Documentation/acpi/enumeration.txt
> index e182be5e3c83..74e35c54febf 100644
> --- a/Documentation/acpi/enumeration.txt
> +++ b/Documentation/acpi/enumeration.txt
> @@ -312,3 +312,30 @@ a code like this:
>
> There are also devm_* versions of these functions which release the
> descriptors once the device is released.
> +
> +MFD devices
> +~~~~~~~~~~~
> +The MFD devices create platform devices from their children. For the
What does this mean? MFD drivers register their children _as_
platform devices.
> +child devices there needs to be an ACPI handle that they can use to
> +reference parts of the ACPI namespace that relate to them. In the Linux
> +MFD subsystem we provide two ways:
> +
> + o The children share the parent ACPI handle.
> + o The MFD cell can specify the ACPI id of the device.
> +
> +For the first case, the MFD drivers do not need to do anything. The
> +resulting child platform device will have its ACPI_COMPANION() set to point
> +to the parent device.
> +
> +If the ACPI namespace has a device that we can match using an ACPI id,
> +the id should be set like:
> +
> + static struct mfd_cell my_subdevice_cell = {
> + .name = "my_subdevice",
> + /* set the resources relative to the parent */
> + .acpi_pnpid = "XYZ0001",
> + };
> +
> +The ACPI id "XYZ0001" is then used to lookup an ACPI device directly under
> +the MFD device and if found, that ACPI companion device is bound to the
> +resulting child platform device.
> diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c
> index 892d343193ad..bb466b28b3b6 100644
> --- a/drivers/mfd/mfd-core.c
> +++ b/drivers/mfd/mfd-core.c
> @@ -78,6 +78,45 @@ static int mfd_platform_add_cell(struct platform_device *pdev,
> return 0;
> }
>
> +#if IS_ENABLED(CONFIG_ACPI)
> +static void mfd_acpi_add_device(const struct mfd_cell *cell,
> + struct platform_device *pdev)
> +{
> + struct acpi_device *parent_adev;
> + struct acpi_device *adev = NULL;
> +
> + parent_adev = ACPI_COMPANION(pdev->dev.parent);
> + if (!parent_adev)
> + return;
> +
> + /*
> + * MFD child device gets its ACPI handle either from the ACPI
> + * device directly under the parent that matches the acpi_pnpid or
> + * it will use the parent handle if is no acpi_pnpid is given.
> + */
> + if (cell->acpi_pnpid) {
> + struct acpi_device_id ids[2] = {};
> + struct acpi_device *child_adev;
> +
> + strlcpy(ids[0].id, cell->acpi_pnpid, sizeof(ids[0].id));
> + list_for_each_entry(child_adev, &parent_adev->children, node)
> + if (acpi_match_device_ids(child_adev, ids)) {
> + adev = child_adev;
> + break;
> + }
> + } else {
> + adev = parent_adev;
> + }
> +
> + ACPI_COMPANION_SET(&pdev->dev, adev);
> +}
> +#else
> +static inline void mfd_acpi_add_device(const struct mfd_cell *cell,
> + struct platform_device *pdev)
> +{
> +}
> +#endif
> +
I'm not keen on polluting the MFD core driver with #differy. Can't you
think of another way to do it?
> static int mfd_add_device(struct device *parent, int id,
> const struct mfd_cell *cell, atomic_t *usage_count,
> struct resource *mem_base,
> @@ -118,6 +157,8 @@ static int mfd_add_device(struct device *parent, int id,
> }
> }
>
> + mfd_acpi_add_device(cell, pdev);
> +
> if (cell->pdata_size) {
> ret = platform_device_add_data(pdev,
> cell->platform_data, cell->pdata_size);
> diff --git a/include/linux/mfd/core.h b/include/linux/mfd/core.h
> index f543de91ce19..73e1709d4c09 100644
> --- a/include/linux/mfd/core.h
> +++ b/include/linux/mfd/core.h
> @@ -44,6 +44,9 @@ struct mfd_cell {
> */
> const char *of_compatible;
>
> + /* Matches ACPI PNP id, either _HID or _CID */
> + const char *acpi_pnpid;
> +
> /*
> * These resources can be specified relative to the parent device.
> * For accessing hardware you should use resources from the platform dev
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Lee Jones <lee.jones@linaro.org>
To: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: Darren Hart <dvhart@linux.intel.com>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Al Stone <al.stone@linaro.org>, Olof Johansson <olof@lixom.net>,
Matthew Garrett <matthew.garrett@nebula.com>,
Matt Fleming <matt.fleming@intel.com>,
David Woodhouse <dwmw2@infradead.org>,
"H. Peter Anvin" <hpa@zytor.com>,
Jacob Pan <jacob.jun.pan@linux.intel.com>,
Josh Triplett <josh@joshtriplett.org>,
Aaron Lu <aaron.lu@intel.com>,
Max Eliaser <max.eliaser@intel.com>,
Robert Moore <robert.moore@intel.com>,
Len Brown <lenb@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Linus Walleij <linus.walleij@linaro.org>,
Alexandre Courbot <gnurou@gmail.com>,
Mark Brown <broonie@linaro.org>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
Bryan Wu <cooloney@gmail.com>, Richard Purdie <rpurdie@rpsys.net>,
Samuel Ortiz <sameo@linux.intel.com>,
Grant Likely <grant.likely@linaro.org>,
Rob Herring <robh+dt@kernel.org>,
linux-acpi@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 5/9] mfd: Add ACPI support
Date: Wed, 20 Aug 2014 16:54:59 +0100 [thread overview]
Message-ID: <20140820155459.GM4266@lee--X1> (raw)
In-Reply-To: <1408172039-32513-6-git-send-email-mika.westerberg@linux.intel.com>
On Sat, 16 Aug 2014, Mika Westerberg wrote:
> If an MFD device is backed by ACPI namespace, we should allow subdevice
> drivers to access their corresponding ACPI companion devices through normal
> means (e.g using ACPI_COMPANION()).
>
> This patch adds such support to the MFD core. If the MFD parent device
> doesn't specify any ACPI _HID/_CID for the child device, the child device
> will share the parent ACPI companion device. Otherwise the child device
> will be assigned with the corresponding ACPI companion, if found in the
> namespace below the parent.
>
> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> Reviewed-by: Darren Hart <dvhart@linux.intel.com>
> ---
> Documentation/acpi/enumeration.txt | 27 +++++++++++++++++++++++++
> drivers/mfd/mfd-core.c | 41 ++++++++++++++++++++++++++++++++++++++
> include/linux/mfd/core.h | 3 +++
> 3 files changed, 71 insertions(+)
>
> diff --git a/Documentation/acpi/enumeration.txt b/Documentation/acpi/enumeration.txt
> index e182be5e3c83..74e35c54febf 100644
> --- a/Documentation/acpi/enumeration.txt
> +++ b/Documentation/acpi/enumeration.txt
> @@ -312,3 +312,30 @@ a code like this:
>
> There are also devm_* versions of these functions which release the
> descriptors once the device is released.
> +
> +MFD devices
> +~~~~~~~~~~~
> +The MFD devices create platform devices from their children. For the
What does this mean? MFD drivers register their children _as_
platform devices.
> +child devices there needs to be an ACPI handle that they can use to
> +reference parts of the ACPI namespace that relate to them. In the Linux
> +MFD subsystem we provide two ways:
> +
> + o The children share the parent ACPI handle.
> + o The MFD cell can specify the ACPI id of the device.
> +
> +For the first case, the MFD drivers do not need to do anything. The
> +resulting child platform device will have its ACPI_COMPANION() set to point
> +to the parent device.
> +
> +If the ACPI namespace has a device that we can match using an ACPI id,
> +the id should be set like:
> +
> + static struct mfd_cell my_subdevice_cell = {
> + .name = "my_subdevice",
> + /* set the resources relative to the parent */
> + .acpi_pnpid = "XYZ0001",
> + };
> +
> +The ACPI id "XYZ0001" is then used to lookup an ACPI device directly under
> +the MFD device and if found, that ACPI companion device is bound to the
> +resulting child platform device.
> diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c
> index 892d343193ad..bb466b28b3b6 100644
> --- a/drivers/mfd/mfd-core.c
> +++ b/drivers/mfd/mfd-core.c
> @@ -78,6 +78,45 @@ static int mfd_platform_add_cell(struct platform_device *pdev,
> return 0;
> }
>
> +#if IS_ENABLED(CONFIG_ACPI)
> +static void mfd_acpi_add_device(const struct mfd_cell *cell,
> + struct platform_device *pdev)
> +{
> + struct acpi_device *parent_adev;
> + struct acpi_device *adev = NULL;
> +
> + parent_adev = ACPI_COMPANION(pdev->dev.parent);
> + if (!parent_adev)
> + return;
> +
> + /*
> + * MFD child device gets its ACPI handle either from the ACPI
> + * device directly under the parent that matches the acpi_pnpid or
> + * it will use the parent handle if is no acpi_pnpid is given.
> + */
> + if (cell->acpi_pnpid) {
> + struct acpi_device_id ids[2] = {};
> + struct acpi_device *child_adev;
> +
> + strlcpy(ids[0].id, cell->acpi_pnpid, sizeof(ids[0].id));
> + list_for_each_entry(child_adev, &parent_adev->children, node)
> + if (acpi_match_device_ids(child_adev, ids)) {
> + adev = child_adev;
> + break;
> + }
> + } else {
> + adev = parent_adev;
> + }
> +
> + ACPI_COMPANION_SET(&pdev->dev, adev);
> +}
> +#else
> +static inline void mfd_acpi_add_device(const struct mfd_cell *cell,
> + struct platform_device *pdev)
> +{
> +}
> +#endif
> +
I'm not keen on polluting the MFD core driver with #differy. Can't you
think of another way to do it?
> static int mfd_add_device(struct device *parent, int id,
> const struct mfd_cell *cell, atomic_t *usage_count,
> struct resource *mem_base,
> @@ -118,6 +157,8 @@ static int mfd_add_device(struct device *parent, int id,
> }
> }
>
> + mfd_acpi_add_device(cell, pdev);
> +
> if (cell->pdata_size) {
> ret = platform_device_add_data(pdev,
> cell->platform_data, cell->pdata_size);
> diff --git a/include/linux/mfd/core.h b/include/linux/mfd/core.h
> index f543de91ce19..73e1709d4c09 100644
> --- a/include/linux/mfd/core.h
> +++ b/include/linux/mfd/core.h
> @@ -44,6 +44,9 @@ struct mfd_cell {
> */
> const char *of_compatible;
>
> + /* Matches ACPI PNP id, either _HID or _CID */
> + const char *acpi_pnpid;
> +
> /*
> * These resources can be specified relative to the parent device.
> * For accessing hardware you should use resources from the platform dev
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
next prev parent reply other threads:[~2014-08-20 15:55 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-16 6:53 [RFC PATCH 0/9] Add ACPI _DSD and unified device properties support Mika Westerberg
2014-08-16 6:53 ` [RFC PATCH 1/9] ACPI: Add support for device specific properties Mika Westerberg
2014-08-16 6:53 ` [RFC PATCH 2/9] ACPI: Document ACPI " Mika Westerberg
2014-08-16 6:53 ` [RFC PATCH 3/9] Driver core: Unified device properties interface for platform firmware Mika Westerberg
2014-08-16 6:53 ` [RFC PATCH 4/9] of: Add property_ops callback for devices with of_node Mika Westerberg
2014-08-16 6:53 ` [RFC PATCH 5/9] mfd: Add ACPI support Mika Westerberg
2014-08-20 15:54 ` Lee Jones [this message]
2014-08-20 15:54 ` Lee Jones
2014-08-21 9:05 ` Mika Westerberg
2014-08-21 9:05 ` Mika Westerberg
2014-08-16 6:53 ` [RFC PATCH 6/9] gpiolib: add API to get gpio desc and flags Mika Westerberg
2014-08-18 16:24 ` Alexandre Courbot
2014-08-19 8:56 ` Mika Westerberg
2014-08-19 8:56 ` Mika Westerberg
2014-08-19 9:02 ` Aaron Lu
2014-08-19 9:02 ` Aaron Lu
2014-08-19 17:16 ` Alexandre Courbot
2014-08-19 17:16 ` Alexandre Courbot
2014-08-16 6:53 ` [RFC PATCH 7/9] gpio: sch: Consolidate core and resume banks Mika Westerberg
2014-08-29 6:36 ` Linus Walleij
2014-08-29 6:36 ` Linus Walleij
2014-08-16 6:53 ` [RFC PATCH 8/9] Input: gpio_keys_polled - Make use of device property API Mika Westerberg
2014-08-18 17:55 ` Jacob Pan
2014-08-18 17:55 ` Jacob Pan
2014-08-19 9:27 ` Mika Westerberg
2014-08-19 9:27 ` Mika Westerberg
2014-08-19 15:21 ` Darren Hart
2014-08-19 15:21 ` Darren Hart
2014-08-16 6:53 ` [RFC PATCH 9/9] leds: leds-gpio: " Mika Westerberg
2014-08-16 16:06 ` [RFC PATCH 0/9] Add ACPI _DSD and unified device properties support Darren Hart
2014-08-16 16:06 ` Darren Hart
2014-08-17 14:11 ` Dmitry Torokhov
2014-08-17 14:11 ` Dmitry Torokhov
2014-08-17 16:52 ` Darren Hart
2014-08-16 18:48 ` Josh Triplett
2014-08-16 18:48 ` Josh Triplett
2014-08-17 6:55 ` Mika Westerberg
2014-08-17 6:55 ` Mika Westerberg
-- strict thread matches above, loose matches on Subject: below --
2014-08-17 6:04 Mika Westerberg
2014-08-17 6:04 ` [RFC PATCH 5/9] mfd: Add ACPI support Mika Westerberg
2014-08-28 11:29 ` Lee Jones
2014-08-28 11:29 ` Lee Jones
2014-08-28 11:45 ` Mika Westerberg
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=20140820155459.GM4266@lee--X1 \
--to=lee.jones@linaro.org \
--cc=aaron.lu@intel.com \
--cc=al.stone@linaro.org \
--cc=broonie@linaro.org \
--cc=cooloney@gmail.com \
--cc=dmitry.torokhov@gmail.com \
--cc=dvhart@linux.intel.com \
--cc=dwmw2@infradead.org \
--cc=gnurou@gmail.com \
--cc=grant.likely@linaro.org \
--cc=gregkh@linuxfoundation.org \
--cc=hpa@zytor.com \
--cc=jacob.jun.pan@linux.intel.com \
--cc=josh@joshtriplett.org \
--cc=lenb@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=matt.fleming@intel.com \
--cc=matthew.garrett@nebula.com \
--cc=max.eliaser@intel.com \
--cc=mika.westerberg@linux.intel.com \
--cc=olof@lixom.net \
--cc=rafael@kernel.org \
--cc=robert.moore@intel.com \
--cc=rpurdie@rpsys.net \
--cc=sameo@linux.intel.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.