swiotlb: don't modify orig_addr in swiotlb_tbl_sync_single
swiotlb_tbl_map_single currently nevers sets a tlb_addr that is not
aligned to the tlb bucket size. But we're going to add such a case
soon, for which this adjustment would be bogus.
Signed-off-by: Christoph Hellwig <hch@xxxxxx>
Acked-by: Jianxiong Gao <jxgao@xxxxxxxxxx>
Tested-by: Jianxiong Gao <jxgao@xxxxxxxxxx>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
driver core: add a min_align_mask field to struct device_dma_parameters
Some devices rely on the address offset in a page to function
correctly (NVMe driver as an example). These devices may use
a different page size than the Linux kernel. The address offset
has to be preserved upon mapping, and in order to do so, we
need to record the page_offset_mask first.
Signed-off-by: Jianxiong Gao <jxgao@xxxxxxxxxx>
Signed-off-by: Christoph Hellwig <hch@xxxxxx>
Acked-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
When a AP queue is switched to soft offline, all pending
requests are purged out of the pending requests list and
'received' by the upper layer like zcrypt device drivers.
This is also done for requests which are already enqueued
into the firmware queue. A request in a firmware queue
may eventually produce an response message, but there is
no waiting process any more. However, the response was
counted with the queue_counter and as this counter was
reset to 0 with the offline switch, the pending response
caused the queue_counter to get negative. The next request
increased this counter to 0 (instead of 1) which caused
the ap code to assume there is nothing to receive and so
the response for this valid request was never tried to
fetch from the firmware queue.
This all caused a queue to not work properly after a
switch offline/online and in the end processes to hang
forever when trying to send a crypto request after an
queue offline/online switch cicle.
Fixed by a) making sure the counter does not drop below 0
and b) on a successful enqueue of a message has at least
a value of 1.
Additionally a warning is emitted, when a reply can't get
assigned to a waiting process. This may be normal operation
(process had timeout or has been killed) but may give a
hint that something unexpected happened (like this odd
behavior described above).
Signed-off-by: Harald Freudenberger <email address hidden>
Cc: <email address hidden>
Signed-off-by: Vasily Gorbik <email address hidden>
(cherry picked from commit e73a99f3287a740a07d6618e9470f4d6cb217da8)
Signed-off-by: Frank Heimes <email address hidden>
Acked-by: Krzysztof Kozlowski <email address hidden>
Acked-by: Tim Gardner <email address hidden>
Signed-off-by: Kleber Sacilotto de Souza <email address hidden>
