summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2025-06-26gpio: rcar: Remove checks for empty bankmasksGeert Uytterhoeven1-10/+4
The GPIO core never passes empty bankmasks to the callbacks for handling multiple signals at once. Remove the superfluous checks, and refactor the code. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/29fb200d3f92e79cdd5ce4048d2847c265f337b4.1750838486.git.geert+renesas@glider.be Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-06-26drm/i915: remove unused DISPLAY_PLANE_FLIP_PENDING() macroJani Nikula1-1/+0
DISPLAY_PLANE_FLIP_PENDING() has been unused since commit fd3a40242e87 ("drm/i915: Rip out legacy page_flip completion/irq handling"). Remove. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/20250625132140.1564473-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-06-26drm/i915/display: Implement wa_16011342517Nemesa Garg2-0/+17
While doing voltage swing for type-c phy for DP 1.62 and HDMI write the LOADGEN_SHARING_PMD_DISABLE bit to 1. -v2: Update commit. Add bspec[Suraj] -v3: Move w/a before DKL_TX_PMD_LANE_SUS. Use DKL_TX_DPCNTL2[Ville] -v4: Use intel_encoder_is_dp and intel_encoder_is_hdmi. [Suraj] Bspec: 55359 Signed-off-by: Nemesa Garg <nemesa.garg@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/20250625074911.194085-1-nemesa.garg@intel.com
2025-06-26drm/i915/panel: register drm_panel and call prepare/unprepare for eDPArun R Murthy2-1/+6
Allocate and register drm_panel to allow the panel_follower framework to detect the eDP panel and pass drm_connector::kdev device to drm_panel allocation for matching. Call drm_panel_prepare/unprepare in ddi_enable for eDP to allow the followers to get notified of the panel power state changes. Note: This is for eDP with DDI platforms only. v2: remove backlight setup from panel_register (Jani) v3: Updated the commit message (Jani) Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/20250624-edp_panel-v3-1-e8197b6d9fde@intel.com
2025-06-26crypto: aspeed - Fix hash fallback path typoHerbert Xu1-1/+1
Fix typo in the fallback code path. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202506231830.us4hiwlZ-lkp@intel.com/ Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-06-26crypto: qat - Use crypto_shash_export_coreHerbert Xu1-7/+7
Use crypto_shash_export_core to export the core hash state without the partial blocks. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-06-26crypto: chelsio - Use crypto_shash_export_coreHerbert Xu1-5/+5
Use crypto_shash_export_core to export the core hash state without the partial blocks. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-06-26net: phy: realtek: add error handling to rtl8211f_get_wolDaniel Braunwarth1-2/+8
We should check if the WOL settings was successfully read from the PHY. In case this fails we cannot just use the error code and proceed. Signed-off-by: Daniel Braunwarth <daniel.braunwarth@kuka.com> Reported-by: Jon Hunter <jonathanh@nvidia.com> Closes: https://lore.kernel.org/baaa083b-9a69-460f-ab35-2a7cb3246ffd@nvidia.com Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20250624-realtek_fixes-v1-1-02a0b7c369bc@kuka.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-26net: enetc: Correct endianness handling in _enetc_rd_reg64Simon Horman1-1/+1
enetc_hw.h provides two versions of _enetc_rd_reg64. One which simply calls ioread64() when available. And another that composes the 64-bit result from ioread32() calls. In the second case the code appears to assume that each ioread32() call returns a little-endian value. However both the shift and logical or used to compose the return value would not work correctly on big endian systems if this were the case. Moreover, this is inconsistent with the first case where the return value of ioread64() is assumed to be in host byte order. It appears that the correct approach is for both versions to treat the return value of ioread*() functions as being in host byte order. And this patch corrects the ioread32()-based version to do so. This is a bug but would only manifest on big endian systems that make use of the ioread32-based implementation of _enetc_rd_reg64. While all in-tree users of this driver are little endian and make use of the ioread64-based implementation of _enetc_rd_reg64. Thus, no in-tree user of this driver is affected by this bug. Flagged by Sparse. Compile tested only. Fixes: 16eb4c85c964 ("enetc: Add ethtool statistics") Closes: https://lore.kernel.org/all/AM9PR04MB850500D3FC24FE23DEFCEA158879A@AM9PR04MB8505.eurprd04.prod.outlook.com/ Signed-off-by: Simon Horman <horms@kernel.org> Reviewed-by: Wei Fang <wei.fang@nxp.com> Link: https://patch.msgid.link/20250624-etnetc-le-v1-1-a73a95d96e4e@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-26atm: idt77252: Add missing `dma_map_error()`Thomas Fourier1-0/+5
The DMA map functions can fail and should be tested for errors. Signed-off-by: Thomas Fourier <fourier.thomas@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250624064148.12815-3-fourier.thomas@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-26team: replace team lock with rtnl lockStanislav Fomichev3-62/+50
syszbot reports various ordering issues for lower instance locks and team lock. Switch to using rtnl lock for protecting team device, similar to bonding. Based on the patch by Tetsuo Handa. Cc: Jiri Pirko <jiri@resnulli.us> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Reported-by: syzbot+705c61d60b091ef42c04@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=705c61d60b091ef42c04 Reported-by: syzbot+71fd22ae4b81631e22fd@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=71fd22ae4b81631e22fd Fixes: 6b1d3c5f675c ("team: grab team lock during team_change_rx_flags") Link: https://lkml.kernel.org/r/ZoZ2RH9BcahEB9Sb@nanopsycho.orion Signed-off-by: Stanislav Fomichev <sdf@fomichev.me> Link: https://patch.msgid.link/20250623153147.3413631-1-sdf@fomichev.me Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-26PCI: endpoint: Fix configfs group removal on driver teardownDamien Le Moal2-0/+2
An endpoint driver configfs attributes group is added to the epf_group list of struct pci_epf_driver by pci_epf_add_cfs() but an added group is not removed from this list when the attribute group is unregistered with pci_ep_cfs_remove_epf_group(). Add the missing list_del() call in pci_ep_cfs_remove_epf_group() to correctly remove the attribute group from the driver list. With this change, once the loop over all attribute groups in pci_epf_remove_cfs() completes, the driver epf_group list should be empty. Add a WARN_ON() to make sure of that. Fixes: ef1433f717a2 ("PCI: endpoint: Create configfs entry for each pci_epf_device_id table entry") Signed-off-by: Damien Le Moal <dlemoal@kernel.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Niklas Cassel <cassel@kernel.org> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20250624114544.342159-3-dlemoal@kernel.org
2025-06-26PCI: endpoint: Fix configfs group list head handlingDamien Le Moal1-1/+0
Doing a list_del() on the epf_group field of struct pci_epf_driver in pci_epf_remove_cfs() is not correct as this field is a list head, not a list entry. This list_del() call triggers a KASAN warning when an endpoint function driver which has a configfs attribute group is torn down: ================================================================== BUG: KASAN: slab-use-after-free in pci_epf_remove_cfs+0x17c/0x198 Write of size 8 at addr ffff00010f4a0d80 by task rmmod/319 CPU: 3 UID: 0 PID: 319 Comm: rmmod Not tainted 6.16.0-rc2 #1 NONE Hardware name: Radxa ROCK 5B (DT) Call trace: show_stack+0x2c/0x84 (C) dump_stack_lvl+0x70/0x98 print_report+0x17c/0x538 kasan_report+0xb8/0x190 __asan_report_store8_noabort+0x20/0x2c pci_epf_remove_cfs+0x17c/0x198 pci_epf_unregister_driver+0x18/0x30 nvmet_pci_epf_cleanup_module+0x24/0x30 [nvmet_pci_epf] __arm64_sys_delete_module+0x264/0x424 invoke_syscall+0x70/0x260 el0_svc_common.constprop.0+0xac/0x230 do_el0_svc+0x40/0x58 el0_svc+0x48/0xdc el0t_64_sync_handler+0x10c/0x138 el0t_64_sync+0x198/0x19c ... Remove this incorrect list_del() call from pci_epf_remove_cfs(). Fixes: ef1433f717a2 ("PCI: endpoint: Create configfs entry for each pci_epf_device_id table entry") Signed-off-by: Damien Le Moal <dlemoal@kernel.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Niklas Cassel <cassel@kernel.org> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20250624114544.342159-2-dlemoal@kernel.org
2025-06-26i2c: omap: Fix an error handling path in omap_i2c_probe()Christophe JAILLET1-2/+5
If an error occurs after calling mux_state_select(), mux_state_deselect() should be called as already done in the remove function. Fixes: b6ef830c60b6 ("i2c: omap: Add support for setting mux") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Cc: <stable@vger.kernel.org> # v6.15+ Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/998542981b6d2435c057dd8b9fe71743927babab.1749913149.git.christophe.jaillet@wanadoo.fr
2025-06-26PCI: dwc: Simplify the return value of PTM debugfs functions returning boolHans Zhang1-7/+7
Replace redundant ternary conditional expressions with direct boolean returns in PTM debugfs functions. Specifically change this pattern: return (condition) ? true : false; to the simpler: return condition; Signed-off-by: Hans Zhang <18255117159@163.com> [mani: subject rewording] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Niklas Cassel <cassel@kernel.org> Link: https://patch.msgid.link/20250612161226.950937-1-18255117159@163.com
2025-06-26platform/x86: Use i2c adapter name to fix build errorsPratap Nirujogi1-1/+2
Use adapater->name inplace of adapter->owner->name to fix build issues when CONFIG_MODULES is not defined. Fixes: 90b85567e457 ("platform/x86: Add AMD ISP platform config for OV05C10") Reported-by: Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/all/04577a46-9add-420c-b181-29bad582026d@infradead.org Tested-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Pratap Nirujogi <pratap.nirujogi@amd.com> Requires: 942e1aece13e ("i2c: designware: Initialize adapter name only when not set" Requires: c8dc57916973 ("i2c: amd-isp: Initialize unique adapter name") Acked-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20250609155601.1477055-4-pratap.nirujogi@amd.com
2025-06-26i2c: amd-isp: Initialize unique adapter namePratap Nirujogi1-0/+2
Initialize unique name for amdisp i2c adapter, which is used in the platform driver to detect the matching adapter for i2c_client creation. Add definition of amdisp i2c adapter name in a new header file (include/linux/soc/amd/isp4_misc.h) as it is referred in different driver modules. Tested-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Pratap Nirujogi <pratap.nirujogi@amd.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20250609155601.1477055-3-pratap.nirujogi@amd.com
2025-06-26i2c: designware: Initialize adapter name only when not setPratap Nirujogi1-2/+3
Check if the adapter name is already set in the driver prior to initializing with generic name in i2c_dw_probe_master(). This check allows to retain the unique adapter name driver has initialized, which platform driver can use to distinguish it from other i2c designware adapters. Tested-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Pratap Nirujogi <pratap.nirujogi@amd.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20250609155601.1477055-2-pratap.nirujogi@amd.com
2025-06-25i2c: tiny-usb: disable zero-length read messagesWolfram Sang1-0/+6
This driver passes the length of an i2c_msg directly to usb_control_msg(). If the message is now a read and of length 0, it violates the USB protocol and a warning will be printed. Enable the I2C_AQ_NO_ZERO_LEN_READ quirk for this adapter thus forbidding 0-length read messages altogether. Fixes: e8c76eed2ecd ("i2c: New i2c-tiny-usb bus driver") Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Cc: <stable@vger.kernel.org> # v2.6.22+ Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20250522064349.3823-2-wsa+renesas@sang-engineering.com
2025-06-25i2c: robotfuzz-osif: disable zero-length read messagesWolfram Sang1-0/+6
This driver passes the length of an i2c_msg directly to usb_control_msg(). If the message is now a read and of length 0, it violates the USB protocol and a warning will be printed. Enable the I2C_AQ_NO_ZERO_LEN_READ quirk for this adapter thus forbidding 0-length read messages altogether. Fixes: 83e53a8f120f ("i2c: Add bus driver for for OSIF USB i2c device.") Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Cc: <stable@vger.kernel.org> # v3.14+ Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20250522064234.3721-2-wsa+renesas@sang-engineering.com
2025-06-25i2c: imx: fix emulated smbus block readLukasz Kucharczyk1-1/+2
Acknowledge the byte count submitted by the target. When I2C_SMBUS_BLOCK_DATA read operation is executed by i2c_smbus_xfer_emulated(), the length of the second (read) message is set to 1. Length of the block is supposed to be obtained from the target by the underlying bus driver. The i2c_imx_isr_read() function should emit the acknowledge on i2c bus after reading the first byte (i.e., byte count) while processing such message (as defined in Section 6.5.7 of System Management Bus Specification [1]). Without this acknowledge, the target does not submit subsequent bytes and the controller only reads 0xff's. In addition, store the length of block data obtained from the target in the buffer provided by i2c_smbus_xfer_emulated() - otherwise the first byte of actual data is erroneously interpreted as length of the data block. [1] https://smbus.org/specs/SMBus_3_3_20240512.pdf Fixes: 5f5c2d4579ca ("i2c: imx: prevent rescheduling in non dma mode") Signed-off-by: Lukasz Kucharczyk <lukasz.kucharczyk@leica-geosystems.com> Cc: <stable@vger.kernel.org> # v6.13+ Acked-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Stefan Eichenberger <eichest@gmail.com> Reviewed-by: Carlos Song <carlos.song@nxp.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20250520122252.1475403-1-lukasz.kucharczyk@leica-geosystems.com
2025-06-25soc: qcom: mdt_loader: Fix error return values in mdt_header_valid()Dan Carpenter1-2/+2
This function is supposed to return true for valid headers and false for invalid. In a couple places it returns -EINVAL instead which means the invalid headers are counted as true. Change it to return false. Fixes: 9f9967fed9d0 ("soc: qcom: mdt_loader: Ensure we don't read past the ELF header") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/db57c01c-bdcc-4a0f-95db-b0f2784ea91f@sabinyo.mountain Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-06-25pinctrl: rp1: Implement RaspberryPi RP1 pinmux/pinconf supportAndrea della Porta1-5/+1044
The current implementation for the pin controller peripheral on the RP1 chipset supports gpio functionality and just the basic configuration of pin hw capabilities. Add support for selecting the pin alternate function (pinmux) and full configuration of the pin (pinconf). Related pins are also gathered into groups. Signed-off-by: Andrea della Porta <andrea.porta@suse.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/all/8c282b89b1aa8b9e3c00f6bd3980332c47d82df7.1750778806.git.andrea.porta@suse.com/ Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
2025-06-25cxl/edac: Fix using wrong repair type to check dram event recordLi Ming1-1/+1
cxl_find_rec_dram() is used to find a DRAM event record based on the inputted attributes. Different repair_type of the inputted attributes will check the DRAM event record in different ways. When EDAC driver is performing a memory rank sparing, it should use CXL_RANK_SPARING rather than CXL_BANK_SPARING as repair_type for DRAM event record checking. Fixes: 588ca944c277 ("cxl/edac: Add CXL memory device memory sparing control feature") Signed-off-by: Li Ming <ming.li@zohomail.com> Reviewed-by: Shiju Jose <shiju.jose@huawei.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Ira Weiny <ira.weiny@intel.com> Reviewed-by: Fan Ni <fan.ni@samsung.com> Link: https://patch.msgid.link/20250620052924.138892-1-ming.li@zohomail.com Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2025-06-25Merge tag 'spi-fix-v6.16-rc3' of ↵Linus Torvalds1-5/+7
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi Pull spi fix from Mark Brown: "One fix for a runtime PM underflow when removing the Cadence QuadSPI driver" * tag 'spi-fix-v6.16-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: spi: spi-cadence-quadspi: Fix pm runtime unbalance
2025-06-25Add few updates to the STM32 SPI driverMark Brown1-33/+279
Merge series from Clément Le Goffic <clement.legoffic@foss.st.com>: This series aims to improve the STM32 SPI driver in different areas. It adds SPI_READY mode, fixes an issue raised by a kernel bot, add the ability to use DMA-MDMA chaining for RX and deprecate an ST bindings vendor property.
2025-06-25Merge tag 'scsi-fixes' of ↵Linus Torvalds7-42/+161
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fixes from James Bottomley: "Fixes all in drivers. ufs and megaraid_sas are small and obvious. The large diffstat in fnic comes from two pieces: the addition of quite a bit of logging (no change to function) and the reworking of the timeout allocation path for the two conditions that can occur simultaneously to prevent reusing the same abort frame and then both trying to free it" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: fnic: Fix missing DMA mapping error in fnic_send_frame() scsi: fnic: Set appropriate logging level for log message scsi: fnic: Add and improve logs in FDMI and FDMI ABTS paths scsi: fnic: Turn off FDMI ACTIVE flags on link down scsi: fnic: Fix crash in fnic_wq_cmpl_handler when FDMI times out scsi: ufs: core: Fix clk scaling to be conditional in reset and restore scsi: megaraid_sas: Fix invalid node index
2025-06-25gpu: nova-core: replace `Duration` with `Delta`Alexandre Courbot4-16/+13
The kernel's `Delta` type was not available when the `wait_on` function was introduced. Now that it is, switch to it as it is more compact than `Duration` and cannot panic. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250624-nova-delta-v1-1-b37d75a593ac@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-25drm/nouveau/disp: Use dev->dev to get the deviceSakari Ailus1-1/+1
The local variable dev points to drm->dev already, use dev directly. Link: https://lore.kernel.org/r/20250409103344.3661603-1-sakari.ailus@linux.intel.com Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-25Merge tag 'wireless-next-2025-06-25' of ↵Jakub Kicinski259-1683/+4058
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Johannes Berg says: ==================== The usual features/cleanups/etc., notably: - rtw88: IBSS mode for SDIO devices - rtw89: - BT coex for MLO/WiFi7 - work on station + P2P concurrency - ath: fix W=2 export.h warnings - ath12k: fix scan on multi-radio devices - cfg80211/mac80211: MLO statistics - mac80211: S1G aggregation - cfg80211/mac80211: per-radio RTS threshold * tag 'wireless-next-2025-06-25' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (171 commits) wifi: iwlwifi: dvm: fix potential overflow in rs_fill_link_cmd() iwlwifi: Add missing check for alloc_ordered_workqueue wifi: iwlwifi: Fix memory leak in iwl_mvm_init() iwlwifi: api: delete repeated words iwlwifi: remove unused no_sleep_autoadjust declaration iwlwifi: Fix comment typo iwlwifi: use DECLARE_BITMAP macro iwlwifi: fw: simplify the iwl_fw_dbg_collect_trig() wifi: iwlwifi: mld: ftm: fix switch end indentation MAINTAINERS: update iwlwifi git link wifi: iwlwifi: pcie: fix non-MSIX handshake register wifi: iwlwifi: mld: don't exit EMLSR when we shouldn't wifi: iwlwifi: move _iwl_trans_set_bits_mask utilities wifi: iwlwifi: mld: make iwl_mld_add_all_rekeys void wifi: iwlwifi: move iwl_trans_pcie_write_mem to iwl-trans.c wifi: iwlwifi: pcie: move iwl_trans_pcie_dump_regs() to utils.c wifi: iwlwifi: mld: advertise support for TTLM changes wifi: iwlwifi: mld: Block EMLSR when scanning on P2P Device wifi: iwlwifi: mld: use the correct struct size for tracing wifi: iwlwifi: support RZL platform device ID ... ==================== Link: https://patch.msgid.link/20250625120135.41933-55-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-25Merge tag 'wireless-2025-06-25' of ↵Jakub Kicinski2-3/+4
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless Johannes Berg says: ==================== Just a few fixes: - iwlegacy: work around large stack with clang/kasan - mac80211: fix integer overflow - mac80211: fix link struct init vs. RCU publish - iwlwifi: fix warning on IFF_UP * tag 'wireless-2025-06-25' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless: wifi: mac80211: finish link init before RCU publish wifi: iwlwifi: mvm: assume '1' as the default mac_config_cmd version wifi: mac80211: fix beacon interval calculation overflow wifi: iwlegacy: work around excessive stack usage on clang/kasan ==================== Link: https://patch.msgid.link/20250625115433.41381-3-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-25drm/xe: Do not wedge device on killed exec queuesMatthew Brost1-4/+6
When a user closes an exec queue or interrupts an app with Ctrl-C, this does not warrant wedging the device in mode 2. Avoid this by skipping the wedge check for killed exec queues in the TDR and LR exec queue cleanup worker. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/20250624174103.2707941-1-matthew.brost@intel.com
2025-06-25samples: rust: platform: Add property child and reference args examplesRemo Senekowitsch2-0/+9
Add some example usage of the device property methods for reading DT/ACPI/swnode child nodes and reference args. Signed-off-by: Remo Senekowitsch <remo@buenzli.dev> Link: https://lore.kernel.org/r/20250616154511.1862909-4-remo@buenzli.dev [ Convert 'child@{0,1}' to 'child-{0,1}'; skip child nodes without 'compatible' property in of_unittest_platform_populate() as proposed by Rob Herring. - Danilo] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-25ASoC: Standardize ASoC menuMark Brown335-1479/+3401
Merge series from Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>: Current Kconfig menu at [ALSA for SoC audio support] has no rules. So, some venders are using menu style, some venders are listed each drivers on top page, etc. It is difficult to find target vender and/or drivers because it is very random. Let's standardize ASoC menu, like below --- ALSA for SoC audio support Analog Devices ---> AMD ---> Apple ---> Atmel ---> Au1x ---- Broadcom ---> Cirrus Logic ---> DesignWare ---> Freescale ---> Google ---> Hisilicon ---> ... One concern is *vender folder* alphabetical order vs *vender name* alphabetical order were different. For example "sunxi" menu is "Allwinner". Link: https://lore.kernel.org/r/8734c8bf3l.wl-kuninori.morimoto.gx@renesas.com
2025-06-25drm/bridge: ti-sn65dsi86: Add HPD for DisplayPort connector typeJayesh Choudhary1-9/+60
By default, HPD was disabled on SN65DSI86 bridge. When the driver was added (commit "a095f15c00e27"), the HPD_DISABLE bit was set in pre-enable call which was moved to other function calls subsequently. Later on, commit "c312b0df3b13" added detect utility for DP mode. But with HPD_DISABLE bit set, all the HPD events are disabled[0] and the debounced state always return 1 (always connected state). Set HPD_DISABLE bit conditionally based on display sink's connector type. Since the HPD_STATE is reflected correctly only after waiting for debounce time (~100-400ms) and adding this delay in detect() is not feasible owing to the performace impact (glitches and frame drop), remove runtime calls in detect() and add hpd_enable()/disable() bridge hooks with runtime calls, to detect hpd properly without any delay. [0]: <https://www.ti.com/lit/gpn/SN65DSI86> (Pg. 32) Fixes: c312b0df3b13 ("drm/bridge: ti-sn65dsi86: Implement bridge connector operations for DP") Cc: Max Krummenacher <max.krummenacher@toradex.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Tested-by: Ernest Van Hoecke <ernest.vanhoecke@toradex.com> Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20250624044835.165708-1-j-choudhary@ti.com
2025-06-25EDAC/amd64: Fix size calculation for Non-Power-of-Two DIMMsAvadhut Naik1-21/+36
Each Chip-Select (CS) of a Unified Memory Controller (UMC) on AMD Zen-based SOCs has an Address Mask and a Secondary Address Mask register associated with it. The amd64_edac module logs DIMM sizes on a per-UMC per-CS granularity during init using these two registers. Currently, the module primarily considers only the Address Mask register for computing DIMM sizes. The Secondary Address Mask register is only considered for odd CS. Additionally, if it has been considered, the Address Mask register is ignored altogether for that CS. For power-of-two DIMMs i.e. DIMMs whose total capacity is a power of two (32GB, 64GB, etc), this is not an issue since only the Address Mask register is used. For non-power-of-two DIMMs i.e., DIMMs whose total capacity is not a power of two (48GB, 96GB, etc), however, the Secondary Address Mask register is used in conjunction with the Address Mask register. However, since the module only considers either of the two registers for a CS, the size computed by the module is incorrect. The Secondary Address Mask register is not considered for even CS, and the Address Mask register is not considered for odd CS. Introduce a new helper function so that both Address Mask and Secondary Address Mask registers are considered, when valid, for computing DIMM sizes. Furthermore, also rename some variables for greater clarity. Fixes: 81f5090db843 ("EDAC/amd64: Support asymmetric dual-rank DIMMs") Closes: https://lore.kernel.org/dbec22b6-00f2-498b-b70d-ab6f8a5ec87e@natrix.lt Reported-by: Žilvinas Žaltiena <zilvinas@natrix.lt> Signed-off-by: Avadhut Naik <avadhut.naik@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Yazen Ghannam <yazen.ghannam@amd.com> Tested-by: Žilvinas Žaltiena <zilvinas@natrix.lt> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/20250529205013.403450-1-avadhut.naik@amd.com
2025-06-25Revert "drm/xe/ptl: Apply Wa_16026007364"Daniele Ceraolo Spurio3-7/+0
This reverts commit 3972872e459d812ab5e481a231a6066cf4f4d0f4. There are several things wrong with the way this WA was implemented: - The KLV is only supported on GuC 70.47.0 or newer, so we shouldn't apply it unconditionally. - The KLV requires 2 DWs of data, which are not currently provided. The GuC currently ignores any unknown KLVs, so on versions older that 70.47.0 nothing happens. However, starting on 70.47.0 the GuC attempts to parse the KLV and fails due to the missing data, causing a GuC load abort. Given that 70.47.0 is the first GuC version approved for public release for PTL, let's revert this patch so it doesn't cause the GuC load to fail with that blob. We can then re-apply it properly fixed after the GuC definition is merged, which will also have the added benefit of running the KLV addition through CI with the right GuC version. Fixes: 3972872e459d ("drm/xe/ptl: Apply Wa_16026007364") Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: sanirban <sk.anirban@intel.com> Cc: Badal Nilawar <badal.nilawar@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/20250625001202.1616606-2-daniele.ceraolospurio@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-06-25pinctrl: samsung: add support for gs101 wakeup mask programmingPeter Griffin2-14/+90
gs101 differs to other currently supported SoCs in that it has 3 wakeup mask registers for the 67 external wakeup interrupt pins in alive and far_alive. EINT_WAKEUP_MASK 0x3A80 EINT[31:0] EINT_WAKEUP_MASK2 0x3A84 EINT[63:32] EINT_WAKEUP_MASK3 0x3A88 EINT[66:64] Add gs101 specific callbacks and a dedicated gs101_wkup_irq_chip struct to handle these differences. The current wakeup mask with upstream is programmed as WAKEUP_MASK0[0x3A80] value[0xFFFFFFFF] WAKEUP_MASK1[0x3A84] value[0xF2FFEFFF] WAKEUP_MASK2[0x3A88] value[0xFFFFFFFF] Which corresponds to the following wakeup sources: gpa7-3 vol down gpa8-1 vol up gpa10-1 power gpa8-2 typec-int Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Link: https://lore.kernel.org/r/20250619-gs101-eint-mask-v1-2-89438cfd7499@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2025-06-25pinctrl: samsung: rename exynosautov920_retention_data to no_retention_dataPeter Griffin1-2/+4
To avoid having an exact copy of this struct for gs101 rename it and use it for both SoCs for eint banks. The purpose of this for exynosautov920 and gs101 is to obtain the PMU syscon for writing the calculated WAKEUP_MASK register(s). Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Link: https://lore.kernel.org/r/20250619-gs101-eint-mask-v1-1-89438cfd7499@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2025-06-25soc: mediatek: mtk-mutex: Fix confusing usage of MUTEX_MOD2Jason-JH Lin1-53/+56
The usage of MUTEX_MOD1 and MUTEX_MOD2 for calculating mod settings over 32 has been confusing. To improve consistency and clarity, these defines need to fit into the same MUTEX_MOD define as possible. However, MUTEX_MOD1 cannot be directly used for all SoCs because, for example, the mod1 register (0x34) of MT2712 is not adjacent to its mod0 register (0x2c). To address this, a `mutex_mod1_reg` field is introduced in the mutex driver data structure. This allows all SoCs to use a unified MUTEX_MOD to determine their register offsets. With this change, the separate usage of MUTEX_MOD1 and MUTEX_MOD2 is eliminated, simplifying the logic for obtaining offsets and mod IDs. Signed-off-by: Jason-JH Lin <jason-jh.lin@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20250624103928.408194-1-jason-jh.lin@mediatek.com Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2025-06-25PCI: Move link up wait time and max retries macros to pci.hNiklas Cassel3-7/+7
Move the LINK_WAIT_SLEEP_MS and LINK_WAIT_MAX_RETRIES macros to pci.h. Prefix the macros with PCIE_ in order to avoid redefining these for drivers that already have macros named like this. No functional changes. Suggested-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20250625102347.1205584-15-cassel@kernel.org
2025-06-25PCI: dwc: Ensure that dw_pcie_wait_for_link() waits 100 ms after link upNiklas Cassel1-0/+8
As per PCIe r6.0, sec 6.6.1, a Downstream Port that supports Link speeds greater than 5.0 GT/s, software must wait a minimum of 100 ms after Link training completes before sending a Configuration Request. Add this delay in dw_pcie_wait_for_link(), after the link is reported as up. The delay will only be performed in the success case where the link came up. DWC glue drivers that have a link up IRQ (drivers that set use_linkup_irq = true) do not call dw_pcie_wait_for_link(), instead they perform this delay in their threaded link up IRQ handler. Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Reviewed-by: Wilfred Mallawa <wilfred.mallawa@wdc.com> Link: https://patch.msgid.link/20250625102347.1205584-14-cassel@kernel.org
2025-06-25PCI: qcom: Wait PCIE_RESET_CONFIG_WAIT_MS after link-up IRQNiklas Cassel1-0/+1
Per PCIe r6.0, sec 6.6.1, software must generally wait a minimum of 100ms (PCIE_RESET_CONFIG_WAIT_MS) after Link training completes before sending a Configuration Request. Prior to 36971d6c5a9a ("PCI: qcom: Don't wait for link if we can detect Link Up"), qcom used dw_pcie_wait_for_link(), which waited between 0 and 90ms after the link came up before we enumerate the bus, and this was apparently enough for most devices. After 36971d6c5a9a, qcom_pcie_global_irq_thread() started enumeration immediately when handling the link-up IRQ, and devices (e.g., Laszlo Fiat's PLEXTOR PX-256M8PeGN NVMe SSD) may not be ready to handle config requests yet. Delay PCIE_RESET_CONFIG_WAIT_MS after the link-up IRQ before starting enumeration. Fixes: 82a823833f4e ("PCI: qcom: Add Qualcomm PCIe controller driver") Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Reviewed-by: Wilfred Mallawa <wilfred.mallawa@wdc.com> Link: https://patch.msgid.link/20250625102347.1205584-13-cassel@kernel.org
2025-06-25PCI: dw-rockchip: Wait PCIE_RESET_CONFIG_WAIT_MS after link-up IRQNiklas Cassel1-0/+1
Per PCIe r6.0, sec 6.6.1, software must generally wait a minimum of 100ms (PCIE_RESET_CONFIG_WAIT_MS) after Link training completes before sending a Configuration Request. Prior to ec9fd499b9c6 ("PCI: dw-rockchip: Don't wait for link since we can detect Link Up"), dw-rockchip used dw_pcie_wait_for_link(), which waited between 0 and 90ms after the link came up before we enumerate the bus, and this was apparently enough for most devices. After ec9fd499b9c6, rockchip_pcie_rc_sys_irq_thread() started enumeration immediately when handling the link-up IRQ, and devices (e.g., Laszlo Fiat's PLEXTOR PX-256M8PeGN NVMe SSD) may not be ready to handle config requests yet. Delay PCIE_RESET_CONFIG_WAIT_MS after the link-up IRQ before starting enumeration. Fixes: 0e898eb8df4e ("PCI: rockchip-dwc: Add Rockchip RK356X host controller driver") Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Reviewed-by: Wilfred Mallawa <wilfred.mallawa@wdc.com> Cc: Laszlo Fiat <laszlo.fiat@proton.me> Link: https://patch.msgid.link/20250625102347.1205584-12-cassel@kernel.org
2025-06-25clk: sunxi-ng: sun55i-a523-r-ccu: Add missing PPU0 resetChen-Yu Tsai1-0/+1
There is a PPU0 reset control bit in the same register as the PPU1 reset control. This missing reset control is for the PCK-600 unit in the SoC. Manual tests show that the reset control indeed exists, and if not configured, the system will hang when the PCK-600 registers are accessed. Add a reset entry for it at the end of the existing ones. Fixes: 8cea339cfb81 ("clk: sunxi-ng: add support for the A523/T527 PRCM CCU") Reviewed-by: Andre Przywara <andre.przywara@arm.com> Acked-by: Stephen Boyd <sboyd@kernel.org> Link: https://patch.msgid.link/20250619171025.3359384-3-wens@kernel.org Signed-off-by: Chen-Yu Tsai <wens@csie.org>
2025-06-25PCI: rockchip-host: Use macro PCIE_RESET_CONFIG_WAIT_MSNiklas Cassel2-8/+1
Macro PCIE_RESET_CONFIG_DEVICE_WAIT_MS was added to pci.h in commit d5ceb9496c56 ("PCI: Add PCIE_RESET_CONFIG_DEVICE_WAIT_MS waiting time value"). Later, in commit 70a7bfb1e515 ("PCI: rockchip-host: Wait 100ms after reset before starting configuration"), PCIE_T_RRS_READY_MS was added to pci.h. These macros are duplicates, and represent the exact same delay in the PCIe specification. Since the comment above PCIE_RESET_CONFIG_WAIT_MS is strictly more correct than the comment above PCIE_T_RRS_READY_MS, change rockchip-host to use PCIE_RESET_CONFIG_WAIT_MS, and remove PCIE_T_RRS_READY_MS, as rockchip-host is the only user of this macro. Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Wilfred Mallawa <wilfred.mallawa@wdc.com> Link: https://patch.msgid.link/20250625102347.1205584-11-cassel@kernel.org
2025-06-25PCI: Rename PCIE_RESET_CONFIG_DEVICE_WAIT_MS to PCIE_RESET_CONFIG_WAIT_MSNiklas Cassel2-2/+2
Rename PCIE_RESET_CONFIG_DEVICE_WAIT_MS to PCIE_RESET_CONFIG_WAIT_MS. Suggested-by: Bjorn Helgaas <helgaas@kernel.org> Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20250625102347.1205584-10-cassel@kernel.org
2025-06-25ata: ahci: Use correct DMI identifier for ASUSPRO-D840SA LPM quirkNiklas Cassel1-1/+1
ASUS store the board name in DMI_PRODUCT_NAME rather than DMI_PRODUCT_VERSION. (Apparently it is only Lenovo that stores the model-name in DMI_PRODUCT_VERSION.) Use the correct DMI identifier, DMI_PRODUCT_NAME, to match the ASUSPRO-D840SA board, such that the quirk actually gets applied. Cc: stable@vger.kernel.org Reported-by: Andy Yang <andyybtc79@gmail.com> Tested-by: Andy Yang <andyybtc79@gmail.com> Closes: https://lore.kernel.org/linux-ide/aFb3wXAwJSSJUB7o@ryzen/ Fixes: b5acc3628898 ("ata: ahci: Disallow LPM for ASUSPRO-D840SA motherboard") Reviewed-by: Hans de Goede <hansg@kernel.org> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Link: https://lore.kernel.org/r/20250624074029.963028-2-cassel@kernel.org Signed-off-by: Niklas Cassel <cassel@kernel.org>
2025-06-25mmc: Merge branch fixes into nextUlf Hansson1-0/+1
Merge the mmc fixes for v6.16-rc[n] into the next branch, to allow them to get tested together with the new mmc changes that are targeted for v6.17. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2025-06-25mtk-sd: reset host->mrq on prepare_data() errorSergey Senozhatsky1-0/+1
Do not leave host with dangling ->mrq pointer if we hit the msdc_prepare_data() error out path. Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org> Reviewed-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Fixes: f5de469990f1 ("mtk-sd: Prevent memory corruption from DMA map failure") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250625052106.584905-1-senozhatsky@chromium.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
generated by cgit v1.2.3 (git 2.39.0) at 2026-06-05 14:31:28 +0300