summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-10-08bpf, lsm: Remove bpf_lsm_key_free hookThomas Weißschuh
The key_free LSM hook has been removed. Remove the corresponding BPF hook. Avoid warnings during the build: BTFIDS vmlinux WARN: resolve_btfids: unresolved symbol bpf_lsm_key_free Fixes: 5f8d28f6d7d5 ("lsm: infrastructure management of the key security blob") Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: Song Liu <song@kernel.org> Acked-by: Jiri Olsa <jolsa@kernel.org> Link: https://lore.kernel.org/bpf/20241005-lsm-key_free-v1-1-42ea801dbd63@weissschuh.net
2024-10-08fbdev: Switch back to struct platform_driver::remove()Uwe Kleine-König
After commit 0edb555a65d1 ("platform: Make platform_driver::remove() return void") .remove() is (again) the right callback to implement for platform drivers. Convert all platform drivers below drivers/video/fbdev to use .remove(), with the eventual goal to drop struct platform_driver::remove_new(). As .remove() and .remove_new() have the same prototypes, conversion is done by just changing the structure member name in the driver initializer. While touching these files, make indention of the struct initializer consistent in several files. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Helge Deller <deller@gmx.de>
2024-10-08thermal: intel: int340x: processor: Add MMIO RAPL PL4 supportZhang Rui
Similar to the MSR RAPL interface, MMIO RAPL supports PL4 too, so add MMIO RAPL PL4d support to the processor_thermal driver. As a result, the powercap sysfs for MMIO RAPL will show a new "peak power" constraint. Signed-off-by: Zhang Rui <rui.zhang@intel.com> Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://patch.msgid.link/20240930081801.28502-7-rui.zhang@intel.com [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-10-08thermal: intel: int340x: processor: Remove MMIO RAPL CPU hotplug supportZhang Rui
CPU0/package0 is always online and the MMIO RAPL driver runs on single package systems only, so there is no need to handle CPU hotplug in it. Always register a RAPL package device for package 0 and remove the unnecessary CPU hotplug support. Signed-off-by: Zhang Rui <rui.zhang@intel.com> Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://patch.msgid.link/20240930081801.28502-6-rui.zhang@intel.com [ rjw: Subject edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-10-08powercap: intel_rapl_msr: Add PL4 support for Arrowlake-USumeet Pawnikar
Add PL4 support for ArrowLake-U platform. Signed-off-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com> Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://patch.msgid.link/20240930081801.28502-5-rui.zhang@intel.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-10-08powercap: intel_rapl_tpmi: Ignore minor version changeZhang Rui
The hardware definition of every TPMI feature contains a major and minor version. When there is a change in the MMIO offset or change in the definition of a field, hardware will change major version. For addition of new fields without modifying existing MMIO offsets or fields, only the minor version is changed. If the driver has not been updated to recognize a new hardware major version, it cannot provide the RAPL interface to users due to possible register layout incompatibilities. However, the driver does not need to be updated every time the hardware minor version changes because in that case it will just miss some new functionality exposed by the hardware. The current implementation causes the driver to refuse to work for any hardware version change which is unnecessarily restrictive. If there is a minor version mismatch, log an information message and continue, but if there is a major version mismatch, log a warning and exit (as before). Signed-off-by: Zhang Rui <rui.zhang@intel.com> Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://patch.msgid.link/20240930081801.28502-4-rui.zhang@intel.com Fixes: 9eef7f9da928 ("powercap: intel_rapl: Introduce RAPL TPMI interface driver") [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-10-08x86/resctrl: Annotate get_mem_config() functions as __initNathan Chancellor
After a recent LLVM change [1] that deduces __cold on functions that only call cold code (such as __init functions), there is a section mismatch warning from __get_mem_config_intel(), which got moved to .text.unlikely. as a result of that optimization: WARNING: modpost: vmlinux: section mismatch in reference: \ __get_mem_config_intel+0x77 (section: .text.unlikely.) -> thread_throttle_mode_init (section: .init.text) Mark __get_mem_config_intel() as __init as well since it is only called from __init code, which clears up the warning. While __rdt_get_mem_config_amd() does not exhibit a warning because it does not call any __init code, it is a similar function that is only called from __init code like __get_mem_config_intel(), so mark it __init as well to keep the code symmetrical. CONFIG_SECTION_MISMATCH_WARN_ONLY=n would turn this into a fatal error. Fixes: 05b93417ce5b ("x86/intel_rdt/mba: Add primary support for Memory Bandwidth Allocation (MBA)") Fixes: 4d05bf71f157 ("x86/resctrl: Introduce AMD QOS feature") Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com> Cc: <stable@kernel.org> Link: https://github.com/llvm/llvm-project/commit/6b11573b8c5e3d36beee099dbe7347c2a007bf53 [1] Link: https://lore.kernel.org/r/20240917-x86-restctrl-get_mem_config_intel-init-v3-1-10d521256284@kernel.org
2024-10-08sched_ext: Documentation: Update instructions for running example schedulersDevaansh-Kumar
Since the artifact paths for tools changed, we need to update the documentation to reflect that path. Signed-off-by: Devaansh-Kumar <devaanshk840@gmail.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2024-10-08Merge tag 'ntfs3_for_6.12' of ↵Linus Torvalds
https://github.com/Paragon-Software-Group/linux-ntfs3 Pull ntfs3 updates from Konstantin Komarov: "New: - implement fallocate for compressed files - add support for the compression attribute - optimize large writes to sparse files Fixes: - fix several potential deadlock scenarios - fix various internal bugs detected by syzbot - add checks before accessing NTFS structures during parsing - correct the format of output messages Refactoring: - replace fsparam_flag_no with fsparam_flag in options parser - remove unused functions and macros" * tag 'ntfs3_for_6.12' of https://github.com/Paragon-Software-Group/linux-ntfs3: (25 commits) fs/ntfs3: Format output messages like others fs in kernel fs/ntfs3: Additional check in ntfs_file_release fs/ntfs3: Fix general protection fault in run_is_mapped_full fs/ntfs3: Sequential field availability check in mi_enum_attr() fs/ntfs3: Additional check in ni_clear() fs/ntfs3: Fix possible deadlock in mi_read ntfs3: Change to non-blocking allocation in ntfs_d_hash fs/ntfs3: Remove unused al_delete_le fs/ntfs3: Rename ntfs3_setattr into ntfs_setattr fs/ntfs3: Replace fsparam_flag_no -> fsparam_flag fs/ntfs3: Add support for the compression attribute fs/ntfs3: Implement fallocate for compressed files fs/ntfs3: Make checks in run_unpack more clear fs/ntfs3: Add rough attr alloc_size check fs/ntfs3: Stale inode instead of bad fs/ntfs3: Refactor enum_rstbl to suppress static checker fs/ntfs3: Fix sparse warning in ni_fiemap fs/ntfs3: Fix warning possible deadlock in ntfs_set_state fs/ntfs3: Fix sparse warning for bigendian fs/ntfs3: Separete common code for file_read/write iter/splice ...
2024-10-08Merge tag 'perf-tools-fixes-for-v6.12-1-2024-10-08' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools Pull perf tools fixes from Arnaldo Carvalho de Melo: - Fix an assert() to handle captured and unprocessed ARM CoreSight CPU traces - Fix static build compilation error when libdw isn't installed or is too old - Add missing include when building with !HAVE_DWARF_GETLOCATIONS_SUPPORT - Add missing refcount put on 32-bit DSOs - Fix disassembly of user space binaries by setting the binary_type of DSO when loading - Update headers with the kernel sources, including asound.h, sched.h, fcntl, msr-index.h, irq_vectors.h, socket.h, list_sort.c and arm64's cputype.h * tag 'perf-tools-fixes-for-v6.12-1-2024-10-08' of git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools: perf cs-etm: Fix the assert() to handle captured and unprocessed cpu trace perf build: Fix build feature-dwarf_getlocations fail for old libdw perf build: Fix static compilation error when libdw is not installed perf dwarf-aux: Fix build with !HAVE_DWARF_GETLOCATIONS_SUPPORT tools headers arm64: Sync arm64's cputype.h with the kernel sources perf tools: Cope with differences for lib/list_sort.c copy from the kernel tools check_headers.sh: Add check variant that excludes some hunks perf beauty: Update copy of linux/socket.h with the kernel sources tools headers UAPI: Sync the linux/in.h with the kernel sources perf trace beauty: Update the arch/x86/include/asm/irq_vectors.h copy with the kernel sources tools arch x86: Sync the msr-index.h copy with the kernel sources tools include UAPI: Sync linux/fcntl.h copy with the kernel sources tools include UAPI: Sync linux/sched.h copy with the kernel sources tools include UAPI: Sync sound/asound.h copy with the kernel sources perf vdso: Missed put on 32-bit dsos perf symbol: Set binary_type of dso when loading
2024-10-08iommu/arm-smmu-v3: Convert comma to semicolonChen Ni
Replace comma between expressions with semicolons. Using a ',' in place of a ';' can have unintended side effects. Although that is not the case here, it is seems best to use ';' unless ',' is intended. Found by inspection. No functional change intended. Compile tested only. Fixes: e3b1be2e73db ("iommu/arm-smmu-v3: Reorganize struct arm_smmu_ctx_desc_cfg") Signed-off-by: Chen Ni <nichen@iscas.ac.cn> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Link: https://lore.kernel.org/r/20240923021557.3432068-1-nichen@iscas.ac.cn Signed-off-by: Will Deacon <will@kernel.org>
2024-10-08iommu/arm-smmu-v3: Fix last_sid_idx calculation for sid_bits==32Daniel Mentz
The function arm_smmu_init_strtab_2lvl uses the expression ((1 << smmu->sid_bits) - 1) to calculate the largest StreamID value. However, this fails for the maximum allowed value of SMMU_IDR1.SIDSIZE which is 32. The C standard states: "If the value of the right operand is negative or is greater than or equal to the width of the promoted left operand, the behavior is undefined." With smmu->sid_bits being 32, the prerequisites for undefined behavior are met. We observed that the value of (1 << 32) is 1 and not 0 as we initially expected. Similar bit shift operations in arm_smmu_init_strtab_linear seem to not be affected, because it appears to be unlikely for an SMMU to have SMMU_IDR1.SIDSIZE set to 32 but then not support 2-level Stream tables This issue was found by Ryan Huang <tzukui@google.com> on our team. Fixes: ce410410f1a7 ("iommu/arm-smmu-v3: Add arm_smmu_strtab_l1/2_idx()") Signed-off-by: Daniel Mentz <danielmentz@google.com> Link: https://lore.kernel.org/r/20241002015357.1766934-1-danielmentz@google.com Signed-off-by: Will Deacon <will@kernel.org>
2024-10-08iommu/arm-smmu: Clarify MMU-500 CPRE workaroundRobin Murphy
CPRE workarounds are implicated in at least 5 MMU-500 errata, some of which remain unfixed. The comment and warning message have proven to be unhelpfully misleading about this scope, so reword them to get the point across with less risk of going out of date or confusing users. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Link: https://lore.kernel.org/r/dfa82171b5248ad7cf1f25592101a6eec36b8c9a.1728400877.git.robin.murphy@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2024-10-08irqchip/sifive-plic: Unmask interrupt in plic_irq_enable()Nam Cao
It is possible that an interrupt is disabled and masked at the same time. When the interrupt is enabled again by enable_irq(), only plic_irq_enable() is called, not plic_irq_unmask(). The interrupt remains masked and never raises. An example where interrupt is both disabled and masked is when handle_fasteoi_irq() is the handler, and IRQS_ONESHOT is set. The interrupt handler: 1. Mask the interrupt 2. Handle the interrupt 3. Check if interrupt is still enabled, and unmask it (see cond_unmask_eoi_irq()) If another task disables the interrupt in the middle of the above steps, the interrupt will not get unmasked, and will remain masked when it is enabled in the future. The problem is occasionally observed when PREEMPT_RT is enabled, because PREEMPT_RT adds the IRQS_ONESHOT flag. But PREEMPT_RT only makes the problem more likely to appear, the bug has been around since commit a1706a1c5062 ("irqchip/sifive-plic: Separate the enable and mask operations"). Fix it by unmasking interrupt in plic_irq_enable(). Fixes: a1706a1c5062 ("irqchip/sifive-plic: Separate the enable and mask operations") Signed-off-by: Nam Cao <namcao@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/20241003084152.2422969-1-namcao@linutronix.de
2024-10-08irqchip/gic-v4: Don't allow a VMOVP on a dying VPEMarc Zyngier
Kunkun Jiang reported that there is a small window of opportunity for userspace to force a change of affinity for a VPE while the VPE has already been unmapped, but the corresponding doorbell interrupt still visible in /proc/irq/. Plug the race by checking the value of vmapp_count, which tracks whether the VPE is mapped ot not, and returning an error in this case. This involves making vmapp_count common to both GICv4.1 and its v4.0 ancestor. Fixes: 64edfaa9a234 ("irqchip/gic-v4.1: Implement the v4.1 flavour of VMAPP") Reported-by: Kunkun Jiang <jiangkunkun@huawei.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/c182ece6-2ba0-ce4f-3404-dba7a3ab6c52@huawei.com Link: https://lore.kernel.org/all/20241002204959.2051709-1-maz@kernel.org
2024-10-08selftests: make kselftest-clean remove libynl outputsGreg Thelen
Starting with 6.12 commit 85585b4bc8d8 ("selftests: add ncdevmem, netcat for devmem TCP") kselftest-all creates additional outputs that kselftest-clean does not cleanup: $ make defconfig $ make kselftest-all $ make kselftest-clean $ git clean -ndxf | grep tools/net Would remove tools/net/ynl/lib/__pycache__/ Would remove tools/net/ynl/lib/ynl.a Would remove tools/net/ynl/lib/ynl.d Would remove tools/net/ynl/lib/ynl.o Make kselftest-clean remove the newly added net/ynl outputs. Fixes: 85585b4bc8d8 ("selftests: add ncdevmem, netcat for devmem TCP") Signed-off-by: Greg Thelen <gthelen@google.com> Reviewed-by: Muhammad Usama Anjum <usama.anjum@collabora.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Link: https://patch.msgid.link/20241005215600.852260-1-gthelen@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-08Merge branch 'selftests-net-add-missing-gitignore-and-extra_clean-entries'Jakub Kicinski
Javier Carrasco says: ==================== selftests: net: add missing gitignore and EXTRA_CLEAN entries. This series is a cherry-pick on top of v6.12-rc1 from the one I sent for selftests with other patches that were not net-related: https://lore.kernel.org/all/20240925-selftests-gitignore-v3-0-9db896474170@gmail.com/ The patches have not been modified, and the Reviewed-by tags have been kept. v1: https://lore.kernel.org/20240930-net-selftests-gitignore-v1-0-65225a855946@gmail.com ==================== Link: https://patch.msgid.link/20241005-net-selftests-gitignore-v2-0-3a0b2876394a@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-08selftests: net: rds: add gitignore file for include.shJavier Carrasco
The generated include.sh should be ignored by git. Create a new gitignore and add the file to the list. Reviewed-by: Allison Henderson <allison.henderson@oracle.com> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> Link: https://patch.msgid.link/20241005-net-selftests-gitignore-v2-3-3a0b2876394a@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-08selftests: net: rds: add include.sh to EXTRA_CLEANJavier Carrasco
The include.sh file is generated when building the net/rds selftests, but there is no rule to delete it with the clean target. Add the file to EXTRA_CLEAN in order to remove it when required. Reviewed-by: Allison Henderson <allison.henderson@oracle.com> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> Link: https://patch.msgid.link/20241005-net-selftests-gitignore-v2-2-3a0b2876394a@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-08selftests: net: add msg_oob to gitignoreJavier Carrasco
This executable is missing from the corresponding gitignore file. Add msg_oob to the net gitignore list. Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> Link: https://patch.msgid.link/20241005-net-selftests-gitignore-v2-1-3a0b2876394a@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-08x86/xen: mark boot CPU of PV guest in MSR_IA32_APICBASEJuergen Gross
Recent topology checks of the x86 boot code uncovered the need for PV guests to have the boot cpu marked in the APICBASE MSR. Fixes: 9d22c96316ac ("x86/topology: Handle bogus ACPI tables correctly") Reported-by: Niels Dettenbach <nd@syndicat.com> Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Juergen Gross <jgross@suse.com>
2024-10-08drm/radeon: always set GEM function pointerChristian König
Make sure to always set the GEM function pointer even for in kernel allocations. This fixes a NULL pointer deref caused by switching to GEM references. Signed-off-by: Christian König <christian.koenig@amd.com> Fixes: fd69ef05029f ("drm/radeon: use GEM references instead of TTMs") Acked-by: Alex Deucher <alexander.deucher@amd.com> Tested-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 01b64bc063d014641631867a7e0edd8ac55282d4)
2024-10-08x86/resctrl: Avoid overflow in MB settings in bw_validate()Martin Kletzander
The resctrl schemata file supports specifying memory bandwidth associated with the Memory Bandwidth Allocation (MBA) feature via a percentage (this is the default) or bandwidth in MiBps (when resctrl is mounted with the "mba_MBps" option). The allowed range for the bandwidth percentage is from /sys/fs/resctrl/info/MB/min_bandwidth to 100, using a granularity of /sys/fs/resctrl/info/MB/bandwidth_gran. The supported range for the MiBps bandwidth is 0 to U32_MAX. There are two issues with parsing of MiBps memory bandwidth: * The user provided MiBps is mistakenly rounded up to the granularity that is unique to percentage input. * The user provided MiBps is parsed using unsigned long (thus accepting values up to ULONG_MAX), and then assigned to u32 that could result in overflow. Do not round up the MiBps value and parse user provided bandwidth as the u32 it is intended to be. Use the appropriate kstrtou32() that can detect out of range values. Fixes: 8205a078ba78 ("x86/intel_rdt/mba_sc: Add schemata support") Fixes: 6ce1560d35f6 ("x86/resctrl: Switch over to the resctrl mbps_val list") Co-developed-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: Martin Kletzander <nert.pinx@gmail.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com> Reviewed-by: Tony Luck <tony.luck@intel.com>
2024-10-08gpio: aspeed: Use devm_clk api to manage clock sourceBilly Tsai
Replace of_clk_get with devm_clk_get_enabled to manage the clock source. Fixes: 5ae4cb94b313 ("gpio: aspeed: Add debounce support") Reviewed-by: Andrew Jeffery <andrew@codeconstruct.com.au> Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com> Link: https://lore.kernel.org/r/20241008081450.1490955-3-billy_tsai@aspeedtech.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-10-08gpio: aspeed: Add the flush write to ensure the write complete.Billy Tsai
Performing a dummy read ensures that the register write operation is fully completed, mitigating any potential bus delays that could otherwise impact the frequency of bitbang usage. E.g., if the JTAG application uses GPIO to control the JTAG pins (TCK, TMS, TDI, TDO, and TRST), and the application sets the TCK clock to 1 MHz, the GPIO's high/low transitions will rely on a delay function to ensure the clock frequency does not exceed 1 MHz. However, this can lead to rapid toggling of the GPIO because the write operation is POSTed and does not wait for a bus acknowledgment. Fixes: 361b79119a4b ("gpio: Add Aspeed driver") Reviewed-by: Andrew Jeffery <andrew@codeconstruct.com.au> Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com> Link: https://lore.kernel.org/r/20241008081450.1490955-2-billy_tsai@aspeedtech.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-10-08nouveau/dmem: Fix vulnerability in migrate_to_ram upon copy errorYonatan Maman
The `nouveau_dmem_copy_one` function ensures that the copy push command is sent to the device firmware but does not track whether it was executed successfully. In the case of a copy error (e.g., firmware or hardware failure), the copy push command will be sent via the firmware channel, and `nouveau_dmem_copy_one` will likely report success, leading to the `migrate_to_ram` function returning a dirty HIGH_USER page to the user. This can result in a security vulnerability, as a HIGH_USER page that may contain sensitive or corrupted data could be returned to the user. To prevent this vulnerability, we allocate a zero page. Thus, in case of an error, a non-dirty (zero) page will be returned to the user. Fixes: 5be73b690875 ("drm/nouveau/dmem: device memory helpers for SVM") Signed-off-by: Yonatan Maman <Ymaman@Nvidia.com> Co-developed-by: Gal Shalom <GalShalom@Nvidia.com> Signed-off-by: Gal Shalom <GalShalom@Nvidia.com> Reviewed-by: Ben Skeggs <bskeggs@nvidia.com> Cc: stable@vger.kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241008115943.990286-3-ymaman@nvidia.com
2024-10-08nouveau/dmem: Fix privileged error in copy engine channelYonatan Maman
When `nouveau_dmem_copy_one` is called, the following error occurs: [272146.675156] nouveau 0000:06:00.0: fifo: PBDMA9: 00000004 [HCE_PRIV] ch 1 00000300 00003386 This indicates that a copy push command triggered a Host Copy Engine Privileged error on channel 1 (Copy Engine channel). To address this issue, modify the Copy Engine channel to allow privileged push commands Fixes: 6de125383a5c ("drm/nouveau/fifo: expose runlist topology info on all chipsets") Signed-off-by: Yonatan Maman <Ymaman@Nvidia.com> Co-developed-by: Gal Shalom <GalShalom@Nvidia.com> Signed-off-by: Gal Shalom <GalShalom@Nvidia.com> Reviewed-by: Ben Skeggs <bskeggs@nvidia.com> Signed-off-by: Danilo Krummrich <dakr@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241008115943.990286-2-ymaman@nvidia.com
2024-10-08RDMA/core: Fix ENODEV error for iWARP test over vlanAnumula Murali Mohan Reddy
If traffic is over vlan, cma_validate_port() fails to match vlan net_device ifindex with bound_if_index and results in ENODEV error. It is because rdma_copy_src_l2_addr() always assigns bound_if_index with real net_device ifindex. This patch fixes the issue by assigning bound_if_index with vlan net_device index if traffic is over vlan. Fixes: f8ef1be816bf ("RDMA/cma: Avoid GID lookups on iWARP devices") Signed-off-by: Anumula Murali Mohan Reddy <anumula@chelsio.com> Signed-off-by: Potnuri Bharat Teja <bharat@chelsio.com> Link: https://patch.msgid.link/20241008114334.146702-1-anumula@chelsio.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2024-10-08Merge branch 'net-dsa-b53-assorted-jumbo-frame-fixes'Paolo Abeni
Jonas Gorski says: ==================== net: dsa: b53: assorted jumbo frame fixes While investigating the capabilities of BCM63XX's integrated switch and its DMA engine, I noticed a few issues in b53's jumbo frame code. Mostly a confusion of MTU vs frame length, but also a few missing cases for 100M switches. Tested on BCM63XX and BCM53115 with intel 1G and realtek 1G NICs, which support MTUs of 9000 or slightly above, but significantly less than the 9716/9720 supported by BCM53115, so I couldn't verify the actual maximum frame length. Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com> --- ==================== Link: https://patch.msgid.link/20241004-b53_jumbo_fixes-v1-0-ce1e54aa7b3c@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-10-08net: dsa: b53: fix jumbo frames on 10/100 portsJonas Gorski
All modern chips support and need the 10_100 bit set for supporting jumbo frames on 10/100 ports, so instead of enabling it only for 583XX enable it for everything except bcm63xx, where the bit is writeable, but does nothing. Tested on BCM53115, where jumbo frames were dropped at 10/100 speeds without the bit set. Fixes: 6ae5834b983a ("net: dsa: b53: add MTU configuration support") Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-10-08net: dsa: b53: allow lower MTUs on BCM5325/5365Jonas Gorski
While BCM5325/5365 do not support jumbo frames, they do support slightly oversized frames, so do not error out if requesting a supported MTU for them. Fixes: 6ae5834b983a ("net: dsa: b53: add MTU configuration support") Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-10-08net: dsa: b53: fix max MTU for BCM5325/BCM5365Jonas Gorski
BCM5325/BCM5365 do not support jumbo frames, so we should not report a jumbo frame mtu for them. But they do support so called "oversized" frames up to 1536 bytes long by default, so report an appropriate MTU. Fixes: 6ae5834b983a ("net: dsa: b53: add MTU configuration support") Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-10-08net: dsa: b53: fix max MTU for 1g switchesJonas Gorski
JMS_MAX_SIZE is the ethernet frame length, not the MTU, which is payload without ethernet headers. According to the datasheets maximum supported frame length for most gigabyte swithes is 9720 bytes, so convert that to the expected MTU when using VLAN tagged frames. Fixes: 6ae5834b983a ("net: dsa: b53: add MTU configuration support") Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-10-08net: dsa: b53: fix jumbo frame mtu checkJonas Gorski
JMS_MIN_SIZE is the full ethernet frame length, while mtu is just the data payload size. Comparing these two meant that mtus between 1500 and 1518 did not trigger enabling jumbo frames. So instead compare the set mtu ETH_DATA_LEN, which is equal to JMS_MIN_SIZE - ETH_HLEN - ETH_FCS_LEN; Also do a check that the requested mtu is actually greater than the minimum length, else we do not need to enable jumbo frames. In practice this only introduced a very small range of mtus that did not work properly. Newer chips allow 2000 byte large frames by default, and older chips allow 1536 bytes long, which is equivalent to an mtu of 1514. So effectivly only mtus of 1515~1517 were broken. Fixes: 6ae5834b983a ("net: dsa: b53: add MTU configuration support") Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-10-08Merge branch 'fix-ti-am65-cpsw-nuss-module-removal'Paolo Abeni
Nicolas Pitre says: ==================== fix ti-am65-cpsw-nuss module removal Fix issues preventing rmmod of ti-am65-cpsw-nuss from working properly. v3: - more patch submission minutiae v2: https://lore.kernel.org/netdev/20241003172105.2712027-2-nico@fluxnic.net/T/ - conform to netdev patch submission customs - address patch review trivias v1: https://lore.kernel.org/netdev/20240927025301.1312590-2-nico@fluxnic.net/T/ ==================== Link: https://patch.msgid.link/20241004041218.2809774-1-nico@fluxnic.net Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-10-08net: ethernet: ti: am65-cpsw: avoid devm_alloc_etherdev, fix module removalNicolas Pitre
Usage of devm_alloc_etherdev_mqs() conflicts with am65_cpsw_nuss_cleanup_ndev() as the same struct net_device instances get unregistered twice. Switch to alloc_etherdev_mqs() and make sure am65_cpsw_nuss_cleanup_ndev() unregisters and frees those net_device instances properly. With this, it is finally possible to rmmod the driver without oopsing the kernel. Fixes: 93a76530316a ("net: ethernet: ti: introduce am65x/j721e gigabit eth subsystem driver") Signed-off-by: Nicolas Pitre <npitre@baylibre.com> Reviewed-by: Roger Quadros <roger@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-10-08net: ethernet: ti: am65-cpsw: prevent WARN_ON upon module removalNicolas Pitre
In am65_cpsw_nuss_remove(), move the call to am65_cpsw_unregister_devlink() after am65_cpsw_nuss_cleanup_ndev() to avoid triggering the WARN_ON(devlink_port->type != DEVLINK_PORT_TYPE_NOTSET) in devl_port_unregister(). Makes it coherent with usage in m65_cpsw_nuss_register_ndevs()'s cleanup path. Fixes: 58356eb31d60 ("net: ti: am65-cpsw-nuss: Add devlink support") Signed-off-by: Nicolas Pitre <npitre@baylibre.com> Reviewed-by: Roger Quadros <rogerq@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-10-08ALSA: hda: Sound support for HP Spectre x360 16 inch model 2024christoph.plattner
Included solution with ALC287/CS35L41 did not cover full function, 14 inch code blocked. Forcing output for treble/bass speaker to connection 0x02, setting pin configs for LEDs and re-powering amp and calling fixups for cs35l41, mute and gpio leds was a working combination to reach correct behaviour. Signed-off-by: christoph.plattner <christoph.plattner@gmx.at> Link: https://patch.msgid.link/20241005173509.1196001-1-christoph.plattner@gmx.at Signed-off-by: Takashi Iwai <tiwai@suse.de>
2024-10-08HID: multitouch: Add quirk for HONOR MagicBook Art 14 touchpadWangYuli
The behavior of HONOR MagicBook Art 14 touchpad is not consistent after reboots, as sometimes it reports itself as a touchpad, and sometimes as a mouse. Similarly to GLO-GXXX it is possible to call MT_QUIRK_FORCE_GET_FEATURE as a workaround to force set feature in mt_set_input_mode() for such special touchpad device. [jkosina@suse.com: reword changelog a little bit] Link: https://gitlab.freedesktop.org/libinput/libinput/-/issues/1040 Signed-off-by: Wentao Guan <guanwentao@uniontech.com> Signed-off-by: WangYuli <wangyuli@uniontech.com> Reviewed-by: Benjamin Tissoires <bentiss@kernel.org> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2024-10-08RDMA/nldev: Fix NULL pointer dereferences issue in rdma_nl_notify_eventQianqiang Liu
nlmsg_put() may return a NULL pointer assigned to nlh, which will later be dereferenced in nlmsg_end(). Fixes: 9cbed5aab5ae ("RDMA/nldev: Add support for RDMA monitoring") Link: https://patch.msgid.link/r/Zva71Yf3F94uxi5A@iZbp1asjb3cy8ks0srf007Z Signed-off-by: Qianqiang Liu <qianqiang.liu@163.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Leon Romanovsky <leon@kernel.org>
2024-10-08RDMA/bnxt_re: Fix the max WQEs used in Static WQE modeSelvin Xavier
max_sw_wqe used for static wqe mode should be same as the max_wqe. Calculate the max_sw_wqe only for the variable WQE mode. Fixes: de1d364c3815 ("RDMA/bnxt_re: Add support for Variable WQE in Genp7 adapters") Link: https://patch.msgid.link/r/1726715161-18941-7-git-send-email-selvin.xavier@broadcom.com Signed-off-by: Selvin Xavier <selvin.xavier@broadcom.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Leon Romanovsky <leon@kernel.org>
2024-10-08RDMA/bnxt_re: Add a check for memory allocationKalesh AP
__alloc_pbl() can return error when memory allocation fails. Driver is not checking the status on one of the instances. Fixes: 0c4dcd602817 ("RDMA/bnxt_re: Refactor hardware queue memory allocation") Link: https://patch.msgid.link/r/1726715161-18941-4-git-send-email-selvin.xavier@broadcom.com Reviewed-by: Selvin Xavier <selvin.xavier@broadcom.com> Signed-off-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Signed-off-by: Selvin Xavier <selvin.xavier@broadcom.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Leon Romanovsky <leon@kernel.org>
2024-10-08RDMA/bnxt_re: Fix incorrect AVID type in WQE structureSaravanan Vajravel
Driver uses internal data structure to construct WQE frame. It used avid type as u16 which can accommodate up to 64K AVs. When outstanding AVID crosses 64K, driver truncates AVID and hence it uses incorrect AVID to WR. This leads to WR failure due to invalid AV ID and QP is moved to error state with reason set to 19 (INVALID AVID). When RDMA CM path is used, this issue hits QP1 and it is moved to error state Fixes: 1ac5a4047975 ("RDMA/bnxt_re: Add bnxt_re RoCE driver") Link: https://patch.msgid.link/r/1726715161-18941-3-git-send-email-selvin.xavier@broadcom.com Reviewed-by: Selvin Xavier <selvin.xavier@broadcom.com> Reviewed-by: Chandramohan Akula <chandramohan.akula@broadcom.com> Signed-off-by: Saravanan Vajravel <saravanan.vajravel@broadcom.com> Signed-off-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Signed-off-by: Selvin Xavier <selvin.xavier@broadcom.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Leon Romanovsky <leon@kernel.org>
2024-10-08RDMA/bnxt_re: Fix a possible memory leakKalesh AP
In bnxt_re_setup_chip_ctx() when bnxt_qplib_map_db_bar() fails driver is not freeing the memory allocated for "rdev->chip_ctx". Fixes: 0ac20faf5d83 ("RDMA/bnxt_re: Reorg the bar mapping") Link: https://patch.msgid.link/r/1726715161-18941-2-git-send-email-selvin.xavier@broadcom.com Signed-off-by: Selvin Xavier <selvin.xavier@broadcom.com> Signed-off-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Leon Romanovsky <leon@kernel.org>
2024-10-08HID: multitouch: Add support for B2402FVA track pointStefan Blum
By default the track point does not work on the Asus Expertbook B2402FVA. From libinput record i got the ID of the track point device: evdev: # Name: ASUE1201:00 04F3:32AE # ID: bus 0x18 vendor 0x4f3 product 0x32ae version 0x100 I found that the track point is functional, when i set the MT_CLS_WIN_8_FORCE_MULTI_INPUT_NSMU class for the reported device. Signed-off-by: Stefan Blum <stefan.blum@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2024-10-08HID: plantronics: Workaround for an unexcepted opposite volume keyWade Wang
Some Plantronics headset as the below send an unexcept opposite volume key's HID report for each volume key press after 200ms, like unecepted Volume Up Key following Volume Down key pressed by user. This patch adds a quirk to hid-plantronics for these devices, which will ignore the second unexcepted opposite volume key if it happens within 220ms from the last one that was handled. Plantronics EncorePro 500 Series (047f:431e) Plantronics Blackwire_3325 Series (047f:430c) The patch was tested on the mentioned model, it shouldn't affect other models, however, this quirk might be needed for them too. Auto-repeat (when a key is held pressed) is not affected per test result. Cc: stable@vger.kernel.org Signed-off-by: Wade Wang <wade.wang@hp.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2024-10-07bpf: Fix memory leak in bpf_core_applyJiri Olsa
We need to free specs properly. Fixes: 3d2786d65aaa ("bpf: correctly handle malformed BPF_CORE_TYPE_ID_LOCAL relos") Signed-off-by: Jiri Olsa <jolsa@kernel.org> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/bpf/20241007160958.607434-1-jolsa@kernel.org
2024-10-07net: airoha: Update tx cpu dma ring idx at the end of xmit loopLorenzo Bianconi
Move the tx cpu dma ring index update out of transmit loop of airoha_dev_xmit routine in order to not start transmitting the packet before it is fully DMA mapped (e.g. fragmented skbs). Fixes: 23020f049327 ("net: airoha: Introduce ethernet support for EN7581 SoC") Reported-by: Felix Fietkau <nbd@nbd.name> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20241004-airoha-eth-7581-mapping-fix-v1-1-8e4279ab1812@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-07net: phy: Remove LED entry from LEDs list on unregisterChristian Marangi
Commit c938ab4da0eb ("net: phy: Manual remove LEDs to ensure correct ordering") correctly fixed a problem with using devm_ but missed removing the LED entry from the LEDs list. This cause kernel panic on specific scenario where the port for the PHY is torn down and up and the kmod for the PHY is removed. On setting the port down the first time, the assosiacted LEDs are correctly unregistered. The associated kmod for the PHY is now removed. The kmod is now added again and the port is now put up, the associated LED are registered again. On putting the port down again for the second time after these step, the LED list now have 4 elements. With the first 2 already unregistered previously and the 2 new one registered again. This cause a kernel panic as the first 2 element should have been removed. Fix this by correctly removing the element when LED is unregistered. Reported-by: Daniel Golle <daniel@makrotopia.org> Tested-by: Daniel Golle <daniel@makrotopia.org> Cc: stable@vger.kernel.org Fixes: c938ab4da0eb ("net: phy: Manual remove LEDs to ensure correct ordering") Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20241004182759.14032-1-ansuelsmth@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-07Merge tag 'for-net-2024-10-04' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth Luiz Augusto von Dentz says: ==================== bluetooth pull request for net: - RFCOMM: FIX possible deadlock in rfcomm_sk_state_change - hci_conn: Fix UAF in hci_enhanced_setup_sync - btusb: Don't fail external suspend requests * tag 'for-net-2024-10-04' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth: Bluetooth: btusb: Don't fail external suspend requests Bluetooth: hci_conn: Fix UAF in hci_enhanced_setup_sync Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_change ==================== Link: https://patch.msgid.link/20241004210124.4010321-1-luiz.dentz@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
generated by cgit (git 2.34.1) at 2025-09-12 18:46:37 +0000