diff options
author | Nishanth Aravamudan <nacc@linux.vnet.ibm.com> | 2013-03-07 16:33:03 +0400 |
---|---|---|
committer | Michael Ellerman <michael@ellerman.id.au> | 2013-04-18 07:04:00 +0400 |
commit | 61435690a9c781b4c9e617aa86bd20c146c9a998 (patch) | |
tree | 40325e72e48f108aabb05c24fafc9e76e3145b98 /arch/powerpc/kernel/ptrace.c | |
parent | fb1b55d654a7038ca6337fbf55839a308c9bc1a7 (diff) | |
download | linux-61435690a9c781b4c9e617aa86bd20c146c9a998.tar.xz |
powerpc/pseries: close DDW race between functions of adapter
Given a PCI device with multiple functions in a DDW capable slot, the
following situation can be encountered: When the first function sets a
64-bit DMA mask, enable_ddw() will be called and we can fail to properly
configure DDW (the most common reason being the new DMA window's size is
not large enough to map all of an LPAR's memory). With the recent
changes to DDW, we remove the base window in order to determine if the
new window is of sufficient size to cover an LPAR's memory. We correctly
replace the base window if we find that not to be the case. However,
once we go through and re-configured 32-bit DMA via the IOMMU, the next
function of the adapter will go through the same process. And since DDW
is a characteristic of the slot itself, we are most likely going to fail
again. But to determine we are going to fail the second slot, we again
remove the base window -- but that is now in-use by the first
function/driver, which might be issuing I/O already.
To close this window, keep a list of all the failed struct device_nodes
that have failed to configure DDW. If the current device_node is in that
list, just fail out immediately and fall back to 32-bit DMA without
doing any DDW manipulation.
Signed-off-by: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Diffstat (limited to 'arch/powerpc/kernel/ptrace.c')
0 files changed, 0 insertions, 0 deletions