This adds SDIO devicetree subnode parsing to the mmc core. While
SDIO devices are runtime probable they sometimes need nonprobable
additional information on embedded systems, like an additional gpio
interrupt or a clock. This patch makes it possible to supply this
information from the devicetree. SDIO drivers will find a pointer
to the devicenode in their devices of_node pointer.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
[hdegoede@redhat.com: Misc. cleanups]
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Presumably ->slotno is normally fairly small and the shift doesn't wrap
but static checkers will complain about it.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The macro is only used by the mmc core, so let's move it in there.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The commit 46420dd7 (PM / Domains: Add APIs to attach/detach a PM
domain for a device) started using errno values in pm.h header file.
It also failed to include the header for these, thus it caused
compiler errors.

Instead of including the errno header to pm.h, let's move the functions
to pm_domain.h, since it's a better match.

Fixes: 46420dd7 (PM / Domains: Add APIs to attach/detach a PM domain for a device)
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Acked-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Acked-by: NWolfram Sang <wsa@the-dreams.de>
Acked-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Use the much more common pr_warn instead of pr_warning.

Other miscellanea:

o Coalesce formats
o Realign arguments
o Remove extra spaces when coalescing formats
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Previously only the ACPI PM domain was supported by the sdio bus.

Let's convert to the common attach/detach functions for PM domains,
which currently means we are extending the support to include the
generic PM domain as well.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Reviewed-by: NKevin Hilman <khilman@linaro.org>
Reviewed-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The sdio func device is added to the driver model after the card
device.

This means the sdio func device will be suspend before the card device
and thus resumed after. The consequence are the mmc core don't
explicity need to protect itself from receiving sdio requests in
suspended state. Instead that can be handled from the sdio bus, which
is thus invokes the PM callbacks instead of old dummy function.

In the case were the sdio func driver don't implement the PM callbacks
the mmc core will in the early phase of system suspend, remove the
card from the driver model and thus power off it.

Cc: Aaron Lu <aaron.lu@intel.com>
Cc: NeilBrown <neilb@suse.de>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Reviewed-by: NAaron Lu <aaron.lu@intel.com>
Tested-by: Nxiaoming wang <xiaoming.wang@intel.com>
Tested-by: NChuanxiao Dong <chuanxiao.dong@intel.com>
Signed-off-by: NChris Ball <chris@printf.net>

Modify acpi_preset_companion() to take a struct acpi_device pointer
instead of an ACPI handle as its second argument and redefine it as
a static inline wrapper around ACPI_COMPANION_SET() passing the
return value of acpi_find_child_device() directly as the second
argument to it.  Update its users to pass struct acpi_device
pointers instead of ACPI handles to it.

This allows some unnecessary acpi_bus_get_device() calls to be
avoided.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: NAaron Lu <aaron.lu@intel.com>
Tested-by: Aaron Lu <aaron.lu@intel.com> # for ATA binding

Modify struct acpi_dev_node to contain a pointer to struct acpi_device
associated with the given device object (that is, its ACPI companion
device) instead of an ACPI handle corresponding to it.  Introduce two
new macros for manipulating that pointer in a CONFIG_ACPI-safe way,
ACPI_COMPANION() and ACPI_COMPANION_SET(), and rework the
ACPI_HANDLE() macro to take the above changes into account.
Drop the ACPI_HANDLE_SET() macro entirely and rework its users to
use ACPI_COMPANION_SET() instead.  For some of them who used to
pass the result of acpi_get_child() directly to ACPI_HANDLE_SET()
introduce a helper routine acpi_preset_companion() doing an
equivalent thing.

The main motivation for doing this is that there are things
represented by struct acpi_device objects that don't have valid
ACPI handles (so called fixed ACPI hardware features, such as
power and sleep buttons) and we would like to create platform
device objects for them and "glue" them to their ACPI companions
in the usual way (which currently is impossible due to the
lack of valid ACPI handles).  However, there are more reasons
why it may be useful.

First, struct acpi_device pointers allow of much better type checking
than void pointers which are ACPI handles, so it should be more
difficult to write buggy code using modified struct acpi_dev_node
and the new macros.  Second, the change should help to reduce (over
time) the number of places in which the result of ACPI_HANDLE() is
passed to acpi_bus_get_device() in order to obtain a pointer to the
struct acpi_device associated with the given "physical" device,
because now that pointer is returned by ACPI_COMPANION() directly.
Finally, the change should make it easier to write generic code that
will build both for CONFIG_ACPI set and unset without adding explicit
compiler directives to it.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> # on Haswell
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Aaron Lu <aaron.lu@intel.com> # for ATA and SDIO part

The dev_attrs field of struct bus_type is going away soon, dev_groups
should be used instead.  This converts the MMC bus code to use the
correct field.

Cc: Chris Ball <cjb@laptop.org>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Konstantin Dorfman <kdorfman@codeaurora.org>
Cc: Seungwon Jeon <tgih.jun@samsung.com>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The "runtime idle" helper routine, rpm_idle(), currently ignores
return values from .runtime_idle() callbacks executed by it.
However, it turns out that many subsystems use
pm_generic_runtime_idle() which checks the return value of the
driver's callback and executes pm_runtime_suspend() for the device
unless that value is not 0.  If that logic is moved to rpm_idle()
instead, pm_generic_runtime_idle() can be dropped and its users
will not need any .runtime_idle() callbacks any more.

Moreover, the PCI, SCSI, and SATA subsystems' .runtime_idle()
routines, pci_pm_runtime_idle(), scsi_runtime_idle(), and
ata_port_runtime_idle(), respectively, as well as a few drivers'
ones may be simplified if rpm_idle() calls rpm_suspend() after 0 has
been returned by the .runtime_idle() callback executed by it.

To reduce overall code bloat, make the changes described above.
Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: NKevin Hilman <khilman@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NKevin Hilman <khilman@linaro.org>
Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>

Even in failed case of pm_runtime_get_sync, the usage_count
is incremented. In order to keep the usage_count with correct
value and runtime power management to behave correctly, call
pm_runtime_put_noidle in such case.
Signed-off-by: NLiu Chuansheng <chuansheng.liu@intel.com>
Signed-off-by: NLi Fei <fei.li@intel.com>
Acked-by: NOhad Ben-Cohen <ohad@wizery.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

ACPI spec 5 defined the _ADR encoding for sdio bus as:
High word - slot number (0 based)
Low word  - function number

This patch adds support for binding sdio function device with acpi node,
and if successful, involve acpi into its power management.
Signed-off-by: NAaron Lu <aaron.lu@intel.com>
Reviewed-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

kfree on a null pointer is a no-op.
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

Suspend methods provided by SDIO drivers are not supposed to be called by
the PM core.  Instead, when the SDIO core gets to suspend a device's
ancestor, it calls the device driver's suspend routine.  However, the PM
core executes suspend callback routines directly for device drivers whose
bus types don't provide suspend callbacks.  In consequece, because the
SDIO bus type doesn't provide a suspend callback, the SDIO drivers'
suspend routines will be executed by the PM core (which shouldn't
happen).

To prevent this from happening, add empty system suspend/resume callbacks
for the SDIO bus type.

An analogous change had been made already by commit (e841a7c6 mmc: sdio:
Use empty system suspend/resume callbacks at the bus level), but then it
was reverted inadvertently by commit (d8e2ac33 mmc: sdio: Fix PM_SLEEP
related build warnings) that attempted to fix build warnings introduced
by commit e841a7c6.
Reported-by: NNeilBrown <neilb@suse.de>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Power management callbacks defined by SIMPLE_DEV_PM_OPS are only used if
the PM_SLEEP Kconfig symbol has been defined. If not, the compiler will
complain about them being unused. However, since the callback for this
driver doesn't do anything it can just as well be dropped.
Signed-off-by: NThierry Reding <thierry.reding@avionic-design.de>
Acked-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NChris Ball <cjb@laptop.org>

Neil Brown reports that commit 35cd133c

   PM: Run the driver callback directly if the subsystem one is not there

breaks suspend for his libertas wifi, because SDIO has a protocol
where the suspend method can return -ENOSYS and this means "There is
no point in suspending, just turn me off".  Moreover, the suspend
methods provided by SDIO drivers are not supposed to be called by
the PM core or bus-level suspend routines (which aren't presend for
SDIO).  Instead, when the SDIO core gets to suspend the device's
ancestor, it calls the device driver's suspend function, catches the
ENOSYS, and turns the device off.

The commit above breaks the SDIO core's assumption that the device
drivers' callbacks won't be executed if it doesn't provide any
bus-level callbacks.  If fact, however, this assumption has never
been really satisfied, because device class or device type suspend
might very well use the driver's callback even without that commit.

The simplest way to address this problem is to make the SDIO core
tell the PM core to ignore driver callbacks, for example by providing
no-operation suspend/resume callbacks at the bus level for it,
which is implemented by this change.
Reported-and-tested-by: NNeil Brown <neilb@suse.de>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
[stable: please apply to 3.3-stable only]
Cc: <stable@vger.kernel.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

These two basic defines were everywhere, simply because module.h
was also everywhere.   But we are cleaning up the latter.  So make
the exporters actually call out their need for the include.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>

All the files using printk function for displaying kernel messages
in the mmc driver have been replaced with corresponding macro.
Signed-off-by: NGirish K S <girish.shivananjappa@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

In the case where a driver returns -ENOSYS from its suspend handler
to indicate that the device should be powered down over suspend, the
remove routine of the driver was not being called, leading to lots of
confusion during resume.

The problem is that runtime PM is disabled during this process,
and when we reach mmc_sdio_remove, calling the runtime PM functions here
(validly) return errors, and this was causing us to skip the remove
function.

Fix this by ignoring the error value of pm_runtime_get_sync(), which
can return valid errors. This also matches the behaviour of
pci_device_remove().
Signed-off-by: NDaniel Drake <dsd@laptop.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

After commit e1866b33 "PM / Runtime: Rework runtime PM handling
during driver removal" was introduced, the driver core stopped
incrementing the runtime PM usage counter of the device during
the invocation of the ->remove() callback.

This indirectly broke SDIO's runtime PM path during driver removal,
because no one calls _put_sync() anymore after ->remove() completes.

This means that the power of runtime-PM-managed SDIO cards is kept
high after their driver is removed (even if it was powered down
beforehand).

Fix that by directly calling _put_sync() when the last usage
counter is downref'ed by the SDIO bus.
Reported-and-tested-by: NDaniel Drake <dsd@laptop.org>
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Initial SDIO runtime PM implementation took a conservative approach
of powering up cards (and fully reinitializing them) on system suspend,
just before the suspend handlers of the relevant drivers were executed.

To avoid redundant power and reinitialization cycles, this patch removes
this behavior: if a card is already powered off when system suspend kicks
in, it is left at that state.

If a card is active when a system sleep starts, everything is
straightforward and works exactly like before. But if the card was
already suspended before the sleep began, then when the MMC core powers
it back up on resume, its run-time PM status has to be updated to reflect
the actual post-system sleep status.

The technique to do that is borrowed from the I2C runtime PM
implementation (for more info see Documentation/power/runtime_pm.txt).
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
Reviewed-by: NChris Ball <cjb@laptop.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

Some board/card/host configurations are not capable of powering off the
card after boot.

To support such configurations, and to allow smoother transition to
runtime PM behavior, MMC_CAP_POWER_OFF_CARD is added, so hosts need to
explicitly indicate whether it's OK to power off their cards after boot.

SDIO core will enable runtime PM for a card only if that cap is set.
As a result, the card will be powered down after boot, and will only
be powered up again when a driver is loaded (and then it's up to the
driver to decide whether power will be kept or not).

This will prevent sdio_bus_probe() failures with setups that do not
support powering off the card.
Reported-and-tested-by: NDaniel Drake <dsd@laptop.org>
Reported-and-tested-by: NArnd Hannemann <arnd@arndnet.de>
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Bring SDIO devices back to full power before their suspend
handler is invoked.

Doing so ensures that SDIO suspend/resume semantics are
maintained (drivers still get to decide whether their
card should be removed or kept during system suspend,
and at what power state), and that SDIO suspend/resume
execution paths are unchanged.

This is achieved by resuming a runtime-suspended SDIO device
in its ->prepare() PM callback (similary to the PCI subsystem).

Since the PM core always increments the run-time usage
counter before calling the ->prepare() callback and decrements
it after calling the ->complete() callback, it is guaranteed
that when the system will come out of suspend, our device's
power state will reflect its runtime PM usage counter.
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
Tested-by: NLuciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Enable runtime PM for SDIO functions.

SDIO functions are initialized with a disabled runtime PM state,
and are set active (and their usage count is incremented)
only before potential drivers are probed.

SDIO function drivers that support runtime PM should call
pm_runtime_put_noidle() in their probe routine, and
pm_runtime_get_noresume() in their remove routine (very
similarly to PCI drivers).

In case a matching driver does not support runtime PM, power will
always be kept high (since the usage count is positive).
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
Tested-by: NLuciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Assign the generic runtime PM handlers for SDIO.

These handlers invoke the relevant SDIO function drivers'
handlers, if exist, otherwise they just return success
(so SDIO drivers don't have to define any runtime PM handlers
unless they need to).

Runtime PM is still disabled by default, so this patch alone
has no immediate effect.
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
Tested-by: NLuciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h

percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files.  percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.

percpu.h -> slab.h dependency is about to be removed.  Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability.  As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.

  http://userweb.kernel.org/~tj/misc/slabh-sweep.py

The script does the followings.

* Scan files for gfp and slab usages and update includes such that
  only the necessary includes are there.  ie. if only gfp is used,
  gfp.h, if slab is used, slab.h.

* When the script inserts a new include, it looks at the include
  blocks and try to put the new include such that its order conforms
  to its surrounding.  It's put in the include block which contains
  core kernel includes, in the same order that the rest are ordered -
  alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
  doesn't seem to be any matching order.

* If the script can't find a place to put a new include (mostly
  because the file doesn't have fitting include block), it prints out
  an error message indicating which .h file needs to be added to the
  file.

The conversion was done in the following steps.

1. The initial automatic conversion of all .c files updated slightly
   over 4000 files, deleting around 700 includes and adding ~480 gfp.h
   and ~3000 slab.h inclusions.  The script emitted errors for ~400
   files.

2. Each error was manually checked.  Some didn't need the inclusion,
   some needed manual addition while adding it to implementation .h or
   embedding .c file was more appropriate for others.  This step added
   inclusions to around 150 files.

3. The script was run again and the output was compared to the edits
   from #2 to make sure no file was left behind.

4. Several build tests were done and a couple of problems were fixed.
   e.g. lib/decompress_*.c used malloc/free() wrappers around slab
   APIs requiring slab.h to be added manually.

5. The script was run on all .h files but without automatically
   editing them as sprinkling gfp.h and slab.h inclusions around .h
   files could easily lead to inclusion dependency hell.  Most gfp.h
   inclusion directives were ignored as stuff from gfp.h was usually
   wildly available and often used in preprocessor macros.  Each
   slab.h inclusion directive was examined and added manually as
   necessary.

6. percpu.h was updated not to include slab.h.

7. Build test were done on the following configurations and failures
   were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
   distributed build env didn't work with gcov compiles) and a few
   more options had to be turned off depending on archs to make things
   build (like ipr on powerpc/64 which failed due to missing writeq).

   * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
   * powerpc and powerpc64 SMP allmodconfig
   * sparc and sparc64 SMP allmodconfig
   * ia64 SMP allmodconfig
   * s390 SMP allmodconfig
   * alpha SMP allmodconfig
   * um on x86_64 SMP allmodconfig

8. percpu.h modifications were reverted so that it could be applied as
   a separate patch and serve as bisection point.

Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: NTejun Heo <tj@kernel.org>
Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

sdio_remove_func() needs to be more careful about reference counting.  It
can be called in error paths where sdio_add_func() has never been called
e.g.  mmc_attach_sdio error path --> mmc_sdio_remove --> sdio_remove_func
Signed-off-by: NDaniel Drake <dsd@laptop.org>
Reviewed-by: NMatt Fleming <matt@console-pimps.org>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Especially with the PM framework, those are quite handy to have in driver
code too.
Signed-off-by: NNicolas Pitre <nico@marvell.com>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-Off-By: NKay Sievers <kay.sievers@vrfy.org>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Store vendor strings found in CISTPL_VERS_1 so that function drivers
can access them.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Signed-off-by: NMariusz Kozlowski <m.kozlowski@tuxland.pl>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Before a driver is probed, set the function's block size to the default so the
driver is sure the block size is something sensible and it needn't explicitly
set it.

The default block size is the largest that's supported by both the card and
the host, with a maximum of 512 to ensure aribitrarily sized transfer use the
optimal (least) number of commands.

See http://lkml.org/lkml/2007/8/7/150 for reasons for the block size choice.
Signed-off-by: NDavid Vrabel <david.vrabel@csr.com>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

On Wed, Jul 25, 2007 at 04:03:04AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.22-rc6-mm1:
>...
>  git-mmc.patch
>...
>  git trees
>...

sdio_dev_attrs[] can become static.
Signed-off-by: NAdrian Bunk <bunk@stusta.de>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Signed-off-by: NNicolas Pitre <npitre@mvista.com>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>