summaryrefslogtreecommitdiff
path: root/drivers/leds/leds-tca6507.c
diff options
context:
space:
mode:
authorRafael J. Wysocki <rjw@sisk.pl>2012-04-01 08:34:58 +0400
committerChris Ball <cjb@laptop.org>2012-04-06 04:32:26 +0400
commite841a7c69b708eeaf784fd517978006e8319b03a (patch)
treec8493c10b1cdd91c109cf2d95e7275d5f88f2a6c /drivers/leds/leds-tca6507.c
parent6500c8ed957ac7b1ff37045ba6a2ad39ab2a8dbc (diff)
downloadlinux-e841a7c69b708eeaf784fd517978006e8319b03a.tar.xz
mmc: sdio: Use empty system suspend/resume callbacks at the bus level
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 <neilb@suse.de> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> [stable: please apply to 3.3-stable only] Cc: <stable@vger.kernel.org> Signed-off-by: Chris Ball <cjb@laptop.org>
Diffstat (limited to 'drivers/leds/leds-tca6507.c')
0 files changed, 0 insertions, 0 deletions