linux.git, branch v5.4.63

Linux 5.4.63

2020-09-05T09:22:51+00:00

Tested-by: Shuah Khan 
Tested-by: Guenter Roeck 
Signed-off-by: Greg Kroah-Hartman

scsi: target: tcmu: Optimize use of flush_dcache_page

2020-09-05T09:22:51+00:00

commit 3c58f737231e2c8cbf543a09d84d8c8e80e05e43 upstream.

(scatter|gather)_data_area() need to flush dcache after writing data to or
before reading data from a page in uio data area.  The two routines are
able to handle data transfer to/from such a page in fragments and flush the
cache after each fragment was copied by calling the wrapper
tcmu_flush_dcache_range().

That means:

1) flush_dcache_page() can be called multiple times for the same page.

2) Calling flush_dcache_page() indirectly using the wrapper does not make
   sense, because each call of the wrapper is for one single page only and
   the calling routine already has the correct page pointer.

Change (scatter|gather)_data_area() such that, instead of calling
tcmu_flush_dcache_range() before/after each memcpy, it now calls
flush_dcache_page() before unmapping a page (when writing is complete for
that page) or after mapping a page (when starting to read the page).

After this change only calls to tcmu_flush_dcache_range() for addresses in
vmalloc'ed command ring are left over.

The patch was tested on ARM with kernel 4.19.118 and 5.7.2

Link: https://lore.kernel.org/r/20200618131632.32748-2-bstroesser@ts.fujitsu.com
Tested-by: JiangYu 
Tested-by: Daniel Meyerholt 
Acked-by: Mike Christie 
Signed-off-by: Bodo Stroesser 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman

scsi: target: tcmu: Fix size in calls to tcmu_flush_dcache_range

2020-09-05T09:22:51+00:00

commit 8c4e0f212398cdd1eb4310a5981d06a723cdd24f upstream.

1) If remaining ring space before the end of the ring is smaller then the
   next cmd to write, tcmu writes a padding entry which fills the remaining
   space at the end of the ring.

   Then tcmu calls tcmu_flush_dcache_range() with the size of struct
   tcmu_cmd_entry as data length to flush.  If the space filled by the
   padding was smaller then tcmu_cmd_entry, tcmu_flush_dcache_range() is
   called for an address range reaching behind the end of the vmalloc'ed
   ring.

   tcmu_flush_dcache_range() in a loop calls
   flush_dcache_page(virt_to_page(start)); for every page being part of the
   range. On x86 the line is optimized out by the compiler, as
   flush_dcache_page() is empty on x86.

   But I assume the above can cause trouble on other architectures that
   really have a flush_dcache_page().  For paddings only the header part of
   an entry is relevant due to alignment rules the header always fits in
   the remaining space, if padding is needed.  So tcmu_flush_dcache_range()
   can safely be called with sizeof(entry->hdr) as the length here.

2) After it has written a command to cmd ring, tcmu calls
   tcmu_flush_dcache_range() using the size of a struct tcmu_cmd_entry as
   data length to flush.  But if a command needs many iovecs, the real size
   of the command may be bigger then tcmu_cmd_entry, so a part of the
   written command is not flushed then.

Link: https://lore.kernel.org/r/20200528193108.9085-1-bstroesser@ts.fujitsu.com
Acked-by: Mike Christie 
Signed-off-by: Bodo Stroesser 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman

sdhci: tegra: Remove SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK for Tegra186

2020-09-05T09:22:51+00:00

commit 391d89dba8c290859a3e29430d0b9e32c358bb0d upstream.

commit 4346b7c7941d ("mmc: tegra: Add Tegra186 support")

SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK is set for Tegra186 from the
beginning of its support in driver.

Tegra186 SDMMC hardware by default uses timeout clock (TMCLK) instead
of SDCLK and this quirk should not be set.

So, this patch remove this quirk for Tegra186.

Fixes: 4346b7c7941d ("mmc: tegra: Add Tegra186 support")
Cc: stable  # 5.4
Tested-by: Jon Hunter 
Reviewed-by: Jon Hunter 
Acked-by: Adrian Hunter 
Signed-off-by: Sowjanya Komatineni 
Link: https://lore.kernel.org/r/1598548861-32373-3-git-send-email-skomatineni@nvidia.com
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

sdhci: tegra: Remove SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK for Tegra210

2020-09-05T09:22:51+00:00

commit e33588adcaa925c18ee2ea253161fb0317fa2329 upstream.

commit b5a84ecf025a ("mmc: tegra: Add Tegra210 support")

SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK is set for Tegra210 from the
beginning of Tegra210 support in the driver.

Tegra210 SDMMC hardware by default uses timeout clock (TMCLK)
instead of SDCLK and this quirk should not be set.

So, this patch remove this quirk for Tegra210.

Fixes: b5a84ecf025a ("mmc: tegra: Add Tegra210 support")
Cc: stable  # 5.4
Tested-by: Jon Hunter 
Reviewed-by: Jon Hunter 
Acked-by: Adrian Hunter 
Signed-off-by: Sowjanya Komatineni 
Link: https://lore.kernel.org/r/1598548861-32373-2-git-send-email-skomatineni@nvidia.com
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

arm64: tegra: Add missing timeout clock to Tegra210 SDMMC

2020-09-05T09:22:51+00:00

commit 679f71fa0db2d777f39c7a5af7f7c0689fc713fa upstream.

commit 742af7e7a0a1 ("arm64: tegra: Add Tegra210 support")

Tegra210 uses separate SDMMC_LEGACY_TM clock for data timeout and
this clock is not enabled currently which is not recommended.

Tegra SDMMC advertises 12Mhz as timeout clock frequency in host
capability register.

So, this clock should be kept enabled by SDMMC driver.

Fixes: 742af7e7a0a1 ("arm64: tegra: Add Tegra210 support")
Cc: stable  # 5.4
Tested-by: Jon Hunter 
Reviewed-by: Jon Hunter 
Signed-off-by: Sowjanya Komatineni 
Link: https://lore.kernel.org/r/1598548861-32373-5-git-send-email-skomatineni@nvidia.com
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

arm64: tegra: Add missing timeout clock to Tegra186 SDMMC nodes

2020-09-05T09:22:50+00:00

commit baba217d2c4446b6eef309d81d8776cb5c68cb55 upstream.

commit 39cb62cb8973 ("arm64: tegra: Add Tegra186 support")

Tegra186 uses separate SDMMC_LEGACY_TM clock for data timeout and
this clock is not enabled currently which is not recommended.

Tegra186 SDMMC advertises 12Mhz as timeout clock frequency in host
capability register and uses it by default.

So, this clock should be kept enabled by the SDMMC driver.

Fixes: 39cb62cb8973 ("arm64: tegra: Add Tegra186 support")
Cc: stable  # 5.4
Tested-by: Jon Hunter 
Reviewed-by: Jon Hunter 
Signed-off-by: Sowjanya Komatineni 
Link: https://lore.kernel.org/r/1598548861-32373-6-git-send-email-skomatineni@nvidia.com
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

arm64: tegra: Add missing timeout clock to Tegra194 SDMMC nodes

2020-09-05T09:22:50+00:00

commit c956c0cd4f6f4aac4f095621b1c4e1c5ee1df877 upstream.

commit 5425fb15d8ee ("arm64: tegra: Add Tegra194 chip device tree")

Tegra194 uses separate SDMMC_LEGACY_TM clock for data timeout and
this clock is not enabled currently which is not recommended.

Tegra194 SDMMC advertises 12Mhz as timeout clock frequency in host
capability register.

So, this clock should be kept enabled by SDMMC driver.

Fixes: 5425fb15d8ee ("arm64: tegra: Add Tegra194 chip device tree")
Cc: stable  # 5.4
Tested-by: Jon Hunter 
Reviewed-by: Jon Hunter 
Signed-off-by: Sowjanya Komatineni 
Link: https://lore.kernel.org/r/1598548861-32373-7-git-send-email-skomatineni@nvidia.com
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

dt-bindings: mmc: tegra: Add tmclk for Tegra210 and later

2020-09-05T09:22:50+00:00

commit f7f86e8ac0ad7cd6792a80137f5a550924966916 upstream.

commit b5a84ecf025a ("mmc: tegra: Add Tegra210 support")

Tegra210 and later uses separate SDMMC_LEGACY_TM clock for data
timeout.

So, this patch adds "tmclk" to Tegra sdhci clock property in the
device tree binding.

Fixes: b5a84ecf025a ("mmc: tegra: Add Tegra210 support")
Cc: stable  # 5.4
Reviewed-by: Jon Hunter 
Signed-off-by: Sowjanya Komatineni 
Link: https://lore.kernel.org/r/1598548861-32373-4-git-send-email-skomatineni@nvidia.com
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

KVM: arm64: Set HCR_EL2.PTW to prevent AT taking synchronous exception

2020-09-05T09:22:50+00:00

commit 71a7f8cb1ca4ca7214a700b1243626759b6c11d4 upstream.

AT instructions do a translation table walk and return the result, or
the fault in PAR_EL1. KVM uses these to find the IPA when the value is
not provided by the CPU in HPFAR_EL1.

If a translation table walk causes an external abort it is taken as an
exception, even if it was due to an AT instruction. (DDI0487F.a's D5.2.11
"Synchronous faults generated by address translation instructions")

While we previously made KVM resilient to exceptions taken due to AT
instructions, the device access causes mismatched attributes, and may
occur speculatively. Prevent this, by forbidding a walk through memory
described as device at stage2. Now such AT instructions will report a
stage2 fault.

Such a fault will cause KVM to restart the guest. If the AT instructions
always walk the page tables, but guest execution uses the translation cached
in the TLB, the guest can't make forward progress until the TLB entry is
evicted. This isn't a problem, as since commit 5dcd0fdbb492 ("KVM: arm64:
Defer guest entry when an asynchronous exception is pending"), KVM will
return to the host to process IRQs allowing the rest of the system to keep
running.

Cc: stable@vger.kernel.org # 
Reviewed-by: Marc Zyngier 
Signed-off-by: Catalin Marinas 
Signed-off-by: Andre Przywara 
Signed-off-by: Greg Kroah-Hartman