aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-03-04iommu: Don't use lazy flush for untrusted deviceLu Baolu1-7/+8
The lazy IOTLB flushing setup leaves a time window, in which the device can still access some system memory, which has already been unmapped by the device driver. It's not suitable for untrusted devices. A malicious device might use this to attack the system by obtaining data that it shouldn't obtain. Fixes: c588072bba6b5 ("iommu/vt-d: Convert intel iommu driver to the iommu ops") Signed-off-by: Lu Baolu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]>
2021-03-04iommu/tegra-smmu: Fix mc errors on tegra124-nyanNicolin Chen1-1/+71
Commit 25938c73cd79 ("iommu/tegra-smmu: Rework tegra_smmu_probe_device()") removed certain hack in the tegra_smmu_probe() by relying on IOMMU core to of_xlate SMMU's SID per device, so as to get rid of tegra_smmu_find() and tegra_smmu_configure() that are typically done in the IOMMU core also. This approach works for both existing devices that have DT nodes and other devices (like PCI device) that don't exist in DT, on Tegra210 and Tegra3 upon testing. However, Page Fault errors are reported on tegra124-Nyan: tegra-mc 70019000.memory-controller: display0a: read @0xfe056b40: EMEM address decode error (SMMU translation error [--S]) tegra-mc 70019000.memory-controller: display0a: read @0xfe056b40: Page fault (SMMU translation error [--S]) After debugging, I found that the mentioned commit changed some function callback sequence of tegra-smmu's, resulting in enabling SMMU for display client before display driver gets initialized. I couldn't reproduce exact same issue on Tegra210 as Tegra124 (arm-32) differs at arch-level code. Actually this Page Fault is a known issue, as on most of Tegra platforms, display gets enabled by the bootloader for the splash screen feature, so it keeps filling the framebuffer memory. A proper fix to this issue is to 1:1 linear map the framebuffer memory to IOVA space so the SMMU will have the same address as the physical address in its page table. Yet, Thierry has been working on the solution above for a year, and it hasn't merged. Therefore, let's partially revert the mentioned commit to fix the errors. The reason why we do a partial revert here is that we can still set priv in ->of_xlate() callback for PCI devices. Meanwhile, devices existing in DT, like display, will go through tegra_smmu_configure() at the stage of bus_set_iommu() when SMMU gets probed(), as what it did before we merged the mentioned commit. Once we have the linear map solution for framebuffer memory, this change can be cleaned away. [Big thank to Guillaume who reported and helped debugging/verification] Fixes: 25938c73cd79 ("iommu/tegra-smmu: Rework tegra_smmu_probe_device()") Reported-by: Guillaume Tucker <[email protected]> Signed-off-by: Nicolin Chen <[email protected]> Tested-by: Guillaume Tucker <[email protected]> Acked-by: Thierry Reding <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]>
2021-03-04iommu/amd: Fix sleeping in atomic in increase_address_space()Andrey Ryabinin1-4/+6
increase_address_space() calls get_zeroed_page(gfp) under spin_lock with disabled interrupts. gfp flags passed to increase_address_space() may allow sleeping, so it comes to this: BUG: sleeping function called from invalid context at mm/page_alloc.c:4342 in_atomic(): 1, irqs_disabled(): 1, pid: 21555, name: epdcbbf1qnhbsd8 Call Trace: dump_stack+0x66/0x8b ___might_sleep+0xec/0x110 __alloc_pages_nodemask+0x104/0x300 get_zeroed_page+0x15/0x40 iommu_map_page+0xdd/0x3e0 amd_iommu_map+0x50/0x70 iommu_map+0x106/0x220 vfio_iommu_type1_ioctl+0x76e/0x950 [vfio_iommu_type1] do_vfs_ioctl+0xa3/0x6f0 ksys_ioctl+0x66/0x70 __x64_sys_ioctl+0x16/0x20 do_syscall_64+0x4e/0x100 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fix this by moving get_zeroed_page() out of spin_lock/unlock section. Fixes: 754265bcab ("iommu/amd: Fix race in increase_address_space()") Signed-off-by: Andrey Ryabinin <[email protected]> Acked-by: Will Deacon <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]>
2021-03-04drm/i915/edp: enable eDP MSO during link trainingJani Nikula3-4/+89
If the source and sink support MSO, enable it during link training. v4: Divide DRRS pixel clock by link count before M/N calculation v3: Adjust timings, refer to splitter v2: Limit MSO to pipe A using ->pipe_mask Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2711 Cc: Nischal Varide <[email protected]> Reviewed-by: Uma Shankar <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/66da48b4b3c5ccffaac7989097cd96d6c6af8243.1614682842.git.jani.nikula@intel.com
2021-03-04drm/i915/edp: modify fixed and downclock modes for MSOJani Nikula1-0/+29
In the case of MSO (Multi-SST Operation), the EDID contains the timings for a single panel segment. We'll want to hide the fact from userspace, and expose modes that span the entire display. Don't modify the EDID, as the userspace should not use that for modesetting, only modify the actual modes. v3: Use pixel overlap if available. v2: Rename intel_dp_mso_mode_fixup -> intel_edp_mso_mode_fixup Cc: Nischal Varide <[email protected]> Reviewed-by: Uma Shankar <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/2862284eb033bb0ffc96134b7d5b11bf29e4587f.1614682842.git.jani.nikula@intel.com
2021-03-04drm/i915/mso: add splitter state checkJani Nikula1-0/+4
For starters, we expect the state to be zero, as we don't enable MSO anywhere. v2: Refer to splitter. Cc: Nischal Varide <[email protected]> Reviewed-by: Uma Shankar <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/459a332f3cdce941c57312150872559db68f88c1.1614682842.git.jani.nikula@intel.com
2021-03-04drm/i915/mso: add splitter state readout for platforms that support itJani Nikula4-2/+79
Add splitter configuration to crtc state, and read it where supported. Also add splitter state dumping. The stream splitter will be required for eDP MSO. v4: - Catch invalid splitter configuration (Uma) v3: - Convert segment timings to full panel timings. - Refer to splitter instead of mso in crtc state. - Dump splitter state. v2: Add warning for mso being enabled on pipes other than A. Cc: Nischal Varide <[email protected]> Cc: Uma Shankar <[email protected]> Reviewed-by: Uma Shankar <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/95cbe1c9d45edf3e3ec252e49fb49055def98155.1614682842.git.jani.nikula@intel.com
2021-03-03drm/amdgpu: fix parameter error of RREG32_PCIE() in amdgpu_regs_pcieKevin Wang1-2/+2
the register offset isn't needed division by 4 to pass RREG32_PCIE() Signed-off-by: Kevin Wang <[email protected]> Reviewed-by: Lijo Lazar <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2021-03-03drm/amd/display: fix the return of the uninitialized value in retColin Ian King1-1/+1
Currently if stream->signal is neither SIGNAL_TYPE_DISPLAY_PORT_MST or SIGNAL_TYPE_DISPLAY_PORT then variable ret is uninitialized and this is checked for > 0 at the end of the function. Ret should be initialized, I believe setting it to zero is a correct default. Addresses-Coverity: ("Uninitialized scalar variable") Fixes: bd0c064c161c ("drm/amd/display: Add return code instead of boolean for future use") Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Colin Ian King <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-03-03drm/amdgpu: enable BACO runpm by default on sienna cichlid and navy flounderAlex Deucher1-2/+0
It works fine and was only disabled because primary GPUs don't enter runpm if there is a console bound to the fbdev due to the kmap. This will at least allow runpm on secondary cards. Reviewed-by: Evan Quan <[email protected]> Reviewed-by: Rajneesh Bhardwaj <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-03-03drm/amd/pm: correct Arcturus mmTHM_BACO_CNTL register addressEvan Quan1-3/+12
Arcturus has a different register address from other SMU V11 ASICs. Signed-off-by: Evan Quan <[email protected]> Acked-by: Guchun Chen <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2021-03-03drm/amdgpu/swsmu/vangogh: Only use RLCPowerNotify msg for disableAlex Deucher1-2/+2
Per discussions with PMFW team, the driver only needs to notify the PMFW when the RLC is disabled. The RLC FW will notify the PMFW directly when it's enabled. Acked-by: Evan Quan <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-03-03drm/amdgpu/pm: make unsupported power profile messages debugAlex Deucher3-3/+3
Making them an error confuses users and the errors are harmless as not all asics support all profiles. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1488 Acked-by: Nirmoy Das <[email protected]> Reviewed-by: Evan Quan <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-03-03drm/amdgpu:disable VCN for Navi12 SKUAsher.Song1-2/+4
Navi12 0x7360/C7 SKU has no video support, so remove it. Reviewed-by: Guchun Chen <[email protected]> Signed-off-by: Asher.Song <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2021-03-03drm/amdgpu: Only check for S0ix if AMD_PMC is configuredAlex Deucher1-1/+2
The S0ix check only makes sense if the AMD PMC driver is present. We need to use the legacy S3 pathes when the PMC driver is not present. Reviewed-by: Prike Liang <[email protected]> Reviewed-by: Rajneesh Bhardwaj <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2021-03-03ACPI: bus: Constify is_acpi_node() and friends (part 2)Andy Shevchenko1-3/+3
Commit 8b9d6802583a ("ACPI: Constify acpi_bus helper functions, switch to macros") only changed functions for CONFIG_ACPI=y case. This part adjusts the rest. Fixes: 8b9d6802583a ("ACPI: Constify acpi_bus helper functions, switch to macros") Signed-off-by: Andy Shevchenko <[email protected]> Reviewed-by: Sakari Ailus <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2021-03-03RDMA/uverbs: Fix kernel-doc warning of _uverbs_allocLeon Romanovsky1-1/+1
Fix the following W=1 compilation warning: drivers/infiniband/core/uverbs_ioctl.c:108: warning: expecting prototype for uverbs_alloc(). Prototype was for _uverbs_alloc() instead Fixes: 461bb2eee4e1 ("IB/uverbs: Add a simple allocator to uverbs_attr_bundle") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
2021-03-03RDMA/mlx5: Set correct kernel-doc identifierLeon Romanovsky1-1/+1
The W=1 allmodconfig build produces the following warning: drivers/infiniband/hw/mlx5/odp.c:1086: warning: wrong kernel-doc identifier on line: * Parse a series of data segments for page fault handling. Fix it by changing /** to be /* as it is written in kernel-doc documentation. Fixes: 5e769e444d26 ("RDMA/hw/mlx5/odp: Fix formatting and add missing descriptions in 'pagefault_data_segments()'") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
2021-03-03tpm: Remove unintentional dump_stack() callJarkko Sakkinen1-2/+0
Somewhere along the line, probably during a rebase, an unintentional dump_stack() got included. Revert this change. Reported-by: Rikard Falkeborn <[email protected]> Fixes: 90cba8d20f8b ("tpm/ppi: Constify static struct attribute_group") Signed-off-by: Jarkko Sakkinen <[email protected]>
2021-03-03ALSA: hda/realtek: Apply dual codec quirks for MSI Godlike X570 boardTakashi Iwai1-0/+1
There is another MSI board (1462:cc34) that has dual Realtek codecs, and we need to apply the existing quirk for fixing the conflicts of Master control. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=211743 Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2021-03-03rsxx: Return -EFAULT if copy_to_user() failsDan Carpenter1-3/+5
The copy_to_user() function returns the number of bytes remaining but we want to return -EFAULT to the user if it can't complete the copy. The "st" variable only holds zero on success or negative error codes on failure so the type should be int. Fixes: 36f988e978f8 ("rsxx: Adding in debugfs entries.") Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2021-03-03drm/i915: Clean up verify_wm_state()Ville Syrjälä2-76/+17
Get rid of the nonsense cursor special case in verify_wm_state() by just iterating through all the planes. And let's use the canonical [PLANE:..] style in the debug prints while at it. Cc: Stanislav Lisovskiy <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Stanislav Lisovskiy <[email protected]>
2021-03-03drm/i915: Check tgl+ SAGV watermarks properlyVille Syrjälä3-50/+47
We know which WM0 (normal vs. SAGV) we supposedly programmed into the hardware, so just check against that instead of accepting either watermark as valid. Cc: Stanislav Lisovskiy <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Stanislav Lisovskiy <[email protected]>
2021-03-03drm/i915: Introduce SAGV transtion watermarkVille Syrjälä3-34/+65
Seems to me that if we calculate WM0 using the bumped up SAGV latency we need to calculate the transition watermark accordingly. Track it alongside the other watermarks. Cc: Stanislav Lisovskiy <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Stanislav Lisovskiy <[email protected]>
2021-03-03drm/i915: Stuff SAGV watermark into a sub-structureVille Syrjälä3-18/+20
We'll want a SAGV transition watermark as well. Prepare for that by collecting SAGV wm0 into a sub-strcture. Cc: Stanislav Lisovskiy <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Stanislav Lisovskiy <[email protected]>
2021-03-03drm/i915: Print wm changes if sagv_wm0 changesVille Syrjälä1-1/+2
Let's consider sagv_wm0 as well when deciding whether to dump out the watermark changes. Cc: Stanislav Lisovskiy <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Stanislav Lisovskiy <[email protected]>
2021-03-03drm/i915: Zero out SAGV wm when we don't have enough DDB for itVille Syrjälä1-5/+6
Let's handle the SAGV WM0 more like the other wm levels and just totally zero it out when we don't have the DDB space to back it up. Cc: Stanislav Lisovskiy <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Stanislav Lisovskiy <[email protected]>
2021-03-03drm/i915: Fix TGL+ plane SAGV watermark programmingVille Syrjälä1-23/+37
When we switch between SAGV on vs. off we need to reprogram all plane wateramrks accordingly. Currently skl_wm_add_affected_planes() totally ignores the SAGV watermark and just assumes we will use the normal WM0. Fix this by utilizing skl_plane_wm_level() which picks the correct watermark based on use_sagv_wm. Thus we will force an update on all the planes whose watermark registers need to be reprogrammed. Cc: Stanislav Lisovskiy <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Stanislav Lisovskiy <[email protected]>
2021-03-03drm/i915: Readout conn_state->max_bpcVille Syrjälä1-8/+16
Populate conn_state->max_bpc with something sensible from the start. Otherwise it's possible that we get to compute_sink_pipe_bpp() with max_bpc==0. The specific scenario goes as follows: 1. Initial connector state allocated with max_bpc==0 2. Trigger a modeset on the crtc feeding the connector, without actually adding the connector to the commit 3. drm_atomic_connector_check() is skipped because the connector has not yet been added, hence conn_state->max_bpc retains its current value 4. drm_atomic_helper_check_modeset() -> drm_atomic_add_affected_connectors() -> the connector is now part of the commit 5. compute_baseline_pipe_bpp() -> MISSING_CASE(max_bpc==0) Note that pipe_bpp itself may not be populated on pre-g4x machines, in which case we just fall back to max_bpc==8 and let .compute_config() limit the resulting pipe_bpp further if necessary. Cc: Daniel Vetter <[email protected]> Reported-by: Chris Wilson <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Tested-by: Chris Wilson <[email protected]> Reviewed-by: José Roberto de Souza <[email protected]>
2021-03-03ALSA: hda/realtek: Add quirk for Intel NUC 10Werner Sembach1-0/+11
This adds a new SND_PCI_QUIRK(...) and applies it to the Intel NUC 10 devices. This fixes the issue of the devices not having audio input and output on the headset jack because the kernel does not recognize when something is plugged in. The new quirk was inspired by the quirk for the Intel NUC 8 devices, but it turned out that the NUC 10 uses another pin. This information was acquired by black box testing likely pins. Co-developed-by: Eckhart Mohr <[email protected]> Signed-off-by: Eckhart Mohr <[email protected]> Signed-off-by: Werner Sembach <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2021-03-03xen: fix p2m size in dom0 for disabled memory hotplug caseJuergen Gross3-26/+21
Since commit 9e2369c06c8a18 ("xen: add helpers to allocate unpopulated memory") foreign mappings are using guest physical addresses allocated via ZONE_DEVICE functionality. This will result in problems for the case of no balloon memory hotplug being configured, as the p2m list will only cover the initial memory size of the domain. Any ZONE_DEVICE allocated address will be outside the p2m range and thus a mapping can't be established with that memory address. Fix that by extending the p2m size for that case. At the same time add a check for a to be created mapping to be within the p2m limits in order to detect errors early. While changing a comment, remove some 32-bit leftovers. This is XSA-369. Fixes: 9e2369c06c8a18 ("xen: add helpers to allocate unpopulated memory") Cc: <[email protected]> # 5.9 Reported-by: Marek Marczykowski-Górecki <[email protected]> Signed-off-by: Juergen Gross <[email protected]> Reviewed-by: Jan Beulich <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
2021-03-03xen-netback: respect gnttab_map_refs()'s return valueJan Beulich1-1/+11
Commit 3194a1746e8a ("xen-netback: don't "handle" error by BUG()") dropped respective a BUG_ON() without noticing that with this the variable's value wouldn't be consumed anymore. With gnttab_set_map_op() setting all status fields to a non-zero value, in case of an error no slot should have a status of GNTST_okay (zero). This is part of XSA-367. Cc: <[email protected]> Reported-by: kernel test robot <[email protected]> Signed-off-by: Jan Beulich <[email protected]> Reviewed-by: Juergen Gross <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Juergen Gross <[email protected]>
2021-03-03Xen/gnttab: handle p2m update errors on a per-slot basisJan Beulich2-7/+72
Bailing immediately from set_foreign_p2m_mapping() upon a p2m updating error leaves the full batch in an ambiguous state as far as the caller is concerned. Instead flags respective slots as bad, unmapping what was mapped there right away. HYPERVISOR_grant_table_op()'s return value and the individual unmap slots' status fields get used only for a one-time - there's not much we can do in case of a failure. Note that there's no GNTST_enomem or alike, so GNTST_general_error gets used. The map ops' handle fields get overwritten just to be on the safe side. This is part of XSA-367. Cc: <[email protected]> Signed-off-by: Jan Beulich <[email protected]> Reviewed-by: Juergen Gross <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Juergen Gross <[email protected]>
2021-03-02Merge tag 'misc-5.12-2021-03-02' of git://git.kernel.dk/linux-blockLinus Torvalds4-6/+16
Pull misc fixes from Jens Axboe: "Two misc fixes that don't belong in other branches: - Fix a regression with ia64 signals, introduced by the TIF_NOTIFY_SIGNAL change in 5.11. - Fix the current swapfile regression from this merge window" * tag 'misc-5.12-2021-03-02' of git://git.kernel.dk/linux-block: swap: fix swapfile read/write offset ia64: don't call handle_signal() unless there's actually a signal queued
2021-03-02swap: fix swapfile read/write offsetJens Axboe3-5/+14
We're not factoring in the start of the file for where to write and read the swapfile, which leads to very unfortunate side effects of writing where we should not be... Fixes: 48d15436fde6 ("mm: remove get_swap_bio") Signed-off-by: Jens Axboe <[email protected]>
2021-03-02ia64: don't call handle_signal() unless there's actually a signal queuedJens Axboe1-1/+2
Sergei and John both reported that ia64 failed to boot in 5.11, and it was related to signals. Turns out the ia64 signal handling is a bit odd, it doesn't check the return value of get_signal() for whether there's a signal to deliver or not. With the introduction of TIF_NOTIFY_SIGNAL, then task_work could trigger it. Fix it by only calling handle_signal() if we actually have a real signal to deliver. This brings it in line with all other archs, too. Fixes: b269c229b0e8 ("ia64: add support for TIF_NOTIFY_SIGNAL") Reported-by: Sergei Trofimovich <[email protected]> Reported-by: John Paul Adrian Glaubitz <[email protected]> Tested-by: Sergei Trofimovich <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2021-03-02ftrace: Have recordmcount use w8 to read relp->r_info in arm64_is_fake_mcountChen Jun1-1/+1
On little endian system, Use aarch64_be(gcc v7.3) downloaded from linaro.org to build image with CONFIG_CPU_BIG_ENDIAN = y, CONFIG_FTRACE = y, CONFIG_DYNAMIC_FTRACE = y. gcc will create symbols of _mcount but recordmcount can not create mcount_loc for *.o. aarch64_be-linux-gnu-objdump -r fs/namei.o | grep mcount 00000000000000d0 R_AARCH64_CALL26 _mcount ... 0000000000007190 R_AARCH64_CALL26 _mcount The reason is than funciton arm64_is_fake_mcount can not work correctly. A symbol of _mcount in *.o compiled with big endian compiler likes: 00 00 00 2d 00 00 01 1b w(rp->r_info) will return 0x2d instead of 0x011b. Because w() takes uint32_t as parameter, which truncates rp->r_info. Use w8() instead w() to read relp->r_info Link: https://lkml.kernel.org/r/[email protected] Fixes: ea0eada45632 ("recordmcount: only record relocation of type R_AARCH64_CALL26 on arm64.") Acked-by: Will Deacon <[email protected]> Signed-off-by: Chen Jun <[email protected]> Signed-off-by: Steven Rostedt (VMware) <[email protected]>
2021-03-02drm/i915/icp+: Use icp_hpd_irq_setup() instead of spt_hpd_irq_setup()Lyude Paul1-0/+2
While reviewing patches for handling workarounds related to gen9 bc, Imre from Intel discovered that we're using spt_hpd_irq_setup() on ICP+ PCHs despite it being almost the same as icp_hpd_irq_setup(). Since we need to be calling icp_hpd_irq_setup() to ensure that CML-S/TGP platforms function correctly anyway, let's move platforms using PCH_ICP which aren't handled by gen11_hpd_irq_setup() over to icp_hpd_irq_setup(). Cc: Tejas Upadhyay <[email protected]> Signed-off-by: Lyude Paul <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-03-02drm/i915/gen9bc: Handle TGP PCH during suspend/resumeTejas Upadhyay1-17/+32
For Legacy S3 suspend/resume GEN9 BC needs to enable and setup TGP PCH. v2: * Move Wa_14010685332 into it's own function - vsyrjala * Add TODO comment about figuring out if we can move this workaround - imre v3: * Rename cnp_irq_post_reset() to cnp_display_clock_wa() * Add TODO item mentioning we need to clarify which platforms this workaround applies to * Just use ibx_irq_reset() in gen8_irq_reset(). This code should be functionally equivalent on gen9 bc to the code v2 added * Drop icp_hpd_irq_setup() call in spt_hpd_irq_setup(), this looks to be more or less identical to spt_hpd_irq_setup() minus additionally enabling one port. Will update i915 to use icp_hpd_irq_setup() for ICP in a separate patch. v4: * Revert Wa_14010685332 system list in comments to how it was before * Add back HAS_PCH_SPLIT() check before calling ibx_irq_reset() Cc: Matt Roper <[email protected]> Signed-off-by: Tejas Upadhyay <[email protected]> Signed-off-by: Lyude Paul <[email protected]> Reviewed-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-03-02pstore/ram: Rate-limit "uncorrectable error in header" messageDmitry Osipenko1-1/+1
There is a quite huge "uncorrectable error in header" flood in KMSG on a clean system boot since there is no pstore buffer saved in RAM. Let's silence the redundant noisy messages by rate-limiting the printk message. Now there are maximum 10 messages printed repeatedly instead of 35+. Signed-off-by: Dmitry Osipenko <[email protected]> Signed-off-by: Kees Cook <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2021-03-02KVM: SVM: Clear the CR4 register on resetBabu Moger1-0/+1
This problem was reported on a SVM guest while executing kexec. Kexec fails to load the new kernel when the PCID feature is enabled. When kexec starts loading the new kernel, it starts the process by resetting the vCPU's and then bringing each vCPU online one by one. The vCPU reset is supposed to reset all the register states before the vCPUs are brought online. However, the CR4 register is not reset during this process. If this register is already setup during the last boot, all the flags can remain intact. The X86_CR4_PCIDE bit can only be enabled in long mode. So, it must be enabled much later in SMP initialization. Having the X86_CR4_PCIDE bit set during SMP boot can cause a boot failures. Fix the issue by resetting the CR4 register in init_vmcb(). Signed-off-by: Babu Moger <[email protected]> Message-Id: <161471109108.30811.6392805173629704166.stgit@bmoger-ubuntu> Signed-off-by: Paolo Bonzini <[email protected]>
2021-03-02KVM: x86/xen: Add support for vCPU runstate informationDavid Woodhouse7-5/+553
This is how Xen guests do steal time accounting. The hypervisor records the amount of time spent in each of running/runnable/blocked/offline states. In the Xen accounting, a vCPU is still in state RUNSTATE_running while in Xen for a hypercall or I/O trap, etc. Only if Xen explicitly schedules does the state become RUNSTATE_blocked. In KVM this means that even when the vCPU exits the kvm_run loop, the state remains RUNSTATE_running. The VMM can explicitly set the vCPU to RUNSTATE_blocked by using the KVM_XEN_VCPU_ATTR_TYPE_RUNSTATE_CURRENT attribute, and can also use KVM_XEN_VCPU_ATTR_TYPE_RUNSTATE_ADJUST to retrospectively add a given amount of time to the blocked state and subtract it from the running state. The state_entry_time corresponds to get_kvmclock_ns() at the time the vCPU entered the current state, and the total times of all four states should always add up to state_entry_time. Co-developed-by: Joao Martins <[email protected]> Signed-off-by: Joao Martins <[email protected]> Signed-off-by: David Woodhouse <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2021-03-02KVM: x86/xen: Fix return code when clearing vcpu_info and vcpu_time_infoDavid Woodhouse1-0/+4
When clearing the per-vCPU shared regions, set the return value to zero to indicate success. This was causing spurious errors to be returned to userspace on soft reset. Also add a paranoid BUILD_BUG_ON() for compat structure compatibility. Fixes: 0c165b3c01fe ("KVM: x86/xen: Allow reset of Xen attributes") Signed-off-by: David Woodhouse <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2021-03-02selftests: kvm: Mmap the entire vcpu mmap areaAaron Lewis1-2/+4
The vcpu mmap area may consist of more than just the kvm_run struct. Allocate enough space for the entire vcpu mmap area. Without this, on x86, the PIO page, for example, will be missing. This is problematic when dealing with an unhandled exception from the guest as the exception vector will be incorrectly reported as 0x0. Message-Id: <[email protected]> Reviewed-by: Andrew Jones <[email protected]> Co-developed-by: Steve Rutherford <[email protected]> Signed-off-by: Aaron Lewis <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2021-03-02KVM: Documentation: Fix index for KVM_CAP_PPC_DAWR1Kai Huang1-1/+1
It should be 7.23 instead of 7.22, which has already been taken by KVM_CAP_X86_BUS_LOCK_EXIT. Signed-off-by: Kai Huang <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2021-03-02KVM: x86: allow compiling out the Xen hypercall interfacePaolo Bonzini4-2/+42
The Xen hypercall interface adds to the attack surface of the hypervisor and will be used quite rarely. Allow compiling it out. Suggested-by: Christoph Hellwig <[email protected]> Reviewed-by: David Woodhouse <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2021-03-02block/bfq: update comments and default value in docs for fifo_expireJoseph Qi2-3/+3
Correct the comments since bfq_fifo_expire[0] is for async request, while bfq_fifo_expire[1] is for sync request. Also update docs, according the source code, the default fifo_expire_async is 250ms, and fifo_expire_sync is 125ms. Signed-off-by: Joseph Qi <[email protected]> Acked-by: Paolo Valente <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2021-03-02rsxx: remove unused including <linux/version.h>Tian Tao1-1/+0
Remove including <linux/version.h> that don't need it. Signed-off-by: Tian Tao <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2021-03-02ALSA: hda/hdmi: let new platforms assign the pcm slot dynamicallyHui Wang1-1/+17
If the platform set the dyn_pcm_assign to true, it will call hdmi_find_pcm_slot() to find a pcm slot when hdmi/dp monitor is connected and need to create a pcm. So far only intel_hsw_common_init() and patch_nvhdmi() set the dyn_pcm_assign to true, here we let tgl platforms assign the pcm slot dynamically first, if the driver runs for a period of time and there is no regression reported, we could set no_fixed_assgin to true in the intel_hsw_common_init(), and then set it to true in the patch_nvhdmi(). This change comes from the discussion between Takashi and Kai Vehmanen. Please refer to: https://github.com/alsa-project/alsa-lib/pull/118 Suggested-and-reviewed-by: Takashi Iwai <[email protected]> Suggested-and-reviewed-by: Kai Vehmanen <[email protected]> Signed-off-by: Hui Wang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2021-03-02ALSA: hda/realtek: Add quirk for Clevo NH55RZQEckhart Mohr1-0/+1
This applies a SND_PCI_QUIRK(...) to the Clevo NH55RZQ barebone. This fixes the issue of the device not recognizing a pluged in microphone. The device has both, a microphone only jack, and a speaker + microphone combo jack. The combo jack already works. The microphone-only jack does not recognize when a device is pluged in without this patch. Signed-off-by: Eckhart Mohr <[email protected]> Co-developed-by: Werner Sembach <[email protected]> Signed-off-by: Werner Sembach <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.