- Sep 20, 2022
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20220916100448.431016349@linuxfoundation.org Tested-by:
Ronald Warsow <rwarsow@gmx.de> Tested-by:
Guenter Roeck <linux@roeck-us.net> Tested-by:
Ron Economos <re@w6rz.net> Tested-by:
Fenil Jain <fkjainco@gmail.com> Tested-by:
Bagas Sanjaya <bagasdotme@gmail.com> Tested-by:
Sudip Mukherjee <sudip.mukherjee@codethink.co.uk> Tested-by:
Justin M. Forbes <jforbes@fedoraproject.org> Tested-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jarrah Gosbell authored
commit 80b9ebd3 upstream. Add compatible string for GT1158 missing from the previous patch. Fixes: 425fe470 ("Input: goodix - add support for GT1158") Signed-off-by:
Jarrah Gosbell <kernel@undef.tools> Link: https://lore.kernel.org/r/20220813043821.9981-1-kernel@undef.tools Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Sindhu-Devale authored
commit 2c884443 upstream. Send with invalidate verb call can pass in an uninitialized s/g array with 0 sge's which is filled into irdma WQE and causes a HW asynchronous event. Fix this by using the s/g array in irdma post send only when its valid. Fixes: 551c46ed ("RDMA/irdma: Add user/kernel shared libraries") Signed-off-by:
Sindhu-Devale <sindhu.devale@intel.com> Signed-off-by:
Shiraz Saleem <shiraz.saleem@intel.com> Link: https://lore.kernel.org/r/20220906223244.1119-5-shiraz.saleem@intel.com Signed-off-by:
Leon Romanovsky <leon@kernel.org> Signed-off-by:
-
William Breathitt Gray authored
[ Upstream commit 410a5041 ] Kernel warns about mutable irq_chips: "not an immutable chip, please consider fixing!" Make the struct irq_chip const, flag it as IRQCHIP_IMMUTABLE, add the new helper functions, and call the appropriate gpiolib functions. Signed-off-by:
William Breathitt Gray <william.gray@linaro.org> Signed-off-by:
Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
William Breathitt Gray authored
[ Upstream commit 35f0aa77 ] Kernel warns about mutable irq_chips: "not an immutable chip, please consider fixing!" Make the struct irq_chip const, flag it as IRQCHIP_IMMUTABLE, add the new helper functions, and call the appropriate gpiolib functions. Signed-off-by:
-
Yupeng Li authored
[ Upstream commit 1a470ce4 ] The kernel build error when unslected CONFIG_MEMORY_HOTREMOVE because arch_remove_memory() is needed by mm/memory_hotplug.c but undefined. Some build error messages like: LD vmlinux.o MODPOST vmlinux.symvers MODINFO modules.builtin.modinfo GEN modules.builtin LD .tmp_vmlinux.kallsyms1 loongarch64-linux-gnu-ld: mm/memory_hotplug.o: in function `.L242': memory_hotplug.c:(.ref.text+0x930): undefined reference to `arch_remove_memory' make: *** [Makefile:1169：vmlinux] 错误 1 Removed CONFIG_MEMORY_HOTREMOVE requirement and rearrange the file refer to the definitions of other platform architectures. Signed-off-by:
Yupeng Li <liyupeng@zbhlos.com> Signed-off-by:
Caicai <caizp2008@163.com> Signed-off-by:
Huacai Chen <chenhuacai@loongson.cn> Signed-off-by:
-
Huacai Chen authored
[ Upstream commit e0fba87c ] Now acpi_os_ioremap() is marked with __init because it calls memblock_ is_memory() which is also marked with __init in the !ARCH_KEEP_MEMBLOCK case. However, acpi_os_ioremap() is called by ordinary functions such as acpi_os_{read, write}_memory() and causes section mismatch warnings: WARNING: modpost: vmlinux.o: section mismatch in reference: acpi_os_read_memory (section: .text) -> acpi_os_ioremap (section: .init.text) WARNING: modpost: vmlinux.o: section mismatch in reference: acpi_os_write_memory (section: .text) -> acpi_os_ioremap (section: .init.text) Fix these warnings by selecting ARCH_KEEP_MEMBLOCK unconditionally and removing the __init modifier of acpi_os_ioremap(). This can also give a chance to track "memory" and "reserved" memblocks after early boot. Signed-off-by:
-
Luke D. Jones authored
[ Upstream commit 5542dfc5 ] Fix for TUF laptops returning with an -ENOSPC on calling asus_wmi_evaluate_method_buf() when fetching default curves. The TUF method requires at least 32 bytes space. This also moves and changes the pr_debug() in fan_curve_check_present() to pr_warn() in fan_curve_get_factory_default() so that there is at least some indication in logs of why it fails. Signed-off-by:
Luke D. Jones <luke@ljones.dev> Link: https://lore.kernel.org/r/20220828074638.5473-1-luke@ljones.dev Reviewed-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Hu Xiaoying authored
[ Upstream commit c61feaee ] USB external storage device(0x0b05:1932), use gnome-disk-utility tools to test usb write < 30MB/s. if does not to load module of uas for this device, can increase the write speed from 20MB/s to >40MB/s. Suggested-by:
Matthias Kaehlcke <mka@chromium.org> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Hu Xiaoying <huxiaoying@kylinos.cn> Link: https://lore.kernel.org/r/20220901045737.3438046-1-huxiaoying@kylinos.cn Signed-off-by:
-
Hans de Goede authored
[ Upstream commit c3b82d26 ] 2 keymap fixes for the Acer Aspire One AOD270 and the same hardware rebranded as Packard Bell Dot SC: 1. The F2 key is marked with a big '?' symbol on the Packard Bell Dot SC, this sends WMID_HOTKEY_EVENTs with a scancode of 0x27 add a mapping for this. 2. Scancode 0x61 is KEY_SWITCHVIDEOMODE. Usually this is a duplicate input event with the "Video Bus" input device events. But on these devices the "Video Bus" does not send events for this key. Map 0x61 to KEY_UNKNOWN instead of using KE_IGNORE so that udev/hwdb can override it on these devs. Signed-off-by:
-
Yu Zhe authored
[ Upstream commit 6bb0d64c ] The platform_get_irq() returns negative error codes. It can't actually return zero. Signed-off-by:
Yu Zhe <yuzhe@nfschina.com> Link: https://lore.kernel.org/r/20220825011844.8536-1-yuzhe@nfschina.com Signed-off-by:
Will Deacon <will@kernel.org> Signed-off-by:
-
Kurt Kanzenbach authored
[ Upstream commit 52267ce2 ] In case the source port cannot be decoded, print the warning only once. This still brings attention to the user and does not spam the logs at the same time. Signed-off-by:
Kurt Kanzenbach <kurt@linutronix.de> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Reviewed-by:
Vladimir Oltean <olteanv@gmail.com> Link: https://lore.kernel.org/r/20220830163448.8921-1-kurt@linutronix.de Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
-
Chengming Gui authored
[ Upstream commit 39c84b8e ] Restrict the ucode loading check to avoid frontdoor loading error. Signed-off-by:
Chengming Gui <Jack.Gui@amd.com> Reviewed-by:
Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Maurizio Lombardi authored
[ Upstream commit 478814a5 ] TCP_FIN_WAIT2 and TCP_LAST_ACK were not handled, the connection is closing so we can ignore them and avoid printing the "unhandled state" warning message. [ 1298.852386] nvmet_tcp: queue 2 unhandled state 5 [ 1298.879112] nvmet_tcp: queue 7 unhandled state 5 [ 1298.884253] nvmet_tcp: queue 8 unhandled state 5 [ 1298.889475] nvmet_tcp: queue 9 unhandled state 5 v2: Do not call nvmet_tcp_schedule_release_queue(), just ignore the fin_wait2 and last_ack states. Signed-off-by:
Maurizio Lombardi <mlombard@redhat.com> Reviewed-by:
Sagi Grimberg <sagi@grimberg.me> Reviewed-by:
Chaitanya Kulkarni <kch@nvidia.com> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Shyamin Ayesh authored
[ Upstream commit 200dccd0 ] Lexar NM610 reports bogus eui64 values that appear to be the same across all drives. Quirk them out so they are not marked as "non globally unique" duplicates. Signed-off-by:
Shyamin Ayesh <me@shyamin.com> [patch formatting] Signed-off-by:
Keith Busch <kbusch@kernel.org> Signed-off-by:
-
Evan Quan authored
[ Upstream commit b0230535 ] For those SMU13.0.7 unsecure SKUs, the vbios carried pptable is ready to go. Use that one instead of hardcoded softpptable. Signed-off-by:
Evan Quan <evan.quan@amd.com> Reviewed-by:
Kenneth Feng <kenneth.feng@amd.com> Signed-off-by:
-
Guchun Chen authored
[ Upstream commit c8fea927 ] Below driver load error will be printed, not friendly to end user. amdgpu: ATOM BIOS: 113-D603GLXE-077 [drm] FRU: Failed to get size field [drm:amdgpu_fru_get_product_info [amdgpu]] *ERROR* Failed to read FRU Manufacturer, ret:-5 Signed-off-by:
Guchun Chen <guchun.chen@amd.com> Reviewed-by:
Kent Russell <kent.russell@amd.com> Signed-off-by:
-
Greg Tulli authored
[ Upstream commit 9c9c7116 ] Add a new iforce_device entry to support the Boeder Force Feedback Wheel device. Signed-off-by:
Greg Tulli <greg.iforce@gmail.com> Link: https://lore.kernel.org/r/3256420-c8ac-31b-8499-3c488a9880fd@gmail.com Signed-off-by:
-
Li Qiong authored
[ Upstream commit ffd7bddd ] The rc code is 0 at the error path "status & CC2520_STATUS_TX_UNDERFLOW". Assign rc code with '-EINVAL' at this error path to fix it. Signed-off-by:
Li Qiong <liqiong@nfschina.com> Link: https://lore.kernel.org/r/20220829071259.18330-1-liqiong@nfschina.com Signed-off-by:
Stefan Schmidt <stefan@datenfreihafen.org> Signed-off-by:
-
Wei Yongjun authored
[ Upstream commit 303e6da9 ] GPIO mockup debugfs is created in gpio_mockup_probe() but forgot to remove when remove device. This patch add a devm managed callback for removing them. Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by:
-
Jean-Francois Le Fillatre authored
[ Upstream commit 1bd3a383 ] The Lenovo OneLink+ Dock contains an RTL8153 controller that behaves as a broken CDC device by default. Add the custom Lenovo PID to the r8152 driver to support it properly. Also, systems compatible with this dock provide a BIOS option to enable MAC address passthrough (as per Lenovo document "ThinkPad Docking Solutions 2017"). Add the custom PID to the MAC passthrough list too. Tested on a ThinkPad 13 1st gen with the expected results: passthrough disabled: Invalid header when reading pass-thru MAC addr passthrough enabled: Using pass-thru MAC addr XX:XX:XX:XX:XX:XX Signed-off-by:
Jean-Francois Le Fillatre <jflf_kernel@gmx.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Kai-Heng Feng authored
[ Upstream commit 2ca1c94c ] Commit d60cd063 ("PM: ACPI: reboot: Use S5 for reboot") caused a reboot hang on one Dell servers so the commit was reverted. Someone managed to collect the AER log and it's caused by MSI: [ 148.762067] ACPI: Preparing to enter system sleep state S5 [ 148.794638] {1}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 5 [ 148.803731] {1}[Hardware Error]: event severity: recoverable [ 148.810191] {1}[Hardware Error]: Error 0, type: fatal [ 148.816088] {1}[Hardware Error]: section_type: PCIe error [ 148.822391] {1}[Hardware Error]: port_type: 0, PCIe end point [ 148.829026] {1}[Hardware Error]: version: 3.0 [ 148.834266] {1}[Hardware Error]: command: 0x0006, status: 0x0010 [ 148.841140] {1}[Hardware Error]: device_id: 0000:04:00.0 [ 148.847309] {1}[Hardware Error]: slot: 0 [ 148.852077] {1}[Hardware Error]: secondary_bus: 0x00 [ 148.857876] {1}[Hardware Error]: vendor_id: 0x14e4, device_id: 0x165f [ 148.865145] {1}[Hardware Error]: class_code: 020000 [ 148.870845] {1}[Hardware Error]: aer_uncor_status: 0x00100000, aer_uncor_mask: 0x00010000 [ 148.879842] {1}[Hardware Error]: aer_uncor_severity: 0x000ef030 [ 148.886575] {1}[Hardware Error]: TLP Header: 40000001 0000030f 90028090 00000000 [ 148.894823] tg3 0000:04:00.0: AER: aer_status: 0x00100000, aer_mask: 0x00010000 [ 148.902795] tg3 0000:04:00.0: AER: [20] UnsupReq (First) [ 148.910234] tg3 0000:04:00.0: AER: aer_layer=Transaction Layer, aer_agent=Requester ID [ 148.918806] tg3 0000:04:00.0: AER: aer_uncor_severity: 0x000ef030 [ 148.925558] tg3 0000:04:00.0: AER: TLP Header: 40000001 0000030f 90028090 00000000 The MSI is probably raised by incoming packets, so power down the device and disable bus mastering to stop the traffic, as user confirmed this approach works. In addition to that, be extra safe and cancel reset task if it's running. Cc: Josef Bacik <josef@toxicpanda.com> Link: https://lore.kernel.org/all/b8db79e6857c41dab4ef08bdf826ea7c47e3bafc.1615947283.git.josef@toxicpanda.com/ BugLink: https://bugs.launchpad.net/bugs/1917471 Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Reviewed-by:
Michael Chan <michael.chan@broadcom.com> Link: https://lore.kernel.org/r/20220826002530.1153296-1-kai.heng.feng@canonical.com Signed-off-by:
-
Luiz Augusto von Dentz authored
[ Upstream commit 23b72814 ] Get Device Flags don't check if device does actually use an RPA in which case it shall only set HCI_CONN_FLAG_REMOTE_WAKEUP if LL Privacy is enabled. Signed-off-by:
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by:
-
Even Xu authored
[ Upstream commit e1fa0767 ] There is a timing issue captured during ishtp client sending stress tests. It was observed during stress tests that ISH firmware is getting out of ordered messages. This is a rare scenario as the current set of ISH client drivers don't send much data to firmware. But this may not be the case going forward. When message size is bigger than IPC MTU, ishtp splits the message into fragments and uses serialized async method to send message fragments. The call stack: ishtp_cl_send_msg_ipc->ipc_tx_callback(first fregment)-> ishtp_send_msg(with callback)->write_ipc_to_queue-> write_ipc_from_queue->callback->ipc_tx_callback(next fregment)...... When an ipc write complete interrupt is received, driver also calls write_ipc_from_queue->ipc_tx_callback in ISR to start sending of next fragment. Through ipc_tx_callback uses spin_lock to protect message splitting, as the serialized sending method will call back to ipc_tx_callback again, so it doesn't put sending under spin_lock, it causes driver cannot guarantee all fragments be sent in order. Considering this scenario: ipc_tx_callback just finished a fragment splitting, and not call ishtp_send_msg yet, there is a write complete interrupt happens, then ISR->write_ipc_from_queue ->ipc_tx_callback->ishtp_send_msg->write_ipc_to_queue...... Because ISR has higher exec priority than normal thread, this causes the new fragment be sent out before previous fragment. This disordered message causes invalid message to firmware. The solution is, to send fragments synchronously: Use ishtp_write_message writing fragments into tx queue directly one by one, instead of ishtp_send_msg only writing one fragment with completion callback. As no completion callback be used, so change ipc_tx_callback to ipc_tx_send. Signed-off-by:
Even Xu <even.xu@intel.com> Acked-by:
Srinivas Pandruvada <srinivas.pandruvada@intel.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Jason Wang authored
[ Upstream commit 94553f8a ] The double `like' is duplicated in the comment, remove one. Signed-off-by:
Jason Wang <wangborong@cdjrlc.com> Signed-off-by:
-
Krzysztof Kozlowski authored
[ Upstream commit 76747020 ] BMG160 has two interrupt pins to which interrupts can be freely mapped. Correct the schema to express such case and fix warnings like: qcom/msm8916-alcatel-idol347.dtb: gyroscope@68: interrupts: [[97, 1], [98, 1]] is too long However the basic issue still persists - the interrupts should come in a defined order. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20220805075503.16983-1-krzysztof.kozlowski@linaro.org Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
-
Junaid Shahid authored
[ Upstream commit b64d740e ] When A/D bits are not available, KVM uses a software access tracking mechanism, which involves making the SPTEs inaccessible. However, the clear_young() MMU notifier does not flush TLBs. So it is possible that there may still be stale, potentially writable, TLB entries. This is usually fine, but can be problematic when enabling dirty logging, because it currently only does a TLB flush if any SPTEs were modified. But if all SPTEs are in access-tracked state, then there won't be a TLB flush, which means that the guest could still possibly write to memory and not have it reflected in the dirty bitmap. So just unconditionally flush the TLBs when enabling dirty logging. As an alternative, KVM could explicitly check the MMU-Writable bit when write-protecting SPTEs to decide if a flush is needed (instead of checking the Writable bit), but given that a flush almost always happens anyway, so just making it unconditional seems simpler. Signed-off-by:
Junaid Shahid <junaids@google.com> Message-Id: <20220810224939.2611160-1-junaids@google.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
Iwona Winiarska authored
[ Upstream commit 1c11289b ] When auxiliary_device_add() returns an error, auxiliary_device_uninit() is called, which causes refcount for device to be decremented and .release callback will be triggered. Because adev_release() re-calls auxiliary_device_uninit(), it will cause use-after-free: [ 1269.455172] WARNING: CPU: 0 PID: 14267 at lib/refcount.c:28 refcount_warn_saturate+0x110/0x15 [ 1269.464007] refcount_t: underflow; use-after-free. Reported-by:
Jianglei Nie <niejianglei2021@163.com> Signed-off-by:
Iwona Winiarska <iwona.winiarska@intel.com> Link: https://lore.kernel.org/r/20220705101501.298395-1-iwona.winiarska@intel.com Signed-off-by:
-
Rob Clark authored
[ Upstream commit 174974d8 ] If the previous thing cat'ing $debugfs/rd left the FIFO full, then subsequent open could deadlock in rd_write() (because open is blocked, not giving a chance for read() to consume any data in the FIFO). Also it is generally a good idea to clear out old data from the FIFO. Signed-off-by:
Rob Clark <robdclark@chromium.org> Patchwork: https://patchwork.freedesktop.org/patch/496706/ Link: https://lore.kernel.org/r/20220807160901.2353471-2-robdclark@gmail.com Signed-off-by:
-
Maximilian Luz authored
[ Upstream commit 84b8e403 ] The Surface Laptop Go 2 seems to have the same SAM client devices as the Surface Laptop Go 1, so re-use its node group. Signed-off-by:
Maximilian Luz <luzmaximilian@gmail.com> Link: https://lore.kernel.org/r/20220810140133.99087-1-luzmaximilian@gmail.com Signed-off-by:
-
Ondrej Jirman authored
[ Upstream commit 425fe470 ] This controller is used by PinePhone and PinePhone Pro. Support for the PinePhone Pro will be added in a later patch set. Signed-off-by:
Ondrej Jirman <megi@xff.cz> Signed-off-by:
-
Chuanhong Guo authored
commit 9946e39f upstream. IRQ override isn't needed on modern AMD Zen systems. There's an active low keyboard IRQ on AMD Ryzen 6000 and it will stay this way on newer platforms. This IRQ override breaks keyboards for almost all Ryzen 6000 laptops currently on the market. Skip this IRQ override for all AMD Zen platforms because this IRQ override is supposed to be a workaround for buggy ACPI DSDT and we can't have a long list of all future AMD CPUs/Laptops in the kernel code. If a device with buggy ACPI DSDT shows up, a separated list containing just them should be created. Link: https://bugzilla.kernel.org/show_bug.cgi?id=216118 Suggested-by:
Mario Limonciello <mario.limonciello@amd.com> Signed-off-by:
Chuanhong Guo <gch981213@gmail.com> Acked-by:
XiaoYan Li <lxy.lixiaoyan@gmail.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Maor Gottlieb authored
[ Upstream commit 9b7d4be9 ] The cited commit removed from the cleanup flow of umr the checks if the resources were created. This could lead to null-ptr-deref in case that we had failure in mlx5_ib_stage_ib_reg_init stage. Fix it by adding new state to the umr that can say if the resources were created or not and check it in the umr cleanup flow before destroying the resources. Fixes: 04876c12 ("RDMA/mlx5: Move init and cleanup of UMR to umr.c") Reviewed-by:
Michael Guralnik <michaelgur@nvidia.com> Signed-off-by:
Maor Gottlieb <maorg@nvidia.com> Link: https://lore.kernel.org/r/4cfa61386cf202e9ce330e8d228ce3b25a36326e.1661763459.git.leonro@nvidia.com Signed-off-by:
-
Aharon Landau authored
[ Upstream commit 158e71bb ] When a UMR fails, the UMR QP state changes to an error state. Therefore, all the further UMR operations will fail too. Add a recovery flow to the UMR QP, and repost the flushed WQEs. Link: https://lore.kernel.org/r/6cc24816cca049bd8541317f5e41d3ac659445d3.1652588303.git.leonro@nvidia.com Signed-off-by:
Aharon Landau <aharonl@nvidia.com> Reviewed-by:
-
Maher Sanalla authored
[ Upstream commit 9ca05b0f ] When the RDMA auxiliary driver probes, it sets its profile based on devlink driverinit value. The latter might not be in sync with FW yet (In case devlink reload is not performed), thus causing a mismatch between RDMA driver and FW. This results in the following FW syndrome when the RDMA driver tries to adjust RoCE state, which fails the probe: "0xC1F678 | modify_nic_vport_context: roce_en set on a vport that doesn't support roce" To prevent this, select the PF profile based on FW RoCE capability instead of relying on devlink driverinit value. To provide backward compatibility of the RoCE disable feature, on older FW's where roce_rw is not set (FW RoCE capability is read-only), keep the current behavior e.g., rely on devlink driverinit value. Fixes: fbfa97b4 ("net/mlx5: Disable roce at HCA level") Reviewed-by:
Shay Drory <shayd@nvidia.com> Reviewed-by:
Saeed Mahameed <saeedm@nvidia.com> Signed-off-by:
Maher Sanalla <msanalla@nvidia.com> Link: https://lore.kernel.org/r/cb34ce9a1df4a24c135cb804db87f7d2418bd6cc.1661763459.git.leonro@nvidia.com Signed-off-by:
-
Yishai Hadas authored
[ Upstream commit dc402ccc ] Use software VHCA id when it's supported by the firmware. A unique id is allocated upon mlx5_mdev_init() and freed upon mlx5_mdev_uninit(), as such it stays the same during the full life cycle of the device including upon health recovery if occurred. The conjunction of sw_vhca_id with sw_owner_id will be a global unique id per function which uses mlx5_core. The sw_vhca_id is set upon init_hca command and is used to specify the VHCA that the NIC vport is affiliated with. This functionality is needed upon migration of VM which is MPV based. (i.e. multi port device). Signed-off-by:
Yishai Hadas <yishaih@nvidia.com> Reviewed-by:
Mark Bloch <mbloch@nvidia.com> Signed-off-by:
-
Yishai Hadas authored
[ Upstream commit 0372c546 ] Introduce ifc related stuff to enable using software vhca id functionality. Signed-off-by:
-
Lu Baolu authored
[ Upstream commit 0c5f6c0d ] The translation table copying code for kdump kernels is currently based on the extended root/context entry formats of ECS mode defined in older VT-d v2.5, and doesn't handle the scalable mode formats. This causes the kexec capture kernel boot failure with DMAR faults if the IOMMU was enabled in scalable mode by the previous kernel. The ECS mode has already been deprecated by the VT-d spec since v3.0 and Intel IOMMU driver doesn't support this mode as there's no real hardware implementation. Hence this converts ECS checking in copying table code into scalable mode. The existing copying code consumes a bit in the context entry as a mark of copied entry. It needs to work for the old format as well as for the extended context entries. As it's hard to find such a common bit for both legacy and scalable mode context entries. This replaces it with a per- IOMMU bitmap. Fixes: 7373a8cc ("iommu/vt-d: Setup context and enable RID2PASID support") Cc: stable@vger.kernel.org Reported-by:
Jerry Snitselaar <jsnitsel@redhat.com> Tested-by:
Wen Jin <wen.jin@intel.com> Signed-off-by:
Lu Baolu <baolu.lu@linux.intel.com> Link: https://lore.kernel.org/r/20220817011035.3250131-1-baolu.lu@linux.intel.com Signed-off-by:
Joerg Roedel <jroedel@suse.de> Signed-off-by:
-
- Sep 15, 2022
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20220913140410.043243217@linuxfoundation.org Tested-by:
Linux Kernel Functional Testing <lkft@linaro.org> Tested-by:
Jiri Slaby <jirislaby@kernel.org> Signed-off-by:
-
Saaem Rizvi authored
commit 149f6d1a 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: c1b972a1 ("drm/amd/display: Insert pulling smu busy status before sending another request") Reviewed-by:
Gabe Teeger <Gabe.Teeger@amd.com> Acked-by:
Solomon Chiu <solomon.chiu@amd.com> Signed-off-by:
Saaem Rizvi <SyedSaaem.Rizvi@amd.com> Tested-by:
Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by:
-
