user/sven/linux.git, branch v5.19.9

Linux 5.19.9

2022-09-15T08:47:20Z

Link: https://lore.kernel.org/r/20220913140410.043243217@linuxfoundation.org Tested-by: Ronald Warsow Tested-by: Fenil Jain Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee Tested-by: Bagas Sanjaya Tested-by: Ron Economos Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Jiri Slaby Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Removing assert statements for Linux

2022-09-15T08:47:20Z

commit 149f6d1a6035a7aa6595ac6eeb9c8f566b2103cd upstream. [WHY] Assert statements causing several bugs on Linux DM [HOW] Removing assert statement for Linux DM (ASSERT(result == VBIOSSMC_Result_OK)). Also adding logging statements for setting dcfclk. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=216092 Fixes: c1b972a18d05 ("drm/amd/display: Insert pulling smu busy status before sending another request") Reviewed-by: Gabe Teeger Acked-by: Solomon Chiu Signed-off-by: Saaem Rizvi Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Add SMU logging code

2022-09-15T08:47:20Z

commit 4b33b5ffcf68de3a43e7dddc91c5dc86e6ed8587 upstream. [WHY] Logging for SMU response value after the wait allows us to know immediately what the response value was. Makes it easier to debug should the value be anything other than OK. [HOW] Using the the already available DC SMU logging functions. Tested-by: Daniel Wheeler Reviewed-by: Charlene Liu Acked-by: Rodrigo Siqueira Signed-off-by: Saaem Rizvi Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman

iommu: Fix false ownership failure on AMD systems with PASID activated

2022-09-15T08:47:20Z

commit 2380f1e8195ef612deea1dc7a3d611c5d2b9b56a upstream. The AMD IOMMU driver cannot activate PASID mode on a RID without the RID's translation being set to IDENTITY. Further it requires changing the RID's page table layout from the normal v1 IOMMU_DOMAIN_IDENTITY layout to a different v2 layout. It does this by creating a new iommu_domain, configuring that domain for v2 identity operation and then attaching it to the group, from within the driver. This logic assumes the group is already set to the IDENTITY domain and is being used by the DMA API. However, since the ownership logic is based on the group's domain pointer equaling the default domain to detect DMA API ownership, this causes it to look like the group is not attached to the DMA API any more. This blocks attaching drivers to any other devices in the group. In a real system this manifests itself as the HD-audio devices on some AMD platforms losing their device drivers. Work around this unique behavior of the AMD driver by checking for equality of IDENTITY domains based on their type, not their pointer value. This allows the AMD driver to have two IDENTITY domains for internal purposes without breaking the check. Have the AMD driver properly declare that the special domain it created is actually an IDENTITY domain. Cc: Robin Murphy Cc: stable@vger.kernel.org Fixes: 512881eacfa7 ("bus: platform,amba,fsl-mc,PCI: Add device DMA ownership management") Reported-by: Takashi Iwai Tested-by: Takashi Iwai Signed-off-by: Jason Gunthorpe Reviewed-by: Robin Murphy Link: https://lore.kernel.org/r/0-v1-ea566e16b06b+811-amd_owner_jgg@nvidia.com Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman

iommu/virtio: Fix interaction with VFIO

2022-09-15T08:47:20Z

commit 91c98fe7941499e4127cdc359c30841b873dd43a upstream. Commit e8ae0e140c05 ("vfio: Require that devices support DMA cache coherence") requires IOMMU drivers to advertise IOMMU_CAP_CACHE_COHERENCY, in order to be used by VFIO. Since VFIO does not provide to userspace the ability to maintain coherency through cache invalidations, it requires hardware coherency. Advertise the capability in order to restore VFIO support. The meaning of IOMMU_CAP_CACHE_COHERENCY also changed from "IOMMU can enforce cache coherent DMA transactions" to "IOMMU_CACHE is supported". While virtio-iommu cannot enforce coherency (of PCIe no-snoop transactions), it does support IOMMU_CACHE. We can distinguish different cases of non-coherent DMA: (1) When accesses from a hardware endpoint are not coherent. The host would describe such a device using firmware methods ('dma-coherent' in device-tree, '_CCA' in ACPI), since they are also needed without a vIOMMU. In this case mappings are created without IOMMU_CACHE. virtio-iommu doesn't need any additional support. It sends the same requests as for coherent devices. (2) When the physical IOMMU supports non-cacheable mappings. Supporting those would require a new feature in virtio-iommu, new PROBE request property and MAP flags. Device drivers would use a new API to discover this since it depends on the architecture and the physical IOMMU. (3) When the hardware supports PCIe no-snoop. It is possible for assigned PCIe devices to issue no-snoop transactions, and the virtio-iommu specification is lacking any mention of this. Arm platforms don't necessarily support no-snoop, and those that do cannot enforce coherency of no-snoop transactions. Device drivers must be careful about assuming that no-snoop transactions won't end up cached; see commit e02f5c1bb228 ("drm: disable uncached DMA optimization for ARM and arm64"). On x86 platforms, the host may or may not enforce coherency of no-snoop transactions with the physical IOMMU. But according to the above commit, on x86 a driver which assumes that no-snoop DMA is compatible with uncached CPU mappings will also work if the host enforces coherency. Although these issues are not specific to virtio-iommu, it could be used to facilitate discovery and configuration of no-snoop. This would require a new feature bit, PROBE property and ATTACH/MAP flags. Cc: stable@vger.kernel.org Fixes: e8ae0e140c05 ("vfio: Require that devices support DMA cache coherence") Signed-off-by: Jean-Philippe Brucker Reviewed-by: Robin Murphy Link: https://lore.kernel.org/r/20220825154622.86759-1-jean-philippe@linaro.org Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman

iommu/vt-d: Correctly calculate sagaw value of IOMMU

2022-09-15T08:47:20Z

commit 53fc7ad6edf210b497230ce74b61b322a202470c upstream. The Intel IOMMU driver possibly selects between the first-level and the second-level translation tables for DMA address translation. However, the levels of page-table walks for the 4KB base page size are calculated from the SAGAW field of the capability register, which is only valid for the second-level page table. This causes the IOMMU driver to stop working if the hardware (or the emulated IOMMU) advertises only first-level translation capability and reports the SAGAW field as 0. This solves the above problem by considering both the first level and the second level when calculating the supported page table levels. Fixes: b802d070a52a1 ("iommu/vt-d: Use iova over first level") Cc: stable@vger.kernel.org Signed-off-by: Lu Baolu Link: https://lore.kernel.org/r/20220817023558.3253263-1-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman

arm64/bti: Disable in kernel BTI when cross section thunks are broken

2022-09-15T08:47:20Z

commit c0a454b9044fdc99486853aa424e5b3be2107078 upstream. GCC does not insert a `bti c` instruction at the beginning of a function when it believes that all callers reach the function through a direct branch[1]. Unfortunately the logic it uses to determine this is not sufficiently robust, for example not taking account of functions being placed in different sections which may be loaded separately, so we may still see thunks being generated to these functions. If that happens, the first instruction in the callee function will result in a Branch Target Exception due to the missing landing pad. While this has currently only been observed in the case of modules having their main code loaded sufficiently far from their init section to require thunks it could potentially happen for other cases so the safest thing is to disable BTI for the kernel when building with an affected toolchain. [1]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106671 Reported-by: D Scott Phillips [Bits of the commit message are lifted from his report & workaround] Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20220905142255.591990-1-broonie@kernel.org Cc: # v5.10+ Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman

hwmon: (asus-ec-sensors) autoload module via DMI data

2022-09-15T08:47:20Z

[ Upstream commit 88700d1396bae72d9a4c23a48bbd98c1c2f53f3d ] Replace autoloading data based on the ACPI EC device with the DMI records for motherboards models. The ACPI method created a bug that when this driver returns error from the probe function because of the unsupported motherboard model, the ACPI subsystem concludes that the EC device does not work properly. Fixes: 5cd29012028d ("hwmon: (asus-ec-sensors) introduce ec_board_info struct for board data") Bug: https://bugzilla.kernel.org/show_bug.cgi?id=216412 Bug: https://bugzilla.redhat.com/show_bug.cgi?id=2121844 Signed-off-by: Eugene Shalygin Link: https://lore.kernel.org/r/20220909155654.123398-2-eugene.shalygin@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin

hwmon: (asus-ec-sensors) add definitions for ROG ZENITH II EXTREME

2022-09-15T08:47:20Z

[ Upstream commit 9992b19d756ab8f0889fcaf3e71ff93852e74694 ] Add definitions for ROG ZENITH II EXTREME and some unknown yet temperature sensors in the second EC bank. Details are available at [1, 2]. [1] https://github.com/zeule/asus-ec-sensors/pull/26 [2] https://github.com/zeule/asus-ec-sensors/issues/16 Signed-off-by: Urs Schroffenegger Signed-off-by: Eugene Shalygin Link: https://lore.kernel.org/r/20220710202639.1812058-2-eugene.shalygin@gmail.com Signed-off-by: Guenter Roeck Stable-dep-of: 88700d1396ba ("hwmon: (asus-ec-sensors) autoload module via DMI data") Signed-off-by: Sasha Levin

hwmon: (asus-ec-sensors) add missing sensors for X570-I GAMING

2022-09-15T08:47:20Z

[ Upstream commit 1c4e4f4a0e8d9ebe8be1c838fec4fb7053a989d9 ] VRM and chipset temperature for ROG STRIX X570-I GAMING were missing according to a user contribution to the LHM project [1]. [1] https://github.com/LibreHardwareMonitor/LibreHardwareMonitor/pull/767 Signed-off-by: Eugene Shalygin Link: https://lore.kernel.org/r/20220710085539.1682869-1-eugene.shalygin@gmail.com Signed-off-by: Guenter Roeck Stable-dep-of: 88700d1396ba ("hwmon: (asus-ec-sensors) autoload module via DMI data") Signed-off-by: Sasha Levin