summaryrefslogtreecommitdiffstats
path: root/include/linux/mmc
diff options
context:
space:
mode:
authorNicolas Pitre <nico@fluxnic.net>2009-09-22 16:45:29 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2009-09-23 07:39:38 -0700
commit95cdfb72b9bc568803f395c266152c71b034b461 (patch)
treeba4d10ee9eb595398d14cf44b433b82ea7802996 /include/linux/mmc
parent17d33e14f7ffc05f8c81e4a3bdb9a8003a05dcce (diff)
downloadblackbird-op-linux-95cdfb72b9bc568803f395c266152c71b034b461.tar.gz
blackbird-op-linux-95cdfb72b9bc568803f395c266152c71b034b461.zip
mmc: propagate error codes back from bus drivers' suspend/resume methods
Especially for SDIO drivers which may have special conditions/errors to report, it is a good thing to relay the returned error code back to upper layers. This also allows for the rationalization of the resume path where code to "remove" a no-longer-existing or replaced card was duplicated into the MMC, SD and SDIO bus drivers. In the SDIO case, if a function suspend method returns an error, then all previously suspended functions are resumed and the error returned. An exception is made for -ENOSYS which the core interprets as "we don't support suspend so just kick the card out for suspend and return success". When resuming SDIO cards, the core code only validates the manufacturer and product IDs to make sure the same kind of card is still present before invoking functions resume methods. It's the function driver's responsibility to perform further tests to confirm that the actual same card is present (same MAC address, etc.) and return an error otherwise. Signed-off-by: Nicolas Pitre <nico@marvell.com> Cc: <linux-mmc@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'include/linux/mmc')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud