aboutsummaryrefslogtreecommitdiff
path: root/fs/bad_inode.c
diff options
context:
space:
mode:
authorRussell King <rmk+kernel@arm.linux.org.uk>2016-01-26 13:40:37 +0000
committerUlf Hansson <ulf.hansson@linaro.org>2016-02-29 11:03:22 +0100
commit94538e51d67da97e798d379d6bcf3d386d609bfb (patch)
tree5c78bf6836b36b206a89a23171566f92ea988dac /fs/bad_inode.c
parentf48f039cd2d33d01ba15e92018dc18a0ea68c764 (diff)
mmc: sdhci: clean up host cookie handling
Commit d31911b9374a ("mmc: sdhci: fix dma memory leak in sdhci_pre_req()") added a complicated method to manage the DMA map state for the data transfer, but this complexity is not required. There are three states: * Unmapped * Mapped by sdhci_pre_req() * Mapped by sdhci_prepare_data() sdhci_prepare_data() needs to know when the data buffers have been successfully mapped by sdhci_pre_req(), and if so, there is no need to map them a second time. When we come to tear down the mapping, we want to know whether sdhci_post_req() will be called (which is determined by sdhci_pre_req() having been previously called) so that we can postpone the unmap operation. Hence, it makes sense to simply record when the successful DMA map happened (via COOKIE_PRE_MAPPED vs COOKIE_MAPPED) rather than having the complex mechanics involving COOKIE_MAPPED vs COOKIE_GIVEN. If a mapping is created by sdhci_prepare_data(), we must tear it down ourselves, without waiting for sdhci_post_req() (hence, the new COOKIE_MAPPED case). If the mapping is created by sdhci_pre_req() then sdhci_post_req() is responsible for tearing the mapping down. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Diffstat (limited to 'fs/bad_inode.c')
0 files changed, 0 insertions, 0 deletions