--- /dev/null
+From 9e02977bfad006af328add9434c8bffa40e053bb Mon Sep 17 00:00:00 2001
+From: Chao Gao <chao.gao@intel.com>
+Date: Wed, 13 Apr 2022 08:32:22 +0200
+Subject: dma-direct: avoid redundant memory sync for swiotlb
+
+From: Chao Gao <chao.gao@intel.com>
+
+commit 9e02977bfad006af328add9434c8bffa40e053bb upstream.
+
+When we looked into FIO performance with swiotlb enabled in VM, we found
+swiotlb_bounce() is always called one more time than expected for each DMA
+read request.
+
+It turns out that the bounce buffer is copied to original DMA buffer twice
+after the completion of a DMA request (one is done by in
+dma_direct_sync_single_for_cpu(), the other by swiotlb_tbl_unmap_single()).
+But the content in bounce buffer actually doesn't change between the two
+rounds of copy. So, one round of copy is redundant.
+
+Pass DMA_ATTR_SKIP_CPU_SYNC flag to swiotlb_tbl_unmap_single() to
+skip the memory copy in it.
+
+This fix increases FIO 64KB sequential read throughput in a guest with
+swiotlb=force by 5.6%.
+
+Fixes: 55897af63091 ("dma-direct: merge swiotlb_dma_ops into the dma_direct code")
+Reported-by: Wang Zhaoyang1 <zhaoyang1.wang@intel.com>
+Reported-by: Gao Liang <liang.gao@intel.com>
+Signed-off-by: Chao Gao <chao.gao@intel.com>
+Reviewed-by: Kevin Tian <kevin.tian@intel.com>
+Signed-off-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/dma/direct.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/kernel/dma/direct.c
++++ b/kernel/dma/direct.c
+@@ -306,7 +306,8 @@ void dma_direct_unmap_page(struct device
+ dma_direct_sync_single_for_cpu(dev, addr, size, dir);
+
+ if (unlikely(is_swiotlb_buffer(phys)))
+- swiotlb_tbl_unmap_single(dev, phys, size, size, dir, attrs);
++ swiotlb_tbl_unmap_single(dev, phys, size, size, dir,
++ attrs | DMA_ATTR_SKIP_CPU_SYNC);
+ }
+ EXPORT_SYMBOL(dma_direct_unmap_page);
+
--- /dev/null
+From bd8963e602c77adc76dbbbfc3417c3cf14fed76b Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Martin=20Povi=C5=A1er?= <povik+lin@cutebit.org>
+Date: Tue, 29 Mar 2022 20:38:17 +0200
+Subject: i2c: pasemi: Wait for write xfers to finish
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Martin Povišer <povik+lin@cutebit.org>
+
+commit bd8963e602c77adc76dbbbfc3417c3cf14fed76b upstream.
+
+Wait for completion of write transfers before returning from the driver.
+At first sight it may seem advantageous to leave write transfers queued
+for the controller to carry out on its own time, but there's a couple of
+issues with it:
+
+ * Driver doesn't check for FIFO space.
+
+ * The queued writes can complete while the driver is in its I2C read
+ transfer path which means it will get confused by the raising of
+ XEN (the 'transaction ended' signal). This can cause a spurious
+ ENODATA error due to premature reading of the MRXFIFO register.
+
+Adding the wait fixes some unreliability issues with the driver. There's
+some efficiency cost to it (especially with pasemi_smb_waitready doing
+its polling), but that will be alleviated once the driver receives
+interrupt support.
+
+Fixes: beb58aa39e6e ("i2c: PA Semi SMBus driver")
+Signed-off-by: Martin Povišer <povik+lin@cutebit.org>
+Reviewed-by: Sven Peter <sven@svenpeter.dev>
+Signed-off-by: Wolfram Sang <wsa@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/i2c/busses/i2c-pasemi.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/drivers/i2c/busses/i2c-pasemi.c
++++ b/drivers/i2c/busses/i2c-pasemi.c
+@@ -137,6 +137,12 @@ static int pasemi_i2c_xfer_msg(struct i2
+
+ TXFIFO_WR(smbus, msg->buf[msg->len-1] |
+ (stop ? MTXFIFO_STOP : 0));
++
++ if (stop) {
++ err = pasemi_smb_waitready(smbus);
++ if (err)
++ goto reset_out;
++ }
+ }
+
+ return 0;
tick-nohz-use-warn_on_once-to-prevent-console-saturation.patch
arm-davinci-da850-evm-avoid-null-pointer-dereference.patch
dm-integrity-fix-memory-corruption-when-tag_size-is-less-than-digest-size.patch
+smp-fix-offline-cpu-check-in-flush_smp_call_function_queue.patch
+i2c-pasemi-wait-for-write-xfers-to-finish.patch
+dma-direct-avoid-redundant-memory-sync-for-swiotlb.patch
--- /dev/null
+From 9e949a3886356fe9112c6f6f34a6e23d1d35407f Mon Sep 17 00:00:00 2001
+From: Nadav Amit <namit@vmware.com>
+Date: Sat, 19 Mar 2022 00:20:15 -0700
+Subject: smp: Fix offline cpu check in flush_smp_call_function_queue()
+
+From: Nadav Amit <namit@vmware.com>
+
+commit 9e949a3886356fe9112c6f6f34a6e23d1d35407f upstream.
+
+The check in flush_smp_call_function_queue() for callbacks that are sent
+to offline CPUs currently checks whether the queue is empty.
+
+However, flush_smp_call_function_queue() has just deleted all the
+callbacks from the queue and moved all the entries into a local list.
+This checks would only be positive if some callbacks were added in the
+short time after llist_del_all() was called. This does not seem to be
+the intention of this check.
+
+Change the check to look at the local list to which the entries were
+moved instead of the queue from which all the callbacks were just
+removed.
+
+Fixes: 8d056c48e4862 ("CPU hotplug, smp: flush any pending IPI callbacks before CPU offline")
+Signed-off-by: Nadav Amit <namit@vmware.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Link: https://lore.kernel.org/r/20220319072015.1495036-1-namit@vmware.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/smp.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/kernel/smp.c
++++ b/kernel/smp.c
+@@ -222,7 +222,7 @@ static void flush_smp_call_function_queu
+
+ /* There shouldn't be any pending callbacks on an offline CPU. */
+ if (unlikely(warn_cpu_offline && !cpu_online(smp_processor_id()) &&
+- !warned && !llist_empty(head))) {
++ !warned && entry != NULL)) {
+ warned = true;
+ WARN(1, "IPI on offline CPU %d\n", smp_processor_id());
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
