summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2026-06-26Merge tag 'regmap-fix-v7.2-merge-window' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap Pull regmap fix from Mark Brown: "Ensure that we don't overwrite the error code when cleaning up a failed cache initialisation, helping people debug issues if they do arise" * tag 'regmap-fix-v7.2-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap: regcache: Do not overwrite error code when finalizing cache after error
2026-06-26Merge branch 'thermal-testing'Rafael J. Wysocki3-8/+43
Merge a fix eliminating a possibility of running the thermal testing module code after that module has been removed. * thermal-testing: thermal: testing: zone: Flush work items during cleanup
2026-06-26Merge branch 'pm-cpuidle'Rafael J. Wysocki1-8/+0
Merge a cpuidle core fix that removes a misguided warning along with an inaccurate comment next to it. * pm-cpuidle: cpuidle: Allow exit latency to exceed target residency
2026-06-26Merge branches 'acpi-sysfs', 'acpi-resource', 'acpi-driver' and 'acpi-processor'Rafael J. Wysocki5-14/+14
Merge an update of comments regarding the ACPI sysfs code, a kernel-doc style fixup update of ACPI resource management, and ACPI IPMI driver fix, and an ACPI processor driver fix for 7.2-rc1: - Fix module parameter file paths in comments in the ACPI code managing the general sysfs attributes (Zenghui Yu) - Update kerneldoc comments in the ACPI resource management code to follow the common style (Andy Shevchenko) - Fix inverted interface check in ipmi_bmc_gone() which may cause ACPI IPMI interfaces to be mishandled (Xu Rao) - Add __cpuidle to idle state management functions related to ACPI _LPI to avoid trace-induced RCU warnings (Li RongQing) * acpi-sysfs: ACPI: sysfs: Fix path of module parameters in comments * acpi-resource: ACPI: resource: Amend kernel-doc style * acpi-driver: ACPI: IPMI: Fix inverted interface check in ipmi_bmc_gone() * acpi-processor: ACPI: processor_idle: Mark LPI enter functions as __cpuidle
2026-06-26drm/i915: Refactor generic_handle_irq_safe() error messagesJonathan Cavitt2-2/+2
Refactor all error messages resulting from generic_handle_irq_safe() failures in I915 for clarity. v2: - Use drm_err_ratelimited() correctly (jcavitt) v3: - Use xe_err_ratelimited() instead (Jadav) - Split into patch series (jcavitt) v4: - Use suggested phrasing (Wajdeczko) v5: - s/PTR_ERR/ERR_PTR (jcavitt) Suggested-by: Raag Jadav <raag.jadav@intel.com> Suggested-by: Michal Wajdeczko <Michal.Wajdeczko@intel.com> Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://lore.kernel.org/r/20260623202310.1023770-1-jonathan.cavitt@intel.com
2026-06-26drm/bridge: of-display-mode-bridge: Fix missing static const for the bridge ↵Damon Ding1-1/+1
funcs Add static qualifier for of_display_mode_bridge_funcs to resolve the sparse warning: drivers/gpu/drm/bridge/of-display-mode-bridge.c:54:25: sparse: sparse: symbol 'of_display_mode_bridge_funcs' was not declared. Should it be static? Also mark the structure const as required by devm_drm_bridge_alloc() parameter type constraints. Fixes: ba2db93cf3d5 ("drm/bridge: Move legacy bridge driver out of imx directory for multi-platform use") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202606170744.FUStcWaB-lkp@intel.com/ Signed-off-by: Damon Ding <damon.ding@rock-chips.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Link: https://patch.msgid.link/20260617080755.186368-1-damon.ding@rock-chips.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-06-26Merge tag 'devicetree-fixes-for-7.2-1' of ↵Linus Torvalds2-2/+10
git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux Pull devicetree fixes from Rob Herring: - Drop unnecessary type reference from khadas,mcu "fan-supply" - Fix clocks in Renesas R-Mobile APE6 example - Add missing Unisoc SC2730 PMIC regulators schema - Fix Amlogic thermal example - kernel-doc fix for of_map_id() - Handle negative index in of_fwnode_get_reference_args() * tag 'devicetree-fixes-for-7.2-1' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux: dt-bindings: mfd: khadas,mcu: Drop type reference from "fan-supply" dt-bindings: clock: renesas: div6: Use ZT/ZTR trace clock in R-Mobile APE6 example regulator: dt-bindings: Add Unisoc SC2730 PMIC dt-bindings: thermal: amlogic: Correct 'reg' in the example dt-bindings: thermal: amlogic: Fix missing header in the example of: Fix RST inline emphasis warnings in of_map_id() kernel-doc of: property: Fix of_fwnode_get_reference_args() with negative index
2026-06-26fbdev: Fix fb_new_modelist to prevent null-ptr-deref in fb_videomode_to_varIan Bridges1-0/+12
info->var, a framebuffer's current mode, is expected to have a matching entry in info->modelist. var_to_display() relies on this and treats a failed fb_match_mode() as "This should not happen". fb_set_var() keeps it true by adding the mode to the list on every change, and do_register_framebuffer() does the same at registration. store_modes() replaces the modelist from userspace. fb_new_modelist() validates the new modes but does not check that info->var still has a match. It relies on fbcon_new_modelist() to re-point consoles, but that only handles consoles mapped to the framebuffer. With fbcon unbound there are none, so info->var is left describing a mode that is no longer in the list. A later console takeover runs var_to_display(), where fb_match_mode() returns NULL and leaves fb_display[i].mode NULL. fbcon_switch() passes it to display_to_var(), and fb_videomode_to_var() dereferences the NULL mode. Keep the current mode in the list in fb_new_modelist(), the same way fb_set_var() does. Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Ian Bridges <icb@fastmail.org> Signed-off-by: Helge Deller <deller@gmx.de>
2026-06-26fbcon: fix NULL pointer dereference for a console without vc_dataIan Bridges1-3/+4
fbcon_new_modelist() runs when a framebuffer's modelist changes. For each console mapped to it with fb_display[i].mode set, it reads vc_cons[i].d and passes the vc_num to fbcon_set_disp(). This assumes a console with a mode set has a vc_data, but it can be NULL. fbcon_set_disp() sets fb_display[i].mode before it checks vc_data, and fbcon_deinit() leaves the mode set after the vc_data is freed. fbcon_new_modelist() then dereferences the NULL vc_data. Keep fb_display[i].mode set only while the console has a vc_data. Check vc_data before setting the mode in fbcon_set_disp(), and clear the mode in fbcon_deinit(). The existing mode check in fbcon_new_modelist() then skips such consoles. Reported-by: syzbot+42525d636f430fd5d983@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=42525d636f430fd5d983 Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Ian Bridges <icb@fastmail.org> Signed-off-by: Helge Deller <deller@gmx.de>
2026-06-26fbdev: fix use-after-free in store_modes()Ian Bridges1-1/+9
store_modes() replaces a framebuffer's modelist with modes from userspace. On success it frees the old modelist with fb_destroy_modelist(). Two fields still point into that freed list. One pointer is fb_display[i].mode, the mode a console is using. fbcon_new_modelist() moves these pointers to the new list. It only does so for consoles still mapped to the framebuffer. An unmapped console is skipped and keeps its stale pointer. Unbinding fbcon, for example, sets con2fb_map[i] to -1 but leaves fb_display[i].mode set. An FBIOPUT_VSCREENINFO ioctl with FB_ACTIVATE_INV_MODE later reaches fbcon_mode_deleted(). That function reads the stale fb_display[i].mode through fb_mode_is_equal(). The read is a use-after-free. The other pointer is fb_info->mode, the current mode. It is set through the mode sysfs attribute. store_modes() does not update fb_info->mode, so it is left pointing into the freed list. show_mode(), the attribute's read handler, dereferences the stale fb_info->mode through mode_string(). The read is a use-after-free. Clear both pointers before freeing the list. Commit a1f305893074 ("fbcon: Set fb_display[i]->mode to NULL when the mode is released") added the helper fbcon_delete_modelist(). It clears every fb_display[i].mode that points into a given list. So far it is called only from the unregister path. Call it from store_modes() too, and set fb_info->mode to NULL. Reported-by: syzbot+81c7c6b52649fd07299d@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=81c7c6b52649fd07299d Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/ajjoDhAi2y4ArSlz@dev/ Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Ian Bridges <icb@fastmail.org> Signed-off-by: Helge Deller <deller@gmx.de>
2026-06-26drm/{i915, xe}: move intel_hpd_cancel_work() to ↵Jani Nikula3-2/+2
intel_display_driver_remove_noirq() intel_hpd_cancel_work() gets called before intel_display_driver_remove_noirq(). Move it there. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Link: https://patch.msgid.link/6be8d033a6c8d0038dc14100d3ee6612d6204770.1781549229.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-06-26drm/{i915, xe}: move opregion cleanup to intel_display_driver_remove_nogem()Jani Nikula3-4/+2
The intel_opregion_cleanup() call should really be in display. Move it at the end of intel_display_driver_probe_noirq(). For xe, this is a completely non-functional change now that the noirq/nogem cleanup calls are in the right order. For i915, this only changes the relative order of intel_opregion_cleanup() and i915_perf_fini(), which should be of no consequence. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Link: https://patch.msgid.link/8ccd49a5945e0560ba22079d686db1268e8e9f7f.1781549229.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-06-26drm/xe/display: change order of intel_display_driver_remove_{nogem, noirq}() ↵Jani Nikula1-1/+1
calls The display driver init and cleanup calls are slightly asymmetric. The cleanup order should be intel_display_driver_remove_noirq() and intel_display_driver_remove_nogem(), not the other way around. This is also what i915 does. Follow suit in xe. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Link: https://patch.msgid.link/afb11c4e11cc4d946f0360aaad1664d004a93f41.1781549229.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-06-26drm/{i915, xe}: move opregion/dram/bw init to intel_display_driver_probe_noirq()Jani Nikula3-37/+20
The intel_opregion_setup(), intel_dram_detect(), and intel_bw_init_hw() calls should really be in display. Move them at the beginning of intel_display_driver_probe_noirq(). This is a completely non-functional change for xe. For i915, the init order changes slightly: - i915_pcode_init() will happen before intel_opregion_setup(). This should be of no consequence. - The intel_gvt_init() calls will happen before the mentioned functions. There's a lot going on in intel_gvt_init(), but it does not look like this should have dependencies on them either. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Link: https://patch.msgid.link/aa37d6443516ae660c2de53aba8ca42e6e6d1a5c.1781549229.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-06-26drm/i915: remove superfluous checks for pdev->msi_enabledJani Nikula1-4/+2
pci_disable_msi() checks for pdev->msi_enabled internally. There's no need to peek at pdev internals in i915. Remove them. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Link: https://patch.msgid.link/71f61eee227178b61af9c1211be8545828a3f3ef.1781549229.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-06-26drm/i915: move intel_display_device_probe() call a level higherJani Nikula1-8/+7
Having display probe be called from i915_driver_create() is slightly misleading, and an artefact from the past. Move the intel_display_device_probe() call a level higher. Use the shared PCI disable error path while at it. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Link: https://patch.msgid.link/c97a8790a5cb1f6b10061286adad8148972c5b3b.1781549229.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-06-26drm/xe/display: skip FORCE_WC and vm_bound check for external dma-bufsMatthew Auld2-2/+4
Currently, xe_display_bo_framebuffer_init() unconditionally attempts to apply XE_BO_FLAG_FORCE_WC to the buffer and rejects the FB creation with -EINVAL if the BO is already VM_BINDed. However, for imported dma-bufs (ttm_bo_type_sg), this check doesn't seem to make much sense since CPU caching policy is entirely controlled by the exporter. Plus there is no place to set this flag, in the first place. Also this is not rejected if not yet vm_binded, but that seems arbitrary since setting or not setting FORCE_WC should a noop either way, at this stage, and whether it is currently VM_BINDed makes no difference. Currently if we run an app and offload rendering to an external dGPU, like NV or another xe device, the dma-buf passed back to the compositor (igpu) will be an actual external import from xe pov, and it will be missing FORCE_WC, and if the compositor side did a VM_BIND before turning into it into an fb the whole thing gets rejected. So it looks like we either need to reject outright, no matter what, or this usecase is valid and we need to loosen the restriction for sg buffers. Proposing here to loosen the restriction. Assisted-by: Gemini:gemini-3.1-pro-preview Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7919 Fixes: 44e694958b95 ("drm/xe/display: Implement display support") Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Maarten Lankhorst <dev@lankhorst.se> Cc: <stable@vger.kernel.org> # v6.12+ Reviewed-by: Maarten Lankhorst <dev@lankhorst.se> Link: https://patch.msgid.link/20260612170501.550816-2-matthew.auld@intel.com
2026-06-26gpio: htc-egpio: use managed gpiochip registrationPengpeng Hou1-1/+5
egpio_probe() registers each nested gpio_chip with gpiochip_add_data() but ignores the return value. If one registration fails, probe still returns success even though one of the chips was not published to gpiolib. Use devm_gpiochip_add_data() and fail probe if any chip registration fails. This lets devres unwind already registered chips and prevents the driver from publishing a partially initialized device. Fixes: a1635b8fe59d ("[ARM] 4947/1: htc-egpio, a driver for GPIO/IRQ expanders with fixed input/output pins") Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Link: https://patch.msgid.link/20260624131828.94139-1-pengpeng@iscas.ac.cn Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-06-26gpio: mvebu: fail probe if gpiochip registration failsPengpeng Hou1-1/+4
mvebu_gpio_probe() registers the GPIO chip with devm_gpiochip_add_data() but ignores the return value. If registration fails, probe continues and leaves later code operating on a GPIO chip that was never published to gpiolib. Return the registration error so the device fails probe cleanly. Fixes: fefe7b092345 ("gpio: introduce gpio-mvebu driver for Marvell SoCs") Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Link: https://patch.msgid.link/20260624131645.86884-1-pengpeng@iscas.ac.cn Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-06-26pinctrl: qcom: Avoid assigning unused private context in test casesSneh Mankad1-3/+0
tlmm_test_rising_while_disabled() sets thread_op_remain to 10, but this variable is only used by the threaded IRQ handler to control the number of GPIO pin toggles. Since tlmm_test_rising_while_disabled() does not register a threaded IRQ handler, the assignment is never used. Similarly, tlmm_test_high() and tlmm_test_low() set intr_op_remain to 9, but the variable is used to denote the IRQ handler the number of times GPIO signal has to be toggled from the hard IRQ handler. Since tlmm_test_high() and tlmm_test_low() themselves toggle the signal and do not require the hard IRQ handler to do it, the assignment is never used. Remove the thread_op_remain assignment from tlmm_test_rising_while_disabled() and intr_op_remain assignment from tlmm_test_high() and tlmm_test_low() test cases. This does not cause any change in functionality. Signed-off-by: Sneh Mankad <sneh.mankad@oss.qualcomm.com> Link: https://patch.msgid.link/20260610-tlmm_test_changes-v2-1-f34536da4717@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-06-26gpio: pca9570: Use I2C match dataPengpeng Hou1-1/+1
The driver stores chip metadata in both the OF match table and the I2C id table, but probe currently reads it with device_get_match_data(). That helper only returns firmware-node match data, so an I2C-id/modalias match can leave chip_data NULL before the driver dereferences it to read ngpio. Use i2c_get_match_data() so the I2C id table driver_data is consumed when firmware match data is not present. Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Link: https://patch.msgid.link/20260624053744.72612-1-pengpeng@iscas.ac.cn Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-06-26power: sequencing: pcie-m2: Add PCI ID for NXP 88W9098 and AW693 BluetoothSherry Sun1-0/+4
88W9098 is a NXP Wi-Fi/BT combo chip with PCI device ID 0x2b43 under Marvell Extended vendor ID. AW693 is a NXP Wi-Fi/BT combo chip with PCI device ID 0x3003 under NXP/Philips vendor ID. Add both chips to pwrseq_m2_pci_ids[] so that the pwrseq-pcie-m2 driver can create the Bluetooth serdev device when these cards are inserted into a PCIe M.2 Key E connector. Both chips use "nxp,88w8987-bt" as the serdev compatible string, which is the entry point for the btnxpuart driver. The driver identifies the actual chip variant at runtime via chip ID auto-detection and loads the appropriate firmware accordingly. Signed-off-by: Sherry Sun <sherry.sun@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20260626023126.2189931-3-sherry.sun@oss.nxp.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-06-26drm/xe: Return error on non-migratable faults requiring devmemMatthew Brost1-4/+2
Non-migratable faults that require devmem incorrectly jump to the 'out' label, which squashes the error code intended to be returned to the upper layers. Fix this by returning -EACCES instead. Reported-by: Sashiko <sashiko-bot@kernel.org> Fixes: 4208fac3dce5 ("drm/xe: Add more SVM GT stats") Cc: stable@vger.kernel.org Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Francois Dugast <francois.dugast@intel.com> Link: https://patch.msgid.link/20260617135101.1245574-1-matthew.brost@intel.com
2026-06-26gpio: realtek: Add driver for Realtek DHC RTD1625 SoCTzuyi Chang3-0/+624
Add support for the GPIO controller found on Realtek DHC RTD1625 SoCs. Unlike the existing Realtek GPIO driver (drivers/gpio/gpio-rtd.c), which manages pins via shared bank registers, the RTD1625 introduces a per-pin register architecture. Each GPIO line now has its own dedicated 32-bit control register to manage configuration independently, including direction, output value, input value, interrupt enable, and debounce. Therefore, this distinct hardware design requires a separate driver. Additionally, the RTD1625 GPIO controller has a specific hardware quirk: it fires both 'assert' and 'de-assert' interrupts simultaneously on any edge toggle. To handle this, we utilize the polarity register to route the requested edge (rising/falling) to the 'assert' IRQ line. The driver then filters out the unwanted 'de-assert' interrupt in the IRQ handler and pre-clears edge interrupts to prevent interrupt storms caused by unhandled dropped interrupts. Interrupt support is optional for this device, matching the dt-bindings. If the interrupts property is not provided, the driver simply skips IRQ initialization and operates purely as a basic GPIO controller. Reviewed-by: Linus Walleij <linusw@kernel.org> Signed-off-by: Tzuyi Chang <tychang@realtek.com> Co-developed-by: Yu-Chun Lin <eleanor.lin@realtek.com> Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com> Link: https://patch.msgid.link/20260622092335.1166876-4-eleanor.lin@realtek.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-06-26gpio: Replace "default y" with "default ARCH_REALTEK" in KconfigYu-Chun Lin1-1/+1
Replace "default y" with "default ARCH_REALTEK" to avoid bloating the build for non-Realtek platforms when COMPILE_TEST is enabled on other platforms. Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com> Link: https://patch.msgid.link/20260622092335.1166876-3-eleanor.lin@realtek.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-06-26gpio: tb10x: remove unnecessary bracesIgor Putko1-2/+1
Fix the checkpatch.pl warning by removing unnecessary braces from a single-statement if-block in tb10x_gpio_probe(). Signed-off-by: Igor Putko <igorpetindev@gmail.com> Link: https://patch.msgid.link/20260618155626.18751-4-igorpetindev@gmail.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-06-26gpio: tb10x: use unsigned int instead of bare unsignedIgor Putko1-1/+1
Fix the checkpatch.pl warning by using 'unsigned int' instead of the bare use of 'unsigned' for the offset parameter in tb10x_gpio_to_irq(). Signed-off-by: Igor Putko <igorpetindev@gmail.com> Link: https://patch.msgid.link/20260618155626.18751-3-igorpetindev@gmail.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-06-26gpio: rockchip: use platform_get_irq() to retrieve interruptMarco Scardovi1-3/+4
The driver currently uses irq_of_parse_and_map() to parse and map the GPIO bank interrupt from the device tree node. Since the bank device is represented by a platform_device, use the standard platform_get_irq() API instead. This integrates cleanly with the platform device framework and ensures proper error propagation (such as -EPROBE_DEFER). Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Marco Scardovi <scardracs@disroot.org> Link: https://patch.msgid.link/20260607230504.35392-4-scardracs@disroot.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-06-26gpio: rockchip: use devm_platform_ioremap_resource() to map registersMarco Scardovi1-7/+2
Currently, the driver retrieves the memory resource with of_address_to_resource() and maps it with devm_ioremap_resource(). Since the bank device is a platform_device, simplify and modernize the code by using devm_platform_ioremap_resource(). This also removes the need for the local struct resource variable. Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Marco Scardovi <scardracs@disroot.org> Link: https://patch.msgid.link/20260607230504.35392-3-scardracs@disroot.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-06-26Merge tag 'asoc-fix-v7.2-merge-window' of ↵Takashi Iwai1-28/+0
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v7.2 We've got a good collection of device specific fix here, plus a couple of stand out things: - Richard fixed some special cases with the new device_link creation by more gracefully handling any errors during creation. - Charles did some light refactoring of the SoundWire interfaces to fix some persistent randconfig issues that people kept running into.
2026-06-25Input: synaptics-rmi4 - bound the F30 keymap to the GPIO/LED countBryam Vargas1-1/+1
rmi_f30_map_gpios() allocates gpioled_key_map with min(gpioled_count, TRACKSTICK_RANGE_END) == at most 6 entries, but rmi_f30_attention() iterates the full f30->gpioled_count (device query register, range 0..31) and dereferences gpioled_key_map[i], and input->keycodemax is set to the full gpioled_count while input->keycode points at the 6-entry allocation. A device that reports gpioled_count > 6 with GPIO support enabled therefore causes an out-of-bounds read on the attention interrupt and out-of-bounds read/write through the EVIOCGKEYCODE/EVIOCSKEYCODE ioctls, which bound the index only against keycodemax. This is the same defect as the F3A handler, which was copied from F30. Size the keymap for the full gpioled_count; the mapping loop still assigns only the first min(gpioled_count, TRACKSTICK_RANGE_END) entries. Fixes: 3e64fcbdbd10 ("Input: synaptics-rmi4 - limit the range of what GPIOs are buttons") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me> Link: https://patch.msgid.link/20260614-b4-disp-818d6bda-v1-2-cf39a3615085@proton.me Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-06-25Input: synaptics-rmi4 - bound the F3A keymap to the GPIO countBryam Vargas1-1/+1
rmi_f3a_initialize() takes the GPIO count from the device query register (f3a->gpio_count = buf & RMI_F3A_GPIO_COUNT, range 0..127). rmi_f3a_map_gpios() then allocates gpio_key_map with min(gpio_count, TRACKSTICK_RANGE_END) == at most 6 entries, but rmi_f3a_attention() iterates the full gpio_count and dereferences gpio_key_map[i], and input->keycodemax is set to the full gpio_count while input->keycode points at the 6-entry allocation. A device that reports gpio_count > 6 therefore causes an out-of-bounds read of gpio_key_map[] on every attention interrupt, and out-of-bounds accesses through the input core's default keymap ioctls: EVIOCGKEYCODE reads past the buffer (leaking adjacent slab memory to user space) and EVIOCSKEYCODE writes a caller-controlled value past it, for any process able to open the evdev node, since input_default_getkeycode() and input_default_setkeycode() only bound the index against keycodemax. Size the keymap for the full gpio_count. The mapping loop is unchanged: it still assigns only the first min(gpio_count, TRACKSTICK_RANGE_END) entries; the remaining slots stay KEY_RESERVED (devm_kcalloc zero-fills) and are skipped when reporting. Fixes: 9e4c596bfd00 ("Input: synaptics-rmi4 - add support for F3A") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me> Link: https://patch.msgid.link/20260614-b4-disp-818d6bda-v1-1-cf39a3615085@proton.me Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-06-26Merge tag 'drm-misc-fixes-2026-06-25' of ↵Dave Airlie12-27/+45
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes drm-misc-fixes for v7.2: - drm/sysfb truncation and alignment fixes. - fix edid OOB read. - fix error handling paths in nouveau - amdxdna get_bo_info fix. - increase displayid topology id to correct size. - fix leak when error handling in ivpu. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patch.msgid.link/2d17f718-43f5-4772-9c04-a975c9ad4bc3@linux.intel.com
2026-06-26Merge tag 'drm-intel-next-fixes-2026-06-25-1' of ↵Dave Airlie2-7/+35
https://gitlab.freedesktop.org/drm/i915/kernel into drm-next - Fix corrupted display output on GLK, #16209 (Ville) - Add missing Spectre mitigation for parallel submit IOCTL (Joonas) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patch.msgid.link/ajzIhInnHnGCwMlu@jlahtine-mobl
2026-06-25Merge tag 'clk-for-linus' of ↵Linus Torvalds73-440/+13976
git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux Pull clk updates from Stephen Boyd: "This is all clk driver updates. Mostly new SoC support for various Qualcomm chips and Canaan K230. Otherwise there's non-critical fixes and updates to clk data such as adding missing clks to existing drivers or marking clks critical. Nothing looks especially exciting" * tag 'clk-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux: (106 commits) clk: qcom: regmap-phy-mux: Rework the implementation clk: qcom: a53: Corrected frequency multiplier for 1152MHz clk: qcom: camcc-milos: Declare icc path dependency for CAMSS_TOP_GDSC clk: qcom: gdsc: Support enabling interconnect path for power domain dt-bindings: clock: qcom,milos-camcc: Document interconnect path interconnect: Add devm_of_icc_get_by_index() as exported API for users clk: qcom: camcc-x1p42100: Add support for camera clock controller clk: qcom: camcc-x1e80100: Add support for camera QDSS debug clocks clk: qcom: videocc-x1p42100: Add support for video clock controller dt-bindings: clock: qcom: Add X1P42100 camera clock controller dt-bindings: clock: qcom: Add X1P42100 video clock controller clk: keystone: sci-clk: fix application of sizeof to pointer clk: keystone: don't cache clock rate clk: spacemit: k3: Add PCIe DBI clock dt-bindings: soc: spacemit: k3: Add PCIe DBI clock IDs clk: spacemit: k3: Fix PCIe clock register offset clk: spacemit: k3: Switch to pll2_d6 as parent for PCIe clock clk: at91: keep securam node alive while mapping it clk: samsung: exynos990: Fix PERIC0/1 USI clock types clk: renesas: r9a08g045: Drop unused pm_domain header file ...
2026-06-25Merge tag 'spmi-for-linus' of ↵Linus Torvalds2-32/+114
git://git.kernel.org/pub/scm/linux/kernel/git/sboyd/spmi Pull SPMI updates from Stephen Boyd: "Support for Qualcomm PMIC arbiter v8.5 and Hawi along with a kernel doc cleanup and a kzalloc flex usage" * tag 'spmi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sboyd/spmi: spmi: use kzalloc_flex in main allocation spmi: clean up kernel-doc in spmi.h spmi: spmi-pmic-arb: add support for PMIC arbiter v8.5 dt-bindings: spmi: glymur-spmi-pmic-arb: Add compatible for Qualcomm Hawi SoC
2026-06-25Merge tag 'net-7.2-rc1' of ↵Linus Torvalds82-391/+848
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from Jakub Kicinski: "Including fixes from netfilter and IPsec. Current release - regressions: - do not acquire dev->tx_global_lock in netdev_watchdog_up() - ethtool: keep rtnl_lock for ops using ethtool_op_get_link() - fix deadlock in nested UP notifier events Current release - new code bugs: - eth: - cn20k: fix subbank free list indexing for search order - airoha: fix BQL underflow in shared QDMA TX ring Previous releases - regressions: - netfilter: - flowtable: fix offloaded ct timeout never being extended - nf_conncount: prevent connlimit drops for early confirmed ct Previous releases - always broken: - require CAP_NET_ADMIN in the originating netns when modifying cross-netns devices - report NAPI thread PID in the caller's pid namespace - mac802154: fix dirty frag in in-place crypto for IOT radios - sctp: hold socket lock when dumping endpoints in sctp_diag, avoid an overflow - eth: gve: fix header buffer corruption with header-split and HW-GRO - af_key: initialize alg_key_len for IPComp states, prevent OOB read" * tag 'net-7.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (213 commits) selftests: bonding: add a test for VLAN propagation over a bonded real device vlan: defer real device state propagation to netdev_work net: add the driver-facing netdev_work scheduling API net: turn the rx_mode work into a generic netdev_work facility net: ethtool: keep rtnl_lock for ops using ethtool_op_get_link() rxrpc: Fix rxrpc_rotate_tx_rotate() to check there's something to rotate rxrpc: Fix leak of released call in recvmsg(MSG_PEEK) rxrpc: Fix socket notification race rxrpc: Fix potential infinite loop in rxrpc_recvmsg() rxrpc: Fix oob challenge leak in cleanup after notification failure rxrpc: Fix the reception of a reply packet before data transmission afs: Fix uncancelled rxrpc OOB message handler afs: Fix further netns teardown to cancel the preallocation charger rxrpc: Fix double unlock in rxrpc_recvmsg() rxrpc: Fix leak of connection from OOB challenge rxrpc: Fix ACKALL packet handling net: hns3: differentiate autoneg default values between copper and fiber net: hns3: fix permanent link down deadlock after reset net: hns3: refactor MAC autoneg and speed configuration net: hns3: unify copper port ksettings configuration path ...
2026-06-25ACPI: RIMT: Only defer the IOMMU configuration in init stageYicong Yang1-3/+4
The IOMMU configuration will be deferred if the IOMMU driver isn't probed by the time. Make this deferral only in the initialization stage with driver_deferred_probe_check_state(). Otherwise the devices depends on IOMMU will be deferred forever in case the IOMMU device probe failed or it doesn't appear in the ACPI namespace. Fixes: 8f7729552582 ("ACPI: RISC-V: Add support for RIMT") Signed-off-by: Yicong Yang <yang.yicong@picoheart.com> Link: https://patch.msgid.link/20260625094702.11558-1-yang.yicong@picoheart.com [pjw@kernel.org: added Fixes line] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-06-25net: ethtool: keep rtnl_lock for ops using ethtool_op_get_link()Jakub Kicinski7-6/+14
Breno reports following splats on mlx5: RTNL: assertion failed at net/core/dev.c (2241) WARNING: net/core/dev.c:2241 at netif_state_change+0xed/0x130, CPU#5: ethtool/1335 RIP: 0010:netif_state_change+0xf9/0x130 Call Trace: <TASK> __linkwatch_sync_dev+0xea/0x120 ethtool_op_get_link+0xe/0x20 __ethtool_get_link+0x26/0x40 linkstate_prepare_data+0x51/0x200 ethnl_default_doit+0x213/0x470 genl_family_rcv_msg_doit+0xdd/0x110 Looks like I missed ethtool_op_get_link() trying to sync linkwatch, which needs rtnl_lock. Not all drivers do this - bnxt doesn't, it just returns the link state, so add an opt-in bit. Reported-by: Breno Leitao <leitao@debian.org> Fixes: 45079e00133e ("net: ethtool: optionally skip rtnl_lock on Netlink path for GET ops") Acked-by: Stanislav Fomichev <sdf@fomichev.me> Reviewed-by: Breno Leitao <leitao@debian.org> Acked-by: Harshitha Ramamurthy <hramamurthy@google.com> Link: https://patch.msgid.link/20260624190439.2521219-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-25Merge tag 'block-7.2-20260625' of ↵Linus Torvalds21-165/+279
git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux Pull block fixes from Jens Axboe: - blk-cgroup locking rework and fixes: - fix a use-after-free in __blkcg_rstat_flush() - defer freeing policy data until after an RCU grace period - defer the blkcg css_put until the blkg is unlinked from the queue - unwind the queue_lock nesting under RCU / blkcg->lock across the lookup, create, associate and destroy paths - NVMe fixes via Keith: - Fix a crash and memory leak during invalid cdev teardown, and related cdev cleanups (Maurizio, John) - nvmet fixes: handle TCP_CLOSING in the tcp state_change handler, reject short AUTH_RECEIVE buffers, handle inline data with a nonzero offset in rdma, fix an sq refcount leak, and allocate ana_state with the port (Maurizio, Michael, Bryam, Wentao, Rosen) - nvme-fc fix to not cancel requests on an IO target before it is initialized (Mohamed) - nvme-apple fix to prevent shared tags across queues on Apple A11 (Nick) - Various smaller fixes and cleanups (John) - MD fixes via Yu Kuai: - raid1/raid10 fixes for writes_pending and barrier reference leaks on write and discard failures, plus REQ_NOWAIT handling fixes (Abd-Alrhman) - raid5 discard accounting and validation, and a batch of fixes for stripe batch races (Yu Kuai, Chen) - Protect raid1 head_position during read balancing (Chen) - block bio-integrity fixes: correct an error injection static key decrement, fix GFP flag confusion in bio_integrity_alloc_buf(), and handle REQ_OP_ZONE_APPEND in __bio_integrity_action() (Christoph) - Fixes for bio_iov_iter_bounce_write(): revert the iov_iter after a short copy, and respect the iov_iter nofault flag (Qu) - Invalidate the cached plug timestamp after a task switch, and clear PF_BLOCK_TS in copy_process() (Usama) - Fix the IORING_URING_CMD_REISSUE flags check in blkdev_uring_cmd() (Yitang) - Remove a redundant plug in __submit_bio() (Wen) - Don't warn when reclassifying a busy socket lock in nbd (Deepanshu) * tag 'block-7.2-20260625' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux: (45 commits) block: handle REQ_OP_ZONE_APPEND in __bio_integrity_action block: fix GFP_ flags confusion in bio_integrity_alloc_buf block, bfq: don't grab queue_lock to initialize bfq mm/page_io: don't nest queue_lock under rcu in bio_associate_blkg_from_page() blk-cgroup: don't nest queue_lock under blkcg->lock in blkcg_destroy_blkgs() blk-cgroup: don't nest queue_lock under rcu in bio_associate_blkg() blk-cgroup: don't nest queue_lock under rcu in blkg_lookup_create() blk-cgroup: don't nest queue_lock under rcu in blkcg_print_blkgs() blk-cgroup: delay freeing policy data after rcu grace period blk-cgroup: protect iterating blkgs with blkcg->lock in blkcg_print_stat() md/raid5: avoid R5_Overlap races while breaking stripe batches md/raid5: use stripe state snapshot in break_stripe_batch_list() blk-cgroup: defer blkcg css_put until blkg is unlinked from queue blk-cgroup: fix UAF in __blkcg_rstat_flush() block, bfq: protect async queue reset with blkcg locks nbd: don't warn when reclassifying a busy socket lock block: fix incorrect error injection static key decrement md/raid5: let stripe batch bm_seq comparison wrap-safe md/raid1: protect head_position for read balance md/raid1: free r1_bio when REQ_NOWAIT is set and read would block on retry ...
2026-06-25spi: core: Abort active target transfer on controller suspendPraveen Talari1-0/+3
When an SPI controller operating in target mode has a transfer in progress at the time of system suspend, the suspend path proceeds without aborting the ongoing transfer. This can leave the hardware in an inconsistent state, potentially causing the system to hang or fail to resume cleanly. Fix this by invoking the controller's target_abort callback from spi_controller_suspend() when the controller is in target mode and the callback is registered. This ensures any active target transfer is cleanly terminated before the controller is suspended. Signed-off-by: Praveen Talari <praveen.talari@oss.qualcomm.com> Link: https://patch.msgid.link/20260625-abort_active_transfer_duirng_s2r-v2-1-1d6f724406b6@oss.qualcomm.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-06-25fbdev: viafb: return an error when DMA copy times outPengpeng Hou1-2/+5
viafb_dma_copy_out_sg() logs a VIA DMA timeout when the DONE bit is not set after the completion wait and grace delay, but still returns success to the caller. Preserve the existing cleanup sequence and return -ETIMEDOUT when the DMA engine did not report completion. Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Signed-off-by: Helge Deller <deller@gmx.de>
2026-06-25Merge tag 'gpio-fixes-for-v7.2-rc1' of ↵Linus Torvalds9-52/+77
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux Pull gpio fixes from Bartosz Golaszewski: - fix locking context with shared GPIOs in gpio-tegra - fix IRQ domain leak in error path in gpio-davinci - fix returning a potentially uninitialized integer in gpiochip_set_multiple() - use raw spinlock in gpio-eic-sprd and gpio-sch to address locking context issues - bail out of probe() if registering the GPIO chip fails in gpio-mlxbf3 - fix varible type for storing the "ngpios" property in gpio-pisosr - fix out-of-bounds pin access in GPIO ACPI - make GPIO ACPI core only trigger interrupts on boot that are marked as ActiveBoth - fix kerneldoc in gpio-tb10x - reference the real software node of the cs5535 GPIO controller in Geode board file * tag 'gpio-fixes-for-v7.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: gpio: davinci: fix IRQ domain leak on devm_kzalloc failure gpio: tegra: do not call pinctrl for GPIO direction gpio: tb10x: fix struct tb10x_gpio kernel-doc gpiolib: initialize return value in gpiochip_set_multiple() x86/platform/geode: reference the real node of the cs5535 GPIO controller gpio: eic-sprd: use raw_spinlock_t in the irq startup path gpio: sch: use raw_spinlock_t in the irq startup path gpiolib: acpi: Prevent out-of-bounds pin access in OperationRegion handler gpiolib: acpi: Add robust bounds-checking for GPIO pin resources gpio: mlxbf3: fail probe if gpiochip registration fails gpio: pisosr: Read "ngpios" as u32 gpiolib: acpi: Only trigger ActiveBoth interrupts on boot
2026-06-25fbdev: goldfishfb: fail pan display on base-update timeoutPengpeng Hou1-4/+9
goldfish_fb_pan_display() waits for the device to acknowledge the new framebuffer base, but it only logs a timeout and still reports success. The probe path also ignores the initial pan-display result before registering the framebuffer. Return -ETIMEDOUT when the base-update acknowledgment does not arrive, and propagate that error from the initial probe-time base update before the framebuffer is published. Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Signed-off-by: Helge Deller <deller@gmx.de>
2026-06-25Merge tag 'pwrseq-fixes-for-v7.2-rc1' of ↵Linus Torvalds2-10/+17
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux Pull power sequencing fixes from Bartosz Golaszewski: - fix an ABBA deadlock in pwrseq unregister path - fix a use-after-free bug in pwrseq core - sort PCI device IDs in ascending order in pwrseq-pcie-m2 * tag 'pwrseq-fixes-for-v7.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: power: sequencing: fix ABBA deadlock in pwrseq_device_unregister() power: sequencing: pcie-m2: Sort PCI device IDs in ascending order pwrseq: core: fix use-after-free in pwrseq_debugfs_seq_next()
2026-06-25fbdev: fbcon: fix out-of-bounds read in err_out of fbcon_do_set_font()Mingyu Wang1-0/+7
When fbcon_do_set_font() fails (e.g., due to a memory allocation failure inside vc_resize() under heavy memory pressure), it jumps to the `err_out` label to roll back the console state. However, the current rollback logic forgets to restore the `hi_font` state, leading to a severe state machine corruption. Earlier in the function, `set_vc_hi_font()` might be called to change `vc->vc_hi_font_mask` and mutate the screen buffer. If `vc_resize()` subsequently fails, the `err_out` path restores `vc_font.charcount` but entirely skips rolling back the `vc_hi_font_mask` and the screen buffer. This mismatch leaves the terminal in a desynchronized state. Because `vc_hi_font_mask` remains set, the VT subsystem will still accept character indices greater than 255 from userspace and write them to the screen buffer. Subsequent rendering calls (e.g., `fbcon_putcs()`) will then use these inflated indices to access the reverted, 256-character font array, leading to a deterministic out-of-bounds read and potential kernel memory disclosure. Fix this by adding the missing rollback logic for the `hi_font` mask and screen buffer in the error path. Fixes: a5a923038d70 ("fbdev: fbcon: Properly revert changes when vc_resize() failed") Cc: stable@vger.kernel.org Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Helge Deller <deller@gmx.de>
2026-06-25net: hns3: differentiate autoneg default values between copper and fiberShuaisong Yang1-0/+7
Fix a link loss issue during driver initialization on optical ports connected to forced-mode (non-autoneg) remote switches. Previously, during driver probe or initialization, hclge_configure() blindly hardcoded hdev->hw.mac.req_autoneg to AUTONEG_ENABLE for all media types. While this is necessary for copper (BASE-T) ports to establish a link, many high-speed optical (fiber) ports in data centers are connected to switches running in forced mode (fixed speed, autoneg disabled). Forcing autoneg on these optical ports during initialization causes a permanent link failure since the remote end refuses to respond to autoneg pulses. Fix this by implementing media-type differentiated initialization in hclge_init_ae_dev(). Copper ports continue to default to AUTONEG_ENABLE, while optical ports strictly inherit the preset autoneg status pre-configured by the firmware (hdev->hw.mac.autoneg), preserving native compatibility with forced-mode network environments. Fixes: 05eb60e9648c ("net: hns3: using user configure after hardware reset") Signed-off-by: Shuaisong Yang <yangshuaisong@h-partners.com> Signed-off-by: Jijie Shao <shaojijie@huawei.com> Link: https://patch.msgid.link/20260624141319.271439-5-shaojijie@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-25net: hns3: fix permanent link down deadlock after resetShuaisong Yang1-7/+15
Fix a critical race condition deadlock where the network interface remains permanently Link Down after a hardware reset under specific ethtool sequences. This issue exclusively manifests in firmware-controlled PHY topologies where the driver relies on the IMP firmware to arbitrate link parameters. Standard devices driven by the kernel's native PHY_LIB are unaffected. The deadlock occurs via the following path: 1. User disables autoneg and forces an unmatched speed, forcing link down: `ethtool -s ethx autoneg off speed 10 duplex full` 2. User re-enables autoneg: `ethtool -s ethx autoneg on`. The netdev stack passes cmd->base.speed as SPEED_UNKNOWN (0xffffffff). 3. Driver saves req_autoneg=1, but before the interface can link up, a hardware reset is triggered. 4. During reset recovery, MAC init reads the un-synchronized runtime state mac.autoneg (which is still 0/OFF), misinterprets it as forced mode, and pushes the cached SPEED_UNKNOWN into the hardware registers, causing the MAC firmware state machine to freeze. Meanwhile, PHY init reads req_autoneg=1 and enables PHY autoneg. Since the MAC is frozen with 0xffffffff and PHY is running autoneg, they mismatch permanently. Fix this by: 1. Intercepting SPEED_UNKNOWN/DUPLEX_UNKNOWN in hclge_set_phy_link_ksettings() and hclge_cfg_mac_speed_dup_h() to prevent it from corrupting the driver's cached valid configuration. 2. Save req_autoneg in hclge_set_autoneg(). 3. Aligning the state judgment in hclge_set_autoneg_speed_dup() to use req_autoneg instead of the un-synchronized runtime mac.autoneg, ensuring both MAC and PHY consistently enter the autoneg branch to eliminate configuration discrepancies during reset recovery. Fixes: 05eb60e9648c ("net: hns3: using user configure after hardware reset") Signed-off-by: Shuaisong Yang <yangshuaisong@h-partners.com> Signed-off-by: Jijie Shao <shaojijie@huawei.com> Link: https://patch.msgid.link/20260624141319.271439-4-shaojijie@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-25net: hns3: refactor MAC autoneg and speed configurationShuaisong Yang2-14/+42
Extract the MAC autoneg and speed/duplex/lane configuration logic out of hclge_mac_init() and encapsulate it into a new dedicated helper function hclge_set_autoneg_speed_dup(). In the init path (hclge_init_ae_dev), this helper is now called after hclge_update_port_info() so that firmware-reported autoneg values are already populated before applying the link configuration. Introduce a separate req_lane_num field in struct hclge_mac to isolate the user-requested lane count from mac.lane_num, which firmware may overwrite via hclge_get_sfp_info() with stale values from a prior link lifecycle (e.g., lane_num=4 from 100G). During probe, req_lane_num is initialized to 0, which instructs firmware to auto-select the correct lane count for the current speed, rather than reusing the firmware- reported mac.lane_num that may be inconsistent with the target speed. This prevents probe failures from mismatched (speed, lane_num) pairs. In the reset path (hclge_reset_ae_dev), it runs immediately after hclge_mac_init(), using the previously cached req_* values to restore the link without re-querying firmware. Signed-off-by: Shuaisong Yang <yangshuaisong@h-partners.com> Signed-off-by: Jijie Shao <shaojijie@huawei.com> Link: https://patch.msgid.link/20260624141319.271439-3-shaojijie@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-25net: hns3: unify copper port ksettings configuration pathShuaisong Yang2-19/+40
Refactor hns3_set_link_ksettings() and hclge_set_phy_link_ksettings() to unify the configuration path for copper ports. Previously, netdevs with a native kernel phy attached bypassed the main MAC parameter caching logic and returned early via phy_ethtool_ksettings_set(). This prevented the driver from updating hdev->hw.mac.req_xxx variables for kernel PHY setups, leaving them out-of-sync during reset recovery. Clean this up by routing all copper port configurations through ops->set_phy_link_ksettings(), and perform driver-level or kernel-level PHY arbitration inside hclge_set_phy_link_ksettings() via hnae3_dev_phy_imp_supported(). This ensures that the user's intended link profiles (req_speed, req_duplex, req_autoneg) are uniformly recorded across all copper and fiber deployment topologies, laying the groundwork for stable reset recovery. For copper ports where neither IMP firmware nor a kernel PHY is available (e.g. PHY_INEXISTENT), hclge_set_phy_link_ksettings() returns -ENODEV. In hns3_set_link_ksettings(), this is caught so the configuration falls through to the existing MAC-level path (check_ksettings_param -> cfg_mac_speed_dup_h), preserving compatibility with PHY-less copper deployments. Signed-off-by: Shuaisong Yang <yangshuaisong@h-partners.com> Signed-off-by: Jijie Shao <shaojijie@huawei.com> Link: https://patch.msgid.link/20260624141319.271439-2-shaojijie@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>