* Re: [PATCH net-next v5 07/15] net: ethernet: oa_tc6: Support for vendor specific MMS
From: sashiko-bot @ 2026-06-15 17:01 UTC (permalink / raw)
To: Selvamani Rajagopal via B4 Relay; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260614-s2500-mac-phy-support-v5-7-89874b72f725@onsemi.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
Pre-existing issues:
- [High] Missing state validation in MAC-PHY RX chunk processing leads to a NULL pointer dereference if a start-of-frame chunk is missed.
- [High] The RX path does not limit the accumulated length of ongoing chunks, allowing a malicious hardware device to trigger an `skb_over_panic`.
- [High] Repeated start-of-frame chunks without corresponding end-of-frame chunks will leak newly allocated socket buffers.
--
commit ad9ba89ed1440b885945a45d429d49b23e68bbdf
Author: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>
net: ethernet: oa_tc6: Support for vendor specific MMS
OPEN Alliance 10BASE-T1x Serial Interface specification, table 6
allows vendors to use any memory map select (MMS) value between
10 and 15. This new API interface enables vendor to map one of
thes MMS values to MDIO_MMD_VEND1.
> diff --git a/drivers/net/ethernet/oa_tc6/oa_tc6.c b/drivers/net/ethernet/oa_tc6/oa_tc6.c
> index 9410cecfdc2aa..fab7cb84df712 100644
> --- a/drivers/net/ethernet/oa_tc6/oa_tc6.c
> +++ b/drivers/net/ethernet/oa_tc6/oa_tc6.c
> @@ -202,6 +202,18 @@ int oa_tc6_ioctl(struct oa_tc6 *tc6, struct ifreq *rq, int cmd)
> }
> EXPORT_SYMBOL_GPL(oa_tc6_ioctl);
>
> +/**
> + * oa_tc6_set_vend1_mms - Add vendor specific MDIO_MMD to OA TC6 MMS
> + * mapper value.
> + * @tc6: oa_tc6 struct.
> + * @mms: vendor defined MMS value for VEND1 mdio device.
> + */
> +void oa_tc6_set_vend1_mms(struct oa_tc6 *tc6, int mms)
> +{
> + tc6->vend1_mms = mms;
> +}
> +EXPORT_SYMBOL_GPL(oa_tc6_set_vend1_mms);
> +
> static __be32 oa_tc6_prepare_ctrl_header(u32 addr, u8 length,
[Severity: High]
This is a pre-existing issue, but I noticed a potential NULL pointer
dereference during RX chunk processing. If the MAC-PHY sends an RX chunk with
end_valid set and start_valid clear as the first chunk:
drivers/net/ethernet/oa_tc6/oa_tc6.c:oa_tc6_prcs_rx_chunk_payload()
if (end_valid && !start_valid) {
size = end_byte_offset + 1;
oa_tc6_prcs_rx_frame_end(tc6, data, size);
return 0;
}
This function unconditionally calls oa_tc6_update_rx_skb(), which invokes
skb_put() on tc6->rx_skb:
drivers/net/ethernet/oa_tc6/oa_tc6.c:oa_tc6_update_rx_skb()
memcpy(skb_put(tc6->rx_skb, length), payload, length);
Since tc6->rx_skb is only allocated when a chunk with a valid start is
received, it will be NULL in this case. Can a malfunctioning or malicious
MAC-PHY trigger a kernel panic here?
[Severity: High]
This isn't a bug introduced by this patch, but there appears to be a missing
length check when accumulating ongoing RX chunks. If the MAC-PHY streams an
unbroken series of ongoing chunks (start_valid = 0 and end_valid = 0),
oa_tc6_prcs_ongoing_rx_frame() repeatedly appends data:
drivers/net/ethernet/oa_tc6/oa_tc6.c:oa_tc6_prcs_ongoing_rx_frame()
oa_tc6_update_rx_skb(tc6, payload, OA_TC6_CHUNK_PAYLOAD_SIZE);
Since the SKB allocated in oa_tc6_allocate_rx_skb() has a fixed capacity
based on the MTU, could a stream of ongoing chunks eventually exceed the
skb's tailroom and trigger an skb_over_panic()?
[Severity: High]
This is a pre-existing issue, but repeated start-of-frame chunks might leak
socket buffers. When oa_tc6_prcs_rx_chunk_payload() receives a new start
chunk without the previous frame ending, it allocates a new SKB:
drivers/net/ethernet/oa_tc6/oa_tc6.c:oa_tc6_prcs_rx_chunk_payload()
if (start_valid && !end_valid) {
size = OA_TC6_CHUNK_PAYLOAD_SIZE - start_byte_offset;
return oa_tc6_prcs_rx_frame_start(tc6, &data[start_byte_offset],
size, footer);
}
This eventually calls oa_tc6_allocate_rx_skb() which overwrites the
tc6->rx_skb pointer:
drivers/net/ethernet/oa_tc6/oa_tc6.c:oa_tc6_allocate_rx_skb()
tc6->rx_skb = netdev_alloc_skb_ip_align(tc6->netdev, tc6->netdev->mtu +
ETH_HLEN + ETH_FCS_LEN +
OA_TC6_TSTAMP_SZ);
If tc6->rx_skb was already populated from a previously interrupted frame,
the old pointer is overwritten without being freed. Can this be used to
exhaust kernel memory by continuously sending start chunks?
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260614-s2500-mac-phy-support-v5-0-89874b72f725@onsemi.com?part=7
^ permalink raw reply
* Re: [PATCH net-next v5 06/15] net: ethernet: oa_tc6: Support for hardware timestamp
From: sashiko-bot @ 2026-06-15 17:01 UTC (permalink / raw)
To: Selvamani Rajagopal via B4 Relay; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260614-s2500-mac-phy-support-v5-6-89874b72f725@onsemi.com>
Thank you for your contribution! Sashiko AI review found 10 potential issue(s) to consider:
New issues:
- [High] Unaligned memory access when casting `skb->data` to `u32 *`.
- [High] Unbounded queuing of original TX SKBs without a timeout leaks socket memory.
- [High] Freeing an ongoing TX SKB on SPI transfer error without removing it from the timestamp queue causes a Use-After-Free.
- [High] Unbounded queuing of TX timestamp requests leads to timestamp ID wrap-around and Use-After-Free.
- [High] Data race on `skb->cb` between the network stack and the SPI kthread leads to SKB memory leaks.
- [Medium] Disabling hardware timestamping corrupts in-flight packets.
- [Medium] Missing cleanup of `tx_ts_skb_q` leaks pending SKBs on device teardown.
- [Medium] Overwriting `so_timestamping` in `oa_tc6_get_ts_info` removes core software timestamping capabilities.
- [Medium] Hardware configuration failure leaves `tc6->ts_config` in an inconsistent state.
Pre-existing issues:
- [High] Transient out-of-memory errors permanently kill the main SPI kthread.
--
commit b7df7518de6607438ff5d3bb817fff0ea7ea3447
Author: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>
net: ethernet: oa_tc6: Support for hardware timestamp
PTP register/unregister calls are implemented in oa_tc6_ptp.c.
The APIs that work with the hardware for timestamp is provided
by vendor code as it may be vendor dependent.
Interface for ndo_hwtstamp_set/get, ioctl, control and status
callback for ethtool are provided to support hardware timestamp
feature.
Besides ioctl interface, hardware timestamp functions that handles
header and footer data are in oa_tc6.c. Helper functions are in
oa_tc6_tstamp.c.
> --- a/drivers/net/ethernet/oa_tc6/oa_tc6.c
> +++ b/drivers/net/ethernet/oa_tc6/oa_tc6.c
[ ... ]
> +static void oa_tc6_defer_for_hwtstamp(struct oa_tc6 *tc6,
> + struct sk_buff *skb)
> +{
[ ... ]
> + list_add_tail(&skb->list, &tc6->tx_ts_skb_q);
> +}
[Severity: High]
Does appending the original skb to tx_ts_skb_q without a timeout leak
socket memory?
Delaying the original transmission skb's destruction prevents the
socket from releasing its sk_wmem_alloc memory. If the packet is
dropped by the hardware or the interrupt is lost, the skb remains in
this list forever.
Should this queue a clone (skb_clone_sk()) for timestamping and free
the original skb, or implement a timeout?
[Severity: High]
Can this also lead to a Use-After-Free if an SPI data transfer fails?
If an SPI transfer fails, the error path invokes
oa_tc6_cleanup_ongoing_tx_skb() which unconditionally frees
tc6->ongoing_tx_skb via kfree_skb().
However, oa_tc6_defer_for_hwtstamp() may have already linked this
skb into tc6->tx_ts_skb_q. Since the cleanup routine doesn't remove
it from the list, the skb becomes a dangling pointer. When a timestamp
event arrives, oa_tc6_process_deferred_skb() will traverse tx_ts_skb_q
and access freed memory.
[ ... ]
> +static int oa_tc6_process_deferred_skb(struct oa_tc6 *tc6, u8 tsc)
> +{
[ ... ]
> + list_for_each_entry_safe(skb, tmp, &tc6->tx_ts_skb_q, list) {
> + ski = oa_tc6_tsinfo_tx(skb);
> + if (ski->tsc != tsc)
> + continue;
[ ... ]
> + list_del(&skb->list);
[ ... ]
> + dev_kfree_skb(skb);
> + }
> + return ret;
> +}
[Severity: High]
Will this loop free active skbs still undergoing SPI transmission if
more than 3 packets are queued?
The MAC-PHY provides 3 TX timestamp capture registers, and the driver
cycles through IDs 1, 2, and 3. If the IDs wrap around, this loop
iterates through tx_ts_skb_q and frees all skbs matching the aliased
tsc value, instead of just the oldest one.
[ ... ]
> +static void oa_tc6_update_ts_in_rx_skb(struct oa_tc6 *tc6)
> +{
> + struct sk_buff *skb = tc6->rx_skb;
> + struct oa_tc6_ts_info_rx *ski;
> + u32 ts[2];
> +
> + if (!tc6->hw_tstamp_enabled)
> + return;
> + ski = oa_tc6_tsinfo_rx(skb);
> + if (!ski->rtsa)
> + return;
[Severity: Medium]
Will returning early here corrupt in-flight packets if hardware
timestamping is disabled dynamically?
If hw_tstamp_enabled is turned off while packets are in-flight, the
driver returns without calling skb_pull(skb, 8). For frames that were
already processed by the MAC-PHY with a prepended timestamp, skipping the
pull leaves the Ethernet header shifted by 8 bytes.
Could this cause the networking stack to misinterpret the packet headers
and drop them?
> +
> + ts[0] = be32_to_cpu(*((u32 *)(skb->data)));
> + ts[1] = be32_to_cpu(*((u32 *)(skb->data) + 1));
[Severity: High]
Does casting skb->data directly to u32 pointer cause an unaligned memory access
exception?
Since netdev_alloc_skb_ip_align() reserves 2 bytes to ensure the IP
header is 4-byte aligned, skb->data itself is only 2-byte aligned. On
strict-alignment architectures, dereferencing this will panic.
Should this use get_unaligned_be32(skb->data) instead?
[ ... ]
> @@ -623,24 +783,29 @@ static void oa_tc6_update_rx_skb(struct oa_tc6 *tc6, u8 *payload, u8 length)
> memcpy(skb_put(tc6->rx_skb, length), payload, length);
> }
>
> -static int oa_tc6_allocate_rx_skb(struct oa_tc6 *tc6)
> +static int oa_tc6_allocate_rx_skb(struct oa_tc6 *tc6, u32 footer)
> {
[Severity: High]
This isn't a bug introduced by this patch, but will a transient
out-of-memory error permanently kill the main SPI kthread?
If netdev_alloc_skb_ip_align() fails under normal memory pressure,
oa_tc6_allocate_rx_skb() returns -ENOMEM. This error propagates up
through the receive path to oa_tc6_try_spi_transfer() and finally to
oa_tc6_spi_thread_handler().
The kthread loop checks the return value and exits. Returning from a
kthread function permanently kills the thread, rendering the MAC-PHY
dead until the module is reloaded.
[ ... ]
> @@ -1073,6 +1250,7 @@ netdev_tx_t oa_tc6_start_xmit(struct oa_tc6 *tc6, struct sk_buff *skb)
> spin_lock_bh(&tc6->tx_skb_lock);
> tc6->waiting_tx_skb = skb;
> spin_unlock_bh(&tc6->tx_skb_lock);
> + oa_tc6_tsinfo_tx(skb)->tsc = 0;
>
> /* Wake spi kthread to perform spi transfer */
> wake_up_interruptible(&tc6->spi_wq);
[Severity: High]
Is there a data race on skb->cb between the network stack and the SPI
kthread here?
The skb is handed over to the SPI kthread by assigning it to
tc6->waiting_tx_skb inside the spinlock. Immediately after releasing
the lock, this code initializes oa_tc6_tsinfo_tx(skb)->tsc = 0.
If the SPI kthread wakes up immediately, grabs the skb, and calls
oa_tc6_defer_for_hwtstamp(), it could assign a valid hardware index
(1, 2, or 3) to tsc.
The main thread would then overwrite the valid index with 0. When the
interrupt arrives, oa_tc6_process_deferred_skb() skips the skb because
its tsc is 0, leaking the skb permanently.
[ ... ]
> @@ -1103,6 +1281,8 @@ struct oa_tc6 *oa_tc6_init(struct spi_device *spi, struct net_device *netdev)
> SET_NETDEV_DEV(netdev, &spi->dev);
> mutex_init(&tc6->spi_ctrl_lock);
> spin_lock_init(&tc6->tx_skb_lock);
> + tc6->tx_ts_idx = OA_TC6_TTSCA_REG_ID;
> + INIT_LIST_HEAD(&tc6->tx_ts_skb_q);
[Severity: Medium]
Is there a missing cleanup routine for tx_ts_skb_q on device teardown?
If the module is unloaded or the device is unbound, any skbs sitting
in this queue (e.g., due to a lost hardware interrupt) appear to
remain indefinitely, causing a memory leak.
> --- /dev/null
> +++ b/drivers/net/ethernet/oa_tc6/oa_tc6_tstamp.c
[ ... ]
> +int oa_tc6_hwtstamp_set(struct oa_tc6 *tc6,
> + struct kernel_hwtstamp_config *cfg)
> +{
[ ... ]
> + hwtstamp_config_from_kernel(&tc6->ts_config, cfg);
> +
> + /* Supports timestamping all traffic */
> + if (cfg->rx_filter != HWTSTAMP_FILTER_NONE)
> + tc6->ts_config.rx_filter = HWTSTAMP_FILTER_ALL;
> + return oa_tc6_set_hwtstamp_settings(tc6);
> +}
[Severity: Medium]
Will a hardware configuration failure leave tc6->ts_config in an
inconsistent state?
The new user-provided configuration is copied into the internal
tc6->ts_config before calling oa_tc6_set_hwtstamp_settings(). If
programming the hardware fails over SPI, the function returns an error
but the internal state is not rolled back.
Could subsequent reads (like SIOCGHWTSTAMP) incorrectly report this
unapplied configuration?
[ ... ]
> +int oa_tc6_get_ts_info(struct oa_tc6 *tc6,
> + struct kernel_ethtool_ts_info *info)
> +{
> + if (!tc6->ptp_clock)
> + return ethtool_op_get_ts_info(tc6->netdev, info);
> +
> + info->so_timestamping = SOF_TIMESTAMPING_RAW_HARDWARE |
> + SOF_TIMESTAMPING_TX_HARDWARE |
> + SOF_TIMESTAMPING_RX_HARDWARE;
[Severity: Medium]
Does overwriting info->so_timestamping remove the core software
timestamping capabilities?
Assigning only hardware timestamping flags overwrites the default
software timestamping capabilities (SOF_TIMESTAMPING_SOFTWARE,
SOF_TIMESTAMPING_TX_SOFTWARE, SOF_TIMESTAMPING_RX_SOFTWARE) that the
core network stack natively supports.
Should the hardware flags be bitwise-ORed with the existing flags or
retrieved via ethtool_op_get_ts_info() first?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260614-s2500-mac-phy-support-v5-0-89874b72f725@onsemi.com?part=6
^ permalink raw reply
* Re: [PATCH net-next v5 03/15] net: ethernet: oa_tc6: Move oa_tc6.c to its own directory
From: sashiko-bot @ 2026-06-15 17:01 UTC (permalink / raw)
To: Selvamani Rajagopal via B4 Relay; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260614-s2500-mac-phy-support-v5-3-89874b72f725@onsemi.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] The kernel module is implicitly renamed from `oa_tc6.ko` to `oa_tc6_mod.ko`, breaking userspace compatibility.
- [Low] The Kconfig prompt for `OA_TC6` was made unconditionally visible, violating standard practice for library modules.
- [Low] The new file pattern in the `MAINTAINERS` file fails to cover all files in the newly created directory.
--
commit ac71755a6e3c87fc8edbf0f95cf23dd24cbc012f
Author: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>
net: ethernet: oa_tc6: Move oa_tc6.c to its own directory
This commit moves oa_tc6.c into a dedicated directory
(drivers/net/ethernet/oa_tc6) and adds a corresponding Makefile and
Kconfig to support adding more files for the OPEN Alliance 10BASE-T1x
Serial Interface.
> diff --git a/MAINTAINERS b/MAINTAINERS
> index cc1dde0c9067d..4cee98fc922cc 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -20001,7 +20001,7 @@ M: Parthiban Veerasooran <parthiban.veerasooran@microchip.com>
> L: netdev@vger.kernel.org
> S: Maintained
> F: Documentation/networking/oa-tc6-framework.rst
> -F: drivers/net/ethernet/oa_tc6.c
> +F: drivers/net/ethernet/oa_tc6/oa_tc6*
[Severity: Low]
Does this glob pattern leave the newly added Makefile and Kconfig orphaned?
Using drivers/net/ethernet/oa_tc6/oa_tc6* only matches files starting with
oa_tc6.
Could this be updated to use the directory-level pattern
drivers/net/ethernet/oa_tc6/ instead?
[ ... ]
> diff --git a/drivers/net/ethernet/oa_tc6/Kconfig b/drivers/net/ethernet/oa_tc6/Kconfig
> new file mode 100644
> index 0000000000000..97345f345fb9f
> --- /dev/null
> +++ b/drivers/net/ethernet/oa_tc6/Kconfig
> @@ -0,0 +1,16 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +#
> +# OA TC6 10BASE-T1x MAC-PHY configuration
> +#
> +
> +config OA_TC6
> + tristate "OPEN Alliance TC6 10BASE-T1x MAC-PHY support"
[Severity: Low]
Was the "if COMPILE_TEST" condition intentionally dropped from this prompt?
The original entry in drivers/net/ethernet/Kconfig correctly hid this
library from users during normal configuration.
Dropping the condition makes the prompt unconditionally visible in
menuconfig, even though the library is designed to be selected by dependent
hardware drivers.
[ ... ]
> diff --git a/drivers/net/ethernet/oa_tc6/Makefile b/drivers/net/ethernet/oa_tc6/Makefile
> new file mode 100644
> index 0000000000000..f24aae852ef27
> --- /dev/null
> +++ b/drivers/net/ethernet/oa_tc6/Makefile
> @@ -0,0 +1,7 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +#
> +# Makefile for OA TC6 10BASE-T1x MAC-PHY
> +#
> +
> +obj-$(CONFIG_OA_TC6) := oa_tc6_mod.o
> +oa_tc6_mod-objs := oa_tc6.o
[Severity: Medium]
Will this rename the generated kernel module from oa_tc6.ko to oa_tc6_mod.ko?
Renaming an existing module breaks out-of-tree dependencies, modprobe
configurations, and initramfs environments that expect the old module name.
To maintain the original module name without hitting a Kbuild cyclic
dependency, could the original oa_tc6.c be renamed to something like
oa_tc6_core.c? Then the Makefile could use:
obj-$(CONFIG_OA_TC6) += oa_tc6.o
oa_tc6-y := oa_tc6_core.o
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260614-s2500-mac-phy-support-v5-0-89874b72f725@onsemi.com?part=3
^ permalink raw reply
* [PATCH RFC v3 6/6] arm64: dts: qcom: sm8650-hdk: add SPMI ADC channels and thermal nodes
From: Neil Armstrong @ 2026-06-15 17:00 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Neil Armstrong
In-Reply-To: <20260615-topic-sm8x50-adc5-gen3-v3-0-216a2b5ccb85@linaro.org>
Add the SPMI ADC channels on the PMK8550 SPMI5 ADC3 for the
other PMICS on the system.
The thermal nodes are sorted by the sensor channel to be
coherent with the system thermal nodes ordering.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
arch/arm64/boot/dts/qcom/sm8650-hdk.dts | 279 ++++++++++++++++++++++++++++++++
1 file changed, 279 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8650-hdk.dts b/arch/arm64/boot/dts/qcom/sm8650-hdk.dts
index eabc828c05b4..cc2d341760a9 100644
--- a/arch/arm64/boot/dts/qcom/sm8650-hdk.dts
+++ b/arch/arm64/boot/dts/qcom/sm8650-hdk.dts
@@ -15,6 +15,9 @@
#include "pm8550ve.dtsi"
#include "pm8550vs.dtsi"
#include "pmk8550.dtsi"
+#include "qcom,pm8550-adc5-gen3.h"
+#include "qcom,pm8550b-adc5-gen3.h"
+#include "qcom,pm8550vx-adc5-gen3.h"
/ {
model = "Qualcomm Technologies, Inc. SM8650 HDK";
@@ -220,6 +223,92 @@ platform {
};
};
+ thermal-zones {
+ skin-thermal {
+ thermal-sensors = <&pmk8550_vadc PM8550_ADC5_GEN3_AMUX_THM1_100K_PU(1)>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ cam-flash-thermal {
+ thermal-sensors = <&pmk8550_vadc PM8550_ADC5_GEN3_AMUX_THM2_100K_PU(1)>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ wlan-thermal {
+ thermal-sensors = <&pmk8550_vadc PM8550_ADC5_GEN3_AMUX_THM3_100K_PU(1)>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ pa-thermal {
+ thermal-sensors = <&pmk8550_vadc PM8550_ADC5_GEN3_AMUX_THM4_100K_PU(1)>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ rear-tof-thermal {
+ thermal-sensors = <&pmk8550_vadc PM8550_ADC5_GEN3_AMUX_THM5_100K_PU(1)>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ usb-thermal {
+ thermal-sensors = <&pmk8550_vadc PM8550B_ADC5_GEN3_AMUX_THM4_USB_THERM_100K_PU(7)>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ wls-thermal {
+ thermal-sensors = <&pmk8550_vadc PM8550B_ADC5_GEN3_AMUX_THM6_GPIO10_100K_PU(7)>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+ };
+
vph_pwr: regulator-vph-pwr {
compatible = "regulator-fixed";
@@ -1041,27 +1130,217 @@ led@3 {
};
};
+&pm8550_temp_alarm {
+ io-channels = <&pmk8550_vadc PM8550_ADC5_GEN3_DIE_TEMP(1)>;
+ io-channel-names = "thermal";
+};
+
&pm8550b_eusb2_repeater {
vdd18-supply = <&vreg_l15b_1p8>;
vdd3-supply = <&vreg_l5b_3p1>;
};
+&pm8550b_temp_alarm {
+ io-channels = <&pmk8550_vadc PM8550B_ADC5_GEN3_DIE_TEMP(7)>;
+ io-channel-names = "thermal";
+};
+
&pm8550vs_c {
status = "okay";
};
+&pm8550vs_c_temp_alarm {
+ io-channels = <&pmk8550_vadc PM8550VS_ADC5_GEN3_DIE_TEMP(2)>;
+ io-channel-names = "thermal";
+};
+
&pm8550vs_d {
status = "okay";
};
+&pm8550vs_d_temp_alarm {
+ io-channels = <&pmk8550_vadc PM8550VS_ADC5_GEN3_DIE_TEMP(3)>;
+ io-channel-names = "thermal";
+};
+
&pm8550vs_e {
status = "okay";
};
+&pm8550vs_e_temp_alarm {
+ io-channels = <&pmk8550_vadc PM8550VS_ADC5_GEN3_DIE_TEMP(4)>;
+ io-channel-names = "thermal";
+};
+
&pm8550vs_g {
status = "okay";
};
+&pm8550vs_g_temp_alarm {
+ io-channels = <&pmk8550_vadc PM8550VS_ADC5_GEN3_DIE_TEMP(6)>;
+ io-channel-names = "thermal";
+};
+
+&pm8550ve_temp_alarm {
+ io-channels = <&pmk8550_vadc PM8550VE_ADC5_GEN3_DIE_TEMP(PMK8550VE_SID)>;
+ io-channel-names = "thermal";
+};
+
+&pmk8550_vadc {
+ /* PM8550 Channel nodes */
+ channel@100 {
+ reg = <PM8550_ADC5_GEN3_REF_GND(1)>;
+ label = "pm8550_offset_ref";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ channel@101 {
+ reg = <PM8550_ADC5_GEN3_1P25VREF(1)>;
+ label = "pm8550_vref_1p25";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ channel@103 {
+ reg = <PM8550_ADC5_GEN3_DIE_TEMP(1)>;
+ label = "pm8550_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ channel@18e {
+ reg = <PM8550_ADC5_GEN3_VPH_PWR(1)>;
+ label = "pm8550_vph_pwr";
+ qcom,pre-scaling = <1 3>;
+ };
+
+ channel@144 {
+ reg = <PM8550_ADC5_GEN3_AMUX_THM1_100K_PU(1)>;
+ label = "pm8550_msm_therm";
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ qcom,adc-tm;
+ };
+
+ channel@145 {
+ reg = <PM8550_ADC5_GEN3_AMUX_THM2_100K_PU(1)>;
+ label = "pm8550_cam_flash_therm";
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ qcom,adc-tm;
+ };
+
+ channel@146 {
+ reg = <PM8550_ADC5_GEN3_AMUX_THM3_100K_PU(1)>;
+ label = "pm8550_wlan_therm";
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ qcom,adc-tm;
+ };
+
+ channel@147 {
+ reg = <PM8550_ADC5_GEN3_AMUX_THM4_100K_PU(1)>;
+ label = "pm8550_pa_therm_1";
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ qcom,adc-tm;
+ };
+
+ channel@148 {
+ reg = <PM8550_ADC5_GEN3_AMUX_THM5_100K_PU(1)>;
+ label = "pm8550_rear_tof_therm";
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ qcom,adc-tm;
+ };
+
+ /* PM8550VS_C Channel nodes */
+ channel@203 {
+ reg = <PM8550VS_ADC5_GEN3_DIE_TEMP(2)>;
+ label = "pm8550vs_c_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ /* PM8550VS_D Channel nodes */
+ channel@303 {
+ reg = <PM8550VS_ADC5_GEN3_DIE_TEMP(3)>;
+ label = "pm8550vs_d_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ /* PM8550VS_E Channel nodes */
+ channel@403 {
+ reg = <PM8550VS_ADC5_GEN3_DIE_TEMP(4)>;
+ label = "pm8550vs_e_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ /* PM8550VE Channel nodes */
+ channel@503 {
+ reg = <PM8550VE_ADC5_GEN3_DIE_TEMP(PMK8550VE_SID)>;
+ label = "pm8550ve_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ /* PM8550VS_G Channel nodes */
+ channel@603 {
+ reg = <PM8550VS_ADC5_GEN3_DIE_TEMP(6)>;
+ label = "pm8550vs_g_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ /* PM8550B Channel nodes */
+ channel@700 {
+ reg = <PM8550B_ADC5_GEN3_REF_GND(7)>;
+ label = "pm8550b_offset_ref";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ channel@701 {
+ reg = <PM8550B_ADC5_GEN3_1P25VREF(7)>;
+ label = "pm8550b_vref_1p25";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ channel@703 {
+ reg = <PM8550B_ADC5_GEN3_DIE_TEMP(7)>;
+ label = "pm8550b_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ channel@78e {
+ reg = <PM8550B_ADC5_GEN3_VPH_PWR(7)>;
+ label = "pm8550b_vph_pwr";
+ qcom,pre-scaling = <1 3>;
+ };
+
+ channel@78f {
+ reg = <PM8550B_ADC5_GEN3_VBAT_SNS_QBG(7)>;
+ label = "pm8550b_vbat_sns_qbg";
+ qcom,pre-scaling = <1 6>;
+ };
+
+ channel@747 {
+ reg = <PM8550B_ADC5_GEN3_AMUX_THM4_USB_THERM_100K_PU(7)>;
+ label = "pm8550b_usb_therm";
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ qcom,adc-tm;
+ };
+
+ channel@749 {
+ reg = <PM8550B_ADC5_GEN3_AMUX_THM6_GPIO10_100K_PU(7)>;
+ label = "pm8550b_wls_therm";
+ qcom,ratiometric;
+ qcom,pre-scaling = <1 1>;
+ qcom,adc-tm;
+ };
+};
+
&pon_pwrkey {
status = "okay";
};
--
2.34.1
^ permalink raw reply related
* [PATCH RFC v3 5/6] arm64: dts: qcom: sm8650-qrd: add SPMI ADC channels and thermal nodes
From: Neil Armstrong @ 2026-06-15 17:00 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Neil Armstrong
In-Reply-To: <20260615-topic-sm8x50-adc5-gen3-v3-0-216a2b5ccb85@linaro.org>
Add the SPMI ADC channels on the PMK8550 SPMI5 ADC3 for the
other PMICS on the system.
The thermal nodes are sorted by the sensor channel to be
coherent with the system thermal nodes ordering.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
arch/arm64/boot/dts/qcom/sm8650-qrd.dts | 279 ++++++++++++++++++++++++++++++++
1 file changed, 279 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8650-qrd.dts b/arch/arm64/boot/dts/qcom/sm8650-qrd.dts
index a3982ae22929..0f5f9e55586a 100644
--- a/arch/arm64/boot/dts/qcom/sm8650-qrd.dts
+++ b/arch/arm64/boot/dts/qcom/sm8650-qrd.dts
@@ -16,6 +16,9 @@
#include "pm8550vs.dtsi"
#include "pmk8550.dtsi"
#include "pmr735d_a.dtsi"
+#include "qcom,pm8550-adc5-gen3.h"
+#include "qcom,pm8550b-adc5-gen3.h"
+#include "qcom,pm8550vx-adc5-gen3.h"
/ {
model = "Qualcomm Technologies, Inc. SM8650 QRD";
@@ -158,6 +161,92 @@ platform {
};
};
+ thermal-zones {
+ skin-thermal {
+ thermal-sensors = <&pmk8550_vadc PM8550_ADC5_GEN3_AMUX_THM1_100K_PU(1)>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ cam-flash-thermal {
+ thermal-sensors = <&pmk8550_vadc PM8550_ADC5_GEN3_AMUX_THM2_100K_PU(1)>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ wlan-thermal {
+ thermal-sensors = <&pmk8550_vadc PM8550_ADC5_GEN3_AMUX_THM3_100K_PU(1)>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ pa-thermal {
+ thermal-sensors = <&pmk8550_vadc PM8550_ADC5_GEN3_AMUX_THM4_100K_PU(1)>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ rear-tof-thermal {
+ thermal-sensors = <&pmk8550_vadc PM8550_ADC5_GEN3_AMUX_THM5_100K_PU(1)>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ usb-thermal {
+ thermal-sensors = <&pmk8550_vadc PM8550B_ADC5_GEN3_AMUX_THM4_USB_THERM_100K_PU(7)>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ wls-thermal {
+ thermal-sensors = <&pmk8550_vadc PM8550B_ADC5_GEN3_AMUX_THM6_GPIO10_100K_PU(7)>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+ };
+
vph_pwr: vph-pwr-regulator {
compatible = "regulator-fixed";
@@ -1040,27 +1129,217 @@ led@3 {
};
};
+&pm8550_temp_alarm {
+ io-channels = <&pmk8550_vadc PM8550_ADC5_GEN3_DIE_TEMP(1)>;
+ io-channel-names = "thermal";
+};
+
&pm8550b_eusb2_repeater {
vdd18-supply = <&vreg_l15b_1p8>;
vdd3-supply = <&vreg_l5b_3p1>;
};
+&pm8550b_temp_alarm {
+ io-channels = <&pmk8550_vadc PM8550B_ADC5_GEN3_DIE_TEMP(7)>;
+ io-channel-names = "thermal";
+};
+
&pm8550vs_c {
status = "okay";
};
+&pm8550vs_c_temp_alarm {
+ io-channels = <&pmk8550_vadc PM8550VS_ADC5_GEN3_DIE_TEMP(2)>;
+ io-channel-names = "thermal";
+};
+
&pm8550vs_d {
status = "okay";
};
+&pm8550vs_d_temp_alarm {
+ io-channels = <&pmk8550_vadc PM8550VS_ADC5_GEN3_DIE_TEMP(3)>;
+ io-channel-names = "thermal";
+};
+
&pm8550vs_e {
status = "okay";
};
+&pm8550vs_e_temp_alarm {
+ io-channels = <&pmk8550_vadc PM8550VS_ADC5_GEN3_DIE_TEMP(4)>;
+ io-channel-names = "thermal";
+};
+
&pm8550vs_g {
status = "okay";
};
+&pm8550vs_g_temp_alarm {
+ io-channels = <&pmk8550_vadc PM8550VS_ADC5_GEN3_DIE_TEMP(6)>;
+ io-channel-names = "thermal";
+};
+
+&pm8550ve_temp_alarm {
+ io-channels = <&pmk8550_vadc PM8550VE_ADC5_GEN3_DIE_TEMP(PMK8550VE_SID)>;
+ io-channel-names = "thermal";
+};
+
+&pmk8550_vadc {
+ /* PM8550 Channel nodes */
+ channel@100 {
+ reg = <PM8550_ADC5_GEN3_REF_GND(1)>;
+ label = "pm8550_offset_ref";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ channel@101 {
+ reg = <PM8550_ADC5_GEN3_1P25VREF(1)>;
+ label = "pm8550_vref_1p25";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ channel@103 {
+ reg = <PM8550_ADC5_GEN3_DIE_TEMP(1)>;
+ label = "pm8550_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ channel@18e {
+ reg = <PM8550_ADC5_GEN3_VPH_PWR(1)>;
+ label = "pm8550_vph_pwr";
+ qcom,pre-scaling = <1 3>;
+ };
+
+ channel@144 {
+ reg = <PM8550_ADC5_GEN3_AMUX_THM1_100K_PU(1)>;
+ label = "pm8550_msm_therm";
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ qcom,adc-tm;
+ };
+
+ channel@145 {
+ reg = <PM8550_ADC5_GEN3_AMUX_THM2_100K_PU(1)>;
+ label = "pm8550_cam_flash_therm";
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ qcom,adc-tm;
+ };
+
+ channel@146 {
+ reg = <PM8550_ADC5_GEN3_AMUX_THM3_100K_PU(1)>;
+ label = "pm8550_wlan_therm";
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ qcom,adc-tm;
+ };
+
+ channel@147 {
+ reg = <PM8550_ADC5_GEN3_AMUX_THM4_100K_PU(1)>;
+ label = "pm8550_pa_therm_1";
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ qcom,adc-tm;
+ };
+
+ channel@148 {
+ reg = <PM8550_ADC5_GEN3_AMUX_THM5_100K_PU(1)>;
+ label = "pm8550_rear_tof_therm";
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ qcom,adc-tm;
+ };
+
+ /* PM8550VS_C Channel nodes */
+ channel@203 {
+ reg = <PM8550VS_ADC5_GEN3_DIE_TEMP(2)>;
+ label = "pm8550vs_c_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ /* PM8550VS_D Channel nodes */
+ channel@303 {
+ reg = <PM8550VS_ADC5_GEN3_DIE_TEMP(3)>;
+ label = "pm8550vs_d_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ /* PM8550VS_E Channel nodes */
+ channel@403 {
+ reg = <PM8550VS_ADC5_GEN3_DIE_TEMP(4)>;
+ label = "pm8550vs_e_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ /* PM8550VE Channel nodes */
+ channel@503 {
+ reg = <PM8550VE_ADC5_GEN3_DIE_TEMP(PMK8550VE_SID)>;
+ label = "pm8550ve_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ /* PM8550VS_G Channel nodes */
+ channel@603 {
+ reg = <PM8550VS_ADC5_GEN3_DIE_TEMP(6)>;
+ label = "pm8550vs_g_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ /* PM8550B Channel nodes */
+ channel@700 {
+ reg = <PM8550B_ADC5_GEN3_REF_GND(7)>;
+ label = "pm8550b_offset_ref";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ channel@701 {
+ reg = <PM8550B_ADC5_GEN3_1P25VREF(7)>;
+ label = "pm8550b_vref_1p25";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ channel@703 {
+ reg = <PM8550B_ADC5_GEN3_DIE_TEMP(7)>;
+ label = "pm8550b_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ channel@78e {
+ reg = <PM8550B_ADC5_GEN3_VPH_PWR(7)>;
+ label = "pm8550b_vph_pwr";
+ qcom,pre-scaling = <1 3>;
+ };
+
+ channel@78f {
+ reg = <PM8550B_ADC5_GEN3_VBAT_SNS_QBG(7)>;
+ label = "pm8550b_vbat_sns_qbg";
+ qcom,pre-scaling = <1 6>;
+ };
+
+ channel@747 {
+ reg = <PM8550B_ADC5_GEN3_AMUX_THM4_USB_THERM_100K_PU(7)>;
+ label = "pm8550b_usb_therm";
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ qcom,adc-tm;
+ };
+
+ channel@749 {
+ reg = <PM8550B_ADC5_GEN3_AMUX_THM6_GPIO10_100K_PU(7)>;
+ label = "pm8550b_wls_therm";
+ qcom,ratiometric;
+ qcom,pre-scaling = <1 1>;
+ qcom,adc-tm;
+ };
+};
+
&qup_i2c3_data_clk {
/* Use internal I2C pull-up */
bias-pull-up = <2200>;
--
2.34.1
^ permalink raw reply related
* [PATCH RFC v3 4/6] arm64: dts: qcom: sm8550-hdk: add SPMI ADC channels and thermal nodes
From: Neil Armstrong @ 2026-06-15 17:00 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Neil Armstrong
In-Reply-To: <20260615-topic-sm8x50-adc5-gen3-v3-0-216a2b5ccb85@linaro.org>
Add the SPMI ADC channels on the PMK8550 SPMI5 ADC3 for the
other PMICS on the system.
The thermal nodes are sorted by the sensor channel to be
coherent with the system thermal nodes ordering.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
arch/arm64/boot/dts/qcom/sm8550-hdk.dts | 279 ++++++++++++++++++++++++++++++++
1 file changed, 279 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8550-hdk.dts b/arch/arm64/boot/dts/qcom/sm8550-hdk.dts
index ee13e6136a82..83cf48a623fc 100644
--- a/arch/arm64/boot/dts/qcom/sm8550-hdk.dts
+++ b/arch/arm64/boot/dts/qcom/sm8550-hdk.dts
@@ -16,6 +16,9 @@
#include "pm8550vs.dtsi"
#include "pmk8550.dtsi"
#include "pmr735d_a.dtsi"
+#include "qcom,pm8550-adc5-gen3.h"
+#include "qcom,pm8550b-adc5-gen3.h"
+#include "qcom,pm8550vx-adc5-gen3.h"
/ {
model = "Qualcomm Technologies, Inc. SM8550 HDK";
@@ -280,6 +283,92 @@ platform {
};
};
+ thermal-zones {
+ skin-thermal {
+ thermal-sensors = <&pmk8550_vadc PM8550_ADC5_GEN3_AMUX_THM1_100K_PU(1)>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ cam-flash-thermal {
+ thermal-sensors = <&pmk8550_vadc PM8550_ADC5_GEN3_AMUX_THM2_100K_PU(1)>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ wlan-thermal {
+ thermal-sensors = <&pmk8550_vadc PM8550_ADC5_GEN3_AMUX_THM3_100K_PU(1)>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ pa-thermal {
+ thermal-sensors = <&pmk8550_vadc PM8550_ADC5_GEN3_AMUX_THM4_100K_PU(1)>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ rear-tof-thermal {
+ thermal-sensors = <&pmk8550_vadc PM8550_ADC5_GEN3_AMUX_THM5_100K_PU(1)>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ usb-thermal {
+ thermal-sensors = <&pmk8550_vadc PM8550B_ADC5_GEN3_AMUX_THM4_USB_THERM_100K_PU(7)>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ wls-thermal {
+ thermal-sensors = <&pmk8550_vadc PM8550B_ADC5_GEN3_AMUX_THM6_GPIO10_100K_PU(7)>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+ };
+
wcn7850-pmu {
compatible = "qcom,wcn7850-pmu";
@@ -1102,27 +1191,217 @@ led@3 {
};
};
+&pm8550_temp_alarm {
+ io-channels = <&pmk8550_vadc PM8550_ADC5_GEN3_DIE_TEMP(1)>;
+ io-channel-names = "thermal";
+};
+
&pm8550b_eusb2_repeater {
vdd18-supply = <&vreg_l15b_1p8>;
vdd3-supply = <&vreg_l5b_3p1>;
};
+&pm8550b_temp_alarm {
+ io-channels = <&pmk8550_vadc PM8550B_ADC5_GEN3_DIE_TEMP(7)>;
+ io-channel-names = "thermal";
+};
+
&pm8550vs_c {
status = "okay";
};
+&pm8550vs_c_temp_alarm {
+ io-channels = <&pmk8550_vadc PM8550VS_ADC5_GEN3_DIE_TEMP(2)>;
+ io-channel-names = "thermal";
+};
+
&pm8550vs_d {
status = "okay";
};
+&pm8550vs_d_temp_alarm {
+ io-channels = <&pmk8550_vadc PM8550VS_ADC5_GEN3_DIE_TEMP(3)>;
+ io-channel-names = "thermal";
+};
+
&pm8550vs_e {
status = "okay";
};
+&pm8550vs_e_temp_alarm {
+ io-channels = <&pmk8550_vadc PM8550VS_ADC5_GEN3_DIE_TEMP(4)>;
+ io-channel-names = "thermal";
+};
+
&pm8550vs_g {
status = "okay";
};
+&pm8550vs_g_temp_alarm {
+ io-channels = <&pmk8550_vadc PM8550VS_ADC5_GEN3_DIE_TEMP(6)>;
+ io-channel-names = "thermal";
+};
+
+&pm8550ve_temp_alarm {
+ io-channels = <&pmk8550_vadc PM8550VE_ADC5_GEN3_DIE_TEMP(PMK8550VE_SID)>;
+ io-channel-names = "thermal";
+};
+
+&pmk8550_vadc {
+ /* PM8550 Channel nodes */
+ channel@100 {
+ reg = <PM8550_ADC5_GEN3_REF_GND(1)>;
+ label = "pm8550_offset_ref";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ channel@101 {
+ reg = <PM8550_ADC5_GEN3_1P25VREF(1)>;
+ label = "pm8550_vref_1p25";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ channel@103 {
+ reg = <PM8550_ADC5_GEN3_DIE_TEMP(1)>;
+ label = "pm8550_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ channel@18e {
+ reg = <PM8550_ADC5_GEN3_VPH_PWR(1)>;
+ label = "pm8550_vph_pwr";
+ qcom,pre-scaling = <1 3>;
+ };
+
+ channel@144 {
+ reg = <PM8550_ADC5_GEN3_AMUX_THM1_100K_PU(1)>;
+ label = "pm8550_msm_therm";
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ qcom,adc-tm;
+ };
+
+ channel@145 {
+ reg = <PM8550_ADC5_GEN3_AMUX_THM2_100K_PU(1)>;
+ label = "pm8550_cam_flash_therm";
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ qcom,adc-tm;
+ };
+
+ channel@146 {
+ reg = <PM8550_ADC5_GEN3_AMUX_THM3_100K_PU(1)>;
+ label = "pm8550_wlan_therm";
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ qcom,adc-tm;
+ };
+
+ channel@147 {
+ reg = <PM8550_ADC5_GEN3_AMUX_THM4_100K_PU(1)>;
+ label = "pm8550_pa_therm_1";
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ qcom,adc-tm;
+ };
+
+ channel@148 {
+ reg = <PM8550_ADC5_GEN3_AMUX_THM5_100K_PU(1)>;
+ label = "pm8550_rear_tof_therm";
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ qcom,adc-tm;
+ };
+
+ /* PM8550VS_C Channel nodes */
+ channel@203 {
+ reg = <PM8550VS_ADC5_GEN3_DIE_TEMP(2)>;
+ label = "pm8550vs_c_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ /* PM8550VS_D Channel nodes */
+ channel@303 {
+ reg = <PM8550VS_ADC5_GEN3_DIE_TEMP(3)>;
+ label = "pm8550vs_d_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ /* PM8550VS_E Channel nodes */
+ channel@403 {
+ reg = <PM8550VS_ADC5_GEN3_DIE_TEMP(4)>;
+ label = "pm8550vs_e_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ /* PM8550VE Channel nodes */
+ channel@503 {
+ reg = <PM8550VE_ADC5_GEN3_DIE_TEMP(PMK8550VE_SID)>;
+ label = "pm8550ve_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ /* PM8550VS_G Channel nodes */
+ channel@603 {
+ reg = <PM8550VS_ADC5_GEN3_DIE_TEMP(6)>;
+ label = "pm8550vs_g_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ /* PM8550B Channel nodes */
+ channel@700 {
+ reg = <PM8550B_ADC5_GEN3_REF_GND(7)>;
+ label = "pm8550b_offset_ref";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ channel@701 {
+ reg = <PM8550B_ADC5_GEN3_1P25VREF(7)>;
+ label = "pm8550b_vref_1p25";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ channel@703 {
+ reg = <PM8550B_ADC5_GEN3_DIE_TEMP(7)>;
+ label = "pm8550b_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ channel@78e {
+ reg = <PM8550B_ADC5_GEN3_VPH_PWR(7)>;
+ label = "pm8550b_vph_pwr";
+ qcom,pre-scaling = <1 3>;
+ };
+
+ channel@78f {
+ reg = <PM8550B_ADC5_GEN3_VBAT_SNS_QBG(7)>;
+ label = "pm8550b_vbat_sns_qbg";
+ qcom,pre-scaling = <1 6>;
+ };
+
+ channel@747 {
+ reg = <PM8550B_ADC5_GEN3_AMUX_THM4_USB_THERM_100K_PU(7)>;
+ label = "pm8550b_usb_therm";
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ qcom,adc-tm;
+ };
+
+ channel@749 {
+ reg = <PM8550B_ADC5_GEN3_AMUX_THM6_GPIO10_100K_PU(7)>;
+ label = "pm8550b_wls_therm";
+ qcom,ratiometric;
+ qcom,pre-scaling = <1 1>;
+ qcom,adc-tm;
+ };
+};
+
&pon_pwrkey {
status = "okay";
};
--
2.34.1
^ permalink raw reply related
* [PATCH RFC v3 3/6] arm64: dts: qcom: sm8550-qrd: add SPMI ADC channels and thermal nodes
From: Neil Armstrong @ 2026-06-15 17:00 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Neil Armstrong
In-Reply-To: <20260615-topic-sm8x50-adc5-gen3-v3-0-216a2b5ccb85@linaro.org>
Add the SPMI ADC channels on the PMK8550 SPMI5 ADC3 for the
other PMICS on the system.
The thermal nodes are sorted by the sensor channel to be
coherent with the system thermal nodes ordering.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
arch/arm64/boot/dts/qcom/sm8550-qrd.dts | 279 ++++++++++++++++++++++++++++++++
1 file changed, 279 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8550-qrd.dts b/arch/arm64/boot/dts/qcom/sm8550-qrd.dts
index 2fb2e0be5e4c..8405cb9e0d6d 100644
--- a/arch/arm64/boot/dts/qcom/sm8550-qrd.dts
+++ b/arch/arm64/boot/dts/qcom/sm8550-qrd.dts
@@ -17,6 +17,9 @@
#include "pmk8550.dtsi"
#include "pmr735d_a.dtsi"
#include "pmr735d_b.dtsi"
+#include "qcom,pm8550-adc5-gen3.h"
+#include "qcom,pm8550b-adc5-gen3.h"
+#include "qcom,pm8550vx-adc5-gen3.h"
/ {
model = "Qualcomm Technologies, Inc. SM8550 QRD";
@@ -205,6 +208,92 @@ platform {
};
};
+ thermal-zones {
+ skin-thermal {
+ thermal-sensors = <&pmk8550_vadc PM8550_ADC5_GEN3_AMUX_THM1_100K_PU(1)>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ cam-flash-thermal {
+ thermal-sensors = <&pmk8550_vadc PM8550_ADC5_GEN3_AMUX_THM2_100K_PU(1)>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ wlan-thermal {
+ thermal-sensors = <&pmk8550_vadc PM8550_ADC5_GEN3_AMUX_THM3_100K_PU(1)>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ pa-thermal {
+ thermal-sensors = <&pmk8550_vadc PM8550_ADC5_GEN3_AMUX_THM4_100K_PU(1)>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ rear-tof-thermal {
+ thermal-sensors = <&pmk8550_vadc PM8550_ADC5_GEN3_AMUX_THM5_100K_PU(1)>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ usb-thermal {
+ thermal-sensors = <&pmk8550_vadc PM8550B_ADC5_GEN3_AMUX_THM4_USB_THERM_100K_PU(7)>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ wls-thermal {
+ thermal-sensors = <&pmk8550_vadc PM8550B_ADC5_GEN3_AMUX_THM6_GPIO10_100K_PU(7)>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+ };
+
vph_pwr: vph-pwr-regulator {
compatible = "regulator-fixed";
regulator-name = "vph_pwr";
@@ -997,27 +1086,217 @@ led@3 {
};
};
+&pm8550_temp_alarm {
+ io-channels = <&pmk8550_vadc PM8550_ADC5_GEN3_DIE_TEMP(1)>;
+ io-channel-names = "thermal";
+};
+
&pm8550b_eusb2_repeater {
vdd18-supply = <&vreg_l15b_1p8>;
vdd3-supply = <&vreg_l5b_3p1>;
};
+&pm8550b_temp_alarm {
+ io-channels = <&pmk8550_vadc PM8550B_ADC5_GEN3_DIE_TEMP(7)>;
+ io-channel-names = "thermal";
+};
+
&pm8550vs_c {
status = "okay";
};
+&pm8550vs_c_temp_alarm {
+ io-channels = <&pmk8550_vadc PM8550VS_ADC5_GEN3_DIE_TEMP(2)>;
+ io-channel-names = "thermal";
+};
+
&pm8550vs_d {
status = "okay";
};
+&pm8550vs_d_temp_alarm {
+ io-channels = <&pmk8550_vadc PM8550VS_ADC5_GEN3_DIE_TEMP(3)>;
+ io-channel-names = "thermal";
+};
+
&pm8550vs_e {
status = "okay";
};
+&pm8550vs_e_temp_alarm {
+ io-channels = <&pmk8550_vadc PM8550VS_ADC5_GEN3_DIE_TEMP(4)>;
+ io-channel-names = "thermal";
+};
+
&pm8550vs_g {
status = "okay";
};
+&pm8550vs_g_temp_alarm {
+ io-channels = <&pmk8550_vadc PM8550VS_ADC5_GEN3_DIE_TEMP(6)>;
+ io-channel-names = "thermal";
+};
+
+&pm8550ve_temp_alarm {
+ io-channels = <&pmk8550_vadc PM8550VE_ADC5_GEN3_DIE_TEMP(PMK8550VE_SID)>;
+ io-channel-names = "thermal";
+};
+
+&pmk8550_vadc {
+ /* PM8550 Channel nodes */
+ channel@100 {
+ reg = <PM8550_ADC5_GEN3_REF_GND(1)>;
+ label = "pm8550_offset_ref";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ channel@101 {
+ reg = <PM8550_ADC5_GEN3_1P25VREF(1)>;
+ label = "pm8550_vref_1p25";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ channel@103 {
+ reg = <PM8550_ADC5_GEN3_DIE_TEMP(1)>;
+ label = "pm8550_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ channel@18e {
+ reg = <PM8550_ADC5_GEN3_VPH_PWR(1)>;
+ label = "pm8550_vph_pwr";
+ qcom,pre-scaling = <1 3>;
+ };
+
+ channel@144 {
+ reg = <PM8550_ADC5_GEN3_AMUX_THM1_100K_PU(1)>;
+ label = "pm8550_msm_therm";
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ qcom,adc-tm;
+ };
+
+ channel@145 {
+ reg = <PM8550_ADC5_GEN3_AMUX_THM2_100K_PU(1)>;
+ label = "pm8550_cam_flash_therm";
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ qcom,adc-tm;
+ };
+
+ channel@146 {
+ reg = <PM8550_ADC5_GEN3_AMUX_THM3_100K_PU(1)>;
+ label = "pm8550_wlan_therm";
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ qcom,adc-tm;
+ };
+
+ channel@147 {
+ reg = <PM8550_ADC5_GEN3_AMUX_THM4_100K_PU(1)>;
+ label = "pm8550_pa_therm_1";
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ qcom,adc-tm;
+ };
+
+ channel@148 {
+ reg = <PM8550_ADC5_GEN3_AMUX_THM5_100K_PU(1)>;
+ label = "pm8550_rear_tof_therm";
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ qcom,adc-tm;
+ };
+
+ /* PM8550VS_C Channel nodes */
+ channel@203 {
+ reg = <PM8550VS_ADC5_GEN3_DIE_TEMP(2)>;
+ label = "pm8550vs_c_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ /* PM8550VS_D Channel nodes */
+ channel@303 {
+ reg = <PM8550VS_ADC5_GEN3_DIE_TEMP(3)>;
+ label = "pm8550vs_d_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ /* PM8550VS_E Channel nodes */
+ channel@403 {
+ reg = <PM8550VS_ADC5_GEN3_DIE_TEMP(4)>;
+ label = "pm8550vs_e_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ /* PM8550VE Channel nodes */
+ channel@503 {
+ reg = <PM8550VE_ADC5_GEN3_DIE_TEMP(PMK8550VE_SID)>;
+ label = "pm8550ve_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ /* PM8550VS_G Channel nodes */
+ channel@603 {
+ reg = <PM8550VS_ADC5_GEN3_DIE_TEMP(6)>;
+ label = "pm8550vs_g_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ /* PM8550B Channel nodes */
+ channel@700 {
+ reg = <PM8550B_ADC5_GEN3_REF_GND(7)>;
+ label = "pm8550b_offset_ref";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ channel@701 {
+ reg = <PM8550B_ADC5_GEN3_1P25VREF(7)>;
+ label = "pm8550b_vref_1p25";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ channel@703 {
+ reg = <PM8550B_ADC5_GEN3_DIE_TEMP(7)>;
+ label = "pm8550b_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ channel@78e {
+ reg = <PM8550B_ADC5_GEN3_VPH_PWR(7)>;
+ label = "pm8550b_vph_pwr";
+ qcom,pre-scaling = <1 3>;
+ };
+
+ channel@78f {
+ reg = <PM8550B_ADC5_GEN3_VBAT_SNS_QBG(7)>;
+ label = "pm8550b_vbat_sns_qbg";
+ qcom,pre-scaling = <1 6>;
+ };
+
+ channel@747 {
+ reg = <PM8550B_ADC5_GEN3_AMUX_THM4_USB_THERM_100K_PU(7)>;
+ label = "pm8550b_usb_therm";
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ qcom,adc-tm;
+ };
+
+ channel@749 {
+ reg = <PM8550B_ADC5_GEN3_AMUX_THM6_GPIO10_100K_PU(7)>;
+ label = "pm8550b_wls_therm";
+ qcom,ratiometric;
+ qcom,pre-scaling = <1 1>;
+ qcom,adc-tm;
+ };
+};
+
&pon_pwrkey {
status = "okay";
};
--
2.34.1
^ permalink raw reply related
* [PATCH RFC v3 2/6] arm64: dts: qcom: pmk8550: add VADC node
From: Neil Armstrong @ 2026-06-15 17:00 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Neil Armstrong
In-Reply-To: <20260615-topic-sm8x50-adc5-gen3-v3-0-216a2b5ccb85@linaro.org>
Add the VADC node and the initial pmk8550 adc channels.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
arch/arm64/boot/dts/qcom/pmk8550.dtsi | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/pmk8550.dtsi b/arch/arm64/boot/dts/qcom/pmk8550.dtsi
index 3049eb6b46d7..515cae060f27 100644
--- a/arch/arm64/boot/dts/qcom/pmk8550.dtsi
+++ b/arch/arm64/boot/dts/qcom/pmk8550.dtsi
@@ -7,6 +7,7 @@
#include <dt-bindings/input/linux-event-codes.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/spmi/spmi.h>
+#include "qcom,pmk8550-adc5-gen3.h"
/ {
reboot-mode {
@@ -44,6 +45,35 @@ pon_resin: resin {
};
};
+ pmk8550_vadc: adc@9000 {
+ compatible = "qcom,spmi-adc5-gen3";
+ reg = <0x9000>, <0x9100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <0x0 0x90 0x1 IRQ_TYPE_EDGE_RISING>,
+ <0x0 0x91 0x1 IRQ_TYPE_EDGE_RISING>;
+ #io-channel-cells = <1>;
+ #thermal-sensor-cells = <1>;
+
+ channel@0 {
+ reg = <PMK8550_ADC5_GEN3_REF_GND(0)>;
+ label = "pmk8550_offset_ref";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ channel@1 {
+ reg = <PMK8550_ADC5_GEN3_1P25VREF(0)>;
+ label = "pmk8550_vref_1p25";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ channel@3 {
+ reg = <PMK8550_ADC5_GEN3_DIE_TEMP(0)>;
+ label = "pmk8550_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+ };
+
pmk8550_rtc: rtc@6100 {
compatible = "qcom,pmk8350-rtc";
reg = <0x6100>, <0x6200>;
--
2.34.1
^ permalink raw reply related
* [PATCH RFC v3 1/6] arm64: dts: qcom: add PMIC5 Gen3 macros for channel numbers
From: Neil Armstrong @ 2026-06-15 17:00 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Neil Armstrong
In-Reply-To: <20260615-topic-sm8x50-adc5-gen3-v3-0-216a2b5ccb85@linaro.org>
Add the PMIC5 Gen3 macros to calculate the channel numbers which
is a combination of SPMI bus number and a constant for the sensor
type and configuration.
The macros definitions were taken out of [1] where it was initially
in the dt-bindings include directory but since those are not hardware
bindings but logical numbers, they can be moved to local includes
instead to make the DT source more readable.
[1] https://lore.kernel.org/all/20250826083657.4005727-4-jishnu.prakash@oss.qualcomm.com/
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
arch/arm64/boot/dts/qcom/qcom,adc5-gen3-channels.h | 88 ++++++++++++++++++++++
arch/arm64/boot/dts/qcom/qcom,pm8550-adc5-gen3.h | 46 +++++++++++
arch/arm64/boot/dts/qcom/qcom,pm8550b-adc5-gen3.h | 85 +++++++++++++++++++++
arch/arm64/boot/dts/qcom/qcom,pm8550vx-adc5-gen3.h | 22 ++++++
arch/arm64/boot/dts/qcom/qcom,pmk8550-adc5-gen3.h | 52 +++++++++++++
5 files changed, 293 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/qcom,adc5-gen3-channels.h b/arch/arm64/boot/dts/qcom/qcom,adc5-gen3-channels.h
new file mode 100644
index 000000000000..a8aac9ae6f40
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/qcom,adc5-gen3-channels.h
@@ -0,0 +1,88 @@
+ /* SPDX-License-Identifier: GPL-2.0 */
+ /*
+ * Copyright (c) 2025, Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+
+#ifndef _QCOM_ADC5_GEN3_CHANNELS_H
+#define _QCOM_ADC5_GEN3_CHANNELS_H
+
+/* ADC channels for PMIC5 Gen3 */
+
+#define ADC5_GEN3_REF_GND 0x00
+#define ADC5_GEN3_1P25VREF 0x01
+#define ADC5_GEN3_VREF_VADC 0x02
+#define ADC5_GEN3_DIE_TEMP 0x03
+
+#define ADC5_GEN3_AMUX1_THM 0x04
+#define ADC5_GEN3_AMUX2_THM 0x05
+#define ADC5_GEN3_AMUX3_THM 0x06
+#define ADC5_GEN3_AMUX4_THM 0x07
+#define ADC5_GEN3_AMUX5_THM 0x08
+#define ADC5_GEN3_AMUX6_THM 0x09
+#define ADC5_GEN3_AMUX1_GPIO 0x0a
+#define ADC5_GEN3_AMUX2_GPIO 0x0b
+#define ADC5_GEN3_AMUX3_GPIO 0x0c
+#define ADC5_GEN3_AMUX4_GPIO 0x0d
+
+#define ADC5_GEN3_CHG_TEMP 0x10
+#define ADC5_GEN3_USB_SNS_V_16 0x11
+#define ADC5_GEN3_VIN_DIV16_MUX 0x12
+#define ADC5_GEN3_VREF_BAT_THERM 0x15
+#define ADC5_GEN3_IIN_FB 0x17
+#define ADC5_GEN3_TEMP_ALARM_LITE 0x18
+#define ADC5_GEN3_IIN_SMB 0x19
+#define ADC5_GEN3_ICHG_SMB 0x1b
+#define ADC5_GEN3_ICHG_FB 0xa1
+
+/* 30k pull-up1 */
+#define ADC5_GEN3_AMUX1_THM_30K_PU 0x24
+#define ADC5_GEN3_AMUX2_THM_30K_PU 0x25
+#define ADC5_GEN3_AMUX3_THM_30K_PU 0x26
+#define ADC5_GEN3_AMUX4_THM_30K_PU 0x27
+#define ADC5_GEN3_AMUX5_THM_30K_PU 0x28
+#define ADC5_GEN3_AMUX6_THM_30K_PU 0x29
+#define ADC5_GEN3_AMUX1_GPIO_30K_PU 0x2a
+#define ADC5_GEN3_AMUX2_GPIO_30K_PU 0x2b
+#define ADC5_GEN3_AMUX3_GPIO_30K_PU 0x2c
+#define ADC5_GEN3_AMUX4_GPIO_30K_PU 0x2d
+
+/* 100k pull-up2 */
+#define ADC5_GEN3_AMUX1_THM_100K_PU 0x44
+#define ADC5_GEN3_AMUX2_THM_100K_PU 0x45
+#define ADC5_GEN3_AMUX3_THM_100K_PU 0x46
+#define ADC5_GEN3_AMUX4_THM_100K_PU 0x47
+#define ADC5_GEN3_AMUX5_THM_100K_PU 0x48
+#define ADC5_GEN3_AMUX6_THM_100K_PU 0x49
+#define ADC5_GEN3_AMUX1_GPIO_100K_PU 0x4a
+#define ADC5_GEN3_AMUX2_GPIO_100K_PU 0x4b
+#define ADC5_GEN3_AMUX3_GPIO_100K_PU 0x4c
+#define ADC5_GEN3_AMUX4_GPIO_100K_PU 0x4d
+
+/* 400k pull-up3 */
+#define ADC5_GEN3_AMUX1_THM_400K_PU 0x64
+#define ADC5_GEN3_AMUX2_THM_400K_PU 0x65
+#define ADC5_GEN3_AMUX3_THM_400K_PU 0x66
+#define ADC5_GEN3_AMUX4_THM_400K_PU 0x67
+#define ADC5_GEN3_AMUX5_THM_400K_PU 0x68
+#define ADC5_GEN3_AMUX6_THM_400K_PU 0x69
+#define ADC5_GEN3_AMUX1_GPIO_400K_PU 0x6a
+#define ADC5_GEN3_AMUX2_GPIO_400K_PU 0x6b
+#define ADC5_GEN3_AMUX3_GPIO_400K_PU 0x6c
+#define ADC5_GEN3_AMUX4_GPIO_400K_PU 0x6d
+
+/* 1/3 Divider */
+#define ADC5_GEN3_AMUX1_GPIO_DIV3 0x8a
+#define ADC5_GEN3_AMUX2_GPIO_DIV3 0x8b
+#define ADC5_GEN3_AMUX3_GPIO_DIV3 0x8c
+#define ADC5_GEN3_AMUX4_GPIO_DIV3 0x8d
+
+#define ADC5_GEN3_VPH_PWR 0x8e
+#define ADC5_GEN3_VBAT_SNS_QBG 0x8f
+
+#define ADC5_GEN3_VBAT_SNS_CHGR 0x94
+#define ADC5_GEN3_VBAT_2S_MID_QBG 0x96
+#define ADC5_GEN3_VBAT_2S_MID_CHGR 0x9d
+
+#define ADC5_GEN3_OFFSET_EXT2 0xf8
+
+#endif /* _QCOM_ADC5_GEN3_CHANNELS_H */
diff --git a/arch/arm64/boot/dts/qcom/qcom,pm8550-adc5-gen3.h b/arch/arm64/boot/dts/qcom/qcom,pm8550-adc5-gen3.h
new file mode 100644
index 000000000000..2a6338812d4e
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/qcom,pm8550-adc5-gen3.h
@@ -0,0 +1,46 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+/*
+ * Copyright (c) 2025, Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+
+#ifndef _QCOM_PM8550_ACD5_GEN3_H
+#define _QCOM_PM8550_ACD5_GEN3_H
+
+#include "qcom,adc5-gen3-channels.h"
+
+/* ADC channels for PM8550_ADC for PMIC5 Gen3 */
+#define PM8550_ADC5_GEN3_REF_GND(sid) ((sid) << 8 | ADC5_GEN3_REF_GND)
+#define PM8550_ADC5_GEN3_1P25VREF(sid) ((sid) << 8 | ADC5_GEN3_1P25VREF)
+#define PM8550_ADC5_GEN3_VREF_VADC(sid) ((sid) << 8 | ADC5_GEN3_VREF_VADC)
+#define PM8550_ADC5_GEN3_DIE_TEMP(sid) ((sid) << 8 | ADC5_GEN3_DIE_TEMP)
+
+#define PM8550_ADC5_GEN3_AMUX_THM1(sid) ((sid) << 8 | ADC5_GEN3_AMUX1_THM)
+#define PM8550_ADC5_GEN3_AMUX_THM2(sid) ((sid) << 8 | ADC5_GEN3_AMUX2_THM)
+#define PM8550_ADC5_GEN3_AMUX_THM3(sid) ((sid) << 8 | ADC5_GEN3_AMUX3_THM)
+#define PM8550_ADC5_GEN3_AMUX_THM4(sid) ((sid) << 8 | ADC5_GEN3_AMUX4_THM)
+#define PM8550_ADC5_GEN3_AMUX_THM5(sid) ((sid) << 8 | ADC5_GEN3_AMUX5_THM)
+#define PM8550_ADC5_GEN3_AMUX_THM6_GPIO2(sid) ((sid) << 8 | ADC5_GEN3_AMUX6_THM)
+#define PM8550_ADC5_GEN3_AMUX1_GPIO3(sid) ((sid) << 8 | ADC5_GEN3_AMUX1_GPIO)
+#define PM8550_ADC5_GEN3_AMUX2_GPIO4(sid) ((sid) << 8 | ADC5_GEN3_AMUX2_GPIO)
+#define PM8550_ADC5_GEN3_AMUX3_GPIO7(sid) ((sid) << 8 | ADC5_GEN3_AMUX3_GPIO)
+#define PM8550_ADC5_GEN3_AMUX4_GPIO12(sid) ((sid) << 8 | ADC5_GEN3_AMUX4_GPIO)
+
+/* 100k pull-up */
+#define PM8550_ADC5_GEN3_AMUX_THM1_100K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX1_THM_100K_PU)
+#define PM8550_ADC5_GEN3_AMUX_THM2_100K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX2_THM_100K_PU)
+#define PM8550_ADC5_GEN3_AMUX_THM3_100K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX3_THM_100K_PU)
+#define PM8550_ADC5_GEN3_AMUX_THM4_100K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX4_THM_100K_PU)
+#define PM8550_ADC5_GEN3_AMUX_THM5_100K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX5_THM_100K_PU)
+#define PM8550_ADC5_GEN3_AMUX_THM6_GPIO2_100K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX6_THM_100K_PU)
+#define PM8550_ADC5_GEN3_AMUX1_GPIO3_100K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX1_GPIO_100K_PU)
+#define PM8550_ADC5_GEN3_AMUX2_GPIO4_100K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX2_GPIO_100K_PU)
+#define PM8550_ADC5_GEN3_AMUX3_GPIO7_100K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX3_GPIO_100K_PU)
+#define PM8550_ADC5_GEN3_AMUX4_GPIO12_100K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX4_GPIO_100K_PU)
+
+/* 1/3 Divider */
+#define PM8550_ADC5_GEN3_AMUX3_GPIO7_DIV3(sid) ((sid) << 8 | ADC5_GEN3_AMUX3_GPIO_DIV3)
+#define PM8550_ADC5_GEN3_AMUX4_GPIO12_DIV3(sid) ((sid) << 8 | ADC5_GEN3_AMUX4_GPIO_DIV3)
+
+#define PM8550_ADC5_GEN3_VPH_PWR(sid) ((sid) << 8 | ADC5_GEN3_VPH_PWR)
+
+#endif /* _QCOM_PM8550_ACD5_GEN3_H */
diff --git a/arch/arm64/boot/dts/qcom/qcom,pm8550b-adc5-gen3.h b/arch/arm64/boot/dts/qcom/qcom,pm8550b-adc5-gen3.h
new file mode 100644
index 000000000000..312daa846f79
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/qcom,pm8550b-adc5-gen3.h
@@ -0,0 +1,85 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+/*
+ * Copyright (c) 2025, Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+
+#ifndef _QCOM_PM8550B_ACD5_GEN3_H
+#define _QCOM_PM8550B_ACD5_GEN3_H
+
+#include "qcom,adc5-gen3-channels.h"
+
+/* ADC channels for PM8550B_ADC for PMIC5 Gen3 */
+#define PM8550B_ADC5_GEN3_REF_GND(sid) ((sid) << 8 | ADC5_GEN3_REF_GND)
+#define PM8550B_ADC5_GEN3_1P25VREF(sid) ((sid) << 8 | ADC5_GEN3_1P25VREF)
+#define PM8550B_ADC5_GEN3_VREF_VADC(sid) ((sid) << 8 | ADC5_GEN3_VREF_VADC)
+#define PM8550B_ADC5_GEN3_DIE_TEMP(sid) ((sid) << 8 | ADC5_GEN3_DIE_TEMP)
+
+#define PM8550B_ADC5_GEN3_AMUX_THM1_BATT_THERM(sid) ((sid) << 8 | ADC5_GEN3_AMUX1_THM)
+#define PM8550B_ADC5_GEN3_AMUX_THM2_BATT_ID(sid) ((sid) << 8 | ADC5_GEN3_AMUX2_THM)
+#define PM8550B_ADC5_GEN3_AMUX_THM3_SMB_TEMP_V(sid) ((sid) << 8 | ADC5_GEN3_AMUX3_THM)
+#define PM8550B_ADC5_GEN3_AMUX_THM4_USB_THERM(sid) ((sid) << 8 | ADC5_GEN3_AMUX4_THM)
+#define PM8550B_ADC5_GEN3_AMUX_THM5_OPTION(sid) ((sid) << 8 | ADC5_GEN3_AMUX5_THM)
+#define PM8550B_ADC5_GEN3_AMUX_THM6_GPIO10(sid) ((sid) << 8 | ADC5_GEN3_AMUX6_THM)
+#define PM8550B_ADC5_GEN3_AMUX1_GPIO1(sid) ((sid) << 8 | ADC5_GEN3_AMUX1_GPIO)
+#define PM8550B_ADC5_GEN3_AMUX2_GPIO5(sid) ((sid) << 8 | ADC5_GEN3_AMUX2_GPIO)
+#define PM8550B_ADC5_GEN3_AMUX3_GPIO6(sid) ((sid) << 8 | ADC5_GEN3_AMUX3_GPIO)
+#define PM8550B_ADC5_GEN3_AMUX4_GPIO12(sid) ((sid) << 8 | ADC5_GEN3_AMUX4_GPIO)
+
+#define PM8550B_ADC5_GEN3_CHG_TEMP(sid) ((sid) << 8 | ADC5_GEN3_CHG_TEMP)
+#define PM8550B_ADC5_GEN3_USB_SNS_V_16(sid) ((sid) << 8 | ADC5_GEN3_USB_SNS_V_16)
+#define PM8550B_ADC5_GEN3_VIN_DIV16_MUX(sid) ((sid) << 8 | ADC5_GEN3_VIN_DIV16_MUX)
+#define PM8550B_ADC5_GEN3_VREF_BAT_THERM(sid) ((sid) << 8 | ADC5_GEN3_VREF_BAT_THERM)
+#define PM8550B_ADC5_GEN3_IIN_FB(sid) ((sid) << 8 | ADC5_GEN3_IIN_FB)
+#define PM8550B_ADC5_GEN3_TEMP_ALARM_LITE(sid) ((sid) << 8 | ADC5_GEN3_TEMP_ALARM_LITE)
+#define PM8550B_ADC5_GEN3_SMB_IIN(sid) ((sid) << 8 | ADC5_GEN3_IIN_SMB)
+#define PM8550B_ADC5_GEN3_SMB_ICHG(sid) ((sid) << 8 | ADC5_GEN3_ICHG_SMB)
+#define PM8550B_ADC5_GEN3_ICHG_FB(sid) ((sid) << 8 | ADC5_GEN3_ICHG_FB)
+
+/* 30k pull-up */
+#define PM8550B_ADC5_GEN3_AMUX_THM1_BATT_THERM_30K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX1_THM_30K_PU)
+#define PM8550B_ADC5_GEN3_AMUX_THM2_BATT_ID_30K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX2_THM_30K_PU)
+#define PM8550B_ADC5_GEN3_AMUX_THM3_SMB_TEMP_V_30K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX3_THM_30K_PU)
+#define PM8550B_ADC5_GEN3_AMUX_THM4_USB_THERM_30K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX4_THM_30K_PU)
+#define PM8550B_ADC5_GEN3_AMUX_THM5_OPTION_30K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX5_THM_30K_PU)
+#define PM8550B_ADC5_GEN3_AMUX_THM6_GPIO10_30K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX6_THM_30K_PU)
+#define PM8550B_ADC5_GEN3_AMUX1_GPIO1_30K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX1_GPIO_30K_PU)
+#define PM8550B_ADC5_GEN3_AMUX2_GPIO5_30K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX2_GPIO_30K_PU)
+#define PM8550B_ADC5_GEN3_AMUX3_GPIO6_30K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX3_GPIO_30K_PU)
+#define PM8550B_ADC5_GEN3_AMUX4_GPIO12_30K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX4_GPIO_30K_PU)
+
+/* 100k pull-up */
+#define PM8550B_ADC5_GEN3_AMUX_THM1_BATT_THERM_100K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX1_THM_100K_PU)
+#define PM8550B_ADC5_GEN3_AMUX_THM2_BATT_ID_100K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX2_THM_100K_PU)
+#define PM8550B_ADC5_GEN3_AMUX_THM3_SMB_TEMP_V_100K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX3_THM_100K_PU)
+#define PM8550B_ADC5_GEN3_AMUX_THM4_USB_THERM_100K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX4_THM_100K_PU)
+#define PM8550B_ADC5_GEN3_AMUX_THM5_OPTION_100K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX5_THM_100K_PU)
+#define PM8550B_ADC5_GEN3_AMUX_THM6_GPIO10_100K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX6_THM_100K_PU)
+#define PM8550B_ADC5_GEN3_AMUX1_GPIO1_100K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX1_GPIO_100K_PU)
+#define PM8550B_ADC5_GEN3_AMUX2_GPIO5_100K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX2_GPIO_100K_PU)
+#define PM8550B_ADC5_GEN3_AMUX3_GPIO6_100K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX3_GPIO_100K_PU)
+#define PM8550B_ADC5_GEN3_AMUX4_GPIO12_100K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX4_GPIO_100K_PU)
+
+/* 400k pull-up */
+#define PM8550B_ADC5_GEN3_AMUX_THM1_BATT_THERM_400K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX1_THM_400K_PU)
+#define PM8550B_ADC5_GEN3_AMUX_THM2_BATT_ID_400K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX2_THM_400K_PU)
+#define PM8550B_ADC5_GEN3_AMUX_THM3_SMB_TEMP_V_400K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX3_THM_400K_PU)
+#define PM8550B_ADC5_GEN3_AMUX_THM4_USB_THERM_400K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX4_THM_400K_PU)
+#define PM8550B_ADC5_GEN3_AMUX_THM5_OPTION_400K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX5_THM_400K_PU)
+#define PM8550B_ADC5_GEN3_AMUX_THM6_GPIO10_400K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX6_THM_400K_PU)
+#define PM8550B_ADC5_GEN3_AMUX1_GPIO1_400K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX1_GPIO_400K_PU)
+#define PM8550B_ADC5_GEN3_AMUX2_GPIO5_400K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX2_GPIO_400K_PU)
+#define PM8550B_ADC5_GEN3_AMUX3_GPIO6_400K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX3_GPIO_400K_PU)
+#define PM8550B_ADC5_GEN3_AMUX4_GPIO12_400K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX4_GPIO_400K_PU)
+
+/* 1/3 Divider */
+#define PM8550B_ADC5_GEN3_AMUX1_GPIO1_DIV3(sid) ((sid) << 8 | ADC5_GEN3_AMUX1_GPIO_DIV3)
+#define PM8550B_ADC5_GEN3_AMUX2_GPIO5_DIV3(sid) ((sid) << 8 | ADC5_GEN3_AMUX2_GPIO_DIV3)
+#define PM8550B_ADC5_GEN3_AMUX3_GPIO6_DIV3(sid) ((sid) << 8 | ADC5_GEN3_AMUX3_GPIO_DIV3)
+
+#define PM8550B_ADC5_GEN3_VPH_PWR(sid) ((sid) << 8 | ADC5_GEN3_VPH_PWR)
+#define PM8550B_ADC5_GEN3_VBAT_SNS_QBG(sid) ((sid) << 8 | ADC5_GEN3_VBAT_SNS_QBG)
+#define PM8550B_ADC5_GEN3_VBAT_SNS_CHGR(sid) ((sid) << 8 | ADC5_GEN3_VBAT_SNS_CHGR)
+#define PM8550B_ADC5_GEN3_VBAT_2S_MID_QBG(sid) ((sid) << 8 | ADC5_GEN3_VBAT_2S_MID_QBG)
+#define PM8550B_ADC5_GEN3_VBAT_2S_MID_CHGR(sid) ((sid) << 8 | ADC5_GEN3_VBAT_2S_MID_CHGR)
+
+#endif /* _QCOM_PM8550B_ACD5_GEN3_H */
diff --git a/arch/arm64/boot/dts/qcom/qcom,pm8550vx-adc5-gen3.h b/arch/arm64/boot/dts/qcom/qcom,pm8550vx-adc5-gen3.h
new file mode 100644
index 000000000000..7a261a7a9cb0
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/qcom,pm8550vx-adc5-gen3.h
@@ -0,0 +1,22 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+/*
+ * Copyright (c) 2025, Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+
+#ifndef _QCOM_PM8550VX_ACD5_GEN3_H
+#define _QCOM_PM8550VX_ACD5_GEN3_H
+
+#include "qcom,adc5-gen3-channels.h"
+
+/* ADC channels for PM8550VX_ADC for PMIC5 Gen3 */
+#define PM8550VS_ADC5_GEN3_REF_GND(sid) ((sid) << 8 | ADC5_GEN3_REF_GND)
+#define PM8550VS_ADC5_GEN3_1P25VREF(sid) ((sid) << 8 | ADC5_GEN3_1P25VREF)
+#define PM8550VS_ADC5_GEN3_VREF_VADC(sid) ((sid) << 8 | ADC5_GEN3_VREF_VADC)
+#define PM8550VS_ADC5_GEN3_DIE_TEMP(sid) ((sid) << 8 | ADC5_GEN3_DIE_TEMP)
+
+#define PM8550VE_ADC5_GEN3_OFFSET_REF(sid) ((sid) << 8 | ADC5_GEN3_REF_GND)
+#define PM8550VE_ADC5_GEN3_1P25VREF(sid) ((sid) << 8 | ADC5_GEN3_1P25VREF)
+#define PM8550VE_ADC5_GEN3_VREF_VADC(sid) ((sid) << 8 | ADC5_GEN3_VREF_VADC)
+#define PM8550VE_ADC5_GEN3_DIE_TEMP(sid) ((sid) << 8 | ADC5_GEN3_DIE_TEMP)
+
+#endif /* _QCOM_PM8550VX_ACD5_GEN3_H */
diff --git a/arch/arm64/boot/dts/qcom/qcom,pmk8550-adc5-gen3.h b/arch/arm64/boot/dts/qcom/qcom,pmk8550-adc5-gen3.h
new file mode 100644
index 000000000000..60b3b9c60d4e
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/qcom,pmk8550-adc5-gen3.h
@@ -0,0 +1,52 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+/*
+ * Copyright (c) 2025, Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+
+#ifndef _QCOM_PMK8550_ACD5_GEN3_H
+#define _QCOM_PMK8550_ACD5_GEN3_H
+
+#include "qcom,adc5-gen3-channels.h"
+
+/* ADC channels for PMK8550_ADC for PMIC5 Gen3 */
+#define PMK8550_ADC5_GEN3_REF_GND(sid) ((sid) << 8 | ADC5_GEN3_REF_GND)
+#define PMK8550_ADC5_GEN3_1P25VREF(sid) ((sid) << 8 | ADC5_GEN3_1P25VREF)
+#define PMK8550_ADC5_GEN3_VREF_VADC(sid) ((sid) << 8 | ADC5_GEN3_VREF_VADC)
+#define PMK8550_ADC5_GEN3_DIE_TEMP(sid) ((sid) << 8 | ADC5_GEN3_DIE_TEMP)
+
+#define PMK8550_ADC5_GEN3_AMUX_THM1_XO_THERM(sid) ((sid) << 8 | ADC5_GEN3_AMUX1_THM)
+#define PMK8550_ADC5_GEN3_AMUX_THM2_GPIO1(sid) ((sid) << 8 | ADC5_GEN3_AMUX2_THM)
+#define PMK8550_ADC5_GEN3_AMUX_THM3_GPIO2(sid) ((sid) << 8 | ADC5_GEN3_AMUX3_THM)
+#define PMK8550_ADC5_GEN3_AMUX_THM4_GPIO3(sid) ((sid) << 8 | ADC5_GEN3_AMUX4_THM)
+#define PMK8550_ADC5_GEN3_AMUX_THM5_GPIO4(sid) ((sid) << 8 | ADC5_GEN3_AMUX5_THM)
+#define PMK8550_ADC5_GEN3_AMUX_THM6_GPIO5(sid) ((sid) << 8 | ADC5_GEN3_AMUX6_THM)
+#define PMK8550_ADC5_GEN3_AMUX1_GPIO6(sid) ((sid) << 8 | ADC5_GEN3_AMUX1_GPIO)
+
+/* 30k pull-up */
+#define PMK8550_ADC5_GEN3_AMUX_THM1_XO_THERM_30K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX1_THM_30K_PU)
+#define PMK8550_ADC5_GEN3_AMUX_THM2_GPIO1_30K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX2_THM_30K_PU)
+#define PMK8550_ADC5_GEN3_AMUX_THM3_GPIO2_30K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX3_THM_30K_PU)
+#define PMK8550_ADC5_GEN3_AMUX_THM4_GPIO3_30K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX4_THM_30K_PU)
+#define PMK8550_ADC5_GEN3_AMUX_THM5_GPIO4_30K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX5_THM_30K_PU)
+#define PMK8550_ADC5_GEN3_AMUX_THM6_GPIO5_30K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX6_THM_30K_PU)
+#define PMK8550_ADC5_GEN3_AMUX1_GPIO6_30K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX1_GPIO_30K_PU)
+
+/* 100k pull-up */
+#define PMK8550_ADC5_GEN3_AMUX_THM1_XO_THERM_100K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX1_THM_100K_PU)
+#define PMK8550_ADC5_GEN3_AMUX_THM2_GPIO1_100K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX2_THM_100K_PU)
+#define PMK8550_ADC5_GEN3_AMUX_THM3_GPIO2_100K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX3_THM_100K_PU)
+#define PMK8550_ADC5_GEN3_AMUX_THM4_GPIO3_100K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX4_THM_100K_PU)
+#define PMK8550_ADC5_GEN3_AMUX_THM5_GPIO4_100K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX5_THM_100K_PU)
+#define PMK8550_ADC5_GEN3_AMUX_THM6_GPIO5_100K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX6_THM_100K_PU)
+#define PMK8550_ADC5_GEN3_AMUX1_GPIO6_100K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX1_GPIO_100K_PU)
+
+/* 400k pull-up */
+#define PMK8550_ADC5_GEN3_AMUX_THM1_XO_THERM_400K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX1_THM_400K_PU)
+#define PMK8550_ADC5_GEN3_AMUX_THM2_GPIO1_400K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX2_THM_400K_PU)
+#define PMK8550_ADC5_GEN3_AMUX_THM3_GPIO2_400K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX3_THM_400K_PU)
+#define PMK8550_ADC5_GEN3_AMUX_THM4_GPIO3_400K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX4_THM_400K_PU)
+#define PMK8550_ADC5_GEN3_AMUX_THM5_GPIO4_400K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX5_THM_400K_PU)
+#define PMK8550_ADC5_GEN3_AMUX_THM6_GPIO5_400K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX6_THM_400K_PU)
+#define PMK8550_ADC5_GEN3_AMUX1_GPIO6_400K_PU(sid) ((sid) << 8 | ADC5_GEN3_AMUX1_GPIO_400K_PU)
+
+#endif /* _QCOM_PMK8550_ACD5_GEN3_H */
--
2.34.1
^ permalink raw reply related
* [PATCH RFC v3 0/6] arm64: dts: qcom: sm8[56]50: add PMIC5 Gen3 ADC channels
From: Neil Armstrong @ 2026-06-15 17:00 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Neil Armstrong
Now the bindings and driver was merged for the SPMI PMIC5 Gen3 ADC
found on the PMK8550 which allow reading ADC data on the PMK8550
and other PMICs on the system.
First, add the PMIC5 Gen3 macros to calculate the channel numbers which
is a combination of SPMI bus number and a constant for the sensor
type and configuration.
The macros definitions were taken out of [1] where it was initially
in the dt-bindings include directory but since those are not hardware
bindings but logical numbers, they can be moved to local includes
instead to make the DT source more readable.
[1] https://lore.kernel.org/all/20250826083657.4005727-4-jishnu.prakash@oss.qualcomm.com/
Finally add the SPMI ADC channels on the PMK8550 SPMI5 ADC3 for the
other PMICS on the system.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
Changes in v3:
- Added note about nodes ordering in commit message
- Rebased on next
- Link to v2: https://patch.msgid.link/20260504-topic-sm8x50-adc5-gen3-v2-0-5cc04d6ecda0@linaro.org
Changes in v2:
- Removed stray line from patch 2, added review tag
- Added missing header file
- Link to v1: https://patch.msgid.link/20260427-topic-sm8x50-adc5-gen3-v1-0-8a70f7b90a75@linaro.org
---
Neil Armstrong (6):
arm64: dts: qcom: add PMIC5 Gen3 macros for channel numbers
arm64: dts: qcom: pmk8550: add VADC node
arm64: dts: qcom: sm8550-qrd: add SPMI ADC channels and thermal nodes
arm64: dts: qcom: sm8550-hdk: add SPMI ADC channels and thermal nodes
arm64: dts: qcom: sm8650-qrd: add SPMI ADC channels and thermal nodes
arm64: dts: qcom: sm8650-hdk: add SPMI ADC channels and thermal nodes
arch/arm64/boot/dts/qcom/pmk8550.dtsi | 30 +++
arch/arm64/boot/dts/qcom/qcom,adc5-gen3-channels.h | 88 +++++++
arch/arm64/boot/dts/qcom/qcom,pm8550-adc5-gen3.h | 46 ++++
arch/arm64/boot/dts/qcom/qcom,pm8550b-adc5-gen3.h | 85 +++++++
arch/arm64/boot/dts/qcom/qcom,pm8550vx-adc5-gen3.h | 22 ++
arch/arm64/boot/dts/qcom/qcom,pmk8550-adc5-gen3.h | 52 ++++
arch/arm64/boot/dts/qcom/sm8550-hdk.dts | 279 +++++++++++++++++++++
arch/arm64/boot/dts/qcom/sm8550-qrd.dts | 279 +++++++++++++++++++++
arch/arm64/boot/dts/qcom/sm8650-hdk.dts | 279 +++++++++++++++++++++
arch/arm64/boot/dts/qcom/sm8650-qrd.dts | 279 +++++++++++++++++++++
10 files changed, 1439 insertions(+)
---
base-commit: 8d6dbbbe3ba62de0a63e962ee004afb848c8e3ac
change-id: 20260427-topic-sm8x50-adc5-gen3-edf94fbd335b
Best regards,
--
Neil Armstrong <neil.armstrong@linaro.org>
^ permalink raw reply
* [PATCH v2 6/6] arm64: dts: qcom: sm8650: Add missing CX power domain to GCC
From: Neil Armstrong @ 2026-06-15 16:57 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Vinod Koul, Abel Vesa,
Konrad Dybcio, Sai Prakash Ranjan, Brian Masney
Cc: linux-arm-msm, linux-clk, devicetree, linux-kernel,
Krzysztof Kozlowski, Neil Armstrong, Konrad Dybcio, Abel Vesa
In-Reply-To: <20260615-topic-sm8x50-tie-gcc-to-cx-v2-0-6b5752dd4747@linaro.org>
Unless CX is declared as the power-domain of GCC, votes (power and
performance) on the GDSCs it provides will not propagate to the CX,
which might result in under-voltage conditions.
Add the missing power-domains property to associate GCC with RPMHPD_CX.
Fixes: d2350377997f ("arm64: dts: qcom: add initial SM8650 dtsi")
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
arch/arm64/boot/dts/qcom/sm8650.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8650.dtsi b/arch/arm64/boot/dts/qcom/sm8650.dtsi
index 160ead25ecf7..8365e97436d6 100644
--- a/arch/arm64/boot/dts/qcom/sm8650.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8650.dtsi
@@ -1963,6 +1963,8 @@ gcc: clock-controller@100000 {
<&ufs_mem_phy 2>,
<&usb_dp_qmpphy QMP_USB43DP_USB3_PIPE_CLK>;
+ power-domains = <&rpmhpd RPMHPD_CX>;
+
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
--
2.34.1
^ permalink raw reply related
* [PATCH v2 5/6] arm64: dts: qcom: sm8550: Add missing CX power domain to GCC
From: Neil Armstrong @ 2026-06-15 16:57 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Vinod Koul, Abel Vesa,
Konrad Dybcio, Sai Prakash Ranjan, Brian Masney
Cc: linux-arm-msm, linux-clk, devicetree, linux-kernel,
Krzysztof Kozlowski, Neil Armstrong, Konrad Dybcio, Abel Vesa
In-Reply-To: <20260615-topic-sm8x50-tie-gcc-to-cx-v2-0-6b5752dd4747@linaro.org>
Unless CX is declared as the power-domain of GCC, votes (power and
performance) on the GDSCs it provides will not propagate to the CX,
which might result in under-voltage conditions.
Add the missing power-domains property to associate GCC with RPMHPD_CX.
Fixes: ffc50b2d3828 ("arm64: dts: qcom: Add base SM8550 dtsi")
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
arch/arm64/boot/dts/qcom/sm8550.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
index 396201905ef2..2cadcaae9e01 100644
--- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
@@ -1183,6 +1183,7 @@ soc: soc@0 {
gcc: clock-controller@100000 {
compatible = "qcom,sm8550-gcc";
reg = <0 0x00100000 0 0x1f4200>;
+ power-domains = <&rpmhpd RPMHPD_CX>;
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
--
2.34.1
^ permalink raw reply related
* [PATCH v2 3/6] dt-bindings: clock: qcom: sm8650-gcc: Add missing power-domains property
From: Neil Armstrong @ 2026-06-15 16:57 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Vinod Koul, Abel Vesa,
Konrad Dybcio, Sai Prakash Ranjan, Brian Masney
Cc: linux-arm-msm, linux-clk, devicetree, linux-kernel,
Krzysztof Kozlowski, Neil Armstrong
In-Reply-To: <20260615-topic-sm8x50-tie-gcc-to-cx-v2-0-6b5752dd4747@linaro.org>
In order for the GCC votes on the GDSCs it provides to be propagated
to CX, CX needs to be declared as power domain of the GCC.
Document the missing power-domains property to that purpose.
Fixes: b69d932154dc ("dt-bindings: clock: qcom: document the SM8650 General Clock Controller")
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
Documentation/devicetree/bindings/clock/qcom,sm8650-gcc.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8650-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8650-gcc.yaml
index c7143e2abc80..9c1504827cbf 100644
--- a/Documentation/devicetree/bindings/clock/qcom,sm8650-gcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,sm8650-gcc.yaml
@@ -32,9 +32,14 @@ properties:
- description: UFS Phy Tx symbol 0 clock source
- description: USB3 Phy wrapper pipe clock source
+ power-domains:
+ items:
+ - description: CX domain
+
required:
- compatible
- clocks
+ - power-domains
- '#power-domain-cells'
allOf:
@@ -58,6 +63,7 @@ examples:
<&ufs_mem_phy 1>,
<&ufs_mem_phy 2>,
<&usb_1_qmpphy>;
+ power-domains = <&rpmhpd RPMHPD_CX>;
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
--
2.34.1
^ permalink raw reply related
* [PATCH v2 4/6] arm64: dts: qcom: sm8450: Add missing CX power domain to GCC
From: Neil Armstrong @ 2026-06-15 16:57 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Vinod Koul, Abel Vesa,
Konrad Dybcio, Sai Prakash Ranjan, Brian Masney
Cc: linux-arm-msm, linux-clk, devicetree, linux-kernel,
Krzysztof Kozlowski, Neil Armstrong, Abel Vesa, Konrad Dybcio
In-Reply-To: <20260615-topic-sm8x50-tie-gcc-to-cx-v2-0-6b5752dd4747@linaro.org>
Unless CX is declared as the power-domain of GCC, votes (power and
performance) on the GDSCs it provides will not propagate to the CX,
which might result in under-voltage conditions.
Add the missing power-domains property to associate GCC with RPMHPD_CX.
Fixes: 5188049c9b36 ("arm64: dts: qcom: Add base SM8450 DTSI")
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
arch/arm64/boot/dts/qcom/sm8450.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8450.dtsi b/arch/arm64/boot/dts/qcom/sm8450.dtsi
index 56cb6e959e4e..2639790307d8 100644
--- a/arch/arm64/boot/dts/qcom/sm8450.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8450.dtsi
@@ -935,6 +935,7 @@ soc: soc@0 {
gcc: clock-controller@100000 {
compatible = "qcom,gcc-sm8450";
reg = <0x0 0x00100000 0x0 0x1f4200>;
+ power-domains = <&rpmhpd RPMHPD_CX>;
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
--
2.34.1
^ permalink raw reply related
* [PATCH v2 2/6] dt-bindings: clock: qcom: sm8550-gcc: Add missing power-domains property
From: Neil Armstrong @ 2026-06-15 16:57 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Vinod Koul, Abel Vesa,
Konrad Dybcio, Sai Prakash Ranjan, Brian Masney
Cc: linux-arm-msm, linux-clk, devicetree, linux-kernel,
Krzysztof Kozlowski, Neil Armstrong
In-Reply-To: <20260615-topic-sm8x50-tie-gcc-to-cx-v2-0-6b5752dd4747@linaro.org>
In order for the GCC votes on the GDSCs it provides to be propagated
to CX, CX needs to be declared as power domain of the GCC.
Document the missing power-domains property to that purpose.
Fixes: 47ba9c50bbeb ("dt-bindings: clock: Add SM8550 GCC clocks")
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
Documentation/devicetree/bindings/clock/qcom,sm8550-gcc.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8550-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8550-gcc.yaml
index c4e9b9bb63f5..19f06d27c7c1 100644
--- a/Documentation/devicetree/bindings/clock/qcom,sm8550-gcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,sm8550-gcc.yaml
@@ -31,9 +31,14 @@ properties:
- description: UFS Phy Tx symbol 0 clock source
- description: USB3 Phy wrapper pipe clock source
+ power-domains:
+ items:
+ - description: CX domain
+
required:
- compatible
- clocks
+ - power-domains
- '#power-domain-cells'
allOf:
@@ -55,6 +60,7 @@ examples:
<&ufs_mem_phy 1>,
<&ufs_mem_phy 2>,
<&usb_1_qmpphy>;
+ power-domains = <&rpmhpd RPMHPD_CX>;
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
--
2.34.1
^ permalink raw reply related
* [PATCH v2 1/6] dt-bindings: clock: qcom: gcc-sm8450: Add missing power-domains property
From: Neil Armstrong @ 2026-06-15 16:57 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Vinod Koul, Abel Vesa,
Konrad Dybcio, Sai Prakash Ranjan, Brian Masney
Cc: linux-arm-msm, linux-clk, devicetree, linux-kernel,
Krzysztof Kozlowski, Neil Armstrong
In-Reply-To: <20260615-topic-sm8x50-tie-gcc-to-cx-v2-0-6b5752dd4747@linaro.org>
In order for the GCC votes on the GDSCs it provides to be propagated
to CX, CX needs to be declared as power domain of the GCC.
Document the missing power-domains property to that purpose.
Fixes: 72a0ca203ca7 ("dt-bindings: clock: Add SM8450 GCC clock bindings")
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
Documentation/devicetree/bindings/clock/qcom,gcc-sm8450.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sm8450.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sm8450.yaml
index 3169ac05e1d8..7e3713cfd498 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-sm8450.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sm8450.yaml
@@ -47,10 +47,15 @@ properties:
- const: usb3_phy_wrapper_gcc_usb30_pipe_clk # Optional clock
minItems: 2
+ power-domains:
+ items:
+ - description: CX domain
+
required:
- compatible
- clocks
- clock-names
+ - power-domains
- '#power-domain-cells'
allOf:
@@ -66,6 +71,7 @@ examples:
reg = <0x00100000 0x001f4200>;
clocks = <&rpmhcc RPMH_CXO_CLK>, <&sleep_clk>;
clock-names = "bi_tcxo", "sleep_clk";
+ power-domains = <&rpmhpd RPMHPD_CX>;
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
--
2.34.1
^ permalink raw reply related
* [PATCH v2 0/6] arm64: dts: qcom: sm8[456]50: Add missing CX power domain to GCC
From: Neil Armstrong @ 2026-06-15 16:57 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Vinod Koul, Abel Vesa,
Konrad Dybcio, Sai Prakash Ranjan, Brian Masney
Cc: linux-arm-msm, linux-clk, devicetree, linux-kernel,
Krzysztof Kozlowski, Neil Armstrong, Abel Vesa, Konrad Dybcio
Recently, on Eliza & Milos, the CX has been tied up to the GCC,
but this is valid for most platforms including sm8[456]50.
So tie the CX power domain to the GCC as well, for the
same exact reasons as on Eliza & Milos.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
Changes in v2:
- Add missing power domains in example
- Pick review tags
- Link to v1: https://patch.msgid.link/20260424-topic-sm8x50-tie-gcc-to-cx-v1-0-4b6e09d532ce@linaro.org
---
Neil Armstrong (6):
dt-bindings: clock: qcom: gcc-sm8450: Add missing power-domains property
dt-bindings: clock: qcom: sm8550-gcc: Add missing power-domains property
dt-bindings: clock: qcom: sm8650-gcc: Add missing power-domains property
arm64: dts: qcom: sm8450: Add missing CX power domain to GCC
arm64: dts: qcom: sm8550: Add missing CX power domain to GCC
arm64: dts: qcom: sm8650: Add missing CX power domain to GCC
Documentation/devicetree/bindings/clock/qcom,gcc-sm8450.yaml | 6 ++++++
Documentation/devicetree/bindings/clock/qcom,sm8550-gcc.yaml | 6 ++++++
Documentation/devicetree/bindings/clock/qcom,sm8650-gcc.yaml | 6 ++++++
arch/arm64/boot/dts/qcom/sm8450.dtsi | 1 +
arch/arm64/boot/dts/qcom/sm8550.dtsi | 1 +
arch/arm64/boot/dts/qcom/sm8650.dtsi | 2 ++
6 files changed, 22 insertions(+)
---
base-commit: 8d6dbbbe3ba62de0a63e962ee004afb848c8e3ac
change-id: 20260424-topic-sm8x50-tie-gcc-to-cx-e756afa72bb8
Best regards,
--
Neil Armstrong <neil.armstrong@linaro.org>
^ permalink raw reply
* Re: [PATCH v3 2/3] arm64: dts: qcom: sm8650: add CPU cache size properties
From: sashiko-bot @ 2026-06-15 16:56 UTC (permalink / raw)
To: Neil Armstrong; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260615-topic-sm8650-upstream-cpu-props-v3-2-eeb6e9fa7581@linaro.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The L1 data cache size for the Cortex-A520 cores (cpu0 and cpu1) is incorrectly set to 64KB (`<65536>`) instead of 32KB (`<32768>`).
--
commit e69e8fc4f3866077641d02b02b7f11554b632507
Author: Neil Armstrong <neil.armstrong@linaro.org>
arm64: dts: qcom: sm8650: add CPU cache size properties
This commit adds L1, L2, and L3 cache size and line size properties to the
CPU and cache nodes in the sm8650 device tree. It splits the unified L1
cache properties into instruction and data cache sizes based on clidr_el1.
> diff --git a/arch/arm64/boot/dts/qcom/sm8650.dtsi b/arch/arm64/boot/dts/qcom/sm8650.dtsi
> index e8e43ddc3032a..090a4739ebc1d 100644
> --- a/arch/arm64/boot/dts/qcom/sm8650.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8650.dtsi
> @@ -75,6 +75,11 @@ cpu0: cpu@0 {
> compatible = "arm,cortex-a520";
> reg = <0 0>;
>
> + i-cache-size = <65536>;
> + i-cache-line-size = <64>;
> + d-cache-size = <65536>;
[Severity: Medium]
Is the d-cache-size for the Cortex-A520 correct here?
According to the ARM Cortex-A520 Technical Reference Manual, the L1 data cache
is strictly fixed at 32KB (<32768>), even though the instruction cache can be
configured to 32KB or 64KB.
This misrepresentation of the hardware topology could potentially lead to
suboptimal scheduling decisions or misguide userspace optimization algorithms.
> + d-cache-line-size = <64>;
> +
> clocks = <&cpufreq_hw 0>;
[ ... ]
> @@ -117,6 +126,11 @@ cpu1: cpu@100 {
> compatible = "arm,cortex-a520";
> reg = <0 0x100>;
>
> + i-cache-size = <65536>;
> + i-cache-line-size = <64>;
> + d-cache-size = <65536>;
[Severity: Medium]
Does this node also need to be updated to <32768> for the 32KB fixed L1 data
cache on the Cortex-A520, similar to cpu0?
> + d-cache-line-size = <64>;
> +
> clocks = <&cpufreq_hw 0>;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260615-topic-sm8650-upstream-cpu-props-v3-0-eeb6e9fa7581@linaro.org?part=2
^ permalink raw reply
* Re: [PATCH RFC 1/2] dt-bindings: pinctl: amlogic,pinctrl-a4: Add gpio irq property
From: Conor Dooley @ 2026-06-15 16:52 UTC (permalink / raw)
To: xianwei.zhao
Cc: Linus Walleij, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
linux-amlogic, linux-gpio, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260611-gpio-to-irq-v1-1-12201716f23f@amlogic.com>
[-- Attachment #1: Type: text/plain, Size: 85 bytes --]
Given Linus' comments on the cover letter,
pw-bot: changes-requested
Thanks,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v6 1/7] dt-bindings: mfd: mt6397: Add MT6392 PMIC
From: Conor Dooley @ 2026-06-15 16:50 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Fabien Parent, Val Packett, Dmitry Torokhov,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sen Chu,
Sean Wang, Macpaul Lin, Lee Jones, Matthias Brugger,
AngeloGioacchino Del Regno, Linus Walleij, Julien Massot,
Louis-Alexis Eyraud, Akari Tsuyukusa, Chen Zhong, linux-input,
devicetree, linux-kernel, linux-pm, linux-arm-kernel, linux-gpio
In-Reply-To: <20260612200717.361018-2-l.scorcia@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1612 bytes --]
On Fri, Jun 12, 2026 at 10:04:06PM +0200, Luca Leonardo Scorcia wrote:
> From: Fabien Parent <parent.f@gmail.com>
>
> Add the initial bindings for the MT6392 PMIC and its RTC device.
>
> Signed-off-by: Fabien Parent <parent.f@gmail.com>
> Signed-off-by: Val Packett <val@packett.cool>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
Sashiko complaint about missing regulators looks valid.
Is it?
Cheers,
Conor.
> ---
> .../devicetree/bindings/mfd/mediatek,mt6397.yaml | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml b/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
> index 3cbc0dc12c31..e39e81aa9924 100644
> --- a/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
> +++ b/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
> @@ -40,6 +40,10 @@ properties:
> - mediatek,mt6358
> - mediatek,mt6359
> - mediatek,mt6397
> + - items:
> + - enum:
> + - mediatek,mt6392
> + - const: mediatek,mt6323
> - items:
> - enum:
> - mediatek,mt6366
> @@ -72,6 +76,10 @@ properties:
> - mediatek,mt6331-rtc
> - mediatek,mt6358-rtc
> - mediatek,mt6397-rtc
> + - items:
> + - enum:
> + - mediatek,mt6392-rtc
> + - const: mediatek,mt6323-rtc
> - items:
> - enum:
> - mediatek,mt6359-rtc
> --
> 2.43.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [RFC PATCH v4 6/9] dt-bindings: npu: rockchip,rk3588-rknn-core: Add RK3568
From: Conor Dooley @ 2026-06-15 16:49 UTC (permalink / raw)
To: MidG971
Cc: tomeu, ogabbay, heiko, robh, krzk+dt, conor+dt, ulf.hansson,
dri-devel, linux-rockchip, devicetree, linux-arm-kernel, linux-pm,
iommu, linux-kernel, xxm, chaoyi.chen, finley.xiao, diederik,
jonas
In-Reply-To: <20260613070116.438906-7-midgy971@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH RFC 3/9] net: stmmac: qcom-ethqos: fix RGMII_ID mode to use DLL bypass
From: Andrew Lunn @ 2026-06-15 16:48 UTC (permalink / raw)
To: Mohd Ayaan Anwar
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Richard Cochran, Bjorn Andersson, Konrad Dybcio, Maxime Coquelin,
Alexandre Torgue, Russell King, linux-arm-msm, netdev, devicetree,
linux-kernel, linux-stm32, linux-arm-kernel
In-Reply-To: <ai93X/cNWHtEQsDt@oss.qualcomm.com>
On Mon, Jun 15, 2026 at 09:24:07AM +0530, Mohd Ayaan Anwar wrote:
> Hello Andrew,
> On Thu, Jun 11, 2026 at 10:54:37PM +0200, Andrew Lunn wrote:
> > On Fri, Jun 12, 2026 at 12:06:59AM +0530, Mohd Ayaan Anwar wrote:
> > > When "rgmii-id" is selected the PHY supplies both TX and RX delays, so
> > > the MAC must not add its own. The driver currently falls through to the
> > > generic DLL initialisation path which programs it to add a delay.
> > >
> > > Power down the DLL and set DDR bypass mode for RGMII_ID, then program
> > > the IO_MACRO via a new ethqos_rgmii_id_macro_init() helper. Also fix
> > > ethqos_set_clk_tx_rate() to not double the clock rate in bypass mode at
> > > 100M/10M, and remove RGMII_ID from the phase-shift suppression in
> > > ethqos_rgmii_macro_init() since RGMII_ID no longer reaches that path.
> >
> > I'm curious how this works at the moment? Do no boards make use of
> > RGMII ID? Are all current boards broken?
>
> Searching through the DTS, I found that we have two boards using "rgmii"
> (qcs404-evb-4000.dts and sa8155-adp.dts) and another board using
> "rgmii-txid" (sa8540p-ride.dts). No board which uses RGMII ID.
So this causes problems. We cannot break existing boards, yet it would
be good to fix the current broken behaviour.
> I don't think any of these boards have extra long wires which would add
> PCB level delay. They are against the netdev definitions for "rgmii" and
> "rgmii-txid".
>
> But the first two boards should still be working fine since the current
> driver programs the IO_MACRO to add the delay when operating in RGMII
> mode.
Which is wrong, given the current definition. No delays should be
added, by either the MAC or the PHY.
Please could you contact the Maintainers of these boards and find out
the real situation with the hardware.
It could be the best way forward is that you issue a warning when
"rgmii" is found and pass rgmii-id to the PHY. And you also change the
two boards to use rgmii-id. Lets think about the rgmii-txid case once
we better understand it.
Andrew
^ permalink raw reply
* [PATCH v3 3/3] arm64: dts: qcom: sm8650: fix soundwire ports properties
From: Neil Armstrong @ 2026-06-15 16:48 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Neil Armstrong,
Krzysztof Kozlowski
In-Reply-To: <20260615-topic-sm8650-upstream-cpu-props-v3-0-eeb6e9fa7581@linaro.org>
Since commit 9e53a66a2f2f ("soundwire: qcom: deprecate qcom,din/out-ports"),
the ports are checked against the actul hardware configuration, leading to:
qcom-soundwire 6ad0000.soundwire: din-ports (0) mismatch with controller (1)
qcom-soundwire 6d30000.soundwire: dout-ports (0) mismatch with controller (1)
Fix the ports count and properties of the corresponding soundwire
controllers.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
arch/arm64/boot/dts/qcom/sm8650.dtsi | 42 ++++++++++++++++++------------------
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8650.dtsi b/arch/arm64/boot/dts/qcom/sm8650.dtsi
index 090a4739ebc1..b1293fdb1481 100644
--- a/arch/arm64/boot/dts/qcom/sm8650.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8650.dtsi
@@ -4734,18 +4734,18 @@ swr1: soundwire@6ad0000 {
pinctrl-0 = <&rx_swr_active>;
pinctrl-names = "default";
- qcom,din-ports = <0>;
+ qcom,din-ports = <1>;
qcom,dout-ports = <11>;
- qcom,ports-sinterval = /bits/ 16 <0x03 0x1f 0x1f 0x07 0x03 0xff 0xff 0x31 0xff 0xff 0xff>;
- qcom,ports-offset1 = /bits/ 8 <0x00 0x00 0x0b 0x09 0x01 0xff 0xff 0x00 0xff 0xff 0xff>;
- qcom,ports-offset2 = /bits/ 8 <0x00 0x00 0x0b 0x00 0x00 0xff 0xff 0x00 0xff 0xff 0xff>;
- qcom,ports-hstart = /bits/ 8 <0xff 0x03 0xff 0xff 0xff 0xff 0xff 0x00 0xff 0xff 0xff>;
- qcom,ports-hstop = /bits/ 8 <0xff 0x06 0xff 0xff 0xff 0xff 0xff 0x0f 0xff 0xff 0xff>;
- qcom,ports-word-length = /bits/ 8 <0x01 0x07 0x04 0xff 0xff 0xff 0xff 0x18 0xff 0xff 0xff>;
- qcom,ports-block-pack-mode = /bits/ 8 <0xff 0x00 0x01 0xff 0xff 0xff 0xff 0x01 0xff 0xff 0xff>;
- qcom,ports-block-group-count = /bits/ 8 <0xff 0xff 0xff 0x01 0x03 0xff 0xff 0x00 0xff 0xff 0xff>;
- qcom,ports-lane-control = /bits/ 8 <0x01 0x00 0x00 0x00 0x00 0xff 0xff 0x01 0xff 0xff 0xff>;
+ qcom,ports-sinterval = /bits/ 16 <0x03 0x1f 0x1f 0x07 0x03 0xff 0xff 0x31 0xff 0xff 0xff 0xff>;
+ qcom,ports-offset1 = /bits/ 8 <0x00 0x00 0x0b 0x09 0x01 0xff 0xff 0x00 0xff 0xff 0xff 0xff>;
+ qcom,ports-offset2 = /bits/ 8 <0x00 0x00 0x0b 0x00 0x00 0xff 0xff 0x00 0xff 0xff 0xff 0xff>;
+ qcom,ports-hstart = /bits/ 8 <0xff 0x03 0xff 0xff 0xff 0xff 0xff 0x00 0xff 0xff 0xff 0xff>;
+ qcom,ports-hstop = /bits/ 8 <0xff 0x06 0xff 0xff 0xff 0xff 0xff 0x0f 0xff 0xff 0xff 0xff>;
+ qcom,ports-word-length = /bits/ 8 <0x01 0x07 0x04 0xff 0xff 0xff 0xff 0x18 0xff 0xff 0xff 0xff>;
+ qcom,ports-block-pack-mode = /bits/ 8 <0xff 0x00 0x01 0xff 0xff 0xff 0xff 0x01 0xff 0xff 0xff 0xff>;
+ qcom,ports-block-group-count = /bits/ 8 <0xff 0xff 0xff 0x01 0x03 0xff 0xff 0x00 0xff 0xff 0xff 0xff>;
+ qcom,ports-lane-control = /bits/ 8 <0x01 0x00 0x00 0x00 0x00 0xff 0xff 0x01 0xff 0xff 0xff 0xff>;
#address-cells = <2>;
#size-cells = <0>;
@@ -4831,17 +4831,17 @@ swr2: soundwire@6d30000 {
pinctrl-names = "default";
qcom,din-ports = <4>;
- qcom,dout-ports = <0>;
-
- qcom,ports-sinterval-low = /bits/ 8 <0x01 0x01 0x03 0x03>;
- qcom,ports-offset1 = /bits/ 8 <0x00 0x00 0x01 0x01>;
- qcom,ports-offset2 = /bits/ 8 <0x00 0x00 0x00 0x00>;
- qcom,ports-hstart = /bits/ 8 <0xff 0xff 0xff 0xff>;
- qcom,ports-hstop = /bits/ 8 <0xff 0xff 0xff 0xff>;
- qcom,ports-word-length = /bits/ 8 <0xff 0xff 0xff 0xff>;
- qcom,ports-block-pack-mode = /bits/ 8 <0xff 0xff 0xff 0xff>;
- qcom,ports-block-group-count = /bits/ 8 <0xff 0xff 0xff 0xff>;
- qcom,ports-lane-control = /bits/ 8 <0x01 0x02 0x00 0x00>;
+ qcom,dout-ports = <1>;
+
+ qcom,ports-sinterval-low = /bits/ 8 <0x00 0x01 0x01 0x03 0x03>;
+ qcom,ports-offset1 = /bits/ 8 <0x00 0x00 0x00 0x01 0x01>;
+ qcom,ports-offset2 = /bits/ 8 <0x00 0x00 0x00 0x00 0x00>;
+ qcom,ports-hstart = /bits/ 8 <0xff 0xff 0xff 0xff 0xff>;
+ qcom,ports-hstop = /bits/ 8 <0xff 0xff 0xff 0xff 0xff>;
+ qcom,ports-word-length = /bits/ 8 <0xff 0xff 0xff 0xff 0xff>;
+ qcom,ports-block-pack-mode = /bits/ 8 <0xff 0xff 0xff 0xff 0xff>;
+ qcom,ports-block-group-count = /bits/ 8 <0xff 0xff 0xff 0xff 0xff>;
+ qcom,ports-lane-control = /bits/ 8 <0xff 0x01 0x02 0x00 0x00>;
#address-cells = <2>;
#size-cells = <0>;
--
2.34.1
^ permalink raw reply related
* [PATCH v3 2/3] arm64: dts: qcom: sm8650: add CPU cache size properties
From: Neil Armstrong @ 2026-06-15 16:48 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Neil Armstrong,
Konrad Dybcio
In-Reply-To: <20260615-topic-sm8650-upstream-cpu-props-v3-0-eeb6e9fa7581@linaro.org>
Add the L1 cache size and its line size (cache-size and
cache-line-size) with the corresponding L1-I cache and L1-D cache.
L1 cache is unified, but clidr_el1 register (get_cache_type) tells that
L1 cache is separated (CACHE_TYPE_SEPARATE), add i-cache-line-size and
d-cache-line-size and cache-line-size of L3 cache is specified.
All cache line sizes were confirmed by checking ccsidr_el1.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
arch/arm64/boot/dts/qcom/sm8650.dtsi | 56 ++++++++++++++++++++++++++++++++++++
1 file changed, 56 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8650.dtsi b/arch/arm64/boot/dts/qcom/sm8650.dtsi
index e8e43ddc3032..090a4739ebc1 100644
--- a/arch/arm64/boot/dts/qcom/sm8650.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8650.dtsi
@@ -75,6 +75,11 @@ cpu0: cpu@0 {
compatible = "arm,cortex-a520";
reg = <0 0>;
+ i-cache-size = <65536>;
+ i-cache-line-size = <64>;
+ d-cache-size = <65536>;
+ d-cache-line-size = <64>;
+
clocks = <&cpufreq_hw 0>;
power-domains = <&cpu_pd0>;
@@ -103,11 +108,15 @@ l2_0: l2-cache {
cache-level = <2>;
cache-unified;
next-level-cache = <&l3_0>;
+ cache-size = <524288>;
+ cache-line-size = <64>;
l3_0: l3-cache {
compatible = "cache";
cache-level = <3>;
cache-unified;
+ cache-size = <12582912>;
+ cache-line-size = <64>;
};
};
};
@@ -117,6 +126,11 @@ cpu1: cpu@100 {
compatible = "arm,cortex-a520";
reg = <0 0x100>;
+ i-cache-size = <65536>;
+ i-cache-line-size = <64>;
+ d-cache-size = <65536>;
+ d-cache-line-size = <64>;
+
clocks = <&cpufreq_hw 0>;
power-domains = <&cpu_pd1>;
@@ -146,6 +160,11 @@ cpu2: cpu@200 {
compatible = "arm,cortex-a720";
reg = <0 0x200>;
+ i-cache-size = <65536>;
+ i-cache-line-size = <64>;
+ d-cache-size = <65536>;
+ d-cache-line-size = <64>;
+
clocks = <&cpufreq_hw 3>;
power-domains = <&cpu_pd2>;
@@ -174,6 +193,8 @@ l2_200: l2-cache {
cache-level = <2>;
cache-unified;
next-level-cache = <&l3_0>;
+ cache-size = <524288>;
+ cache-line-size = <64>;
};
};
@@ -182,6 +203,11 @@ cpu3: cpu@300 {
compatible = "arm,cortex-a720";
reg = <0 0x300>;
+ i-cache-size = <65536>;
+ i-cache-line-size = <64>;
+ d-cache-size = <65536>;
+ d-cache-line-size = <64>;
+
clocks = <&cpufreq_hw 3>;
power-domains = <&cpu_pd3>;
@@ -210,6 +236,8 @@ l2_300: l2-cache {
cache-level = <2>;
cache-unified;
next-level-cache = <&l3_0>;
+ cache-size = <524288>;
+ cache-line-size = <64>;
};
};
@@ -218,6 +246,11 @@ cpu4: cpu@400 {
compatible = "arm,cortex-a720";
reg = <0 0x400>;
+ i-cache-size = <65536>;
+ i-cache-line-size = <64>;
+ d-cache-size = <65536>;
+ d-cache-line-size = <64>;
+
clocks = <&cpufreq_hw 3>;
power-domains = <&cpu_pd4>;
@@ -246,6 +279,8 @@ l2_400: l2-cache {
cache-level = <2>;
cache-unified;
next-level-cache = <&l3_0>;
+ cache-size = <524288>;
+ cache-line-size = <64>;
};
};
@@ -254,6 +289,11 @@ cpu5: cpu@500 {
compatible = "arm,cortex-a720";
reg = <0 0x500>;
+ i-cache-size = <65536>;
+ i-cache-line-size = <64>;
+ d-cache-size = <65536>;
+ d-cache-line-size = <64>;
+
clocks = <&cpufreq_hw 1>;
power-domains = <&cpu_pd5>;
@@ -282,6 +322,8 @@ l2_500: l2-cache {
cache-level = <2>;
cache-unified;
next-level-cache = <&l3_0>;
+ cache-size = <524288>;
+ cache-line-size = <64>;
};
};
@@ -290,6 +332,11 @@ cpu6: cpu@600 {
compatible = "arm,cortex-a720";
reg = <0 0x600>;
+ i-cache-size = <65536>;
+ i-cache-line-size = <64>;
+ d-cache-size = <65536>;
+ d-cache-line-size = <64>;
+
clocks = <&cpufreq_hw 1>;
power-domains = <&cpu_pd6>;
@@ -318,6 +365,8 @@ l2_600: l2-cache {
cache-level = <2>;
cache-unified;
next-level-cache = <&l3_0>;
+ cache-size = <524288>;
+ cache-line-size = <64>;
};
};
@@ -326,6 +375,11 @@ cpu7: cpu@700 {
compatible = "arm,cortex-x4";
reg = <0 0x700>;
+ i-cache-size = <65536>;
+ i-cache-line-size = <64>;
+ d-cache-size = <65536>;
+ d-cache-line-size = <64>;
+
clocks = <&cpufreq_hw 2>;
power-domains = <&cpu_pd7>;
@@ -354,6 +408,8 @@ l2_700: l2-cache {
cache-level = <2>;
cache-unified;
next-level-cache = <&l3_0>;
+ cache-size = <2097152>;
+ cache-line-size = <64>;
};
};
--
2.34.1
^ permalink raw reply related
* [PATCH v3 1/3] arm64: dts: qcom: sm8650: update the cpus capacity-dmips-mhz
From: Neil Armstrong @ 2026-06-15 16:48 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Neil Armstrong,
Konrad Dybcio
In-Reply-To: <20260615-topic-sm8650-upstream-cpu-props-v3-0-eeb6e9fa7581@linaro.org>
After some more advanced benchmarks with Integer, Floaring Point,
Encryption, Compression, NEON, ... on the A520, A720 and X4 cpus,
the median gain with the same frequency range is:
- 281% of A720 over A520
- 126% of X4 over A720
When adjusted with the frequency delta, we get better values
describing the difference in capacity, showing the weakness of
the A520 designed for very small tasks while the A720 and X4
are much more powerful.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
arch/arm64/boot/dts/qcom/sm8650.dtsi | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8650.dtsi b/arch/arm64/boot/dts/qcom/sm8650.dtsi
index 160ead25ecf7..e8e43ddc3032 100644
--- a/arch/arm64/boot/dts/qcom/sm8650.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8650.dtsi
@@ -153,7 +153,7 @@ cpu2: cpu@200 {
enable-method = "psci";
next-level-cache = <&l2_200>;
- capacity-dmips-mhz = <1792>;
+ capacity-dmips-mhz = <2909>;
dynamic-power-coefficient = <238>;
qcom,freq-domain = <&cpufreq_hw 3>;
@@ -189,7 +189,7 @@ cpu3: cpu@300 {
enable-method = "psci";
next-level-cache = <&l2_300>;
- capacity-dmips-mhz = <1792>;
+ capacity-dmips-mhz = <2909>;
dynamic-power-coefficient = <238>;
qcom,freq-domain = <&cpufreq_hw 3>;
@@ -225,7 +225,7 @@ cpu4: cpu@400 {
enable-method = "psci";
next-level-cache = <&l2_400>;
- capacity-dmips-mhz = <1792>;
+ capacity-dmips-mhz = <2909>;
dynamic-power-coefficient = <238>;
qcom,freq-domain = <&cpufreq_hw 3>;
@@ -261,7 +261,7 @@ cpu5: cpu@500 {
enable-method = "psci";
next-level-cache = <&l2_500>;
- capacity-dmips-mhz = <1792>;
+ capacity-dmips-mhz = <2909>;
dynamic-power-coefficient = <238>;
qcom,freq-domain = <&cpufreq_hw 1>;
@@ -297,7 +297,7 @@ cpu6: cpu@600 {
enable-method = "psci";
next-level-cache = <&l2_600>;
- capacity-dmips-mhz = <1792>;
+ capacity-dmips-mhz = <2909>;
dynamic-power-coefficient = <238>;
qcom,freq-domain = <&cpufreq_hw 1>;
@@ -333,7 +333,7 @@ cpu7: cpu@700 {
enable-method = "psci";
next-level-cache = <&l2_700>;
- capacity-dmips-mhz = <1894>;
+ capacity-dmips-mhz = <3591>;
dynamic-power-coefficient = <588>;
qcom,freq-domain = <&cpufreq_hw 2>;
--
2.34.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox