Jishnu Prakash [Mon, 23 Mar 2026 06:19:41 +0000 (23:19 -0700)]
arm64: dts: qcom: kaanapali: Add PMIC devices
Add a spmi-pmic-arb device for the SPMI PMIC arbiter found on Kaanapali.
It has two subnodes corresponding to the SPMI0 bus controller and the
SPMI1 bus controller.
Also add dtsi files for PMH0104, PMH0110, PMD8028, PMIH0108, PMR735D
and PM8010 along with temp-alarm and GPIO nodes under them, which are
needed on Kaanapali.
Taniya Das [Wed, 25 Feb 2026 07:19:24 +0000 (23:19 -0800)]
arm64: dts: qcom: kaanapali: Add support for MM clock controllers for Kaanapali
Add the device nodes for the multimedia clock controllers (cambistmclkcc,
camcc, dispcc, videocc, gpucc and gxclkctl).
Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260224-knp-dts-misc-v6-9-79d20dab8a60@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Prasad Kumpatla [Wed, 25 Feb 2026 07:19:23 +0000 (23:19 -0800)]
arm64: dts: qcom: kaanapali-mtp: Add audio support (WSA8845, WCD9395, DMIC)
Add support for audio on the Kaanapali MTP platform by introducing device
tree nodes for WSA8845 smart speaker amplifier for playback, DMIC
microphone for capture, and sound card routing. The WCD9395 codec is add
to supply MIC-BIAS, for enabling onboard microphone capture.
Prasad Kumpatla [Wed, 25 Feb 2026 07:19:20 +0000 (23:19 -0800)]
arm64: dts: qcom: kaanapali: Add support for audio
Introduce audio support for Kaanapali SoC by adding LPASS macro codecs,
TLMM pin controller and SoundWire controller with similar hardware
implementation to SM8750 platform. Also add GPR (Generic Pack Router) node
along with support for APM (Audio Process Manager) and PRM
(Proxy Resource Manager) audio services.
Signed-off-by: Prasad Kumpatla <prasad.kumpatla@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260224-knp-dts-misc-v6-5-79d20dab8a60@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
arm64: dts: qcom: kaanapali: Add TSENS and thermal zones
The Kaanapali includes seven TSENS instances, with a total of 55 thermal
sensors distributed across various locations on the SoC.
The TSENS max/reset threshold is configured to 130°C in the hardware.
Enable all TSENS instances, and define the thermal zones with a hot trip
at 120°C and critical trip at 125°C.
Signed-off-by: Manaf Meethalavalappu Pallikunhi <manaf.pallikunhi@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260224-knp-dts-misc-v6-3-79d20dab8a60@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
arm64: dts: qcom: kaanapali: Add QUPv3 configuration for serial engines
Add device tree support for QUPv3 serial engine protocols on Kaanapali.
Kaanapali has 24 QUP serial engines across 4 QUP wrappers, each with
support of GPI DMA engines, and it also includes 5 I2C hubs.
Jie Gan [Wed, 25 Feb 2026 07:19:16 +0000 (23:19 -0800)]
arm64: dts: qcom: kaanapali: add coresight nodes
Add CoreSight nodes to enable trace paths such as TPDM->ETF and STM->ETF.
These devices are part of the AOSS, CDSP, QDSS, modem and some small
subsystems, such as DCC, GCC, ipcc and so on.
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260224-knp-dts-misc-v6-1-79d20dab8a60@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Pradeep P V K [Wed, 11 Feb 2026 13:29:25 +0000 (18:59 +0530)]
arm64: dts: qcom: hamoa: Add UFS nodes for x1e80100 SoC
Add UFS host controller and PHY nodes for x1e80100 SoC.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Reviewed-by: Taniya Das <taniya.das@oss.qualcomm.com> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Pradeep P V K <pradeep.pragallapati@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260211132926.3716716-3-pradeep.pragallapati@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Loic Poulain [Fri, 13 Mar 2026 10:38:21 +0000 (10:38 +0000)]
arm64: dts: qcom: Add Arduino Monza (VENTUNO Q) board support
Add device tree support for the Arduino VENTUNO Q board,
based on the Qualcomm QCS8300 (Monaco) SoC.
The board features a Qualcomm Monza SoM and integrates various
peripherals, including:
- USB Type‑C connector with dual‑role support
- ADV7535 DSI‑to‑HDMI bridge
- MAX98091 audio codec
- 2.5G Ethernet PHY (HSGMII)
- PCIe0 (to onboard WiFi chipset and USB bridge)
- PCIe1 (to M2/nvme)
- Button (via GPIO‑keys)
Loic Poulain [Fri, 13 Mar 2026 10:38:19 +0000 (10:38 +0000)]
arm64: dts: qcom: Add Monaco Monza SoM
The Monaco Monza SoM is a compact computing module that integrates a
Monaco/QCS8300 System on Chip (SoC), along with essential components
optimized for IoT applications. It is designed to be mounted on
carrier boards, enabling the development of complete embedded systems.
The following components are described:
- Fixed S2S 1.8V rail
- PMM8654AU RPMh regulators (PMIC A and PMIC C)
- Display subsystem/phy supplies (DSI, DP)
- Enable GPU, GPI DMA, IRIS
- PCIe Gen4 for both controllers and PHY supply hookups
- QUPv3 firmware declarations
- REFGEN always-on workaround for USB2 HS PHY
- Remoteproc firmware names for ADSP, CDSP and GPDSP
- Ethernet SERDES supplies
- USB HS/SS PHY regulators
- On-SoM eMMC
arm64: dts: qcom: qcs6490-rb3gen2-industrial-mezzanine: Add second TC9563 PCIe switch node for PCIe1
Add a node for the second TC9563 PCIe switch on PCIe1, which is connected
in cascade to the first TC9563 switch via the former's downstream port.
Two embedded Ethernet devices are present on one of the downstream
ports of this second switch as well. All the ports present in the
node represent the downstream ports and embedded endpoints.
The second TC9563 is powered up via the same LDO regulators as the first
one, and these can be controlled via two GPIOs, which are already present
as fixed regulators. This TC9563 can also be configured through I2C.
Add a node for the TC9563 PCIe switch connected to PCIe0. The switch
has three downstream ports.Two embedded Ethernet devices are present
on one of the downstream ports. The other downstream ports route to
M.2 E key and PCIe x4 connector respectively. All the ports present
in the node represent the downstream ports and embedded endpoints.
Power to the TC9563 is supplied through two LDO regulators, which
are on by default and are added as fixed regulators. TC9563 can be
configured through I2C.
Since PCIe0 now routes to TC9563 instead of WCN6750, disable the
WCN6750 and WPSS device tree nodes to reflect the actual hardware
configuration and avoid probing issues.
The restriction on UHS-I speed modes was added to all SM8650 platforms
by copying it from SM8450 and SM8550 dtsi files, and it was an actually
reproducible problem due to the overclocking of SD cards. Since the latter
issue has been fixed in the SM8650 GCC driver, UHS-I speed modes are
working fine on SM8650 boards, below is the test performed on SM8650-HDK:
SDR50 speed mode:
mmc0: new UHS-I speed SDR50 SDHC card at address 0001
mmcblk0: mmc0:0001 00000 14.6 GiB
mmcblk0: p1
% dd if=/dev/mmcblk0p1 of=/dev/null bs=1M count=1024
1024+0 records in
1024+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 24.8086 s, 43.3 MB/s
SDR104 speed mode:
mmc0: new UHS-I speed SDR104 SDHC card at address 59b4
mmcblk0: mmc0:59b4 USDU1 28.3 GiB
mmcblk0: p1
% dd if=/dev/mmcblk0p1 of=/dev/null bs=1M count=1024
1024+0 records in
1024+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 12.9448 s, 82.9 MB/s
Unset the UHS-I speed mode restrictions from the SM8550 platform dtsi
file, there is no indication that the SDHC controller is broken.
Fixes: 10e024671295 ("arm64: dts: qcom: sm8650: add interconnect dependent device nodes") Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Link: https://lore.kernel.org/r/20260314023715.357512-7-vladimir.zapolskiy@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
The restriction on UHS-I speed modes was added to all SM8550 platforms
by copying it from SM8450 dtsi file, and due to the overclocking of SD
cards it was an actually reproducible problem. Since the latter issue
has been fixed, UHS-I speed modes are working fine on SM8550 boards,
below is the test performed on SM8550-HDK:
SDR50 speed mode:
mmc0: new UHS-I speed SDR50 SDHC card at address 0001
mmcblk0: mmc0:0001 00000 14.6 GiB
mmcblk0: p1
% dd if=/dev/mmcblk0p1 of=/dev/null bs=1M count=1024
1024+0 records in
1024+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 23.5468 s, 45.6 MB/s
SDR104 speed mode:
mmc0: new UHS-I speed SDR104 SDHC card at address 59b4
mmcblk0: mmc0:59b4 USDU1 28.3 GiB
mmcblk0: p1
% dd if=/dev/mmcblk0p1 of=/dev/null bs=1M count=1024
1024+0 records in
1024+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 11.9819 s, 89.6 MB/s
Unset the UHS-I speed mode restrictions from the SM8550 platform dtsi
file, there is no indication that the SDHC controller is broken.
Fixes: ffc50b2d3828 ("arm64: dts: qcom: Add base SM8550 dtsi") Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Link: https://lore.kernel.org/r/20260314023715.357512-6-vladimir.zapolskiy@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
The reported problem of some non-working UHS-I speed modes on SM8450
originates in commit 0a631a36f724 ("arm64: dts: qcom: Add device tree
for Sony Xperia 1 IV"), and then it was spread to all SM8450 powered
platforms by commit 9d561dc4e5cc ("arm64: dts: qcom: sm8450: disable
SDHCI SDR104/SDR50 on all boards").
The tests show that the rootcause of the problem was related to an
overclocking of SD cards, and it's fixed later on by commit a27ac3806b0a
("clk: qcom: gcc-sm8450: Use floor ops for SDCC RCGs").
Since then both SDR50 and SDR104 speed modes are working fine on SM8450,
tested on SM8450-HDK:
SDR50 speed mode:
mmc0: new UHS-I speed SDR50 SDHC card at address 0001
mmcblk0: mmc0:0001 00000 14.6 GiB
mmcblk0: p1
% dd if=/dev/mmcblk0p1 of=/dev/null bs=1M count=1024
1024+0 records in
1024+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 24.6254 s, 43.6 MB/s
SDR104 speed mode:
mmc0: new UHS-I speed SDR104 SDHC card at address 59b4
mmcblk0: mmc0:59b4 USDU1 28.3 GiB
mmcblk0: p1
% dd if=/dev/mmcblk0p1 of=/dev/null bs=1M count=1024
1024+0 records in
1024+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 12.3266 s, 87.1 MB/s
Remove the restrictions on SD card speed modes from the SM8450 platform
dtsi file and enable UHS-I speed modes.
Fixes: 9d561dc4e5cc ("arm64: dts: qcom: sm8450: disable SDHCI SDR104/SDR50 on all boards") Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Link: https://lore.kernel.org/r/20260314023715.357512-5-vladimir.zapolskiy@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
arm64: dts: qcom: hamoa: Fix xo clock supply of platform SD host controller
The expected frequency of SD host controller core supply clock is 19.2MHz,
while RPMH_CXO_CLK clock frequency on SM8650 platform is 38.4MHz.
Apparently the overclocked supply clock could be good enough on some
boards and even with the most of SD cards, however some low-end UHS-I
SD cards in SDR104 mode of the host controller produce I/O errors in
runtime, fortunately this problem is gone, if the "xo" clock frequency
matches the expected 19.2MHz clock rate.
Fixes: ffb21c1e19b1 ("arm64: dts: qcom: x1e80100: Describe the SDHC controllers") Reported-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20260314023715.357512-4-vladimir.zapolskiy@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
arm64: dts: qcom: sm8650: Fix xo clock supply of SD host controller
The expected frequency of SD host controller core supply clock is 19.2MHz,
while RPMH_CXO_CLK clock frequency on SM8650 platform is 38.4MHz.
Apparently the overclocked supply clock could be good enough on some
boards and even with the most of SD cards, however some low-end UHS-I
SD cards in SDR104 mode of the host controller produce I/O errors in
runtime, fortunately this problem is gone, if the "xo" clock frequency
matches the expected 19.2MHz clock rate.
Fixes: 10e024671295 ("arm64: dts: qcom: sm8650: add interconnect dependent device nodes") Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20260314023715.357512-3-vladimir.zapolskiy@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
arm64: dts: qcom: sm8550: Fix xo clock supply of platform SD host controller
The expected frequency of SD host controller core supply clock is 19.2MHz,
while RPMH_CXO_CLK clock frequency on SM8650 platform is 38.4MHz.
Apparently the overclocked supply clock could be good enough on some
boards and even with the most of SD cards, however some low-end UHS-I
SD cards in SDR104 mode of the host controller produce I/O errors in
runtime, fortunately this problem is gone, if the "xo" clock frequency
matches the expected 19.2MHz clock rate.
Fixes: ffc50b2d3828 ("arm64: dts: qcom: Add base SM8550 dtsi") Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20260314023715.357512-2-vladimir.zapolskiy@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Konrad Dybcio [Tue, 17 Mar 2026 14:41:16 +0000 (15:41 +0100)]
arm64: dts: qcom: sm8450: Fix GIC_ITS range length
Currently, the GITS_SGIR register is cut off. Fix it up.
Fixes: fc8b0b9b630d ("arm64: dts: qcom: sm8450 add ITS device tree node") Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260317-topic-its_range_fixup-v1-3-49be8076adb1@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
arm64: dts: qcom: sm8750-mtp: Enable USB headset and Type-C accessory mode
MTP8750 does not have audio jack connected and relies on USB mux
(WCD9395). Add necessary nodes for proper audio headset support along
with USB Type-C accessory mode and orientation.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260317-sm8750-display-dts-v5-3-fb53371e251c@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Dmitry Baryshkov [Fri, 13 Mar 2026 15:27:13 +0000 (17:27 +0200)]
arm64: dts: qcom: sm8750: correct Iris corners for the MXC rail
The corners of the MVS0 / MVS0C clocks on the MMCX rail don't always
match the PLL corners on the MXC rail. Correct the performance corners
for the MXC rail following the PLL documentation.
Dmitry Baryshkov [Fri, 13 Mar 2026 15:27:12 +0000 (17:27 +0200)]
arm64: dts: qcom: sm8650: correct Iris corners for the MXC rail
The corners of the MVS0 / MVS0C clocks on the MMCX rail don't always
match the PLL corners on the MXC rail. Correct the performance corners
for the MXC rail following the PLL documentation.
Dmitry Baryshkov [Fri, 13 Mar 2026 15:27:11 +0000 (17:27 +0200)]
arm64: dts: qcom: sm8550: correct Iris corners for the MXC rail
The corners of the MVS0 / MVS0C clocks on the MMCX rail don't always
match the PLL corners on the MXC rail. Correct the performance corners
for the MXC rail following the PLL documentation.
Dmitry Baryshkov [Fri, 13 Mar 2026 15:27:10 +0000 (17:27 +0200)]
arm64: dts: qcom: monaco: correct Iris corners for the MXC rail
The corners of the MVS0 / MVS0C clocks on the MMCX rail don't always
match the PLL corners on the MXC rail. Correct the performance corners
for the MXC rail following the PLL documentation.
Dmitry Baryshkov [Fri, 13 Mar 2026 15:27:09 +0000 (17:27 +0200)]
arm64: dts: qcom: lemans: correct Iris corners for the MXC rail
The corners of the MVS0 / MVS0C clocks on the MMCX rail don't always
match the PLL corners on the MXC rail. Correct the performance corners
for the MXC rail following the PLL documentation.
Fixes: 7bc95052c64f ("arm64: dts: qcom: sa8775p: add support for video node") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260313-iris-fix-corners-v1-2-32a393c25dda@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Dmitry Baryshkov [Fri, 13 Mar 2026 15:27:08 +0000 (17:27 +0200)]
arm64: dts: qcom: hamoa: correct Iris corners for the MXC rail
The corners of the MVS0 / MVS0C clocks on the MMCX rail don't always
match the PLL corners on the MXC rail. Correct the performance corners
for the MXC rail following the PLL documentation.
Abel Vesa [Wed, 18 Mar 2026 10:19:34 +0000 (12:19 +0200)]
arm64: dts: qcom: eliza: Enable Eliza MTP board support
The MTP is a one of the boards that comes with the Eliza SoC.
So add dedicated board dts for it.
The initial support enables:
- UART debug console
- Ob-board UFS storage
- Qualcomm RPMh regulators (PMIC) and VPH_PWR
- board specific clocks & reserved GPIO ranges
Co-developed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260318-eliza-base-dt-v3-3-8a50bd2201ed@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Abel Vesa [Wed, 18 Mar 2026 10:19:33 +0000 (12:19 +0200)]
arm64: dts: qcom: Introduce Eliza Soc base dtsi
Introduce the initial support for the Qualcomm Eliza SoC. It comes in
different flavors. There is SM7750 for mobiles and then QC7790S/M for IoT.
Describe the common parts under a common dtsi.
The initial submission enables support for:
- CPU nodes with cpufreq and cpuidle support
- Global Clock Controller (GCC)
- Resource State Coordinator (RSC) with clock controller & genpd provider
- Interrupt controller
- Power Domain Controller (PDC)
- Vendor specific SMMU
- SPMI bus arbiter
- Top Control and Status Register (TCSR)
- Top Level Mode Multiplexer (TLMM)
- Debug UART
- Reserved memory nodes
- Interconnect providers
- System timer
- UFS
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Co-developed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> 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/20260318-eliza-base-dt-v3-2-8a50bd2201ed@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Abel Vesa [Wed, 18 Mar 2026 10:19:32 +0000 (12:19 +0200)]
dt-bindings: arm: qcom: Document Eliza SoC and its MTP board
Qualcomm Eliza SoC comes with different flavors. There is SM7750 for
mobiles and then QC7790S/M for IoT. One of the boards that comes with
Eliza SoC is the MTP.
So document both the SoC and MTP board compatibles.
Bjorn Andersson [Thu, 19 Mar 2026 02:26:37 +0000 (21:26 -0500)]
Merge branch 'icc-eliza' of https://git.kernel.org/pub/scm/linux/kernel/git/djakov/icc into HEAD
Merge the Eliza interconnect DeviceTree bindings from topic branch, in
order to introduce the interconnect constants used in the Eliza
DeviceTree source.
Introduce support for the Mahua SoC and the CRD based on it. Some of
the notable differences are the absent CPU cluster, interconnect, TLMM,
thermal zones and adjusted PCIe west clocks. Everything else should
work as-is.
dt-bindings: arm: qcom: Document Mahua SoC and board
Mahua is a derivative of Glymur SoC with the third CPU cluster disabled.
Document the compatible strings for the Mahua SoC and the Compute
Reference Device (CRD) board based on it.
Wei Deng [Mon, 2 Mar 2026 02:46:58 +0000 (08:16 +0530)]
arm64: dts: qcom: qcs8300-ride: Enable Bluetooth support
Enable BT on qcs8300-ride by adding a BT device tree node.
Since the platform uses the QCA6698 Bluetooth chip. While
the QCA6698 shares the same IP core as the WCN6855, it has
different RF components and RAM sizes, requiring new firmware
files. Use the firmware-name property to specify the NVM and
rampatch firmware to load.
Tobias Heider [Thu, 26 Feb 2026 14:04:30 +0000 (15:04 +0100)]
arm64: dts: qcom: add missing denali-oled.dtb to Makefile
The DeviceTree for the OLED variant of the Microsoft Surface Pro 11th
Edition was originally added in commit '0d72ccaa1e84 ("arm64: dts: qcom:
Add support for X1-based Surface Pro 11")'. The original patch on the
mailing list also added the new device tree to the Makefile but that
part seems to have been dropped (by accident) when it got merged.
Signed-off-by: Tobias Heider <tobias.heider@canonical.com> Fixes: 0d72ccaa1e84 ("arm64: dts: qcom: Add support for X1-based Surface Pro 11") Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260226140429.232544-3-tobias.heider@canonical.com
[bjorn: Rewrote commit message reference to offending commit] Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Erikas Bitovtas [Wed, 25 Feb 2026 14:43:24 +0000 (16:43 +0200)]
arm64: dts: qcom: msm8939-asus-z00t: add ambient light and proximity sensor
This device uses Capella CM36686 as its ambient light and proximity
sensor. It is fully compatible with Vishay VCNL4040. Downstream device
tree reports Capella CM36283, but upon probe, a device ID for CM36686 is
actually found. This commit adds support for Capella CM36686 ambient
light and proximity sensor.
Monaco EVK board does not include a camera sensor in its default hardware
configuration. Introducing a device tree overlay to support optional
integration of the IMX577 sensor via CSIPHY1.
Camera reset is handled through an I2C expander, and power is enabled
via TLMM GPIO74.
Qualcomm QCS8300 SoC contains three Camera Control Interface (CCI).
Compared to Lemans, the key difference is in SDA/SCL GPIO assignments
and number of CCIs.
Luca Weiss [Fri, 13 Feb 2026 14:03:19 +0000 (15:03 +0100)]
arm64: dts: qcom: milos: Sort pinctrl subnodes by pins
As documented in the "Devicetree Sources (DTS) Coding Style" document,
pinctrl subnodes should be sorted by the pins property. Do this once for
milos.dtsi so that future additions can be added at the right places.
Aruino Uno-Q uses Analogix ANX7625 DSI-to-DP bridge to convert DSI
signals to the connected USB-C DisplayPort dongles. Decribe the chip,
USB-C connector and routing of USB and display signals.
Xueyao An [Thu, 12 Feb 2026 08:25:57 +0000 (16:25 +0800)]
arm64: dts: qcom: hamoa-iot-som: Add firmware-name to QUPv3 nodes
Traditionally, firmware loading for Serial Engines (SE) in the QUP hardware
of Qualcomm SoCs has been managed by TrustZone (TZ). While this approach
ensures secure SE assignment and access control, it limits flexibility for
developers who need to enable various protocols on different SEs.
Add the firmware-name property to QUPv3 nodes in the device tree to enable
firmware loading from the Linux environment. Handle SE assignments and
access control permissions directly within Linux, removing the dependency
on TrustZone.
Paolo Abeni [Thu, 26 Mar 2026 14:38:14 +0000 (15:38 +0100)]
Merge tag 'nf-26-03-26' of git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf
Pablo Neira Ayuso says:
====================
Netfilter for net
This is v3, I kept back an ipset fix and another to tigthen the xtables
interface to reject invalid combinations with the NFPROTO_ARP family.
They need a bit more discussion. I fixed the issues reported by AI on
patch 9 (add #ifdef to access ct zone, update nf_conntrack_broadcast
and patch 10 (use better Fixes: tag). Thanks!
The following patchset contains Netfilter fixes for *net*.
Note that most bugs fixed here stem from 2.6 days, the large PR is not
due to an increase in regressions.
1) Fix incorrect reject of set updates with nf_tables pipapo set
avx2 backend. This comes with a regression test in patch 2.
From Florian Westphal.
2) nfnetlink_log needs to zero padding to prevent infoleak to userspace,
from Weiming Shi.
3) xtables ip6t_rt module never validated that addrnr length is within the
allowed array boundary. Reject bogus values. From Ren Wei.
4) Fix high memory usage in rbtree set backend that was unwanted side-effect
of the recently added binary search blob. From Pablo Neira Ayuso.
5) Patches 5 to 10, also from Pablo, address long-standing RCU safety bugs
in conntracks handling of expectations: We can never safely defer
a conntrack extension area without holding a reference. Yet expectation
handling does so in multiple places. Fix this by avoiding the need to
look into the master conntrack to begin with and by extending locked
sections in a few places.
11) Fix use of uninitialized rtp_addr in the sip conntrack helper,
also from Weiming Shi.
12) Add stricter netlink policy checks in ctnetlink, from David Carlier.
This avoids undefined behaviour when userspace provides huge wscale
value.
netfilter pull request 26-03-26
* tag 'nf-26-03-26' of git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf:
netfilter: ctnetlink: use netlink policy range checks
netfilter: nf_conntrack_sip: fix use of uninitialized rtp_addr in process_sdp
netfilter: nf_conntrack_expect: skip expectations in other netns via proc
netfilter: nf_conntrack_expect: store netns and zone in expectation
netfilter: ctnetlink: ensure safe access to master conntrack
netfilter: nf_conntrack_expect: use expect->helper
netfilter: nf_conntrack_expect: honor expectation helper field
netfilter: nft_set_rbtree: revisit array resize logic
netfilter: ip6t_rt: reject oversized addrnr in rt_mt6_check()
netfilter: nfnetlink_log: fix uninitialized padding leak in NFULA_PAYLOAD
selftests: netfilter: nft_concat_range.sh: add check for flush+reload bug
netfilter: nft_set_pipapo_avx2: don't return non-matching entry on expiry
====================
Steven Rostedt [Tue, 24 Mar 2026 18:01:45 +0000 (14:01 -0400)]
tracing: Move snapshot code out of trace.c and into trace_snapshot.c
The trace.c file was a dumping ground for most tracing code. Start
organizing it better by moving various functions out into their own files.
Move all the snapshot code, including the max trace code into its own
trace_snapshot.c file.
mm: damon: Use trace_call__##name() at guarded tracepoint call sites
Replace trace_damos_stat_after_apply_interval() with
trace_call__damos_stat_after_apply_interval() at a site already guarded
by an early return when !trace_damos_stat_after_apply_interval_enabled(),
avoiding a redundant static_branch_unlikely() re-evaluation inside the
tracepoint.
Cc: Andrew Morton <akpm@linux-foundation.org> Link: https://patch.msgid.link/20260323160052.17528-19-vineeth@bitbyteword.org Suggested-by: Steven Rostedt <rostedt@goodmis.org> Suggested-by: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Vineeth Pillai (Google) <vineeth@bitbyteword.org> Reviewed-by: SeongJae Park <sj@kernel.org> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
btrfs: Use trace_call__##name() at guarded tracepoint call sites
Replace trace_foo() with the new trace_call__foo() at sites already
guarded by trace_foo_enabled(), avoiding a redundant
static_branch_unlikely() re-evaluation inside the tracepoint.
trace_call__foo() calls the tracepoint callbacks directly without
utilizing the static branch again.
Cc: Chris Mason <clm@fb.com> Link: https://patch.msgid.link/20260323160052.17528-16-vineeth@bitbyteword.org Suggested-by: Steven Rostedt <rostedt@goodmis.org> Suggested-by: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Vineeth Pillai (Google) <vineeth@bitbyteword.org> Assisted-by: Claude:claude-sonnet-4-6 Acked-by: David Sterba <dsterba@suse.com> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
spi: Use trace_call__##name() at guarded tracepoint call sites
Replace trace_foo() with the new trace_call__foo() at sites already
guarded by trace_foo_enabled(), avoiding a redundant
static_branch_unlikely() re-evaluation inside the tracepoint.
trace_call__foo() calls the tracepoint callbacks directly without
utilizing the static branch again.
Cc: Michael Hennerich <michael.hennerich@analog.com> Cc: Nuno Sá <nuno.sa@analog.com> Cc: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20260323160052.17528-14-vineeth@bitbyteword.org Suggested-by: Steven Rostedt <rostedt@goodmis.org> Suggested-by: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Vineeth Pillai (Google) <vineeth@bitbyteword.org> Assisted-by: Claude:claude-sonnet-4-6 Acked-by: Mark Brown <broonie@kernel.org> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
i2c: Use trace_call__##name() at guarded tracepoint call sites
Replace trace_foo() with the new trace_call__foo() at sites already
guarded by trace_foo_enabled(), avoiding a redundant
static_branch_unlikely() re-evaluation inside the tracepoint.
trace_call__foo() calls the tracepoint callbacks directly without
utilizing the static branch again.
Link: https://patch.msgid.link/20260323160052.17528-13-vineeth@bitbyteword.org Suggested-by: Steven Rostedt <rostedt@goodmis.org> Suggested-by: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Vineeth Pillai (Google) <vineeth@bitbyteword.org> Assisted-by: Claude:claude-sonnet-4-6 Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Mickaël Salaün [Thu, 12 Mar 2026 10:04:36 +0000 (11:04 +0100)]
nsproxy: Add FOR_EACH_NS_TYPE() X-macro and CLONE_NS_ALL
Introduce the FOR_EACH_NS_TYPE(X) macro as the single source of truth
for the set of (struct type, CLONE_NEW* flag) pairs that define Linux
namespace types.
Currently, the list of CLONE_NEW* flags is duplicated inline in
multiple call sites and would need another copy in each new consumer.
This makes it easy to miss one when a new namespace type is added.
Derive two things from the X-macro:
- CLONE_NS_ALL: Bitmask of all known CLONE_NEW* flags, usable as a
validity mask or iteration bound.
- ns_common_type(): Rewritten to use the X-macro via a leading-comma
_Generic pattern, so the struct-to-flag mapping stays in sync with the
flag set automatically.
Replace the inline flag enumerations in copy_namespaces(),
unshare_nsproxy_namespaces(), check_setns_flags(), and
ksys_unshare() with CLONE_NS_ALL.
When a new namespace type is added, only FOR_EACH_NS_TYPE needs to
be updated; CLONE_NS_ALL, ns_common_type(), and all the call sites
pick up the change automatically.
Cc: Christian Brauner <brauner@kernel.org> Cc: Günther Noack <gnoack@google.com> Signed-off-by: Mickaël Salaün <mic@digikod.net> Link: https://patch.msgid.link/20260312100444.2609563-4-mic@digikod.net Reviewed-by: Christian Brauner <brauner@kernel.org> Signed-off-by: Christian Brauner <brauner@kernel.org>
David Howells [Wed, 25 Mar 2026 08:20:17 +0000 (08:20 +0000)]
netfs: Fix the handling of stream->front by removing it
The netfs_io_stream::front member is meant to point to the subrequest
currently being collected on a stream, but it isn't actually used this way
by direct write (which mostly ignores it). However, there's a tracepoint
which looks at it. Further, stream->front is actually redundant with
stream->subrequests.next.
Fix the potential problem in the direct code by just removing the member
and using stream->subrequests.next instead, thereby also simplifying the
code.
Fixes: a0b4c7a49137 ("netfs: Fix unbuffered/DIO writes to dispatch subrequests in strict sequence") Reported-by: Paulo Alcantara <pc@manguebit.org> Signed-off-by: David Howells <dhowells@redhat.com> Link: https://patch.msgid.link/4158599.1774426817@warthog.procyon.org.uk Reviewed-by: Paulo Alcantara (Red Hat) <pc@manguebit.org>
cc: netfs@lists.linux.dev
cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner <brauner@kernel.org>
I've been looking into changes to ->setattr and noticed that we still
have a few instances where the method has the ages old notify_change
name. Fix this up and include dusting off outdated comments.
* patches from https://patch.msgid.link/20260325063711.3298685-1-hch@lst.de:
proc: rename proc_notify_change to proc_setattr
proc: rename proc_setattr to proc_nochmod_setattr
affs: rename affs_notify_change to affs_setattr
adfs: rename adfs_notify_change to adfs_setattr
hfs: update comments on hfs_inode_setattr
What is currently proc_setattr is a special version added after the more
general procfs ->seattr in commit 6d76fa58b050 ("Don't allow chmod() on
the /proc/<pid>/ files"). Give it a name that reflects that to free the
proc_setattr name and better describe what is doing.
The top of function comment about hfs_inode_setattr is severely out
of date and reference a previous name for this function. Remove it,
and update the comments in the file to record the still relevant bits
directly.
Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://patch.msgid.link/20260325063711.3298685-2-hch@lst.de Reviewed-by: Viacheslav Dubeyko <slava@dubeyko.com> Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Christian Brauner <brauner@kernel.org>
Paolo Abeni [Thu, 26 Mar 2026 14:14:51 +0000 (15:14 +0100)]
Merge branch '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue
Tony Nguyen says:
====================
For ice:
Michal corrects call to alloc_etherdev_mqs() to provide maximum number
of queues supported rather than currently allocated number of queues.
Petr Oros fixes issues related to some ethtool operations in switchdev
mode.
For iavf:
Kohei Enju corrects number of reported queues for ethtool statistics to
absolute max as using current number could race and cause out-of-bounds
issues.
For idpf:
Josh NULLs cdev_info pointer after freeing to prevent possible subsequent
improper access. He also defers setting of refillqs value until after
allocation to prevent possible NULL pointer dereference.
* '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue:
idpf: only assign num refillqs if allocation was successful
idpf: clear stale cdev_info ptr
iavf: fix out-of-bounds writes in iavf_get_ethtool_stats()
ice: use ice_update_eth_stats() for representor stats
ice: fix inverted ready check for VF representors
ice: set max queues in alloc_etherdev_mqs()
====================
Long Li [Mon, 23 Mar 2026 19:49:25 +0000 (12:49 -0700)]
net: mana: Set default number of queues to 16
Set the default number of queues per vPort to MANA_DEF_NUM_QUEUES (16),
as 16 queues can achieve optimal throughput for typical workloads. The
actual number of queues may be lower if it exceeds the hardware reported
limit. Users can increase the number of queues up to max_queues via
ethtool if needed.
Merge patch series "fs: Move metadata bh tracking from address_space"
Jan Kara <jack@suse.cz> says:
This patch series cleans up the mess that has accumulated over the years in
metadata buffer_head tracking for inodes, moves the tracking into dedicated
structure in filesystem-private part of the inode (so that we don't use
private_list, private_data, and private_lock in struct address_space), and also
moves couple other users of private_data and private_list so these are removed
from struct address_space saving 3 longs in struct inode for 99% of inodes. I
would like to get rid of private_lock in struct address_space as well however
the locking changes for buffer_heads are non-trivial there and the patch series
is long enough as is. So let's leave that for another time.
* patches from https://patch.msgid.link/20260326082428.31660-1-jack@suse.cz: (42 commits)
fs: Drop i_private_list from address_space
fs: Drop mapping_metadata_bhs from address space
ext4: Track metadata bhs in fs-private inode part
minix: Track metadata bhs in fs-private inode part
udf: Track metadata bhs in fs-private inode part
fat: Track metadata bhs in fs-private inode part
bfs: Track metadata bhs in fs-private inode part
affs: Track metadata bhs in fs-private inode part
ext2: Track metadata bhs in fs-private inode part
fs: Provide functions for handling mapping_metadata_bhs directly
fs: Switch inode_has_buffers() to take mapping_metadata_bhs
fs: Make bhs point to mapping_metadata_bhs
fs: Move metadata bhs tracking to a separate struct
fs: Fold fsync_buffers_list() into sync_mapping_buffers()
fs: Drop osync_buffers_list()
kvm: Use private inode list instead of i_private_list
fs: Remove i_private_data
aio: Stop using i_private_data and i_private_lock
hugetlbfs: Stop using i_private_data
fs: Stop using i_private_data for metadata bh tracking
...
projects / thirdparty / kernel / stable.git / log
