summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2026-03-04iio: adc: ad9467: remove unused output_mode fieldAntoniu Miclaus1-1/+0
Remove unused output_mode field from ad9467_state struct. The field is declared but never accessed in the driver. Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com> Reviewed-by: Tomas Melin <tomas.melin@vaisala.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2026-03-04iio: adc: ad7793: remove unused int_vref_mv fieldAntoniu Miclaus1-1/+0
Remove unused int_vref_mv field from ad7793_state struct. The field is declared but never accessed in the driver. Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2026-03-04iio: adc: ad7768-1: remove unused mclk_div fieldAntoniu Miclaus1-1/+0
Remove unused mclk_div field from ad7768_state struct. The field is declared but never accessed in the driver. Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2026-03-04iio: adc: ad4080: remove unused dec_rate fieldAntoniu Miclaus1-1/+0
Remove unused dec_rate field from ad4080_state struct. The driver reads/writes decimation rate directly from hardware registers via ad4080_get_dec_rate() and ad4080_set_dec_rate() functions. Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2026-03-04iio: sca3000: manage device registration with devm helperHarshit Mogalapalli1-14/+1
Convert the iio registration to use devm_* helpers so the probe no longer needs a separate cleanup path and remove callback can also drop the unregister. After this there is no need for having a remove callback, so remote it. No functional change intended. Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com> Reviewed-by: David Lechner <dlechner@baylibe.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2026-03-04iio: sca3000: stop interrupts via devm_add_action_or_reset()Harshit Mogalapalli1-5/+7
Used devm_add_action_or_reset() for shutting down the interrupts. Make sca3000_stop_all_interrupts() return void now that it always hooks into devm cleanup. No functional change intended. Suggested-by: David Lechner <dlechner@baylibre.com> Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2026-03-04iio: sca3000: use guard(mutex) to simplify return pathsHarshit Mogalapalli1-4/+5
Switch sca3000_stop_all_interrupts() to use guard(mutex) to simplify the error paths without needing a goto. Suggested-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2026-03-04iio: sca3000: make stop_all_interrupts() return voidHarshit Mogalapalli1-7/+6
sca3000_stop_all_interrupts() is called only from the driver remove path and its return value is discarded, so convert the helper to return void. No functional change. Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2026-03-04iio: sca3000: Move sca3000_stop_all_interrupts() above sca3000_probe()Harshit Mogalapalli1-18/+18
Move sca3000_stop_all_interrupts() above sca3000_probe() without altering its logic so the next set of patches are easier to review. No functional change. Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2026-03-04iio: sca3000: switch IRQ handling to devm helpersHarshit Mogalapalli1-17/+8
Convert the threaded IRQ registration to devm_request_threaded_irq() so that the probe and remove paths can drop manual freeing of irqs. No functionality change. Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com> Reviewed-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2026-03-04iio: sca3000: reuse device pointer for devm helpersHarshit Mogalapalli1-4/+4
Cache struct device *dev and feed it to the devm helpers to simplify the probe function. No functional changes. Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2026-03-04iio: imu: inv_icm42600: Convert to uXX and sXX integer typesAndy Shevchenko1-1/+1
The driver has a some use of intXX_t and uintXX_t types which is not the pattern we use in the IIO subsystem. Switch the driver to use kernel internal types for that. No functional changes. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2026-03-04iio: dac: ad5360: converting to guard(mutex)Menderes Sabaz1-20/+9
Converting mutex_lock and mutex_unlock to guard(mutex) Signed-off-by: Menderes Sabaz <sabazmenderes@gmail.com> Reviewed-by: David Lechner <dlechner@baylibre.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2026-03-04iio: light: apds9306: remove redundant explicit pointer castSAJJA EASWAR SAI1-1/+1
C allows implicit conversion from void * to struct apds9306_data *, so the explicit cast on 'ptr' is unnecessary. Removing it improves readability. Signed-off-by: SAJJA EASWAR SAI <eshwarsajja20@gmail.com> Acked-by: Subhajit Ghosh <subhajit.ghosh@tweaklogic.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2026-03-04iio: pressure: hsc030pa: Improve i2c_transfer return value handlingAntoniu Miclaus1-1/+6
The i2c_transfer() function returns the number of messages successfully transferred. The function sends 1 message but checks for ret == 2, which can never be true. In practice this has no impact since the caller checks ret < 0, and the erroneous return value of 1 is not treated as an error. Improve the return value handling to properly distinguish between I2C errors and unexpected transfer counts. Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com> Tested-by: Petre Rodan <petre.rodan@subdimension.ro> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2026-03-04iio: frequency: admv4420: return proper error code from ↵Antoniu Miclaus1-1/+1
admv4420_calc_parameters() Return -EINVAL instead of -1 when no valid PLL parameters solution is found. Using standard kernel error codes ensures consistency and proper error propagation through the call chain. Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2026-03-04igc: Fix trigger of incorrect irq in igc_xsk_wakeup functionVivek Behera2-11/+26
This patch addresses the issue where the igc_xsk_wakeup function was triggering an incorrect IRQ for tx-0 when the i226 is configured with only 2 combined queues or in an environment with 2 active CPU cores. This prevented XDP Zero-copy send functionality in such split IRQ configurations. The fix implements the correct logic for extracting q_vectors saved during rx and tx ring allocation and utilizes flags provided by the ndo_xsk_wakeup API to trigger the appropriate IRQ. Fixes: fc9df2a0b520 ("igc: Enable RX via AF_XDP zero-copy") Fixes: 15fd021bc427 ("igc: Add Tx hardware timestamp request for AF_XDP zero-copy packet") Signed-off-by: Vivek Behera <vivek.behera@siemens.com> Reviewed-by: Jacob Keller <jacob.keller@intel.com> Reviewed-by: Aleksandr loktinov <aleksandr.loktionov@intel.com> Reviewed-by: Piotr Kwapulinski <piotr.kwapulinski@intel.com> Reviewed-by: Song Yoong Siang <yoong.siang.song@intel.com> Tested-by: Avigail Dahan <avigailx.dahan@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-03-04igb: Fix trigger of incorrect irq in igb_xsk_wakeupVivek Behera1-8/+30
The current implementation in the igb_xsk_wakeup expects the Rx and Tx queues to share the same irq. This would lead to triggering of incorrect irq in split irq configuration. This patch addresses this issue which could impact environments with 2 active cpu cores or when the number of queues is reduced to 2 or less cat /proc/interrupts | grep eno2 167: 0 0 0 0 IR-PCI-MSIX-0000:08:00.0 0-edge eno2 168: 0 0 0 0 IR-PCI-MSIX-0000:08:00.0 1-edge eno2-rx-0 169: 0 0 0 0 IR-PCI-MSIX-0000:08:00.0 2-edge eno2-rx-1 170: 0 0 0 0 IR-PCI-MSIX-0000:08:00.0 3-edge eno2-tx-0 171: 0 0 0 0 IR-PCI-MSIX-0000:08:00.0 4-edge eno2-tx-1 Furthermore it uses the flags input argument to trigger either rx, tx or both rx and tx irqs as specified in the ndo_xsk_wakeup api documentation Fixes: 80f6ccf9f116 ("igb: Introduce XSK data structures and helpers") Signed-off-by: Vivek Behera <vivek.behera@siemens.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Suggested-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Acked-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Tested-by: Saritha Sanigani <sarithax.sanigani@intel.com> (A Contingent Worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-03-04iavf: fix netdev->max_mtu to respect actual hardware limitKohei Enju1-1/+16
iavf sets LIBIE_MAX_MTU as netdev->max_mtu, ignoring vf_res->max_mtu from PF [1]. This allows setting an MTU beyond the actual hardware limit, causing TX queue timeouts [2]. Set correct netdev->max_mtu using vf_res->max_mtu from the PF. Note that currently PF drivers such as ice/i40e set the frame size in vf_res->max_mtu, not MTU. Convert vf_res->max_mtu to MTU before setting netdev->max_mtu. [1] # ip -j -d link show $DEV | jq '.[0].max_mtu' 16356 [2] iavf 0000:00:05.0 enp0s5: NETDEV WATCHDOG: CPU: 1: transmit queue 0 timed out 5692 ms iavf 0000:00:05.0 enp0s5: NIC Link is Up Speed is 10 Gbps Full Duplex iavf 0000:00:05.0 enp0s5: NETDEV WATCHDOG: CPU: 6: transmit queue 3 timed out 5312 ms iavf 0000:00:05.0 enp0s5: NIC Link is Up Speed is 10 Gbps Full Duplex ... Fixes: 5fa4caff59f2 ("iavf: switch to Page Pool") Signed-off-by: Kohei Enju <kohei@enjuk.jp> Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Rafal Romanowski <rafal.romanowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-03-04libie: don't unroll if fwlog isn't supportedMichal Swiatkowski1-0/+4
The libie_fwlog_deinit() function can be called during driver unload even when firmware logging was never properly initialized. This led to call trace: [ 148.576156] Oops: Oops: 0000 [#1] SMP NOPTI [ 148.576167] CPU: 80 UID: 0 PID: 12843 Comm: rmmod Kdump: loaded Not tainted 6.17.0-rc7next-queue-3oct-01915-g06d79d51cf51 #1 PREEMPT(full) [ 148.576177] Hardware name: HPE ProLiant DL385 Gen10 Plus/ProLiant DL385 Gen10 Plus, BIOS A42 07/18/2020 [ 148.576182] RIP: 0010:__dev_printk+0x16/0x70 [ 148.576196] Code: 1f 44 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 41 55 41 54 49 89 d4 55 48 89 fd 53 48 85 f6 74 3c <4c> 8b 6e 50 48 89 f3 4d 85 ed 75 03 4c 8b 2e 48 89 df e8 f3 27 98 [ 148.576204] RSP: 0018:ffffd2fd7ea17a48 EFLAGS: 00010202 [ 148.576211] RAX: ffffd2fd7ea17aa0 RBX: ffff8eb288ae2000 RCX: 0000000000000000 [ 148.576217] RDX: ffffd2fd7ea17a70 RSI: 00000000000000c8 RDI: ffffffffb68d3d88 [ 148.576222] RBP: ffffffffb68d3d88 R08: 0000000000000000 R09: 0000000000000000 [ 148.576227] R10: 00000000000000c8 R11: ffff8eb2b1a49400 R12: ffffd2fd7ea17a70 [ 148.576231] R13: ffff8eb3141fb000 R14: ffffffffc1215b48 R15: ffffffffc1215bd8 [ 148.576236] FS: 00007f5666ba6740(0000) GS:ffff8eb2472b9000(0000) knlGS:0000000000000000 [ 148.576242] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 148.576247] CR2: 0000000000000118 CR3: 000000011ad17000 CR4: 0000000000350ef0 [ 148.576252] Call Trace: [ 148.576258] <TASK> [ 148.576269] _dev_warn+0x7c/0x96 [ 148.576290] libie_fwlog_deinit+0x112/0x117 [libie_fwlog] [ 148.576303] ixgbe_remove+0x63/0x290 [ixgbe] [ 148.576342] pci_device_remove+0x42/0xb0 [ 148.576354] device_release_driver_internal+0x19c/0x200 [ 148.576365] driver_detach+0x48/0x90 [ 148.576372] bus_remove_driver+0x6d/0xf0 [ 148.576383] pci_unregister_driver+0x2e/0xb0 [ 148.576393] ixgbe_exit_module+0x1c/0xd50 [ixgbe] [ 148.576430] __do_sys_delete_module.isra.0+0x1bc/0x2e0 [ 148.576446] do_syscall_64+0x7f/0x980 It can be reproduced by trying to unload ixgbe driver in recovery mode. Fix that by checking if fwlog is supported before doing unroll. Fixes: 641585bc978e ("ixgbe: fwlog support for e610") Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Rinitha S <sx.rinitha@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-03-04ice: Fix memory leak in ice_set_ringparam()Zilin Guan1-2/+9
In ice_set_ringparam, tx_rings and xdp_rings are allocated before rx_rings. If the allocation of rx_rings fails, the code jumps to the done label leaking both tx_rings and xdp_rings. Furthermore, if the setup of an individual Rx ring fails during the loop, the code jumps to the free_tx label which releases tx_rings but leaks xdp_rings. Fix this by introducing a free_xdp label and updating the error paths to ensure both xdp_rings and tx_rings are properly freed if rx_rings allocation or setup fails. Compile tested only. Issue found using a prototype static analysis tool and code review. Fixes: fcea6f3da546 ("ice: Add stats and ethtool support") Fixes: efc2214b6047 ("ice: Add support for XDP") Signed-off-by: Zilin Guan <zilin@seu.edu.cn> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Tested-by: Rinitha S <sx.rinitha@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-03-04ice: fix retry for AQ command 0x06EEJakub Staniszewski2-21/+15
Executing ethtool -m can fail reporting a netlink I/O error while firmware link management holds the i2c bus used to communicate with the module. According to Intel(R) Ethernet Controller E810 Datasheet Rev 2.8 [1] Section 3.3.10.4 Read/Write SFF EEPROM (0x06EE) request should to be retried upon receiving EBUSY from firmware. Commit e9c9692c8a81 ("ice: Reimplement module reads used by ethtool") implemented it only for part of ice_get_module_eeprom(), leaving all other calls to ice_aq_sff_eeprom() vulnerable to returning early on getting EBUSY without retrying. Remove the retry loop from ice_get_module_eeprom() and add Admin Queue (AQ) command with opcode 0x06EE to the list of commands that should be retried on receiving EBUSY from firmware. Cc: stable@vger.kernel.org Fixes: e9c9692c8a81 ("ice: Reimplement module reads used by ethtool") Signed-off-by: Jakub Staniszewski <jakub.staniszewski@linux.intel.com> Co-developed-by: Dawid Osuchowski <dawid.osuchowski@linux.intel.com> Signed-off-by: Dawid Osuchowski <dawid.osuchowski@linux.intel.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Link: https://www.intel.com/content/www/us/en/content-details/613875/intel-ethernet-controller-e810-datasheet.html [1] 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>
2026-03-04ice: reintroduce retry mechanism for indirect AQJakub Staniszewski1-3/+9
Add retry mechanism for indirect Admin Queue (AQ) commands. To do so we need to keep the command buffer. This technically reverts commit 43a630e37e25 ("ice: remove unused buffer copy code in ice_sq_send_cmd_retry()"), but combines it with a fix in the logic by using a kmemdup() call, making it more robust and less likely to break in the future due to programmer error. Cc: Michal Schmidt <mschmidt@redhat.com> Cc: stable@vger.kernel.org Fixes: 3056df93f7a8 ("ice: Re-send some AQ commands, as result of EBUSY AQ error") Signed-off-by: Jakub Staniszewski <jakub.staniszewski@linux.intel.com> Co-developed-by: Dawid Osuchowski <dawid.osuchowski@linux.intel.com> Signed-off-by: Dawid Osuchowski <dawid.osuchowski@linux.intel.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@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>
2026-03-04ice: fix adding AQ LLDP filter for VFLarysa Zaremba1-1/+1
The referenced commit came from a misunderstanding of the FW LLDP filter AQ (Admin Queue) command due to the error in the internal documentation. Contrary to the assumptions in the original commit, VFs can be added and deleted from this filter without any problems. Introduced dev_info message proved to be useful, so reverting the whole commit does not make sense. Without this fix, trusted VFs do not receive LLDP traffic, if there is an AQ LLDP filter on PF. When trusted VF attempts to add an LLDP multicast MAC address, the following message can be seen in dmesg on host: ice 0000:33:00.0: Failed to add Rx LLDP rule on VSI 20 error: -95 Revert checking VSI type when adding LLDP filter through AQ. Fixes: 4d5a1c4e6d49 ("ice: do not add LLDP-specific filter if not necessary") Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com> Tested-by: Rafal Romanowski <rafal.romanowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-03-03drm/msm: Fix dma_free_attrs() buffer sizeThomas Fourier1-1/+1
The gpummu->table buffer is alloc'd with size TABLE_SIZE + 32 in a2xx_gpummu_new() but freed with size TABLE_SIZE in a2xx_gpummu_destroy(). Change the free size to match the allocation. Fixes: c2052a4e5c99 ("drm/msm: implement a2xx mmu") Cc: <stable@vger.kernel.org> Signed-off-by: Thomas Fourier <fourier.thomas@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/707340/ Message-ID: <20260226095714.12126-2-fourier.thomas@gmail.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-03-03drm/msm/a6xx: Fix the bogus protect error on X2-85Akhil P Oommen1-2/+1
Update the X2-85 gpu's register protect count configuration with the correct count_max value to avoid blocking the entire MMIO region from the UMD. Protect configurations are a bit complicated on A8xx. There are 2 set of protect registers with different counts: Global and Pipe-specific. The last-span-unbound feature is available only on the Pipe-specific protect registers. Due to this, we cannot use the BUILD_BUG sanity check for A8x protect configurations, so remove the A840 entry from there. Fixes: 01ff3bf27215 ("drm/msm/a8xx: Add support for Adreno X2-85 GPU") Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/706944/ Message-ID: <20260225-glymur-protect-fix-v1-1-0deddedf9277@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-03-03cxl/port: Fix use after free of parent_port in cxl_detach_ep()Alison Schofield1-2/+6
cxl_detach_ep() is called during bottom-up removal when all CXL memory devices beneath a switch port have been removed. For each port in the hierarchy it locks both the port and its parent, removes the endpoint, and if the port is now empty, marks it dead and unregisters the port by calling delete_switch_port(). There are two places during this work where the parent_port may be used after freeing: First, a concurrent detach may have already processed a port by the time a second worker finds it via bus_find_device(). Without pinning parent_port, it may already be freed when we discover port->dead and attempt to unlock the parent_port. In a production kernel that's a silent memory corruption, with lock debug, it looks like this: []DEBUG_LOCKS_WARN_ON(__owner_task(owner) != get_current()) []WARNING: kernel/locking/mutex.c:949 at __mutex_unlock_slowpath+0x1ee/0x310 []Call Trace: []mutex_unlock+0xd/0x20 []cxl_detach_ep+0x180/0x400 [cxl_core] []devm_action_release+0x10/0x20 []devres_release_all+0xa8/0xe0 []device_unbind_cleanup+0xd/0xa0 []really_probe+0x1a6/0x3e0 Second, delete_switch_port() releases three devm actions registered against parent_port. The last of those is unregister_port() and it calls device_unregister() on the child port, which can cascade. If parent_port is now also empty the device core may unregister and free it too. So by the time delete_switch_port() returns, parent_port may be free, and the subsequent device_unlock(&parent_port->dev) operates on freed memory. The kernel log looks same as above, with a different offset in cxl_detach_ep(). Both of these issues stem from the absence of a lifetime guarantee between a child port and its parent port. Establish a lifetime rule for ports: child ports hold a reference to their parent device until release. Take the reference when the port is allocated and drop it when released. This ensures the parent is valid for the full lifetime of the child and eliminates the use after free window in cxl_detach_ep(). This is easily reproduced with a reload of cxl_acpi in QEMU with CXL devices present. Fixes: 2345df54249c ("cxl/memdev: Fix endpoint port removal") Reviewed-by: Dave Jiang <dave.jiang@intel.com> Reviewed-by: Li Ming <ming.li@zohomail.com> Signed-off-by: Alison Schofield <alison.schofield@intel.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Link: https://patch.msgid.link/20260226184439.1732841-1-alison.schofield@intel.com Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2026-03-03drm/i915/overlay: Fix oops on unloadVille Syrjälä1-2/+2
Apparently I failed to test the unload case properly and thus didn't notice that the i915_overlay_is_active() needs i915->overlay after fetch_and_zero() already cleared it. Stop using fetch_and_zero() and only clear the pointer at the end to avoid the oops. Fixes: 38d9a352c45e ("drm/i915/overlay: Extract i915_overlay_is_active()") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260303101417.14409-1-ville.syrjala@linux.intel.com Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
2026-03-03soc: microchip: mpfs-sys-controller: add support for pic64gxPierre-Henry Moussay1-20/+54
pic64gx is not compatible with mpfs because due to the lack of FPGA functionality some features are disabled. Notably, anything to do with FPGA fabric contents is not supported. Signed-off-by: Pierre-Henry Moussay <pierre-henry.moussay@microchip.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2026-03-03ixgbe: refactor: use DECLARE_BITMAP for ring state fieldAleksandr Loktionov4-44/+45
Convert the ring state field from 'unsigned long' to a proper bitmap using DECLARE_BITMAP macro, aligning with the implementation pattern already used in the i40e driver. This change: - Adds __IXGBE_RING_STATE_NBITS as the bitmap size sentinel to enum ixgbe_ring_state_t (consistent with i40e's __I40E_RING_STATE_NBITS) - Changes 'unsigned long state' to 'DECLARE_BITMAP(state, __IXGBE_RING_STATE_NBITS)' in struct ixgbe_ring - Removes the address-of operator (&) when passing ring->state to bit manipulation functions, as bitmap arrays naturally decay to pointers The change maintains functional equivalence while using the more appropriate kernel bitmap API, consistent with other Intel Ethernet drivers. Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Marcin Szycik <marcin.szycik@linux.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>
2026-03-03i40e: Add missing wordpart.h headerAndy Shevchenko1-0/+2
When cleaning up another header I have met this build error: drivers/net/ethernet/intel/i40e/i40e_hmc.h:105:22: error: implicit declaration of function 'upper_32_bits' [-Wimplicit-function-declaration] 105 | val1 = (u32)(upper_32_bits(pa)); \ This is due to missing header, add it to fix the possible issue. Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-03-03i40e: drop useless bitmap_weight() call in i40e_set_rxfh_fields()Yury Norov (NVIDIA)1-13/+8
bitmap_weight() is O(N) and useless here, because the following for_each_set_bit() returns immediately in case of empty flow_pctypes. Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Rinitha S <sx.rinitha@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-03-03ice: Make name member of struct ice_cgu_pin_desc constSimon Horman1-1/+1
The name member of struct ice_cgu_pin_desc never modified. Make it const. Found by inspection. Compile tested only. Signed-off-by: Simon Horman <horms@kernel.org> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-03-03drm/i915/dp: Ack only the handled link service IRQsImre Deak1-1/+16
Ack only those SST link service IRQs that will be handled, similarly to device service IRQs. While at it add asserts that only the known/acked link service IRQs are handled both in the MST and SST case. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260225164618.1261368-21-imre.deak@intel.com
2026-03-03drm/i915/dp: Ack only the handled device service IRQsImre Deak1-0/+14
Only those IRQs should be acked that are handled, however for SST all IRQs triggered by the sink are acked. This can be a problem for flags that are reserved/reading zero at a given moment, but become used for some purpose - with a side-effect if set - in a future DPCD revision. Fix the above by acking only those device service IRQs that will be handled. While at it add asserts that only the known/acked device service IRQs are handled both in the MST and SST case. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260225164618.1261368-20-imre.deak@intel.com
2026-03-03drm/i915/dp_mst: Reuse intel_dp_handle_link_service_irq()Imre Deak1-9/+4
Use intel_dp_handle_link_service_irq() while handling an MST HPD IRQ, instead of open-coding this. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260225164618.1261368-19-imre.deak@intel.com
2026-03-03drm/i915/dp: Check SST link status while handling link service IRQsImre Deak1-2/+9
Move checking the link status for SST to intel_dp_handle_link_service_irq(). This is the logical place for the check which should only happen in response to a LINK_STATUS_CHANGE sink IRQ. This IRQ is only supported by DPCD revision >= 1.2, so for sinks with an older DPCD revision the link status is checked in response to any HPD IRQ. For newer DPCD revisions however the link status check can be made conditional on LINK_STATUS_CHANGE. For now keep the current behavior of always forcing a link status check regardless of LINK_STATUS_CHANGE being set or not. This also prepares for a follow-up change sharing the link service IRQ handler for SST and MST (on MST the link status check only happening in response to a LINK_STATUS_CHANGE IRQ). Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260225164618.1261368-18-imre.deak@intel.com
2026-03-03drm/i915/dp: Print debug message for a sink connected off requestImre Deak1-0/+8
So far the CONNECTED_OFF_ENTRY_REQUESTED request was accepted only implicitly, by acking all the IRQs raised by the sink. Make this explicit by printing a debug message. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260225164618.1261368-17-imre.deak@intel.com
2026-03-03drm/i915/dp: Read/ack sink count and sink IRQs for SST as it's done for MSTImre Deak1-63/+79
Read and ack the sink count, sink device and link service IRQs for SST the same way this is done for MST, the read/ack happening in separate steps via an ESI (Event Status Indicator) vector. The above way is more efficient, since on newer (DPCD_REV >= 1.2) sinks the DP_SINK_COUNT_ESI..DP_LINK_SERVICE_IRQ_VECTOR_ESI0 registers can be read out in one AUX transaction - and the 3 last one written in one transaction. Also this allows sharing more of the SST and MST IRQ handling code (done as a follow-up). For now keep the current behavior of always reading the legacy DP_SINK_COUNT, DP_DEVICE_SERVICE_IRQ_VECTOR registers and not reading the DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1 register. v2: Document the ESI vector get/ack helper fnuctions' return value. (Jani, Luca) Cc: Jani Nikula <jani.nikula@intel.com> Cc: Luca Coelho <luciano.coelho@intel.com> Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260225164618.1261368-16-imre.deak@intel.com
2026-03-03drm/i915/dp: Return early if getting/ackink link service IRQs failsImre Deak1-16/+29
If getting/acking the link service IRQs fail, the short HPD handler should bail out, falling back to a full connector detection as in case of any AUX access failures during the HPD handling. Do this by separating the getting/acking and handling steps of the IRQs. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260225164618.1261368-15-imre.deak@intel.com
2026-03-03drm/i915/dp: Return early if getting/acking device service IRQs failsImre Deak1-12/+23
If getting/acking the device service IRQs fail, the short HPD handler should bail out, falling back to a full connector detection as in case of any AUX access failures during the HPD handling. Do this by separating the getting/acking and handling steps of the IRQs. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260225164618.1261368-14-imre.deak@intel.com
2026-03-03drm/i915/dp: Reprobe connector if getting/acking link service IRQs failsImre Deak1-2/+10
An AUX access failure during HPD IRQ handling should be handled by falling back to a full connector detection, ensure that if the failure happens while reading/acking a link service IRQ. While at it add code comment documenting the return value of intel_dp_check_link_service_irq(). v2: Docuement intel_dp_check_link_service_irq()'s return value. (Jani) Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260225164618.1261368-13-imre.deak@intel.com
2026-03-03drm/i915/dp: Reprobe connector if getting/acking device IRQs failsImre Deak1-6/+19
An AUX access failure during HPD IRQ handling should be handled by falling back to a full connector detection, ensure that if the failure happens while reading/acking a device service IRQ. v2: Document intel_dp_check_device_service_irq()'s return value. (Jani, Luca) Cc: Jani Nikula <jani.nikula@intel.com> Cc: Luca Coelho <luciano.coelho@intel.com> Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260225164618.1261368-12-imre.deak@intel.com
2026-03-03drm/i915/dp: Fix the link service IRQ DPCD_REV checkImre Deak1-1/+1
The DP_LINK_SERVICE_IRQ_VECTOR_ESI0 DPCD register is supported only since DPCD REV 1.2, so fix the revision check accordingly. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260225164618.1261368-11-imre.deak@intel.com
2026-03-03drm/i915/dp: Fix the device service IRQ DPCD_REV checkImre Deak1-3/+0
The DP_DEVICE_SERVICE_IRQ_VECTOR DPCD register is supported since DPCD REV 1.0, so read it out always. Flags added only by later DPCD revisions are defined as reserved/must-be-zero by earlier DP Standard versions. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260225164618.1261368-10-imre.deak@intel.com
2026-03-03drm/i915/dp: Remove the device service IRQ handling from connector detectImre Deak1-2/+0
The device service IRQ handling was added to the connector detect function by commit 09b1eb130e43 ("drm/i915: Move Displayport test request and sink IRQ logic to intel_dp_detect()") since some Automated Test Request IRQs couldn't be handled in the short HPD IRQ handler context. This has been fixed meanwhile by deferring the handling of all test request events from the IRQ handler to the hotplug handler (intel_dp_short_pulse() -> intel_dp_test_short_pulse() -> reprobe) and by handling all hotplug events (both for short and long HPD pulses) in the test application. Handling device IRQs during connector detection is not standard compliant (the IRQs should be handled when an HPD IRQ is raised) and it happens in a racy way with the same device IRQ handling happening from the HPD IRQ handler (since the detect and HPD IRQ handler can run in parallel). Based on the above, remove the redundant call from the detect function. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260225164618.1261368-9-imre.deak@intel.com
2026-03-03drm/i915/dp: Don't clobber the encoder state in the HPD IRQ handlerImre Deak1-6/+2
The intel_dp_get_dpcd() function called from an HPD IRQ handler reads out the DPRX capabilities from the sink and updates these in the intel_dp encoder state. Since the IRQ handler can run in parallel with the encoder/connector detection (intel_dp_detect()) which also calls intel_dp_get_dpcd(), the encoder state can get corrupted, since the two updates happen in a racy way. Fix the above by checking only for any change in the sink count value in the HPD IRQ handler, without updating the encoder state. Note that any state change in the sink requiring an update of the encoder state is handled via the sink's SINK_COUNT change, RX_CAPS_CHANGED, DOWNSTREAM_PORT_STATUS_CHANGED signaling, which all should result in a full connector detection. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260225164618.1261368-8-imre.deak@intel.com
2026-03-03drm/i915/dp: Handle the DOWNSTREAM_PORT_STATUS_CHANGED eventImre Deak2-1/+16
Handle the DOWNSTREAM_PORT_STATUS_CHANGED event a branch device can use to indicate the state change of a DFP connector on the branch device. The event is signaled in the DP_LANE_ALIGN_STATUS_UPDATED DPCD register setting a clear-on-read flag and triggering an HPD IRQ. Accordingly keep a cached version of the flag, updating it whenever DP_LANE_ALIGN_STATUS_UPDATED is read. Schedule a full connector detection from the HPD IRQ handler if the cached flag is set and clear the cached flag at the start of detection. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260225164618.1261368-7-imre.deak@intel.com
2026-03-03drm/i915/dp: Handle the RX_CAP_CHANGED HPD IRQImre Deak1-1/+7
Handle the RX_CAP_CHANGED IRQ, which a sink can use to indicate a DPRX capability change without disconnecting and reconnecting itself (i.e. through a short vs. long HPD pulse). Handle the IRQ by doing a full connector detection. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260225164618.1261368-6-imre.deak@intel.com
2026-03-03drm/i915/dp: Handle a tunneling IRQ after acking itImre Deak1-14/+11
HPD IRQs in general should be handled after acking them. The 1. Read IRQ register (read DP_DEVICE_SERVICE_IRQ_VECTOR, DP_LINK_SERVICE_IRQ_VECTOR_ESI0) 2. Handle IRQ 3. Ack IRQ (write DP_DEVICE_SERVICE_IRQ_VECTOR, DP_LINK_SERVICE_IRQ_VECTOR_ESI0) sequence would miss a new interrupt triggered after 2. and before 3., since the flag set in the IRQ register for this interrupt would be cleared in step 3. Fix the above by handling the IRQ after acking it. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260225164618.1261368-5-imre.deak@intel.com
generated by cgit v1.2.3 (git 2.39.0) at 2026-06-11 09:57:29 +0300