summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2025-11-12drm/i915/fb: Init 'ret' in each error branch in intel_framebuffer_init()Ville Syrjälä
Make the order of things a bit less fragile in intel_framebuffer_init() by assigning 'ret' in each error branch instead of depending on some earlier assignment. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251107181126.5743-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-11-12drm/i915: Nuke intel_plane_config.tilingVille Syrjälä
Use intel_fb_modifier_to_tiling() to convert the modifier into the fence tiling mode during BIOS FB readout, rather than hand rolling it. With this we can also stop tracking the tiling mode in the intel_plane_config. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251107181126.5743-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-11-12drm/i915: Populate fb->format accurately in BIOS FB readoutVille Syrjälä
Use drm_get_format_info() instead of drm_format_info() to populate fb->format during the BIOS FB readout. The difference being that drm_get_format_info() knows about compressed formats whereas drm_format_info() doesn't. This doesn't actually matter in practice since the BIOS FB should never be compressed, but no reason we shouldn't use the more accurate function here anyway. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251107181126.5743-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-11-12drm/i915: Pass drm_format_info into plane->max_stride()Ville Syrjälä
Pass the format info into plane->max_stride() from the caller instead of doing yet another drm_format_info() lookup on the spot. drm_format_info() is both rather expensive, and technically incorrect since it doesn't return the correct format info for compressed formats (though that doesn't actually matter for the current .max_stride() implementations since they are just interested in the cpp value). Most callers already have the format info available. The only exception is intel_dumb_fb_max_stride() where we shall use the actually correct drm_get_format_info() variant. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251107181126.5743-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-11-12drm/i915: Introduce intel_dumb_fb_max_stride()Ville Syrjälä
Wrap intel_plane_fb_max_stride() in intel_dumb_fb_max_stride() for the purposes of dumb fb creation. I want to change intel_plane_fb_max_stride() to take a 'struct drm_format_info' instead of the 'u32 pixel_format' so we need an excplicit format info lookup in the dumb fb path and I don't really want to have that in i915_gem_dumb_create() directly. This makes intel_plane_fb_max_stride() internal to the display code again, and thus we can pass in struct intel_display instead of struct drm_device. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251107181126.5743-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-11-12ACPI: property: Fix fwnode refcount leak in acpi_fwnode_graph_parse_endpoint()Haotian Zhang
acpi_fwnode_graph_parse_endpoint() calls fwnode_get_parent() to obtain the parent fwnode but returns without calling fwnode_handle_put() on it. This potentially leads to a fwnode refcount leak and prevents the parent node from being released properly. Call fwnode_handle_put() on the parent fwnode before returning to prevent the leak from occurring. Fixes: 3b27d00e7b6d ("device property: Move fwnode graph ops to firmware specific locations") Signed-off-by: Haotian Zhang <vulab@iscas.ac.cn> Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com> [ rjw: Changelog edits ] Link: https://patch.msgid.link/20251111075000.1828-1-vulab@iscas.ac.cn Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-11-12cxl: Add handling of locked CXL decoderDave Jiang
When a decoder is locked, it means that its configuration cannot be changed. CXL spec r3.2 8.2.4.20.13 discusses the details regarding locked decoders. Locking happens when bit 8 of the decoder control register is set and then the decoder is committed afterwards (CXL spec r3.2 8.2.4.20.7). Given that the driver creates a virtual decoder for each CFMWS, the Fixed Device Configuration (bit 4) of the Window Restriction field is considered as locking for the virtual decoder by the driver. The current driver code disregards the locked status and a region can be destroyed regardless of the locking state. Add a region flag to indicate the region is in a locked configuration. The driver will considered a region locked if the CFMWS or any decoder is configured as locked. The consideration is all or nothing regarding the locked state. It is reasonable to determine the region "locked" status while the region is being assembled based on the decoders. Add a check in region commit_store() to intercept when a 0 is written to the commit sysfs attribute in order to prevent the destruction of a region when in locked state. This should be the only entry point from user space to destroy a region. Add a check is added to cxl_decoder_reset() to prevent resetting a locked decoder within the kernel driver. Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Link: https://patch.msgid.link/20251105201826.2901915-1-dave.jiang@intel.com Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2025-11-12ACPI: DPTF: Support Nova LakeSrinivas Pandruvada
Add Nova Lake ACPI IDs for DPTF. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://patch.msgid.link/20251111004552.137984-3-srinivas.pandruvada@linux.intel.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-11-12thermal: intel: int340x: Add DLVR support for Nova LakeSrinivas Pandruvada
Add support for DLVR (Digital Linear Voltage Regulator) for Nova Lake. There are no new sysfs attributes or difference in operations compared to prior generations. MMIO offset and bit positions are changed. Also no mapping is required as units are already in MHz. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://patch.msgid.link/20251111004552.137984-2-srinivas.pandruvada@linux.intel.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-11-12thermal: int340x: processor_thermal: Add Nova Lake processor thermal deviceSrinivas Pandruvada
Add PCI IDs for Nova Lake processor thermal device. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://patch.msgid.link/20251111004552.137984-1-srinivas.pandruvada@linux.intel.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-11-12hwmon/pmbus: (isl68137) Add support for raa229141Jeff Lin
The RAA229141A is a digital dual output multiphase (X+Y ≤ 12) PWM controller designed to be compliant with Intel VR13, VR13.HC, VR14 and VR14.Cloud specifications, targeting VCORE and auxiliary rails. The RAA229141A supports the Intel SVID interface along with PMBus V1.3 specifications, making it ideal for controlling the microprocessor core and system rails in Intel VR13, VR13.HC, VR14 and VR14.Cloud platforms. Signed-off-by: Jeff Lin <jefflin994697@gmail.com> Link: https://lore.kernel.org/r/20251106104519.2014853-1-jefflin994697@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-11-12thermal: intel: int340x: Replace sprintf() with sysfs_emit()Kaushlendra Kumar
Replace sprintf() calls with sysfs_emit() in sysfs "show" functions to follow current kernel coding standards. sysfs_emit() is the preferred method for formatting sysfs output as it provides better bounds checking and is more secure. Signed-off-by: Kaushlendra Kumar <kaushlendra.kumar@intel.com> [ rjw: Subject adjustments, changelog edits ] Link: https://patch.msgid.link/20251030053410.311656-1-kaushlendra.kumar@intel.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-11-12thermal: intel: int340x: Use symbolic constant for UUID comparisonKaushlendra Kumar
Replace sizeof() with a symbolic constant for UUID matching to maintain existing ABI behavior while improving code clarity. The current behavior of comparing only the first 7 characters is sufficient to distinguish all UUIDs and changing to full string comparison would alter the kernel ABI, potentially breaking existing userspace applications. Use a defined constant to make the truncated comparison explicit and maintainable. Signed-off-by: Kaushlendra Kumar <kaushlendra.kumar@intel.com> [ rjw: Subject adjustments ] Link: https://patch.msgid.link/20251030035955.62171-1-kaushlendra.kumar@intel.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-11-12hwmon: Add TSC1641 I2C power monitor driverIgor Reznichenko
Add a driver for the ST Microelectronics TSC1641 16-bit high-precision power monitor. The driver supports reading bus voltage, current, power, and temperature. Sysfs attributes are exposed for shunt resistor and update interval. The driver integrates with the hwmon subsystem and supports optional ALERT pin polarity configuration. Signed-off-by: Igor Reznichenko <igor@reznichenko.net> Link: https://lore.kernel.org/r/20251105201406.1210856-3-igor@reznichenko.net Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-11-12cpuidle: teo: Use this_cpu_ptr() where possibleChristian Loehle
The cpuidle governor callbacks for update, select and reflect are always running on the actual idle entering/exiting CPU, so use the more optimized this_cpu_ptr() to access the internal teo data. This brings down the latency-critical teo_reflect() from static void teo_reflect(struct cpuidle_device *dev, int state) { ffffffc080ffcff0: hint #0x19 ffffffc080ffcff4: stp x29, x30, [sp, #-48]! struct teo_cpu *cpu_data = per_cpu_ptr(&teo_cpus, dev->cpu); ffffffc080ffcff8: adrp x2, ffffffc0848c0000 <gicv5_global_data+0x28> { ffffffc080ffcffc: add x29, sp, #0x0 ffffffc080ffd000: stp x19, x20, [sp, #16] ffffffc080ffd004: orr x20, xzr, x0 struct teo_cpu *cpu_data = per_cpu_ptr(&teo_cpus, dev->cpu); ffffffc080ffd008: add x0, x2, #0xc20 { ffffffc080ffd00c: stp x21, x22, [sp, #32] struct teo_cpu *cpu_data = per_cpu_ptr(&teo_cpus, dev->cpu); ffffffc080ffd010: adrp x19, ffffffc083eb5000 <cpu_devices+0x78> ffffffc080ffd014: add x19, x19, #0xbb0 ffffffc080ffd018: ldr w3, [x20, #4] dev->last_state_idx = state; to static void teo_reflect(struct cpuidle_device *dev, int state) { ffffffc080ffd034: hint #0x19 ffffffc080ffd038: stp x29, x30, [sp, #-48]! ffffffc080ffd03c: add x29, sp, #0x0 ffffffc080ffd040: stp x19, x20, [sp, #16] ffffffc080ffd044: orr x20, xzr, x0 struct teo_cpu *cpu_data = this_cpu_ptr(&teo_cpus); ffffffc080ffd048: adrp x19, ffffffc083eb5000 <cpu_devices+0x78> { ffffffc080ffd04c: stp x21, x22, [sp, #32] struct teo_cpu *cpu_data = this_cpu_ptr(&teo_cpus); ffffffc080ffd050: add x19, x19, #0xbb0 dev->last_state_idx = state; This saves us: adrp x2, ffffffc0848c0000 <gicv5_global_data+0x28> add x0, x2, #0xc20 ldr w3, [x20, #4] Signed-off-by: Christian Loehle <christian.loehle@arm.com> [ rjw: Subject tweak ] Link: https://patch.msgid.link/20251110120819.714560-1-christian.loehle@arm.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-11-12cpuidle: Add sanity check for exit latency and target residencyRafael J. Wysocki
Make __cpuidle_driver_init() fail if the exit latency of one of the driver's idle states is less than its target residency which would break cpuidle assumptions. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Reviewed-by: Christian Loehle <christian.loehle@arm.com> [ rjw: Changelog fix ] Link: https://patch.msgid.link/12779486.O9o76ZdvQC@rafael.j.wysocki Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-11-12PM: wakeup: Update after recent wakeup source removal ordering changeRafael J. Wysocki
After a recent change, wakeup_source_activate() will warn that the given wakeup source is "unregistered" after its timer has been shut down in wakeup_source_remove() which may be somewhat confusing, so change the warning message to say that the wakeup source is "unusable". Accordingly, rename wakeup_source_not_registered() to wakeup_source_not_usable() and update the comment in it to also mention the removal of the wakeup source. Also restore the comment in wakeup_source_remove() regarding the warning in wakeup_source_activate() that may trigger after shutting down the wakeup source timer. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/12788103.O9o76ZdvQC@rafael.j.wysocki
2025-11-12cpufreq: intel_pstate: Use mutex guard for driver lockingRafael J. Wysocki
Use guard(mutex)(&intel_pstate_driver_lock), or the scoped variant of it, wherever intel_pstate_driver_lock needs to be held. This allows some local variables and goto statements to be dropped as they are not necessary any more. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Muhammad Usama Anjum <usama.anjum@collabora.com> Link: https://patch.msgid.link/2807232.mvXUDI8C0e@rafael.j.wysocki
2025-11-12hwmon: (gpd-fan) initialize EC on driver load for Win 4Cryolitia PukNgae
The original implement will re-init the EC when it reports a zero value, and it's a workaround for the black box buggy firmware. Now a contributer test and report that, the bug is that, the firmware won't initialize the EC on boot, so the EC ramains in unusable status. And it won't need to re-init it during runtime. The original implement is not perfect, any write command will be ignored until we first read it. Just re-init it unconditionally when the driver load could work. Fixes: 0ab88e239439 ("hwmon: add GPD devices sensor driver") Co-developed-by: kylon <3252255+kylon@users.noreply.github.com> Signed-off-by: kylon <3252255+kylon@users.noreply.github.com> Link: https://github.com/Cryolitia/gpd-fan-driver/pull/20 Signed-off-by: Cryolitia PukNgae <cryolitia@uniontech.com> Link: https://lore.kernel.org/r/20251030-win4-v1-1-c374dcb86985@uniontech.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-11-12hwmon: (gpd-fan) Fix compilation error in non-ACPI buildsGopi Krishna Menon
Building gpd-fan driver without CONFIG_ACPI results in the following build errors: drivers/hwmon/gpd-fan.c: In function ‘gpd_ecram_read’: drivers/hwmon/gpd-fan.c:228:9: error: implicit declaration of function ‘outb’ [-Werror=implicit-function-declaration] 228 | outb(0x2E, addr_port); | ^~~~ drivers/hwmon/gpd-fan.c:241:16: error: implicit declaration of function ‘inb’ [-Werror=implicit-function-declaration] 241 | *val = inb(data_port); The definitions for inb() and outb() come from <linux/io.h> (specifically through <asm/io.h>), which is implicitly included via <acpi_io.h>. When CONFIG_ACPI is not set, <acpi_io.h> is not included resulting in <linux/io.h> to be omitted as well. Since the driver does not depend on ACPI, remove <linux/acpi.h> and add <linux/io.h> directly to fix the compilation errors. Signed-off-by: Gopi Krishna Menon <krishnagopi487@gmail.com> Link: https://lore.kernel.org/r/20251024202042.752160-1-krishnagopi487@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-11-12Merge tag 'amd-pstate-v6.19-2025-11-10' of ↵Rafael J. Wysocki
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/superm1/linux Pull amd-pstate content for 6.19 (11/10/25) from Mario Liminciello: "* optimizations for parameter array handling * fix for mode changes with offline CPUs" * tag 'amd-pstate-v6.19-2025-11-10' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/superm1/linux: cpufreq/amd-pstate: Call cppc_set_auto_sel() only for online CPUs cpufreq/amd-pstate: Add static asserts for EPP indices cpufreq/amd-pstate: Fix some whitespace issues cpufreq/amd-pstate: Adjust return values in amd_pstate_update_status() cpufreq/amd-pstate: Make amd_pstate_get_mode_string() never return NULL cpufreq/amd-pstate: Drop NULL value from amd_pstate_mode_string cpufreq/amd-pstate: Use sysfs_match_string() for epp
2025-11-12Merge back cpufreq material for 6.19Rafael J. Wysocki
2025-11-12can: bxcan: Fix a typo error for assignChu Guangqing
Fix the spelling error of "assign". Signed-off-by: Chu Guangqing <chuguangqing@inspur.com> Reviewed-by: Dario Binacchi <dario.binacchi@amarulasolutions.com> Link: https://patch.msgid.link/20251103074009.4708-1-chuguangqing@inspur.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-11-12can: mcp251xfd: add gpio functionalityGregor Herburger
The mcp251xfd devices allow two pins to be configured as gpio. Add this functionality to driver. Acked-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Signed-off-by: Gregor Herburger <gregor.herburger@ew.tq-group.com> Tested-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com> Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20251001091006.4003841-6-viken.dadhaniya@oss.qualcomm.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-11-12can: mcp251xfd: only configure PIN1 when rx_int is setGregor Herburger
When rx_int is used th mcp251xfd_chip_rx_int_enable and mcp251xfd_chip_rx_int_disable function configure both PIN0 and PIN1. To prepare the support of the GPIOS only configure PIN1 with regmap_update_bits. This way PIN0 can be used as GPIO while PIN1 is used as rx_int interrupt. Signed-off-by: Gregor Herburger <gregor.herburger@ew.tq-group.com> Tested-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com> Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20251001091006.4003841-5-viken.dadhaniya@oss.qualcomm.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-11-12can: mcp251xfd: add workaround for errata 5Gregor Herburger
According to Errata DS80000789E 5 writing IOCON register using one SPI write command clears LAT0/LAT1. Errata Fix/Work Around suggests to write registers with single byte write instructions. However, it seems that every write to the second byte causes the overwrite of LAT0/LAT1. Never write byte 2 of IOCON register to avoid clearing of LAT0/LAT1. Signed-off-by: Gregor Herburger <gregor.herburger@ew.tq-group.com> Tested-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com> Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20251001091006.4003841-4-viken.dadhaniya@oss.qualcomm.com [mkl: add missing MCP251XFD_REG_IOCON_GPIO_MASK] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-11-12Merge tag 'arm64-fpsimd-on-stack-for-v6.19' into libcrypto-fpsimd-on-stackEric Biggers
Pull fpsimd-on-stack changes from Ard Biesheuvel: "Shared tag/branch for arm64 FP/SIMD changes going through libcrypto" Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2025-11-12drm/nouveau: fully define nvfw_hs_load_header_v2Timur Tabi
Add the missing fields of the nvfw_hs_load_header_v2 struct, so that the struct matches the actual contents of the firmware images. nvfw_hs_load_header_v2 is a struct that defines a header for some firmware images used by Nouveau. The current structure definition is incomplete; it omits the last two fields because they are unused. To maintain consistency between Nouveau, OpenRM, and Nova, and to make it easier to support possible future images, we should fully define the struct. Also add a __counted_by tag for the flex array. Signed-off-by: Timur Tabi <ttabi@nvidia.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patch.msgid.link/20251010223957.1078525-1-ttabi@nvidia.com
2025-11-12Merge tag 'wireless-next-2025-11-12' of ↵Jakub Kicinski
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Johannes Berg says: ==================== More -next material, notably: - split ieee80211.h file, it's way too big - mac80211: initial chanctx work towards NAN - mac80211: MU-MIMO sniffer improvements - ath12k: statistics improvements * tag 'wireless-next-2025-11-12' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (26 commits) wifi: cw1200: Fix potential memory leak in cw1200_bh_rx_helper() wifi: mac80211: make monitor link info check more specific wifi: mac80211: track MU-MIMO configuration on disabled interfaces wifi: cfg80211/mac80211: Add fallback mechanism for INDOOR_SP connection wifi: cfg80211/mac80211: clean up duplicate ap_power handling wifi: cfg80211: use a C99 initializer in wiphy_register wifi: cfg80211: fix doc of struct key_params wifi: mac80211: remove unnecessary vlan NULL check wifi: mac80211: pass frame type to element parsing wifi: mac80211: remove "disabling VHT" message wifi: mac80211: add and use chanctx usage iteration wifi: mac80211: simplify ieee80211_recalc_chanctx_min_def() API wifi: mac80211: remove chanctx to link back-references wifi: mac80211: make link iteration safe for 'break' wifi: mac80211: fix EHT typo wifi: cfg80211: fix EHT typo wifi: ieee80211: split NAN definitions out wifi: ieee80211: split P2P definitions out wifi: ieee80211: split S1G definitions out wifi: ieee80211: split EHT definitions out ... ==================== Link: https://patch.msgid.link/20251112115126.16223-4-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-12Merge tag 'wireless-2025-11-12' of ↵Jakub Kicinski
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless Johannes Berg says: ==================== Couple more fixes: - mwl8k: work around FW expecting a DSSS element in beacons - ath11k: report correct TX status - iwlwifi: avoid toggling links due to wrong element use - iwlwifi: fix beacon template rate on older devices - iwlwifi: fix loop iterator being used after loop - mac80211: disallow address changes while using the address - mac80211: avoid bad rate warning in monitor/sniffer mode - hwsim: fix potential NULL deref (on monitor injection) * tag 'wireless-2025-11-12' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless: wifi: iwlwifi: mld: always take beacon ies in link grading wifi: iwlwifi: mvm: fix beacon template/fixed rate wifi: iwlwifi: fix aux ROC time event iterator usage wifi: mwl8k: inject DSSS Parameter Set element into beacons if missing wifi: mac80211_hwsim: Fix possible NULL dereference wifi: mac80211: skip rate verification for not captured PSDUs wifi: mac80211: reject address change while connecting wifi: ath11k: zero init info->status in wmi_process_mgmt_tx_comp() ==================== Link: https://patch.msgid.link/20251112114621.15716-5-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-12drm/nouveau/drm: Bump the driver version to 1.4.1 to report new featuresMohamed Ahmed
The HW can only do compression on large and huge pages, and enabling it on 4K pages leads to a MMU fault. Compression also needs kernel support for handling the compressed kinds and managing the compression tags. This increments the nouveau version number which allows NVK to enable it only when the kernel actually supports both features and avoid breaking the system if a newer mesa version is paired with an older kernel version. For the associated userspace MR, please see !36450: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36450 Signed-off-by: Mohamed Ahmed <mohamedahmedegypt2001@gmail.com> Signed-off-by: Mary Guillemard <mary@mary.zone> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: James Jones <jajones@nvidia.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patch.msgid.link/20251110-nouveau-compv6-v6-5-83b05475f57c@mary.zone
2025-11-12drm/nouveau/mmu/tu102: Add support for compressed kindsBen Skeggs
Allow compressed PTE kinds to be written into PTEs when GSP-RM is present, rather than reverting to their non-compressed versions. Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Signed-off-by: Mohamed Ahmed <mohamedahmedegypt2001@gmail.com> Signed-off-by: Mary Guillemard <mary@mary.zone> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: James Jones <jajones@nvidia.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patch.msgid.link/20251110-nouveau-compv6-v6-4-83b05475f57c@mary.zone
2025-11-12drm/nouveau/mmu/gp100: Remove unused/broken support for compressionBen Skeggs
From GP100 onwards it's not possible to initialise comptag RAM without PMU firmware, which nouveau has no support for. As such, this code is essentially a no-op and will always revert to the equivalent non-compressed kind due to comptag allocation failure. It's also broken for the needs of VM_BIND/Vulkan. Remove the code entirely to make way for supporting compression on GPUs that support GSM-RM. Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Signed-off-by: Mohamed Ahmed <mohamedahmedegypt2001@gmail.com> Signed-off-by: Mary Guillemard <mary@mary.zone> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: James Jones <jajones@nvidia.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patch.msgid.link/20251110-nouveau-compv6-v6-3-83b05475f57c@mary.zone
2025-11-12drm/nouveau/uvmm: Allow larger pagesMary Guillemard
Now that everything in UVMM knows about the variable page shift, we can select larger values. The proposed approach relies on nouveau_bo::page unless if it would cause alignment issues (in which case we fall back to searching for an appropriate shift) Signed-off-by: Mary Guillemard <mary@mary.zone> Co-developed-by: Mohamed Ahmed <mohamedahmedegypt2001@gmail.com> Signed-off-by: Mohamed Ahmed <mohamedahmedegypt2001@gmail.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: James Jones <jajones@nvidia.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patch.msgid.link/20251110-nouveau-compv6-v6-2-83b05475f57c@mary.zone
2025-11-12drm/nouveau/uvmm: Prepare for larger pagesMary Guillemard
Currently memory allocated by VM_BIND uAPI can only have a granuality matching PAGE_SIZE (4KiB in common case) To have a better memory management and to allow big (64KiB) and huge (2MiB) pages later in the series, we are now passing the page shift all around the internals of UVMM. Signed-off-by: Mary Guillemard <mary@mary.zone> Co-developed-by: Mohamed Ahmed <mohamedahmedegypt2001@gmail.com> Signed-off-by: Mohamed Ahmed <mohamedahmedegypt2001@gmail.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: James Jones <jajones@nvidia.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patch.msgid.link/20251110-nouveau-compv6-v6-1-83b05475f57c@mary.zone
2025-11-12net: stmmac: improve ndev->max_mtu setup readabilityRussell King (Oracle)
Improve the readibility of the code setting ndev->max_mtu. This depends on the hardware specific maximum defined by the MAC core, and also a platform provided maximum. The code was originally checking that the platform specific maximum was between ndev->min_mtu..MAC core maximum before reducing ndev->max_mtu, otherwise if the platform specific maximum was less than ndev->min_mtu, issuing a warning. Re-order the code to handle the case where the platform specific max is below ndev->min_mtu, which then means that the subsequent test is simply reducing ndev->max_mtu. Update the comment, and add a few blank lines to separate the blocks of code. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1vImWA-0000000DrIl-1HZY@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-12drm/xe/pf: Allow to lockdown the PF using custom guardMichal Wajdeczko
Some driver components, like eudebug or ccs-mode, can't be used when VFs are enabled. Add functions to allow those components to block the PF from enabling VFs for the requested duration. Introduce trivial counter to allow lockdown or exclusive access that can be used in the scenarios where we can't follow the strict owner semantics as required by the rw_semaphore implementation. Before enabling VFs, the PF will try to arm the "vfs_enabling" guard for the exclusive access. This will fail if there are some lockdown requests already initiated by the other components. For testing purposes, add debugfs file which will call these new functions from the file's open/close hooks. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Christoph Manszewski <christoph.manszewski@intel.com> Reviewed-by: Christoph Manszewski <christoph.manszewski@intel.com> Link: https://patch.msgid.link/20251109162451.4779-1-michal.wajdeczko@intel.com
2025-11-12r8169: add support for RTL8125Kjaven
This adds support for chip RTL8125K. Its XID is 0x68a. It is basically based on the one with XID 0x688, but with different firmware file. Signed-off-by: javen <javen_xu@realsil.com.cn> Reviewed-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://patch.msgid.link/20251111092851.3371-1-javen_xu@realsil.com.cn Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-12null_blk: fix zone read length beyond write pointerKeith Busch
Fix up the divisor calculating the number of zone sectors being read and handle a read that straddles the zone write pointer. The length is rounded up a sector boundary, so be sure to truncate any excess bytes off to avoid copying past the data segment. Fixes: 3451cf34f51bb70 ("null_blk: allow byte aligned memory offsets") Signed-off-by: Keith Busch <kbusch@kernel.org> Tested-by: Bart van Assche <bvanassche@acm.org> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-11-12cpufreq: intel_pstate: Check IDA only before MSR_IA32_PERF_CTL writesSrinivas Pandruvada
Commit ac4e04d9e378 ("cpufreq: intel_pstate: Unchecked MSR aceess in legacy mode") introduced a check for feature X86_FEATURE_IDA to verify turbo mode support. Although this is the correct way to check for turbo mode support, it causes issues on some platforms that disable turbo during OS boot, but enable it later [1]. Before adding this feature check, users were able to get turbo mode frequencies by writing 0 to /sys/devices/system/cpu/intel_pstate/no_turbo post-boot. To restore the old behavior on the affected systems while still addressing the unchecked MSR issue on some Skylake-X systems, check X86_FEATURE_IDA only immediately before updates of MSR_IA32_PERF_CTL that may involve setting the Turbo Engage Bit (bit 32). Fixes: ac4e04d9e378 ("cpufreq: intel_pstate: Unchecked MSR aceess in legacy mode") Reported-by: Aaron Rainbolt <arainbolt@kfocus.org> Closes: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2122531 [1] Tested-by: Aaron Rainbolt <arainbolt@kfocus.org> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> [ rjw: Subject adjustment, changelog edits ] Link: https://patch.msgid.link/20251111010840.141490-1-srinivas.pandruvada@linux.intel.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-11-12drm/xe/pcode: Rework error mappingLucas De Marchi
The sparse array used for error decoding from is unnecessarily big. It should be better handled by a switch statement that will also allow us to more easily improve this code. Add a CASE_ERR() macro to keep the table compact and use it instead of the 256-entries array, which saves some space: $ bloat-o-meter xe_pcode.o.old xe_pcode.o add/remove: 0/1 grow/shrink: 2/0 up/down: 190/-4096 (-3906) Function old new delta __pcode_mailbox_rw 363 465 +102 __pcode_mailbox_rw.cold 58 146 +88 err_decode 4096 - -4096 Total: Before=7890, After=3984, chg -49.51% Reviewed-by: Raag Jadav <raag.jadav@intel.com> Link: https://patch.msgid.link/20251110-pcode-errmap-v2-1-cb18c8f54238@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-11-12coresight: etm4x: Remove the state_needs_restore flagLeo Yan
When the restore flow is invoked, it means no error occurred during the save phase. Otherwise, if any errors happened while saving the context, the function would return an error and abort the suspend sequence. Therefore, the state_needs_restore flag is unnecessary. The save and restore functions are changed to check two conditions: 1) The global flag pm_save_enable is SELF_HOSTED mode; 2) The device is in active mode (non DISABLED). Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com> Reviewed-by: Mike Leach <mike.leach@linaro.org> Tested-by: James Clark <james.clark@linaro.org> Signed-off-by: Leo Yan <leo.yan@arm.com> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Link: https://lore.kernel.org/r/20251111-arm_coresight_power_management_fix-v6-8-f55553b6c8b3@arm.com
2025-11-12phy: sophgo: Remove unused of_gpio.hAndy Shevchenko
of_gpio.h is deprecated and subject to remove. The driver doesn't use it, simply remove the unused header. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-11-12drm/i915/dp_mst: Disable Panel ReplayImre Deak
Disable Panel Replay on MST links until it's properly implemented. For instance the required VSC SDP is not programmed on MST and FEC is not enabled if Panel Replay is enabled. Fixes: 3257e55d3ea7 ("drm/i915/panelreplay: enable/disable panel replay") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/15174 Cc: Jouni Högander <jouni.hogander@intel.com> Cc: Animesh Manna <animesh.manna@intel.com> Cc: stable@vger.kernel.org # v6.8+ Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20251107124141.911895-1-imre.deak@intel.com (cherry picked from commit e109f644b871df8440c886a69cdce971ed533088) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-11-12drm/xe: fix kernel-doc function name mismatch in xe_pm.cKriish Sharma
Documentation build reported: WARNING: ./drivers/gpu/drm/xe/xe_pm.c:131 expecting prototype for xe_pm_might_block_on_suspend(). Prototype was for xe_pm_block_on_suspend() instead The kernel-doc comment for xe_pm_block_on_suspend() incorrectly used the function name xe_pm_might_block_on_suspend(). Fix the header to match the actual function prototype. No functional changes. Fixes: f73f6dd312a5 ("drm/xe/pm: Add lockdep annotation for the pm_block completion") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202511061736.CiuroL7H-lkp@intel.com/ Signed-off-by: Kriish Sharma <kriish.sharma2006@gmail.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20251110184206.2113830-1-kriish.sharma2006@gmail.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-11-12phy: phy-can-transceiver: Support TJA1048/TJA1051Vinod Koul
Peng Fan <peng.fan@nxp.com> says: TJA1048 is a Dual channel can transceiver with Sleep mode supported. TJA105{1,7} is a Single Channel can transceiver with Sleep mode supported. Link: https://patch.msgid.link/20251001-can-v7-0-fad29efc3884@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-11-12phy: phy-can-transceiver: Add support for TJA105{1,7}Peng Fan
Support TJA105{1,7} which are a single channel high-speed CAN transceiver with silent mode supported. phy mode is not implemented as of now. silent settings are kept in phy_power_on and phy_power_off. After phy mode is supported, the silent settings could be moved to phy_set_mode. Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com> Acked-by: Marc Kleine-Budde <mkl@pengutronix.de> Link: https://patch.msgid.link/20251001-can-v7-5-fad29efc3884@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-11-12phy: phy-can-transceiver: Drop the gpio desc checkPeng Fan
gpiod_set_value_cansleep has an internal check on gpio_desc using 'VALIDATE_DESC(desc)', the check before invoking gpiod_set_value_cansleep could be removed. Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com> Acked-by: Marc Kleine-Budde <mkl@pengutronix.de> Link: https://patch.msgid.link/20251001-can-v7-4-fad29efc3884@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-11-12phy: phy-can-transceiver: Add dual channel support for TJA1048Peng Fan
- Introduce new flag CAN_TRANSCEIVER_DUAL_CH to indicate the phy has two channels. - Alloc a phy for each channel - Support TJA1048 which is a dual high-speed CAN transceiver with sleep mode supported. - Add can_transceiver_phy_xlate for parsing phy Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com> Acked-by: Marc Kleine-Budde <mkl@pengutronix.de> Link: https://patch.msgid.link/20251001-can-v7-3-fad29efc3884@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-11-12phy: phy-can-transceiver: Introduce can_transceiver_privPeng Fan
To prepare for dual-channel phy support, introduce can_transceiver_priv as a higher level encapsulation for phy. No functional changes. Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com> Acked-by: Marc Kleine-Budde <mkl@pengutronix.de> Link: https://patch.msgid.link/20251001-can-v7-2-fad29efc3884@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>