Doug / smarc-fsl-linux-kernel

07 Dec, 2012

2 commits

  • 4c42d6cc2   mmc: Remove redundant null check before kfree in sdio_bus.c ... Browse Code »

    kfree on a null pointer is a no-op.

    Signed-off-by: Sachin Kamat
    Signed-off-by: Chris Ball

    Sachin Kamat
     
  • b0afd8f68   mmc: sdio: Add empty bus-level suspend/resume callbacks ... Browse Code »

    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 (e841a7c mmc: sdio:
    Use empty system suspend/resume callbacks at the bus level), but then it
    was reverted inadvertently by commit (d8e2ac3 mmc: sdio: Fix PM_SLEEP
    related build warnings) that attempted to fix build warnings introduced
    by commit e841a7c.

    Reported-by: NeilBrown
    Signed-off-by: Rafael J. Wysocki
    Signed-off-by: Chris Ball

    Rafael J. Wysocki
     

19 Sep, 2012

1 commit

  • d8e2ac330   mmc: sdio: Fix PM_SLEEP related build warnings ... Browse Code »

    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: Thierry Reding
    Acked-by: Rafael J. Wysocki
    Signed-off-by: Chris Ball

    Thierry Reding
     

06 Apr, 2012

1 commit

  • e841a7c69   mmc: sdio: Use empty system suspend/resume callbacks at the bus level ... Browse Code »

    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: Neil Brown
    Signed-off-by: Rafael J. Wysocki
    [stable: please apply to 3.3-stable only]
    Cc:
    Signed-off-by: Chris Ball

    Rafael J. Wysocki
     

01 Nov, 2011

1 commit

27 Oct, 2011

1 commit

21 Jul, 2011

1 commit

  • ecc024419   mmc: fix runtime PM with -ENOSYS suspend case ... Browse Code »

    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: Daniel Drake
    Signed-off-by: Chris Ball

    Ohad Ben-Cohen
     

26 Jun, 2011

1 commit

  • 297c7f2f1   mmc: sdio: fix runtime PM path during driver removal ... Browse Code »

    After commit e1866b3 "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: Daniel Drake
    Signed-off-by: Ohad Ben-Cohen
    Signed-off-by: Chris Ball

    Ohad Ben-Cohen
     

09 Jan, 2011

1 commit

  • e594573d7   mmc: sdio: don't power up cards on system suspend ... Browse Code »

    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: Ohad Ben-Cohen
    Reviewed-by: Chris Ball
    Signed-off-by: Chris Ball

    Ohad Ben-Cohen
     

20 Nov, 2010

1 commit

  • ed919b012   mmc: sdio: fix runtime PM anomalies by introducing MMC_CAP_POWER_OFF_CARD ... Browse Code »

    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: Daniel Drake
    Reported-and-tested-by: Arnd Hannemann
    Signed-off-by: Ohad Ben-Cohen
    Signed-off-by: Chris Ball

    Ohad Ben-Cohen
     

23 Oct, 2010

3 commits

  • ed2a97859   mmc: sdio: support suspend/resume while runtime suspended ... Browse Code »

    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: Ohad Ben-Cohen
    Tested-by: Luciano Coelho
    Signed-off-by: Chris Ball

    Ohad Ben-Cohen
     
  • 40bba0c1c   mmc: sdio: enable runtime PM for SDIO functions ... Browse Code »

    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: Ohad Ben-Cohen
    Tested-by: Luciano Coelho
    Signed-off-by: Chris Ball

    Ohad Ben-Cohen
     
  • 80fd933c4   mmc: sdio: use the generic runtime PM handlers ... Browse Code »

    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: Ohad Ben-Cohen
    Tested-by: Luciano Coelho
    Signed-off-by: Chris Ball

    Ohad Ben-Cohen
     

30 Mar, 2010

1 commit

  • 5a0e3ad6a   include cleanup: Update gfp.h and slab.h includes to prepare for breaking implic… ... Browse Code »

    …it 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: Tejun Heo <tj@kernel.org>
    Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

    Tejun Heo
     

18 Dec, 2009

1 commit

  • 3d10a1ba0   sdio: fix reference counting in sdio_remove_func() ... Browse Code »

    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: Daniel Drake
    Reviewed-by: Matt Fleming
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Daniel Drake
     

23 Sep, 2009

1 commit

09 Nov, 2008

1 commit

14 Oct, 2007

1 commit

24 Sep, 2007

12 commits