summaryrefslogtreecommitdiff
path: root/Documentation
AgeCommit message (Collapse)Author
2026-03-24dt-bindings: timer: fsl,imxgpt: add compatible string fsl,imx25-epitFrank Li
Add compatible string fsl,imx25-epit to fix below CHECK_DTBS warnings: arch/arm/boot/dts/nxp/imx/imx25-eukrea-mbimxsd25-baseboard-dvi-svga.dtb: /soc/bus@53f00000/timer@53f94000: failed to match any schema with compatible: ['fsl,imx25-epit'] Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260211214947.3705328-1-Frank.Li@nxp.com
2026-03-24ASoC: Merge up fixesMark Brown
Merge branch 'for-7.0' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into asoc-7.1 to get fixes into our development branch and resolve interactions with the match tables.
2026-03-24f2fs: Add defrag_blocks sysfs nodeliujinbao1
Add the defrag_blocks sysfs node to track the amount of data blocks moved during filesystem defragmentation. Signed-off-by: Sheng Yong <shengyong1@xiaomi.com> Signed-off-by: liujinbao1 <liujinbao1@xiaomi.com> Reviewed-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2026-03-24dt-bindings: arm: rockchip: Add Omega4 Evaluation boardFabio Estevam
Onion Omega4 board is a board based on the RV1103B SoC. Document its compatible. Signed-off-by: Fabio Estevam <festevam@nabladev.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://patch.msgid.link/20260313131058.708361-3-festevam@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-03-24dt-bindings: soc: rockchip: grf: Add RV1103B compatiblesFabio Estevam
Add the PMU GRF and IOC compatible strings for the RV1103B SoC. Signed-off-by: Fabio Estevam <festevam@nabladev.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260313131058.708361-1-festevam@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-03-24dt-bindings: display: arm,komeda: add Arm China Linlon D6 compatibleCunyuan Liu
Add the Arm China Linlon D6 display controller compatible string. Linlon D6 is register-compatible with Mali-D71, so describe it as a vendor-specific compatible with a fallback to "arm,mali-d71". Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Cunyuan Liu <cunyuan.liu@cixtech.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patch.msgid.link/20260313033119.33686-3-cunyuan.liu@cixtech.com
2026-03-24dt-bindings: vendor-prefixes: Add Arm Technology (China) Co., Ltd.Cunyuan Liu
Add "armchina" vendor prefix for Arm Technology (China) Co., Ltd. Link: https://www.armchina.com/ Acked-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Cunyuan Liu <cunyuan.liu@cixtech.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patch.msgid.link/20260313033119.33686-2-cunyuan.liu@cixtech.com
2026-03-24ASoc: uda1380: Improve error reportingMark Brown
Wenyuan Li <2063309626@qq.com> says: The driver currently ignores the return values of several I2C operations during register writes, which could lead to silent failures and inconsistent device state. Link: https://patch.msgid.link/tencent_579D057AC557914CF739A2D9EAD045CE7306@qq.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-03-24hwmon: (peci/cputemp) Fix crit_hyst returning delta instead of absolute ↵Sanman Pradhan
temperature The hwmon sysfs ABI expects tempN_crit_hyst to report the temperature at which the critical condition clears, not the hysteresis delta from the critical limit. The peci cputemp driver currently returns tjmax - tcontrol for crit_hyst_type, which is the hysteresis margin rather than the corresponding absolute temperature. Return tcontrol directly, and update the documentation accordingly. Fixes: bf3608f338e9 ("hwmon: peci: Add cputemp driver") Cc: stable@vger.kernel.org Signed-off-by: Sanman Pradhan <psanman@juniper.net> Link: https://lore.kernel.org/r/20260323002352.93417-2-sanman.pradhan@hpe.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-03-24iommu/arm-smmu-v3: Update Arm errataRobin Murphy
MMU-700 r1p1 has subsequently fixed some of the errata for which we've been applying the workarounds unconditionally, so we can now make those conditional. However, there have also been some more new cases identified where we must rely on range invalidation commands, and thus still nominally avoid DVM being inadvertently enabled. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-03-24platform/x86: bitland-mifs-wmi: Add new Bitland MIFS WMI driverMingyou Chen
Add a new driver for Bitland laptops that utilize the MIFS (MiInterface) WMI interface. The driver implements several features through the WMI interface: - Platform Profile: Supports "Quiet", "Balanced", "Performance", and "Full Speed" modes. The "Full Speed" mode is intelligently restricted based on the AC adapter type (requires DC power, not supported on USB-C charging) as required by the hardware. - Hwmon: Provides monitoring for CPU, GPU, and System fan speeds, as well as CPU temperature sensors. - Keyboard Backlight: Integrated with the LED class device for brightness control and provides sysfs attributes for keyboard modes (cyclic, fixed, etc.). - GPU Mode: Allows switching between Hybrid, Discrete, and UMA graphics modes via sysfs. - Hotkeys: Handles WMI events for system hotkeys (Calculator, Browser, App launch) using sparse keymaps and reports status changes for Airplane mode, Touchpad, and CapsLock. - Fan Boost: Provides a sysfs interface to force fans to maximum speed. The driver registers two WMI GUIDs: - B60BFB48-3E5B-49E4-A0E9-8CFFE1B3434B: Control methods - 46C93E13-EE9B-4262-8488-563BCA757FEF: Event notifications Reviewed-by: Armin Wolf <W_Armin@gmx.de> Signed-off-by: Mingyou Chen <qby140326@gmail.com> Link: https://patch.msgid.link/20260323132218.444383-1-qby140326@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-03-24ASoC: dt-bindings: stm32: Fix incorrect compatible string in stm32h7-sai matchJihed Chaibi
The conditional block that defines clock constraints for the stm32h7-sai variant references "st,stm32mph7-sai", which does not match any compatible string in the enum. As a result, clock validation for the h7 variant is silently skipped. Correct the compatible string to "st,stm32h7-sai". Fixes: 8509bb1f11a1f ("ASoC: dt-bindings: add stm32mp25 support for sai") Signed-off-by: Jihed Chaibi <jihed.chaibi.dev@gmail.com> Reviewed-by: Olivier Moysan <olivier.moysan@foss.st.com> Link: https://patch.msgid.link/20260321012011.125791-1-jihed.chaibi.dev@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-03-24Merge branch 'ib-scmi-pinctrl-gpio' into develLinus Walleij
2026-03-24gpio: dt-bindings: Add GPIO on top of generic pin controlAKASHI Takahiro
Traditionally, firmware will provide a GPIO interface or a pin control interface. However, the SCMI protocol provides a generic pin control interface and the GPIO support is built on top of that using the normal pin control interfaces. Potentially, other firmware will adopt a similar generic approach in the future. Document how to configure the GPIO device. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Linus Walleij <linusw@kernel.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-03-24perf: add NVIDIA Tegra410 C2C PMUBesar Wicaksono
Adds NVIDIA C2C PMU support in Tegra410 SOC. This PMU is used to measure memory latency between the SOC and device memory, e.g GPU Memory (GMEM), CXL Memory, or memory on remote Tegra410 SOC. Reviewed-by: Ilkka Koskinen <ilkka@os.amperecomputing.com> Signed-off-by: Besar Wicaksono <bwicaksono@nvidia.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-03-24perf: add NVIDIA Tegra410 CPU Memory Latency PMUBesar Wicaksono
Adds CPU Memory (CMEM) Latency PMU support in Tegra410 SOC. The PMU is used to measure latency between the edge of the Unified Coherence Fabric to the local system DRAM. Reviewed-by: Ilkka Koskinen <ilkka@os.amperecomputing.com> Signed-off-by: Besar Wicaksono <bwicaksono@nvidia.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-03-24perf/arm_cspmu: nvidia: Add Tegra410 PCIE-TGT PMUBesar Wicaksono
Adds PCIE-TGT PMU support in Tegra410 SOC. This PMU is instanced in each root complex in the SOC and it captures traffic originating from any source towards PCIE BAR and CXL HDM range. The traffic can be filtered based on the destination root port or target address range. Reviewed-by: Ilkka Koskinen <ilkka@os.amperecomputing.com> Signed-off-by: Besar Wicaksono <bwicaksono@nvidia.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-03-24perf/arm_cspmu: nvidia: Add Tegra410 PCIE PMUBesar Wicaksono
Adds PCIE PMU support in Tegra410 SOC. This PMU is instanced in each root complex in the SOC and can capture traffic from PCIE device to various memory types. This PMU can filter traffic based on the originating root port or BDF and the target memory types (CPU DRAM, GPU Memory, CXL Memory, or remote Memory). Reviewed-by: Ilkka Koskinen <ilkka@os.amperecomputing.com> Signed-off-by: Besar Wicaksono <bwicaksono@nvidia.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-03-24perf/arm_cspmu: nvidia: Add Tegra410 UCF PMUBesar Wicaksono
The Unified Coherence Fabric (UCF) contains last level cache and cache coherent interconnect in Tegra410 SOC. The PMU in this device can be used to capture events related to access to the last level cache and memory from different sources. Reviewed-by: Ilkka Koskinen <ilkka@os.amperecomputing.com> Signed-off-by: Besar Wicaksono <bwicaksono@nvidia.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-03-24perf/arm_cspmu: nvidia: Rename doc to Tegra241Besar Wicaksono
The documentation in nvidia-pmu.rst contains PMUs specific to NVIDIA Tegra241 SoC. Rename the file for this specific SoC to have better distinction with other NVIDIA SoC. Signed-off-by: Besar Wicaksono <bwicaksono@nvidia.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-03-24media: dt-bindings: ovti,ov8856: Allow orientation & rotation propsAlexander Koskovich
Allow the orientation and rotation properties from video-interface-devices to be specified. The sensor can be front or rear facing and can be mounted at any rotation. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Alexander Koskovich <akoskovich@pm.me> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-03-24dt-bindings: media: st,stm32-dcmi: add 'power-domains' propertyAlain Volmat
STM32 DCMI may be in a power domain which is the case for the STM32MP2x based boards. Allow a single 'power-domains' entry for STM32 DCMI. Signed-off-by: Alain Volmat <alain.volmat@foss.st.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-03-24media: uapi: Clarify MBUS color component order for serial busesMaxime Ripard
The subdev format documentation has a subsection describing how to use the media bus pixel codes for serial buses. While it describes the sampling part well, it doesn't really describe the current convention used for the components order. Let's improve that. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-03-24dt-bindings: PCI: cix,sky1-pcie-host: Add power-domainsGary Yang
The Sky1 PCIe controller resides in a dedicated power domain managed via SCMI. Add the power-domains property to the binding to allow describing this dependency. Signed-off-by: Gary Yang <gary.yang@cixtech.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260313114914.1564115-2-gary.yang@cixtech.com
2026-03-23drm/doc: Update documentation for 'none' recovery methodRaag Jadav
Expand 'none' recovery method for wedged event to include debug cases where driver wants to hint "no recovery" without resetting the device from driver context. Signed-off-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260305130720.3685754-2-raag.jadav@intel.com
2026-03-23dt-bindings: firmware: qcom,scm: document Eliza SCM Firmware InterfaceAbel Vesa
Document the SCM Firmware Interface on the Eliza SoC. Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260311-eliza-bindings-scm-v2-1-b2d2e69068e3@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-23dt-bindings: media: venus: Fix iommus propertySumit Garg
Fix IOMMU DT propety for venus via dropping SMMU stream IDs which relates to secure context bank. Assigning Linux kernel (HLOS) VMID to secure context bank stream IDs is incorrect. The maximum value for iommus property is updated accordingly. These DT bindings changes should be backwards compatible. Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Link: https://lore.kernel.org/r/20260122121042.579270-3-sumit.garg@kernel.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-23dt-bindings: display: msm: qcm2290-mdss: Fix iommus propertySumit Garg
Fix IOMMU DT propety for display via dropping SMMU stream IDs which relates to secure context bank. Assigning Linux kernel (HLOS) VMID to secure context bank stream IDs is incorrect. The maximum value for iommus property is updated accordingly. These DT bindings changes should be backwards compatible. Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Link: https://lore.kernel.org/r/20260122121042.579270-2-sumit.garg@kernel.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-23clk: baikal-t1: Remove not-going-to-be-supported code for Baikal SoCAndy Shevchenko
As noticed in the discussion [1] the Baikal SoC and platforms are not going to be finalized, hence remove stale code. Reviewed-by: Brian Masney <bmasney@redhat.com> Link: https://lore.kernel.org/lkml/22b92ddf-6321-41b5-8073-f9c7064d3432@infradead.org/ [1] Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2026-03-23regulator: cros-ec: cleanup and add suppliesMark Brown
Chen-Yu Tsai <wenst@chromium.org> says: This series is part of a broader collection of regulator related cleanups for MediaTek Chromebooks. This one covers the regulators exposed by the ChromeOS Embedded Controller. Patch 1 adds the names of the power supply inputs to the binding. Patch 2 adds the supply names from the DT binding change in patch 1 to the regulator descriptions in the driver. This patch has a checkpatch.pl warnings, but I wonder if it's because the context size for checking complex macros is not large enough. Device tree changes will be sent separately. The goal is to get the regulator tree as complete as possible. This includes adding supply names to other regulator DT bindings, and adding all the supply links to the existing DTs.
2026-03-23regulator: dt-bindings: cros-ec: Add regulator supplyChen-Yu Tsai
Even a regulator remotely controlled by the EC will have a power supply input. Add a property to describe the power supply input. Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Link: https://patch.msgid.link/20260320083135.2455444-2-wenst@chromium.org Signed-off-by: Mark Brown <broonie@kernel.org>
2026-03-23spi: hisi-kunpeng cleanup and fixMark Brown
Pei Xiao <xiaopei01@kylinos.cn> says: I might have wasted your valuable time again. Please help check the two modifications. Thank you!
2026-03-23Documentation: PCI: Document PCIe TLP Header decoder for AER messagesLukas Wunner
The prefix/header of a TLP that caused an error may be recorded in the AER Capability and emitted to the kernel log in raw hex format. Document the existence and usage of tlp-tool, which decodes the TLP Header into human-readable form. The TLP Header hints at the root cause of an error, yet is often ignored because of its seeming opaqueness. Instead, PCIe errors are frequently worked around by a change in the kernel without fully understanding the actual source of the problem. With more documentation on available tools we'll hopefully come up with better solutions. There are also wireshark dissectors for TLPs, but it seems they expect a complete TLP, not just the header, and they cannot grok the hex format emitted by the kernel directly. tlp-tool appears to be the most cut and dried solution out there. Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Maciej Grochowski <mx2pg@pm.me> Link: https://patch.msgid.link/bf826c41b4c1d255c7dcb16e266b52f774d944ed.1774246067.git.lukas@wunner.de
2026-03-23Merge tag 'drm-misc-next-2026-03-12' into drm-rust-nextDanilo Krummrich
We need the latest GPU buddy changes from drm-misc-next-2026-03-12 in drm-rust-next as well, as the Rust abstractions are built on top of it. Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-23Merge branch ↵Bjorn Andersson
'20260319-clk-qcom-dispcc-eliza-v3-1-d1f2b19a6e6b@oss.qualcomm.com' into clk-for-7.1 Merge the Eliza display clock controller binding through a topic branch, to allow the constants to be shared with the DeviceTree branch.
2026-03-23dt-bindings: clock: qcom,eliza-dispcc: Add Eliza SoC display CCKrzysztof Kozlowski
Add bindings for Qualcomm Eliza SoC display clock controller (dispcc), which is very similar to one in SM8750, except new HDMI-related clocks and additional clock input from HDMI PHY PLL. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260319-clk-qcom-dispcc-eliza-v3-1-d1f2b19a6e6b@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-23dt-bindings: mmc: Add sdhci support for Canaan k230Jiayu Du
The Canaan k230 uses the SDHCI from Synopsys. Add compatible strings to the k230. The k230 has two controllers. MMC0 supports eMMC, while MMC1 supports SDIO. Signed-off-by: Jiayu Du <jiayu.riscv@isrc.iscas.ac.cn> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2026-03-23dt-bindings: mmc: snps,dwcmshc-sdhci: add HPE GSC dwcmshc compatibleNick Hawkins
Add the 'hpe,gsc-dwcmshc' compatible string for the HPE GSC (ARM64 Cortex-A53) BMC SoC eMMC controller. The HPE GSC requires access to the MSHCCS register in the SoC system register block to configure SCG sync disable for HS200 RX delay-line phase selection. The required 'hpe,gxp-sysreg' property takes a phandle to the existing 'hpe,gxp-sysreg' syscon and the MSHCCS register offset within that block. The HPE GSC eMMC interface only exposes a single 'core' clock (no bus clock), so clocks/clock-names are constrained to a single item. Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2026-03-23dt-bindings: mmc: rockchip-dw-mshc: Fix the RV1103B compatibleFabio Estevam
RV1103B uses the same DesignWare MSHC controller IP version as RK3576. They have no "ciu-drive" nor "ciu-sample" clocks and use the phase tuning inside the controller. Fix it accordingly. Fixes: 517b1e3c9455 ("dt-bindings: mmc: rockchip-dw-mshc: Add RV1103B compatible") Suggested-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Fabio Estevam <festevam@nabladev.com> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2026-03-23media: dt-bindings: rockchip,vdec: Add alternative reg-names order for ↵Cristian Ciocaltea
RK35{76,88} With the introduction of the RK3588 SoC, and RK3576 afterwards, three register blocks have been provided for the video decoder unit instead of just one, which are further referenced in vendor's datasheet by 'link table', 'function' and 'cache'. The former is present at the top of the listing, starting at video decoder unit base address. However, while documenting RK3588, the binding broke the convention expecting the unit address to indicate the start of the primary register range, i.e. the 'function' block got listed before the 'link' one. Since the binding changes have been already released and a fix would bring up an ABI break, mark the current 'reg-names' ordering as deprecated and introduce an alternative 'link,function,cache' listing which follows the address-based ordering according to the TRM. Additionally, drop the 'reg' description items as the order is not fixed anymore, while the information they offer is not very relevant anyway. It's worth noting there are currently no (known) users impacted by these binding changes, since the video decoder support for the aforementioned SoCs in mainline driver and devicetrees hasn't been released yet - it landed in v7.0-rc1 while all DTS updates resulting from this will be handled before v7.0 is out. Fixes: c6ffb7e1fb90 ("media: dt-bindings: rockchip: Document RK3588 Video Decoder bindings") Fixes: a5c4a6526476 ("media: dt-bindings: rockchip: Add RK3576 Video Decoder bindings") Cc: stable@vger.kernel.org Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-03-23media: dt-bindings: rockchip,vdec: Mark reg-names required for RK35{76,88}Cristian Ciocaltea
The Rockchip Video Decoder driver expects reg-names to be mandatory for RK3576 and RK3588 SoCs, however the binding does not currently require the use of them. As a consequence, driver would fail to probe with a hypothetical devicetree that doesn't provide the reg-names for these SoCs, but which is otherwise a perfectly valid DT from the binding perspective. Update the binding and make reg-names required for the aforementioned SoCs. While this change introduces an ABI break, the expected impact on potential users would be minimal, if any, since the old SoCs are unaffected, while the video decoder support for these newer variants in mainline driver and devicetrees hasn't been released yet. Moreover, this is also a prerequisite for a subsequent binding update introducing an alternative reg-names order, according to the address-based listing in the vendor's datasheet. Reported-by: Conor Dooley <conor@kernel.org> Closes: https://lore.kernel.org/all/20260227-urologist-gratitude-7984733f2d41@spud/ Fixes: c6ffb7e1fb90 ("media: dt-bindings: rockchip: Document RK3588 Video Decoder bindings") Fixes: a5c4a6526476 ("media: dt-bindings: rockchip: Add RK3576 Video Decoder bindings") Cc: stable@vger.kernel.org Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-03-23dt-bindings: npu: arm,ethos: Add "arm,corstone1000-ethos-u85"Rob Herring (Arm)
The Corstone-1000-A320 platform contains an Ethos-U85 NPU. Add a specific compatible for it. Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Message-Id: <20260320-dt-corstone1000-a320-v1-2-a549dfcfe8da@kernel.org> Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-03-23dt-bindings: arm,corstone1000: Add "arm,corstone1000-a320-fvp"Rob Herring (Arm)
The Arm Corstone1000-A320 is a variation of the Corstone1000 with Cortex-A320 cores and an Ethos-U85 NPU. An FVP for the platform is available here[1]. [1] https://developer.arm.com/Tools%20and%20Software/Fixed%20Virtual%20Platforms/IoT%20FVPs Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Message-Id: <20260320-dt-corstone1000-a320-v1-1-a549dfcfe8da@kernel.org> Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-03-23dt-bindings: gpio: fix microchip,mpfs-gpio interrupt documentationConor Dooley
The microchip,mpfs-gpio binding suffered greatly due to being written with a narrow minded view of the controller, and the interrupt bits ended up incorrect. It was mistakenly assumed that the interrupt configuration was set by platform firmware, based on the FPGA configuration, and that the GPIO DT nodes were the only way to really communicate interrupt configuration to software. Instead, the mux should be a device in its own right, and the GPIO controllers should be connected to it, rather than to the PLIC. Now that a binding exists for that mux, try to fix the misconceptions in the GPIO controller binding. Firstly, it's not possible for this controller to have fewer than 14 GPIOs, and thus 14 interrupts also. There are three controllers, with 14, 24 & 32 GPIOs each. The fabric core, CoreGPIO, can of course have a customisable number of GPIOs. The example is wacky too - it follows from the incorrect understanding that the GPIO controllers are connected to the PLIC directly. They are not however, with a mux sitting in between. Update the example to use the mux as a parent, and the interrupt numbers at the mux for GPIO2 as the example - rather than the strange looking, repeated <53>. Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Linus Walleij <linusw@kernel.org> Link: https://patch.msgid.link/20260318-fondly-tradition-90b8241f0cc8@spud Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-03-23dt-bindings: pinctrl: realtek: Add RTD1625 pinctrl bindingTzuyi Chang
Add device tree bindings for RTD1625. Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Linus Walleij <linusw@kernel.org> Signed-off-by: Tzuyi Chang <tychang@realtek.com> Co-developed-by: Yu-Chun Lin <eleanor.lin@realtek.com> Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com> Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-03-23dt-bindings: pinctrl: realtek: Improve 'realtek,duty-cycle' descriptionYu-Chun Lin
The previous description was misleading because this hardware block is not a PWM generator. It does not generate a signal with a specific frequency and duty ratio. Instead, it provides a fixed nanosecond-level adjustment to the rising/ falling edges of an existing signal. The property name is kept as 'realtek,duty-cycle' rather than being renamed to strictly preserve Device Tree ABI backward compatibility. Acked-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Linus Walleij <linusw@kernel.org> Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com> Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-03-23dt-bindings: pincfg-node: Add input-threshold-voltage-microvolt propertyTzuyi Chang
Add a generic pin configuration property "input-threshold-voltage-microvolt" to support hardware designs where the input logic threshold is decoupled from the power supply voltage. This property allows the pinctrl driver to configure the correct internal reference voltage for pins that need to accept input signals at a different voltage level than their power supply. For example, a pin powered by 3.3V may need to accept 1.8V logic signals. This defines the reference for VIH (Input High Voltage) and VIL (Input Low Voltage) thresholds, enabling proper signal detection across different voltage domains. Signed-off-by: Tzuyi Chang <tychang@realtek.com> Co-developed-by: Yu-Chun Lin <eleanor.lin@realtek.com> Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-03-23Merge 7.0-rc5 into tty-nextGreg Kroah-Hartman
We need the tty/serial fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-03-23Merge tag 'drm-misc-next-2026-03-20' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next for v7.1: UAPI Changes: math: - provide __KERNEL_DIV_ROUND_CLOSEST() in UAPI mode: - provide DRM_ARGB_GET*() macros for reading color components Cross-subsystem Changes: math: - implement DIV_ROUND_CLOSEST() with __KERNEL_DIV_ROUND_CLOSEST() Core Changes: atomic: - fix handling of colorop state in atomic updates - provide CRTC background color ttm: - improve tests and doumentation Driver Changes: amdxdna: - allow forcing DMA through IOMMU IOVA - improve debugging bridge: - Support Lontium LT8713SX DP MST bridge plus DT bindings imx: - support planes behind the primary plane - fix bus-format selection ivpu: - perform engine reset on TDR error panel: - novatek-nt36672a: Use mipi_dsi_*_multi() functions - panel-edp: Support BOE NV153WUM-N42, CMN N153JCA-ELK, CSW MNF307QS3-2 renesas: - rz-du: clean up rockchip: - support CRTC background color sun4i: - fix leak in init code - clean up tildc - clean up v3d: - improve handling of struct v3d_stats - improve error handling - clean up vkms: - support CRTC background color Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260320082604.GA17867@linux.fritz.box
2026-03-22docs: use logo.svg as faviconRito Rhymes
Use the existing documentation logo as the HTML favicon. This makes generated documentation pages use a matching browser tab icon without introducing a separate favicon asset. Signed-off-by: Rito Rhymes <rito@ritovision.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <20260321125532.9568-1-rito@ritovision.com>