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>,
Aaron Lu <aaron.lu@intel.com>,
Max Eliaser <max.eliaser@intel.com>,
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: Thu, 28 Aug 2014 12:29:00 +0100 [thread overview]
Message-ID: <20140828112900.GM24579@lee--X1> (raw)
In-Reply-To: <1408255459-17625-6-git-send-email-mika.westerberg@linux.intel.com>
On Sun, 17 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
> +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;
> + }
What happens if cell->acpi_pnpid is provided, but not matched?
Surely adev will them be NULL?
In these cases shouldn't you then "adev = parent_adev"?
> + } 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
> +
> 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
next prev parent reply other threads:[~2014-08-28 11:29 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-17 6:04 [RFC PATCH 0/9] Add ACPI _DSD and unified device properties support Mika Westerberg
2014-08-17 6:04 ` [RFC PATCH 1/9] ACPI: Add support for device specific properties Mika Westerberg
2014-08-18 8:13 ` Hanjun Guo
2014-08-18 8:27 ` Mika Westerberg
2014-08-18 8:57 ` Hanjun Guo
2014-08-18 12:37 ` Darren Hart
[not found] ` <1408255459-17625-1-git-send-email-mika.westerberg-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2014-08-17 6:04 ` [RFC PATCH 2/9] ACPI: Document ACPI " Mika Westerberg
2014-08-18 10:54 ` Mark Rutland
2014-08-18 16:05 ` Mika Westerberg
2014-08-19 5:45 ` Darren Hart
2014-08-19 16:51 ` Mark Rutland
2014-08-17 6:04 ` [RFC PATCH 6/9] gpiolib: add API to get gpio desc and flags Mika Westerberg
2014-08-17 13:00 ` Grant Likely
2014-08-17 17:43 ` Darren Hart
2014-08-18 4:57 ` Rafael J. Wysocki
[not found] ` <1927766.GeLld99ozq-sKB8Sp2ER+y1GS7QM15AGw@public.gmane.org>
2014-08-18 7:16 ` Aaron Lu
2014-08-19 15:58 ` Grant Likely
2014-08-17 6:04 ` [RFC PATCH 7/9] gpio: sch: Consolidate core and resume banks Mika Westerberg
2014-08-17 6:04 ` [RFC PATCH 3/9] Driver core: Unified device properties interface for platform firmware Mika Westerberg
2014-08-17 12:49 ` Grant Likely
2014-08-17 17:31 ` Darren Hart
2014-08-18 4:55 ` Rafael J. Wysocki
2014-08-18 4:46 ` Rafael J. Wysocki
2014-08-17 6:04 ` [RFC PATCH 4/9] of: Add property_ops callback for devices with of_node Mika Westerberg
2014-08-17 12:54 ` Grant Likely
2014-08-18 9:29 ` Mika Westerberg
[not found] ` <20140818092937.GT2462-3PARRvDOhMZrdx17CPfAsdBPR1lH4CV8@public.gmane.org>
2014-08-18 12:44 ` Darren Hart
2014-08-18 0:44 ` Rob Herring
2014-08-17 6:04 ` [RFC PATCH 5/9] mfd: Add ACPI support Mika Westerberg
2014-08-28 11:29 ` Lee Jones [this message]
2014-08-28 11:45 ` Mika Westerberg
2014-08-17 6:04 ` [RFC PATCH 8/9] Input: gpio_keys_polled - Make use of device property API Mika Westerberg
2014-08-17 6:04 ` [RFC PATCH 9/9] leds: leds-gpio: " Mika Westerberg
[not found] <1408172039-32513-1-git-send-email-mika.westerberg@linux.intel.com>
[not found] ` <1408172039-32513-6-git-send-email-mika.westerberg@linux.intel.com>
2014-08-20 15:54 ` [RFC PATCH 5/9] mfd: Add ACPI support Lee Jones
2014-08-21 9:05 ` 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=20140828112900.GM24579@lee--X1 \
--to=lee.jones@linaro.org \
--cc=aaron.lu@intel.com \
--cc=devicetree@vger.kernel.org \
--cc=dvhart@linux.intel.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=max.eliaser@intel.com \
--cc=mika.westerberg@linux.intel.com \
--cc=rafael@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox