summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-11-21Merge tag 'mediatek-drm-next-20251120' of ↵Dave Airlie
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux into drm-next Mediatek DRM Next - 20251120 1. Fix probe resource leaks 2. Add support for MT8195/88 HDMIv2 and DDCv2 3. Fix CCORR mtk_ctm_s31_32_to_s1_n function issue 4. Fix device node reference leak in mtk_dp_dt_parse() Signed-off-by: Dave Airlie <airlied@redhat.com> From: Chun-Kuang Hu <chunkuang.hu@kernel.org> Link: https://patch.msgid.link/20251119233202.10034-1-chunkuang.hu@kernel.org
2025-11-21docs: efi: add CPER functions to driver-apiMauro Carvalho Chehab
There are two kernel-doc like descriptions at cper, which is used by other parts of cper and on ghes driver. They both have kernel-doc like descriptions. Change the tags for them to be actual kernel-doc tags and add them to the driver-api documentaion at the UEFI section. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Borislav Petkov (AMD) <bp@alien8.de> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2025-11-21efi/cper: align ARM CPER type with UEFI 2.9A/2.10 specsMauro Carvalho Chehab
Up to UEFI spec 2.9, the type byte of CPER struct for ARM processor was defined simply as: Type at byte offset 4: - Cache error - TLB Error - Bus Error - Micro-architectural Error All other values are reserved Yet, there was no information about how this would be encoded. Spec 2.9A errata corrected it by defining: - Bit 1 - Cache Error - Bit 2 - TLB Error - Bit 3 - Bus Error - Bit 4 - Micro-architectural Error All other values are reserved That actually aligns with the values already defined on older versions at N.2.4.1. Generic Processor Error Section. Spec 2.10 also preserve the same encoding as 2.9A. Adjust CPER and GHES handling code for both generic and ARM processors to properly handle UEFI 2.9A and 2.10 encoding. Link: https://uefi.org/specs/UEFI/2.10/Apx_N_Common_Platform_Error_Record.html#arm-processor-error-information Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Borislav Petkov (AMD) <bp@alien8.de> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2025-11-21efi/cper: Add a new helper function to print bitmasksMauro Carvalho Chehab
Add a helper function to print a string with names associated to each bit field. A typical example is: const char * const bits[] = { "bit 3 name", "bit 4 name", "bit 5 name", }; char str[120]; unsigned int bitmask = BIT(3) | BIT(5); #define MASK GENMASK(5,3) cper_bits_to_str(str, sizeof(str), FIELD_GET(MASK, bitmask), bits, ARRAY_SIZE(bits)); The above code fills string "str" with "bit 3 name|bit 5 name". Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Acked-by: Borislav Petkov (AMD) <bp@alien8.de> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2025-11-21efi/cper: Adjust infopfx size to accept an extra spaceMauro Carvalho Chehab
Compiling with W=1 with werror enabled produces an error: drivers/firmware/efi/cper-arm.c: In function ‘cper_print_proc_arm’: drivers/firmware/efi/cper-arm.c:298:64: error: ‘snprintf’ output may be truncated before the last format character [-Werror=format-truncation=] 298 | snprintf(infopfx, sizeof(infopfx), "%s ", newpfx); | ^ drivers/firmware/efi/cper-arm.c:298:25: note: ‘snprintf’ output between 2 and 65 bytes into a destination of size 64 298 | snprintf(infopfx, sizeof(infopfx), "%s ", newpfx); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ As the logic there adds an space at the end of infopx buffer. Add an extra space to avoid such warning. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Borislav Petkov (AMD) <bp@alien8.de> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2025-11-21RAS: Report all ARM processor CPER information to userspaceJason Tian
The ARM processor CPER record was added in UEFI v2.6 and remained unchanged up to v2.10. Yet, the original arm_event trace code added by e9279e83ad1f ("trace, ras: add ARM processor error trace event") is incomplete, as it only traces some fields of UAPI 2.6 table N.16, not exporting any information from tables N.17 to N.29 of the record. This is not enough for the user to be able to figure out what has exactly happened or to take appropriate action. According to the UEFI v2.9 specification chapter N2.4.4, the ARM processor error section includes: - several (ERR_INFO_NUM) ARM processor error information structures (Tables N.17 to N.20); - several (CONTEXT_INFO_NUM) ARM processor context information structures (Tables N.21 to N.29); - several vendor specific error information structures. The size is given by Section Length minus the size of the other fields. In addition, it also exports two fields that are parsed by the GHES driver when firmware reports it, e.g.: - error severity - CPU logical index Report all of these information to userspace via a the ARM tracepoint so that userspace can properly record the error and take decisions related to CPU core isolation according to error severity and other info. The updated ARM trace event now contains the following fields: ====================================== ============================= UEFI field on table N.16 ARM Processor trace fields ====================================== ============================= Validation handled when filling data for affinity MPIDR and running state. ERR_INFO_NUM pei_len CONTEXT_INFO_NUM ctx_len Section Length indirectly reported by pei_len, ctx_len and oem_len Error affinity level affinity MPIDR_EL1 mpidr MIDR_EL1 midr Running State running_state PSCI State psci_state Processor Error Information Structure pei_err - count at pei_len Processor Context ctx_err- count at ctx_len Vendor Specific Error Info oem - count at oem_len ====================================== ============================= It should be noted that decoding of tables N.17 to N.29, if needed, will be handled in userspace. That gives more flexibility, as there won't be any need to flood the kernel with micro-architecture specific error decoding. Also, decoding the other fields require a complex logic, and should be done for each of the several values inside the record field. So, let userspace daemons like rasdaemon decode them, parsing such tables and having vendor-specific micro-architecture-specific decoders. [mchehab: modified description, solved merge conflicts and fixed coding style] Signed-off-by: Jason Tian <jason@os.amperecomputing.com> Co-developed-by: Shengwei Luo <luoshengwei@huawei.com> Signed-off-by: Shengwei Luo <luoshengwei@huawei.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Daniel Ferguson <danielf@os.amperecomputing.com> # rebased Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Tested-by: Shiju Jose <shiju.jose@huawei.com> Acked-by: Borislav Petkov (AMD) <bp@alien8.de> Fixes: e9279e83ad1f ("trace, ras: add ARM processor error trace event") Link: https://uefi.org/specs/UEFI/2.10/Apx_N_Common_Platform_Error_Record.html#arm-processor-error-section Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2025-11-21Merge tag 'drm-xe-fixes-2025-11-21' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes Driver Changes: - Fix out-of-bounds access with BIT() (Shuicheng Lin) - Fix kunit test checking wrong condition (Matt Roper) - Drop duplicate kconfig select (Shuicheng Lin) - Fix guc2host irq handler with MSI-X (Venkata Ramana Nayana) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patch.msgid.link/uadbrmftcud3wg32c6tje7mmfcr7wgmpnkzxwubk6fletahje2@coek2ciunkvz
2025-11-21Merge tag 'amd-drm-fixes-6.18-2025-11-20' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-fixes-6.18-2025-11-20: amdgpu: - DTBCLK gating fix - EDID fetching retry improvements - HDMI HPD debounce filtering - DCN 2.0 cursor fix - DP MST PBN fix - VPE fix - GC 11 fix - PRT fix - MMIO remap page fix - SR-IOV fix radeon: - Fence deadlock fix Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20251120164110.1077973-1-alexander.deucher@amd.com
2025-11-21drm/gem: Use vmemdup_array_user in drm_gem_objects_lookupTvrtko Ursulin
Use a helper to shrink the code and separate the user and kernel slabs for better security. While at it lets remove the useless debug message. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Reviewed-by: André Almeida <andrealmeid@igalia.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20251112092732.23584-1-tvrtko.ursulin@igalia.com
2025-11-21Merge tag 'drm-misc-fixes-2025-11-20' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes Short summary of fixes pull: atomic: - Return error codes on failed blob creation for planes nouveau: - Fix memory leak tegra: - Fix device ref counting - Fix pid ref counting - Revert booting on Pixel C Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20251120151308.GA589436@linux.fritz.box
2025-11-21drm/xe/oa: Fix potential UAF in xe_oa_add_config_ioctl()Sanjay Yadav
In xe_oa_add_config_ioctl(), we accessed oa_config->id after dropping metrics_lock. Since this lock protects the lifetime of oa_config, an attacker could guess the id and call xe_oa_remove_config_ioctl() with perfect timing, freeing oa_config before we dereference it, leading to a potential use-after-free. Fix this by caching the id in a local variable while holding the lock. v2: (Matt A) - Dropped mutex_unlock(&oa->metrics_lock) ordering change from xe_oa_remove_config_ioctl() Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6614 Fixes: cdf02fe1a94a7 ("drm/xe/oa/uapi: Add/remove OA config perf ops") Cc: <stable@vger.kernel.org> # v6.11+ Suggested-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Sanjay Yadav <sanjay.kumar.yadav@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20251118114859.3379952-2-sanjay.kumar.yadav@intel.com (cherry picked from commit 28aeaed130e8e587fd1b73b6d66ca41ccc5a1a31) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-11-21drm/xe/pf: Check for fence error on VRAM save/restoreMichał Winiarski
The code incorrectly assumes that the VRAM save/restore fence is valid. Fix it by checking for error. Fixes: 49cf1b9b609fe ("drm/xe/pf: Handle VRAM migration data as part of PF control") Suggested-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20251114122339.1791026-1-michal.winiarski@intel.com Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> (cherry picked from commit 78ff838a8ab78b3cd438e382ff5204b93db3237e) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-11-21drm/xe/pf: Drop the VF VRAM BO reference on successful restoreMichał Winiarski
The reference is only dropped on error. Fix it by adding the missing xe_bo_put(). Fixes: 49cf1b9b609fe ("drm/xe/pf: Handle VRAM migration data as part of PF control") Reported-by: Adam Miszczak <adam.miszczak@linux.intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20251114100713.1776073-1-michal.winiarski@intel.com Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> (cherry picked from commit dab751b4240f0f0eadea81f93ff0b439379bc6ae) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-11-21drm/xe/pf: Fix kernel-doc warning in migration_save_consumeMichał Winiarski
The kernel-doc for xe_sriov_pf_migration_save_consume() contained multiple "Return:" sections, causing a warning. Fix it by removing the extra line. Fixes: 67df4a5cbc583 ("drm/xe/pf: Add data structures and handlers for migration rings") Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20251114134030.1795947-1-michal.winiarski@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> (cherry picked from commit 562b0f254d8b1515a1c8d2a650f940d4f719300e) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-11-21Merge tag 'drm-intel-fixes-2025-11-20' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/i915/kernel into drm-fixes - Wildcat Lake and Panther Lake detangled for display fixes (Dnyaneshwar) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/aR8jByCwjIThpnpk@intel.com
2025-11-21wifi: rtl8xxxu: Enable 40 MHz width by defaultBitterblue Smith
40 MHz support is hidden behind the ht40_2g module parameter with this comment: /* * Some APs will negotiate HT20_40 in a noisy environment leading * to miserable performance. Rather than defaulting to this, only * enable it if explicitly requested at module load time. */ This parameter was added in commit 26f1fad29ad9 ("New driver: rtl8xxxu (mac80211)"). Back then rtl8xxxu only supported RTL8723AU and the RTL8192CU family. It's entirely possible the miserable performance was due to mistakes in the channel switching function, which were fixed in a previous patch. Delete the ht40_2g module parameter. If someone still needs to disable 40 MHz support, cfg80211 has the module parameter cfg80211_disable_40mhz_24ghz. That works too. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/4f053103-adfd-4ead-acb3-ef69127a4bab@gmail.com
2025-11-21wifi: rtl8xxxu: Fix RX channel width reported by RTL8192FUBitterblue Smith
The other chips report the RX channel width in the RX descriptor, but this one doesn't. Get the RX channel width from the PHY status. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/1c6c1fd4-92f6-4327-a24e-f0747ab21819@gmail.com
2025-11-21wifi: rtl8xxxu: Fix the 40 MHz subchannel for RTL8192EU, RTL8723BUBitterblue Smith
rtl8xxxu_gen2_config_channel() was missing the subchannel setting. This function is used by RTL8192EU and RTL8723BU. This change seems to make no difference in my testing on channel 13 with either chip. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/a5de8d39-45c1-4667-ab4c-7109de6eb13d@gmail.com
2025-11-21wifi: rtl8xxxu: Make RTL8192CU, RTL8723AU TX with 40 MHz widthBitterblue Smith
Set the required fields in the TX descriptor to allow these chips to transmit with 40 MHz channel width when the access point supports it. Tested only with RTL8192CU, but these settings are identical for RTL8723AU. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/30d95228-69b2-48f9-8854-c98d2408c4d3@gmail.com
2025-11-21wifi: rtl8xxxu: Fix HT40 channel config for RTL8192CU, RTL8723AUBitterblue Smith
Flip the response rate subchannel. It was backwards, causing low speeds when using 40 MHz channel width. "iw dev ... station dump" showed a low RX rate, 11M or less. Also fix the channel width field of RF6052_REG_MODE_AG. Tested only with RTL8192CU, but these settings are identical for RTL8723AU. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/1f46571d-855b-43e1-8bfc-abacceb96043@gmail.com
2025-11-21dma-buf: system_heap: use larger contiguous mappings instead of per-page mmapBarry Song
We can allocate high-order pages, but mapping them one by one is inefficient. This patch changes the code to map as large a chunk as possible. The code looks somewhat complicated mainly because supporting mmap with a non-zero offset is a bit tricky. Using the micro-benchmark below, we see that mmap becomes 35X faster: #include <stdio.h> #include <fcntl.h> #include <linux/dma-heap.h> #include <sys/ioctl.h> #include <sys/mman.h> #include <time.h> #include <unistd.h> #include <stdlib.h> #define SIZE (512UL * 1024 * 1024) #define PAGE 4096 #define STRIDE (PAGE/sizeof(int)) #define PAGES (SIZE/PAGE) int main(void) { int heap = open("/dev/dma_heap/system", O_RDONLY); struct dma_heap_allocation_data d = { .len = SIZE, .fd_flags = O_RDWR|O_CLOEXEC }; ioctl(heap, DMA_HEAP_IOCTL_ALLOC, &d); struct timespec t0, t1; clock_gettime(CLOCK_MONOTONIC, &t0); int *p = mmap(NULL, SIZE, PROT_READ|PROT_WRITE, MAP_SHARED, d.fd, 0); clock_gettime(CLOCK_MONOTONIC, &t1); for (int i = 0; i < PAGES; i++) p[i*STRIDE] = i; for (int i = 0; i < PAGES; i++) if (p[i*STRIDE] != i) { fprintf(stderr, "mismatch at page %d\n", i); exit(1); } long ns = (t1.tv_sec-t0.tv_sec)*1000000000L + (t1.tv_nsec-t0.tv_nsec); printf("mmap 512MB took %.3f us, verify OK\n", ns/1000.0); return 0; } W/ patch: ~ # ./a.out mmap 512MB took 200266.000 us, verify OK ~ # ./a.out mmap 512MB took 198151.000 us, verify OK ~ # ./a.out mmap 512MB took 197069.000 us, verify OK ~ # ./a.out mmap 512MB took 196781.000 us, verify OK ~ # ./a.out mmap 512MB took 198102.000 us, verify OK ~ # ./a.out mmap 512MB took 195552.000 us, verify OK W/o patch: ~ # ./a.out mmap 512MB took 6987470.000 us, verify OK ~ # ./a.out mmap 512MB took 6970739.000 us, verify OK ~ # ./a.out mmap 512MB took 6984383.000 us, verify OK ~ # ./a.out mmap 512MB took 6971311.000 us, verify OK ~ # ./a.out mmap 512MB took 6991680.000 us, verify OK Signed-off-by: Barry Song <v-songbaohua@oppo.com> Acked-by: John Stultz <jstultz@google.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org> [sumits: correct from 3.5x to 35x] Link: https://patch.msgid.link/20251021042022.47919-1-21cnbao@gmail.com
2025-11-21cpufreq: qcom-nvmem: fix compilation warning for qcom_cpufreq_ipq806x_match_listChristian Marangi
If CONFIG_OF is not enabled, of_match_node() is set as NULL and qcom_cpufreq_ipq806x_match_list won't be used causing a compilation warning. Flag qcom_cpufreq_ipq806x_match_list as __maybe_unused to fix the compilation warning. While at it also flag as __initconst as it's used only in probe contest and can be freed after probe. This follows the pattern of the usual of_device_id variables. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202511202119.6zvvFMup-lkp@intel.com/ Fixes: 58f5d39d5ed8 ("cpufreq: qcom-nvmem: add compatible fallback for ipq806x for no SMEM") Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> [ Viresh: Drop __initconst ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2025-11-20Merge tag 'vfio-v6.19-dma-buf-v9+' into v6.19/vfio/nextAlex Williamson
[v9] vfio/pci: Allow MMIO regions to be exported through dma-buf https://lore.kernel.org/all/20251120-dmabuf-vfio-v9-0-d7f71607f371@nvidia.com Signed-off-by: Alex Williamson <alex@shazbot.org>
2025-11-20vfio/nvgrace: Support get_dmabuf_physJason Gunthorpe
Call vfio_pci_core_fill_phys_vec() with the proper physical ranges for the synthetic BAR 2 and BAR 4 regions. Otherwise use the normal flow based on the PCI bar. This demonstrates a DMABUF that follows the region info report to only allow mapping parts of the region that are mmapable. Since the BAR is power of two sized and the "CXL" region is just page aligned the there can be a padding region at the end that is not mmaped or passed into the DMABUF. The "CXL" ranges that are remapped into BAR 2 and BAR 4 areas are not PCI MMIO, they actually run over the CXL-like coherent interconnect and for the purposes of DMA behave identically to DRAM. We don't try to model this distinction between true PCI BAR memory that takes a real PCI path and the "CXL" memory that takes a different path in the p2p framework for now. Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Tested-by: Alex Mastro <amastro@fb.com> Tested-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Acked-by: Ankit Agrawal <ankita@nvidia.com> Reviewed-by: Ankit Agrawal <ankita@nvidia.com> Link: https://lore.kernel.org/r/20251120-dmabuf-vfio-v9-11-d7f71607f371@nvidia.com Signed-off-by: Alex Williamson <alex@shazbot.org>
2025-11-20vfio/pci: Add dma-buf export support for MMIO regionsLeon Romanovsky
Add support for exporting PCI device MMIO regions through dma-buf, enabling safe sharing of non-struct page memory with controlled lifetime management. This allows RDMA and other subsystems to import dma-buf FDs and build them into memory regions for PCI P2P operations. The implementation provides a revocable attachment mechanism using dma-buf move operations. MMIO regions are normally pinned as BARs don't change physical addresses, but access is revoked when the VFIO device is closed or a PCI reset is issued. This ensures kernel self-defense against potentially hostile userspace. Currently VFIO can take MMIO regions from the device's BAR and map them into a PFNMAP VMA with special PTEs. This mapping type ensures the memory cannot be used with things like pin_user_pages(), hmm, and so on. In practice only the user process CPU and KVM can safely make use of these VMA. When VFIO shuts down these VMAs are cleaned by unmap_mapping_range() to prevent any UAF of the MMIO beyond driver unbind. However, VFIO type 1 has an insecure behavior where it uses follow_pfnmap_*() to fish a MMIO PFN out of a VMA and program it back into the IOMMU. This has a long history of enabling P2P DMA inside VMs, but has serious lifetime problems by allowing a UAF of the MMIO after the VFIO driver has been unbound. Introduce DMABUF as a new safe way to export a FD based handle for the MMIO regions. This can be consumed by existing DMABUF importers like RDMA or DRM without opening an UAF. A following series will add an importer to iommufd to obsolete the type 1 code and allow safe UAF-free MMIO P2P in VM cases. DMABUF has a built in synchronous invalidation mechanism called move_notify. VFIO keeps track of all drivers importing its MMIO and can invoke a synchronous invalidation callback to tell the importing drivers to DMA unmap and forget about the MMIO pfns. This process is being called revoke. This synchronous invalidation fully prevents any lifecycle problems. VFIO will do this before unbinding its driver ensuring there is no UAF of the MMIO beyond the driver lifecycle. Further, VFIO has additional behavior to block access to the MMIO during things like Function Level Reset. This is because some poor platforms may experience a MCE type crash when touching MMIO of a PCI device that is undergoing a reset. Today this is done by using unmap_mapping_range() on the VMAs. Extend that into the DMABUF world and temporarily revoke the MMIO from the DMABUF importers during FLR as well. This will more robustly prevent an errant P2P from possibly upsetting the platform. A DMABUF FD is a preferred handle for MMIO compared to using something like a pgmap because: - VFIO is supported, including its P2P feature, on archs that don't support pgmap - PCI devices have all sorts of BAR sizes, including ones smaller than a section so a pgmap cannot always be created - It is undesirable to waste a lot of memory for struct pages, especially for a case like a GPU with ~100GB of BAR size - We want a synchronous revoke semantic to support FLR with light hardware requirements Use the P2P subsystem to help generate the DMA mapping. This is a significant upgrade over the abuse of dma_map_resource() that has historically been used by DMABUF exporters. Experience with an OOT version of this patch shows that real systems do need this. This approach deals with all the P2P scenarios: - Non-zero PCI bus_offset - ACS flags routing traffic to the IOMMU - ACS flags that bypass the IOMMU - though vfio noiommu is required to hit this. There will be further work to formalize the revoke semantic in DMABUF. For now this acts like a move_notify dynamic exporter where importer fault handling will get a failure when they attempt to map. This means that only fully restartable fault capable importers can import the VFIO DMABUFs. A future revoke semantic should open this up to more HW as the HW only needs to invalidate, not handle restartable faults. Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Acked-by: Ankit Agrawal <ankita@nvidia.com> Link: https://lore.kernel.org/r/20251120-dmabuf-vfio-v9-10-d7f71607f371@nvidia.com Signed-off-by: Alex Williamson <alex@shazbot.org>
2025-11-21arm64: dts: ti: k3-am62l: Fix unit address of cbass_wakeupVignesh Raghavendra
Fix the following warning with W=1: arch/arm64/boot/dts/ti/k3-am62l.dtsi:101.30-112.5: Warning (simple_bus_reg): /bus@f0000/bus@43000000: simple-bus unit address format error, expected "a80000" While at that, also remove extra space b/w label and node name. Fixes: 5f016758b0ab ("arm64: dts: ti: k3-am62l: add initial infrastructure") Link: https://patch.msgid.link/20251120143419.223238-1-vigneshr@ti.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2025-11-21arm64: dts: ti: k3-j721e-sk: Fix pinmux for pin Y1 used by power regulatorSiddharth Vadapalli
The SoC pin Y1 is incorrectly defined in the WKUP Pinmux device-tree node (pinctrl@4301c000) leading to the following silent failure: pinctrl-single 4301c000.pinctrl: mux offset out of range: 0x1dc (0x178) According to the datasheet for the J721E SoC [0], the pin Y1 belongs to the MAIN Pinmux device-tree node (pinctrl@11c000). This is confirmed by the address of the pinmux register for it on page 142 of the datasheet which is 0x00011C1DC. Hence fix it. [0]: https://www.ti.com/lit/ds/symlink/tda4vm.pdf Fixes: 97b67cc102dc ("arm64: dts: ti: k3-j721e-sk: Add DT nodes for power regulators") Cc: stable@vger.kernel.org Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com> Reviewed-by: Yemike Abhilash Chandra <y-abhilashchandra@ti.com> Link: https://patch.msgid.link/20251119160148.2752616-1-s-vadapalli@ti.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2025-11-21arm64: dts: ti: Add missing applied DT overlay targetsRob Herring (Arm)
It's a requirement that DT overlays be applied at build time in order to validate them as overlays are not validated on their own. Add the missing TI overlays. Some of the TI overlays have the first part needed (a "*-dtbs" variable), but not the second part adding the target to dtb-y/dtb- variable. Signed-off-by: Rob Herring (Arm) <robh@kernel.org> [vigneshr@ti.com: create new target for J721e GESI EVM] Link: https://patch.msgid.link/20251120141936.190796-1-vigneshr@ti.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2025-11-21wifi: rtw89: 8852a: correct field mask of reset DAC/ADC FIFOPing-Ke Shih
The field mask should be bits 16-31, but suddenly use wrong bits 24-31, rarely causing a little performance degraded if DAC/DAC FIFO stays on an unexpected state. Found this by Geert who works on bit field functions. Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Closes: https://lore.kernel.org/linux-wireless/CAMuHMdVt+5yOA6tuasX4KQgZud5wtRwu0A15UkEfQJbcd_xvVw@mail.gmail.com/ Cc: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20251120031044.12493-2-pkshih@realtek.com
2025-11-21wifi: rtw88: add WQ_UNBOUND to alloc_workqueue usersMarco Crivellari
Currently if a user enqueues a work item using schedule_delayed_work() the used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to schedule_work() that is using system_wq and queue_work(), that makes use again of WORK_CPU_UNBOUND. This lack of consistency cannot be addressed without refactoring the API. For more details see the Link tag below. alloc_workqueue() treats all queues as per-CPU by default, while unbound workqueues must opt-in via WQ_UNBOUND. This default is suboptimal: most workloads benefit from unbound queues, allowing the scheduler to place worker threads where they’re needed and reducing noise when CPUs are isolated. This continues the effort to refactor workqueue APIs, which began with the introduction of new workqueues and a new alloc_workqueue flag in: commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq") commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag") This change adds the WQ_UNBOUND flag to explicitly request alloc_workqueue() to be unbound, because this specific workload has no benefit being per-cpu. With the introduction of the WQ_PERCPU flag (equivalent to !WQ_UNBOUND), any alloc_workqueue() caller that doesn’t explicitly specify WQ_UNBOUND must now use WQ_PERCPU. Once migration is complete, WQ_UNBOUND can be removed and unbound will become the implicit default. Suggested-by: Tejun Heo <tj@kernel.org> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com> Link: https://lore.kernel.org/all/20250221112003.1dSuoGyc@linutronix.de/ Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20251118102032.54375-3-marco.crivellari@suse.com
2025-11-21wifi: rtlwifi: add WQ_UNBOUND to alloc_workqueue usersMarco Crivellari
Currently if a user enqueues a work item using schedule_delayed_work() the used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to schedule_work() that is using system_wq and queue_work(), that makes use again of WORK_CPU_UNBOUND. This lack of consistency cannot be addressed without refactoring the API. For more details see the Link tag below. alloc_workqueue() treats all queues as per-CPU by default, while unbound workqueues must opt-in via WQ_UNBOUND. This default is suboptimal: most workloads benefit from unbound queues, allowing the scheduler to place worker threads where they’re needed and reducing noise when CPUs are isolated. This continues the effort to refactor workqueue APIs, which began with the introduction of new workqueues and a new alloc_workqueue flag in: commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq") commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag") This change adds the WQ_UNBOUND flag to explicitly request alloc_workqueue() to be unbound, because this specific workload has no benefit being per-cpu. With the introduction of the WQ_PERCPU flag (equivalent to !WQ_UNBOUND), any alloc_workqueue() caller that doesn’t explicitly specify WQ_UNBOUND must now use WQ_PERCPU. Once migration is complete, WQ_UNBOUND can be removed and unbound will become the implicit default. Suggested-by: Tejun Heo <tj@kernel.org> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com> Link: https://lore.kernel.org/all/20250221112003.1dSuoGyc@linutronix.de/ Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20251118102032.54375-2-marco.crivellari@suse.com
2025-11-20Merge tag 'clk-imx-6.19' of ↵Stephen Boyd
git://git.kernel.org/pub/scm/linux/kernel/git/abelvesa/linux into clk-imx Pull i.MX clk driver updates from Abel Vesa: - Add delay to the PCC enable/disable in i.MX7ULP composite, needed by some specific peripherals - Simplify the i.MX8MP auxiomix by using devm_auxiliary_device_create() - Add the i.MX8ULP SIM LPAV platform specific clock provider * tag 'clk-imx-6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/abelvesa/linux: clk: imx: add driver for imx8ulp's sim lpav dt-bindings: clock: document 8ULP's SIM LPAV clk: imx: imx8mp-audiomix: use devm_auxiliary_device_create() to simple code clk: imx: Add some delay before deassert the reset
2025-11-21wifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb()Seungjin Bae
The rtl8187_rx_cb() calculates the rx descriptor header address by subtracting its size from the skb tail pointer. However, it does not validate if the received packet (skb->len from urb->actual_length) is large enough to contain this header. If a truncated packet is received, this will lead to a buffer underflow, reading memory before the start of the skb data area, and causing a kernel panic. Add length checks for both rtl8187 and rtl8187b descriptor headers before attempting to access them, dropping the packet cleanly if the check fails. Fixes: 6f7853f3cbe4 ("rtl8187: change rtl8187_dev.c to support RTL8187B (part 2)") Signed-off-by: Seungjin Bae <eeodqql09@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20251118013258.1789949-2-eeodqql09@gmail.com
2025-11-20clk: actions: Fix discarding const qualifier by 'container_of' macroAdrian Barnaś
Remove const qualifier from functions parameter because it was discarded when container_of was called. Received pointer had mutable access to it through received container. Signed-off-by: Adrian Barnaś <abarnas@google.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2025-11-20clk: spacemit: Set clk_hw_onecell_data::num before using flex arrayCharles Mirabile
When booting with KASAN enabled the following splat is encountered during probe of the k1 clock driver: UBSAN: array-index-out-of-bounds in drivers/clk/spacemit/ccu-k1.c:1044:16 index 0 is out of range for type 'clk_hw *[*]' CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.18.0-rc5+ #1 PREEMPT(lazy) Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2022.10spacemit 10/01/2022 Call Trace: [<ffffffff8002b628>] dump_backtrace+0x28/0x38 [<ffffffff800027d2>] show_stack+0x3a/0x50 [<ffffffff800220c2>] dump_stack_lvl+0x5a/0x80 [<ffffffff80022100>] dump_stack+0x18/0x20 [<ffffffff800164b8>] ubsan_epilogue+0x10/0x48 [<ffffffff8099034e>] __ubsan_handle_out_of_bounds+0xa6/0xa8 [<ffffffff80acbfa6>] k1_ccu_probe+0x37e/0x420 [<ffffffff80b79e6e>] platform_probe+0x56/0x98 [<ffffffff80b76a7e>] really_probe+0x9e/0x350 [<ffffffff80b76db0>] __driver_probe_device+0x80/0x138 [<ffffffff80b76f52>] driver_probe_device+0x3a/0xd0 [<ffffffff80b771c4>] __driver_attach+0xac/0x1b8 [<ffffffff80b742fc>] bus_for_each_dev+0x6c/0xc8 [<ffffffff80b76296>] driver_attach+0x26/0x38 [<ffffffff80b759ae>] bus_add_driver+0x13e/0x268 [<ffffffff80b7836a>] driver_register+0x52/0x100 [<ffffffff80b79a78>] __platform_driver_register+0x28/0x38 [<ffffffff814585da>] k1_ccu_driver_init+0x22/0x38 [<ffffffff80023a8a>] do_one_initcall+0x62/0x2a0 [<ffffffff81401c60>] do_initcalls+0x170/0x1a8 [<ffffffff81401e7a>] kernel_init_freeable+0x16a/0x1e0 [<ffffffff811f7534>] kernel_init+0x2c/0x180 [<ffffffff80025f56>] ret_from_fork_kernel+0x16/0x1d8 [<ffffffff81205336>] ret_from_fork_kernel_asm+0x16/0x18 ---[ end trace ]--- This is bogus and is simply a result of KASAN consulting the `.num` member of the struct for bounds information (as it should due to `__counted_by`) and finding 0 set by kzalloc() because it has not been initialized before the loop that fills in the array. The easy fix is to just move the line that sets `num` to before the loop that fills the array so that KASAN has the information it needs to accurately conclude that the access is valid. Fixes: 1b72c59db0add ("clk: spacemit: Add clock support for SpacemiT K1 SoC") Tested-by: Yanko Kaneti <yaneti@declera.com> Signed-off-by: Charles Mirabile <cmirabil@redhat.com> Reviewed-by: Alex Elder <elder@riscstar.com> Reviewed-by: Troy Mitchell <troy.mitchell@linux.spacemit.com> Reviewed-by: Yixun Lan <dlan@gentoo.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2025-11-20Merge branch 'devlink-net-mlx5-implement-swp_l4_csum_mode-via-devlink-params'Jakub Kicinski
Daniel Zahka says: ==================== devlink: net/mlx5: implement swp_l4_csum_mode via devlink params This series introduces a new devlink feature for querying param default values, and resetting params to their default values. This feature is then used to implement a new mlx5 driver param. The series starts with two pure refactor patches: one that passes through the extack to devlink_param::get() implementations. And a second small refactor that prepares the netlink tlv handling code in the devlink_param::get() path to better handle default parameter values. The third patch introduces the uapi and driver api for default parameter values. The driver api is opt-in, and both the uapi and driver api preserve existing behavior when not used by drivers or userspace. The fourth patch introduces a new mlx5 driver param, swp_l4_csum_mode, for controlling tx csum behavior. The "l4_only" value of this param is a dependency for PSP initialization on CX7 NICs. Lastly, the series introduces a new driver param with cmode runtime to netdevsim, and then uses this param in a new testcase for netdevsim devlink params. Here are some examples of using the default param uapi with the devlink cli. Note the devlink cli binary I am using has changes which I am posting in accompanying series targeting iproute2-next: # netdevsim ./devlink dev param show netdevsim/netdevsim0 netdevsim/netdevsim0: name max_macs type generic values: cmode driverinit value 32 default 32 name test1 type driver-specific values: cmode driverinit value true default true # set to false ./devlink dev param set netdevsim/netdevsim0 name test1 value false cmode driverinit ./devlink dev param show netdevsim/netdevsim0 netdevsim/netdevsim0: name max_macs type generic values: cmode driverinit value 32 default 32 name test1 type driver-specific values: cmode driverinit value false default true # set back to default ./devlink dev param set netdevsim/netdevsim0 name test1 default cmode driverinit ./devlink dev param show netdevsim/netdevsim0 netdevsim/netdevsim0: name max_macs type generic values: cmode driverinit value 32 default 32 name test1 type driver-specific values: cmode driverinit value true default true # mlx5 params on cx7 ./devlink dev param show pci/0000:01:00.0 pci/0000:01:00.0: name max_macs type generic values: cmode driverinit value 128 default 128 ... name swp_l4_csum_mode type driver-specific values: cmode permanent value default default default # set to l4_only ./devlink dev param set pci/0000:01:00.0 name swp_l4_csum_mode value l4_only cmode permanent ./devlink dev param show pci/0000:01:00.0 name swp_l4_csum_mode pci/0000:01:00.0: name swp_l4_csum_mode type driver-specific values: cmode permanent value l4_only default default # reset to default ./devlink dev param set pci/0000:01:00.0 name swp_l4_csum_mode default cmode permanent ./devlink dev param show pci/0000:01:00.0 name swp_l4_csum_mode pci/0000:01:00.0: name swp_l4_csum_mode type driver-specific values: cmode permanent value default default default ==================== Link: https://patch.msgid.link/20251119025038.651131-1-daniel.zahka@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-20selftest: netdevsim: test devlink default paramsDaniel Zahka
Test querying default values and resetting to default values for netdevsim devlink params. This should cover the basic paths of interest: driverinit and non-driverinit cmodes, as well as bool and non-bool value type. Default param values of type bool are encoded with u8 netlink type as opposed to flag type, so that userspace can distinguish "not-present" from false. Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com> Link: https://patch.msgid.link/20251119025038.651131-7-daniel.zahka@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-20netdevsim: register a new devlink param with default value interfaceDaniel Zahka
Create a new devlink param, test2, that supports default param actions via the devlink_param::get_default() and devlink_param::reset_default() functions. Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com> Link: https://patch.msgid.link/20251119025038.651131-6-daniel.zahka@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-20net/mlx5: implement swp_l4_csum_mode via devlink paramsDaniel Zahka
swp_l4_csum_mode controls how L4 transmit checksums are computed when using Software Parser (SWP) hints for header locations. Supported values: 1. default: device will choose between full_csum or l4_only. Driver will discover the device's choice during initialization. 2. full_csum: calculate L4 checksum with the pseudo-header. 3. l4_only: calculate L4 checksum without the pseudo-header. Only available when swp_l4_csum_mode_l4_only is set in mlx5_ifc_nv_sw_offload_cap_bits. Note that 'default' might be returned from the device and passed to userspace, and it might also be set during a devlink_param::reset_default() call, but attempts to set a value of default directly with param-set will be rejected. The l4_only setting is a dependency for PSP initialization in mlx5e_psp_init(). Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com> Link: https://patch.msgid.link/20251119025038.651131-5-daniel.zahka@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-20devlink: support default values for param-get and param-setDaniel Zahka
Support querying and resetting to default param values. Introduce two new devlink netlink attrs: DEVLINK_ATTR_PARAM_VALUE_DEFAULT and DEVLINK_ATTR_PARAM_RESET_DEFAULT. The former is used to contain an optional parameter value inside of the param_value nested attribute. The latter is used in param-set requests from userspace to indicate that the driver should reset the param to its default value. To implement this, two new functions are added to the devlink driver api: devlink_param::get_default() and devlink_param::reset_default(). These callbacks allow drivers to implement default param actions for runtime and permanent cmodes. For driverinit params, the core latches the last value set by a driver via devl_param_driverinit_value_set(), and uses that as the default value for a param. Because default parameter values are optional, it would be impossible to discern whether or not a param of type bool has default value of false or not provided if the default value is encoded using a netlink flag type. For this reason, when a DEVLINK_PARAM_TYPE_BOOL has an associated default value, the default value is encoded using a u8 type. Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com> Link: https://patch.msgid.link/20251119025038.651131-4-daniel.zahka@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-20devlink: refactor devlink_nl_param_value_fill_one()Daniel Zahka
Lift the param type demux and value attr placement into a separate function. This new function, devlink_nl_param_put(), can be used to place additional types values in the value array, e.g., default, current, next values. This commit has no functional change. Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com> Link: https://patch.msgid.link/20251119025038.651131-3-daniel.zahka@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-20devlink: pass extack through to devlink_param::get()Daniel Zahka
Allow devlink_param::get() handlers to report error messages via extack. This function is called in a few different contexts, but not all of them will have an valid extack to use. When devlink_param::get() is called from param_get_doit or param_get_dumpit contexts, pass the extack through so that drivers can report errors when retrieving param values. devlink_param::get() is called from the context of devlink_param_notify(), pass NULL in for the extack. Reviewed-by: Saeed Mahameed <saeedm@nvidia.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com> Link: https://patch.msgid.link/20251119025038.651131-2-daniel.zahka@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-20clk: visconti: Add VIIF clocksYuji Ishikawa
Add the control sequence of register bits to handle the clocks and the resets of Video Input Interface. Signed-off-by: Yuji Ishikawa <yuji2.ishikawa@toshiba.co.jp> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2025-11-20dt-bindings: clock: tmpv770x: Add VIIF clocksYuji Ishikawa
Add clock and reset identifiers for the Video Input Interface. These identifiers support two instances: VIIF0 and VIIF1. Signed-off-by: Yuji Ishikawa <yuji2.ishikawa@toshiba.co.jp> Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2025-11-20dt-bindings: clock: tmpv770x: Remove definition of number of clocksYuji Ishikawa
Remove the definitions of number of clocks from bindings because they prevent adding new clocks. Since the previous patch removed all refereces within the driver, they can now be deleted. The same for resets and plls. Signed-off-by: Yuji Ishikawa <yuji2.ishikawa@toshiba.co.jp> Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2025-11-20clk: visconti: Do not define number of clocks in bindingsYuji Ishikawa
Remove use of TMPV770X_NR_CLK. Instead, define number of clocks inside the driver directory. The same for TMPV770X_NR_RESET and TMPV770X_NR_PLL. Signed-off-by: Yuji Ishikawa <yuji2.ishikawa@toshiba.co.jp> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2025-11-20Merge branch 'netconsole-allow-userdata-buffer-to-grow-dynamically'Jakub Kicinski
Gustavo Luiz Duarte says: ==================== netconsole: Allow userdata buffer to grow dynamically The current netconsole implementation allocates a static buffer for extradata (userdata + sysdata) with a fixed size of MAX_EXTRADATA_ENTRY_LEN * MAX_EXTRADATA_ITEMS bytes for every target, regardless of whether userspace actually uses this feature. This forces us to keep MAX_EXTRADATA_ITEMS small (16), which is restrictive for users who need to attach more metadata to their log messages. This patch series enables dynamic allocation of the userdata buffer, allowing it to grow on-demand based on actual usage. The series: 1. Refactors send_fragmented_body() to simplify handling of separated userdata and sysdata (patch 1/4) 2. Splits userdata and sysdata into separate buffers (patch 2/4) 3. Implements dynamic allocation for the userdata buffer (patch 3/4) 4. Increases MAX_USERDATA_ITEMS from 16 to 256 now that we can do so without memory waste (patch 4/4) Benefits: - No memory waste when userdata is not used - Targets that use userdata only consume what they need - Users can attach significantly more metadata without impacting systems that don't use this feature ==================== Link: https://patch.msgid.link/20251119-netconsole_dynamic_extradata-v3-0-497ac3191707@meta.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-20netconsole: Increase MAX_USERDATA_ITEMSGustavo Luiz Duarte
Increase MAX_USERDATA_ITEMS from 16 to 256 entries now that the userdata buffer is allocated dynamically. The previous limit of 16 was necessary because the buffer was statically allocated for all targets. With dynamic allocation, we can support more entries without wasting memory on targets that don't use userdata. This allows users to attach more metadata to their netconsole messages, which is useful for complex debugging and logging scenarios. Also update the testcase accordingly. Signed-off-by: Gustavo Luiz Duarte <gustavold@gmail.com> Reviewed-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20251119-netconsole_dynamic_extradata-v3-4-497ac3191707@meta.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-20netconsole: Dynamic allocation of userdata bufferGustavo Luiz Duarte
The userdata buffer in struct netconsole_target is currently statically allocated with a size of MAX_USERDATA_ITEMS * MAX_EXTRADATA_ENTRY_LEN (16 * 256 = 4096 bytes). This wastes memory when userdata entries are not used or when only a few entries are configured, which is common in typical usage scenarios. It also forces us to keep MAX_USERDATA_ITEMS small to limit the memory wasted. Change the userdata buffer from a static array to a dynamically allocated pointer. The buffer is now allocated on-demand in update_userdata() whenever userdata entries are added, modified, or removed via configfs. The implementation calculates the exact size needed for all current userdata entries, allocates a new buffer of that size, formats the entries into it, and atomically swaps it with the old buffer. This approach provides several benefits: - Memory efficiency: Targets with no userdata use zero bytes instead of 4KB, and targets with userdata only allocate what they need; - Scalability: Makes it practical to increase MAX_USERDATA_ITEMS to a much larger value without imposing a fixed memory cost on every target; - No hot-path overhead: Allocation occurs during configuration (write to configfs), not during message transmission If memory allocation fails during userdata update, -ENOMEM is returned to userspace through the configfs attribute write operation. The sysdata buffer remains statically allocated since it has a smaller fixed size (MAX_SYSDATA_ITEMS * MAX_EXTRADATA_ENTRY_LEN = 4 * 256 = 1024 bytes) and its content length is less predictable. Signed-off-by: Gustavo Luiz Duarte <gustavold@gmail.com> Reviewed-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20251119-netconsole_dynamic_extradata-v3-3-497ac3191707@meta.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-20netconsole: Split userdata and sysdataGustavo Luiz Duarte
Separate userdata and sysdata into distinct buffers to enable independent management. Previously, both were stored in a single extradata_complete buffer with a fixed size that accommodated both types of data. This separation allows: - userdata to grow dynamically (in subsequent patch) - sysdata to remain in a small static buffer - removal of complex entry counting logic that tracked both types together The split also simplifies the code by eliminating the need to check total entry count across both userdata and sysdata when enabling features, which allows to drop holding su_mutex on sysdata_*_enabled_store(). No functional change in this patch, just structural preparation for dynamic userdata allocation. Signed-off-by: Gustavo Luiz Duarte <gustavold@gmail.com> Reviewed-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20251119-netconsole_dynamic_extradata-v3-2-497ac3191707@meta.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
generated by cgit v1.2.3 (git 2.51.0) at 2026-11-10 19:15:56 +0000