summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2025-08-19EDAC/skx_common: Remove redundant upper bound check for res->imcQiuxu Zhuo
The following upper bound check for the memory controller physical index decoded by ADXL is the only place where use the macro 'NUM_IMC' is used: res->imc > NUM_IMC - 1 Since this check is already covered by skx_get_mc_mapping(), meaning no memory controller logical index exists for an invalid memory controller physical index decoded by ADXL, remove the redundant upper bound check so that the definition for 'NUM_IMC' can be cleaned up (in another patch). Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com> Link: https://lore.kernel.org/r/20250731145534.2759334-6-qiuxu.zhuo@intel.com
2025-08-19EDAC/skx_common: Make skx_dev->imc[] a flexible arrayQiuxu Zhuo
The current skx->imc[NUM_IMC] array of memory controller instances is sized using the macro NUM_IMC. Each time EDAC support is added for a new CPU, NUM_IMC needs to be updated to ensure it is greater than or equal to the number of memory controllers for the new CPU. This approach is inconvenient and results in memory waste for older CPUs with fewer memory controllers. To address this, make skx->imc[] a flexible array and determine its size from configuration data or at runtime. Suggested-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com> Link: https://lore.kernel.org/r/20250731145534.2759334-5-qiuxu.zhuo@intel.com
2025-08-19EDAC/skx_common: Swap memory controller index mappingQiuxu Zhuo
The current mapping of memory controller indices is from physical index [1] to logical index [2], as show below: skx_dev->imc[pmc].mc_mapping = lmc Since skx_dev->imc[] is an array of present memory controller instances, mapping memory controller indices from logical index to physical index, as show below, is more reasonable. This is also a preparatory step for making skx_dev->imc[] a flexible array. skx_dev->imc[lmc].mc_mapping = pmc Both mappings are equivalent. No functional changes intended. [1] Indices for memory controllers include both those present to the OS and those disabled by BIOS. [2] Indices for memory controllers present to the OS. Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com> Link: https://lore.kernel.org/r/20250731145534.2759334-4-qiuxu.zhuo@intel.com
2025-08-19EDAC/skx_common: Move mc_mapping to be a field inside struct skx_imcQiuxu Zhuo
The mc_mapping and imc fields of struct skx_dev have the same size, NUM_IMC. Move mc_mapping to be a field inside struct skx_imc to prepare for making the imc array of memory controller instances a flexible array. No functional changes intended. Suggested-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com> Link: https://lore.kernel.org/r/20250731145534.2759334-3-qiuxu.zhuo@intel.com
2025-08-19EDAC/{skx_common,skx}: Use configuration data, not global macrosQiuxu Zhuo
Use model-specific configuration data for the number of memory controllers per socket, channels per memory controller, and DIMMs per channel as intended, instead of relying on global macros for maximum values. No functional changes intended. Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com> Link: https://lore.kernel.org/r/20250731145534.2759334-2-qiuxu.zhuo@intel.com
2025-08-19EDAC/i10nm: Skip DIMM enumeration on a disabled memory controllerQiuxu Zhuo
When loading the i10nm_edac driver on some Intel Granite Rapids servers, a call trace may appear as follows: UBSAN: shift-out-of-bounds in drivers/edac/skx_common.c:453:16 shift exponent -66 is negative ... __ubsan_handle_shift_out_of_bounds+0x1e3/0x390 skx_get_dimm_info.cold+0x47/0xd40 [skx_edac_common] i10nm_get_dimm_config+0x23e/0x390 [i10nm_edac] skx_register_mci+0x159/0x220 [skx_edac_common] i10nm_init+0xcb0/0x1ff0 [i10nm_edac] ... This occurs because some BIOS may disable a memory controller if there aren't any memory DIMMs populated on this memory controller. The DIMMMTR register of this disabled memory controller contains the invalid value ~0, resulting in the call trace above. Fix this call trace by skipping DIMM enumeration on a disabled memory controller. Fixes: ba987eaaabf9 ("EDAC/i10nm: Add Intel Granite Rapids server support") Reported-by: Jose Jesus Ambriz Meza <jose.jesus.ambriz.meza@intel.com> Reported-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com> Closes: https://lore.kernel.org/all/20250730063155.2612379-1-acelan.kao@canonical.com/ Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com> Tested-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com> Link: https://lore.kernel.org/r/20250806065707.3533345-1-qiuxu.zhuo@intel.com
2025-08-19i2c: rtl9300: Add missing count byte for SMBus Block OpsSven Eckelmann
The expected on-wire format of an SMBus Block Write is S Addr Wr [A] Comm [A] Count [A] Data [A] Data [A] ... [A] Data [A] P Everything starting from the Count byte is provided by the I2C subsystem in the array data->block. But the driver was skipping the Count byte (data->block[0]) when sending it to the RTL93xx I2C controller. Only the actual data could be seen on the wire: S Addr Wr [A] Comm [A] Data [A] Data [A] ... [A] Data [A] P This wire format is not SMBus Block Write compatible but matches the format of an I2C Block Write. Simply adding the count byte to the buffer for the I2C controller is enough to fix the transmission. This also affects read because the I2C controller must receive the count byte + $count * data bytes. Fixes: c366be720235 ("i2c: Add driver for the RTL9300 I2C controller") Signed-off-by: Sven Eckelmann <sven@narfation.org> Cc: <stable@vger.kernel.org> # v6.13+ Reviewed-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Tested-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20250810-i2c-rtl9300-multi-byte-v5-4-cd9dca0db722@narfation.org
2025-08-19i2c: rtl9300: Increase timeout for transfer pollingSven Eckelmann
The timeout for transfers was only set to 2ms. Because of this relatively low limit, 12-byte read operations to the frontend MCU of a RTL8239 POE PSE chip cluster was consistently resulting in a timeout. The original OpenWrt downstream driver [1] was not using any timeout limit at all. This is also possible by setting the timeout_us parameter of regmap_read_poll_timeout() to 0. But since the driver currently implements the ETIMEDOUT error, it is more sensible to increase the timeout in such a way that communication with the (quite common) Realtek I2C-connected POE management solution is possible. [1] https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/realtek/files-6.12/drivers/i2c/busses/i2c-rtl9300.c;h=c4d973195ef39dc56d6207e665d279745525fcac#l202 Fixes: c366be720235 ("i2c: Add driver for the RTL9300 I2C controller") Signed-off-by: Sven Eckelmann <sven@narfation.org> Cc: <stable@vger.kernel.org> # v6.13+ Reviewed-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Tested-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20250810-i2c-rtl9300-multi-byte-v5-3-cd9dca0db722@narfation.org
2025-08-19i2c: rtl9300: Fix multi-byte I2C writeHarshal Gohel
The RTL93xx I2C controller has 4 32 bit registers to store the bytes for the upcoming I2C transmission. The first byte is stored in the least-significant byte of the first register. And the last byte in the most significant byte of the last register. A map of the transferred bytes to their order in the registers is: reg 0: 0x04_03_02_01 reg 1: 0x08_07_06_05 reg 2: 0x0c_0b_0a_09 reg 3: 0x10_0f_0e_0d The i2c_read() function basically demonstrates how the hardware would pick up bytes from this register set. But the i2c_write() function was just pushing bytes one after another to the least significant byte of a register AFTER shifting the last one to the next more significant byte position. If you would then have tried to send a buffer with numbers 1-11 using i2c_write(), you would have ended up with following register content: reg 0: 0x01_02_03_04 reg 1: 0x05_06_07_08 reg 2: 0x00_09_0a_0b reg 3: 0x00_00_00_00 On the wire, you would then have seen: Sr Addr Wr [A] 04 A 03 A 02 A 01 A 08 A 07 A 06 A 05 A 0b A 0a A 09 A P But the correct data transmission was expected to be Sr Addr Wr [A] 01 A 02 A 03 A 04 A 05 A 06 A 07 A 08 A 09 A 0a A 0b A P Because of this multi-byte ordering problem, only single byte i2c_write() operations were executed correctly (on the wire). By shifting the byte directly to the correct end position in the register, it is possible to avoid this incorrect byte ordering and fix multi-byte transmissions. The second initialization (to 0) of vals was also be dropped because this array is initialized to 0 on the stack by using `= {};`. This makes the fix a lot more readable. Fixes: c366be720235 ("i2c: Add driver for the RTL9300 I2C controller") Signed-off-by: Harshal Gohel <hg@simonwunderlich.de> Cc: <stable@vger.kernel.org> # v6.13+ Co-developed-by: Sven Eckelmann <sven@narfation.org> Signed-off-by: Sven Eckelmann <sven@narfation.org> Reviewed-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Tested-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20250810-i2c-rtl9300-multi-byte-v5-2-cd9dca0db722@narfation.org
2025-08-19i2c: rtl9300: Fix out-of-bounds bug in rtl9300_i2c_smbus_xferAlex Guo
The data->block[0] variable comes from user. Without proper check, the variable may be very large to cause an out-of-bounds bug. Fix this bug by checking the value of data->block[0] first. 1. commit 39244cc75482 ("i2c: ismt: Fix an out-of-bounds bug in ismt_access()") 2. commit 92fbb6d1296f ("i2c: xgene-slimpro: Fix out-of-bounds bug in xgene_slimpro_i2c_xfer()") Fixes: c366be720235 ("i2c: Add driver for the RTL9300 I2C controller") Signed-off-by: Alex Guo <alexguo1023@gmail.com> Cc: <stable@vger.kernel.org> # v6.13+ Reviewed-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Tested-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Sven Eckelmann <sven@narfation.org> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20250810-i2c-rtl9300-multi-byte-v5-1-cd9dca0db722@narfation.org
2025-08-19EDAC/ie31200: Add two more Intel Alder Lake-S SoCs for EDAC supportKyle Manna
Host Device IDs (DID0) correspond to: * Intel Core i7-12700K * Intel Core i5-12600K See documentation: * 12th Generation Intel® Core™ Processors Datasheet * Volume 1 of 2, Doc. No.: 655258, Rev.: 011 * https://edc.intel.com/output/DownloadPdfDocument?id=8297 (PDF) Signed-off-by: Kyle Manna <kyle@kylemanna.com> Signed-off-by: Tony Luck <tony.luck@intel.com> Reviewed-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Link: https://lore.kernel.org/r/20250819161739.3241152-1-kyle@kylemanna.com
2025-08-19thermal: intel: int340x: Remove redundant acpi_has_method() callSalah Triki
acpi_evaluate_object() returns an error if the needed method does not exist, so remove an unnecessary acpi_has_method() call preceding it. Signed-off-by: Salah Triki <salah.triki@gmail.com> Link: https://patch.msgid.link/aIMQ9RFciI8jmmAh@pc [ rjw: Subject adjustment ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-08-19cpufreq: Avoid calling get_governor() for first policyZihuan Zhang
When a cpufreq driver registers the first policy, it may attempt to initialize the policy governor from `last_governor`. However, this is meaningless for the first policy instance, because `last_governor` is only updated when policies are removed (e.g. during CPU offline). The `last_governor` mechanism is intended to restore the previously used governor across CPU hotplug events. For the very first policy, there is no "previous governor" to restore, so calling get_governor(last_governor) is unnecessary and potentially confusing. Skip looking up `last_governor` when registering the first policy. Instead, it directly uses the default governor after all governors have been registered and are available. This avoids meaningless lookups, reduces unnecessary module reference handling, and simplifies the initial policy path. Signed-off-by: Zihuan Zhang <zhangzihuan@kylinos.cn> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Lifeng Zheng <zhenglifeng1@huawei.com> Link: https://patch.msgid.link/20250725041450.68754-1-zhangzihuan@kylinos.cn [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-08-19spi: Remove the use of dev_err_probe()Mark Brown
Merge series from Xichao Zhao <zhao.xichao@vivo.com>: The dev_err_probe() doesn't do anything when error is '-ENOMEM'. Therefore, remove the useless call to dev_err_probe(), and just return the value instead.
2025-08-19Merge tag 'vfs-6.17-rc3.fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs Pull vfs fixes from Christian Brauner: - Fix two memory leaks in pidfs - Prevent changing the idmapping of an already idmapped mount without OPEN_TREE_CLONE through open_tree_attr() - Don't fail listing extended attributes in kernfs when no extended attributes are set - Fix the return value in coredump_parse() - Fix the error handling for unbuffered writes in netfs - Fix broken data integrity guarantees for O_SYNC writes via iomap - Fix UAF in __mark_inode_dirty() - Keep inode->i_blkbits constant in fuse - Fix coredump selftests - Fix get_unused_fd_flags() usage in do_handle_open() - Rename EXPORT_SYMBOL_GPL_FOR_MODULES to EXPORT_SYMBOL_FOR_MODULES - Fix use-after-free in bh_read() - Fix incorrect lflags value in the move_mount() syscall * tag 'vfs-6.17-rc3.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs: signal: Fix memory leak for PIDFD_SELF* sentinels kernfs: don't fail listing extended attributes coredump: Fix return value in coredump_parse() fs/buffer: fix use-after-free when call bh_read() helper pidfs: Fix memory leak in pidfd_info() netfs: Fix unbuffered write error handling fhandle: do_handle_open() should get FD with user flags module: Rename EXPORT_SYMBOL_GPL_FOR_MODULES to EXPORT_SYMBOL_FOR_MODULES fs: fix incorrect lflags value in the move_mount syscall selftests/coredump: Remove the read() that fails the test fuse: keep inode->i_blkbits constant iomap: Fix broken data integrity guarantees for O_SYNC writes selftests/mount_setattr: add smoke tests for open_tree_attr(2) bug open_tree_attr: do not allow id-mapping changes without OPEN_TREE_CLONE fs: writeback: fix use-after-free in __mark_inode_dirty()
2025-08-19regulator: rt5133: Fix IS_ERR() vs NULL bug in rt5133_validate_vendor_info()Dan Carpenter
The "priv->cdata" pointer isn't an error pointer; this should be a NULL check instead. Otherwise it leads to a NULL pointer dereference in the caller, rt5133_probe(). Fixes: 714165e1c4b0 ("regulator: rt5133: Add RT5133 PMIC regulator Support") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://patch.msgid.link/aKMc1oK-7yY4cD3K@stanley.mountain Signed-off-by: Mark Brown <broonie@kernel.org>
2025-08-19regulator: tps65219: regulator: tps65219: Fix error codes in probe()Dan Carpenter
There is a copy and paste error and we accidentally use "PTR_ERR(rdev)" instead of "error". The "rdev" pointer is valid at this point. Also there is no need to print the error code in the error message because dev_err_probe() already prints that. So clean up the error message a bit. Fixes: 38c9f98db20a ("regulator: tps65219: Add support for TPS65215 Regulator IRQs") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://patch.msgid.link/aKRGmVdbvT1HBvm8@stanley.mountain Signed-off-by: Mark Brown <broonie@kernel.org>
2025-08-19PCI: mediatek-gen3: Add support for MediaTek MT8196 SoCAngeloGioacchino Del Regno
Introduce support for the PCI-Express Gen3 controller found in the MT8196 (and MT6991) SoC by adding a compatible string and platform specific data. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20250703120847.121826-4-angelogioacchino.delregno@collabora.com
2025-08-19PCI: mediatek-gen3: Implement sys clock ready time settingAngeloGioacchino Del Regno
In preparation to add support for the PCI-Express Gen3 controller found in newer MediaTek SoCs, such as the Dimensity 9400 MT6991 and the MT8196 Chromebook SoC, add the definition for the PCIE Resource Control register and a new sys_clk_rdy_time_us variable in platform data. If sys_clk_rdy_time_us is found (> 0), set the new value in the aforementioned register only after configuring the controller to RC mode, as this may otherwise be reset. Overriding the register defaults for SYS_CLK_RDY_TIME allows to work around sys_clk_rdy signal glitching in MT6991 and MT8196. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> [mani: used FIELD_MODIFY() to simplify mask and update] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20250703120847.121826-2-angelogioacchino.delregno@collabora.com
2025-08-19drm/xe: Assign ioctl xe file handler to vm in xe_vm_createPiotr Piórkowski
In several code paths, such as xe_pt_create(), the vm->xef field is used to determine whether a VM originates from userspace or the kernel. Previously, this handler was only assigned in xe_vm_create_ioctl(), after the VM was created by xe_vm_create(). However, xe_vm_create() triggers page table creation, and that function assumes vm->xef should be already set. This could lead to incorrect origin detection. To fix this problem and ensure consistency in the initialization of the VM object, let's move the assignment of this handler to xe_vm_create. v2: - take reference to the xe file object only when xef is not NULL - release the reference to the xe file object on the error path (Matthew) Fixes: 7f387e6012b6 ("drm/xe: add XE_BO_FLAG_PINNED_LATE_RESTORE") Signed-off-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://lore.kernel.org/r/20250811104358.2064150-2-piotr.piorkowski@intel.com Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> (cherry picked from commit 9337166fa1d80f7bb7c7d3a8f901f21c348c0f2a) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-08-19usb: xhci: fix host not responding after suspend and resumeNiklas Neronin
Partially revert commit e1db856bd288 ("usb: xhci: remove '0' write to write-1-to-clear register") because the patch cleared the Interrupt Pending bit during interrupt enabling and disabling. The Interrupt Pending bit should only be cleared when the driver has handled the interrupt. Ideally, all interrupts should be handled before disabling the interrupt; consequently, no interrupt should be pending when enabling the interrupt. For this reason, keep the debug message informing if an interrupt is still pending when an interrupt is disabled. Because the Interrupt Pending bit is write-1-to-clear, writing '0' to it ensures that the state does not change. Link: https://lore.kernel.org/linux-usb/20250818231103.672ec7ed@foxbook Fixes: e1db856bd288 ("usb: xhci: remove '0' write to write-1-to-clear register") Closes: https://bbs.archlinux.org/viewtopic.php?id=307641 cc: stable@vger.kernel.org # 6.16+ Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250819125844.2042452-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-08-19usb: xhci: Fix slot_id resource race conflictWeitao Wang
xHC controller may immediately reuse a slot_id after it's disabled, giving it to a new enumerating device before the xhci driver freed all resources related to the disabled device. In such a scenario, device-A with slot_id equal to 1 is disconnecting while device-B is enumerating, device-B will fail to enumerate in the follow sequence. 1.[device-A] send disable slot command 2.[device-B] send enable slot command 3.[device-A] disable slot command completed and wakeup waiting thread 4.[device-B] enable slot command completed with slot_id equal to 1 and wakeup waiting thread 5.[device-B] driver checks that slot_id is still in use (by device-A) in xhci_alloc_virt_device, and fail to enumerate due to this conflict 6.[device-A] xhci->devs[slot_id] set to NULL in xhci_free_virt_device To fix driver's slot_id resources conflict, clear xhci->devs[slot_id] and xhci->dcbba->dev_context_ptrs[slot_id] pointers in the interrupt context when disable slot command completes successfully. Simultaneously, adjust function xhci_free_virt_device to accurately handle device release. [minor smatch warning and commit message fix -Mathias] Cc: stable@vger.kernel.org Fixes: 7faac1953ed1 ("xhci: avoid race between disable slot command and host runtime suspend") Signed-off-by: Weitao Wang <WeitaoWang-oc@zhaoxin.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250819125844.2042452-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-08-19net: ethernet: stmmac: dwmac-rk: Make the clk_phy could be used for external phyChaoyi Chen
For external phy, clk_phy should be optional, and some external phy need the clock input from clk_phy. This patch adds support for setting clk_phy for external phy. Signed-off-by: David Wu <david.wu@rock-chips.com> Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com> Link: https://patch.msgid.link/20250815023515.114-1-kernel@airkyi.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-08-19pinctrl: sx150x: Make the driver tristateFange Zhang
Set PINCTRL_SX150X config option as a tristate and add MODULE_DEVICE_TABLE()/MODULE_LICENSE() to export appropriate information. Signed-off-by: Fange Zhang <fange.zhang@oss.qualcomm.com> Link: https://lore.kernel.org/20250818-modularize-sx150x-gpio-expander-v1-1-c2a027200fed@oss.qualcomm.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2025-08-19net: mana: Use page pool fragments for RX buffers instead of full pages to ↵Dipayaan Roy
improve memory efficiency. This patch enhances RX buffer handling in the mana driver by allocating pages from a page pool and slicing them into MTU-sized fragments, rather than dedicating a full page per packet. This approach is especially beneficial on systems with large base page sizes like 64KB. Key improvements: - Proper integration of page pool for RX buffer allocations. - MTU-sized buffer slicing to improve memory utilization. - Reduce overall per Rx queue memory footprint. - Automatic fallback to full-page buffers when: * Jumbo frames are enabled (MTU > PAGE_SIZE / 2). * The XDP path is active, to avoid complexities with fragment reuse. Testing on VMs with 64KB pages shows around 200% throughput improvement. Memory efficiency is significantly improved due to reduced wastage in page allocations. Example: We are now able to fit 35 rx buffers in a single 64kb page for MTU size of 1500, instead of 1 rx buffer per page previously. Tested: - iperf3, iperf2, and nttcp benchmarks. - Jumbo frames with MTU 9000. - Native XDP programs (XDP_PASS, XDP_DROP, XDP_TX, XDP_REDIRECT) for testing the XDP path in driver. - Memory leak detection (kmemleak). - Driver load/unload, reboot, and stress scenarios. Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Saurabh Sengar <ssengar@linux.microsoft.com> Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by: Dipayaan Roy <dipayanroy@linux.microsoft.com> Link: https://patch.msgid.link/20250814140410.GA22089@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-08-19mmc: Merge branch fixes into nextUlf Hansson
Merge the mmc fixes for v6.17-rc[n] into the next branch, to allow them to get tested together with the new mmc changes that are targeted for v6.18. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2025-08-19mmc: sdhci-cadence: implement multi-block read gap tuningBenoît Monin
The controller suspends the clock between blocks when reading from the MMC as part of its flow-control, called read block gap. At higher clock speed and with IO delay between the controller and the MMC, this clock pause can happen too late, during the read of the next block and trigger a read error. To prevent this, the delay can be programmed for each mode via the pair of registers HRS37/38. This delay is obtained during tuning, by trying a multi-block read and increasing the delay until the read succeeds. For now, the tuning is only done in HS200, as the read error has only been observed at that speed. Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Benoît Monin <benoit.monin@bootlin.com> Link: https://lore.kernel.org/r/20250818-mobileye-emmc-for-upstream-4-v4-6-34ecb3995e96@bootlin.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2025-08-19mmc: core: add mmc_read_tuningBenoît Monin
Provide a function to the MMC hosts to read some blocks of data as part of their tuning. This function only returns the status of the read operation, not the data read. Signed-off-by: Benoît Monin <benoit.monin@bootlin.com> Link: https://lore.kernel.org/r/20250818-mobileye-emmc-for-upstream-4-v4-5-34ecb3995e96@bootlin.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2025-08-19mmc: block: use mmc_card cmd23 helpersBenoît Monin
Use the dedicated helpers for CMD23 card support. Signed-off-by: Benoît Monin <benoit.monin@bootlin.com> Link: https://lore.kernel.org/r/20250818-mobileye-emmc-for-upstream-4-v4-4-34ecb3995e96@bootlin.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2025-08-19mmc: mmc_test: use mmc_card cmd23 helpersBenoît Monin
Use mmc_card_can_cmd23 instead of using a local and partial implementation, and check for the CMD23 quirk with mmc_card_blk_no_cmd23. Signed-off-by: Benoît Monin <benoit.monin@bootlin.com> Link: https://lore.kernel.org/r/20250818-mobileye-emmc-for-upstream-4-v4-3-34ecb3995e96@bootlin.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2025-08-19mmc: card: add mmc_card_blk_no_cmd23Benoît Monin
Add a helper to check for the missing CMD23 quirk, similar to other quirk helpers. Also reorder the helpers to match the order of the quirk bits defined in include/linux/mmc/card.h. Signed-off-by: Benoît Monin <benoit.monin@bootlin.com> Link: https://lore.kernel.org/r/20250818-mobileye-emmc-for-upstream-4-v4-2-34ecb3995e96@bootlin.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2025-08-19mmc: core: add mmc_card_can_cmd23Benoît Monin
Add a dedicated helper to check for CMD23 support for MMC card, similar to mmc_host_can_cmd23 for the host, as it is easy to get the check wrong. Signed-off-by: Benoît Monin <benoit.monin@bootlin.com> Link: https://lore.kernel.org/r/20250818-mobileye-emmc-for-upstream-4-v4-1-34ecb3995e96@bootlin.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2025-08-19mmc: remove unneeded 'fast_io' parameter in regmap_configWolfram Sang
When using MMIO with regmap, fast_io is implied. No need to set it again. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/20250813161517.4746-11-wsa+renesas@sang-engineering.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2025-08-19mmc: meson-mx-sdhc: use PTR_ERR_OR_ZERO() to simplify codeXichao Zhao
Use the standard error pointer macro to shorten the code and simplify. Signed-off-by: Xichao Zhao <zhao.xichao@vivo.com> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Link: https://lore.kernel.org/r/20250812092908.101867-1-zhao.xichao@vivo.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2025-08-19misc: rtsx: usb card reader: add OCP supportRicky Wu
This patch adds support for Over Current Protection (OCP) to the Realtek USB card reader driver. The OCP mechanism protects the hardware by detecting and handling current overload conditions. This implementation includes: - Register configurations to enable OCP monitoring. - Handling of OCP interrupt events and associated error reporting. - Card power management changes in response to OCP triggers. This enhancement improves the robustness of the driver when operating in environments where electrical anomalies may occur, particularly with SD and MS card interfaces. Signed-off-by: Ricky Wu <ricky_wu@realtek.com> Link: https://lore.kernel.org/r/20250812030811.2426112-1-ricky_wu@realtek.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2025-08-19memstick: Add timeout to prevent indefinite waitingJiayi Li
Add timeout handling to wait_for_completion calls in memstick_set_rw_addr() and memstick_alloc_card() to prevent indefinite blocking in case of hardware or communication failures. Signed-off-by: Jiayi Li <lijiayi@kylinos.cn> Link: https://lore.kernel.org/r/20250804024825.1565078-1-lijiayi@kylinos.cn Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2025-08-19mmc: renesas_sdhi: Enable 64-bit polling modeBiju Das
Enable 64-bit polling mode for R-Car gen3 and RZ/G2L SoCs. Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/r/20250730164618.233117-3-biju.das.jz@bp.renesas.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2025-08-19mmc: tmio: Add 64-bit read/write support for SD_BUF0 in polling modeBiju Das
As per the RZ/{G2L,G3E} HW manual SD_BUF0 can be accessed by 16/32/64 bits. Most of the data transfer in SD/SDIO/eMMC mode is more than 8 bytes. During testing it is found that, if the DMA buffer is not aligned to 128 bit it fallback to PIO mode. In such cases, 64-bit access is much more efficient than the current 16-bit. Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/r/20250730164618.233117-2-biju.das.jz@bp.renesas.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2025-08-19mmc: host: renesas_sdhi: Fix the actual clockBiju Das
Wrong actual clock reported, if the SD clock division ratio is other than 1:1(bits DIV[7:0] in SD_CLK_CTRL are set to 11111111). On high speed mode, cat /sys/kernel/debug/mmc1/ios Without the patch: clock: 50000000 Hz actual clock: 200000000 Hz After the fix: clock: 50000000 Hz actual clock: 50000000 Hz Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/r/20250629203859.170850-1-biju.das.jz@bp.renesas.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2025-08-19mmc: mmc_spi: multiple block read remove read crc ackRex Chen
For multiple block read, the current implementation, transfer packet includes cmd53 + cmd53 response + block nums*(1byte token + block length bytes payload + 2bytes CRC + 1byte transfer), the last 1byte transfer of every block is not needed, so remove it. Why doesn't multiple block read need CRC ack? For read operation, host side get the payload and CRC value, then will only check the CRC value to confirm if the data is correct or not, but not send CRC ack to card. If the data is correct, save it, or discard it and retransmit if data is error, so the last 1byte transfer of every block make no sense. What's the side effect of this 1byte transfer? As the SPI is full duplex, if add this redundant 1byte transfer, SDIO card side take it as the token of next block, then all the next sub blocks sequence distort. Signed-off-by: Rex Chen <rex.chen_1@nxp.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250728082230.1037917-3-rex.chen_1@nxp.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2025-08-19mmc: core: SPI mode remove cmd7Rex Chen
SPI mode doesn't support cmd7, so remove it in mmc_sdio_alive() and confirm if sdio is active by checking CCCR register value is available or not. Signed-off-by: Rex Chen <rex.chen_1@nxp.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250728082230.1037917-2-rex.chen_1@nxp.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2025-08-19pinctrl: meson-g12a: add GPIOC_7 pcie_clkreqn pinmuxDa Xue
Amlogic G12 exposes PCIe clock request signal on GPIOC_7 pinmux func 1 Add the relevant pinmux and pin groups Signed-off-by: Da Xue <da@libre.computer> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Link: https://lore.kernel.org/20250814181236.1956731-1-da@libre.computer Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2025-08-19gpiolib: acpi: Add quirk for ASUS ProArt PX13Mario Limonciello (AMD)
The ASUS ProArt PX13 has a spurious wakeup event from the touchpad a few moments after entering hardware sleep. This can be avoided by preventing the touchpad from being a wake source. Add to the wakeup ignore list. Reported-by: Amit Chaudhari <amitchaudhari@mac.com> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4482 Tested-by: Amit Chaudhari <amitchaudhari@mac.com> Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Link: https://lore.kernel.org/20250814183430.3887973-1-superm1@kernel.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2025-08-19pmdomain: mediatek: Convert all SoCs to new style regmap retrievalAngeloGioacchino Del Regno
Add the bus_prot_blocks handle and declare num_bus_prot_blocks to allow all of the currently supported AArch64 MediaTek SoCs to use the new style regmap retrieval in the driver when a new style devicetree declaring the mediatek,bus-protection phandle(s) in the main power controller node is found. Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20250805074746.29457-10-angelogioacchino.delregno@collabora.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2025-08-19pmdomain: mediatek: Add support for RTFF Hardware in MT8196/MT6991AngeloGioacchino Del Regno
New generation SoCs use a new RTFF Hardware to save power during operation of various IPs, other than managing isolation of the internal buck converters during powerup/down of power domains. Since some of the power domains need different RTFF handling, add a new scpys_rtff_type enumeration and hold the value for each power domain in struct scpsys_domain_data. If RTFF HW is available, the RTFF additional power sequences are handled in scpsys_ctl_pwrseq_{on,off}(). Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20250805074746.29457-9-angelogioacchino.delregno@collabora.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2025-08-19pmdomain: mediatek: Add support for modem power sequencesAngeloGioacchino Del Regno
Add support for the modem power domains by adding its specific power sequence in functions scpsys_modem_pwrseq_{on,off}() and call them if the flag MTK_SCPD_MODEM_PWRSEQ is present. While at it, since some SoC models need to skip setting/clearing the PWR_RST_B_BIT, also add a MTK_SCPD_SKIP_RESET_B flag for that. Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20250805074746.29457-8-angelogioacchino.delregno@collabora.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2025-08-19pmdomain: mediatek: Move ctl sequences out of power_on/off functionsAngeloGioacchino Del Regno
In preparation to support power domains of new SoCs and the modem power domains for both new and already supported chips, move the generic control power sequences out of the scpsys_power_on() and scpsys_power_off() and put them in new scpsys_ctl_pwrseq_on(), scpsys_ctl_pewseq_off() functions. Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20250805074746.29457-7-angelogioacchino.delregno@collabora.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2025-08-19pmdomain: mediatek: Handle SoCs with inverted SRAM power-down bitsAngeloGioacchino Del Regno
Some SoCs, and even some subsystems in the same SoC, may have the logic for SRAM power-down inverted, as in, setting the bit means "power down" and unsetting means "power up": this is because some hardware subsystems use this as a power-lock indication and some use this as a power down one (for example, usually, the modem ss has it inverted!). In preparation for adding support for power domains with inverted SRAM_PDN bits, add a new MTK_SCPD_SRAM_PDN_INVERTED flag and check for it in scpsys_sram_enable() and scpsys_sram_disable(). Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20250805074746.29457-6-angelogioacchino.delregno@collabora.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2025-08-19pmdomain: mediatek: Refactor bus protection regmaps retrievalAngeloGioacchino Del Regno
In preparation to add support for new generation SoCs like MT8196, MT6991 and other variants, which require to set bus protection on different busses than the ones found on legacy chips, and to also simplify and reduce memory footprint of this driver, refactor the mechanism to retrieve and use the bus protection regmaps. This is done by removing the three pointers to struct regmap from struct scpsys_domain (allocated for each power domain) and moving them to the main struct scpsys (allocated per driver instance) as an array of pointers to regmap named **bus_prot. That deprecates the old devicetree properties to grab phandles to the three predefined busses (infracfg, infracfg-nao and smi) and replaces it with the base property "access-controllers" that is meant to be an array of phandles holding the same busses where required (for now - for legacy SoCs). The new bus protection phandles are indexed by the bus_prot_index member of struct scpsys, used to map "bus type" (ex.: infra, smi, etc) to the specific *bus_prot[x] element. While the old per-power-domain regmap pointers were removed, the support for old devicetree was retained by still checking if the new property (in DT) and new-style declaration (in SoC specific platform data) are both present at probe time. If those are not present, a lookup for the old properties will be done in all of the children of the power controller, and pointers to regmaps will be retrieved with the old properties, but then will be internally remapped to follow the new style regmap anyway as to let this driver benefit of the memory footprint reduction. Finally, it was necessary to change macros in mtk-pm-domains.h and in mt8365-pm-domains.h to make use of the new style bus protection declaration, as the actual HW block is now recognized not by flags but by its own scpsys_bus_prot_block enumeration. The BUS_PROT_(STA)_COMPONENT_{INFRA,INFRA_NAO,SMI} flags were also removed since they are now unused, and because that enumeration was initially meant to vary the logic of bus protection and not the bus where work is performed, anyway! Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20250805074746.29457-5-angelogioacchino.delregno@collabora.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2025-08-19pmdomain: Merge branch fixes into nextUlf Hansson
Merge the pmdomain fixes for v6.17-rc[n] into the next branch, to allow them to get tested together with the new changes that are targeted for v6.18. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
generated by cgit v1.2.3 (git 2.25.1) at 2026-09-17 03:43:29 +0000