summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-01-13net: airoha: implement get_link_ksettingsAleksander Jan Bajkowski
Implement the .get_link_ksettings to get the rate, duplex, and auto-negotiation status. Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl> Tested-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20260110170212.570793-1-olek2@wp.pl Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-01-13PCI: qcom-ep: Add support for firmware-managed PCIe EndpointMrinmay Sarkar
Some Qualcomm platforms use firmware to manage PCIe resources such as clocks, resets, and PHY through the SCMI interface. In these cases, the Linux driver should not perform resource enable or disable operations directly. So introduce a `firmware_managed` flag in 'struct qcom_pcie_ep_cfg', and set it to true for SA8255p SoC. When this flag is set, the driver will skip the resource handling and rely on runtime PM APIs to let the firmware handle the resources with the help of power domain. Signed-off-by: Mrinmay Sarkar <mrinmay.sarkar@oss.qualcomm.com> [mani: reworded description and tiny code cleanup] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20260106-firmware_managed_ep-v5-2-1933432127ec@oss.qualcomm.com
2026-01-13dt-bindings: PCI: qcom,sa8255p-pcie-ep: Document firmware managed PCIe endpointMrinmay Sarkar
Document the required configuration to enable the PCIe Endpoint controller on SA8255p which is managed by firmware using power-domain based handling. Signed-off-by: Mrinmay Sarkar <mrinmay.sarkar@oss.qualcomm.com> [mani: added MAINTAINERS entry] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260106-firmware_managed_ep-v5-1-1933432127ec@oss.qualcomm.com
2026-01-13drm/mediatek: Convert legacy DRM logging to drm_* helpers in mtk_crtc.cAbhishek Rajput
Replace DRM_ERROR() and DRM_DEBUG_DRIVER() calls in drivers/gpu/drm/mediatek/mtk_crtc.c with the corresponding drm_err() and drm_dbg_driver() helpers. The drm_*() logging helpers take a struct drm_device * argument, allowing the DRM core to prefix log messages with the correct device name and instance. This is required to correctly distinguish log messages on systems with multiple GPUs. This change aligns the Mediatek DRM driver with the DRM TODO item: "Convert logging to drm_* functions with drm_device parameter". Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202512220515.z3QybJ8I-lkp@intel.com/ Signed-off-by: Abhishek Rajput <abhiraj21put@gmail.com> Reviewed-by: CK Hu <ck.hu@mediatek.com> Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20251223095434.492041-1-abhiraj21put@gmail.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2026-01-13USB: serial: f81232: fix incomplete serial port generationJi-Ze Hong (Peter Hong)
The Fintek F81532A/534A/535/536 family relies on the F81534A_CTRL_CMD_ENABLE_PORT (116h) register during initialization to both determine serial port status and control port creation. If the driver experiences fast load/unload cycles, the device state may becomes unstable, resulting in the incomplete generation of serial ports. Performing a dummy read operation on the register prior to the initial write command resolves the issue. This clears the device's stale internal state. Subsequent write operations will correctly generate all serial ports. This patch also removes the retry loop in f81534a_ctrl_set_register() because the stale state has been fixed. Tested on: HygonDM1SLT(Hygon C86 3250 8-core Processor) Signed-off-by: Ji-Ze Hong (Peter Hong) <peter_hong@fintek.com.tw> Signed-off-by: Johan Hovold <johan@kernel.org>
2026-01-13PCI: sophgo: Disable L0s and L1 on Sophgo 2044 PCIe Root PortsInochi Amaoto
Sophgo 2044 Root Ports advertise L0 and L1 capabilities without supporting them. Since commit f3ac2ff14834 ("PCI/ASPM: Enable all ClockPM and ASPM states for devicetree platforms") force enabled ASPM on all device tree platforms, the issue became evident and the SG2044 Root Port started breaking. Hence, disable the L0s and L1 capabilities in the LINKCAP register for the SG2044 Root Ports, so that these states won't get enabled. Fixes: 467d9c0348d6 ("PCI: dwc: Add Sophgo SG2044 PCIe controller driver in Root Complex mode") Signed-off-by: Inochi Amaoto <inochiama@gmail.com> [mani: reworded description and corrected fixes tag] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Tested-by: Han Gao <gaohan@iscas.ac.cn> Link: https://patch.msgid.link/20260109040756.731169-1-inochiama@gmail.com
2026-01-13platform/x86/intel/pmc: Remove double empty lineXi Pardee
Remove double empty line to improve readability. Signed-off-by: Xi Pardee <xi.pardee@linux.intel.com> Link: https://patch.msgid.link/20260108223144.504267-5-xi.pardee@linux.intel.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-01-13platform/x86/intel/pmc: Enable substate residencies for multiple PMCsXi Pardee
Enable substate residencies support for multiple PMCs. Previously substate residencies were shown only for the primary PMC. This change enables substate residencies for all available PMCs. The output of substate_residencies with this patch will be similar to this: pmc0 Substate Residency S0i2.0 0 S0i2.1 0 S0i2.2 0 pmc1 Substate Residency S0i2.0 0 S0i2.1 0 S0i2.2 0 pmc2 Substate Residency S0i2.0 0 Signed-off-by: Xi Pardee <xi.pardee@linux.intel.com> Link: https://patch.msgid.link/20260108223144.504267-4-xi.pardee@linux.intel.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-01-13platform/x86/intel/pmc: Move LPM mode attributes to PMCXi Pardee
Move LPM modes attributes from the pmc_dev to the pmc structure. LPM modes are PMC-specific and should be stored within the pmc structure. After the change, LPM mode information will be retrieved and stored per PMC. The substate_requirements attribute in debugfs will display the requirements for each enabled LPM substate. Signed-off-by: Xi Pardee <xi.pardee@linux.intel.com> Link: https://patch.msgid.link/20260108223144.504267-3-xi.pardee@linux.intel.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-01-13platform/x86/intel/pmc: Change LPM mode fields to u8Xi Pardee
Change the datatypes of num_lpm_modes and lpm_en_modes[] from int to u8. The u8 type is more appropriate and improves the readability and maintainability of the code. Signed-off-by: Xi Pardee <xi.pardee@linux.intel.com> Link: https://patch.msgid.link/20260108223144.504267-2-xi.pardee@linux.intel.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-01-13platform/x86: ISST: Optimize suspend/resume callbacksSrinivas Pandruvada
If SST-CP or SST-PP is not supported then don't store configuration during suspend callback and restore during resume callback. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://patch.msgid.link/20260107061649.1634737-1-srinivas.pandruvada@linux.intel.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-01-13platform/x86: ISST: Check for admin capability for write commandsSrinivas Pandruvada
In some SST deployments, administrators want to allow reading SST capabilities for non-root users. This can be achieved by changing file permissions for "/dev/isst_interface", but they still want to prevent any changes to the SST configuration by non-root users. This capability was available before for non-TPMI SST. Extend the same capability for TPMI SST by adding a check for CAP_SYS_ADMIN for all write commands. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://patch.msgid.link/20260107060729.1634420-1-srinivas.pandruvada@linux.intel.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-01-13platform/x86: ISST: Store and restore all domains dataSrinivas Pandruvada
The suspend/resume callbacks currently only store and restore the configuration for power domain 0. However, other power domains may also have modified configurations that need to be preserved across suspend/ resume cycles. Extend the store/restore functionality to handle all power domains. Fixes: 91576acab020 ("platform/x86: ISST: Add suspend/resume callbacks") Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> CC: stable@vger.kernel.org Link: https://patch.msgid.link/20260107060256.1634188-3-srinivas.pandruvada@linux.intel.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-01-13platform/x86: ISST: Add missing write block checkSrinivas Pandruvada
If writes are blocked, then return error during SST-CP enable command. Add missing write block check in this code path. Fixes: 8bed9ff7dbcc ("platform/x86: ISST: Process read/write blocked feature status") Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260107060256.1634188-2-srinivas.pandruvada@linux.intel.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-01-13x86/crash: Use set_memory_p() instead of __set_memory_prot()Coiby Xu
set_memory_p() is available to use outside of its compilation unit since: 030ad7af9437 ("x86/mm: Regularize set_memory_p() parameters and make non-static"). There is no use for __set_memory_prot() anymore so drop it too. [ bp: Massage commit message. ] Signed-off-by: Coiby Xu <coxu@redhat.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://patch.msgid.link/20260106095100.656292-1-coxu@redhat.com
2026-01-13null_blk: fix kmemleak by releasing references to fault configfs itemsNilay Shroff
When CONFIG_BLK_DEV_NULL_BLK_FAULT_INJECTION is enabled, the null-blk driver sets up fault injection support by creating the timeout_inject, requeue_inject, and init_hctx_fault_inject configfs items as children of the top-level nullbX configfs group. However, when the nullbX device is removed, the references taken to these fault-config configfs items are not released. As a result, kmemleak reports a memory leak, for example: unreferenced object 0xc00000021ff25c40 (size 32): comm "mkdir", pid 10665, jiffies 4322121578 hex dump (first 32 bytes): 69 6e 69 74 5f 68 63 74 78 5f 66 61 75 6c 74 5f init_hctx_fault_ 69 6e 6a 65 63 74 00 88 00 00 00 00 00 00 00 00 inject.......... backtrace (crc 1a018c86): __kmalloc_node_track_caller_noprof+0x494/0xbd8 kvasprintf+0x74/0xf4 config_item_set_name+0xf0/0x104 config_group_init_type_name+0x48/0xfc fault_config_init+0x48/0xf0 0xc0080000180559e4 configfs_mkdir+0x304/0x814 vfs_mkdir+0x49c/0x604 do_mkdirat+0x314/0x3d0 sys_mkdir+0xa0/0xd8 system_call_exception+0x1b0/0x4f0 system_call_vectored_common+0x15c/0x2ec Fix this by explicitly releasing the references to the fault-config configfs items when dropping the reference to the top-level nullbX configfs group. Cc: stable@vger.kernel.org Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Fixes: bb4c19e030f4 ("block: null_blk: make fault-injection dynamically configurable per device") Signed-off-by: Nilay Shroff <nilay@linux.ibm.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-01-13block, nvme: remove unused dma_iova_state function parameterNitesh Shetty
DMA IOVA state is not used inside blk_rq_dma_map_iter_next, get rid of the argument. Signed-off-by: Nitesh Shetty <nj.shetty@samsung.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-01-13Merge branch 'icc-mtk' into icc-nextGeorgi Djakov
This series is a combination of binding changes, driver cleanups and new driver code to enable the interconnect on the MediaTek MT8196 SoC. * icc-mtk dt-bindings: interconnect: mt8183-emi: Add support for MT8196 EMI interconnect: mediatek: Add support for MediaTek MT8196 EMI ICC interconnect: mediatek: Don't hijack parent device interconnect: mediatek: Aggregate bandwidth with saturating add Link: https://lore.kernel.org/r/20251124-mt8196-dvfsrc-v2-0-d9c1334db9f3@collabora.com Signed-off-by: Georgi Djakov <djakov@kernel.org>
2026-01-13interconnect: Add kunit tests for core functionalityKuan-Wei Chiu
The interconnect framework currently lacks in-tree unit tests to verify the core logic in isolation. This makes it difficult to validate regression stability when modifying the provider/consumer APIs or aggregation logic. Introduce a kunit test suite that verifies the fundamental behavior of the subsystem. The tests cover: - Provider API (node creation, linking, topology construction). - Consumer API (path enabling/disabling, bandwidth requests). - Standard aggregation logic (accumulating bandwidth across links). - Bulk operations for setting bandwidth on multiple paths. The suite simulates a simple SoC topology with multiple masters and a shared bus to validate traffic aggregation behavior in a controlled software environment, without requiring specific hardware or Device Tree support. Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com> Link: https://lore.kernel.org/r/20260110184309.906735-1-visitorckw@gmail.com Signed-off-by: Georgi Djakov <djakov@kernel.org>
2026-01-13gpio: pca9570: use lock guardsAndy Shevchenko
Shrink the code by a couple lines and improve lock management by using lock guards from cleanup.h. Reviewed-by: Linus Walleij <linusw@kernel.org> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20260113111156.188051-4-andriy.shevchenko@linux.intel.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-01-13gpio: pca9570: Don't use "proxy" headersAndy Shevchenko
Update header inclusions to follow IWYU (Include What You Use) principle. Note that kernel.h is discouraged to be included as it's written at the top of that file. Reviewed-by: Linus Walleij <linusw@kernel.org> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20260113111156.188051-3-andriy.shevchenko@linux.intel.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-01-13gpio: pca9570: Use devm_mutex_init() for mutex initializationAndy Shevchenko
Use devm_mutex_init() since it brings some benefits when CONFIG_DEBUG_MUTEXES is enabled. Reviewed-by: Linus Walleij <linusw@kernel.org> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20260113111156.188051-2-andriy.shevchenko@linux.intel.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-01-13dt-bindings: interconnect: qcom,qcs615-rpmh: Drop IPA interconnectsKonrad Dybcio
This has been agreed to be characterized as a clock resource, not an interconnect provider. Bring QCS615 in line with the expectation. Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250627-topic-qcs615_icc_ipa-v1-3-dc47596cde69@oss.qualcomm.com Signed-off-by: Georgi Djakov <djakov@kernel.org>
2026-01-13ALSA: usb-audio: Prevent excessive number of framesEdward Adam Davis
In this case, the user constructed the parameters with maxpacksize 40 for rate 22050 / pps 1000, and packsize[0] 22 packsize[1] 23. The buffer size for each data URB is maxpacksize * packets, which in this example is 40 * 6 = 240; When the user performs a write operation to send audio data into the ALSA PCM playback stream, the calculated number of frames is packsize[0] * packets = 264, which exceeds the allocated URB buffer size, triggering the out-of-bounds (OOB) issue reported by syzbot [1]. Added a check for the number of single data URB frames when calculating the number of frames to prevent [1]. [1] BUG: KASAN: slab-out-of-bounds in copy_to_urb+0x261/0x460 sound/usb/pcm.c:1487 Write of size 264 at addr ffff88804337e800 by task syz.0.17/5506 Call Trace: copy_to_urb+0x261/0x460 sound/usb/pcm.c:1487 prepare_playback_urb+0x953/0x13d0 sound/usb/pcm.c:1611 prepare_outbound_urb+0x377/0xc50 sound/usb/endpoint.c:333 Reported-by: syzbot+6db0415d6d5c635f72cb@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=6db0415d6d5c635f72cb Tested-by: syzbot+6db0415d6d5c635f72cb@syzkaller.appspotmail.com Signed-off-by: Edward Adam Davis <eadavis@qq.com> Link: https://patch.msgid.link/tencent_9AECE6CD2C7A826D902D696C289724E8120A@qq.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-01-13PCI: starfive: Use regulator APIs to control the 3v3 power supply of PCIe slotsHal Feng
The driver has been using the "enable-gpios" property to control the 3v3 power supply of PCIe slots. But it is not documented in the dt-bindings and also using GPIO APIs is not a standard way to control PCIe slot power, so use the documented "vpcie3v3-supply" property and regulator APIs to control the slot supply. This change will break the DTs which used "enable-gpio" or "enable-gpios" property under the controller node. Since these properties were not defined in the bindings, it is safe to switch to "vpcie3v3-supply". Any out-of-tree DTS impacted by this change should migrate to "vpcie3v3-supply" instead. Signed-off-by: Hal Feng <hal.feng@starfivetech.com> [mani: reworded description] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Acked-by: Kevin Xie <kevin.xie@starfivetech.com> Link: https://patch.msgid.link/20251218102149.28062-1-hal.feng@starfivetech.com
2026-01-13Axiado AX3000 SoC SPI DB controller driverMark Brown
Merge series from Vladimir Moravcevic <vmoravcevic@axiado.com>: This series introduces new SPI controller driver for Axiado AX3000 SoC and its evaluation board. The SPI controller provides: - Full-duplex and half-duplex transfer support - Configurable clock polarity and phase - Interrupt-driven Functionality has been verified using the `jedec,spi-nor` interface to access onboard flash memory. This ensures compatibility with common NOR flash devices used in boot and storage subsystem. Further improvements, including performance tuning and extended hardware feature support, will be submitted in follow-up patches.
2026-01-13arm64: dts: rockchip: Add Radxa CM3J on RPi CM4 IO BoardFUKAUMI Naoki
The Raspberry Pi Compute Module 4 IO Board is an application board for the Compute Module 4. [1] This patch adds support for the Radxa CM3J mounted on the RPi CM4 IO Board. Specification: - 12V 5521 DC jack - 2x full-size HDMI 2.0 connectors (only HDMI0 is supported with CM3J) - Gigabit Ethernet RJ45 with PoE support - 2x USB 2.0 connectors, with header for two more connectors - Micro USB connector - microSD card socket - PCIe Gen 2 x1 socket - 12V 4-pin PWM fan connector - External power connector (+5V, +12V) - 2x MIPI DSI connectors - 2x MIPI CSI-2 connectors - 40-pin GPIO header - RTC with battery socket - Red (power) and green (heartbeat) LEDs [1] https://datasheets.raspberrypi.com/cm4io/cm4io-datasheet.pdf Signed-off-by: FUKAUMI Naoki <naoki@radxa.com> Link: https://patch.msgid.link/20260108113341.14037-3-naoki@radxa.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-01-13arm64: dts: rockchip: Add Radxa CM3JFUKAUMI Naoki
The Radxa CM3J is a feature rich industrial compute module based on the Rockchip RK3568J SoC. [1] Specification: - Quad-core Cortex-A55 CPU - Mali-G52 2EE GPU - 1TOPS NPU - Up to 8GB LPDDR4x RAM - Up to 32GB eMMC (optional) - 16MB SPI flash (optional) - Wi-Fi 5 / BT 5.0 with external antenna connector - Gigabit Ethernet PHY - RK809 PMIC - Green (power) LED [1] https://dl.radxa.com/cm3j/docs/hw/radxa_cm3j_schematic_v1.2_20250115.pdf Signed-off-by: FUKAUMI Naoki <naoki@radxa.com> Link: https://patch.msgid.link/20260108113341.14037-2-naoki@radxa.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-01-13dt-bindings: arm: rockchip: Add Radxa CM3J on RPi CM4 IO BoardFUKAUMI Naoki
The Radxa CM3J is a feature rich industrial compute module developed by Radxa, based on the Rockchip RK3568 SoC. [1] Add devicetree binding documentation for the Radxa CM3J on RPi CM4 IO Board. [1] https://dl.radxa.com/cm3j/docs/hw/radxa_cm3j_product_brief_Revision_1.0.pdf Signed-off-by: FUKAUMI Naoki <naoki@radxa.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260108113341.14037-1-naoki@radxa.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-01-13drm/gud: fix NULL fb and crtc dereferences on USB disconnectShenghao Yang
On disconnect drm_atomic_helper_disable_all() is called which sets both the fb and crtc for a plane to NULL before invoking a commit. This causes a kernel oops on every display disconnect. Add guards for those dereferences. Cc: <stable@vger.kernel.org> # 6.18.x Fixes: 73cfd166e045 ("drm/gud: Replace simple display pipe with DRM atomic helpers") Signed-off-by: Shenghao Yang <me@shenghaoyang.info> Reviewed-by: Ruben Wauters <rubenru09@aol.com> Signed-off-by: Ruben Wauters <rubenru09@aol.com> Link: https://patch.msgid.link/20251231055039.44266-1-me@shenghaoyang.info
2026-01-13x86/pvlocks: Move paravirt spinlock functions into own headerJuergen Gross
Instead of having the pv spinlock function definitions in paravirt.h, move them into the new header paravirt-spinlock.h. Signed-off-by: Juergen Gross <jgross@suse.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://patch.msgid.link/20260105110520.21356-22-jgross@suse.com
2026-01-13arm64: dts: rockchip: Make eeprom read-only for Radxa ROCK 3C/5A/5CFUKAUMI Naoki
The BL24C16 EEPROM implemented on the Radxa ROCK 3C, 5A, and 5C [1] [2] [3] is designed to have data written during factory programming (regardless of whether data is actually written or not), and we at Radxa permit users to read the data but not write to it. [4] Therefore, we will add a read-only property to the eeprom node. [1] https://dl.radxa.com/rock3/docs/hw/3c/v1400/radxa_rock_3c_v1400_schematic.pdf p.13 [2] https://dl.radxa.com/rock5/5a/docs/hw/radxa_rock5a_V1.1_sch.pdf p.19 [3] https://dl.radxa.com/rock5/5c/docs/hw/v1100/radxa_rock_5c_schematic_v1100.pdf p.18 [4] https://github.com/radxa/u-boot/blob/next-dev-v2024.10/drivers/misc/radxa-i2c-eeprom.c Signed-off-by: FUKAUMI Naoki <naoki@radxa.com> Link: https://patch.msgid.link/20260108034252.2713-1-naoki@radxa.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-01-13arm64: dts: rockchip: Add TS133 variant of the QNAP NAS seriesHeiko Stuebner
The TS133 is a one-bay NAS mostly similar to the other devices in the series. The main difference is that it is build around the RK3566 SoC instead of the RK3568 variant. The RK3566/RK3568 are mostly similar with only slight variants in both speed and some specific peripherals - the RK3568 has more. The specific for the NAS series stay the same though. Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20260104191448.2693309-6-heiko@sntech.de
2026-01-13dt-bindings: arm: rockchip: add TS133 to RK356x-based QNAP NAS devicesHeiko Stuebner
QNAP builds a number of variants of the RK356x-based NAS design. Add the 1-bay TS133 variant. This one is a tiny bit special as it is based around the RK3566 variant of the mostly similar RK3566/RK3568 SoCs. Acked-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20260104191448.2693309-5-heiko@sntech.de
2026-01-13arm64: dts: rockchip: Move copy-key to TSx33 board filesHeiko Stuebner
The copy-key is not present on all device variants, so move it to the individual boards that have this key. Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20260104191448.2693309-4-heiko@sntech.de
2026-01-13arm64: dts: rockchip: Fix the common combophy + SATA on QNAP TSx33 devicesHeiko Stuebner
The common used SATA controller on all TSx33 devices is actually SATA2. So move the SATA controller + combophy enablement to their correct position between shared dtsi and board devicetrees. Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20260104191448.2693309-3-heiko@sntech.de
2026-01-13arm64: dts: rockchip: Move SoC include to individual QNAP TSx33 boardsHeiko Stuebner
The TS133 while mostly similar, is based around the RK3566 variant, so needs a different SoC include. By moving the SoC include to the board devicetrees, we can still keep the shared common setup, while supporting the different base SoCs. Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20260104191448.2693309-2-heiko@sntech.de
2026-01-13ALSA: hda/cirrus_scodec_test: Fix test suite nameRichard Fitzgerald
Change the test suite name string to "snd-hda-cirrus-scodec-test". It was incorrectly named "snd-hda-scodec-cs35l56-test", a leftover from when the code under test was actually in the cs35l56 driver. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Fixes: 2144833e7b414 ("ALSA: hda: cirrus_scodec: Add KUnit test") Link: https://patch.msgid.link/20260113134056.619051-1-rf@opensource.cirrus.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-01-13x86/paravirt: Specify pv_ops array in paravirt macrosJuergen Gross
In order to prepare having multiple pv_ops arrays, specify the array in the paravirt macros. Signed-off-by: Juergen Gross <jgross@suse.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://patch.msgid.link/20260105110520.21356-21-jgross@suse.com
2026-01-13MIPS: vdso: Provide getres_time64() for 32-bit ABIsThomas Weißschuh
For consistency with __vdso_clock_gettime64() there should also be a 64-bit variant of clock_getres(). This will allow the extension of CONFIG_COMPAT_32BIT_TIME to the vDSO and finally the removal of 32-bit time types from the kernel and UAPI. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20251223-vdso-compat-time32-v1-9-97ea7a06a543@linutronix.de
2026-01-13arm64: vdso32: Provide clock_getres_time64()Thomas Weißschuh
For consistency with __vdso_clock_gettime64() there should also be a 64-bit variant of clock_getres(). This will allow the extension of CONFIG_COMPAT_32BIT_TIME to the vDSO and finally the removal of 32-bit time types from the kernel and UAPI. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Acked-by: Will Deacon <will@kernel.org> Link: https://patch.msgid.link/20251223-vdso-compat-time32-v1-8-97ea7a06a543@linutronix.de
2026-01-13ARM: VDSO: Provide clock_getres_time64()Thomas Weißschuh
For consistency with __vdso_clock_gettime64() there should also be a 64-bit variant of clock_getres(). This will allow the extension of CONFIG_COMPAT_32BIT_TIME to the vDSO and finally the removal of 32-bit time types from the kernel and UAPI. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20251223-vdso-compat-time32-v1-7-97ea7a06a543@linutronix.de
2026-01-13ARM: VDSO: Patch out __vdso_clock_getres() if unavailableThomas Weißschuh
The vDSO code hides symbols which are non-functional. __vdso_clock_getres() was not added to this list when it got introduced. Fixes: 052e76a31b4a ("ARM: 8931/1: Add clock_getres entry point") Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20251223-vdso-compat-time32-v1-6-97ea7a06a543@linutronix.de
2026-01-13x86/vdso: Provide clock_getres_time64() for x86-32Thomas Weißschuh
For consistency with __vdso_clock_gettime64() there should also be a 64-bit variant of clock_getres(). This will allow the extension of CONFIG_COMPAT_32BIT_TIME to the vDSO and finally the removal of 32-bit time types from the kernel and UAPI. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20251223-vdso-compat-time32-v1-5-97ea7a06a543@linutronix.de
2026-01-13selftests: vDSO: vdso_test_abi: Add test for clock_getres_time64()Thomas Weißschuh
Some architectures will start to implement this function. Make sure it works correctly. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20251223-vdso-compat-time32-v1-4-97ea7a06a543@linutronix.de
2026-01-13selftests: vDSO: vdso_test_abi: Use UAPI system call numbersThomas Weißschuh
SYS_clock_getres might have been redirected by libc to some other system call than the actual clock_getres. For testing it is required to use exactly this system call. Use the system call number exported by the UAPI headers which is always correct. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20251223-vdso-compat-time32-v1-3-97ea7a06a543@linutronix.de
2026-01-13selftests: vDSO: vdso_config: Add configurations for clock_getres_time64()Thomas Weißschuh
Some architectures will start to implement this function. Make sure that tests can be written for it. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20251223-vdso-compat-time32-v1-2-97ea7a06a543@linutronix.de
2026-01-13vdso: Add prototype for __vdso_clock_getres_time64()Thomas Weißschuh
For consistency with __vdso_clock_gettime64() there should also be a 64-bit variant of clock_getres(). This will allow the extension of CONFIG_COMPAT_32BIT_TIME to the vDSO and finally the removal of 32-bit time types from the kernel and UAPI. The generic vDSO library already provides nearly all necessary building blocks for architectures to provide this function. Only a prototype is missing. Add the prototype to the generic header so architectures can start providing this function. Suggested-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20251223-vdso-compat-time32-v1-1-97ea7a06a543@linutronix.de
2026-01-13dt-bindings: PCI: loongson: Document msi-parent propertyYao Zi
Loongson PCI controllers found in LS2K1000/2000 SoCs (loongson,ls2k-pci), 7A1000/2000 bridge chips (loongson,ls7a-pci), and RS780E bridge chips (loongson,rs780e-pci) all have their paired MSI controllers. Though only the one in LS2K2000 SoC is described in devicetree, we should document the property for all variants. For the same reason, it isn't marked as required for now. Fixes: 83e757ecfd5d ("dt-bindings: Document Loongson PCI Host Controller") Signed-off-by: Yao Zi <me@ziyao.cc> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Acked-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20251209140006.54821-3-me@ziyao.cc
2026-01-13RDMA/irdma: Remove fixed 1 ms delay during AH wait loopJacob Moroni
The AH CQP command wait loop executes in an atomic context and was using a fixed 1 ms delay. Since many AH create commands can complete much faster than 1 ms, use poll_timeout_us_atomic with a 1 us delay. Also, use the timeout value indicated during the capability exchange rather than a hard-coded value. Signed-off-by: Jacob Moroni <jmoroni@google.com> Link: https://patch.msgid.link/20260105180550.2907858-1-jmoroni@google.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
generated by cgit v1.2.3 (git 2.51.0) at 2026-11-08 22:01:27 +0000