aboutsummaryrefslogtreecommitdiffstats
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
5 daysnet: phy: aquantia: check for NVMEM deferralRobert Marko1-1/+1
Currently, if NVMEM provider is probed later than Aquantia, loading the firmware will fail with -EINVAL. To fix this, simply check for -EPROBE_DEFER when NVMEM is attempted and return it. Fixes: e93984ebc1c8 ("net: phy: aquantia: add firmware load support") Signed-off-by: Robert Marko <robimarko@gmail.com> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/20251127114514.460924-1-robimarko@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
6 daysnet: vxlan: prevent NULL deref in vxlan_xmit_oneAntoine Tenart1-3/+15
Neither sock4 nor sock6 pointers are guaranteed to be non-NULL in vxlan_xmit_one, e.g. if the iface is brought down. This can lead to the following NULL dereference: BUG: kernel NULL pointer dereference, address: 0000000000000010 Oops: Oops: 0000 [#1] SMP NOPTI RIP: 0010:vxlan_xmit_one+0xbb3/0x1580 Call Trace: vxlan_xmit+0x429/0x610 dev_hard_start_xmit+0x55/0xa0 __dev_queue_xmit+0x6d0/0x7f0 ip_finish_output2+0x24b/0x590 ip_output+0x63/0x110 Mentioned commits changed the code path in vxlan_xmit_one and as a side effect the sock4/6 pointer validity checks in vxlan(6)_get_route were lost. Fix this by adding back checks. Since both commits being fixed were released in the same version (v6.7) and are strongly related, bundle the fixes in a single commit. Reported-by: Liang Li <liali@redhat.com> Fixes: 6f19b2c136d9 ("vxlan: use generic function for tunnel IPv4 route lookup") Fixes: 2aceb896ee18 ("vxlan: use generic function for tunnel IPv6 route lookup") Cc: Beniamino Galvani <b.galvani@gmail.com> Signed-off-by: Antoine Tenart <atenart@kernel.org> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Tested-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20251126102627.74223-1-atenart@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
6 daysiavf: Implement settime64 with -EOPNOTSUPPMichal Schmidt1-0/+7
ptp_clock_settime() assumes every ptp_clock has implemented settime64(). Stub it with -EOPNOTSUPP to prevent a NULL dereference. The fix is similar to commit 329d050bbe63 ("gve: Implement settime64 with -EOPNOTSUPP"). Fixes: d734223b2f0d ("iavf: add initial framework for registering PTP clock") Signed-off-by: Michal Schmidt <mschmidt@redhat.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Tim Hostetler <thostet@google.com> Link: https://patch.msgid.link/20251126094850.2842557-1-mschmidt@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
6 daysMerge tag 'net-6.18-rc8' of ↵Linus Torvalds31-183/+425
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from Paolo Abeni: "Including fixes from bluetooth and CAN. No known outstanding regressions. Current release - regressions: - mptcp: initialize rcv_mss before calling tcp_send_active_reset() - eth: mlx5e: fix validation logic in rate limiting Previous releases - regressions: - xsk: avoid data corruption on cq descriptor number - bluetooth: - prevent race in socket write iter and sock bind - fix not generating mackey and ltk when repairing - can: - kvaser_usb: fix potential infinite loop in command parsers - rcar_canfd: fix CAN-FD mode as default - eth: - veth: reduce XDP no_direct return section to fix race - virtio-net: avoid unnecessary checksum calculation on guest RX Previous releases - always broken: - sched: fix TCF_LAYER_TRANSPORT handling in tcf_get_base_ptr() - bluetooth: mediatek: fix kernel crash when releasing iso interface - vhost: rewind next_avail_head while discarding descriptors - eth: - r8169: fix RTL8127 hang on suspend/shutdown - aquantia: add missing descriptor cache invalidation on ATL2 - dsa: microchip: fix resource releases in error path" * tag 'net-6.18-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (47 commits) mptcp: Initialise rcv_mss before calling tcp_send_active_reset() in mptcp_do_fastclose(). net: fec: do not register PPS event for PEROUT net: fec: do not allow enabling PPS and PEROUT simultaneously net: fec: do not update PEROUT if it is enabled net: fec: cancel perout_timer when PEROUT is disabled net: mctp: unconditionally set skb->dev on dst output net: atlantic: fix fragment overflow handling in RX path MAINTAINERS: separate VIRTIO NET DRIVER and add netdev virtio-net: avoid unnecessary checksum calculation on guest RX eth: fbnic: Fix counter roll-over issue mptcp: clear scheduled subflows on retransmit net: dsa: sja1105: fix SGMII linking at 10M or 100M but not passing traffic s390/net: list Aswin Karuvally as maintainer net: wwan: mhi: Keep modem name match with Foxconn T99W640 vhost: rewind next_avail_head while discarding descriptors net/sched: em_canid: fix uninit-value in em_canid_match can: rcar_canfd: Fix CAN-FD mode as default xsk: avoid data corruption on cq descriptor number r8169: fix RTL8127 hang on suspend/shutdown net: sxgbe: fix potential NULL dereference in sxgbe_rx() ...
6 daysMerge tag 'platform-drivers-x86-v6.18-5' of ↵Linus Torvalds2-7/+11
git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86 Pull platform driver fixes from Ilpo Järvinen: - arm64/thinkpad-t14s-ec: - Fix IRQ race condition - Sleep after EC access - intel/punit_ipc: Fix memory corruption * tag 'platform-drivers-x86-v6.18-5' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86: platform/x86: intel: punit_ipc: fix memory corruption platform: arm64: thinkpad-t14s-ec: sleep after EC access platform: arm64: thinkpad-t14s-ec: fix IRQ race condition
6 daysnet: fec: do not register PPS event for PEROUTWei Fang1-2/+5
There are currently two situations that can trigger the PTP interrupt, one is the PPS event, the other is the PEROUT event. However, the irq handler fec_pps_interrupt() does not check the irq event type and directly registers a PPS event into the system, but the event may be a PEROUT event. This is incorrect because PEROUT is an output signal, while PPS is the input of the kernel PPS system. Therefore, add a check for the event type, if pps_enable is true, it means that the current event is a PPS event, and then the PPS event is registered. Fixes: 350749b909bf ("net: fec: Add support for periodic output signal of PPS") Signed-off-by: Wei Fang <wei.fang@nxp.com> Link: https://patch.msgid.link/20251125085210.1094306-5-wei.fang@nxp.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
6 daysnet: fec: do not allow enabling PPS and PEROUT simultaneouslyWei Fang1-0/+12
In the current driver, PPS and PEROUT use the same channel to generate the events, so they cannot be enabled at the same time. Otherwise, the later configuration will overwrite the earlier configuration. Therefore, when configuring PPS, the driver will check whether PEROUT is enabled. Similarly, when configuring PEROUT, the driver will check whether PPS is enabled. Fixes: 350749b909bf ("net: fec: Add support for periodic output signal of PPS") Signed-off-by: Wei Fang <wei.fang@nxp.com> Link: https://patch.msgid.link/20251125085210.1094306-4-wei.fang@nxp.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
6 daysnet: fec: do not update PEROUT if it is enabledWei Fang2-10/+34
If the previously set PEROUT is already active, updating it will cause the new PEROUT to start immediately instead of at the specified time. This is because fep->reload_period is updated whithout check whether the PEROUT is enabled, and the old PEROUT is not disabled. Therefore, the pulse period will be updated immediately in the pulse interrupt handler fec_pps_interrupt(). Currently, the driver does not support directly updating PEROUT and it will make the logic be more complicated. To fix the current issue, add a check before enabling the PEROUT, the driver will return an error if PEROUT is enabled. If users wants to update a new PEROUT, they should disable the old PEROUT first. Fixes: 350749b909bf ("net: fec: Add support for periodic output signal of PPS") Signed-off-by: Wei Fang <wei.fang@nxp.com> Link: https://patch.msgid.link/20251125085210.1094306-3-wei.fang@nxp.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
6 daysnet: fec: cancel perout_timer when PEROUT is disabledWei Fang1-0/+2
The PEROUT allows the user to set a specified future time to output the periodic signal. If the future time is far from the current time, the FEC driver will use hrtimer to configure PEROUT one second before the future time. However, the hrtimer will not be canceled if the PEROUT is disabled before the hrtimer expires. So the PEROUT will be configured when the hrtimer expires, which is not as expected. Therefore, cancel the hrtimer in fec_ptp_pps_disable() to fix this issue. Fixes: 350749b909bf ("net: fec: Add support for periodic output signal of PPS") Signed-off-by: Wei Fang <wei.fang@nxp.com> Link: https://patch.msgid.link/20251125085210.1094306-2-wei.fang@nxp.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
7 daysMerge tag 'linux-can-fixes-for-6.18-20251126' of ↵Jakub Kicinski5-41/+124
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can Marc Kleine-Budde says: ==================== pull-request: can 2025-11-26 this is a pull request of 8 patches for net/main. Seungjin Bae provides a patch for the kvaser_usb driver to fix a potential infinite loop in the USB data stream command parser. Thomas Mühlbacher's patch for the sja1000 driver IRQ handler's max loop handling, that might lead to unhandled interrupts. 3 patches by me for the gs_usb driver fix handling of failed transmit URBs and add checking of the actual length of received URBs before accessing the data. The next patch is by me and is a port of Thomas Mühlbacher's patch (fix IRQ handler's max loop handling, that might lead to unhandled interrupts.) to the sun4i_can driver. Biju Das provides a patch for the rcar_canfd driver to fix the CAN-FD mode setting. The last patch is by Shaurya Rane for the em_canid filter to ensure that the complete CAN frame is present in the linear data buffer before accessing it. * tag 'linux-can-fixes-for-6.18-20251126' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can: net/sched: em_canid: fix uninit-value in em_canid_match can: rcar_canfd: Fix CAN-FD mode as default can: sun4i_can: sun4i_can_interrupt(): fix max irq loop handling can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing data can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing header can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted URBs can: sja1000: fix max irq loop handling can: kvaser_usb: leaf: Fix potential infinite loop in command parsers ==================== Link: https://patch.msgid.link/20251126155713.217105-1-mkl@pengutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
7 daysnet: atlantic: fix fragment overflow handling in RX pathJiefeng Zhang1-0/+5
The atlantic driver can receive packets with more than MAX_SKB_FRAGS (17) fragments when handling large multi-descriptor packets. This causes an out-of-bounds write in skb_add_rx_frag_netmem() leading to kernel panic. The issue occurs because the driver doesn't check the total number of fragments before calling skb_add_rx_frag(). When a packet requires more than MAX_SKB_FRAGS fragments, the fragment index exceeds the array bounds. Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for. And reusing the existing check to prevent the overflow earlier in the code path. This crash occurred in production with an Aquantia AQC113 10G NIC. Stack trace from production environment: ``` RIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0 Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89 ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90 c8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48 89 fa 83 RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287 RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX: fffffffe0a0c8000 RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI: 0000000000037a40 RBP: 0000000000000024 R08: 0000000000000000 R09: 0000000000000021 R10: 0000000000000848 R11: 0000000000000000 R12: ffffa9bec02a8e24 R13: ffff925ad8615570 R14: 0000000000000000 R15: ffff925b22e80a00 FS: 0000000000000000(0000) GS:ffff925e47880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4: 0000000000f72ef0 PKRU: 55555554 Call Trace: <IRQ> aq_ring_rx_clean+0x175/0xe60 [atlantic] ? aq_ring_rx_clean+0x14d/0xe60 [atlantic] ? aq_ring_tx_clean+0xdf/0x190 [atlantic] ? kmem_cache_free+0x348/0x450 ? aq_vec_poll+0x81/0x1d0 [atlantic] ? __napi_poll+0x28/0x1c0 ? net_rx_action+0x337/0x420 ``` Fixes: 6aecbba12b5c ("net: atlantic: add check for MAX_SKB_FRAGS") Changes in v4: - Add Fixes: tag to satisfy patch validation requirements. Changes in v3: - Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for. Signed-off-by: Jiefeng Zhang <jiefeng.z.zhang@gmail.com> Link: https://patch.msgid.link/20251126032249.69358-1-jiefeng.z.zhang@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
7 daysvirtio-net: avoid unnecessary checksum calculation on guest RXJon Kohler2-2/+3
Commit a2fb4bc4e2a6 ("net: implement virtio helpers to handle UDP GSO tunneling.") inadvertently altered checksum offload behavior for guests not using UDP GSO tunneling. Before, tun_put_user called tun_vnet_hdr_from_skb, which passed has_data_valid = true to virtio_net_hdr_from_skb. After, tun_put_user began calling tun_vnet_hdr_tnl_from_skb instead, which passes has_data_valid = false into both call sites. This caused virtio hdr flags to not include VIRTIO_NET_HDR_F_DATA_VALID for SKBs where skb->ip_summed == CHECKSUM_UNNECESSARY. As a result, guests are forced to recalculate checksums unnecessarily. Restore the previous behavior by ensuring has_data_valid = true is passed in the !tnl_gso_type case, but only from tun side, as virtio_net_hdr_tnl_from_skb() is used also by the virtio_net driver, which in turn must not use VIRTIO_NET_HDR_F_DATA_VALID on tx. cc: stable@vger.kernel.org Fixes: a2fb4bc4e2a6 ("net: implement virtio helpers to handle UDP GSO tunneling.") Signed-off-by: Jon Kohler <jon@nutanix.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Link: https://patch.msgid.link/20251125222754.1737443-1-jon@nutanix.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
7 dayseth: fbnic: Fix counter roll-over issueMohsin Bashir1-1/+1
Fix a potential counter roll-over issue in fbnic_mbx_alloc_rx_msgs() when calculating descriptor slots. The issue occurs when head - tail results in a large positive value (unsigned) and the compiler interprets head - tail - 1 as a signed value. Since FBNIC_IPC_MBX_DESC_LEN is a power of two, use a masking operation, which is a common way of avoiding this problem when dealing with these sort of ring space calculations. Fixes: da3cde08209e ("eth: fbnic: Add FW communication mechanism") Signed-off-by: Mohsin Bashir <mohsin.bashr@gmail.com> Link: https://patch.msgid.link/20251125211704.3222413-1-mohsin.bashr@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
7 daysnet: dsa: sja1105: fix SGMII linking at 10M or 100M but not passing trafficVladimir Oltean1-7/+0
When using the SGMII PCS as a fixed-link chip-to-chip connection, it is easy to miss the fact that traffic passes only at 1G, since that's what any normal such connection would use. When using the SGMII PCS connected towards an on-board PHY or an SFP module, it is immediately noticeable that when the link resolves to a speed other than 1G, traffic from the MAC fails to pass: TX counters increase, but nothing gets decoded by the other end, and no local RX counters increase either. Artificially lowering a fixed-link rate to speed = <100> makes us able to see the same issue as in the case of having an SGMII PHY. Some debugging shows that the XPCS configuration is A-OK, but that the MAC Configuration Table entry for the port has the SPEED bits still set to 1000Mbps, due to a special condition in the driver. Deleting that condition, and letting the resolved link speed be programmed directly into the MAC speed field, results in a functional link at all 3 speeds. This piece of evidence, based on testing on both generations with SGMII support (SJA1105S and SJA1110A) directly contradicts the statement from the blamed commit that "the MAC is fixed at 1 Gbps and we need to configure the PCS only (if even that)". Worse, that statement is not backed by any documentation, and no one from NXP knows what it might refer to. I am unable to recall sufficient context regarding my testing from March 2020 to understand what led me to draw such a braindead and factually incorrect conclusion. Yet, there is nothing of value regarding forcing the MAC speed, either for SGMII or 2500Base-X (introduced at a later stage), so remove all such logic. Fixes: ffe10e679cec ("net: dsa: sja1105: Add support for the SGMII port") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://patch.msgid.link/20251122111324.136761-1-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
7 daysnet: wwan: mhi: Keep modem name match with Foxconn T99W640Slark Xiao1-1/+1
Correct it since M.2 device T99W640 has updated from T99W515. We need to align it with MHI side otherwise this modem can't get the network. Fixes: ae5a34264354 ("bus: mhi: host: pci_generic: Fix the modem name of Foxconn T99W640") Signed-off-by: Slark Xiao <slark_xiao@163.com> Reviewed-by: Loic Poulain <loic.poulain@oss.qualcomm.com> Link: https://patch.msgid.link/20251125070900.33324-1-slark_xiao@163.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
7 daysvhost: rewind next_avail_head while discarding descriptorsJason Wang3-36/+103
When discarding descriptors with IN_ORDER, we should rewind next_avail_head otherwise it would run out of sync with last_avail_idx. This would cause driver to report "id X is not a head". Fixing this by returning the number of descriptors that is used for each buffer via vhost_get_vq_desc_n() so caller can use the value while discarding descriptors. Fixes: 67a873df0c41 ("vhost: basic in order support") Cc: stable@vger.kernel.org Signed-off-by: Jason Wang <jasowang@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Link: https://patch.msgid.link/20251120022950.10117-1-jasowang@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
7 daysFix Intel Dollar Cove TI battery driver 32-bit build errorLinus Torvalds1-4/+6
The driver is doing a 64-bit divide, rather than using the proper helpers, causing link errors on i386 allyesconfig builds: x86_64-linux-ld: drivers/power/supply/intel_dc_ti_battery.o: in function `dc_ti_battery_get_voltage_and_current_now': intel_dc_ti_battery.c:(.text+0x5c): undefined reference to `__udivdi3' x86_64-linux-ld: intel_dc_ti_battery.c:(.text+0x96): undefined reference to `__udivdi3' and while fixing that, fix the double rounding: keep the timing difference in nanoseconds ('ktime'), and then just convert to usecs at the end. Not because the timing precision is likely to matter, but because doing it right also makes the code simpler. Reported-by: Guenter Roeck <linux@roeck-us.net> Cc: Hans de Goede <hansg@kernel.org> Cc: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
7 daysMerge tag 'acpi-6.18-rc8' of ↵Linus Torvalds2-73/+48
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull ACPI fix from Rafael Wysocki: "Revert a commit that attempted to make the code in the ACPI processor driver more straightforward, but it turned out to cause the kernel to crash on at least one system, along with some further cleanups on top of it" * tag 'acpi-6.18-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: Revert "ACPI: processor: idle: Optimize ACPI idle driver registration" Revert "ACPI: processor: Remove unused empty stubs of some functions" Revert "ACPI: processor: idle: Rearrange declarations in header file" Revert "ACPI: processor: idle: Redefine two functions as void" Revert "ACPI: processor: Do not expose global variable acpi_idle_driver"
7 dayscan: rcar_canfd: Fix CAN-FD mode as defaultBiju Das1-22/+31
The commit 5cff263606a1 ("can: rcar_canfd: Fix controller mode setting") has aligned with the flow mentioned in the hardware manual for all SoCs except R-Car Gen3 and RZ/G2L SoCs. On R-Car Gen4 and RZ/G3E SoCs, due to the wrong logic in the commit[1] sets the default mode to FD-Only mode instead of CAN-FD mode. This patch sets the CAN-FD mode as the default for all SoCs by dropping the rcar_canfd_set_mode() as some SoC requires mode setting in global reset mode, and the rest of the SoCs in channel reset mode and update the rcar_canfd_reset_controller() to take care of these constraints. Moreover, the RZ/G3E and R-Car Gen4 SoCs support 3 modes compared to 2 modes on the R-Car Gen3. Use inverted logic in rcar_canfd_reset_controller() to simplify the code later to support FD-only mode. [1] commit 45721c406dcf ("can: rcar_canfd: Add support for r8a779a0 SoC") Fixes: 5cff263606a1 ("can: rcar_canfd: Fix controller mode setting") Cc: stable@vger.kernel.org Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://patch.msgid.link/20251118123926.193445-1-biju.das.jz@bp.renesas.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
8 daysr8169: fix RTL8127 hang on suspend/shutdownHeiner Kallweit1-5/+14
There have been reports that RTL8127 hangs on suspend and shutdown, partially disappearing from lspci until power-cycling. According to Realtek disabling PLL's when switching to D3 should be avoided on that chip version. Fix this by aligning disabling PLL's with the vendor drivers, what in addition results in PLL's not being disabled when switching to D3hot on other chip versions. Fixes: f24f7b2f3af9 ("r8169: add support for RTL8127A") Tested-by: Fabio Baltieri <fabio.baltieri@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://patch.msgid.link/d7faae7e-66bc-404a-a432-3a496600575f@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
8 daysnet: sxgbe: fix potential NULL dereference in sxgbe_rx()Alexey Kodanev1-1/+3
Currently, when skb is null, the driver prints an error and then dereferences skb on the next line. To fix this, let's add a 'break' after the error message to switch to sxgbe_rx_refill(), which is similar to the approach taken by the other drivers in this particular case, e.g. calxeda with xgmac_rx(). Found during a code review. Fixes: 1edb9ca69e8a ("net: sxgbe: add basic framework for Samsung 10Gb ethernet driver") Signed-off-by: Alexey Kodanev <aleksei.kodanev@bell-sw.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20251121123834.97748-1-aleksei.kodanev@bell-sw.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
8 daysteam: Move team device type change at the end of team_port_addNikola Z. Ivanov1-8/+15
Attempting to add a port device that is already up will expectedly fail, but not before modifying the team device header_ops. In the case of the syzbot reproducer the gre0 device is already in state UP when it attempts to add it as a port device of team0, this fails but before that header_ops->create of team0 is changed from eth_header to ipgre_header in the call to team_dev_type_check_change. Later when we end up in ipgre_header() struct ip_tunnel* points to nonsense as the private data of the device still holds a struct team. Example sequence of iproute2 commands to reproduce the hang/BUG(): ip link add dev team0 type team ip link add dev gre0 type gre ip link set dev gre0 up ip link set dev gre0 master team0 ip link set dev team0 up ping -I team0 1.1.1.1 Move team_dev_type_check_change down where all other checks have passed as it changes the dev type with no way to restore it in case one of the checks that follow it fail. Also make sure to preserve the origial mtu assignment: - If port_dev is not the same type as dev, dev takes mtu from port_dev - If port_dev is the same type as dev, port_dev takes mtu from dev This is done by adding a conditional before the call to dev_set_mtu to prevent it from assigning port_dev->mtu = dev->mtu and instead letting team_dev_type_check_change assign dev->mtu = port_dev->mtu. The conditional is needed because the patch moves the call to team_dev_type_check_change past dev_set_mtu. Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot Reported-by: syzbot+a2a3b519de727b0f7903@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=a2a3b519de727b0f7903 Fixes: 1d76efe1577b ("team: add support for non-ethernet devices") Signed-off-by: Nikola Z. Ivanov <zlatistiv@gmail.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Link: https://patch.msgid.link/20251122002027.695151-1-zlatistiv@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
8 daysnet/mlx5e: Fix validation logic in rate limitingDanielle Costantino1-1/+1
The rate limiting validation condition currently checks the output variable max_bw_value[i] instead of the input value maxrate->tc_maxrate[i]. This causes the validation to compare an uninitialized or stale value rather than the actual requested rate. The condition should check the input rate to properly validate against the upper limit: } else if (maxrate->tc_maxrate[i] <= upper_limit_gbps) { This aligns with the pattern used in the first branch, which correctly checks maxrate->tc_maxrate[i] against upper_limit_mbps. The current implementation can lead to unreliable validation behavior: - For rates between 25.5 Gbps and 255 Gbps, if max_bw_value[i] is 0 from initialization, the GBPS path may be taken regardless of whether the actual rate is within bounds - When processing multiple TCs (i > 0), max_bw_value[i] contains the value computed for the previous TC, affecting the validation logic - The overflow check for rates exceeding 255 Gbps may not trigger consistently depending on previous array values This patch ensures the validation correctly examines the requested rate value for proper bounds checking. Fixes: 43b27d1bd88a ("net/mlx5e: Fix wraparound in rate limiting for values above 255 Gbps") Signed-off-by: Danielle Costantino <dcostantino@meta.com> Reviewed-by: Gal Pressman <gal@nvidia.com> Link: https://patch.msgid.link/20251124180043.2314428-1-dcostantino@meta.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
8 daysMerge tag 'arm64-fixes' of ↵Linus Torvalds1-2/+2
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fixes from Will Deacon: "We've got a revert due to one of the recent CCA commits breaking ACPI firmware-based error reporting, a fix for a hard-lockup introduced by a prior fix affecting non-default (CONFIG_EXPERT) configurations and another ACPI fix for systems using MMIO-based timers. Other than that, we're looking pretty good. - Avoid hardlockup when CONFIG_MITIGATE_SPECTRE_BRANCH_HISTORY=n - Fix regression in APEI/GHES error handling - Fix MMIO timers when probed via ACPI" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64: proton-pack: Fix hard lockup when !MITIGATE_SPECTRE_BRANCH_HISTORY ACPI: GTDT: Correctly number platform devices for MMIO timers Revert "arm64: acpi: Enable ACPI CCEL support"
8 daysMerge tag 'for-linus-iommufd' of ↵Linus Torvalds2-2/+4
git://git.kernel.org/pub/scm/linux/kernel/git/jgg/iommufd Pull iommufd fixes from Jason Gunthorpe: "Two build fixes, no functional change: - Fix a possible compiler error around counted_by() due to wrong initialization order - Fix a -Wflex-array-member-not-at-end" * tag 'for-linus-iommufd' of git://git.kernel.org/pub/scm/linux/kernel/git/jgg/iommufd: iommufd/iommufd_private.h: Avoid -Wflex-array-member-not-at-end warning iommufd/driver: Fix counter initialization for counted_by annotation
8 daysRevert "ACPI: processor: idle: Optimize ACPI idle driver registration"Rafael J. Wysocki2-45/+23
Revert commit 7a8c994cbb2d ("ACPI: processor: idle: Optimize ACPI idle driver registration") because it is reported to introduce a cpuidle regression leading to a kernel crash on a platform using the ACPI idle driver. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reported-by: Borislav Petkov <bp@alien8.de> Tested-by: Borislav Petkov (AMD) <bp@alien8.de> Closes: https://lore.kernel.org/lkml/20251124200019.GIaSS5U9HhsWBotrQZ@fat_crate.local/
8 daysnet: lan966x: Fix the initialization of taprioHoratiu Vultur1-1/+4
To initialize the taprio block in lan966x, it is required to configure the register REVISIT_DLY. The purpose of this register is to set the delay before revisit the next gate and the value of this register depends on the system clock. The problem is that the we calculated wrong the value of the system clock period in picoseconds. The actual system clock is ~165.617754MHZ and this correspond to a period of 6038 pico seconds and not 15125 as currently set. Fixes: e462b2717380b4 ("net: lan966x: Add offload support for taprio") Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20251121061411.810571-1-horatiu.vultur@microchip.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
8 daysRevert "ACPI: processor: idle: Redefine two functions as void"Rafael J. Wysocki1-19/+22
Revert commit fbd401e95e56 ("ACPI: processor: idle: Redefine two functions as void") because it depends on a problematic one. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
8 daysRevert "ACPI: processor: Do not expose global variable acpi_idle_driver"Rafael J. Wysocki2-9/+3
Revert commit 559f2eacc8a2 ACPI: processor: Do not expose global variable acpi_idle_driver" because it depends on a problematic one. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
8 daysnet: phy: mxl-gpy: fix link properties on USXGMII and internal PHYsDaniel Golle1-7/+11
gpy_update_interface() returns early in case the PHY is internal or connected via USXGMII. In this case the gigabit master/slave property as well as MDI/MDI-X status also won't be read which seems wrong. Always read those properties by moving the logic to retrieve them to gpy_read_status(). Fixes: fd8825cd8c6fc ("net: phy: mxl-gpy: Add PHY Auto/MDI/MDI-X set driver for GPY211 chips") Fixes: 311abcdddc00a ("net: phy: add support to get Master-Slave configuration") Suggested-by: "Russell King (Oracle)" <linux@armlinux.org.uk> Signed-off-by: Daniel Golle <daniel@makrotopia.org> Link: https://patch.msgid.link/71fccf3f56742116eb18cc070d2a9810479ea7f9.1763650701.git.daniel@makrotopia.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
8 daysatm/fore200e: Fix possible data race in fore200e_open()Gui-Dong Han1-0/+2
Protect access to fore200e->available_cell_rate with rate_mtx lock in the error handling path of fore200e_open() to prevent a data race. The field fore200e->available_cell_rate is a shared resource used to track available bandwidth. It is concurrently accessed by fore200e_open(), fore200e_close(), and fore200e_change_qos(). In fore200e_open(), the lock rate_mtx is correctly held when subtracting vcc->qos.txtp.max_pcr from available_cell_rate to reserve bandwidth. However, if the subsequent call to fore200e_activate_vcin() fails, the function restores the reserved bandwidth by adding back to available_cell_rate without holding the lock. This introduces a race condition because available_cell_rate is a global device resource shared across all VCCs. If the error path in fore200e_open() executes concurrently with operations like fore200e_close() or fore200e_change_qos() on other VCCs, a read-modify-write race occurs. Specifically, the error path reads the rate without the lock. If another CPU acquires the lock and modifies the rate (e.g., releasing bandwidth in fore200e_close()) between this read and the subsequent write, the error path will overwrite the concurrent update with a stale value. This results in incorrect bandwidth accounting. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Gui-Dong Han <hanguidong02@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20251120120657.2462194-1-hanguidong02@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
8 daysnet: dsa: microchip: Fix symetry in ksz_ptp_msg_irq_{setup/free}()Bastien Curutchet (Schneider Electric)1-11/+7
The IRQ numbers created through irq_create_mapping() are only assigned to ptpmsg_irq[n].num at the end of the IRQ setup. So if an error occurs between their creation and their assignment (for instance during the request_threaded_irq() step), we enter the error path and fail to release the newly created virtual IRQs because they aren't yet assigned to ptpmsg_irq[n].num. Move the mapping creation to ksz_ptp_msg_irq_setup() to ensure symetry with what's released by ksz_ptp_msg_irq_free(). In the error path, move the irq_dispose_mapping to the out_ptp_msg label so it will be called only on created IRQs. Cc: stable@vger.kernel.org Fixes: cc13ab18b201 ("net: dsa: microchip: ptp: enable interrupt for timestamping") Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com> Link: https://patch.msgid.link/20251120-ksz-fix-v6-5-891f80ae7f8f@bootlin.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
8 daysnet: dsa: microchip: Free previously initialized ports on init failuresBastien Curutchet (Schneider Electric)1-12/+11
If a port interrupt setup fails after at least one port has already been successfully initialized, the gotos miss some resource releasing: - the already initialized PTP IRQs aren't released - the already initialized port IRQs aren't released if the failure occurs in ksz_pirq_setup(). Merge 'out_girq' and 'out_ptpirq' into a single 'port_release' label. Behind this label, use the reverse loop to release all IRQ resources for all initialized ports. Jump in the middle of the reverse loop if an error occurs in ksz_ptp_irq_setup() to only release the port IRQ of the current iteration. Cc: stable@vger.kernel.org Fixes: c9cd961c0d43 ("net: dsa: microchip: lan937x: add interrupt support for port phy link") Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com> Link: https://patch.msgid.link/20251120-ksz-fix-v6-4-891f80ae7f8f@bootlin.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
8 daysnet: dsa: microchip: Don't free uninitialized ksz_irqBastien Curutchet (Schneider Electric)1-1/+1
If something goes wrong at setup, ksz_irq_free() can be called on uninitialized ksz_irq (for example when ksz_ptp_irq_setup() fails). It leads to freeing uninitialized IRQ numbers and/or domains. Use dsa_switch_for_each_user_port_continue_reverse() in the error path to iterate only over the fully initialized ports. Cc: stable@vger.kernel.org Fixes: cc13ab18b201 ("net: dsa: microchip: ptp: enable interrupt for timestamping") Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com> Link: https://patch.msgid.link/20251120-ksz-fix-v6-3-891f80ae7f8f@bootlin.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
8 daysnet: dsa: microchip: ptp: Fix checks on irq_find_mapping()Bastien Curutchet (Schneider Electric)1-2/+2
irq_find_mapping() returns a positive IRQ number or 0 if no IRQ is found but it never returns a negative value. However, during the PTP IRQ setup, we verify that its returned value isn't negative. Fix the irq_find_mapping() check to enter the error path when 0 is returned. Return -EINVAL in such case. Cc: stable@vger.kernel.org Fixes: cc13ab18b201 ("net: dsa: microchip: ptp: enable interrupt for timestamping") Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com> Link: https://patch.msgid.link/20251120-ksz-fix-v6-2-891f80ae7f8f@bootlin.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
8 daysnet: dsa: microchip: common: Fix checks on irq_find_mapping()Bastien Curutchet (Schneider Electric)1-4/+4
irq_find_mapping() returns a positive IRQ number or 0 if no IRQ is found but it never returns a negative value. However, on each irq_find_mapping() call, we verify that the returned value isn't negative. Fix the irq_find_mapping() checks to enter error paths when 0 is returned. Return -EINVAL in such cases. CC: stable@vger.kernel.org Fixes: c9cd961c0d43 ("net: dsa: microchip: lan937x: add interrupt support for port phy link") Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com> Link: https://patch.msgid.link/20251120-ksz-fix-v6-1-891f80ae7f8f@bootlin.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
8 daysnet: aquantia: Add missing descriptor cache invalidation on ATL2Kai-Heng Feng4-19/+25
ATL2 hardware was missing descriptor cache invalidation in hw_stop(), causing SMMU translation faults during device shutdown and module removal: [ 70.355743] arm-smmu-v3 arm-smmu-v3.5.auto: event 0x10 received: [ 70.361893] arm-smmu-v3 arm-smmu-v3.5.auto: 0x0002060000000010 [ 70.367948] arm-smmu-v3 arm-smmu-v3.5.auto: 0x0000020000000000 [ 70.374002] arm-smmu-v3 arm-smmu-v3.5.auto: 0x00000000ff9bc000 [ 70.380055] arm-smmu-v3 arm-smmu-v3.5.auto: 0x0000000000000000 [ 70.386109] arm-smmu-v3 arm-smmu-v3.5.auto: event: F_TRANSLATION client: 0001:06:00.0 sid: 0x20600 ssid: 0x0 iova: 0xff9bc000 ipa: 0x0 [ 70.398531] arm-smmu-v3 arm-smmu-v3.5.auto: unpriv data write s1 "Input address caused fault" stag: 0x0 Commit 7a1bb49461b1 ("net: aquantia: fix potential IOMMU fault after driver unbind") and commit ed4d81c4b3f2 ("net: aquantia: when cleaning hw cache it should be toggled") fixed cache invalidation for ATL B0, but ATL2 was left with only interrupt disabling. This allowed hardware to write to cached descriptors after DMA memory was unmapped, triggering SMMU faults. Once cache invalidation is applied to ATL2, the translation fault can't be observed anymore. Add shared aq_hw_invalidate_descriptor_cache() helper and use it in both ATL B0 and ATL2 hw_stop() implementations for consistent behavior. Fixes: e54dcf4bba3e ("net: atlantic: basic A2 init/deinit hw_ops") Tested-by: Carol Soto <csoto@nvidia.com> Signed-off-by: Kai-Heng Feng <kaihengf@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20251120041537.62184-1-kaihengf@nvidia.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
9 daysMerge tag 'for-6.18/dm-fixes' of ↵Linus Torvalds7-14/+10
git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm Pull device mapper fixes from Mikulas Patocka: - dm-pcache fixes - fix a regression with empty flush bios - dm-verity: fix unreliable memory allocation with GFP_NOWAIT * tag 'for-6.18/dm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm: dm-verity: fix unreliable memory allocation dm: fix failure when empty flush's bi_sector points beyond the device end dm-pcache: zero cache_info before default init dm-pcache: reuse meta_addr in pcache_meta_find_latest dm-pcache: allow built-in build and rename flush helper
9 daysACPI: GTDT: Correctly number platform devices for MMIO timersMarc Zyngier1-2/+2
Use the actual timer counter instead of the watchdog counter. Fixes: 5669d92f3efa ("ACPI: GTDT: Generate platform devices for MMIO timers") Reported-by: Pavan Kondeti <pavan.kondeti@oss.qualcomm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Cc: Hanjun Guo <guohanjun@huawei.com> Cc: Sudeep Holla <sudeep.holla@arm.com> Cc: Rafael J. Wysocki <rafael@kernel.org> Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Mark Rutland <mark.rutland@arm.com> Acked-by: Hanjun Guo <guohanjun@huawei.com> Signed-off-by: Will Deacon <will@kernel.org>
9 daysplatform/x86: intel: punit_ipc: fix memory corruptionDan Carpenter1-1/+1
This passes the address of the pointer "&punit_ipcdev" when the intent was to pass the pointer itself "punit_ipcdev" (without the ampersand). This means that the: complete(&ipcdev->cmd_complete); in intel_punit_ioc() will write to a wrong memory address corrupting it. Fixes: fdca4f16f57d ("platform:x86: add Intel P-Unit mailbox IPC driver") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://patch.msgid.link/aSCmoBipSQ_tlD-D@stanley.mountain Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
10 daysMerge tag 'clk-fixes-for-linus' of ↵Linus Torvalds2-3/+3
git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux Pull clk fixes from Stephen Boyd: "Fixes for the Allwinner A523 clk driver: - Lower the minimum rate for the A523 audio PLL to support frequencies required by audio devices - Mark a couple clks critical on A523 so that Linux doesn't turn them off when they're used by other code like TF-A" * tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux: clk: sunxi-ng: sun55i-a523-ccu: Lower audio0 pll minimum rate clk: sunxi-ng: sun55i-a523-r-ccu: Mark bus-r-dma as critical clk: sunxi-ng: Mark A523 bus-r-cpucfg clock as critical
11 daysMerge tag 'scsi-fixes' of ↵Linus Torvalds2-1/+12
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fixes from James Bottomley: "One target driver fix and one scsi-generic one. The latter is 10 lines because the problem lock has to be dropped and re-taken around the call causing the sleep in atomic" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: sg: Do not sleep in atomic context scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show()
11 daysMerge tag 'input-for-v6.18-rc6' of ↵Linus Torvalds6-29/+19
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input Pull input fixes from Dmitry Torokhov: - INPUT_PROP_HAPTIC_TOUCHPAD definition added early in 6.18 cycle has been renamed to INPUT_PROP_PRESSUREPAD to better reflect the kind of devices it is supposed to be set for - a new ID for a touchscreen found in Ayaneo Flip DS in Goodix driver - Goodix driver no longer tries to set reset pin as "input" as it causes issues when there is no pull up resistor installed on the board - fixes for cros_ec_keyb, imx_sc_key, and pegasus-notetaker drivers to deal with potential out-of-bounds access and memory corruption issues * tag 'input-for-v6.18-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Input: rename INPUT_PROP_HAPTIC_TOUCHPAD to INPUT_PROP_PRESSUREPAD Input: cros_ec_keyb - fix an invalid memory access Input: imx_sc_key - fix memory corruption on unload Input: pegasus-notetaker - fix potential out-of-bounds access Input: goodix - remove setting of RST pin to input Input: goodix - add support for ACPI ID GDIX1003
11 daysMerge tag 'riscv-for-linus-6.18-rc7' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux Pull RISC-V fixes from Paul Walmsley: - Correct the MIPS RISC-V/JEDEC vendor ID - Fix the system shutdown behavior in the legacy case where CONFIG_RISCV_SBI_V01 is set, but the firmware implementation doesn't support the older v0.1 system shutdown method - Align some tools/ macro definitions with the corresponding kernel headers * tag 'riscv-for-linus-6.18-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: tools: riscv: Fixed misalignment of CSR related definitions riscv: sbi: Prefer SRST shutdown over legacy riscv: Update MIPS vendor id to 0x127
12 daysMerge tag 'for-net-2025-11-21' of ↵Jakub Kicinski1-7/+32
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth Luiz Augusto von Dentz says: ==================== bluetooth pull request for net: - hci_sock: Prevent race in socket write iter and sock bind - hci_core: Fix triggering cmd_timer for HCI_OP_NOP - hci_core: lookup hci_conn on RX path on protocol side - SMP: Fix not generating mackey and ltk when repairing - btusb: mediatek: Fix kernel crash when releasing mtk iso interface - btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref * tag 'for-net-2025-11-21' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth: Bluetooth: SMP: Fix not generating mackey and ltk when repairing Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref Bluetooth: hci_core: lookup hci_conn on RX path on protocol side Bluetooth: hci_sock: Prevent race in socket write iter and sock bind Bluetooth: hci_core: Fix triggering cmd_timer for HCI_OP_NOP Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso interface ==================== Link: https://patch.msgid.link/20251121145332.177015-1-luiz.dentz@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
12 daysnet: phy: mxl-gpy: fix bogus error on USXGMII and integrated PHYDaniel Golle1-1/+1
As the interface mode doesn't need to be updated on PHYs connected with USXGMII and integrated PHYs, gpy_update_interface() should just return 0 in these cases rather than -EINVAL which has wrongly been introduced by commit 7a495dde27ebc ("net: phy: mxl-gpy: Change gpy_update_interface() function return type"), as this breaks support for those PHYs. Fixes: 7a495dde27ebc ("net: phy: mxl-gpy: Change gpy_update_interface() function return type") Signed-off-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/f744f721a1fcc5e2e936428c62ff2c7d94d2a293.1763648168.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
12 daysiommufd/iommufd_private.h: Avoid -Wflex-array-member-not-at-end warningGustavo A. R. Silva1-1/+3
-Wflex-array-member-not-at-end was introduced in GCC-14, and we are getting ready to enable it, globally. Move the conflicting declaration to the end of the corresponding structure. Notice that struct iommufd_vevent is a flexible structure, this is a structure that contains a flexible-array member. Fix the following warning: drivers/iommu/iommufd/iommufd_private.h:621:31: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] Link: https://patch.msgid.link/r/aRHOAwpATIE0oajj@kspp Signed-off-by: "Gustavo A. R. Silva" <gustavoars@kernel.org> Fixes: e36ba5ab808e ("iommufd: Add IOMMUFD_OBJ_VEVENTQ and IOMMUFD_CMD_VEVENTQ_ALLOC") Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
12 daysiommufd/driver: Fix counter initialization for counted_by annotationGustavo A. R. Silva1-1/+1
One of the requirements for counted_by annotations is that the counter member must be initialized before the first reference to the flexible-array member. Move the vevent->data_len = data_len; initialization to before the first access to flexible array vevent->event_data. Link: https://patch.msgid.link/r/aRL7ZFFqM5bRTd2D@kspp Cc: stable@vger.kernel.org Fixes: e8e1ef9b77a7 ("iommufd/viommu: Add iommufd_viommu_report_event helper") Signed-off-by: "Gustavo A. R. Silva" <gustavoars@kernel.org> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
12 daysMerge tag 'block-6.18-20251120' of ↵Linus Torvalds6-11/+15
git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux Pull block fixes from Jens Axboe: "NVMe pull request via Keith: - Admin queue use-after-free fix (Keith) - Target authentication fix (Alistar) - Multipath lockdeup fix (Shin'ichiro) - FC transport teardown fixes (Ewan)" * tag 'block-6.18-20251120' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux: nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl() nvme: nvme-fc: move tagset removal to nvme_fc_delete_ctrl() nvme-multipath: fix lockdep WARN due to partition scan work nvmet-auth: update sc_c in target host hash calculation nvme: fix admin request_queue lifetime
12 daysMerge tag 'ata-6.18-rc7' of ↵Linus Torvalds2-1/+20
git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux Pull ata fixes from Niklas Cassel: - Add a missing refcount decrement in ata_scsi_dev_rescan() when the device or its queue is not running. In the case where the device is running, the recount is already decremented properly (Yihang Li) - Generate the proper sense code for a Security locked device. There was a regression caused by a recent change of how sense data is generated for commands that did not provide any sense data. This broke system suspend for Security locked devices. Generate the sense data that the SCSI disk driver expects for a Security locked device so that system suspend works again (me) - Set capacity to zero for a Security locked device. All I/O commands will be aborted by a Security locked device. Thus, the block layer disk partition scanning will result in a bunch of, for the user, confusing I/O errors in dmesg during boot. Since a Security locked device is unusable anyway, set the capacity to zero, to avoid the disk partition scanning during boot. We still create the block device in /dev such that the user may unlock the device using e.g. hdparm (me) * tag 'ata-6.18-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux: ata: libata-core: Set capacity to zero for a security locked drive ata: libata-scsi: Fix system suspend for a security locked drive ata: libata-scsi: Add missing scsi_device_put() in ata_scsi_dev_rescan()
12 daysMerge tag 'pinctrl-v6.18-2' of ↵Linus Torvalds6-13/+26
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl Pull pin control fixes from Linus Walleij: - Fix register naming in the Mediatek mt8189 driver - Select REGMAP_MMIO for the Realtek RTD driver - Fix the number of items in groups in the Toshiba Visconti driver - Fix a memory leak in the Cirrus CS42L43 driver - Fix a deadlock (!) in Qualcomm pinmux configuration - Fix use of uninitialized memory and list initialization in the S32CC pin controller * tag 'pinctrl-v6.18-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: dt-bindings: pinctrl: xlnx,versal-pinctrl: Add missing unevaluatedProperties on '^conf' nodes pinctrl: s32cc: initialize gpio_pin_config::list after kmalloc() pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc pinctrl: qcom: msm: Fix deadlock in pinmux configuration pinctrl: cirrus: Fix fwnode leak in cs42l43_pin_probe() dt-bindings: pinctrl: toshiba,visconti: Fix number of items in groups pinctrl: realtek: Select REGMAP_MMIO for RTD driver pinctrl: mediatek: mt8189: align register base names to dt-bindings ones pinctrl: mediatek: mt8196: align register base names to dt-bindings ones
12 daysMerge tag 'gpio-fixes-for-v6.18-rc7' of ↵Linus Torvalds1-2/+7
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux Pull gpio fixes from Bartosz Golaszewski: - fix a use-after-free bug in GPIO character device code - update MAINTAINERS * tag 'gpio-fixes-for-v6.18-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: MAINTAINERS: update my email address gpio: cdev: make sure the cdev fd is still active before emitting events
12 daysMerge tag 'drm-fixes-2025-11-21' of https://gitlab.freedesktop.org/drm/kernelLinus Torvalds28-104/+242
Pull drm fixes from Dave Airlie: "A range of small fixes across the board, the i915 display disambiguation is probably the biggest otherwise amdgpu and xe as usual with tegra, nouveau, radeon and a core atomic fix. Looks mostly normal. 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 xe: - Fix out-of-bounds access with BIT() - Fix kunit test checking wrong condition - Drop duplicate kconfig select - Fix guc2host irq handler with MSI-X i915: - Wildcat Lake and Panther Lake detangled for display fixes 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" * tag 'drm-fixes-2025-11-21' of https://gitlab.freedesktop.org/drm/kernel: (25 commits) drm/amdgpu: Add sriov vf check for VCN per queue reset support. drm/amdgpu/ttm: Fix crash when handling MMIO_REMAP in PDE flags drm/amdgpu/vm: Check PRT uAPI flag instead of PTE flag drm/amdgpu: Skip emit de meta data on gfx11 with rs64 enabled drm/amd: Skip power ungate during suspend for VPE drm/plane: Fix create_in_format_blob() return value drm/xe/irq: Handle msix vector0 interrupt drm/xe: Remove duplicate DRM_EXEC selection from Kconfig drm/xe/kunit: Fix forcewake assertion in mocs test drm/xe: Prevent BIT() overflow when handling invalid prefetch region drm/radeon: delete radeon_fence_process in is_signaled, no deadlock drm/amd/display: Fix pbn to kbps Conversion drm/amd/display: Clear the CUR_ENABLE register on DCN20 on DPP5 drm/amd/display: Add an HPD filter for HDMI drm/amd/display: Increase DPCD read retries drm/amd/display: Move sleep into each retry for retrieve_link_cap() drm/amd/display: Prevent Gating DTBCLK before It Is Properly Latched drm/i915/xe3: Restrict PTL intel_encoder_is_c10phy() to only PHY A drm/i915/display: Add definition for wcl as subplatform drm/pcids: Split PTL pciids group to make wcl subplatform ...
12 daysplatform: arm64: thinkpad-t14s-ec: sleep after EC accessSebastian Reichel1-0/+4
The ACPI ECRD and ECWR functions have a 10ms sleep at the end. It turns out, that this is sometimes needed to avoid I2C transmission failures, especially for functions doing regmap_update_bits (and thus read + write shortly after each other). This fixes problems like the following appearing in the kernel log: leds platform::micmute: Setting an LED's brightness failed (-6) leds platform::kbd_backlight: Setting an LED's brightness failed (-6) The ACPI QEVT function used to read the interrupt status register also has a 10ms sleep at the end. Without that there are problems with reading multiple events following directly after each other resulting in the following error message being logged: thinkpad-t14s-ec 4-0028: Failed to read event Fixes: 60b7ab6ce030 ("platform: arm64: thinkpad-t14s-ec: new driver") Signed-off-by: Sebastian Reichel <sre@kernel.org> Link: https://patch.msgid.link/20251119-thinkpad-t14s-ec-improvements-v2-2-441219857c02@kernel.org Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
12 daysplatform: arm64: thinkpad-t14s-ec: fix IRQ race conditionSebastian Reichel1-6/+6
Fix a race condition, that an input key related interrupt might be triggered before the input handler has been registered, which results in a NULL pointer dereference. This can happen if the user enables the keyboard backlight shortly before the driver is being probed. This fixes the following backtrace visible in dmesg: Unable to handle kernel NULL pointer dereference at virtual address 00000000000000e0 ... Call trace: sparse_keymap_report_event+0x2c/0x978 [sparse_keymap] (P) t14s_ec_irq_handler+0x190/0x3e8 [lenovo_thinkpad_t14s] irq_thread_fn+0x30/0xb8 irq_thread+0x18c/0x3b0 kthread+0x148/0x228 ret_from_fork+0x10/0x20 Fixes: 60b7ab6ce030 ("platform: arm64: thinkpad-t14s-ec: new driver") Signed-off-by: Sebastian Reichel <sre@kernel.org> Reviewed-by: Bryan O'Donoghue <bod@kernel.org> Link: https://patch.msgid.link/20251119-thinkpad-t14s-ec-improvements-v2-1-441219857c02@kernel.org Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
12 daysdm-verity: fix unreliable memory allocationMikulas Patocka1-5/+1
GFP_NOWAIT allocation may fail anytime. It needs to be changed to GFP_NOIO. There's no need to handle an error because mempool_alloc with GFP_NOIO can't fail. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Cc: stable@vger.kernel.org Reviewed-by: Eric Biggers <ebiggers@kernel.org>
13 daysMerge tag 'drm-xe-fixes-2025-11-21' of ↵Dave Airlie4-21/+6
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
13 daysMerge tag 'amd-drm-fixes-6.18-2025-11-20' of ↵Dave Airlie14-58/+196
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
13 daysMerge tag 'drm-misc-fixes-2025-11-20' of ↵Dave Airlie5-13/+10
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
13 daysveth: reduce XDP no_direct return section to fix raceJesper Dangaard Brouer1-4/+3
As explain in commit fa349e396e48 ("veth: Fix race with AF_XDP exposing old or uninitialized descriptors") for veth there is a chance after napi_complete_done() that another CPU can manage start another NAPI instance running veth_pool(). For NAPI this is correctly handled as the napi_schedule_prep() check will prevent multiple instances from getting scheduled, but for the remaining code in veth_pool() this can run concurrent with the newly started NAPI instance. The problem/race is that xdp_clear_return_frame_no_direct() isn't designed to be nested. Prior to commit 401cb7dae813 ("net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.") the temporary BPF net context bpf_redirect_info was stored per CPU, where this wasn't an issue. Since this commit the BPF context is stored in 'current' task_struct. When running veth in threaded-NAPI mode, then the kthread becomes the storage area. Now a race exists between two concurrent veth_pool() function calls one exiting NAPI and one running new NAPI, both using the same BPF net context. Race is when another CPU gets within the xdp_set_return_frame_no_direct() section before exiting veth_pool() calls the clear-function xdp_clear_return_frame_no_direct(). Fixes: 401cb7dae8130 ("net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.") Signed-off-by: Jesper Dangaard Brouer <hawk@kernel.org> Link: https://patch.msgid.link/176356963888.337072.4805242001928705046.stgit@firesoul Signed-off-by: Jakub Kicinski <kuba@kernel.org>
13 daysBluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL derefDouglas Anderson1-0/+5
In btusb_mtk_setup(), we set `btmtk_data->isopkt_intf` to: usb_ifnum_to_if(data->udev, MTK_ISO_IFNUM) That function can return NULL in some cases. Even when it returns NULL, though, we still go on to call btusb_mtk_claim_iso_intf(). As of commit e9087e828827 ("Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()"), calling btusb_mtk_claim_iso_intf() when `btmtk_data->isopkt_intf` is NULL will cause a crash because we'll end up passing a bad pointer to device_lock(). Prior to that commit we'd pass the NULL pointer directly to usb_driver_claim_interface() which would detect it and return an error, which was handled. Resolve the crash in btusb_mtk_claim_iso_intf() by adding a NULL check at the start of the function. This makes the code handle a NULL `btmtk_data->isopkt_intf` the same way it did before the problematic commit (just with a slight change to the error message printed). Reported-by: IncogCyberpunk <incogcyberpunk@proton.me> Closes: http://lore.kernel.org/r/a380d061-479e-4713-bddd-1d6571ca7e86@leemhuis.info Fixes: e9087e828827 ("Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()") Cc: stable@vger.kernel.org Tested-by: IncogCyberpunk <incogcyberpunk@proton.me> Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
13 daysBluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso interfaceChris Lu1-7/+27
When performing reset tests and encountering abnormal card drop issues that lead to a kernel crash, it is necessary to perform a null check before releasing resources to avoid attempting to release a null pointer. <4>[ 29.158070] Hardware name: Google Quigon sku196612/196613 board (DT) <4>[ 29.158076] Workqueue: hci0 hci_cmd_sync_work [bluetooth] <4>[ 29.158154] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) <4>[ 29.158162] pc : klist_remove+0x90/0x158 <4>[ 29.158174] lr : klist_remove+0x88/0x158 <4>[ 29.158180] sp : ffffffc0846b3c00 <4>[ 29.158185] pmr_save: 000000e0 <4>[ 29.158188] x29: ffffffc0846b3c30 x28: ffffff80cd31f880 x27: ffffff80c1bdc058 <4>[ 29.158199] x26: dead000000000100 x25: ffffffdbdc624ea3 x24: ffffff80c1bdc4c0 <4>[ 29.158209] x23: ffffffdbdc62a3e6 x22: ffffff80c6c07000 x21: ffffffdbdc829290 <4>[ 29.158219] x20: 0000000000000000 x19: ffffff80cd3e0648 x18: 000000031ec97781 <4>[ 29.158229] x17: ffffff80c1bdc4a8 x16: ffffffdc10576548 x15: ffffff80c1180428 <4>[ 29.158238] x14: 0000000000000000 x13: 000000000000e380 x12: 0000000000000018 <4>[ 29.158248] x11: ffffff80c2a7fd10 x10: 0000000000000000 x9 : 0000000100000000 <4>[ 29.158257] x8 : 0000000000000000 x7 : 7f7f7f7f7f7f7f7f x6 : 2d7223ff6364626d <4>[ 29.158266] x5 : 0000008000000000 x4 : 0000000000000020 x3 : 2e7325006465636e <4>[ 29.158275] x2 : ffffffdc11afeff8 x1 : 0000000000000000 x0 : ffffffdc11be4d0c <4>[ 29.158285] Call trace: <4>[ 29.158290] klist_remove+0x90/0x158 <4>[ 29.158298] device_release_driver_internal+0x20c/0x268 <4>[ 29.158308] device_release_driver+0x1c/0x30 <4>[ 29.158316] usb_driver_release_interface+0x70/0x88 <4>[ 29.158325] btusb_mtk_release_iso_intf+0x68/0xd8 [btusb (HASH:e8b6 5)] <4>[ 29.158347] btusb_mtk_reset+0x5c/0x480 [btusb (HASH:e8b6 5)] <4>[ 29.158361] hci_cmd_sync_work+0x10c/0x188 [bluetooth (HASH:a4fa 6)] <4>[ 29.158430] process_scheduled_works+0x258/0x4e8 <4>[ 29.158441] worker_thread+0x300/0x428 <4>[ 29.158448] kthread+0x108/0x1d0 <4>[ 29.158455] ret_from_fork+0x10/0x20 <0>[ 29.158467] Code: 91343000 940139d1 f9400268 927ff914 (f9401297) <4>[ 29.158474] ---[ end trace 0000000000000000 ]--- <0>[ 29.167129] Kernel panic - not syncing: Oops: Fatal exception <2>[ 29.167144] SMP: stopping secondary CPUs <4>[ 29.167158] ------------[ cut here ]------------ Fixes: ceac1cb0259d ("Bluetooth: btusb: mediatek: add ISO data transmission functions") Signed-off-by: Chris Lu <chris.lu@mediatek.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
13 daysdm: fix failure when empty flush's bi_sector points beyond the device endMikulas Patocka1-1/+1
An empty flush bio can have arbitrary bi_sector. The commit 2b1c6d7a890a introduced a regression that device mapper would fail an empty flush bio with -EIO if the sector pointed beyond the end of the device. The commit introduced an optimization, that optimization would pass flushes to __split_and_process_bio and __split_and_process_bio is not prepared to handle empty bios. Fix this bug by passing only non-empty flushes to __split_and_process_bio - non-empty flushes must have valid bi_sector. Empty bios will go through __send_empty_flush, as they did before the optimization. This problem can be reproduced by running the lvm2 test: make check_local T=lvconvert-thin.sh LVM_TEST_PREFER_BRD=0 Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Fixes: 2b1c6d7a890a ("dm: optimize REQ_PREFLUSH with data when using the linear target") Reported-by: Zdenek Kabelac <zkabelac@redhat.com> Reviewed-by: Bart Van Assche <bvanassche@acm.org>
13 daysMerge tag 'pm-6.18-rc7' of ↵Linus Torvalds1-9/+16
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull power management fix from Rafael Wysocki: "Fix a regression introduced during the 6.16 development cycle that may cause runtime PM to be enabled by mistake for devices that do not support it (which may lead to some serious trouble) if there is a system wakeup event during the "late suspend" phase of system suspend" * tag 'pm-6.18-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: PM: sleep: core: Fix runtime PM enabling in device_resume_early()
13 daysMerge tag 'acpi-6.18-rc7' of ↵Linus Torvalds1-23/+41
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull ACPI fix from Rafael Wysocki: "This fixes EINJV2 support introduced during the 6.17 cycle by unbreaking the initialization broken by a previous attempted fix, adding sanity checks for data coming from the platform firmware, and updating the code to handle injecting legacy error types on an EINJV2 capable systems properly (Tony Luck)" * tag 'acpi-6.18-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI: APEI: EINJ: Fix EINJV2 initialization and injection
13 daysMerge tag 'platform-drivers-x86-v6.18-4' of ↵Linus Torvalds13-91/+120
git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86 Pull x86 platform driver fixes from Ilpo Järvinen: "This one has lots of new HW entries which adds to the size in diffstat but the individual changes are simple. Fixes - acer-wmi: Ignore backlight event - alienware-wmi-wmax: Fix quirk match table order & drop redundant entries - amd/pmc: - Add Xbox Ally to spurious 8042 quirk list - Quirk list Lenovo Legion Go 2 NVMe resume - msi-wmi-platform: - Correct GUID to uppercase - GUID is uncleverly copy-pasted from an example so add a DMI whitelist - intel/speed_select_if: PCIBIOS_* return code conversion - intel-uncore-freq & ISST: Fix kernel doc warnings New HW support - alienware-wmi-wmax: - Alienware 16 Aurora support - Alienware M support - Alienware X support - Dell G support - amd/pmc: - ROG Xbox Ally (non-X) support - huaway-wmi: HONOR MagicBoox X16/X14 PrintScreen & YOYO keys - hp-wmi: - Omen 16-wf1xxx fan support - Omen MAX 16-ah0xx fan + thermal profile support - Victus 16-r0 and 16-s0 fan + thermal profile support - intel/hid: Intel Nova Lake support - intel-uncore-freq: - Intel Panther Lake support - Intel Wildcat Lake support - Intel Nova Lake support" * tag 'platform-drivers-x86-v6.18-4' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86: (21 commits) platform/x86: intel-uncore-freq: fix all header kernel-doc warnings platform/x86: acer-wmi: Ignore backlight event platform/x86/intel/speed_select_if: Convert PCIBIOS_* return codes to errnos platform/x86/intel/hid: Add Nova Lake support platform/x86: alienware-wmi-wmax: Add AWCC support to Alienware 16 Aurora platform/x86: hp-wmi: Add Omen MAX 16-ah0xx fan support and thermal profile platform/x86: msi-wmi-platform: Fix typo in WMI GUID platform/x86: msi-wmi-platform: Only load on MSI devices platform/x86/amd: pmc: Add Lenovo Legion Go 2 to pmc quirk list platform/x86/amd/pmc: Add spurious_8042 to Xbox Ally platform/x86/amd/pmc: Add support for Van Gogh SoC platform/x86: alienware-wmi-wmax: Add support for the whole "G" family platform/x86: alienware-wmi-wmax: Add support for the whole "X" family platform/x86: alienware-wmi-wmax: Add support for the whole "M" family platform/x86: alienware-wmi-wmax: Drop redundant DMI entries platform/x86: alienware-wmi-wmax: Fix "Alienware m16 R1 AMD" quirk order platform/x86: ISST: isst_if.h: fix all kernel-doc warnings platform/x86: intel-uncore-freq: Add additional client processors platform/x86: hp-wmi: Add Omen 16-wf1xxx fan support platform/x86: huawei-wmi: add keys for HONOR models ...
13 daysMerge tag 'net-6.18-rc7' of ↵Linus Torvalds16-47/+115
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from Jakub Kicinski: "Including fixes from IPsec and wireless. Previous releases - regressions: - prevent NULL deref in generic_hwtstamp_ioctl_lower(), newer APIs don't populate all the pointers in the request - phylink: add missing supported link modes for the fixed-link - mptcp: fix false positive warning in mptcp_pm_nl_rm_addr Previous releases - always broken: - openvswitch: remove never-working support for setting NSH fields - xfrm: number of fixes for error paths of xfrm_state creation/ modification/deletion - xfrm: fixes for offload - fix the determination of the protocol of the inner packet - don't push locally generated packets directly to L2 tunnel mode offloading, they still need processing from the standard xfrm path - mptcp: fix a couple of corner cases in fallback and fastclose handling - wifi: rtw89: hw_scan: prevent connections from getting stuck, work around apparent bug in FW by tweaking messages we send - af_unix: fix duplicate data if PEEK w/ peek_offset needs to wait - veth: more robust handing of race to avoid txq getting stuck - eth: ps3_gelic_net: handle skb allocation failures" * tag 'net-6.18-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (47 commits) vsock: Ignore signal/timeout on connect() if already established be2net: pass wrb_params in case of OS2BMC l2tp: reset skb control buffer on xmit net: dsa: microchip: lan937x: Fix RGMII delay tuning selftests: mptcp: add a check for 'add_addr_accepted' mptcp: fix address removal logic in mptcp_pm_nl_rm_addr selftests: mptcp: join: userspace: longer timeout selftests: mptcp: join: endpoints: longer timeout selftests: mptcp: join: fastclose: remove flaky marks mptcp: fix duplicate reset on fastclose mptcp: decouple mptcp fastclose from tcp close mptcp: do not fallback when OoO is present mptcp: fix premature close in case of fallback mptcp: avoid unneeded subflow-level drops mptcp: fix ack generation for fallback msk wifi: rtw89: hw_scan: Don't let the operating channel be last net: phylink: add missing supported link modes for the fixed-link selftest: af_unix: Add test for SO_PEEK_OFF. af_unix: Read sk_peek_offset() again after sleeping in unix_stream_read_generic(). net/mlx5: Clean up only new IRQ glue on request_irq() failure ...
13 daysbe2net: pass wrb_params in case of OS2BMCAndrey Vatoropin1-3/+4
be_insert_vlan_in_pkt() is called with the wrb_params argument being NULL at be_send_pkt_to_bmc() call site.  This may lead to dereferencing a NULL pointer when processing a workaround for specific packet, as commit bc0c3405abbb ("be2net: fix a Tx stall bug caused by a specific ipv6 packet") states. The correct way would be to pass the wrb_params from be_xmit(). Fixes: 760c295e0e8d ("be2net: Support for OS2BMC.") Cc: stable@vger.kernel.org Signed-off-by: Andrey Vatoropin <a.vatoropin@crpt.ru> Link: https://patch.msgid.link/20251119105015.194501-1-a.vatoropin@crpt.ru Signed-off-by: Jakub Kicinski <kuba@kernel.org>
13 daysMerge tag 'nvme-6.18-2025-11-20' of git://git.infradead.org/nvme into block-6.18Jens Axboe6-11/+15
Pull NVMe fixes from Keith: "nvme fixes for Linux 6.18 - Admin queue use-after-free fix (Keith) - Target authentication fix (Alistar) - Multipath lockdeup fix (Shin'ichiro) - FC transport teardown fixes (Ewan)" * tag 'nvme-6.18-2025-11-20' of git://git.infradead.org/nvme: nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl() nvme: nvme-fc: move tagset removal to nvme_fc_delete_ctrl() nvme-multipath: fix lockdep WARN due to partition scan work nvmet-auth: update sc_c in target host hash calculation nvme: fix admin request_queue lifetime
13 daysata: libata-core: Set capacity to zero for a security locked driveNiklas Cassel1-0/+10
For Security locked drives (drives that have Security enabled, and have not been Security unlocked by boot firmware), the automatic partition scanning will result in the user being spammed with errors such as: ata5.00: failed command: READ DMA ata5.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 7 dma 4096 in res 51/04:08:00:00:00/00:00:00:00:00/e0 Emask 0x1 (device error) ata5.00: status: { DRDY ERR } ata5.00: error: { ABRT } sd 4:0:0:0: [sda] tag#7 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=0s sd 4:0:0:0: [sda] tag#7 Sense Key : Aborted Command [current] sd 4:0:0:0: [sda] tag#7 Add. Sense: No additional sense information during boot, because most commands except for IDENTIFY will be aborted by a Security locked drive. For a Security locked drive, set capacity to zero, so that no automatic partition scanning will happen. If the user later unlocks the drive using e.g. hdparm, the close() by the user space application should trigger a revalidation of the drive. Reviewed-by: Hannes Reinecke <hare@suse.de> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Signed-off-by: Niklas Cassel <cassel@kernel.org>
13 daysata: libata-scsi: Fix system suspend for a security locked driveNiklas Cassel1-0/+7
Commit cf3fc037623c ("ata: libata-scsi: Fix ata_to_sense_error() status handling") fixed ata_to_sense_error() to properly generate sense key ABORTED COMMAND (without any additional sense code), instead of the previous bogus sense key ILLEGAL REQUEST with the additional sense code UNALIGNED WRITE COMMAND, for a failed command. However, this broke suspend for Security locked drives (drives that have Security enabled, and have not been Security unlocked by boot firmware). The reason for this is that the SCSI disk driver, for the Synchronize Cache command only, treats any sense data with sense key ILLEGAL REQUEST as a successful command (regardless of ASC / ASCQ). After commit cf3fc037623c ("ata: libata-scsi: Fix ata_to_sense_error() status handling") the code that treats any sense data with sense key ILLEGAL REQUEST as a successful command is no longer applicable, so the command fails, which causes the system suspend to be aborted: sd 1:0:0:0: PM: dpm_run_callback(): scsi_bus_suspend returns -5 sd 1:0:0:0: PM: failed to suspend async: error -5 PM: Some devices failed to suspend, or early wake event detected To make suspend work once again, for a Security locked device only, return sense data LOGICAL UNIT ACCESS NOT AUTHORIZED, the actual sense data which a real SCSI device would have returned if locked. The SCSI disk driver treats this sense data as a successful command. Cc: stable@vger.kernel.org Reported-by: Ilia Baryshnikov <qwelias@gmail.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220704 Fixes: cf3fc037623c ("ata: libata-scsi: Fix ata_to_sense_error() status handling") Reviewed-by: Hannes Reinecke <hare@suse.de> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Signed-off-by: Niklas Cassel <cassel@kernel.org>
13 daysata: libata-scsi: Add missing scsi_device_put() in ata_scsi_dev_rescan()Yihang Li1-1/+3
Call scsi_device_put() in ata_scsi_dev_rescan() if the device or its queue are not running. Fixes: 0c76106cb975 ("scsi: sd: Fix TCG OPAL unlock on system resume") Cc: stable@vger.kernel.org Signed-off-by: Yihang Li <liyihang9@h-partners.com> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Signed-off-by: Niklas Cassel <cassel@kernel.org>
13 daysMerge tag 'wireless-2025-11-20' of ↵Paolo Abeni1-0/+7
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless Johannes Berg says: ==================== wireless-2025-11-20 A single fix for scanning on some rtw89 devices. * tag 'wireless-2025-11-20' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless: wifi: rtw89: hw_scan: Don't let the operating channel be last ==================== Link: https://patch.msgid.link/20251120085433.8601-3-johannes@sipsolutions.net Signed-off-by: Paolo Abeni <pabeni@redhat.com>
13 daysnet: dsa: microchip: lan937x: Fix RGMII delay tuningOleksij Rempel1-0/+1
Correct RGMII delay application logic in lan937x_set_tune_adj(). The function was missing `data16 &= ~PORT_TUNE_ADJ` before setting the new delay value. This caused the new value to be bitwise-OR'd with the existing PORT_TUNE_ADJ field instead of replacing it. For example, when setting the RGMII 2 TX delay on port 4, the intended TUNE_ADJUST value of 0 (RGMII_2_TX_DELAY_2NS) was incorrectly OR'd with the default 0x1B (from register value 0xDA3), leaving the delay at the wrong setting. This patch adds the missing mask to clear the field, ensuring the correct delay value is written. Physical measurements on the RGMII TX lines confirm the fix, showing the delay changing from ~1ns (before change) to ~2ns. While testing on i.MX 8MP showed this was within the platform's timing tolerance, it did not match the intended hardware-characterized value. Fixes: b19ac41faa3f ("net: dsa: microchip: apply rgmii tx and rx delay in phylink mac config") Cc: stable@vger.kernel.org Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Link: https://patch.msgid.link/20251114090951.4057261-1-o.rempel@pengutronix.de Signed-off-by: Paolo Abeni <pabeni@redhat.com>
14 daysMerge branch '200GbE' of ↵Jakub Kicinski2-3/+21
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2025-11-18 (idpf, ice) This series contains updates to idpf and ice drivers. Emil adds a check for NULL vport_config during removal to avoid NULL pointer dereference in idpf. Grzegorz fixes PTP teardown paths to account for some missed cleanups for ice driver. * '200GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue: ice: fix PTP cleanup on driver removal in error path idpf: fix possible vport_config NULL pointer deref in remove ==================== Link: https://patch.msgid.link/20251118235207.2165495-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
14 daysscsi: sg: Do not sleep in atomic contextBart Van Assche1-1/+9
sg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may sleep. Hence, call sg_finish_rem_req() with interrupts enabled instead of disabled. Reported-by: syzbot+c01f8e6e73f20459912e@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-scsi/691560c4.a70a0220.3124cb.001a.GAE@google.com/ Cc: Hannes Reinecke <hare@suse.de> Cc: stable@vger.kernel.org Fixes: 97d27b0dd015 ("scsi: sg: close race condition in sg_remove_sfp_usercontext()") Signed-off-by: Bart Van Assche <bvanassche@acm.org> Link: https://patch.msgid.link/20251113181643.1108973-1-bvanassche@acm.org Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
14 dayswifi: rtw89: hw_scan: Don't let the operating channel be lastBitterblue Smith1-0/+7
Scanning can be offloaded to the firmware. To that end, the driver prepares a list of channels to scan, including periodic visits back to the operating channel, and sends the list to the firmware. When the channel list is too long to fit in a single H2C message, the driver splits the list, sends the first part, and tells the firmware to scan. When the scan is complete, the driver sends the next part of the list and tells the firmware to scan. When the last channel that fit in the H2C message is the operating channel something seems to go wrong in the firmware. It will acknowledge receiving the list of channels but apparently it will not do anything more. The AP can't be pinged anymore. The driver still receives beacons, though. One way to avoid this is to split the list of channels before the operating channel. Affected devices: * RTL8851BU with firmware 0.29.41.3 * RTL8832BU with firmware 0.29.29.8 * RTL8852BE with firmware 0.29.29.8 The commit 57a5fbe39a18 ("wifi: rtw89: refactor flow that hw scan handles channel list") is found by git blame, but it is actually to refine the scan flow, but not a culprit, so skip Fixes tag. Reported-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Closes: https://lore.kernel.org/linux-wireless/0abbda91-c5c2-4007-84c8-215679e652e1@gmail.com/ Cc: stable@vger.kernel.org # 6.16+ Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/c1e61744-8db4-4646-867f-241b47d30386@gmail.com
14 daysdrm/amdgpu: Add sriov vf check for VCN per queue reset support.Shikang Fan2-2/+4
Add SRIOV check when setting VCN ring's supported reset mask. Signed-off-by: Shikang Fan <shikang.fan@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit ee9b603ad43f9870eb75184f9fb0a84f8c3cc852) Cc: stable@vger.kernel.org
14 daysdrm/amdgpu/ttm: Fix crash when handling MMIO_REMAP in PDE flagsSrinivasan Shanmugam1-1/+1
The MMIO_REMAP BO is a special 4K IO page that does not have a ttm_tt behind it. However, amdgpu_ttm_tt_pde_flags() was treating it like normal TT/doorbell/preempt memory and unconditionally accessed ttm->caching. For the MMIO_REMAP BO, ttm is NULL, so this leads to a NULL pointer dereference when computing PDE flags. Fix this by checking that ttm is non-NULL before reading ttm->caching. This prevents the crash for MMIO_REMAP and also makes the code more defensive if other BOs ever come through without a ttm_tt. Fixes: fb5a52dbe9fe ("drm/amdgpu: Implement TTM handling for MMIO_REMAP placement") Suggested-by: Jesse Zhang <Jesse.Zhang@amd.com> Suggested-by: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Reviewed-by: Jesse Zhang <Jesse.Zhang@amd.com> Tested-by: Jesse Zhang <Jesse.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 0db94da5a0a1cacda080b9ec8425fcbe4babc141)
14 daysdrm/amdgpu/vm: Check PRT uAPI flag instead of PTE flagTimur Kristóf1-2/+2
This fixes sparse mappings (aka. partially resident textures). Check the correct flags. Since a recent refactor, the code works with uAPI flags (for mapping buffer objects), and not PTE (page table entry) flags. Fixes: 6716a823d18d ("drm/amdgpu: rework how PTE flags are generated v3") Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 8feeab26c80635b802f72b3ed986c693ff8f3212)
14 daysdrm/amdgpu: Skip emit de meta data on gfx11 with rs64 enabledYifan Zha1-2/+2
[Why] Accoreding to CP updated to RS64 on gfx11, WRITE_DATA with PREEMPTION_META_MEMORY(dst_sel=8) is illegal for CP FW. That packet is used for MCBP on F32 based system. So it would lead to incorrect GRBM write and FW is not handling that extra case correctly. [How] With gfx11 rs64 enabled, skip emit de meta data. Signed-off-by: Yifan Zha <Yifan.Zha@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 8366cd442d226463e673bed5d199df916f4ecbcf) Cc: stable@vger.kernel.org
14 daysdrm/amd: Skip power ungate during suspend for VPEMario Limonciello1-1/+2
During the suspend sequence VPE is already going to be power gated as part of vpe_suspend(). It's unnecessary to call during calls to amdgpu_device_set_pg_state(). It actually can expose a race condition with the firmware if s0i3 sequence starts as well. Drop these calls. Cc: Peyton.Lee@amd.com Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 2a6c826cfeedd7714611ac115371a959ead55bda) Cc: stable@vger.kernel.org
2025-11-19drm/plane: Fix create_in_format_blob() return valueVille Syrjälä1-2/+2
create_in_format_blob() is either supposed to return a valid pointer or an error, but never NULL. The caller will dereference the blob when it is not an error, and thus will oops if NULL returned. Return proper error values in the failure cases. Cc: stable@vger.kernel.org Cc: Arun R Murthy <arun.r.murthy@intel.com> Fixes: 0d6dcd741c26 ("drm/plane: modify create_in_formats to acommodate async") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251112233030.24117-2-ville.syrjala@linux.intel.com Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
2025-11-19Merge tag 'soc-fixes-6.18-3' of ↵Linus Torvalds2-4/+4
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull SoC fixes from Arnd Bergmann: "These are mainly devicetree fixes for the arm platforms from Rockchips NXP, ASpeed and Broadcom, addressing issues with accidental overclocking, pinctrl, network and dtc warnings. There are additional fixes for regressions with the i.MX reset and memory controller drivers as well as the Tegra memory controller driver. Minor updates to the MAINTAINERS file, tee documentation and defconfigs bring those up to date with recent changes elsewhere" * tag 'soc-fixes-6.18-3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (29 commits) MAINTAINERS: sync omap devicetree maintainers with omap platform MAINTAINERS: Update Krzysztof Kozlowski's email arm64: dts: rockchip: fix PCIe 3.3V regulator voltage on orangepi-5 arm64: dts: rockchip: disable HS400 on RK3588 Tiger arm64: dts: rockchip: drop reset from rk3576 i2c9 node tee: <uapi/linux/tee.h: fix all kernel-doc issues arm64: dts: rockchip: Fix USB power enable pin for BTT CB2 and Pi2 arm64: dts: broadcom: bcm2712: rpi-5: Add ethernet0 alias arm64: dts: broadcom: Assign clock rates in eth node for RPi5 reset: imx8mp-audiomix: Fix bad mask values ARM: dts: BCM53573: Fix address of Luxul XAP-1440's Ethernet PHY arm64: defconfig: Fix V3D deferred probe timeout arm64: dts: rockchip: Fix vccio4-supply on rk3566-pinetab2 arm64: dts: rockchip: include rk3399-base instead of rk3399 in rk3399-op1 arm64: dts: imx8mp-kontron: Fix USB OTG role switching arm64: dts: imx95: Fix MSI mapping for PCIe endpoint nodes arm64: dts: imx8-ss-img: Avoid gpio0_mipi_csi GPIOs being deferred arm: imx_v6_v7_defconfig: enable ext4 directly memory: tegra210: Fix incorrect client ids arm64: dts: rockchip: Fix indentation on rk3399 haikou demo dtso ...
2025-11-19Merge tag 'pwm/for-6.18-rc7-fixes' of ↵Linus Torvalds1-2/+2
git://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux Pull pwm fix from Uwe Kleine-König: "Correct mismatched pwm chip info for adp5585. Luke Wang found a problem in the pwm-adp5585 driver about how register information is mapped to the different device variants. This effectively made the driver non-functional. That didn't pop up before because the driver change was developed as part of a bigger mfd series and the original author didn't retest PWM functionality after it was tested in an earlier revision but then reworked" * tag 'pwm/for-6.18-rc7-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux: pwm: adp5585: Correct mismatched pwm chip info
2025-11-19Merge tag 'hid-for-linus-2025111901' of ↵Linus Torvalds12-20/+57
git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid Pull HID fixes from Jiri Kosina: - memory leak fixes in hid-uclogic, hid-ntrig and hid-playstation drivers (Abdun Nihaal, Masami Ichikawa) - regression fix for playback handling in hid-pidff (Tomasz Pakuła) - initialization fix for some amd_sfh platforms (Mario Limonciello) - a few assorted device-specific ID additions and quirks * tag 'hid-for-linus-2025111901' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid: HID: uclogic: Fix potential memory leak in error path HID: playstation: Fix memory leak in dualshock4_get_calibration_data() HID: pidff: Fix needs_playback check HID: corsair-void: Use %pe for printing PTR_ERR HID: elecom: Add support for ELECOM M-XT3URBK (018F) HID: hid-input: Extend Elan ignore battery quirk to USB HID: hid-ntrig: Prevent memory leak in ntrig_report_version() HID: amd_sfh: Stop sensor before starting HID: apple: Add SONiX AK870 PRO to non_apple_keyboards quirk list HID: lenovo: fixup Lenovo Yoga Slim 7x Keyboard rdesc HID: quirks: work around VID/PID conflict for 0x4c4a/0x4155
2025-11-19net: phylink: add missing supported link modes for the fixed-linkWei Fang1-0/+3
Pause, Asym_Pause and Autoneg bits are not set when pl->supported is initialized, so these link modes will not work for the fixed-link. This leads to a TCP performance degradation issue observed on the i.MX943 platform. The switch CPU port of i.MX943 is connected to an ENETC MAC, this link is a fixed link and the link speed is 2.5Gbps. And one of the switch user ports is the RGMII interface, and its link speed is 1Gbps. If the flow-control of the fixed link is not enabled, we can easily observe the iperf performance of TCP packets is very low. Because the inbound rate on the CPU port is greater than the outbound rate on the user port, the switch is prone to congestion, leading to the loss of some TCP packets and requiring multiple retransmissions. Solving this problem should be as simple as setting the Asym_Pause and Pause bits. The reason why the Autoneg bit needs to be set, Russell has gave a very good explanation in the thread [1], see below. "As the advertising and lp_advertising bitmasks have to be non-empty, and the swphy reports aneg capable, aneg complete, and AN enabled, then for consistency with that state, Autoneg should be set. This is how it was prior to the blamed commit." Fixes: de7d3f87be3c ("net: phylink: Use phy_caps_lookup for fixed-link configuration") Link: https://lore.kernel.org/aRjqLN8eQDIQfBjS@shell.armlinux.org.uk # [1] Signed-off-by: Wei Fang <wei.fang@nxp.com> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/20251117102943.1862680-1-wei.fang@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-19Merge drm/drm-fixes into drm-misc-fixesThomas Zimmermann262-1118/+2286
Backmerging to get fixes from v6.18-rc6. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
2025-11-19ACPI: APEI: EINJ: Fix EINJV2 initialization and injectionTony Luck1-23/+41
ACPI 6.6 specification for EINJV2 appends an extra structure to the end of the existing struct set_error_type_with_address. Several issues showed up in testing. 1) Initialization was broken by an earlier fix [1] since is_v2 is only set while performing an injection, not during initialization. 2) A buggy BIOS provided invalid "revision" and "length" for the extension structure. Add several sanity checks. 3) When injecting legacy error types on an EINJV2 capable system, don't copy the component arrays. Fixes: 6c7058514991 ("ACPI: APEI: EINJ: Check if user asked for EINJV2 injection") # [1] Fixes: b47610296d17 ("ACPI: APEI: EINJ: Enable EINJv2 error injections") Signed-off-by: Tony Luck <tony.luck@intel.com> [ rjw: Changelog edits ] Cc: 6.17+ <stable@vger.kernel.org> # 6.17+ Link: https://patch.msgid.link/20251119012712.178715-1-tony.luck@intel.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-11-19gpio: cdev: make sure the cdev fd is still active before emitting eventsBartosz Golaszewski1-2/+7
With the final call to fput() on a file descriptor, the release action may be deferred and scheduled on a work queue. The reference count of that descriptor is still zero and it must not be used. It's possible that a GPIO change, we want to notify the user-space about, happens AFTER the reference count on the file descriptor associated with the character device went down to zero but BEFORE the .release() callback was called from the workqueue and so BEFORE we unregistered from the notifier. Using the regular get_file() routine in this situation triggers the following warning: struct file::f_count incremented from zero; use-after-free condition present! So use the get_file_active() variant that will return NULL on file descriptors that have been or are being released. Fixes: 40b7c49950bd ("gpio: cdev: put emitting the line state events on a workqueue") Reported-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Closes: https://lore.kernel.org/all/5d605f7fc99456804911403102a4fe999a14cc85.camel@siemens.com/ Tested-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Link: https://lore.kernel.org/r/20251117-gpio-cdev-get-file-v1-1-28a16b5985b8@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-11-18net/mlx5: Clean up only new IRQ glue on request_irq() failurePradyumn Rahar1-4/+2
The mlx5_irq_alloc() function can inadvertently free the entire rmap and end up in a crash[1] when the other threads tries to access this, when request_irq() fails due to exhausted IRQ vectors. This commit modifies the cleanup to remove only the specific IRQ mapping that was just added. This prevents removal of other valid mappings and ensures precise cleanup of the failed IRQ allocation's associated glue object. Note: This error is observed when both fwctl and rds configs are enabled. [1] mlx5_core 0000:05:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:05:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:06:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:06:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:06:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:03:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 general protection fault, probably for non-canonical address 0xe277a58fde16f291: 0000 [#1] SMP NOPTI RIP: 0010:free_irq_cpu_rmap+0x23/0x7d Call Trace: <TASK> ? show_trace_log_lvl+0x1d6/0x2f9 ? show_trace_log_lvl+0x1d6/0x2f9 ? mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] ? __die_body.cold+0x8/0xa ? die_addr+0x39/0x53 ? exc_general_protection+0x1c4/0x3e9 ? dev_vprintk_emit+0x5f/0x90 ? asm_exc_general_protection+0x22/0x27 ? free_irq_cpu_rmap+0x23/0x7d mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] irq_pool_request_vector+0x7d/0x90 [mlx5_core] mlx5_irq_request+0x2e/0xe0 [mlx5_core] mlx5_irq_request_vector+0xad/0xf7 [mlx5_core] comp_irq_request_pci+0x64/0xf0 [mlx5_core] create_comp_eq+0x71/0x385 [mlx5_core] ? mlx5e_open_xdpsq+0x11c/0x230 [mlx5_core] mlx5_comp_eqn_get+0x72/0x90 [mlx5_core] ? xas_load+0x8/0x91 mlx5_comp_irqn_get+0x40/0x90 [mlx5_core] mlx5e_open_channel+0x7d/0x3c7 [mlx5_core] mlx5e_open_channels+0xad/0x250 [mlx5_core] mlx5e_open_locked+0x3e/0x110 [mlx5_core] mlx5e_open+0x23/0x70 [mlx5_core] __dev_open+0xf1/0x1a5 __dev_change_flags+0x1e1/0x249 dev_change_flags+0x21/0x5c do_setlink+0x28b/0xcc4 ? __nla_parse+0x22/0x3d ? inet6_validate_link_af+0x6b/0x108 ? cpumask_next+0x1f/0x35 ? __snmp6_fill_stats64.constprop.0+0x66/0x107 ? __nla_validate_parse+0x48/0x1e6 __rtnl_newlink+0x5ff/0xa57 ? kmem_cache_alloc_trace+0x164/0x2ce rtnl_newlink+0x44/0x6e rtnetlink_rcv_msg+0x2bb/0x362 ? __netlink_sendskb+0x4c/0x6c ? netlink_unicast+0x28f/0x2ce ? rtnl_calcit.isra.0+0x150/0x146 netlink_rcv_skb+0x5f/0x112 netlink_unicast+0x213/0x2ce netlink_sendmsg+0x24f/0x4d9 __sock_sendmsg+0x65/0x6a ____sys_sendmsg+0x28f/0x2c9 ? import_iovec+0x17/0x2b ___sys_sendmsg+0x97/0xe0 __sys_sendmsg+0x81/0xd8 do_syscall_64+0x35/0x87 entry_SYSCALL_64_after_hwframe+0x6e/0x0 RIP: 0033:0x7fc328603727 Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 0b ed ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 44 ed ff ff 48 RSP: 002b:00007ffe8eb3f1a0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc328603727 RDX: 0000000000000000 RSI: 00007ffe8eb3f1f0 RDI: 000000000000000d RBP: 00007ffe8eb3f1f0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 0000000000000000 R14: 00007ffe8eb3f3c8 R15: 00007ffe8eb3f3bc </TASK> ---[ end trace f43ce73c3c2b13a2 ]--- RIP: 0010:free_irq_cpu_rmap+0x23/0x7d Code: 0f 1f 80 00 00 00 00 48 85 ff 74 6b 55 48 89 fd 53 66 83 7f 06 00 74 24 31 db 48 8b 55 08 0f b7 c3 48 8b 04 c2 48 85 c0 74 09 <8b> 38 31 f6 e8 c4 0a b8 ff 83 c3 01 66 3b 5d 06 72 de b8 ff ff ff RSP: 0018:ff384881640eaca0 EFLAGS: 00010282 RAX: e277a58fde16f291 RBX: 0000000000000000 RCX: 0000000000000000 RDX: ff2335e2e20b3600 RSI: 0000000000000000 RDI: ff2335e2e20b3400 RBP: ff2335e2e20b3400 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 00000000ffffffe4 R12: ff384881640ead88 R13: ff2335c3760751e0 R14: ff2335e2e1672200 R15: ff2335c3760751f8 FS: 00007fc32ac22480(0000) GS:ff2335e2d6e00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f651ab54000 CR3: 00000029f1206003 CR4: 0000000000771ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Kernel panic - not syncing: Fatal exception Kernel Offset: 0x1dc00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) kvm-guest: disable async PF for cpu 0 Fixes: 3354822cde5a ("net/mlx5: Use dynamic msix vectors allocation") Signed-off-by: Mohith Kumar Thummaluru<mohith.k.kumar.thummaluru@oracle.com> Tested-by: Mohith Kumar Thummaluru<mohith.k.kumar.thummaluru@oracle.com> Reviewed-by: Moshe Shemesh <moshe@nvidia.com> Reviewed-by: Shay Drori <shayd@nvidia.com> Signed-off-by: Pradyumn Rahar <pradyumn.rahar@oracle.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1763381768-1234998-1-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-18pinctrl: s32cc: initialize gpio_pin_config::list after kmalloc()Jared Kangas1-0/+1
s32_pmx_gpio_request_enable() does not initialize the newly-allocated gpio_pin_config::list before adding it to s32_pinctrl::gpio_configs. This could result in a linked list corruption. Initialize the new list_head with INIT_LIST_HEAD() to fix this. Fixes: fd84aaa8173d ("pinctrl: add NXP S32 SoC family support") Signed-off-by: Jared Kangas <jkangas@redhat.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2025-11-18pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_descJared Kangas1-1/+1
s32_pinctrl_desc is allocated with devm_kmalloc(), but not all of its fields are initialized. Notably, num_custom_params is used in pinconf_generic_parse_dt_config(), resulting in intermittent allocation errors, such as the following splat when probing i2c-imx: WARNING: CPU: 0 PID: 176 at mm/page_alloc.c:4795 __alloc_pages_noprof+0x290/0x300 [...] Hardware name: NXP S32G3 Reference Design Board 3 (S32G-VNP-RDB3) (DT) [...] Call trace: __alloc_pages_noprof+0x290/0x300 (P) ___kmalloc_large_node+0x84/0x168 __kmalloc_large_node_noprof+0x34/0x120 __kmalloc_noprof+0x2ac/0x378 pinconf_generic_parse_dt_config+0x68/0x1a0 s32_dt_node_to_map+0x104/0x248 dt_to_map_one_config+0x154/0x1d8 pinctrl_dt_to_map+0x12c/0x280 create_pinctrl+0x6c/0x270 pinctrl_get+0xc0/0x170 devm_pinctrl_get+0x50/0xa0 pinctrl_bind_pins+0x60/0x2a0 really_probe+0x60/0x3a0 [...] __platform_driver_register+0x2c/0x40 i2c_adap_imx_init+0x28/0xff8 [i2c_imx] [...] This results in later parse failures that can cause issues in dependent drivers: s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property [...] pca953x 0-0022: failed writing register: -6 i2c i2c-0: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property i2c i2c-1: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property i2c i2c-2: IMX I2C adapter registered Fix this by initializing s32_pinctrl_desc with devm_kzalloc() instead of devm_kmalloc() in s32_pinctrl_probe(), which sets the previously uninitialized fields to zero. Fixes: fd84aaa8173d ("pinctrl: add NXP S32 SoC family support") Signed-off-by: Jared Kangas <jkangas@redhat.com> Tested-by: Jan Petrous (OSS) <jan.petrous@oss.nxp.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2025-11-18ice: fix PTP cleanup on driver removal in error pathGrzegorz Nitka1-3/+19
Improve the cleanup on releasing PTP resources in error path. The error case might happen either at the driver probe and PTP feature initialization or on PTP restart (errors in reset handling, NVM update etc). In both cases, calls to PF PTP cleanup (ice_ptp_cleanup_pf function) and 'ps_lock' mutex deinitialization were missed. Additionally, ptp clock was not unregistered in the latter case. Keep PTP state as 'uninitialized' on init to distinguish between error scenarios and to avoid resource release duplication at driver removal. The consequence of missing ice_ptp_cleanup_pf call is the following call trace dumped when ice_adapter object is freed (port list is not empty, as it is required at this stage): [ T93022] ------------[ cut here ]------------ [ T93022] WARNING: CPU: 10 PID: 93022 at ice/ice_adapter.c:67 ice_adapter_put+0xef/0x100 [ice] ... [ T93022] RIP: 0010:ice_adapter_put+0xef/0x100 [ice] ... [ T93022] Call Trace: [ T93022] <TASK> [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? __warn.cold+0xb0/0x10e [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? report_bug+0xd8/0x150 [ T93022] ? handle_bug+0xe9/0x110 [ T93022] ? exc_invalid_op+0x17/0x70 [ T93022] ? asm_exc_invalid_op+0x1a/0x20 [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] pci_device_remove+0x42/0xb0 [ T93022] device_release_driver_internal+0x19f/0x200 [ T93022] driver_detach+0x48/0x90 [ T93022] bus_remove_driver+0x70/0xf0 [ T93022] pci_unregister_driver+0x42/0xb0 [ T93022] ice_module_exit+0x10/0xdb0 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] ... [ T93022] ---[ end trace 0000000000000000 ]--- [ T93022] ice: module unloaded Fixes: e800654e85b5 ("ice: Use ice_adapter for PTP shared data instead of auxdev") Signed-off-by: Grzegorz Nitka <grzegorz.nitka@intel.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Tested-by: Rinitha S <sx.rinitha@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2025-11-18idpf: fix possible vport_config NULL pointer deref in removeEmil Tantilov1-0/+2
Attempting to remove the driver will cause a crash in cases where the vport failed to initialize. Following trace is from an instance where the driver failed during an attempt to create a VF: [ 1661.543624] idpf 0000:84:00.7: Device HW Reset initiated [ 1722.923726] idpf 0000:84:00.7: Transaction timed-out (op:1 cookie:2900 vc_op:1 salt:29 timeout:60000ms) [ 1723.353263] BUG: kernel NULL pointer dereference, address: 0000000000000028 ... [ 1723.358472] RIP: 0010:idpf_remove+0x11c/0x200 [idpf] ... [ 1723.364973] Call Trace: [ 1723.365475] <TASK> [ 1723.365972] pci_device_remove+0x42/0xb0 [ 1723.366481] device_release_driver_internal+0x1a9/0x210 [ 1723.366987] pci_stop_bus_device+0x6d/0x90 [ 1723.367488] pci_stop_and_remove_bus_device+0x12/0x20 [ 1723.367971] pci_iov_remove_virtfn+0xbd/0x120 [ 1723.368309] sriov_disable+0x34/0xe0 [ 1723.368643] idpf_sriov_configure+0x58/0x140 [idpf] [ 1723.368982] sriov_numvfs_store+0xda/0x1c0 Avoid the NULL pointer dereference by adding NULL pointer check for vport_config[i], before freeing user_config.q_coalesce. Fixes: e1e3fec3e34b ("idpf: preserve coalescing settings across resets") Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com> Reviewed-by: Chittim Madhu <madhu.chittim@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Samuel Salin <Samuel.salin@intel.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2025-11-18drm/xe/irq: Handle msix vector0 interruptVenkata Ramana Nayana1-17/+1
Current gu2host handler registered as MSI-X vector 0 and as per bspec for a msix vector 0 interrupt, the driver must check the legacy registers 190008(TILE_INT_REG), 190060h (GT INTR Identity Reg 0) and other registers mentioned in "Interrupt Service Routine Pseudocode" otherwise it will block the next interrupts. To overcome this issue replacing guc2host handler with legacy xe_irq_handler. Fixes: da889070be7b2 ("drm/xe/irq: Separate MSI and MSI-X flows") Bspec: 62357 Signed-off-by: Venkata Ramana Nayana <venkata.ramana.nayana@intel.com> Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Link: https://patch.msgid.link/20251107083141.2080189-1-venkata.ramana.nayana@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> (cherry picked from commit c34a14bce7090862ebe5a64abe8d85df75e62737) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-11-18drm/xe: Remove duplicate DRM_EXEC selection from KconfigShuicheng Lin1-1/+0
There are 2 identical "select DRM_EXEC" lines for DRM_XE. Remove one to clean up the configuration. Fixes: d490ecf57790 ("drm/xe: Rework xe_exec and the VM rebind worker to use the drm_exec helper") Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Reviewed-by: Nitin Gote <nitin.r.gote@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patch.msgid.link/20251110232657.1807998-2-shuicheng.lin@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> (cherry picked from commit b1aa02acd03bfef3ed39c511d33c4a4303d2f9b1) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-11-18drm/xe/kunit: Fix forcewake assertion in mocs testMatt Roper1-1/+1
The MOCS kunit test calls KUNIT_ASSERT_TRUE_MSG() with a condition of 'true;' this prevents the assertion from ever failing. Replace KUNIT_ASSERT_TRUE_MSG with KUNIT_FAIL_AND_ABORT to get the intended failure behavior in cases where forcewake was not acquired successfully. Fixes: 51c0ee84e4dc ("drm/xe/tests/mocs: Hold XE_FORCEWAKE_ALL for LNCF regs") Cc: Tejas Upadhyay <tejas.upadhyay@intel.com> Cc: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patch.msgid.link/20251113234038.2256106-2-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> (cherry picked from commit 9be4f0f687048ba77428ceca11994676736507b7) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-11-18drm/xe: Prevent BIT() overflow when handling invalid prefetch regionShuicheng Lin1-2/+4
If user provides a large value (such as 0x80) for parameter prefetch_mem_region_instance in vm_bind ioctl, it will cause BIT(prefetch_region) overflow as below: " ------------[ cut here ]------------ UBSAN: shift-out-of-bounds in drivers/gpu/drm/xe/xe_vm.c:3414:7 shift exponent 128 is too large for 64-bit type 'long unsigned int' CPU: 8 UID: 0 PID: 53120 Comm: xe_exec_system_ Tainted: G W 6.18.0-rc1-lgci-xe-kernel+ #200 PREEMPT(voluntary) Tainted: [W]=WARN Hardware name: ASUS System Product Name/PRIME Z790-P WIFI, BIOS 0812 02/24/2023 Call Trace: <TASK> dump_stack_lvl+0xa0/0xc0 dump_stack+0x10/0x20 ubsan_epilogue+0x9/0x40 __ubsan_handle_shift_out_of_bounds+0x10e/0x170 ? mutex_unlock+0x12/0x20 xe_vm_bind_ioctl.cold+0x20/0x3c [xe] ... " Fix it by validating prefetch_region before the BIT() usage. v2: Add Closes and Cc stable kernels. (Matt) Reported-by: Koen Koning <koen.koning@intel.com> Reported-by: Peter Senna Tschudin <peter.senna@linux.intel.com> Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6478 Cc: <stable@vger.kernel.org> # v6.8+ Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20251112181005.2120521-2-shuicheng.lin@intel.com (cherry picked from commit 8f565bdd14eec5611cc041dba4650e42ccdf71d9) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-11-18dm-pcache: zero cache_info before default initLi Chen1-1/+1
pcache_meta_find_latest() leaves whatever it last copied into the caller’s buffer even when it returns NULL. For cache_info_init(), that meant cache->cache_info could still contain CRC-bad garbage when no valid metadata exists, leading later initialization paths to read bogus flags. Explicitly memset cache->cache_info in cache_info_init_default() so new-cache paths start from a clean slate. The default sequence number assignment becomes redundant with this reset, so it drops out. Signed-off-by: Li Chen <chenl311@chinatelecom.cn> Reviewed-by: Zheng Gu <cengku@gmail.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2025-11-18dm-pcache: reuse meta_addr in pcache_meta_find_latestLi Chen1-1/+1
pcache_meta_find_latest() already computes the metadata address as meta_addr. Reuse that instead of recomputing. Signed-off-by: Li Chen <chenl311@chinatelecom.cn> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2025-11-18dm-pcache: allow built-in build and rename flush helperLi Chen4-6/+6
CONFIG_BCACHE is tristate, so dm-pcache can also be built-in. Switch the Makefile to use obj-$(CONFIG_DM_PCACHE) so the target can be linked into vmlinux instead of always being a loadable module. Also rename cache_flush() to pcache_cache_flush() to avoid a global symbol clash with sunrpc/cache.c's cache_flush(). Signed-off-by: Li Chen <chenl311@chinatelecom.cn> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2025-11-18drm/radeon: delete radeon_fence_process in is_signaled, no deadlockRobert McClinton1-7/+0
Delete the attempt to progress the queue when checking if fence is signaled. This avoids deadlock. dma-fence_ops::signaled can be called with the fence lock in unknown state. For radeon, the fence lock is also the wait queue lock. This can cause a self deadlock when signaled() tries to make forward progress on the wait queue. But advancing the queue is unneeded because incorrectly returning false from signaled() is perfectly acceptable. Link: https://github.com/brave/brave-browser/issues/49182 Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4641 Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Robert McClinton <rbmccav@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 527ba26e50ec2ca2be9c7c82f3ad42998a75d0db) Cc: stable@vger.kernel.org
2025-11-18drm/amd/display: Fix pbn to kbps ConversionFangzhi Zuo1-36/+23
[Why] Existing routine has two conversion sequence, pbn_to_kbps and kbps_to_pbn with margin. Non of those has without-margin calculation. kbps_to_pbn with margin conversion includes fec overhead which has already been included in pbn_div calculation with 0.994 factor considered. It is a double counted fec overhead factor that causes potential bw loss. [How] Add without-margin calculation. Fix fec overhead double counted issue. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3735 Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Fangzhi Zuo <Jerry.Zuo@amd.com> Signed-off-by: Ivan Lipski <ivan.lipski@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit e0dec00f3d05e8c0eceaaebfdca217f8d10d380c) Cc: stable@vger.kernel.org
2025-11-18HID: uclogic: Fix potential memory leak in error pathAbdun Nihaal1-1/+3
In uclogic_params_ugee_v2_init_event_hooks(), the memory allocated for event_hook is not freed in the next error path. Fix that by freeing it. Fixes: a251d6576d2a ("HID: uclogic: Handle wireless device reconnection") Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-11-18drm/amd/display: Clear the CUR_ENABLE register on DCN20 on DPP5Ivan Lipski1-0/+8
[Why] On DCN20 & DCN30, the 6th DPP's & HUBP's are powered on permanently and cannot be power gated. Thus, when dpp_reset() is invoked for the DPP5, while it's still powered on, the cached cursor_state (dpp_base->pos.cur0_ctl.bits.cur0_enable) and the actual state (CUR0_ENABLE) bit are unsycned. This can cause a double cursor in full screen with non-native scaling. [How] Force disable cursor on DPP5 on plane powerdown for ASICs w/ 6 DPPs/HUBPs. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4673 Reviewed-by: Aric Cyr <aric.cyr@amd.com> Signed-off-by: Ivan Lipski <ivan.lipski@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 79b3c037f972dcb13e325a8eabfb8da835764e15) Cc: stable@vger.kernel.org
2025-11-18HID: playstation: Fix memory leak in dualshock4_get_calibration_data()Abdun Nihaal1-0/+2
The memory allocated for buf is not freed in the error paths when ps_get_report() fails. Free buf before jumping to transfer_failed label Fixes: 947992c7fa9e ("HID: playstation: DS4: Fix calibration workaround for clone devices") Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in> Reviewed-by: Silvan Jegen <s.jegen@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-11-18drm/amd/display: Add an HPD filter for HDMIIvan Lipski2-0/+144
[Why] Some monitors perform rapid “autoscan” HPD re‑assertions right after a disconnect or powersaving mode enablement. These appear as a quick disconnect→reconnect with an identical EDID. Since Linux has no HDMI hotplug detection (HPD) filter, these quick reconnects are seen as hotplug events, which can unintentionally wake a system with DPMS off. An example: https://gitlab.freedesktop.org/drm/amd/-/issues/2876 Such 'fake reconnects' are considered when the interval between a disconnect and a connect is within 1500ms (experimentally chosen using several monitors), and the two connections have the same EDID. [How] Implement a time-based debounce mechanism: 1. On HDMI disconnect detection, instead of immediately processing the HPD event, save the current sink and schedule delayed work (default 1500ms) 2. If another HDMI disconnect HPD event arrives during the debounce period, it reschedules the pending work, ensuring only the final state is processed. 3. When the debounce timer expires, re-detect the display and compare the new sink with the cached one using EDID comparison. 4. If sinks match (same EDID), this was a spontaneous HPD toggle: - Update connector state internally - Skip hotplug event to prevent desktop rearrangement If sinks differ, this was a real display change: - Process normally with the hotplug event The debounce delay is configurable via module parameter 'hdmi_hpd_debounce_delay_ms'. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/2876 Reviewed-by: Sun peng (Leo) Li <sunpeng.li@amd.com> Signed-off-by: Ivan Lipski <ivan.lipski@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit c918e75e1ed95be76f8e3156a411188f650fe03f)
2025-11-18drm/amd/display: Increase DPCD read retriesMario Limonciello (AMD)1-1/+1
[Why] Empirical measurement of some monitors that fail to read EDID while booting shows that the number of retries with a 30ms delay between tries is as high as 16. [How] Increase number of retries to 20. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4672 Reviewed-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Ivan Lipski <ivan.lipski@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit ad1c59ad7cf74ec06e32fe2c330ac1e957222288) Cc: stable@vger.kernel.org
2025-11-18HID: pidff: Fix needs_playback checkTomasz Pakuła1-2/+2
A small bug made it's way here when rewriting code to Linux quality. Currently, if an effect is not infinite and a program requests it's playback with the same number of loops, the play command won't be fired and if an effect is infinite, the spam will continue. We want every playback update for non-infinite effects and only some for infinite (detecting when a program requests stop with 0 which will be different than previous value which is usually 1 or 255). Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-11-18HID: corsair-void: Use %pe for printing PTR_ERRStuart Hayhurst1-3/+2
Use %pe to print a PTR_ERR to silence a cocci warning Reported-by: kernel test robot <lkp@intel.com> Reported-by: Julia Lawall <julia.lawall@inria.fr> Closes: https://lore.kernel.org/r/202510300342.WtPn2jF3-lkp@intel.com/ Signed-off-by: Stuart Hayhurst <stuart.a.hayhurst@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-11-18drm/amd/display: Move sleep into each retry for retrieve_link_cap()Mario Limonciello (AMD)1-4/+5
[Why] When a monitor is booting it's possible that it isn't ready to retrieve link caps and this can lead to an EDID read failure: ``` [drm:retrieve_link_cap [amdgpu]] *ERROR* retrieve_link_cap: Read receiver caps dpcd data failed. amdgpu 0000:c5:00.0: [drm] *ERROR* No EDID read. ``` [How] Rather than msleep once and try a few times, msleep each time. Should be no changes for existing working monitors, but should correct reading caps on a monitor that is slow to boot. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4672 Reviewed-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Ivan Lipski <ivan.lipski@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 669dca37b3348a447db04bbdcbb3def94d5997cc) Cc: stable@vger.kernel.org
2025-11-18HID: elecom: Add support for ELECOM M-XT3URBK (018F)Naoki Ueki3-4/+8
The ELECOM M-XT3URBK trackball has an additional device ID (0x018F), which shares the same report descriptor as the existing device (0x00FB). However, the driver does not currently recognize this new ID, resulting in only five buttons being functional. This patch adds the new device ID so that all six buttons work properly. Signed-off-by: Naoki Ueki <naoki25519@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-11-18drm/amd/display: Prevent Gating DTBCLK before It Is Properly LatchedFangzhi Zuo2-2/+4
[why] 1. With allow_0_dtb_clk enabled, the time required to latch DTBCLK to 600 MHz depends on the SMU. If DTBCLK is not latched to 600 MHz before set_mode completes, gating DTBCLK causes the DP2 sink to lose its clock source. 2. The existing DTBCLK gating sequence ungates DTBCLK based on both pix_clk and ref_dtbclk, but gates DTBCLK when either pix_clk or ref_dtbclk is zero. pix_clk can be zero outside the set_mode sequence before DTBCLK is properly latched, which can lead to DTBCLK being gated by mistake. [how] Consider both pixel_clk and ref_dtbclk when determining when it is safe to gate DTBCLK; this is more accurate. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4701 Fixes: 5949e7c4890c ("drm/amd/display: Enable Dynamic DTBCLK Switch") Reviewed-by: Charlene Liu <charlene.liu@amd.com> Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Fangzhi Zuo <Jerry.Zuo@amd.com> Signed-off-by: Roman Li <roman.li@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit d04eb0c402780ca037b62a6aecf23b863545ebca) Cc: stable@vger.kernel.org
2025-11-18PM: sleep: core: Fix runtime PM enabling in device_resume_early()Rafael J. Wysocki1-9/+16
Runtime PM should only be enabled in device_resume_early() if it has been disabled for the given device by device_suspend_late(). Otherwise, it may cause runtime PM callbacks to run prematurely in some cases which leads to further functional issues. Make two changes to address this problem. First, reorder device_suspend_late() to only disable runtime PM for a device when it is going to look for the device's callback or if the device is a "syscore" one. In all of the other cases, disabling runtime PM for the device is not in fact necessary. However, if the device's callback returns an error and the power.is_late_suspended flag is not going to be set, enable runtime PM so it only remains disabled when power.is_late_suspended is set. Second, make device_resume_early() only enable runtime PM for the devices with the power.is_late_suspended flag set. Fixes: 443046d1ad66 ("PM: sleep: Make suspend of devices more asynchronous") Reported-by: Rose Wu <ya-jou.wu@mediatek.com> Closes: https://lore.kernel.org/linux-pm/70b25dca6f8c2756d78f076f4a7dee7edaaffc33.camel@mediatek.com/ Cc: 6.16+ <stable@vger.kernel.org> # 6.16+ Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/12784270.O9o76ZdvQC@rafael.j.wysocki
2025-11-18drm/i915/xe3: Restrict PTL intel_encoder_is_c10phy() to only PHY ADnyaneshwar Bhadane1-8/+6
On PTL, no combo PHY is connected to PORT B. However, PORT B can still be used for Type-C and will utilize the C20 PHY for eDP over Type-C. In such configurations, VBTs also enumerate PORT B. This leads to issues where PORT B is incorrectly identified as using the C10 PHY, due to the assumption that returning true for PORT B in intel_encoder_is_c10phy() would not cause problems. From PTL's perspective, only PORT A/PHY A uses the C10 PHY. Update the helper intel_encoder_is_c10phy() to return true only for PORT A/PHY on PTL. v2: Change the condition code style for ptl/wcl Bspec: 72571,73944 Fixes: 9d10de78a37f ("drm/i915/wcl: C10 phy connected to port A and B") Signed-off-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/20250922150317.2334680-4-dnyaneshwar.bhadane@intel.com (cherry picked from commit 8147f7a1c083fd565fb958824f7c552de3b2dc46) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-11-18drm/i915/display: Add definition for wcl as subplatformDnyaneshwar Bhadane2-1/+15
We will need to differentiate between WCL and PTL in intel_encoder_is_c10phy(). Since WCL and PTL use the same display architecture, let's define WCL as a subplatform of PTL to allow the differentiation. v2: Update commit message and reorder wcl define (Gustavo) Fixes: 3c0f211bc8fc ("drm/xe: Add Wildcat Lake device IDs to PTL list") Signed-off-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/20250922150317.2334680-3-dnyaneshwar.bhadane@intel.com (cherry picked from commit 4dfaae643e59cf3ab71b88689dce1b874f036f00) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> [Rodrigo added Fixes tag when porting it to fixes]
2025-11-18drm/pcids: Split PTL pciids group to make wcl subplatformDnyaneshwar Bhadane2-0/+2
To form the WCL platform as a subplatform of PTL in definition, WCL pci ids are splited into saparate group from PTL. So update the pciidlist struct to cover all the pci ids. v2: - Squash wcl description in single patch for display and xe.(jani,gustavo) Fixes: 3c0f211bc8fc ("drm/xe: Add Wildcat Lake device IDs to PTL list") Signed-off-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/20250922150317.2334680-2-dnyaneshwar.bhadane@intel.com (cherry picked from commit 32620e176443bf23ec81bfe8f177c6721a904864) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> [Rodrigo added the Fixes tag when porting it to fixes]
2025-11-18net: ps3_gelic_net: handle skb allocation failuresFlorian Fuchs2-11/+35
Handle skb allocation failures in RX path, to avoid NULL pointer dereference and RX stalls under memory pressure. If the refill fails with -ENOMEM, complete napi polling and wake up later to retry via timer. Also explicitly re-enable RX DMA after oom, so the dmac doesn't remain stopped in this situation. Previously, memory pressure could lead to skb allocation failures and subsequent Oops like: Oops: Kernel access of bad area, sig: 11 [#2] Hardware name: SonyPS3 Cell Broadband Engine 0x701000 PS3 NIP [c0003d0000065900] gelic_net_poll+0x6c/0x2d0 [ps3_gelic] (unreliable) LR [c0003d00000659c4] gelic_net_poll+0x130/0x2d0 [ps3_gelic] Call Trace: gelic_net_poll+0x130/0x2d0 [ps3_gelic] (unreliable) __napi_poll+0x44/0x168 net_rx_action+0x178/0x290 Steps to reproduce the issue: 1. Start a continuous network traffic, like scp of a 20GB file 2. Inject failslab errors using the kernel fault injection: echo -1 > /sys/kernel/debug/failslab/times echo 30 > /sys/kernel/debug/failslab/interval echo 100 > /sys/kernel/debug/failslab/probability 3. After some time, traces start to appear, kernel Oopses and the system stops Step 2 is not always necessary, as it is usually already triggered by the transfer of a big enough file. Fixes: 02c1889166b4 ("ps3: gigabit ethernet driver for PS3, take3") Signed-off-by: Florian Fuchs <fuchsfl@gmail.com> Link: https://patch.msgid.link/20251113181000.3914980-1-fuchsfl@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-11-18net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and ↵Pavel Zhigulin1-2/+3
qede_tpa_end() The loops in 'qede_tpa_cont()' and 'qede_tpa_end()', iterate over 'cqe->len_list[]' using only a zero-length terminator as the stopping condition. If the terminator was missing or malformed, the loop could run past the end of the fixed-size array. Add an explicit bound check using ARRAY_SIZE() in both loops to prevent a potential out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 55482edc25f0 ("qede: Add slowpath/fastpath support and enable hardware GRO") Signed-off-by: Pavel Zhigulin <Pavel.Zhigulin@kaspersky.com> Link: https://patch.msgid.link/20251113112757.4166625-1-Pavel.Zhigulin@kaspersky.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-11-18platform/x86: intel-uncore-freq: fix all header kernel-doc warningsRandy Dunlap1-4/+5
In file uncore-frequency/uncore-frequency-common.h, correct all kernel-doc warnings by adding missing leading " *" to some lines, adding a missing kernel-doc entry, and fixing a name typo. Warning: uncore-frequency-common.h:50 bad line: Storage for kobject attribute elc_low_threshold_percent Warning: uncore-frequency-common.h:52 bad line: Storage for kobject attribute elc_high_threshold_percent Warning: uncore-frequency-common.h:54 bad line: Storage for kobject attribute elc_high_threshold_enable Warning: uncore-frequency-common.h:92 struct member 'min_freq_khz_kobj_attr' not described in 'uncore_data' Warning: uncore-frequency-common.h:92 struct member 'die_id_kobj_attr' not described in 'uncore_data' Fixes: 24b6616355f7 ("platform/x86/intel-uncore-freq: Add efficiency latency control to sysfs interface") Fixes: 416de0246f35 ("platform/x86: intel-uncore-freq: Fix types in sysfs callbacks") Fixes: 247b43fcd872 ("platform/x86/intel-uncore-freq: Add attributes to show die_id") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Link: https://patch.msgid.link/20251111060938.1998542-1-rdunlap@infradead.org Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-11-18platform/x86: acer-wmi: Ignore backlight eventArmin Wolf1-0/+4
On the Acer Nitro AN515-58, the event 4 - 0 is send by the ACPI firmware when the backlight up/down keys are pressed. Ignore this event to avoid spamming the kernel log with error messages, as the acpi-video driver already handles brightness up/down events. Reported-by: Bugaddr <Bugaddr@protonmail.com> Closes: https://bugaddr.tech/posts/2025-11-16-debugging-the-acer-nitro-5-an515-58-fn-f10-keyboard-backlight-bug-on-linux/#wmi-interface-issues Tested-by: Bugaddr <Bugaddr@protonmail.com> Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://patch.msgid.link/20251117155938.3030-1-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-11-18platform/x86/intel/speed_select_if: Convert PCIBIOS_* return codes to errnosHaotian Zhang1-2/+2
isst_if_probe() uses pci_read_config_dword() that returns PCIBIOS_* codes. The return code is returned from the probe function as is but probe functions should return normal errnos. A proper implementation can be found in drivers/leds/leds-ss4200.c. Convert PCIBIOS_* return codes using pcibios_err_to_errno() into normal errno before returning. Fixes: d3a23584294c ("platform/x86: ISST: Add Intel Speed Select mmio interface") Signed-off-by: Haotian Zhang <vulab@iscas.ac.cn> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://patch.msgid.link/20251117033354.132-1-vulab@iscas.ac.cn Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-11-18platform/x86/intel/hid: Add Nova Lake supportSrinivas Pandruvada1-0/+1
Add ACPI ID for Nova Lake. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://patch.msgid.link/20251110235041.123685-1-srinivas.pandruvada@linux.intel.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-11-18platform/x86: alienware-wmi-wmax: Add AWCC support to Alienware 16 AuroraAnthony Wong1-0/+8
Add AWCC support to Alienware 16 Aurora Cc: stable@vger.kernel.org Signed-off-by: Anthony Wong <anthony.wong@ubuntu.com> Reviewed-by: Kurt Borja <kuurtb@gmail.com> Link: https://patch.msgid.link/20251116185311.18074-1-anthony.wong@canonical.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-11-17Input: rename INPUT_PROP_HAPTIC_TOUCHPAD to INPUT_PROP_PRESSUREPADPeter Hutterer1-1/+1
And expand it to encompass all pressure pads. Definition: "pressure pad" as used here as includes all touchpads that use physical pressure to convert to click, without physical hinges. Also called haptic touchpads in general parlance, Synaptics calls them ForcePads. Most (all?) pressure pads are currently advertised as INPUT_PROP_BUTTONPAD. The suggestion to identify them as pressure pads by defining the resolution on ABS_MT_PRESSURE has been in the docs since commit 20ccc8dd38a3 ("Documentation: input: define ABS_PRESSURE/ABS_MT_PRESSURE resolution as grams") but few devices provide this information. In userspace it's thus impossible to determine whether a device is a true pressure pad (pressure equals pressure) or a normal clickpad with (pressure equals finger size). Commit 7075ae4ac9db ("Input: add INPUT_PROP_HAPTIC_TOUCHPAD") introduces INPUT_PROP_HAPTIC_TOUCHPAD but restricted it to those touchpads that have support for userspace-controlled effects. Let's expand and rename that definition to include all pressure pad touchpads since those that do support FF effects can be identified by the presence of the FF_HAPTIC bit. This means: - clickpad: INPUT_PROP_BUTTONPAD - pressurepad: INPUT_PROP_BUTTONPAD + INPUT_PROP_PRESSUREPAD - pressurepad with configurable haptics: INPUT_PROP_BUTTONPAD + INPUT_PROP_PRESSUREPAD + FF_HAPTIC Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Acked-by: Benjamin Tissoires <bentiss@kernel.org> Link: https://patch.msgid.link/20251106114534.GA405512@tassie Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2025-11-17Merge tag 'v6.18-rc6' into for-linusDmitry Torokhov5597-89951/+288868
Sync up with the mainline to bring in definition of INPUT_PROP_HAPTIC_TOUCHPAD.
2025-11-17net: airoha: Do not loopback traffic to GDM2 if it is available on the deviceLorenzo Bianconi1-1/+1
Airoha_eth driver forwards offloaded uplink traffic (packets received on GDM1 and forwarded to GDM{3,4}) to GDM2 in order to apply hw QoS. This is correct if the device does not support a dedicated GDM2 port. In this case, in order to enable hw offloading for uplink traffic, the packets should be sent to GDM{3,4} directly. Fixes: 9cd451d414f6 ("net: airoha: Add loopback support for GDM2") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20251113-airoha-hw-offload-gdm2-fix-v1-1-7e4ca300872f@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-17s390/ctcm: Fix double-kfreeAleksei Nikiforov1-1/+0
The function 'mpc_rcvd_sweep_req(mpcginfo)' is called conditionally from function 'ctcmpc_unpack_skb'. It frees passed mpcginfo. After that a call to function 'kfree' in function 'ctcmpc_unpack_skb' frees it again. Remove 'kfree' call in function 'mpc_rcvd_sweep_req(mpcginfo)'. Bug detected by the clang static analyzer. Fixes: 0c0b20587b9f25a2 ("s390/ctcm: fix potential memory leak") Reviewed-by: Aswin Karuvally <aswin@linux.ibm.com> Signed-off-by: Aleksei Nikiforov <aleksei.nikiforov@linux.ibm.com> Signed-off-by: Aswin Karuvally <aswin@linux.ibm.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20251112182724.1109474-1-aswin@linux.ibm.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-17nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::bootNam Cao1-0/+2
nvkm_falcon_fw::boot is allocated, but no one frees it. This causes a kmemleak warning. Make sure this data is deallocated. Fixes: 2541626cfb79 ("drm/nouveau/acr: use common falcon HS FW code for ACR FWs") Signed-off-by: Nam Cao <namcao@linutronix.de> Cc: stable@vger.kernel.org Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patch.msgid.link/20251117084231.2910561-1-namcao@linutronix.de
2025-11-17drm/i915/xe3lpd: Load DMC for Xe3_LPD version 30.02Dnyaneshwar Bhadane1-3/+7
Load the DMC for Xe3_LPD version 30.02. Fixes: 3c0f211bc8fc ("drm/xe: Add Wildcat Lake device IDs to PTL list") Signed-off-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Link: https://lore.kernel.org/r/20251016131517.2032684-1-dnyaneshwar.bhadane@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> (cherry picked from commit a63db39a578b543f5e5719b9f14dd82d3b8648d1) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> [Rodrigo added the Fixes tag while cherry-picking to fixes]
2025-11-17nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl()Ewan D. Milne1-1/+1
nvme_fc_delete_assocation() waits for pending I/O to complete before returning, and an error can cause ->ioerr_work to be queued after cancel_work_sync() had been called. Move the call to cancel_work_sync() to be after nvme_fc_delete_association() to ensure ->ioerr_work is not running when the nvme_fc_ctrl object is freed. Otherwise the following can occur: [ 1135.911754] list_del corruption, ff2d24c8093f31f8->next is NULL [ 1135.917705] ------------[ cut here ]------------ [ 1135.922336] kernel BUG at lib/list_debug.c:52! [ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary) [ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025 [ 1135.950969] Workqueue: 0x0 (nvme-wq) [ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f [ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b [ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046 [ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000 [ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0 [ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08 [ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100 [ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0 [ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000 [ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0 [ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 1136.055910] PKRU: 55555554 [ 1136.058623] Call Trace: [ 1136.061074] <TASK> [ 1136.063179] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.067540] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.071898] ? move_linked_works+0x4a/0xa0 [ 1136.075998] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.081744] ? __die_body.cold+0x8/0x12 [ 1136.085584] ? die+0x2e/0x50 [ 1136.088469] ? do_trap+0xca/0x110 [ 1136.091789] ? do_error_trap+0x65/0x80 [ 1136.095543] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.101289] ? exc_invalid_op+0x50/0x70 [ 1136.105127] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.110874] ? asm_exc_invalid_op+0x1a/0x20 [ 1136.115059] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.120806] move_linked_works+0x4a/0xa0 [ 1136.124733] worker_thread+0x216/0x3a0 [ 1136.128485] ? __pfx_worker_thread+0x10/0x10 [ 1136.132758] kthread+0xfa/0x240 [ 1136.135904] ? __pfx_kthread+0x10/0x10 [ 1136.139657] ret_from_fork+0x31/0x50 [ 1136.143236] ? __pfx_kthread+0x10/0x10 [ 1136.146988] ret_from_fork_asm+0x1a/0x30 [ 1136.150915] </TASK> Fixes: 19fce0470f05 ("nvme-fc: avoid calling _nvme_fc_abort_outstanding_ios from interrupt context") Cc: stable@vger.kernel.org Tested-by: Marco Patalano <mpatalan@redhat.com> Reviewed-by: Justin Tee <justin.tee@broadcom.com> Signed-off-by: Ewan D. Milne <emilne@redhat.com> Signed-off-by: Keith Busch <kbusch@kernel.org>
2025-11-17nvme: nvme-fc: move tagset removal to nvme_fc_delete_ctrl()Ewan D. Milne1-6/+7
Now target is removed from nvme_fc_ctrl_free() which is the ctrl->ref release handler. And even admin queue is unquiesced there, this way is definitely wrong because the ctr->ref is grabbed when submitting command. And Marco observed that nvme_fc_ctrl_free() can be called from request completion code path, and trigger kernel warning since request completes from softirq context. Fix the issue by moveing target removal into nvme_fc_delete_ctrl(), which is also aligned with nvme-tcp and nvme-rdma. Patch originally proposed by Ming Lei, then modified to move the tagset removal down to after nvme_fc_delete_association() after further testing. Cc: Marco Patalano <mpatalan@redhat.com> Cc: Ewan Milne <emilne@redhat.com> Cc: James Smart <james.smart@broadcom.com> Cc: Sagi Grimberg <sagi@grimberg.me> Signed-off-by: Ming Lei <ming.lei@redhat.com> Cc: stable@vger.kernel.org Tested-by: Marco Patalano <mpatalan@redhat.com> Reviewed-by: Justin Tee <justin.tee@broadcom.com> Signed-off-by: Ewan D. Milne <emilne@redhat.com> Signed-off-by: Keith Busch <kbusch@kernel.org>
2025-11-17Merge tag 'mtd/fixes-for-6.18-rc7' of ↵Linus Torvalds6-9/+12
git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux Pull MTD fixes from Miquel Raynal: "Mostly small misc fixes, here they are sorted by sub-subsystem: ECC fixes: - Realtek Kconfig fix SPI NAND fixes: - Remove nonexistent QE bit on FMSH FM25S01A Raw NAND fixes: - Prevent DMA device NULL pointer dereference in Cadence driver MTD device fixes: - Possible integer overflow in read/write ioctls - Fix the IRQ handler pointer in the onenand driver, even if in practice it is never dereferenced. * tag 'mtd/fixes-for-6.18-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux: mtd: onenand: Pass correct pointer to IRQ handler mtd: spinand: fmsh: remove QE bit for FM25S01A flash mtd: rawnand: cadence: fix DMA device NULL pointer dereference mtd: rawnand: realtek: Make rtl_ecc_engine_ops const mtd: nand: MTD_NAND_ECC_REALTEK should depend on HAS_DMA mtd: nand: realtek-ecc: Fix a IS_ERR() vs NULL bug in probe mtdchar: fix integer overflow in read/write ioctls
2025-11-17can: sun4i_can: sun4i_can_interrupt(): fix max irq loop handlingMarc Kleine-Budde1-2/+2
Reading the interrupt register `SUN4I_REG_INT_ADDR` causes all of its bits to be reset. If we ever reach the condition of handling more than `SUN4I_CAN_MAX_IRQ` IRQs, we will have read the register and reset all its bits but without actually handling the interrupt inside of the loop body. This may, among other issues, cause us to never `netif_wake_queue()` again after a transmission interrupt. Fixes: 0738eff14d81 ("can: Allwinner A10/A20 CAN Controller support - Kernel module") Cc: stable@vger.kernel.org Co-developed-by: Thomas Mühlbacher <tmuehlbacher@posteo.net> Signed-off-by: Thomas Mühlbacher <tmuehlbacher@posteo.net> Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://patch.msgid.link/20251116-sun4i-fix-loop-v1-1-3d76d3f81950@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-11-17can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before ↵Marc Kleine-Budde1-5/+54
accessing data The URB received in gs_usb_receive_bulk_callback() contains a struct gs_host_frame. The length of the data after the header depends on the gs_host_frame hf::flags and the active device features (e.g. time stamping). Introduce a new function gs_usb_get_minimum_length() and check that we have at least received the required amount of data before accessing it. Only copy the data to that skb that has actually been received. Fixes: d08e973a77d1 ("can: gs_usb: Added support for the GS_USB CAN devices") Link: https://patch.msgid.link/20251114-gs_usb-fix-usb-callbacks-v1-3-a29b42eacada@pengutronix.de [mkl: rename gs_usb_get_minimum_length() -> +gs_usb_get_minimum_rx_length()] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-11-17nvme-multipath: fix lockdep WARN due to partition scan workShin'ichiro Kawasaki1-1/+1
Blktests test cases nvme/014, 057 and 058 fail occasionally due to a lockdep WARN. As reported in the Closes tag URL, the WARN indicates that a deadlock can happen due to the dependency among disk->open_mutex, kblockd workqueue completion and partition_scan_work completion. To avoid the lockdep WARN and the potential deadlock, cut the dependency by running the partition_scan_work not by kblockd workqueue but by nvme_wq. Reported-by: Yi Zhang <yi.zhang@redhat.com> Closes: https://lore.kernel.org/linux-block/CAHj4cs8mJ+R_GmQm9R8ebResKAWUE8kF5+_WVg0v8zndmqd6BQ@mail.gmail.com/ Link: https://lore.kernel.org/linux-block/oeyzci6ffshpukpfqgztsdeke5ost5hzsuz4rrsjfmvpqcevax@5nhnwbkzbrpa/ Fixes: 1f021341eef4 ("nvme-multipath: defer partition scanning") Signed-off-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Keith Busch <kbusch@kernel.org>
2025-11-17nvmet-auth: update sc_c in target host hash calculationAlistair Francis3-2/+4
Commit 7e091add9c43 "nvme-auth: update sc_c in host response" added the sc_c variable to the dhchap queue context structure which is appropriately set during negotiate and then used in the host response. This breaks secure concat connections with a Linux target as the target code wasn't updated at the same time. This patch fixes this by adding a new sc_c variable to the host hash calculations. Fixes: 7e091add9c43 ("nvme-auth: update sc_c in host response") Tested-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com> Tested-by: Yi Zhang <yi.zhang@redhat.com> Reviewed-by: Martin George <marting@netapp.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Keith Busch <kbusch@kernel.org>
2025-11-16tools: riscv: Fixed misalignment of CSR related definitionsChen Pei1-1/+1
The file tools/arch/riscv/include/asm/csr.h borrows from arch/riscv/include/asm/csr.h, and subsequent modifications related to CSR should maintain consistency. Signed-off-by: Chen Pei <cp0613@linux.alibaba.com> Link: https://patch.msgid.link/20251114071215.816-1-cp0613@linux.alibaba.com [pjw@kernel.org: dropped Fixes: lines for patches that weren't broken; removed superfluous blank line] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-11-16can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before ↵Marc Kleine-Budde1-7/+19
accessing header The driver expects to receive a struct gs_host_frame in gs_usb_receive_bulk_callback(). Use struct_group to describe the header of the struct gs_host_frame and check that we have at least received the header before accessing any members of it. To resubmit the URB, do not dereference the pointer chain "dev->parent->hf_size_rx" but use "parent->hf_size_rx" instead. Since "urb->context" contains "parent", it is always defined, while "dev" is not defined if the URB it too short. Fixes: d08e973a77d1 ("can: gs_usb: Added support for the GS_USB CAN devices") Link: https://patch.msgid.link/20251114-gs_usb-fix-usb-callbacks-v1-2-a29b42eacada@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-11-16can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted URBsMarc Kleine-Budde1-2/+15
The driver lacks the cleanup of failed transfers of URBs. This reduces the number of available URBs per error by 1. This leads to reduced performance and ultimately to a complete stop of the transmission. If the sending of a bulk URB fails do proper cleanup: - increase netdev stats - mark the echo_sbk as free - free the driver's context and do accounting - wake the send queue Closes: https://github.com/candle-usb/candleLight_fw/issues/187 Fixes: d08e973a77d1 ("can: gs_usb: Added support for the GS_USB CAN devices") Link: https://patch.msgid.link/20251114-gs_usb-fix-usb-callbacks-v1-1-a29b42eacada@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-11-16can: sja1000: fix max irq loop handlingThomas Mühlbacher1-2/+2
Reading the interrupt register `SJA1000_IR` causes all of its bits to be reset. If we ever reach the condition of handling more than `SJA1000_MAX_IRQ` IRQs, we will have read the register and reset all its bits but without actually handling the interrupt inside of the loop body. This may, among other issues, cause us to never `netif_wake_queue()` again after a transmission interrupt. Fixes: 429da1cc841b ("can: Driver for the SJA1000 CAN controller") Cc: stable@vger.kernel.org Signed-off-by: Thomas Mühlbacher <tmuehlbacher@posteo.net> Acked-by: Oliver Hartkopp <socketcan@hartkopp.net> Link: https://patch.msgid.link/20251115153437.11419-1-tmuehlbacher@posteo.net Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-11-16can: kvaser_usb: leaf: Fix potential infinite loop in command parsersSeungjin Bae1-2/+2
The `kvaser_usb_leaf_wait_cmd()` and `kvaser_usb_leaf_read_bulk_callback` functions contain logic to zero-length commands. These commands are used to align data to the USB endpoint's wMaxPacketSize boundary. The driver attempts to skip these placeholders by aligning the buffer position `pos` to the next packet boundary using `round_up()` function. However, if zero-length command is found exactly on a packet boundary (i.e., `pos` is a multiple of wMaxPacketSize, including 0), `round_up` function will return the unchanged value of `pos`. This prevents `pos` to be increased, causing an infinite loop in the parsing logic. This patch fixes this in the function by using `pos + 1` instead. This ensures that even if `pos` is on a boundary, the calculation is based on `pos + 1`, forcing `round_up()` to always return the next aligned boundary. Fixes: 7259124eac7d ("can: kvaser_usb: Split driver into kvaser_usb_core.c and kvaser_usb_leaf.c") Signed-off-by: Seungjin Bae <eeodqql09@gmail.com> Reviewed-by: Jimmy Assarsson <extja@kvaser.com> Tested-by: Jimmy Assarsson <extja@kvaser.com> Link: https://patch.msgid.link/20251023162709.348240-1-eeodqql09@gmail.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-11-16Merge tag 'firewire-fixes-6.18-rc6' of ↵Linus Torvalds2-1/+4
git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394 Pull firewire fixes from Takashi Sakamoto: "This includes some fixes for the topology map, newly introduced in v6.18 kernel" * tag 'firewire-fixes-6.18-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394: firewire: core: fix to update generation field in topology map firewire: core: Initialize topology_map.lock
2025-11-16Merge tag 'edac_urgent_for_v6.18_rc6' of ↵Linus Torvalds2-16/+30
git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras Pull EDAC fixes from Borislav Petkov: - In Versalnet, handle the reporting of non-standard hw errors whose information can come in more than one remote processor message. - Explicitly reenable ECC checking after a warm reset in Altera OCRAM as those registers are reset to default otherwise - Fix single-bit error injection in Altera EDAC to not inject errors directly in ECC RAM and thus lead to false double-bit errors due to same ECC RAM being in concurrent use * tag 'edac_urgent_for_v6.18_rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras: EDAC/altera: Use INTTEST register for Ethernet and USB SBE injection EDAC/altera: Handle OCRAM ECC enable after warm reset EDAC/versalnet: Handle split messages for non-standard errors
2025-11-16firewire: core: fix to update generation field in topology mapTakashi Sakamoto1-1/+2
The generation field of topology map is updated after initialized by zero. The updated value of generation field is always zero, and is against specification. This commit fixes the bug. Fixes: 7d138cb269db ("firewire: core: use spin lock specific to topology map") Link: https://lore.kernel.org/r/20251114144421.415278-1-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2025-11-15Merge tag 'irq-urgent-2025-11-15' of ↵Linus Torvalds1-1/+2
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull irq fix from Ingo Molnar: "Fix an irqchip driver release bug in the riscv-intc irqchip driver" * tag 'irq-urgent-2025-11-15' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: irqchip/riscv-intc: Add missing free() callback in riscv_intc_domain_ops
2025-11-14veth: more robust handing of race to avoid txq getting stuckJesper Dangaard Brouer1-18/+20
Commit dc82a33297fc ("veth: apply qdisc backpressure on full ptr_ring to reduce TX drops") introduced a race condition that can lead to a permanently stalled TXQ. This was observed in production on ARM64 systems (Ampere Altra Max). The race occurs in veth_xmit(). The producer observes a full ptr_ring and stops the queue (netif_tx_stop_queue()). The subsequent conditional logic, intended to re-wake the queue if the consumer had just emptied it (if (__ptr_ring_empty(...)) netif_tx_wake_queue()), can fail. This leads to a "lost wakeup" where the TXQ remains stopped (QUEUE_STATE_DRV_XOFF) and traffic halts. This failure is caused by an incorrect use of the __ptr_ring_empty() API from the producer side. As noted in kernel comments, this check is not guaranteed to be correct if a consumer is operating on another CPU. The empty test is based on ptr_ring->consumer_head, making it reliable only for the consumer. Using this check from the producer side is fundamentally racy. This patch fixes the race by adopting the more robust logic from an earlier version V4 of the patchset, which always flushed the peer: (1) In veth_xmit(), the racy conditional wake-up logic and its memory barrier are removed. Instead, after stopping the queue, we unconditionally call __veth_xdp_flush(rq). This guarantees that the NAPI consumer is scheduled, making it solely responsible for re-waking the TXQ. This handles the race where veth_poll() consumes all packets and completes NAPI *before* veth_xmit() on the producer side has called netif_tx_stop_queue. The __veth_xdp_flush(rq) will observe rx_notify_masked is false and schedule NAPI. (2) On the consumer side, the logic for waking the peer TXQ is moved out of veth_xdp_rcv() and placed at the end of the veth_poll() function. This placement is part of fixing the race, as the netif_tx_queue_stopped() check must occur after rx_notify_masked is potentially set to false during NAPI completion. This handles the race where veth_poll() consumes all packets, but haven't finished (rx_notify_masked is still true). The producer veth_xmit() stops the TXQ and __veth_xdp_flush(rq) will observe rx_notify_masked is true, meaning not starting NAPI. Then veth_poll() change rx_notify_masked to false and stops NAPI. Before exiting veth_poll() will observe TXQ is stopped and wake it up. Fixes: dc82a33297fc ("veth: apply qdisc backpressure on full ptr_ring to reduce TX drops") Reviewed-by: Toshiaki Makita <toshiaki.makita1@gmail.com> Signed-off-by: Jesper Dangaard Brouer <hawk@kernel.org> Link: https://patch.msgid.link/176295323282.307447.14790015927673763094.stgit@firesoul Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-14net: mlxsw: linecards: fix missing error check in ↵Pavel Zhigulin1-0/+2
mlxsw_linecard_devlink_info_get() The call to devlink_info_version_fixed_put() in mlxsw_linecard_devlink_info_get() did not check for errors, although it is checked everywhere in the code. Add missed 'err' check to the mlxsw_linecard_devlink_info_get() Fixes: 3fc0c51905fb ("mlxsw: core_linecards: Expose device PSID over device info") Signed-off-by: Pavel Zhigulin <Pavel.Zhigulin@kaspersky.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20251113161922.813828-1-Pavel.Zhigulin@kaspersky.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-14net: dsa: hellcreek: fix missing error handling in LED registrationPavel Zhigulin1-2/+12
The LED setup routine registered both led_sync_good and led_is_gm devices without checking the return values of led_classdev_register(). If either registration failed, the function continued silently, leaving the driver in a partially-initialized state and leaking a registered LED classdev. Add proper error handling Fixes: 7d9ee2e8ff15 ("net: dsa: hellcreek: Add PTP status LEDs") Signed-off-by: Pavel Zhigulin <Pavel.Zhigulin@kaspersky.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Kurt Kanzenbach <kurt@linutronix.de> Link: https://patch.msgid.link/20251113135745.92375-1-Pavel.Zhigulin@kaspersky.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-14Merge tag 'pci-v6.18-fixes-5' of ↵Linus Torvalds4-28/+48
git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci Pull pci fixes from Bjorn Helgaas: - Cache the ASPM L0s/L1 Supported bits early so quirks can override them if necessary (Bjorn Helgaas) - Add quirks for PA Semi and Freescale Root Ports and a HiSilicon Wi-Fi device that are reported to have broken L0s and L1 (Shawn Lin, Bjorn Helgaas) * tag 'pci-v6.18-fixes-5' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci: PCI/ASPM: Avoid L0s and L1 on Hi1105 [19e5:1105] Wi-Fi PCI/ASPM: Avoid L0s and L1 on PA Semi [1959:a002] Root Ports PCI/ASPM: Avoid L0s and L1 on Freescale [1957:0451] Root Ports PCI/ASPM: Convert quirks to override advertised link states PCI/ASPM: Add pcie_aspm_remove_cap() to override advertised link states PCI/ASPM: Cache L0s/L1 Supported so advertised link states can be overridden
2025-11-14Merge tag 'drm-fixes-2025-11-15' of https://gitlab.freedesktop.org/drm/kernelLinus Torvalds17-20/+102
Pull drm fixes from Dave Airlie: "Weekly fixes, amdgpu and vmwgfx making up the most of it, along with panthor and i915/xe. Seems about right for this time of development, nothing major outstanding. client: - Fix description of module parameter panthor: - Flush writes before mapping buffers vmwgfx: - Improve command validation - Improve ref counting - Fix cursor-plane support amdgpu: - Disallow P2P DMA for GC 12 DCC surfaces - ctx error handling fix - UserQ fixes - VRR fix - ISP fix - JPEG 5.0.1 fix amdkfd: - Save area check fix - Fix GPU mappings for APU after prefetch i915: - Fix PSR's pipe to vblank conversion - Disable Panel Replay on MST links xe: - New HW workarounds affecting PTL and WCL platforms * tag 'drm-fixes-2025-11-15' of https://gitlab.freedesktop.org/drm/kernel: drm/client: fix MODULE_PARM_DESC string for "active" drm/i915/dp_mst: Disable Panel Replay drm/amdkfd: Fix GPU mappings for APU after prefetch drm/amdkfd: relax checks for over allocation of save area drm/amdgpu/jpeg: Add parse_cs for JPEG5_0_1 drm/amd/amdgpu: Ensure isp_kernel_buffer_alloc() creates a new BO drm/amd/display: Allow VRR params change if unsynced with the stream drm/amdgpu: fix lock warning in amdgpu_userq_fence_driver_process drm/amdgpu: jump to the correct label on failure drm/amdgpu: disable peer-to-peer access for DCC-enabled GC12 VRAM surfaces drm/xe/xe3lpg: Extend Wa_15016589081 for xe3lpg drm/xe/xe3: Extend wa_14023061436 drm/xe/xe3: Add WA_14024681466 for Xe3_LPG drm/i915/psr: fix pipe to vblank conversion drm/panthor: Flush shmem writes before mapping buffers CPU-uncached drm/vmwgfx: Restore Guest-Backed only cursor plane support drm/vmwgfx: Use kref in vmw_bo_dirty drm/vmwgfx: Validate command header size against SVGA_CMD_MAX_DATASIZE
2025-11-14Merge tag 'mmc-v6.18-rc2' of ↵Linus Torvalds4-42/+22
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc Pull MMC fixes from Ulf Hansson: - dw_mmc-rockchip: Fix internal phase calculation - pxamci: Simplify and fix ->probe() error handling - sdhci-of-dwcmshc: Fix strbin signal delay - wmt-sdmmc: Fix compile test default * tag 'mmc-v6.18-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc: mmc: dw_mmc-rockchip: Fix wrong internal phase calculate mmc: pxamci: Simplify pxamci_probe() error handling using devm APIs mmc: sdhci-of-dwcmshc: Change DLL_STRBIN_TAPNUM_DEFAULT to 0x4 mmc: wmt-sdmmc: fix compile test default
2025-11-14Merge tag 'pmdomain-v6.18-rc2' of ↵Linus Torvalds3-17/+27
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm Pull pmdomain fixes from Ulf Hansson: - imx: Fix reference count leak in ->remove() - samsung: Rework legacy splash-screen handover workaround - samsung: Fix potential memleak during ->probe() - arm: Fix genpd leak on provider registration failure for scmi * tag 'pmdomain-v6.18-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm: pmdomain: imx: Fix reference count leak in imx_gpc_remove pmdomain: samsung: Rework legacy splash-screen handover workaround pmdomain: arm: scmi: Fix genpd leak on provider registration failure pmdomain: samsung: plug potential memleak during probe
2025-11-14Merge tag 'cxl-fixes-6.18-rc6' of ↵Linus Torvalds3-22/+28
git://git.kernel.org/pub/scm/linux/kernel/git/cxl/cxl Pull cxl fixes from Dave Jiang: - Fix incorrect device handle check for Generic Initiator - Fix offset calculation for extended linear cache poison injection - Fix lockdep warning for hmem_register_resource() * tag 'cxl-fixes-6.18-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/cxl/cxl: acpi/hmat: Fix lockdep warning for hmem_register_resource() cxl: Adjust offset calculation for poison injection acpi,srat: Fix incorrect device handle check for Generic Initiator
2025-11-14Merge tag 'reset-fixes-for-v6.18' of ↵Arnd Bergmann1-2/+2
https://git.pengutronix.de/git/pza/linux into arm/fixes Reset controller fixes for v6.18 * Fix incorrect EARC reset masks in the reset-imx8mp-audiomix driver, introduced in commit a83bc87cd30a. * tag 'reset-fixes-for-v6.18' of https://git.pengutronix.de/git/pza/linux: reset: imx8mp-audiomix: Fix bad mask values Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-11-14Merge tag 'memory-controller-drv-fixes-6.18' of ↵Arnd Bergmann1-2/+2
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl into arm/fixes Memory controller drivers - fixes for v6.18 Correct incorrect ID used for the memory controller client IDs in Tegra210 Memory Controller driver, introduced in v6.18-rc1. * tag 'memory-controller-drv-fixes-6.18' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl: memory: tegra210: Fix incorrect client ids Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-11-14Merge tag 'spi-fix-v6.18-rc5' of ↵Linus Torvalds3-5/+24
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi Pull spi fixes from Mark Brown: "A few standard fixes here, plus one more interesting one from Hans which addresses an issue where a move in when we requested GPIOs on ACPI systems caused us to stop doing pinmuxing and leave things floating that we'd really rather not have floating" * tag 'spi-fix-v6.18-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: spi: Add TODO comment about ACPI GPIO setup spi: xilinx: increase number of retries before declaring stall spi: imx: keep dma request disabled before dma transfer setup spi: Try to get ACPI GPIO IRQ earlier
2025-11-14Merge tag 'regulator-fix-v6.18-rc5' of ↵Linus Torvalds1-0/+1
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator Pull regulator fix from Mark Brown: "One simple fix for a GPIO descriptor leak in the probe error handling for the fixed regulator" * tag 'regulator-fix-v6.18-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: regulator: fixed: fix GPIO descriptor leak on register failure
2025-11-14Revert "drm/tegra: dsi: Clear enable register if powered by bootloader"Diogo Ivo1-9/+0
Commit b6bcbce33596 ("soc/tegra: pmc: Ensure power-domains are in a known state") was introduced so that all power domains get initialized to a known working state when booting and it does this by shutting them down (including asserting resets and disabling clocks) before registering each power domain with the genpd framework, leaving it to each driver to later on power its needed domains. This caused the Google Pixel C to hang when booting due to a workaround in the DSI driver introduced in commit b22fd0b9639e ("drm/tegra: dsi: Clear enable register if powered by bootloader") meant to handle the case where the bootloader enabled the DSI hardware module. The workaround relies on reading a hardware register to determine the current status and after b6bcbce33596 that now happens in a powered down state thus leading to the boot hang. Fix this by reverting b22fd0b9639e since currently we are guaranteed that the hardware will be fully reset by the time we start enabling the DSI module. Fixes: b6bcbce33596 ("soc/tegra: pmc: Ensure power-domains are in a known state") Cc: stable@vger.kernel.org Signed-off-by: Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patch.msgid.link/20251103-diogo-smaug_ec_typec-v1-1-be656ccda391@tecnico.ulisboa.pt
2025-11-14drm/tegra: Add call to put_pid()Prateek Agarwal1-2/+5
Add a call to put_pid() corresponding to get_task_pid(). host1x_memory_context_alloc() does not take ownership of the PID so we need to free it here to avoid leaking. Signed-off-by: Prateek Agarwal <praagarwal@nvidia.com> Fixes: e09db97889ec ("drm/tegra: Support context isolation") [mperttunen@nvidia.com: reword commit message] Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patch.msgid.link/20250919-host1x-put-pid-v1-1-19c2163dfa87@nvidia.com
2025-11-14drm/tegra: dc: Fix reference leak in tegra_dc_couple()Ma Ke1-0/+1
driver_find_device() calls get_device() to increment the reference count once a matching device is found, but there is no put_device() to balance the reference count. To avoid reference count leakage, add put_device() to decrease the reference count. Found by code review. Cc: stable@vger.kernel.org Fixes: a31500fe7055 ("drm/tegra: dc: Restore coupling of display controllers") Signed-off-by: Ma Ke <make24@iscas.ac.cn> Acked-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patch.msgid.link/20251022114720.24937-1-make24@iscas.ac.cn
2025-11-14Merge tag 'v6.18-p5' of ↵Linus Torvalds1-0/+2
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 Pull crypto fix from Herbert Xu: - Fix device reference leak in hisilicon * tag 'v6.18-p5' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: crypto: hisilicon/qm - Fix device reference leak in qm_get_qos_value
2025-11-14irqchip/riscv-intc: Add missing free() callback in riscv_intc_domain_opsNick Hu1-1/+2
The irq_domain_free_irqs() helper requires that the irq_domain_ops->free callback is implemented. Otherwise, the kernel reports the warning message "NULL pointer, cannot free irq" when irq_dispose_mapping() is invoked to release the per-HART local interrupts. Set irq_domain_ops->free to irq_domain_free_irqs_top() to cure that. Fixes: 832f15f42646 ("RISC-V: Treat IPIs as normal Linux IRQs") Signed-off-by: Nick Hu <nick.hu@sifive.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://patch.msgid.link/20251114-rv-intc-fix-v1-1-a3edd1c1a868@sifive.com
2025-11-14firewire: core: Initialize topology_map.lockVille Syrjälä1-0/+2
Lockdep barfs on the new uninitialized spinlock. Initialize it. protip: enable lockdep (CONFIG_PROVE_LOCKING=y) when doing locking changes firewire_ohci 0000:02:01.1: added OHCI v1.10 device as card 0, 4 IR + 4 IT contexts, quirks 0x11 INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. CPU: 0 UID: 0 PID: 1042 Comm: irq/17-firewire Not tainted 6.17.0-rc2-cl-bisect2-00026-g7d138cb269db #136 PREEMPT Hardware name: Dell Inc. Latitude E5400 /0D695C, BIOS A19 06/13/2013 Call Trace: <TASK> dump_stack_lvl+0x6d/0xa0 register_lock_class+0x783/0x790 ? find_held_lock+0x2b/0x80 ? __mod_timer+0x110/0x320 ? __mod_timer+0x110/0x320 __lock_acquire+0x405/0x2600 lock_acquire+0xca/0x2e0 ? fw_core_handle_bus_reset+0x888/0xca0 [firewire_core] ? fw_core_handle_bus_reset+0x878/0xca0 [firewire_core] ? fw_core_handle_bus_reset+0x878/0xca0 [firewire_core] _raw_spin_lock+0x2e/0x40 ? fw_core_handle_bus_reset+0x888/0xca0 [firewire_core] fw_core_handle_bus_reset+0x888/0xca0 [firewire_core] handle_selfid_complete_event+0x35c/0x7a0 [firewire_ohci] ? irq_thread+0x8d/0x280 irq_thread_fn+0x18/0x50 irq_thread+0x15a/0x280 ? irq_check_status_bit+0x100/0x100 ? lockdep_hardirqs_on+0x78/0x100 ? irq_finalize_oneshot.part.0+0xc0/0xc0 ? irq_forced_thread_fn+0x60/0x60 kthread+0x114/0x200 ? kthreads_online_cpu+0x110/0x110 ret_from_fork+0x158/0x1e0 ? kthreads_online_cpu+0x110/0x110 ret_from_fork_asm+0x11/0x20 </TASK> Reported-by: Erhard Furtner <erhard_f@mailbox.org> Fixes: 7d138cb269db ("firewire: core: use spin lock specific to topology map") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2025-11-14pwm: adp5585: Correct mismatched pwm chip infoLuke Wang1-2/+2
The register addresses of ADP5585 and ADP5589 are swapped. Fixes: 75024f97e82e ("pwm: adp5585: add support for adp5589") Signed-off-by: Luke Wang <ziniu.wang_1@nxp.com> Acked-by: Nuno Sá <nuno.sa@analog.com> Tested-by: Liu Ying <victor.liu@nxp.com> # ADP5585 PWM Link: https://patch.msgid.link/20251114065308.2074893-1-ziniu.wang_1@nxp.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-11-14Merge tag 'drm-xe-fixes-2025-11-13' of ↵Dave Airlie2-0/+12
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes Driver Changes: - New HW workarounds affecting PTL and WCL platforms (Nitin Gote, Tangudu Tilak Tirumalesh) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patch.msgid.link/ay2qztgonodwson6tuzcv5napjmqbgwzv27so4ybfola34guux@xgufrrmbzyws
2025-11-14Merge tag 'drm-intel-fixes-2025-11-13' of ↵Dave Airlie1-1/+6
https://gitlab.freedesktop.org/drm/i915/kernel into drm-fixes - Fix PSR's pipe to vblank conversion (Jani) - Disable Panel Replay on MST links (Imre) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/aRXdQnitzyFcokhF@intel.com
2025-11-14Merge tag 'drm-misc-fixes-2025-11-13' of ↵Dave Airlie6-10/+46
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes Short summary of fixes pull: client: - Fix description of module parameter panthor: - Flush writes before mapping buffers vmwgfx: - Improve command validation - Improve ref counting - Fix cursor-plane support Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20251113132317.GA451885@linux.fritz.box
2025-11-13mlxsw: spectrum: Fix memory leak in mlxsw_sp_flower_stats()Zilin Guan1-2/+4
The function mlxsw_sp_flower_stats() calls mlxsw_sp_acl_ruleset_get() to obtain a ruleset reference. If the subsequent call to mlxsw_sp_acl_rule_lookup() fails to find a rule, the function returns an error without releasing the ruleset reference, causing a memory leak. Fix this by using a goto to the existing error handling label, which calls mlxsw_sp_acl_ruleset_put() to properly release the reference. Fixes: 7c1b8eb175b69 ("mlxsw: spectrum: Add support for TC flower offload statistics") Signed-off-by: Zilin Guan <zilin@seu.edu.cn> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20251112052114.1591695-1-zilin@seu.edu.cn Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-13Merge tag 'hwmon-for-v6.18-rc6' of ↵Linus Torvalds1-28/+26
git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging Pull hwmon fixes from Guenter Roeck: - gpd-fan: Fix compilation error for non-ACPI builds, and initialize EC when loading the driver * tag 'hwmon-for-v6.18-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: hwmon: (gpd-fan) initialize EC on driver load for Win 4 hwmon: (gpd-fan) Fix compilation error in non-ACPI builds
2025-11-13Merge tag 'pm-6.18-rc6' of ↵Linus Torvalds1-5/+4
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull power management fixes from Rafael Wysocki: "These fix issues related to the handling of compressed hibernation images and a recent intel_pstate driver regression: - Fix issues related to using inadequate data types and incorrect use of atomic variables in the compressed hibernation images handling code that were introduced during the 6.9 development cycle (Mario Limonciello) - Move a X86_FEATURE_IDA check from turbo_is_disabled() to the places where a new value for MSR_IA32_PERF_CTL is computed in intel_pstate to address a regression preventing users from enabling turbo frequencies post-boot (Srinivas Pandruvada)" * tag 'pm-6.18-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: cpufreq: intel_pstate: Check IDA only before MSR_IA32_PERF_CTL writes PM: hibernate: Fix style issues in save_compressed_image() PM: hibernate: Use atomic64_t for compressed_size variable PM: hibernate: Emit an error when image writing fails
2025-11-13Merge tag 'acpi-6.18-rc6' of ↵Linus Torvalds2-13/+36
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull ACPI fixes from Rafael Wysocki: "These fix issues in the ACPI CPPC library and in the recently added parser for the ACPI MRRM table: - Limit some checks in the ACPI CPPC library to online CPUs to avoid accessing uninitialized per-CPU variables when some CPUs are offline to start with, like during boot with 'nosmt=force' (Gautham Shenoy) - Rework add_boot_memory_ranges() in the ACPI MRRM table parser to fix memory leaks and improve error handling (Kaushlendra Kumar)" * tag 'acpi-6.18-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI: MRRM: Fix memory leaks and improve error handling ACPI: CPPC: Limit perf ctrs in PCC check only to online CPUs ACPI: CPPC: Perform fast check switch only for online CPUs ACPI: CPPC: Check _CPC validity for only the online CPUs ACPI: CPPC: Detect preferred core availability on online CPUs
2025-11-13Merge branches 'acpi-cppc' and 'acpi-tables'Rafael J. Wysocki2-13/+36
Merge ACPI CPPC library fixes and an ACPI MRRM table parser fix for 6.18-rc6. * acpi-cppc: ACPI: CPPC: Limit perf ctrs in PCC check only to online CPUs ACPI: CPPC: Perform fast check switch only for online CPUs ACPI: CPPC: Check _CPC validity for only the online CPUs ACPI: CPPC: Detect preferred core availability on online CPUs * acpi-tables: ACPI: MRRM: Fix memory leaks and improve error handling
2025-11-13Merge tag 'net-6.18-rc6' of ↵Linus Torvalds25-136/+255
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from Paolo Abeni: "Including fixes from Bluetooth and Wireless. No known outstanding regressions. Current release - regressions: - eth: - bonding: fix mii_status when slave is down - mlx5e: fix missing error assignment in mlx5e_xfrm_add_state() Previous releases - regressions: - sched: limit try_bulk_dequeue_skb() batches - ipv4: route: prevent rt_bind_exception() from rebinding stale fnhe - af_unix: initialise scc_index in unix_add_edge() - netpoll: fix incorrect refcount handling causing incorrect cleanup - bluetooth: don't hold spin lock over sleeping functions - hsr: Fix supervision frame sending on HSRv0 - sctp: prevent possible shift out-of-bounds - tipc: fix use-after-free in tipc_mon_reinit_self(). - dsa: tag_brcm: do not mark link local traffic as offloaded - eth: virtio-net: fix incorrect flags recording in big mode Previous releases - always broken: - sched: initialize struct tc_ife to fix kernel-infoleak - wifi: - mac80211: reject address change while connecting - iwlwifi: avoid toggling links due to wrong element use - bluetooth: cancel mesh send timer when hdev removed - strparser: fix signed/unsigned mismatch bug - handshake: fix memory leak in tls_handshake_accept() Misc: - selftests: mptcp: fix some flaky tests" * tag 'net-6.18-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (60 commits) hsr: Follow standard for HSRv0 supervision frames hsr: Fix supervision frame sending on HSRv0 virtio-net: fix incorrect flags recording in big mode ipv4: route: Prevent rt_bind_exception() from rebinding stale fnhe 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 net_sched: limit try_bulk_dequeue_skb() batches selftests: mptcp: join: properly kill background tasks selftests: mptcp: connect: trunc: read all recv data selftests: mptcp: join: userspace: longer transfer selftests: mptcp: join: endpoints: longer transfer selftests: mptcp: join: rm: set backup flag selftests: mptcp: connect: fix fallback note due to OoO ethtool: fix incorrect kernel-doc style comment in ethtool.h mlx5: Fix default values in create CQ Bluetooth: btrtl: Avoid loading the config file on security chips net/mlx5e: Fix potentially misleading debug message net/mlx5e: Fix wraparound in rate limiting for values above 255 Gbps net/mlx5e: Fix maxrate wraparound in threshold between units ...
2025-11-13drm/client: fix MODULE_PARM_DESC string for "active"Randy Dunlap1-2/+2
The MODULE_PARM_DESC string for the "active" parameter is missing a space and has an extraneous trailing ']' character. Correct these. Before patch: $ modinfo -p ./drm_client_lib.ko active:Choose which drm client to start, default isfbdev] (string) After patch: $ modinfo -p ./drm_client_lib.ko active:Choose which drm client to start, default is fbdev (string) Fixes: f7b42442c4ac ("drm/log: Introduce a new boot logger to draw the kmsg on the screen") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20251112010920.2355712-1-rdunlap@infradead.org
2025-11-13PCI/ASPM: Avoid L0s and L1 on Hi1105 [19e5:1105] Wi-FiShawn Lin1-0/+1
This Wi-Fi advertises the L0s and L1 capabilities but actually it doesn't support them. This is confirmed by HiSilicon team in actual productization. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/1762916319-139532-1-git-send-email-shawn.lin@rock-chips.com
2025-11-13virtio-net: fix incorrect flags recording in big modeXuan Zhuo1-5/+11
The purpose of commit 703eec1b2422 ("virtio_net: fixing XDP for fully checksummed packets handling") is to record the flags in advance, as their value may be overwritten in the XDP case. However, the flags recorded under big mode are incorrect, because in big mode, the passed buf does not point to the rx buffer, but rather to the page of the submitted buffer. This commit fixes this issue. For the small mode, the commit c11a49d58ad2 ("virtio_net: Fix mismatched buf address when unmapping for small packets") fixed it. Tested-by: Alyssa Ross <hi@alyssa.is> Fixes: 703eec1b2422 ("virtio_net: fixing XDP for fully checksummed packets handling") Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com> Acked-by: Jason Wang <jasowang@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Link: https://patch.msgid.link/20251111090828.23186-1-xuanzhuo@linux.alibaba.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-11-12PCI/ASPM: Avoid L0s and L1 on PA Semi [1959:a002] Root PortsBjorn Helgaas1-0/+1
Christian reported that f3ac2ff14834 ("PCI/ASPM: Enable all ClockPM and ASPM states for devicetree platforms") broke booting on the A-EON AmigaOne X1000. Override the L0s and L1 Support advertised in Link Capabilities by the X1000 Root Ports ([1959:a002]) so we don't try to enable those states. Fixes: f3ac2ff14834 ("PCI/ASPM: Enable all ClockPM and ASPM states for devicetree platforms") Fixes: df5192d9bb0e ("PCI/ASPM: Enable only L0s and L1 for devicetree platforms") Reported-by: Christian Zigotzky <chzigotzky@xenosoft.de> Link: https://lore.kernel.org/r/a41d2ca1-fcd9-c416-b111-a958e92e94bf@xenosoft.de Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2025-11-12PCI/ASPM: Avoid L0s and L1 on Freescale [1957:0451] Root PortsBjorn Helgaas1-0/+1
Christian reported that f3ac2ff14834 ("PCI/ASPM: Enable all ClockPM and ASPM states for devicetree platforms") broke booting on the A-EON X5000. Override the L0s and L1 Support advertised in Link Capabilities by the X5000 Root Ports ([1957:0451]) so we don't try to enable those states. Fixes: f3ac2ff14834 ("PCI/ASPM: Enable all ClockPM and ASPM states for devicetree platforms") Fixes: df5192d9bb0e ("PCI/ASPM: Enable only L0s and L1 for devicetree platforms") Reported-by: Christian Zigotzky <chzigotzky@xenosoft.de> Link: https://lore.kernel.org/r/db5c95a1-cf3e-46f9-8045-a1b04908051a@xenosoft.de Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Shawn Lin <shawn.lin@rock-chips.com> Reviewed-by: Lukas Wunner <lukas@wunner.de> Link: https://patch.msgid.link/20251110222929.2140564-5-helgaas@kernel.org
2025-11-12PCI/ASPM: Convert quirks to override advertised link statesBjorn Helgaas1-20/+19
Existing quirks to disable ASPM L0s and L1 use pci_disable_link_state(), which disables ASPM states and prevents their use in the future. But since they are FINAL quirks, they happen after ASPM has already been enabled. Here's a typical call path: pci_host_probe pci_scan_root_bus_bridge pci_scan_child_bus pci_scan_slot pci_scan_single_device pci_device_add pci_fixup_device(pci_fixup_header) # HEADER quirks pcie_aspm_init_link_state pcie_config_aspm_path pcie_config_aspm_link pcie_config_aspm_dev # ASPM may be enabled pci_bus_add_devices pci_bus_add_devices pci_fixup_device(pci_fixup_final) # FINAL quirks quirk_disable_aspm_l0s pci_disable_link_state(dev, PCIE_LINK_STATE_L0S) Sometimes enabling ASPM can make the link non-functional, so if we know ASPM is broken on a device, we shouldn't enable it at all, even temporarily. Convert the existing quirks to use pcie_aspm_remove_cap() instead, which overrides the ASPM Support advertised in PCIe Link Capabilities, and make them HEADER quirks so they run before pcie_aspm_init_link_state() has a chance to enable ASPM. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Shawn Lin <shawn.lin@rock-chips.com> Reviewed-by: Lukas Wunner <lukas@wunner.de> Link: https://patch.msgid.link/20251110222929.2140564-4-helgaas@kernel.org
2025-11-12PCI/ASPM: Add pcie_aspm_remove_cap() to override advertised link statesBjorn Helgaas2-0/+15
Add pcie_aspm_remove_cap(). A quirk can use this to prevent use of ASPM L0s or L1 link states, even if the device advertised support for them. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Shawn Lin <shawn.lin@rock-chips.com> Reviewed-by: Lukas Wunner <lukas@wunner.de> Link: https://patch.msgid.link/20251110222929.2140564-3-helgaas@kernel.org
2025-11-12PCI/ASPM: Cache L0s/L1 Supported so advertised link states can be overriddenBjorn Helgaas2-8/+11
Defective devices sometimes advertise support for ASPM L0s or L1 states even if they don't work correctly. Cache the L0s Supported and L1 Supported bits early in enumeration so HEADER quirks can override the ASPM states advertised in Link Capabilities before pcie_aspm_cap_init() enables ASPM. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Shawn Lin <shawn.lin@rock-chips.com> Reviewed-by: Lukas Wunner <lukas@wunner.de> Link: https://patch.msgid.link/20251110222929.2140564-2-helgaas@kernel.org
2025-11-12acpi/hmat: Fix lockdep warning for hmem_register_resource()Dave Jiang1-21/+25
The following lockdep splat was observed while kernel auto-online a CXL memory region: ====================================================== WARNING: possible circular locking dependency detected 6.17.0djtest+ #53 Tainted: G W ------------------------------------------------------ systemd-udevd/3334 is trying to acquire lock: ffffffff90346188 (hmem_resource_lock){+.+.}-{4:4}, at: hmem_register_resource+0x31/0x50 but task is already holding lock: ffffffff90338890 ((node_chain).rwsem){++++}-{4:4}, at: blocking_notifier_call_chain+0x2e/0x70 which lock already depends on the new lock. [..] Chain exists of: hmem_resource_lock --> mem_hotplug_lock --> (node_chain).rwsem Possible unsafe locking scenario: CPU0 CPU1 ---- ---- rlock((node_chain).rwsem); lock(mem_hotplug_lock); lock((node_chain).rwsem); lock(hmem_resource_lock); The lock ordering can cause potential deadlock. There are instances where hmem_resource_lock is taken after (node_chain).rwsem, and vice versa. Split out the target update section of hmat_register_target() so that hmat_callback() only envokes that section instead of attempt to register hmem devices that it does not need to. [ dj: Fix up comment to be closer to 80cols. (Jonathan) ] Fixes: cf8741ac57ed ("ACPI: NUMA: HMAT: Register "soft reserved" memory as an "hmem" device") Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Tested-by: Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com> Reviewed-by: Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com> Reviewed-by: Dan Williams <dan.j.williams@intel.com> Link: https://patch.msgid.link/20251105235115.85062-3-dave.jiang@intel.com Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2025-11-12hwmon: (gpd-fan) initialize EC on driver load for Win 4Cryolitia PukNgae1-27/+25
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 Menon1-1/+1
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 'wireless-2025-11-12' of ↵Jakub Kicinski7-35/+99
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-12cpufreq: intel_pstate: Check IDA only before MSR_IA32_PERF_CTL writesSrinivas Pandruvada1-5/+4
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/i915/dp_mst: Disable Panel ReplayImre Deak1-0/+4
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-12pinctrl: qcom: msm: Fix deadlock in pinmux configurationPraveen Talari1-1/+1
Replace disable_irq() with disable_irq_nosync() in msm_pinmux_set_mux() to prevent deadlock when wakeup IRQ is triggered on the same GPIO being reconfigured. The issue occurs when a wakeup IRQ is triggered on a GPIO and the IRQ handler attempts to reconfigure the same GPIO's pinmux. In this scenario, msm_pinmux_set_mux() calls disable_irq() which waits for the currently running IRQ handler to complete, creating a circular dependency that results in deadlock. Using disable_irq_nosync() avoids waiting for the IRQ handler to complete, preventing the deadlock condition while still properly disabling the interrupt during pinmux reconfiguration. Suggested-by: Prasad Sodagudi <prasad.sodagudi@oss.qualcomm.com> Signed-off-by: Praveen Talari <praveen.talari@oss.qualcomm.com> Reviewed-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2025-11-12platform/x86: hp-wmi: Add Omen MAX 16-ah0xx fan support and thermal profileMarcos Vega1-0/+1
New HP Omen laptops follow the same WMI thermal profile as Victus 16-r1000 and 16-s1000. Add DMI board 8D41 to victus_s_thermal_profile_boards. Signed-off-by: Marcos Vega <marcosmola2@gmail.com> Link: https://patch.msgid.link/20251108114739.9255-3-marcosmola2@gmail.com [ij: changelog taken partially from v1] Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-11-12wifi: iwlwifi: mld: always take beacon ies in link gradingMiri Korenblit1-6/+1
One of the factors of a link's grade is the channel load, which is calculated from the AP's bss load element. The current code takes this element from the beacon for an active link, and from bss->ies for an inactive link. bss->ies is set to either the beacon's ies or to the probe response ones, with preference to the probe response (meaning that if there was even one probe response, the ies of it will be stored in bss->ies and won't be overiden by the beacon ies). The probe response can be very old, i.e. from the connection time, where a beacon is updated before each link selection (which is triggered only after a passive scan). In such case, the bss load element in the probe response will not include the channel load caused by the STA, where the beacon will. This will cause the inactive link to always have a lower channel load, and therefore an higher grade than the active link's one. This causes repeated link switches, causing the throughput to drop. Fix this by always taking the ies from the beacon, as those are for sure new. Fixes: d1e879ec600f ("wifi: iwlwifi: add iwlmld sub-driver") Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20251110145652.b493dbb1853a.I058ba7309c84159f640cc9682d1bda56dd56a536@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2025-11-12wifi: iwlwifi: mvm: fix beacon template/fixed rateJohannes Berg2-13/+12
During the development of the rate changes, I evidently made some changes that shouldn't have been there; beacon templates with rate_n_flags are only in old versions, so no changes to them should have been necessary, and evidently broke on some devices. This also would have broken fixed (injection) rates, it would seem. Restore the old handling of this. Fixes: dabc88cb3b78 ("wifi: iwlwifi: handle v3 rates") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220558 Reviewed-by: Benjamin Berg <benjamin.berg@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Link: https://patch.msgid.link/20251008112044.3bb8ea849d8d.I90f4d2b2c1f62eaedaf304a61d2ab9e50c491c2d@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2025-11-12wifi: iwlwifi: fix aux ROC time event iterator usageJunjie Cao1-7/+7
The list_for_each_entry() iterator must not be used outside the loop. Even though we break and check for NULL, doing so still violates kernel iteration rules and triggers Coccinelle's use_after_iter.cocci warning. Cache the matched entry in aux_roc_te and use it consistently after the loop. This follows iterator best practices, resolves the warning, and makes the code more maintainable. Signed-off-by: Junjie Cao <junjie.cao@intel.com> Link: https://patch.msgid.link/20251016014919.383565-1-junjie.cao@intel.com Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2025-11-11drm/amdkfd: Fix GPU mappings for APU after prefetchHarish Kasiviswanathan1-0/+2
Fix the following corner case:- Consider a 2M huge page SVM allocation, followed by prefetch call for the first 4K page. The whole range is initially mapped with single PTE. After the prefetch, this range gets split to first page + rest of the pages. Currently, the first page mapping is not updated on MI300A (APU) since page hasn't migrated. However, after range split PTE mapping it not valid. Fix this by forcing page table update for the whole range when prefetch is called. Calling prefetch on APU doesn't improve performance. If all it deteriotes. However, functionality has to be supported. v2: Use apu_prefer_gtt as this issue doesn't apply to APUs with carveout VRAM v3: Simplify by setting the flag for all ASICs as it doesn't affect dGPU v4: Remove v2 and v3 changes. Force update_mapping when range is split at a size that is not aligned to prange granularity Suggested-by: Philip Yang <Philip.Yang@amd.com> Signed-off-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> Reviewed-by: Philip Yang<Philip.Yang@amd.com> Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 076470b9f6f8d9c7c8ca73a9f054942a686f9ba7)
2025-11-11drm/amdkfd: relax checks for over allocation of save areaJonathan Kim1-6/+6
Over allocation of save area is not fatal, only under allocation is. ROCm has various components that independently claim authority over save area size. Unless KFD decides to claim single authority, relax size checks. Signed-off-by: Jonathan Kim <jonathan.kim@amd.com> Reviewed-by: Philip Yang <philip.yang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 15bd4958fe38e763bc17b607ba55155254a01f55) Cc: stable@vger.kernel.org
2025-11-11drm/amdgpu/jpeg: Add parse_cs for JPEG5_0_1Sathishkumar S1-0/+1
enable parse_cs callback for JPEG5_0_1. Signed-off-by: Sathishkumar S <sathishkumar.sundararaju@amd.com> Reviewed-by: Leo Liu <leo.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 547985579932c1de13f57f8bcf62cd9361b9d3d3) Cc: stable@vger.kernel.org
2025-11-11drm/amd/amdgpu: Ensure isp_kernel_buffer_alloc() creates a new BOSultan Alsawaf1-0/+2
When the BO pointer provided to amdgpu_bo_create_kernel() points to non-NULL, amdgpu_bo_create_kernel() takes it as a hint to pin that address rather than allocate a new BO. This functionality is never desired for allocating ISP buffers. A new BO should always be created when isp_kernel_buffer_alloc() is called, per the description for isp_kernel_buffer_alloc(). Ensure this by zeroing *bo right before the amdgpu_bo_create_kernel() call. Fixes: 55d42f616976 ("drm/amd/amdgpu: Add helper functions for isp buffers") Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Reviewed-by: Pratap Nirujogi <pratap.nirujogi@amd.com> Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 73c8c29baac7f0c7e703d92eba009008cbb5228e)
2025-11-11drm/amd/display: Allow VRR params change if unsynced with the streamIvan Lipski1-0/+11
[Why] When changing resolution (e.g., 4K → FHD) in mirror/clone mode with certain monitors, the monitor blanks and loses connection due to an early exit in vrr_settings_require_update(). The function only checks if VRR state, fixed refresh target, or min/max refresh rate range has changed. During mode changes, if the calculated min/max refresh values remain the same even though the stream's v_total changed, the function returns early without updating vrr_params.adjust.v_total_min/max, leaving the monitor's VRR timing parameters unsynced with the new mode, causing it to blank out. [How] Explicitly adjust VRR parameters to the stream's nominal v_total when VRR is supported, but inactive. Fixes: 6d31602a9f57 ("drm/amd/display: more liberal vmin/vmax update for freesync") Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Ivan Lipski <ivan.lipski@amd.com> Signed-off-by: Fangzhi Zuo <jerry.zuo@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 607df8248a011524211ee34850345305a1913f9e)
2025-11-11drm/amdgpu: fix lock warning in amdgpu_userq_fence_driver_processJesse.Zhang1-2/+3
Fix a potential deadlock caused by inconsistent spinlock usage between interrupt and process contexts in the userq fence driver. The issue occurs when amdgpu_userq_fence_driver_process() is called from both: - Interrupt context: gfx_v11_0_eop_irq() -> amdgpu_userq_fence_driver_process() - Process context: amdgpu_eviction_fence_suspend_worker() -> amdgpu_userq_fence_driver_force_completion() -> amdgpu_userq_fence_driver_process() In interrupt context, the spinlock was acquired without disabling interrupts, leaving it in {IN-HARDIRQ-W} state. When the same lock is acquired in process context, the kernel detects inconsistent locking since the process context acquisition would enable interrupts while holding a lock previously acquired in interrupt context. Kernel log shows: [ 4039.310790] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage. [ 4039.310804] kworker/7:2/409 [HC0[0]:SC0[0]:HE1:SE1] takes: [ 4039.310818] ffff9284e1bed000 (&fence_drv->fence_list_lock){?...}-{3:3}, [ 4039.310993] {IN-HARDIRQ-W} state was registered at: [ 4039.311004] lock_acquire+0xc6/0x300 [ 4039.311018] _raw_spin_lock+0x39/0x80 [ 4039.311031] amdgpu_userq_fence_driver_process.part.0+0x30/0x180 [amdgpu] [ 4039.311146] amdgpu_userq_fence_driver_process+0x17/0x30 [amdgpu] [ 4039.311257] gfx_v11_0_eop_irq+0x132/0x170 [amdgpu] Fix by using spin_lock_irqsave()/spin_unlock_irqrestore() to properly manage interrupt state regardless of calling context. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit ded3ad780cf97a04927773c4600823b84f7f3cc2) Cc: stable@vger.kernel.org