From: Aaron Lu <aaron.lu@intel.com>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Chris Ball <cjb@laptop.org>,
linux-mmc@vger.kernel.org, linux-pm@vger.kernel.org,
linux-acpi@vger.kernel.org, Aaron Lu <aaron.lwe@gmail.com>
Subject: Re: [RFC PATCH 2/4] mmc: sdio: bind sdio device with acpi device
Date: Sat, 20 Oct 2012 15:12:47 +0800 [thread overview]
Message-ID: <20121020071244.GA4798@localhost.localdomain> (raw)
In-Reply-To: <1834995.5UHtKnYTb2@vostro.rjw.lan>
On Fri, Oct 19, 2012 at 01:25:46AM +0200, Rafael J. Wysocki wrote:
> On Friday 12 of October 2012 11:12:39 Aaron Lu wrote:
> > ACPI spec defines the _ADDR encoding for sdio bus as:
> > High word - slot number (0 based)
> > Low word - function number
> >
> > This patch adds support for sdio device binding with acpi using the
> > generic ACPI glue framework.
> >
> > Signed-off-by: Aaron Lu <aaron.lu@intel.com>
> > ---
> > drivers/mmc/core/Makefile | 1 +
> > drivers/mmc/core/sdio_acpi.c | 35 +++++++++++++++++++++++++++++++++++
> > drivers/mmc/core/sdio_bus.c | 14 ++++++++++++--
> > drivers/mmc/core/sdio_bus.h | 2 ++
> > 4 files changed, 50 insertions(+), 2 deletions(-)
> > create mode 100644 drivers/mmc/core/sdio_acpi.c
> >
> > diff --git a/drivers/mmc/core/Makefile b/drivers/mmc/core/Makefile
> > index 38ed210..c8300aa 100644
> > --- a/drivers/mmc/core/Makefile
> > +++ b/drivers/mmc/core/Makefile
> > @@ -10,3 +10,4 @@ mmc_core-y := core.o bus.o host.o \
> > quirks.o slot-gpio.o
> >
> > mmc_core-$(CONFIG_DEBUG_FS) += debugfs.o
> > +mmc_core-$(CONFIG_ACPI) += sdio_acpi.o
> > diff --git a/drivers/mmc/core/sdio_acpi.c b/drivers/mmc/core/sdio_acpi.c
> > new file mode 100644
> > index 0000000..0f92e90
> > --- /dev/null
> > +++ b/drivers/mmc/core/sdio_acpi.c
> > @@ -0,0 +1,35 @@
> > +#include <linux/mmc/host.h>
> > +#include <linux/mmc/card.h>
> > +#include <linux/mmc/sdhci.h>
> > +#include <linux/mmc/sdio_func.h>
> > +#include <linux/acpi.h>
> > +#include <acpi/acpi_bus.h>
> > +#include "sdio_bus.h"
> > +
> > +static int acpi_sdio_find_device(struct device *dev, acpi_handle *handle)
> > +{
> > + struct sdio_func *func;
> > + struct sdhci_host *host;
> > + u64 addr;
> > +
> > + func = dev_to_sdio_func(dev);
> > + host = mmc_priv(func->card->host);
> > +
> > + addr = (host->slotno << 16) | func->num;
> > +
> > + *handle = acpi_get_child(DEVICE_ACPI_HANDLE(dev), addr);
> > + if (!*handle)
> > + return -ENODEV;
> > +
> > + return 0;
> > +}
> > +
> > +static struct acpi_bus_type acpi_sdio_bus = {
> > + .bus = &sdio_bus_type,
> > + .find_device = acpi_sdio_find_device,
> > +};
> > +
> > +int sdio_acpi_register(void)
>
> I'd call it sdio_acpi_register_bus().
OK, will update this in v2.
>
> > +{
> > + return register_acpi_bus_type(&acpi_sdio_bus);
> > +}
> > diff --git a/drivers/mmc/core/sdio_bus.c b/drivers/mmc/core/sdio_bus.c
> > index 6bf6879..aaec9e2 100644
> > --- a/drivers/mmc/core/sdio_bus.c
> > +++ b/drivers/mmc/core/sdio_bus.c
> > @@ -23,6 +23,7 @@
> >
> > #include "sdio_cis.h"
> > #include "sdio_bus.h"
> > +#include "sdio_acpi.h"
> >
> > /* show configuration fields */
> > #define sdio_config_attr(field, format_string) \
> > @@ -209,7 +210,7 @@ static const struct dev_pm_ops sdio_bus_pm_ops = {
> >
> > #endif /* !CONFIG_PM */
> >
> > -static struct bus_type sdio_bus_type = {
> > +struct bus_type sdio_bus_type = {
> > .name = "sdio",
> > .dev_attrs = sdio_dev_attrs,
> > .match = sdio_bus_match,
> > @@ -221,7 +222,16 @@ static struct bus_type sdio_bus_type = {
> >
> > int sdio_register_bus(void)
> > {
> > - return bus_register(&sdio_bus_type);
> > + int ret;
> > +
> > + ret = bus_register(&sdio_bus_type);
> > + if (ret)
> > + goto out;
> > +
> > + ret = sdio_acpi_register();
>
> What happens if this fails?
Oh, yes, it shouldn't affect the sdio_register_bus function. So I'll not
check its return value in v2.
Thanks,
Aaron
>
> > +
> > +out:
> > + return ret;
> > }
> >
> > void sdio_unregister_bus(void)
> > diff --git a/drivers/mmc/core/sdio_bus.h b/drivers/mmc/core/sdio_bus.h
> > index 567a768..91c0e93 100644
> > --- a/drivers/mmc/core/sdio_bus.h
> > +++ b/drivers/mmc/core/sdio_bus.h
> > @@ -18,5 +18,7 @@ void sdio_remove_func(struct sdio_func *func);
> > int sdio_register_bus(void);
> > void sdio_unregister_bus(void);
> >
> > +extern struct bus_type sdio_bus_type;
> > +
> > #endif
>
> Thanks,
> Rafael
>
>
> --
> I speak only for myself.
> Rafael J. Wysocki, Intel Open Source Technology Center.
next prev parent reply other threads:[~2012-10-20 7:12 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-12 3:12 [RFC PATCH 0/4] Enable setting of sdio device power state with ACPI Aaron Lu
2012-10-12 3:12 ` [RFC PATCH 1/4] sdhci: add slot number into sdhci_host structure Aaron Lu
2012-10-12 3:12 ` [RFC PATCH 2/4] mmc: sdio: bind sdio device with acpi device Aaron Lu
2012-10-18 23:25 ` Rafael J. Wysocki
2012-10-20 7:12 ` Aaron Lu [this message]
2012-10-12 3:12 ` [RFC PATCH 3/4] sdio: introduce sdio_platform_pm_ops Aaron Lu
2012-10-18 23:30 ` Rafael J. Wysocki
2012-10-12 3:12 ` [RFC PATCH 4/4] sdio: pm: set device's power state after driver runtime suspended it Aaron Lu
2012-10-18 23:39 ` Rafael J. Wysocki
2012-10-19 18:08 ` Rafael J. Wysocki
2012-10-20 7:15 ` Aaron Lu
2012-10-21 19:57 ` Rafael J. Wysocki
2012-10-22 0:49 ` Aaron Lu
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=20121020071244.GA4798@localhost.localdomain \
--to=aaron.lu@intel.com \
--cc=aaron.lwe@gmail.com \
--cc=cjb@laptop.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rjw@sisk.pl \
/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;
as well as URLs for NNTP newsgroup(s).