summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2026-05-27mtd: Consistently define pci_device_idsUwe Kleine-König (The Capable Hub)
Initializing a pci_device_id using plain list expressions is hard to understand for a human who isn't into the Linux PCI subsystem. So for each initializer use one of the PCI_DEVICE macros for .vendor, .device, .subvendor and .subdevice and named initializers for the remaining assignments. This makes it easier to parse and also more robust against chagnes to the struct definition. Also drop useless zeros and commas. The mentioned robustness is relevant for a planned change to struct pci_device_id that replaces .driver_data by an anonymous union. This change doesn't introduce changes to the compiled pci_device_id array. Tested on x86 and arm64. Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2026-05-27mtd: rawnand: pl353: fix probe resource allocationBastien Curutchet
During probe(), the devm_ioremap() is called with the parent device instead of the current one. So when the module is unloaded, the register area isn't released. Target the pl35x device in the devm_ioremap() instead of its parent. Cc: stable@vger.kernel.org Fixes: 08d8c62164a3 ("mtd: rawnand: pl353: Add support for the ARM PL353 SMC NAND controller") Signed-off-by: Bastien Curutchet <bastien.curutchet@bootlin.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2026-05-27mtd: rawnand: qcom: embed nand_controller into qcom_nand_controllerRosen Penev
The qcom_nand_controller had a struct nand_controller *controller pointer that was assigned to (struct nand_controller *)&nandc[1], with the allocation oversized by sizeof(*controller) to make room. get_qcom_nand_controller() then walked backwards from chip->controller using sizeof()-based arithmetic to recover the enclosing nandc. Embed the nand_controller directly into qcom_nand_controller and use container_of() in get_qcom_nand_controller(). The header now needs the full rawnand.h definition rather than a forward declaration. Assisted-by: Claude:Opus-4.7 Signed-off-by: Rosen Penev <rosenp@gmail.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2026-05-27mtd: rawnand: Pause continuous reads at block boundariesMiquel Raynal
Some chips do not support sequential cached reads past block boundaries, like Winbond. In practice when using UBI, this should very rarely happen, but let's make sure it never happens. Cc: stable@vger.kernel.org Fixes: 003fe4b9545b ("mtd: rawnand: Support for sequential cache reads") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2026-05-27mtd: maps: vmu-flash: fix NULL pointer dereference in initializationFlorian Fuchs
The mtd_info contains a struct device, which must be linked to its parent. Without this, the initialization of the MTD fails with a NULL pointer dereference. Fixes: 47a72688fae7 ("mtd: flash mapping support for Dreamcast VMU.") Cc: stable@vger.kernel.org Signed-off-by: Florian Fuchs <fuchsfl@gmail.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2026-05-27mtd: maps: vmu-flash: fix fault in unaligned fixupFlorian Fuchs
Use kzalloc_obj() / kzalloc_objs() to allocate the memcard structs, instead of kmalloc_obj() / kmalloc_objs() to prevent access to uninitialized data. Fixes runtime error: Fault in unaligned fixup: 0000 [#1] at mtd_get_fact_prot_info. Fixes: 47a72688fae7 ("mtd: flash mapping support for Dreamcast VMU.") Cc: stable@vger.kernel.org Signed-off-by: Florian Fuchs <fuchsfl@gmail.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2026-05-27mtd: spinand: macronix: Enable randomizer supportCheng Ming Lin
Implement the 'set_randomizer' callback for Macronix SPI NAND chips. The randomizer is enabled by setting bit 1 of the Configuration Register (address 0x10). This patch adds support for the following chips: - MX35LFxG24AD series - MX35UFxG24AD series When the randomizer is enabled, data is scrambled internally during program operations and automatically descrambled during read operations. This helps reduce bit errors caused by program disturbance. Please refer to the following link for randomizer feature: Link: https://www.mxic.com.tw/Lists/ApplicationNote/Attachments/2151/AN1051V1-The%20Introduction%20of%20Randomizer%20Feature%20on%20MX30xFxG28AD_MX35xFxG24AD.pdf Signed-off-by: Cheng Ming Lin <chengminglin@mxic.com.tw> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2026-05-27mtd: spinand: Add support for randomizerCheng Ming Lin
This patch adds support for the randomizer feature. It introduces a 'set_randomizer' callback in 'struct spinand_info' and 'struct spinand_device'. If a driver implements this callback, the core will invoke it during device initialization (spinand_init) to enable or disable the randomizer feature based on the device tree configuration. Signed-off-by: Cheng Ming Lin <chengminglin@mxic.com.tw> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2026-05-27mtd: sc520cdp: Remove mapping since board is no longer supportedSean Young
Since commit 8b793a92d862 ("x86/cpu: Remove M486/M486SX/ELAN support"), this board is no longer supported. Remove the mtd map too. Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2026-05-27mtd: netsc520: Remove mapping since board is no longer supportedSean Young
Since commit 8b793a92d862 ("x86/cpu: Remove M486/M486SX/ELAN support"), this board is no longer supported. Remove the mtd map too. Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2026-05-27mtd: ts5500_flash: Remove mapping since board is no longer supportedSean Young
Since commit 8b793a92d862 ("x86/cpu: Remove M486/M486SX/ELAN support"), this board is no longer supported. Remove the mtd map too. Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2026-05-27mtd: rawnand: fix condition in 'nand_select_target()'Arseniy Krasnov
'cs' here must be in range [0:nanddev_ntargets[. Cc: stable@vger.kernel.org Fixes: 32813e288414 ("mtd: rawnand: Get rid of chip->numchips") Signed-off-by: Arseniy Krasnov <avkrasnov@rulkc.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2026-05-27media: staging: imx: remove unnecessary out-of-memory error messageShyam Sunder Reddy Padira
Remove dev_err() call after dma_alloc_coherent() failure. checkpatch.pl reports this as an unnecessary out-of-memory message because failure is already conveyed by returning -ENOMEM, and the current message does not provide additional useful debugging information. Signed-off-by: Shyam Sunder Reddy Padira <shyamsunderreddypadira@gmail.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-05-27media: staging: imx-csi: use media_pad_is_streaming helperMichael Tretter
The media_pad_is_streaming() helper is explicitly intended to check whether a pad has been started with media_pipeline_start(). Use it instead of relying on the implicit assumption that a pad with a pipeline is streaming. Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Michael Tretter <m.tretter@pengutronix.de> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-05-27media: staging: imx-csi: explicitly start media pipeline on pad 0Michael Tretter
entity->pads is an array that contains all the pads of an entity. Calling __media_pipeline_start() or __media_pipeline_stop() on the pads, implicitly starts the pipeline with the first pad in this array as origin. Explicitly use the first pad to start the pipeline to make this more obvious to the reader. Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Michael Tretter <m.tretter@pengutronix.de> Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-05-27media: staging: imx-csi: move media_pipeline to video deviceMichael Tretter
The imx-media driver has a single imx_media_device. Attaching the media_pipeline to the imx_media_device prevents the execution of multiple media pipelines on the device. This should be possible as long as the media_pipelines don't use the same pads or pads that be configured while the other media pipeline is streaming. Move the media_pipeline to the imx_media_video_dev to be able to construct media pipelines per imx capture device. If different media pipelines in the media device conflict, the validation will fail. Thus, the pipeline will fail to start and signal an error to user space. Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Michael Tretter <m.tretter@pengutronix.de> Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-05-27wifi: rtw89: usb: Support switching to USB 3 modeBitterblue Smith
The Realtek wifi 6/7 devices which support USB 3 are weird: when first plugged in, they pretend to be USB 2. The driver needs to send some commands to the device, which make it disappear and come back as a USB 3 device. Implement the required commands in rtw89. Add a new function rtw89_usb_write32_quiet() to avoid the warnings when writing to R_{AX,BE}_PAD_CTRL2. Even though the write succeeds, usb_control_msg() returns -EPROTO, probably because the USB device disappears immediately. This results in some confusing warnings in the kernel log. When a USB 3 device is plugged into a USB 2 port, rtw89 will try to switch it to USB 3 mode only once. The device will disappear and come back still in USB 2 mode, of course. Tested with RTL8832AU, RTL8832BU, RTL8832CU, and RTL8912AU. 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/e955451c-93a1-4d04-8024-d224a04f1d4a@gmail.com
2026-05-27media: rcar-vin: Drop min_queued_buffersJacopo Mondi
The R-Car VIN driver already uses a scratch buffer to sustain capture operations in absence of a frame buffer provided by userspace. There is no reason to require 4 buffers queued at all times for the driver to operate. Drop min_queued_buffers from the VIN driver to allow single-frame capture operations. Signed-off-by: Jacopo Mondi <jacopo.mondi+renesas@ideasonboard.com> Reviewed-by: Jai Luthra <jai.luthra+renesas@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Tested-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-05-27wifi: rtw88: Add more validation for the RX descriptorBitterblue Smith
Some RTL8821CE cards can return frames with corrupted RX descriptor, causing warnings and crashes if they are passed to the upper layers. The PHY status size field is 4 bits wide, but in rtw88 its value should only be 0 or 4. Checking this catches most of the corrupt frames. If a PHY status is present, the PHY status size should not be 0. The frame size should not be less than or equal to 4 and should not exceed 11454. The rate should not exceed 4SS MCS9. Discard the frame if any of these checks fail. Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221286 Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Tested-by: Oleksandr Havrylov <goainwo@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/5bfecba3-8a90-4e0f-9558-af5cd8a14975@gmail.com
2026-05-27wifi: rtw89: 8922d: configure TX shape settingsZong-Zhe Yang
By default, BB enables triangular spectrum by a series of register settings. According to band and regulation, RF parameters determine whether TX shape needs to be restricted or not. So now, clear the corresponding settings if it has no need to do. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260520123823.1792954-8-pkshih@realtek.com
2026-05-27wifi: rtw89: debug: show large MRU in txpwr_table dbgfsZong-Zhe Yang
Read and print the CR settings of large MRU. For now, only RTL8922D_CID7090 support it. For example, [TX power limit_large_mru] RU484_242 1TX - IDX_0 IDX_1 IDX_2 IDX_3 | 17, 0, 0, 0, dBm RU484_242 2TX - IDX_0 IDX_1 IDX_2 IDX_3 | 16, 0, 0, 0, dBm RU996_484 1TX - IDX_0 IDX_1 | 0, 0, dBm RU996_484 2TX - IDX_0 IDX_1 | 0, 0, dBm RU996_484_242 1TX - IDX_0 IDX_1 | 0, 0, dBm RU996_484_242 2TX - IDX_0 IDX_1 | 0, 0, dBm Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260520123823.1792954-7-pkshih@realtek.com
2026-05-27drm/i915/power: drop resume parameter from intel_display_power_init_hw()Jani Nikula
intel_power_domains_resume() calling intel_display_power_init_hw() with the resume parameter is an internal implementation detail. Hide it inside intel_display_power.c, and provide a clean external interface without the parameter. Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/63666514d457f548c69ccd35c02f2b8200ca08a1.1779800132.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-05-27drm/i915/power: rename intel_power_domains_*() to intel_display_power_*()Jani Nikula
It's confusing that intel_display_power.[ch] exposes two groups of interfaces, one named intel_power_domains_*() and one intel_display_power_*(). Unify on the latter, based on the file name, but also because it's more generic. This makes the caller side easier to follow. Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/8fae4b0e3476aeffb0164215b7e0f0ae1d825f72.1779800132.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-05-27drm/i915/power: make intel_power_domains_{suspend, resume}() staticJani Nikula
intel_power_domains_suspend() and intel_power_domains_resume() are only used inside intel_display_power.c. Make them static. Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/bfb5f09794b6b5035839d0182d22980119da2165.1779800132.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-05-27wifi: rtw89: Wi-Fi 7 configure TX power limit for large MRUZong-Zhe Yang
Support of Large MRU (Multiple Resource Unit) starts from RTL8922D_CID7090, i.e. RTL8922A and RTL8922D-VS variant do not support it. There are the new corresponding control registers. So, configure them. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260520123823.1792954-6-pkshih@realtek.com
2026-05-27wifi: rtw89: fw: load TX compensation element by RFE typePing-Ke Shih
Originally driver uses TX compensation element by AID, and now tables are by RFE type. Add the logic accordingly. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260520123823.1792954-5-pkshih@realtek.com
2026-05-27wifi: rtw89: 8922d: support new digital power compensation formatPing-Ke Shih
The new format shared the base set (7 elements). As there are total 40 sets, save 7 * 39 elements. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260520123823.1792954-4-pkshih@realtek.com
2026-05-27wifi: rtw89: 8922d: refactor digital power compensation to support new formatPing-Ke Shih
Because base settings of digital power compensation can be shared across all bands, the settings are divided into two parts -- base and individual values per bands. Refactor the code to be reuse with new format. No change logic at all. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260520123823.1792954-3-pkshih@realtek.com
2026-05-27wifi: rtw89: fw: load TX power track element according to AIDZong-Zhe Yang
RF parameters has different TX power track table for different AID. FW elements may include multiple TX power track tables for different AID. So, load the corresponding one. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260520123823.1792954-2-pkshih@realtek.com
2026-05-27gpio: gpiolib: use seq_puts() for plain stringsChen Jung Ku
Replace seq_printf() with seq_puts() where the format string is a plain string literal with no format specifiers. No functional change intended. Signed-off-by: Chen Jung Ku <ku.loong@gapp.nthu.edu.tw> Link: https://patch.msgid.link/20260526121905.46345-1-ku.loong@gapp.nthu.edu.tw Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-05-27gpio: ts5500: remove obsolete driverArnd Bergmann
The ts5500 platform is no longer functional because it is based on the removed AMD Élan i486 SoC. Remove the now obsolete driver. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Linus Walleij <linusw@kernel.org> Link: https://patch.msgid.link/20260526103424.3246915-1-arnd@kernel.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-05-26net: thunderx: fix PTP device ref leak in nicvf_probe()Haoxiang Li
cavium_ptp_get() acquires a reference to the PTP PCI device through pci_get_device(). If any initialization step fails after cavium_ptp_get(), the PTP PCI device reference is leaked. Add a common error path to release the PTP reference before returning from probe failures. Signed-off-by: Haoxiang Li <lihaoxiang@isrc.iscas.ac.cn> Link: https://patch.msgid.link/20260525082611.61817-1-lihaoxiang@isrc.iscas.ac.cn Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-26Merge tag 'nfc-7.1-rc6' of https://codeberg.org/linux-nfc/linuxJakub Kicinski
David Heidelberg says: ==================== nfc pull request for net: Code improvements - llcp: Fix use-after-free in llcp_sock_release() - llcp: Fix use-after-free race in nfc_llcp_recv_cc() - hci: fix out-of-bounds read in HCP header parsing Regression fixes: - nxp-nci: i2c: use rising-edge IRQ on ACPI systems Signed-off-by: David Heidelberg <david@ixit.cz> * tag 'nfc-7.1-rc6' of https://codeberg.org/linux-nfc/linux: nfc: nxp-nci: i2c: use rising-edge IRQ on ACPI systems nfc: hci: fix out-of-bounds read in HCP header parsing nfc: llcp: Fix use-after-free race in nfc_llcp_recv_cc() nfc: llcp: Fix use-after-free in llcp_sock_release() ==================== Link: https://patch.msgid.link/217c0646-8a30-4037-b613-580c2b189729@ixit.cz Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-26vxlan: do not reuse cached ip_hdr() value after skb_tunnel_check_pmtu()Eric Dumazet
skb_tunnel_check_pmtu() can change skb->head. Reusing old_iph afer skb_tunnel_check_pmtu() can cause an UAF. Use instead ip_hdr(skb) as done in drivers/net/bareudp.c and drivers/net/geneve.c. Found by Sashiko. Fixes: 4cb47a8644cc ("tunnels: PMTU discovery support for directly bridged IP packets") Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Stefano Brivio <sbrivio@redhat.com> Link: https://patch.msgid.link/20260525203642.2389723-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-26netconsole: Constify struct configfs_item_operations and ↵Christophe JAILLET
configfs_group_operations 'struct configfs_item_operations' and 'configfs_group_operations' are not modified in this driver. Constifying these structures moves some data to a read-only section, so increases overall security, especially when the structure holds some function pointers. On a x86_64, with allmodconfig, as an example: Before: ====== text data bss dec hex filename 64259 24272 608 89139 15c33 drivers/net/netconsole.o After: ===== text data bss dec hex filename 64579 23952 608 89139 15c33 drivers/net/netconsole.o Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/7ff56bdb0cee826a56365f930dcdf457b44931df.1779711734.git.christophe.jaillet@wanadoo.fr Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-26mlxsw: spectrum_fid: use a dedicated list head pointer for sorted insertMaoyi Xie
mlxsw_sp_fid_port_vid_list_add() inserts into a list sorted by local_port. It walks the list to find the first entry with a larger local_port, then inserts the new entry before it: list_add_tail(&port_vid->list, &tmp_port_vid->list); If the loop falls through (the new local_port is the largest), tmp_port_vid runs off the end of the list. &tmp_port_vid->list then ends up at the list head itself (container_of() offsets cancel), and list_add_tail() inserts at the tail. So the code works today. It is fragile though. Anyone who later adds a read of another field of tmp_port_vid will hit memory outside the list head. Track the insertion point with a dedicated list_head pointer. Initialise insert_before to &fid->port_vid_list, set it to &tmp_port_vid->list only on early break, and pass insert_before to list_add_tail(). The cursor is no longer touched after the loop. Behaviour is unchanged. Same shape as the Koschel cleanups from 2022 (e.g. 99d8ae4ec8a tracing, 2966a9918df clockevents, dc1acd5c946 dlm). Signed-off-by: Maoyi Xie <maoyixie.tju@gmail.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20260525071759.1517576-1-maoyixie.tju@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-26net: dsa: netc: fix unmet Kconfig dependencies for NET_DSA_NETC_SWITCHWei Fang
NET_DSA_NETC_SWITCH selects NXP_NTMP, NXP_NETC_LIB and FSL_ENETC_MDIO, but these symbols depend on NET_VENDOR_FREESCALE which may not be enabled. This results in Kconfig warnings and linker errors like: undefined reference to `ntmp_bpt_update_entry' undefined reference to `ntmp_fdbt_search_port_entry' undefined reference to `ntmp_free_cbdr' undefined reference to `enetc_hw_alloc' ... Therefore, add "depends on NET_VENDOR_FREESCALE" to NET_DSA_NETC_SWITCH, ensuring that the selected symbols NXP_NTMP, NXP_NETC_LIB and FSL_ENETC_MDIO, which all depend on NET_VENDOR_FREESCALE, can only be selected when that dependency is already satisfied. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202605240046.8MvKuOMg-lkp@intel.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202605240706.EuGmnrz5-lkp@intel.com/ Fixes: 187fbae024c8 ("net: dsa: netc: introduce NXP NETC switch driver for i.MX94") Signed-off-by: Wei Fang <wei.fang@nxp.com> Link: https://patch.msgid.link/20260524070310.2429819-1-wei.fang@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-26net: phy: air_en8811h: add AN8811HB MCU assert/deassert supportLucien.Jheng
AN8811HB needs a MCU soft-reset cycle before firmware loading begins. Assert the MCU (hold it in reset) and immediately deassert (release) via a dedicated PBUS register pair (0x5cf9f8 / 0x5cf9fc), accessed through a registered mdio_device at PHY-addr+8. Add __air_pbus_reg_write() as a low-level helper taking a struct mdio_device *, create and register the PBUS mdio_device in an8811hb_probe() and store it in priv->pbusdev, then implement an8811hb_mcu_assert() / _deassert() on top of it. Add an8811hb_remove() to unregister the PBUS device on teardown. Wire both calls into an8811hb_load_firmware() and en8811h_restart_mcu() so every firmware load or MCU restart on AN8811HB correctly sequences the reset control registers. Fixes: 5afda1d734ed ("net: phy: air_en8811h: add Airoha AN8811HB support") Signed-off-by: Lucien Jheng <lucienzx159@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20260524063915.47961-1-lucienzx159@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-27i2c: davinci: fix division by zero on missing clock-frequencyChaitanya Sabnis
When the 'clock-frequency' property is missing from the device tree, the driver falls back to DAVINCI_I2C_DEFAULT_BUS_FREQ. However, this macro was defined in kHz (100), whereas the device tree property is expected in Hz. The probe function divided the fallback value by 1000, causing integer truncation that resulted in dev->bus_freq = 0. This triggered a deterministic division-by-zero kernel panic when calculating clock dividers later in the probe sequence. Fix this by redefining DAVINCI_I2C_DEFAULT_BUS_FREQ in Hz (100000) to match the expected device tree property unit, allowing the existing division logic to work correctly for both cases. Fixes: b04ce6385979 ("i2c: davinci: kill platform data") Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://lore.kernel.org/all/20260514044726.57297C2BCB7@smtp.kernel.org/ Signed-off-by: Chaitanya Sabnis <chaitanya.msabnis@gmail.com> Cc: <stable@vger.kernel.org> # v6.14+ Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20260526102240.4949-1-chaitanya.msabnis@gmail.com
2026-05-27drm/i915/display: stop passing i to for_each_pipe_crtc_modeset_{enable, ↵Jani Nikula
disable}() Refactor for_each_pipe_crtc_modeset_{enable,disable}() and their underlying for_each_crtc_in_masks{,_reverse}() helpers to utilize __UNIQUE_ID() to avoid having to pass the for loop variable to them. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/2270d4a10663bb55d5b16902b02798234f440517.1778659089.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-05-27drm/i915/display: stop passing i to for_each_*_intel_crtc_in_state() macrosJani Nikula
None of the for_each_*_intel_crtc_in_state() macros or their users actually need the CRTC index i variable anymore. Remove them. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/edb9dc76cb9cad50622a1f425abaf076d1509888.1778659089.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-05-27drm/i915/display: pass struct intel_display to all for_each_intel_crtc*() macrosJani Nikula
Now that the for_each_intel_crtc*() iterator macros primarily use display->pipe_list for iteration, it's more convenient to pass struct intel_display to them directly instead of struct drm_device. Make it so. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/90ec6b84d772a4842d4816efc10042ec4403e996.1778659089.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-05-27drm/i915/display: always pass display->drm to for_each_intel_crtc*()Jani Nikula
In preparation for always passing struct intel_display to for_each_intel_crtc*() family of iterators, start off by unifying their usage to always having struct intel_display *display around, and passing display->drm to them. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/447a5b2309e213abb849601727d45b406d440c88.1778659089.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-05-27drm/i915/display: switch from drm_for_each_crtc() to for_each_intel_crtc()Jani Nikula
intel_has_pending_fb_unpin() has the last direct user of drm_for_each_crtc() in i915. Switch to for_each_intel_crtc() to ensure pipe order iteration in all cases. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/8ee4320cd15bc35a8b40676faae6db4b33eb50eb.1778659089.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-05-27drm/{i915, xe}: move xe_display_flush_cleanup_work() to i915 displayJani Nikula
xe_display_flush_cleanup_work() is a bit of an oddball function in xe display code. There shouldn't be anything this specific or xe specific. While I'm not sure what the correct refactor for the function should be, move it to shared display code for starters, next to the eerily similar but slightly different intel_has_pending_fb_unpin() that is only called from i915 core. The main goal here is to unblock some refactors on for_each_intel_crtc(). v2: Add FIXME comment (Ville) Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260525110553.651208-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-05-26nvme-multipath: enable PCI P2PDMA for multipath devicesKiran Kumar Modukuri
NVMe multipath does not expose BLK_FEAT_PCI_P2PDMA on the head disk even when all underlying controllers support it. Set BLK_FEAT_PCI_P2PDMA unconditionally in nvme_mpath_alloc_disk() alongside the other features. nvme_update_ns_info_block() already calls queue_limits_stack_bdev() to stack each path's limits onto the head disk, which routes through blk_stack_limits(). The core now clears BLK_FEAT_PCI_P2PDMA automatically if any path (e.g., FC) does not support it, consistent with how BLK_FEAT_NOWAIT and BLK_FEAT_POLL are handled. Tested-by: Pranjal Shrivastava <praan@google.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Reviewed-by: Nitesh Shetty <nj.shetty@samsung.com> Signed-off-by: Kiran Kumar Modukuri <kmodukuri@nvidia.com> Signed-off-by: Chaitanya Kulkarni <kch@nvidia.com> Tested=by: Pranjal Shrivastava <praan@google.com> Link: https://patch.msgid.link/20260513185153.95552-4-kch@nvidia.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-05-26md: propagate BLK_FEAT_PCI_P2PDMA from member devices to RAID deviceKiran Kumar Modukuri
MD RAID does not propagate BLK_FEAT_PCI_P2PDMA from member devices to the RAID device, preventing peer-to-peer DMA through the RAID layer even when all underlying devices support it. Enable BLK_FEAT_PCI_P2PDMA unconditionally in raid0, raid1 and raid10 personalities during queue limits setup. blk_stack_limits() clears it automatically if any member device lacks support, consistent with how BLK_FEAT_NOWAIT and BLK_FEAT_POLL are handled in the block core. Parity RAID personalities (raid4/5/6) are excluded because they require CPU access to data pages for parity computation, which is incompatible with P2P mappings. Tested with RAID0/1/10 arrays containing multiple NVMe devices with P2PDMA support, confirming that peer-to-peer transfers work correctly through the RAID layer. Tested-by: Pranjal Shrivastava <praan@google.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Reviewed-by: Xiao Ni <xni@redhat.com> Signed-off-by: Kiran Kumar Modukuri <kmodukuri@nvidia.com> Signed-off-by: Chaitanya Kulkarni <kch@nvidia.com> Reviewed-by: Yu Kuai <yukuai@fygo.io> Tested=by: Pranjal Shrivastava <praan@google.com> Link: https://patch.msgid.link/20260513185153.95552-3-kch@nvidia.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-05-26irqchip/gic-v4: Don't advertise VLPIs if no ITS is probedMostafa Saleh
When accidentally setting “kvm-arm.vgic_v4_enable=1” on a system that has no MSI controller device tree node and GICv4, it results a panic as “gic_domain” is NULL and the kernel attempts to access it. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000028 Mem abort info: ESR = 0x0000000096000006 CPU: 1 UID: 0 PID: 295 Comm: lkvm-static Not tainted 7.1.0-rc4-ge3f15ad3970e #5 PREEMPT Hardware name: linux,dummy-virt (DT) pstate: 81402005 (Nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : __irq_domain_instantiate+0x1d4/0x578 lr : __irq_domain_instantiate+0x1cc/0x578 Set vLPI support to false at init time if the host has no ITS, so it propagates properly to kvm_vgic_global_state.has_gicv4. Suggested-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Mostafa Saleh <smostafa@google.com> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Acked-by: Marc Zyngier <maz@kernel.org> Link: https://patch.msgid.link/20260526125317.3672297-1-smostafa@google.com
2026-05-26drm/xe: Assign queue name in time for drm_sched_initTvrtko Ursulin
Currently the queue name is only assigned after the drm scheduler instance has been created. This loses information with all logging or debug workqueue facilities so lets re-order things a bit so the name gets assigned in time. To be able to assign a GuC ID early we split the allocation into reservation and publish phases. First, with the submission state lock held, we reserve the ID in the GuC ID manager, which serves as an authoritative source of truth. Then we can drop the lock and reserve entries in the exec queue lookup XArray. This can be lockless since the NULL entries are invisible both to the kernel and userspace. Only after the queue has been fully created we replace the reserved entries with the queue pointer, which can be done locklessly for single width queues. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20260523103418.61832-1-tvrtko.ursulin@igalia.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-05-26iio: core: fix uninitialized data in debugfsDan Carpenter
If *ppos is non-zero then simple_write_to_buffer() will not initialize the start of buf[]. Non zero values for *ppos aren't going to work anyway. Test for them at the start of the function and return -EINVAL. Fixes: 6d5dd486c715 ("iio: core: make use of simple_write_to_buffer()") Signed-off-by: Dan Carpenter <error27@gmail.com> Reviewed-by: Maxwell Doose <m32285159@gmail.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>