summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-03-14blk-integrity: support arbitrary buffer alignmentKeith Busch
A bio segment may have partial interval block data with the rest continuing into the next segments because direct-io data payloads only need to align in memory to the device's DMA limits. At the same time, the protection information may also be split in multiple segments. The most likely way that may happen is if two requests merge, or if we're directly using the io_uring user metadata. The generate/verify, however, only ever accessed the first bip_vec. Further, it may be possible to unalign the protection fields from the user space buffer, or if there are odd additional opaque bytes in front or in back of the protection information metadata region. Change up the iteration to allow spanning multiple segments. This patch is mostly a re-write of the protection information handling to allow any arbitrary alignments, so it's probably easier to review the end result rather than the diff. Many controllers are not able to handle interval data composed of multiple segments when PI is used, so this patch introduces a new integrity limit that a low level driver can set to notify that it is capable, default to false. The nvme driver is the first one to enable it in this patch. Everyone else will force DMA alignment to the logical block size as before to ensure interval data is always aligned within a single segment. Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Keith Busch <kbusch@kernel.org> Link: https://patch.msgid.link/20260313144701.1221652-2-kbusch@meta.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-03-14ALSA: hda/realtek: Add quirk for ASUS ROG Flow Z13-KJP GZ302EACMatthew Schwartz
Fixes lack of audio output on the ASUS ROG Flow Z13-KJP GZ302EAC model, similar to the ASUS ROG Flow Z13 GZ302EA. Signed-off-by: Matthew Schwartz <matthew.schwartz@linux.dev> Link: https://patch.msgid.link/20260313172503.285846-1-matthew.schwartz@linux.dev Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-03-14ALSA: hda/realtek: add quirk for Lenovo Yoga 7 2-in-1 16AKP10Zhang Heng
This machine is equipped with ALC287 and requires the quirk ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN to fix the issue where the bass speakers are not configured and the speaker volume cannot be controlled. Link: https://bugzilla.kernel.org/show_bug.cgi?id=221210 Signed-off-by: Zhang Heng <zhangheng@kylinos.cn> Link: https://patch.msgid.link/20260313080624.1395362-1-zhangheng@kylinos.cn Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-03-14Merge tag 'device_lock_cond_guard-7.1-rc1' into driver-core-testingDanilo Krummrich
DEFINE_GUARD_COND() for device_lock_interruptible() Introduce conditional guard version of device_lock() for scenarios that require conditional device lock holding. This is a stable tag for other trees to merge. Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-14iio: orientation: hid-sensor-rotation: add timestamp hack to not break userspaceDavid Lechner
Add a hack to push two timestamps in the hid-sensor-rotation scan data to avoid breaking userspace applications that depend on the timestamp being at the incorrect location in the scan data due to unintentional misalignment in older kernels. When this driver was written, the timestamp was in the correct location because of the way iio_compute_scan_bytes() was implemented at the time. (Samples were 24 bytes each.) Then commit 883f61653069 ("iio: buffer: align the size of scan bytes to size of the largest element") changed the computed scan_bytes to be a different size (32 bytes), which caused iio_push_to_buffers_with_timestamp() to place the timestamp at an incorrect offset. There have been long periods of time (6 years each) where the timestamp was in either location, so to not break either case, we open-code the timestamps to be pushed to both locations in the scan data. Reported-by: Jonathan Cameron <jic23@kernel.org> Closes: https://lore.kernel.org/linux-iio/20260215162351.79f40b32@jic23-huawei/ Fixes: 883f61653069 ("iio: buffer: align the size of scan bytes to size of the largest element") Signed-off-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2026-03-14iio: adc: ti-ads7950: remove chip_info[]David Lechner
Remove the chip_info[] array and related enum used for looking up chip- specific information. Instead, use individual structs directly in the module device tables. Also update to use spi_get_device_match_data() in case the devicetree table is ever used instead of the SPI device ID table. Signed-off-by: David Lechner <dlechner@baylibre.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2026-03-14iio: adc: palmas_gpadc: Replace leading space indentation with tabsGiorgi Tchankvetadze
Fix lines starting with spaces instead of tabs to comply with the kernel coding style. No functional change. Signed-off-by: Giorgi Tchankvetadze <giorgitchankvetadze1997@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2026-03-14iio: accel: adxl372: convert to guard(mutex)Rajveer Chaudhari
Replace manual mutex_lock/mutex_unlock pair with guard(mutex) in adxl372_write_threshold_value(). This ensures the mutex is released on all return paths and allows returning directly without a goto label. Signed-off-by: Rajveer Chaudhari <rajveer.chaudhari.linux@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2026-03-14iio: accel: adxl313: convert to guard(mutex)Rajveer Chaudhari
Replace manual mutex_lock/mutex_unlock pair with guard(mutex) in adxl313_read_axis(). This ensures the mutex is released on all return paths and allows returning directly without a goto label. Signed-off-by: Rajveer Chaudhari <rajveer.chaudhari.linux@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2026-03-14iio: buffer: hw-consumer: remove redundant scan_mask flexible arrayNuno Sá
The scan_mask flexible array member in hw_consumer_buffer duplicates the scan_mask pointer already present in struct iio_buffer. Remove it and allocate the bitmap directly with bitmap_zalloc(), assigning it to buf->buffer.scan_mask. This simplifies the code and there's no need for the flex array allocation. Signed-off-by: Nuno Sá <nuno.sa@analog.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2026-03-14iio: adc: meson: no devm for nvmem_cell_getRosen Penev
There is no reason to extend the lifetime of this post removal of the driver when it's only needed in one spot. Moved tsc_regmap assignment to avoid two nvmem_cell_put calls. Signed-off-by: Rosen Penev <rosenp@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2026-03-14iio: adc: at91-sama5d2_adc: no devm for nvmem_cell_getRosen Penev
There is absolutely no reason to pospone cleanup of this post driver removal. Just do it immediately. Signed-off-by: Rosen Penev <rosenp@gmail.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Reviewed-by: Eugen Hristev <eugen.hristev@linaro.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2026-03-14iio: light: acpi-als: Convert ACPI driver to a platform oneRafael J. Wysocki
In all cases in which a struct acpi_driver is used for binding a driver to an ACPI device object, a corresponding platform device is created by the ACPI core and that device is regarded as a proper representation of underlying hardware. Accordingly, a struct platform_driver should be used by driver code to bind to that device. There are multiple reasons why drivers should not bind directly to ACPI device objects [1]. Overall, it is better to bind drivers to platform devices than to their ACPI companions, so convert the ACPI ambient light sensor driver to a platform one. After this change, the subordinate IIO device will be registered under the platform device used for driver binding instead of its ACPI companion. While this is not expected to alter functionality, it changes sysfs layout and so it will be visible to user space. Link: https://lore.kernel.org/all/2396510.ElGaqSPkdT@rafael.j.wysocki/ [1] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2026-03-14iio: light: acpi-als: Register ACPI notify handler directlyRafael J. Wysocki
To facilitate subsequent conversion of the driver to a platform one, make it install an ACPI notify handler directly instead of using a .notify() callback in struct acpi_driver. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2026-03-14iio: frequency: admv1013: fix NULL pointer dereference on strAntoniu Miclaus
When device_property_read_string() fails, str is left uninitialized but the code falls through to strcmp(str, ...), dereferencing a garbage pointer. Replace manual read/strcmp with device_property_match_property_string() and consolidate the SE mode enums into a single sequential enum, mapping to hardware register values via a switch consistent with other bitfields in the driver. Several cleanup patches have been applied to this driver recently so this will need a manual backport. Fixes: da35a7b526d9 ("iio: frequency: admv1013: add support for ADMV1013") Reviewed-by: Nuno Sá <nuno.sa@analog.com> Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2026-03-14iio: adc: max1363: Reformat enum and array initializersGiorgi Tchankvetadze
Reformat the device enum so each entry is on its own line and add a trailing comma to the final enumerator. Also reformat the nearby monitor speeds array for consistency. No functional change. Signed-off-by: Giorgi Tchankvetadze <giorgitchankvetadze1997@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2026-03-14ARM: multi_v7_defconfig: Drop duplicate CONFIG_TI_PRUSS=mNathan Chancellor
Commit ee1ab82ee032 ("ARM: defconfig: move entries") added a duplicate instance of CONFIG_TI_PRUSS=m, causing a Kconfig warning: arch/arm/configs/multi_v7_defconfig:1152:warning: override: reassigning to symbol TI_PRUSS Drop the first instance, as the second instance added by the aforementioned change is where savedefconfig puts it. Fixes: ee1ab82ee032 ("ARM: defconfig: move entries") Signed-off-by: Nathan Chancellor <nathan@kernel.org> Link: https://patch.msgid.link/20260305-arm-defconfig-drop-duplicate-ti-pruss-v1-1-2839e3b42a8b@kernel.org Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2026-03-14thermal: sysfs: Use str_enabled_disabled() helper in mode_show()Thorsten Blum
Replace hard-coded strings with the str_enabled_disabled() helper. This unifies the output and helps the linker with deduplication, which may result in a smaller binary. Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> [ rjw: Subject and changelog tweaks ] Link: https://patch.msgid.link/20260311164212.405981-3-thorsten.blum@linux.dev Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-03-14iio: proximity: rfd77402: Fix completion race condition in IRQ modeFelix Gu
In IRQ mode, the completion was being reinitialized after the measurement command had already been sent to the hardware. This created a race condition where the IRQ handler could call complete() before reinit_completion() was executed. Consequently, wait_for_completion_timeout() would fail to see the signal and wait until it timed out. Move reinit_completion() to occur before the measurement command is triggered to ensure the synchronization primitive is ready to capture the interrupt. Fixes: dc81be96a73a ("iio: proximity: rfd77402: Add interrupt handling support") Signed-off-by: Felix Gu <ustc.gu@gmail.com> Reviewed-by: Shrikant Raskar <raskar.shree97@gmail.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2026-03-14kernfs: Add missing documentation for kernfs_put_active's drop_supers argumentT.J. Mercier
The drop_supers argument was added to kernfs_put_active to control whether the kernfs_supers_rwsem is temporarily dropped along with the kernfs_rwsem, but no documentation was added for it. Fixes: eea5d2bb34ba ("kernfs: Send IN_DELETE_SELF and IN_IGNORED") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202603130112.2FcCzv1g-lkp@intel.com/ Signed-off-by: T.J. Mercier <tjmercier@google.com> Link: https://patch.msgid.link/20260313175153.235681-1-tjmercier@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-03-14Merge tag 'renesas-dt-bindings-for-v7.1-tag1' of ↵Krzysztof Kozlowski
https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into soc/drivers Renesas DT binding updates for v7.1 - Document RZ/G3L SoC variants, the RZ/G3L SYSC block, and RZ/G3L SMARC SoM and Carrier-II EVK boards. * tag 'renesas-dt-bindings-for-v7.1-tag1' of https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel: dt-bindings: soc: renesas: renesas,rzg2l-sysc: Document RZ/G3L SoC dt-bindings: soc: renesas: Document RZ/G3L SoC variants, SMARC SoM and Carrier-II EVK Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2026-03-14Merge tag 'renesas-drivers-for-v7.1-tag1' of ↵Krzysztof Kozlowski
https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into soc/drivers Renesas driver updates for v7.1 - Initial support for the Renesas RZ/G3L (R9A08G046) SoC. * tag 'renesas-drivers-for-v7.1-tag1' of https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel: soc: renesas: rz-sysc: Add SoC identification for RZ/G3L SoC Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2026-03-14Merge tag 'renesas-arm-defconfig-for-v7.1-tag1' of ↵Krzysztof Kozlowski
https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into soc/defconfig Renesas ARM defconfig updates for v7.1 - Refresh the ARM SH-Mobile defconfig for v7.0-rc1. * tag 'renesas-arm-defconfig-for-v7.1-tag1' of https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel: ARM: shmobile: defconfig: Refresh for v7.0-rc1 Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2026-03-14Merge tag 'renesas-fixes-for-v7.0-tag1' of ↵Krzysztof Kozlowski
https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into arm/fixes Renesas fixes for v7.0 - Fix SD card initialization on the RZ/T2H and RZ/N2H EVK boards, - Remove WDT nodes meant for other CPU cores on the RZ/V2H(P) SoC, - Fix Clock Pulse Generator registers on the RZ/T2H and RZ/N2H SoCs, - Fix Versa3-related boot hangs on the RZ/G3S SoM, - Fix Extended SPI interrupts on the R-Car X5H SoC. * tag 'renesas-fixes-for-v7.0-tag1' of https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel: arm64: dts: renesas: r8a78000: Fix out-of-range SPI interrupt numbers arm64: dts: renesas: rzg3s-smarc-som: Set bypass for Versa3 PLL2 arm64: dts: renesas: r9a09g087: Fix CPG register region sizes arm64: dts: renesas: r9a09g077: Fix CPG register region sizes arm64: dts: renesas: r9a09g057: Remove wdt{0,2,3} nodes arm64: dts: renesas: rzv2-evk-cn15-sd: Add ramp delay for SD0 regulator arm64: dts: renesas: rzt2h-n2h-evk: Add ramp delay for SD0 card regulator Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2026-03-14interconnect: qcom: sm8450: Fix NULL pointer dereference in icc_link_nodes()Vladimir Zapolskiy
The change to dynamic IDs for SM8450 platform interconnects left two links unconverted, fix it to avoid the NULL pointer dereference in runtime, when a pointer to a destination interconnect is not valid: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 <...> Call trace: icc_link_nodes+0x3c/0x100 (P) qcom_icc_rpmh_probe+0x1b4/0x528 platform_probe+0x64/0xc0 really_probe+0xc4/0x2a8 __driver_probe_device+0x80/0x140 driver_probe_device+0x48/0x170 __device_attach_driver+0xc0/0x148 bus_for_each_drv+0x88/0xf0 __device_attach+0xb0/0x1c0 device_initial_probe+0x58/0x68 bus_probe_device+0x40/0xb8 deferred_probe_work_func+0x90/0xd0 process_one_work+0x15c/0x3c0 worker_thread+0x2e8/0x400 kthread+0x150/0x208 ret_from_fork+0x10/0x20 Code: 900310f4 911d6294 91008280 94176078 (f94002a0) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Oops: Fatal exception Fixes: 51513bec806f ("interconnect: qcom: sm8450: convert to dynamic IDs") Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://msgid.link/20260314012933.350644-1-vladimir.zapolskiy@linaro.org Signed-off-by: Georgi Djakov <djakov@kernel.org>
2026-03-14dt-bindings: thermal: qcom-tsens: Document the SM8750 Temperature SensorManaf Meethalavalappu Pallikunhi
Document the Temperature Sensor (TSENS) on the SM8750 SoC. Signed-off-by: Manaf Meethalavalappu Pallikunhi <quic_manafm@quicinc.com> Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260313-sm8750_tsens-v1-1-250fcc3794a2@oss.qualcomm.com Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org>
2026-03-13sched_ext/selftests: Fix incorrect include guard commentsCheng-Yang Chou
Fix two mismatched closing comments in header include guards: - util.h: closing comment says __SCX_TEST_H__ but the guard is __SCX_TEST_UTIL_H__ - exit_test.h: closing comment has a spurious '#' character before the guard name Signed-off-by: Cheng-Yang Chou <yphbchou0911@gmail.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2026-03-13sched_ext: Fix uninitialized ret in scx_alloc_and_add_sched()Cheng-Yang Chou
Under CONFIG_EXT_SUB_SCHED, the kzalloc() and kstrdup() failure paths jump to err_stop_helper without first setting ret. The function then returns ERR_PTR(ret) with ret uninitialized, which can produce ERR_PTR(0) (NULL), causing the caller's IS_ERR() check to pass and leading to a NULL pointer dereference. Set ret = -ENOMEM before each goto to fix the error path. Fixes: ebeca1f930ea ("sched_ext: Introduce cgroup sub-sched support") Signed-off-by: Cheng-Yang Chou <yphbchou0911@gmail.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2026-03-13selftests/sched_ext: Update scx_bpf_dsq_move_to_local() in kselftestsAndrea Righi
After commit 860683763ebf ("sched_ext: Add enq_flags to scx_bpf_dsq_move_to_local()") some of the kselftests are failing to build: exit.bpf.c:44:34: error: too few arguments provided to function-like macro invocation 44 | scx_bpf_dsq_move_to_local(DSQ_ID); Update the kselftests adding the new argument to scx_bpf_dsq_move_to_local(). Fixes: 860683763ebf ("sched_ext: Add enq_flags to scx_bpf_dsq_move_to_local()") Signed-off-by: Andrea Righi <arighi@nvidia.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2026-03-14drm/sun4i: layers: Use drm_fb_dma_get_gem_addr() to get display memoryChen-Yu Tsai
Commit 4636ce93d5b2 ("drm/fb-cma-helper: Add drm_fb_cma_get_gem_addr()") adds a new helper, which covers fetching a drm_framebuffer's GEM object and calculating the buffer address for a given plane. This patch uses this helper to replace our own open coded version of the same function. Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://patch.msgid.link/20260309165635.1138413-1-wens@kernel.org Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
2026-03-14drm/sun4i: Fix resource leaksEthan Tidmore
Three clocks are not being released in devm_regmap_init_mmio() error path. Add proper goto and set ret to the error code. Fixes: 8270249fbeaf0 ("drm/sun4i: backend: Create regmap after access is possible") Signed-off-by: Ethan Tidmore <ethantidmore06@gmail.com> Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://patch.msgid.link/20260226163836.10335-1-ethantidmore06@gmail.com Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
2026-03-14batman-adv: avoid OGM aggregation when skb tailroom is insufficientYang Yang
When OGM aggregation state is toggled at runtime, an existing forwarded packet may have been allocated with only packet_len bytes, while a later packet can still be selected for aggregation. Appending in this case can hit skb_put overflow conditions. Reject aggregation when the target skb tailroom cannot accommodate the new packet. The caller then falls back to creating a new forward packet instead of appending. Fixes: c6c8fea29769 ("net: Add batman-adv meshing protocol") Cc: stable@vger.kernel.org Reported-by: Yifan Wu <yifanwucs@gmail.com> Reported-by: Juefei Pu <tomapufckgml@gmail.com> Signed-off-by: Yuan Tan <tanyuan98@outlook.com> Signed-off-by: Xin Liu <bird@lzu.edu.cn> Signed-off-by: Ao Zhou <n05ec@lzu.edu.cn> Signed-off-by: Yang Yang <n05ec@lzu.edu.cn> Signed-off-by: Sven Eckelmann <sven@narfation.org> Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
2026-03-14arm64: dts: allwinner: h6: Add TaiqiCat (TQC) A01 supportJun Yan
TaiqiCat (TQC) A01 is a set-top box powered by an Allwinner H6 SoC, equipped with an AXP305 PMIC, 1GB LPDDR3 RAM, 8GB eMMC, an AP6212 WiFi/BT combo module, one 100M Ethernet port, one USB 3.0 Type-A port, one USB 2.0 Type-A port, one Micro USB port, HDMI, SPDIF, Micro-SD, and infrared input. It was released by Ultrapower(UQSoft) as a blockchain-based terminal and is now discontinued and no longer supported. https://web.archive.org/web/20190409213228/https://tq.ultrapower.com.cn/product.html Hardware schematics are not available at this time; however, the dts from the vendor firmware is provided for reference [1]. Based on the PCB silkscreen marking "AZW-KT02 2.0", the ODM/OEM can be confirmed as AZW, and the overall hardware circuit design is highly similar to the Beelink GS1. Tested, works: - debug UART - status LED - USB 3.0 Type-A port - USB 2.0 Type-A port - Micro USB port (Host) - MicroSD - eMMC - WiFi/Bluetooth - HDMI video output Does not work: - Ethernet (requires AC200 MFD/EPHY driver) - HDMI audio Untested: - SPDIF - IR receiver [1] https://archive.org/download/tqc-a01-stock-fw/tqc-a01-stock-fw.dts Signed-off-by: Jun Yan <jerrysteve1101@gmail.com> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://patch.msgid.link/20260304073430.438835-4-jerrysteve1101@gmail.com Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
2026-03-14dt-bindings: arm: sunxi: Add TaiqiCat (TQC) A01Jun Yan
TaiqiCat (TQC) A01 is a set-top box powered by an Allwinner H6 SoC, equipped with an AXP305 PMIC, 1GB LPDDR3 RAM, 8GB eMMC, an AP6212 WiFi/BT combo module, one 100M Ethernet port, one USB 3.0 Type-A port, one USB 2.0 Type-A port, one Micro USB port, HDMI, SPDIF, Micro-SD, and infrared input. It is a blockchain-based terminal product launched by UQSoft (Beijing UQSoft Interactive Technology Co., Ltd.), a wholly-owned subsidiary of Ultrapower. Its dedicated product homepage[1] was once hosted on Ultrapower’s official website[2]. It should be noted that UQSoft's official website[3] is no longer operational, and the company appears to have been discontinued. [1] https://web.archive.org/web/20190409213228/https://tq.ultrapower.com.cn/product.html [2] https://www.ultrapower.com.cn [3] http://www.uqsoft.com Signed-off-by: Jun Yan <jerrysteve1101@gmail.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260304073430.438835-3-jerrysteve1101@gmail.com Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
2026-03-14dt-bindings: vendor-prefixes: Add Beijing Ultrapower Software Co., Ltd.Jun Yan
Beijing Ultrapower Software Co., Ltd. is a company focusing on global mobile games, ICT services, cloud computing, and artificial intelligence solutions. TaiqiCat A01 is a blockchain-based terminal product launched by UQSoft (Beijing UQSoft Interactive Technology Co., Ltd.), a wholly-owned subsidiary of Ultrapower. Its dedicated product homepage[1] was once hosted on Ultrapower’s official website[2]. It should be noted that UQSoft's official website[3] is no longer operational, and the company appears to have been discontinued. [1] https://web.archive.org/web/20190409213228/https://tq.ultrapower.com.cn/product.html [2] https://www.ultrapower.com.cn [3] http://www.uqsoft.com Signed-off-by: Jun Yan <jerrysteve1101@gmail.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260304073430.438835-2-jerrysteve1101@gmail.com Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
2026-03-14crypto: tcrypt - stop ahash speed tests when setkey failsSaeed Mirzamohammadi
The async hash speed path ignores the return code from crypto_ahash_setkey(). If the caller picks an unsupported key length, the transform keeps whatever key state it already has and the speed test still runs, producing misleading numbers, hence bail out of the loop when setkey fails. Signed-off-by: Saeed Mirzamohammadi <saeed.mirzamohammadi@oracle.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-03-14crypto: tcrypt - clamp num_mb to avoid divide-by-zeroSaeed Mirzamohammadi
Passing num_mb=0 to the multibuffer speed tests leaves test_mb_aead_cycles() and test_mb_acipher_cycles() dividing by (8 * num_mb). With sec=0 (the default), the module prints "1 operation in ..." and hits a divide-by-zero fault. Force num_mb to at least 1 during module init and warn the caller so the warm-up loop and the final report stay well-defined. To reproduce: sudo modprobe tcrypt mode=600 num_mb=0 Signed-off-by: Saeed Mirzamohammadi <saeed.mirzamohammadi@oracle.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-03-14include/psp-sev.h: fix structure member in commentTycho Andersen (AMD)
The member is 'data', not 'opaque'. Signed-off-by: Tycho Andersen (AMD) <tycho@kernel.org> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-03-14crypto: ccp - simplify sev_update_firmware()Tycho Andersen (AMD)
sev_do_cmd() has its own command buffer (sev->cmd_buf) with the correct alignment, perms, etc. that it copies the command into, so prepending it to the firmware data is unnecessary. Switch sev_update_firmware() to using a stack allocated command in light of this copy, and drop all of the resulting pointer math. Signed-off-by: Tycho Andersen (AMD) <tycho@kernel.org> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-03-14crypto: qce - Remove return variable and unused assignmentsThorsten Blum
In qce_aead_done(), the return variable 'ret' is no longer used - remove it. And qce_aead_prepare_dst_buf() jumps directly to 'dst_tbl_free:' on error and returns 'sg' - drop the useless 'ret' assignments. Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-03-14dt-bindings: rng: atmel,at91-trng: add microchip,lan9691-trngRobert Marko
Document Microchip LAN969X TRNG compatible. Signed-off-by: Robert Marko <robert.marko@sartura.hr> Acked-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-03-14crypto: ccp - Fix leaking the same page twiceGuenter Roeck
Commit 551120148b67 ("crypto: ccp - Fix a case where SNP_SHUTDOWN is missed") fixed a case where SNP is left in INIT state if page reclaim fails. It removes the transition to the INIT state for this command and adjusts the page state management. While doing this, it added a call to snp_leak_pages() after a call to snp_reclaim_pages() failed. Since snp_reclaim_pages() already calls snp_leak_pages() internally on the pages it fails to reclaim, calling it again leaks the exact same page twice. Fix by removing the extra call to snp_leak_pages(). The problem was found by an experimental code review agent based on gemini-3.1-pro while reviewing backports into v6.18.y. Assisted-by: Gemini:gemini-3.1-pro Fixes: 551120148b67 ("crypto: ccp - Fix a case where SNP_SHUTDOWN is missed") Cc: Tycho Andersen (AMD) <tycho@kernel.org> Cc: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Reviewed-by: Tycho Andersen (AMD) <tycho@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-03-13Merge branch 'optimize-bounds-refinement-by-reordering-deductions'Alexei Starovoitov
Paul Chaignon says: ==================== Optimize bounds refinement by reordering deductions This patchset optimizes the bounds refinement (reg_bounds_sync) by reordering deductions in __reg_deduce_bounds. This reordering allows us to improve precision slightly while losing one call to __reg_deduce_bounds. The first patch from Eduard refactors the __reg_deduce_bounds subfunctions, the second patch implements the reordering, and the last one adds a selftest. Changes in v3: - Added first commit from Eduard that significantly helps with readability of second commit. - Reshuffled a bit more the functions in the second commit to improve precision (Eduard). - Rebased. Changes in v2: - Updated description to mention potential precision improvement and to clarify the sequence of refinements (Shung-Hsi). - Added the second patch. - Rebased. ==================== Link: https://patch.msgid.link/cover.1773401138.git.paul.chaignon@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-03-13selftests/bpf: Test case for refinement improvement using 64b boundsPaul Chaignon
This new selftest demonstrates the improvement of bounds refinement from the previous patch. It is inspired from a set of reg_bounds_sync inputs generated using CBMC [1] by Shung-Hsi: reg.smin_value=0x8000000000000002 reg.smax_value=2 reg.umin_value=2 reg.umax_value=19 reg.s32_min_value=2 reg.s32_max_value=3 reg.u32_min_value=2 reg.u32_max_value=3 reg_bounds_sync returns R=[2; 3] without the previous patch, and R=2 with it. __reg64_deduce_bounds is able to derive that u64=2, but before the previous patch, those bounds are overwritten in __reg_deduce_mixed_bounds using the 32bits bounds. To arrive to these reg_bounds_sync inputs, we bound the 32bits value first to [2; 3]. We can then upper-bound s64 without impacting u64. At that point, the refinement to u64=2 doesn't happen because the ranges still overlap in two points: 0 umin=2 umax=0xff..ff00..03 U64_MAX | [xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] | |----------------------------|------------------------------| |xx] [xxxxxxxxxxxxxxxxxxxxxxxxxxxx| 0 smax=2 smin=0x800..02 -1 With an upper-bound check at value 19, we can reach the above inputs for reg_bounds_sync. At that point, the refinement to u64=2 happens and because it isn't overwritten by __reg_deduce_mixed_bounds anymore, reg_bounds_sync returns with reg=2. The test validates this result by including an illegal instruction in the (dead) branch reg != 2. Link: https://github.com/shunghsiyu/reg_bounds_sync-review/ [1] Co-developed-by: Shung-Hsi Yu <shung-hsi.yu@suse.com> Signed-off-by: Shung-Hsi Yu <shung-hsi.yu@suse.com> Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> Tested-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/r/622dc51c581cd4d652fff362188b2a5f73c1fe99.1773401138.git.paul.chaignon@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-03-13bpf: Avoid one round of bounds deductionPaul Chaignon
In commit 5dbb19b16ac49 ("bpf: Add third round of bounds deduction"), I added a new round of bounds deduction because two rounds were not enough to converge to a fixed point. This commit slightly refactor the bounds deduction logic such that two rounds are enough. In [1], Eduard noticed that after we improved the refinement logic, a third call to the bounds deduction (__reg_deduce_bounds) was needed to converge to a fixed point. More specifically, we needed this third call to improve the s64 range using the s32 range. We added the third call and postponed a more detailed analysis of the refinement logic. I've been looking into this more recently. The register refinement consists of the following calls. __update_reg_bounds(); 3 x __reg_deduce_bounds() { deduce_bounds_32_from_64(); deduce_bounds_32_from_32(); deduce_bounds_64_from_64(); deduce_bounds_64_from_32(); }; __reg_bound_offset(); __update_reg_bounds(); From this, we can observe that we first improve the 32bit ranges from the 64bit ranges in deduce_bounds_32_from_64, then improve the 64bit ranges on their own in deduce_bounds_64_from_64. Intuitively, if we were to improve the 64bit ranges on their own *before* we use them to improve the 32bit ranges, we may reach a fixed point earlier. In a similar manner, using CBMC, Eduard found that it's best to improve the 32bit ranges on their own *after* we've improve them using the 64bit ranges. That is, running deduce_bounds_32_from_32 after deduce_bounds_32_from_64. These changes allow us to lose one call to __reg_deduce_bounds. Without this reordering, the test "verifier_bounds/bounds deduction cross sign boundary, negative overlap" fails when removing one call to __reg_deduce_bounds. In some cases, this change can even improve precision a little bit, as illustrated in the new selftest in the next patch. As expected, this change didn't have any impact on the number of instructions processed when running it through the Cilium complexity test suite [2]. Link: https://lore.kernel.org/bpf/aIKtSK9LjQXB8FLY@mail.gmail.com/ [1] Link: https://pchaigno.github.io/test-verifier-complexity.html [2] Acked-by: Shung-Hsi Yu <shung-hsi.yu@suse.com> Co-developed-by: Eduard Zingerman <eddyz87@gmail.com> Signed-off-by: Eduard Zingerman <eddyz87@gmail.com> Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> Link: https://lore.kernel.org/r/1b00d2749ec4c774c3ada84e265ac7fda72cfe56.1773401138.git.paul.chaignon@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-03-13bpf: better naming for __reg_deduce_bounds() partsEduard Zingerman
This renaming will also help reshuffle the different parts in the subsequent patch. Signed-off-by: Eduard Zingerman <eddyz87@gmail.com> Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> Link: https://lore.kernel.org/r/a988ecf2c57e265b97917136b14b421038534e8c.1773401138.git.paul.chaignon@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-03-13ptp: ocp: Add support for Xilinx-based Adva TimeCard variantSagi Maimon
Add support for the Adva TimeCard model built on a Xilinx-based design. This patch enables detection and integration of the new hardware within the existing OCP timecard framework. The Xilinx variant relies on the shared driver infrastructure, requiring only small, targeted additions to accommodate its specific characteristics. Signed-off-by: Sagi Maimon <maimon.sagi@gmail.com> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Link: https://patch.msgid.link/20260312082009.249622-1-maimon.sagi@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-13Merge branch 'udp-retire-udp-lite'Jakub Kicinski
Kuniyuki Iwashima says: ==================== udp: Retire UDP-Lite. In 2023, syzbot found a null-ptr-deref bug triggered when UDP-Lite attempted to charge an skb after the total memory usage for UDP-Lite _and_ UDP exceeded a system-wide threshold, net.ipv4.udp_mem[1]. Since this threshold is shared with UDP, the bug would have been easy to trigger if any real-world applications were using UDP-Lite; however, only syzbot ever stumbled upon it. The bug had persisted since 2016, suggesting that UDP-Lite had remained unused for 7 years at that point. The bug was fixed in commit ad42a35bdfc6 ("udplite: Fix NULL pointer dereference in __sk_mem_raise_allocated()."), and we added another commit be28c14ac8bb ("udplite: Print deprecation notice.") to announce the deprecation plan. Since then, no one has complained, so it is time to officially retire UDP-Lite. This series first removes IPv6 and IPv4 UDP-Lite sockets, then gradually cleans up the remaining dead/unnecessary code within the UDP stack. By removing a bunch of conditionals for UDP-Lite from the fast path, udp_rr with 20,000 flows sees a 10% increase in pps (13.3 Mpps -> 14.7 Mpps) on an AMD EPYC 7B12 (Zen 2) 64-Core Processor platform. [ With FDO, the baseline is much higher and the delta was ~3%, 20.1 Mpps -> 20.7 Mpps ] Before: $ nstat > /dev/null; sleep 1; nstat | grep Udp Udp6InDatagrams 14013408 0.0 Udp6OutDatagrams 14013128 0.0 After: $ nstat > /dev/null; sleep 1; nstat | grep Udp Udp6InDatagrams 15491971 0.0 Udp6OutDatagrams 15491671 0.0 $ ./scripts/bloat-o-meter vmlinux.before vmlinux.after add/remove: 13/75 grow/shrink: 11/75 up/down: 13777/-18401 (-4624) Function old new delta udp4_gro_receive 872 866 -6 udp6_gro_receive 910 903 -7 udp_rcv 32 1727 +1695 udpv6_rcv 32 1450 +1418 __udp4_lib_rcv 2045 - -2045 __udp6_lib_rcv 2084 - -2084 udp_unicast_rcv_skb 160 149 -11 udp6_unicast_rcv_skb 196 181 -15 __udp4_lib_mcast_deliver 925 846 -79 __udp6_lib_mcast_deliver 922 810 -112 __udp4_lib_lookup 973 969 -4 __udp6_lib_lookup 940 929 -11 __udp4_lib_lookup_skb 106 100 -6 __udp6_lib_lookup_skb 71 66 -5 udp4_lib_lookup_skb 132 127 -5 udp6_lib_lookup_skb 87 81 -6 udp_queue_rcv_skb 326 356 +30 udpv6_queue_rcv_skb 331 361 +30 udp_queue_rcv_one_skb 1233 914 -319 udpv6_queue_rcv_one_skb 1250 930 -320 __udp_enqueue_schedule_skb 1067 995 -72 udp_rcv_segment 520 480 -40 udp_post_segment_fix_csum 120 - -120 udp_lib_checksum_complete 200 84 -116 udp_err 27 1103 +1076 udpv6_err 36 1417 +1381 __udp4_lib_err 1112 - -1112 __udp6_lib_err 1448 - -1448 udp_recvmsg 1149 994 -155 udpv6_recvmsg 1349 1294 -55 udp_sendmsg 2730 2648 -82 udp_send_skb 909 681 -228 udpv6_sendmsg 3022 2861 -161 udp_v6_send_skb 1214 952 -262 ... Total: Before=18446744073748075501, After=18446744073748070877, chg -0.00% ==================== Link: https://patch.msgid.link/20260311052020.1213705-1-kuniyu@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-13udp: Don't pass proto to __udp4_lib_rcv() and __udp6_lib_rcv().Kuniyuki Iwashima
UDP and UDP-Lite shared __udp4_lib_rcv() and __udp6_lib_rcv() by passing IPPROTO_UDP or IPPROTO_UDPLITE. Now, @proto is always IPPROTO_UDP. Let's not pass it and rename the functions accordingly. With this series removing a bunch of conditionals for UDP-Lite from the fast path, udp_rr with 20,000 flows sees a 10% increase in pps (13.3 Mpps -> 14.7 Mpps) on an AMD EPYC 7B12 (Zen 2) 64-Core Processor platform. [ With FDO, the baseline is much higher and the delta was ~3%, 20.1 Mpps -> 20.7 Mpps ] Before: $ nstat > /dev/null; sleep 1; nstat | grep Udp Udp6InDatagrams 14013408 0.0 Udp6OutDatagrams 14013128 0.0 After: $ nstat > /dev/null; sleep 1; nstat | grep Udp Udp6InDatagrams 15491971 0.0 Udp6OutDatagrams 15491671 0.0 $ ./scripts/bloat-o-meter vmlinux.before vmlinux.after add/remove: 13/75 grow/shrink: 11/75 up/down: 13777/-18401 (-4624) Function old new delta udp4_gro_receive 872 866 -6 udp6_gro_receive 910 903 -7 udp_rcv 32 1727 +1695 udpv6_rcv 32 1450 +1418 __udp4_lib_rcv 2045 - -2045 __udp6_lib_rcv 2084 - -2084 udp_unicast_rcv_skb 160 149 -11 udp6_unicast_rcv_skb 196 181 -15 __udp4_lib_mcast_deliver 925 846 -79 __udp6_lib_mcast_deliver 922 810 -112 __udp4_lib_lookup 973 969 -4 __udp6_lib_lookup 940 929 -11 __udp4_lib_lookup_skb 106 100 -6 __udp6_lib_lookup_skb 71 66 -5 udp4_lib_lookup_skb 132 127 -5 udp6_lib_lookup_skb 87 81 -6 udp_queue_rcv_skb 326 356 +30 udpv6_queue_rcv_skb 331 361 +30 udp_queue_rcv_one_skb 1233 914 -319 udpv6_queue_rcv_one_skb 1250 930 -320 __udp_enqueue_schedule_skb 1067 995 -72 udp_rcv_segment 520 480 -40 udp_post_segment_fix_csum 120 - -120 udp_lib_checksum_complete 200 84 -116 udp_err 27 1103 +1076 udpv6_err 36 1417 +1381 __udp4_lib_err 1112 - -1112 __udp6_lib_err 1448 - -1448 udp_recvmsg 1149 994 -155 udpv6_recvmsg 1349 1294 -55 udp_sendmsg 2730 2648 -82 udp_send_skb 909 681 -228 udpv6_sendmsg 3022 2861 -161 udp_v6_send_skb 1214 952 -262 ... Total: Before=18446744073748075501, After=18446744073748070877, chg -0.00% Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20260311052020.1213705-16-kuniyu@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-13udp: Don't pass udptable to IPv4 socket lookup functions.Kuniyuki Iwashima
Since UDP and UDP-Lite had dedicated socket hash tables for each, we have had to pass the pointer down to many socket lookup functions. UDP-Lite gone, and we do not need to do that. Let's fetch net->ipv4.udp_table only where needed in IPv4 stack: __udp4_lib_lookup(), __udp4_lib_mcast_deliver(), and udp_diag_dump(). Some functions are renamed as the wrapper functions are no longer needed. __udp4_lib_err() -> udp_err() __udp_diag_destroy() -> udp_diag_destroy() udp_dump_one() -> udp_diag_dump_one() udp_dump() -> udp_diag_dump() Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20260311052020.1213705-15-kuniyu@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>