* Re: [PATCH net-next v5 14/15] dt-bindings: net: add onsemi's S2500
From: sashiko-bot @ 2026-06-15 17:01 UTC (permalink / raw)
To: Selvamani Rajagopal via B4 Relay; +Cc: conor+dt, devicetree, robh
In-Reply-To: <20260614-s2500-mac-phy-support-v5-14-89874b72f725@onsemi.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The device tree binding example incorrectly configures a level-triggered hardware interrupt as edge-triggered (IRQ_TYPE_EDGE_FALLING) instead of level-low (IRQ_TYPE_LEVEL_LOW) to document a software work-around rather than the hardware specification.
--
commit ec7eac5028b65bdc87468f9d30d6acc2c8cd7494
Author: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>
dt-bindings: net: add onsemi's S2500
This commit adds a new device tree binding for the onsemi S2500 10BASE-T1S
MACPHY Ethernet Controller. It documents the required properties for the
SPI-connected device and provides an example configuration.
> diff --git a/Documentation/devicetree/bindings/net/onnn,s2500.yaml b/Documentation/devicetree/bindings/net/onnn,s2500.yaml
> new file mode 100644
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/onnn,s2500.yaml
[ ... ]
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/irq.h>
> + spi {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ethernet@0 {
> + compatible = "onnn,s2500";
> + reg = <0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <ð0_pins>;
> + interrupt-parent = <&gpio>;
> + interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
[Severity: Medium]
The commit message mentions the OPEN Alliance specification requires a
level-low interrupt, but the example configures an edge-triggered falling
interrupt to work around a Linux software framework bug.
Should the device tree binding example accurately describe the physical
hardware (IRQ_TYPE_LEVEL_LOW) rather than documenting an OS-specific
software workaround?
Treating a level-sensitive interrupt as edge-sensitive could lead to
missed interrupts and stall the MAC-PHY hardware state machine if the
interrupt line is held low due to multiple pending events. Is it possible
to reflect the correct hardware state in the binding, while handling
the temporary software workaround internally within the driver?
> + spi-max-frequency = <15000000>;
> + };
> + };
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260614-s2500-mac-phy-support-v5-0-89874b72f725@onsemi.com?part=14
^ permalink raw reply
* Re: [PATCH net-next v5 13/15] onsemi: s2500: Added selftest support to onsemi's S2500 driver
From: sashiko-bot @ 2026-06-15 17:01 UTC (permalink / raw)
To: Selvamani Rajagopal via B4 Relay; +Cc: devicetree, conor+dt, robh
In-Reply-To: <20260614-s2500-mac-phy-support-v5-13-89874b72f725@onsemi.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Returning 0 from `get_sset_count` for `ETH_SS_TEST` triggers a `WARN_ON` in the ethtool core when `CONFIG_NET_SELFTESTS` is disabled.
--
commit 8adb07a1816e950bf0dedebd55b13b3a9497928e
Author: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>
onsemi: s2500: Added selftest support to onsemi's S2500 driver
This commit introduces ethtool selftest support to the onsemi S2500 MAC-PHY
driver. It exposes selftests by handling the ETH_SS_TEST stringset and
registering the self_test callback in the ethtool operations.
> diff --git a/drivers/net/ethernet/onsemi/s2500/s2500_ethtool.c b/drivers/net/ethernet/onsemi/s2500/s2500_ethtool.c
> index 85bd8ea50dd8c..334fac71ddea2 100644
> --- a/drivers/net/ethernet/onsemi/s2500/s2500_ethtool.c
> +++ b/drivers/net/ethernet/onsemi/s2500/s2500_ethtool.c
[ ... ]
> @@ -229,6 +230,8 @@ static int s2500_get_sset_count(struct net_device *ndev, int sset)
> switch (sset) {
> case ETH_SS_STATS:
> return S2500_MAC_STATS_LEN;
> + case ETH_SS_TEST:
> + return net_selftest_get_count();
[Severity: Medium]
When CONFIG_NET_SELFTESTS is disabled, the dummy implementation of
net_selftest_get_count() defined in include/net/selftests.h returns 0.
Because the driver unconditionally registers the .self_test callback below
in s2500_ethtool_ops:
const struct ethtool_ops s2500_ethtool_ops = {
...
.self_test = net_selftest,
};
Will returning 0 from s2500_get_sset_count() trigger a WARN_ON(test_len == 0)
in the ethtool core ioctl path when a user runs "ethtool -t"?
Could this check for a 0 test count and return -EOPNOTSUPP instead to avoid
the warning?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260614-s2500-mac-phy-support-v5-0-89874b72f725@onsemi.com?part=13
^ permalink raw reply
* Re: [PATCH net-next v5 12/15] onsemi: s2500: Add driver support for TS2500 MAC-PHY
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-12-89874b72f725@onsemi.com>
Thank you for your contribution! Sashiko AI review found 12 potential issue(s) to consider:
- [High] Premature exit of the polling kthread leads to a Use-After-Free during driver teardown or RX mode updates.
- [High] Lockless traversal of the multicast address list in the background thread causes data races and potential Use-After-Free.
- [High] PTP adjtime blocks for up to 60 seconds and computes frequency offset incorrectly.
- [High] Failure in s2500_open() leaks the background kthread and leaves the PHY running.
- [High] Failure paths in s2500_probe() do not clean up resources allocated by oa_tc6_init().
- [High] Concurrent Read-Modify-Write of the MAC_CTRL register leads to lost updates.
- [High] The s2500_thread_fun kthread contains a lost wakeup window for kthread_stop() causing 5 second interface teardown hang.
- [Medium] Standard netdev statistics are duplicated in driver-private ethtool -S strings.
- [Medium] The multicast hardware filter is incorrectly left disabled when specific MAC addresses are configured.
- [Medium] IFF_UNICAST_FLT is set but secondary unicast MAC filtering is not implemented.
- [Medium] The initialization function silently ignores failures when configuring the device's MAC address filter.
- [Medium] Incorrect MAC address filter register write ordering for multicast addresses.
--
commit 460baa0800374b033a33a01995e62355074e779a
Author: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>
onsemi: s2500: Add driver support for TS2500 MAC-PHY
This commit introduces a new ethernet driver for the onsemi S2500, an 802.3 cg
compliant transceiver with integrated MAC-PHY. It hooks into the Open Alliance
TC6 framework and implements ethtool stats, hardware timestamping, and PTP.
> --- /dev/null
> +++ b/drivers/net/ethernet/onsemi/s2500/s2500_ethtool.c
[ ... ]
> +static const char s2500_mac_stat_strings[][ETH_GSTRING_LEN] = {
> + "tx_bytes",
> + "tx_frames",
> + "tx_broadcast_frames",
> + "tx_multicast_frames",
[Severity: Medium]
Is it necessary to duplicate standard network statistics like tx_bytes and
tx_frames here?
Standard hardware counters should typically be exposed through ndo_get_stats64
(struct rtnl_link_stats64) rather than driver-private ethtool -S strings.
[ ... ]
> --- /dev/null
> +++ b/drivers/net/ethernet/onsemi/s2500/s2500_main.c
[ ... ]
> +static int s2500_mac_ctrl_modify_bits(struct s2500_info *priv,
> + u32 in_bits, bool clr)
> +{
> + u32 reg = S2500_REG_MAC_CTRL;
> + u32 rval = 0;
> + int ret;
> +
> + ret = oa_tc6_read_register_mms(priv->tc6, reg,
> + OA_TC6_PHY_C45_MAC_MMS1, &rval);
> + if (!ret) {
> + u32 wval = 0;
> +
> + if (clr)
> + wval = rval & ~in_bits;
> + else
> + wval = rval | in_bits;
> + if (rval != wval)
> + ret = oa_tc6_write_register_mms(priv->tc6, reg,
> + OA_TC6_PHY_C45_MAC_MMS1, wval);
[Severity: High]
Is this read-modify-write cycle safe from concurrent execution?
This function appears to be called from the asynchronous background thread
(s2500_rx_mode_update) as well as the networking stack callbacks (e.g.,
s2500_shutdown in the ndo_stop path). Without locking, a TOCTOU race could
cause one path's modification to overwrite the other's.
[ ... ]
> +static int s2500_init(struct s2500_info *priv)
> +{
[ ... ]
> + /* Program the source MAC address into the device */
> + ret = s2500_set_mac_filter(priv->ndev, priv->ndev->dev_addr);
> +
> + val = S2500_MAC_CTRL_ADRF_BIT | S2500_MAC_CTRL_FCSA_BIT;
> +
> + return s2500_mac_ctrl_modify_bits(priv, val, false);
[Severity: Medium]
Does this intentionally discard the return code from s2500_set_mac_filter()?
If setting the MAC address filter fails, the error in 'ret' is immediately
overwritten. This could cause the driver to silently proceed with a
misconfigured MAC address.
[ ... ]
> +static int s2500_set_multicast_mode(struct s2500_info *priv,
> + unsigned int rx_flags)
> +{
[ ... ]
> + } else {
> + struct netdev_hw_addr *ha;
> + u32 addrh, addrl;
> +
> + /* Disable multicast filter */
> + ret = s2500_mac_ctrl_modify_bits(priv,
> + S2500_MAC_CTRL_MCSF_BIT,
> + true);
> + if (ret)
> + return ret;
> +
> + /* Disable filters */
[Severity: Medium]
Should the multicast filter be re-enabled after writing the specific addresses
to the hardware slots?
The code intentionally disables the global filter (S2500_MAC_CTRL_MCSF_BIT) at
the beginning of this block, but it does not invoke modify_bits(..., false) at
the end, leaving the hardware in all-multicast mode.
[ ... ]
> + i = 1;
> + netdev_for_each_mc_addr(ha, priv->ndev) {
[Severity: High]
Can this lockless iteration race with userspace modifications?
Since this is executed in the background kthread asynchronously, traversing the
multicast list without holding the netif_addr_lock_bh(ndev) lock might
cause list corruption or a use-after-free if dev_mc_add or dev_mc_del runs
concurrently.
[ ... ]
> + ret = oa_tc6_write_register_mms(priv->tc6,
> + S2500_REG_MAC_ADDRFILTH(i),
> + OA_TC6_PHY_C45_MAC_MMS1, addrh);
> + if (ret)
> + return ret;
> +
> + ret = oa_tc6_write_register_mms(priv->tc6,
> + S2500_REG_MAC_ADDRFILTL(i),
> + OA_TC6_PHY_C45_MAC_MMS1, addrl);
[Severity: Medium]
Is this write order correct?
This writes S2500_REG_MAC_ADDRFILTH(i) (which contains the
S2500_MAC_ADDRFILT_EN_BIT enable flag) before writing the
S2500_REG_MAC_ADDRFILTL(i) payload. Writing the enable bit before the data
payload could cause the hardware to match against a partially-updated,
stale MAC address.
[ ... ]
> +static int s2500_thread_fun(void *data)
> +{
[ ... ]
> + do {
> + if (update_rx_mode) {
> + ret = s2500_rx_mode_update(priv);
> + if (unlikely(ret)) {
> + dev_err(&priv->spi->dev, "Failed to set new RX mode");
> + break;
> + }
> + }
[Severity: High]
If s2500_rx_mode_update() fails, this break statement drops out of the loop
causing the kthread to terminate and the kernel to free its task_struct.
However, the driver does not set priv->thread to NULL. When the device is
stopped, won't kthread_stop() blindly dereference the freed task_struct
leading to a use-after-free?
[ ... ]
> + spin_lock_irqsave(&priv->lock, flags);
> + __set_current_state(TASK_INTERRUPTIBLE);
> +
> + update_rx_mode = priv->rx_flags_upd;
> + ret = update_rx_mode;
> +
> + spin_unlock_irqrestore(&priv->lock, flags);
> +
> + if (!ret)
> + tout = schedule_timeout(tout);
> + else
> + set_current_state(TASK_RUNNING);
> + } while (!kthread_should_stop());
> + return 0;
> +}
[Severity: High]
Could kthread_stop() trigger a lost wakeup here?
If kthread_stop() runs after the loop condition is evaluated but before
__set_current_state(), the thread's TASK_RUNNING state will be immediately
overwritten with TASK_INTERRUPTIBLE. The thread would then sleep in
schedule_timeout() for up to 5 seconds, ignoring the stop request.
[ ... ]
> +static int s2500_open(struct net_device *ndev)
> +{
[ ... ]
> + if (IS_ERR(priv->thread)) {
> + ret = PTR_ERR(priv->thread);
> + } else {
> + val = S2500_MAC_CTRL_TXEN_BIT | S2500_MAC_CTRL_RXEN_BIT;
> + ret = s2500_mac_ctrl_modify_bits(priv, val, false);
> +
> + netif_start_queue(priv->ndev);
> + }
> + return ret;
> +}
[Severity: High]
If s2500_mac_ctrl_modify_bits() fails here, the function returns an error
without stopping the kthread or the PHY. Since ndo_stop is not invoked
if ndo_open fails, won't this leak the kthread and leave the PHY running?
[ ... ]
> +static int s2500_stop(struct net_device *ndev)
> +{
[ ... ]
> + s2500_shutdown(priv);
> +
> + kthread_stop(priv->thread);
> + priv->thread = NULL;
> +
> + return 0;
> +}
[ ... ]
> +static int s2500_probe(struct spi_device *spi)
> +{
[ ... ]
> + ndev->priv_flags |= IFF_UNICAST_FLT;
[Severity: Medium]
The driver advertises IFF_UNICAST_FLT, but s2500_set_rx_mode() does not
appear to process ndev->uc (the unicast address list).
Since this flag is set, the kernel won't automatically fall back to promiscuous
mode when secondary unicast addresses are assigned, which may cause traffic for
those addresses to be dropped.
[ ... ]
> + ret = s2500_init(priv);
> + if (unlikely(ret)) {
> + dev_err(&spi->dev, "failed to s2500_init the device");
> + goto err_reg_read;
> + }
[ ... ]
> + ret = register_netdev(ndev);
> + if (ret) {
> + dev_err(&spi->dev, "failed to register the S2500 device\n");
> + ret = -ENODEV;
> +
> + goto err_reg_read;
> + }
> + return 0;
> +
> +err_reg_read:
> + dev_err(&spi->dev, "could not initialize macphy");
> + return ret;
> +}
[Severity: High]
If s2500_init(), s2500_ptp_register(), or register_netdev() fail, this jumps
to err_reg_read but does not clean up the TC6 framework.
Should this call oa_tc6_exit() and oa_tc6_ptp_unregister() to prevent memory
leaks and dangling PTP registrations?
[ ... ]
> --- /dev/null
> +++ b/drivers/net/ethernet/onsemi/s2500/s2500_ptp.c
[ ... ]
> +static int s2500_ptp_adjtime(struct ptp_clock_info *ptp, s64 delta)
> +{
[ ... ]
> + /* Compute scaled_ppm (Qx.16). scaled_ppm = ppm * 2^16
> + * ppm = (delta_seconds / period_seconds) * 1e6
> + * => scaled_ppm = delta_ns * 65536 / (period_ms * 1000)
> + */
> + num = remaining * 65536LL;
> + den = (s64)period_ms * 1000LL;
> +
> + /* Integer division rounds toward zero; keep sign in numerator */
> + scaled_ppm = div_s64(num, den);
> +
> + /* Apply frequency adjustment */
> + ret = ptp->adjfine(ptp, (long)scaled_ppm);
> + if (ret)
> + break;
> +
> + /* Sleep for the slew period (interruptible). If interrupted, clear
> + * the adjfine and return with -EINTR.
> + */
> + if (msleep_interruptible(period_ms)) {
[Severity: High]
Does this extra multiplication by 1000 result in an incorrect scaled_ppm?
Dividing the denominator by 1000 again will make the frequency adjustment
1000 times too small.
Additionally, the software slewing loop calls msleep_interruptible() for
up to 60 seconds (or 180s total) while holding the ptp_adj_lock. Will this
block the calling userspace servo loop (e.g., ptp4l via clock_adjtime)
in the kernel for excessive periods?
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260614-s2500-mac-phy-support-v5-0-89874b72f725@onsemi.com?part=12
^ permalink raw reply
* Re: [PATCH net-next v5 11/15] net: phy: ncn26000: Support for loopback
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-11-89874b72f725@onsemi.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The newly added loopback support is broken because the driver's config_aneg implementation blindly overwrites the MII_BMCR register, clearing the loopback bit.
--
commit 5a40363adea3a7ee8be993f04a56cb1d3004a24b
Author: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>
net: phy: ncn26000: Support for loopback
Adding loopback support for S2500 internal PHY to help running
loopback test through ethtool.
> diff --git a/drivers/net/phy/ncn26000.c b/drivers/net/phy/ncn26000.c
> index c3a34b2c524d5..afafa81dc22b8 100644
> --- a/drivers/net/phy/ncn26000.c
> +++ b/drivers/net/phy/ncn26000.c
> @@ -178,6 +178,7 @@ static struct phy_driver ncn26000_driver[] = {
> .config_aneg = ncn26000_config_aneg,
> .read_status = ncn26000_read_status,
> .handle_interrupt = ncn26000_handle_interrupt,
> + .set_loopback = genphy_loopback_fixed_speed,
[Severity: High]
Does ncn26000_config_aneg() inadvertently clear the loopback bit that is
configured here?
Looking at the driver's implementation of ncn26000_config_aneg():
drivers/net/phy/ncn26000.c:ncn26000_config_aneg() {
...
// bring up the link
return phy_write(phydev, MII_BMCR, NCN26000_BCMR_LINK_CTRL_BIT);
}
When the interface is brought up, the PHY state machine is asynchronously
scheduled and can transition from PHY_UP by unconditionally calling
ncn26000_config_aneg().
If the user activates the loopback selftest simultaneously, the loopback
bit is set via genphy_loopback_fixed_speed(). However, because
ncn26000_config_aneg() blindly overwrites the MII_BMCR register using
phy_write(), it silently clears the BMCR_LOOPBACK bit.
This causes the hardware loopback to be disabled while the software state
indicates it is active, which can lead to selftest failures and potentially
leak test packets onto the network wire.
Could ncn26000_config_aneg() use phy_modify() instead of phy_write() to
preserve orthogonal bits like BMCR_LOOPBACK?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260614-s2500-mac-phy-support-v5-0-89874b72f725@onsemi.com?part=11
^ permalink raw reply
* Re: [PATCH net-next v5 08/15] net: ethernet: oa_tc6: read, write interface with MMS option
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-8-89874b72f725@onsemi.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Incorrect teardown order in lan865x_remove allows a race condition leading to a use-after-free on the private netdev structure.
--
commit 6ac71b4b2fa47efef74336ba2f488f113f5cdd43
Author: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>
net: ethernet: oa_tc6: read, write interface with MMS option
This commit introduces new read/write APIs to the oa_tc6 framework that
accept the Memory Map Selector (MMS) as a parameter. This allows vendors
to use any memory map selector without having to manually encode the
address prior to calling the API. The lan865x driver is updated to use
these new functions.
> diff --git a/drivers/net/ethernet/microchip/lan865x/lan865x.c b/drivers/net/ethernet/microchip/lan865x/lan865x.c
> index 0277d9737369a..3b555ee698041 100644
> --- a/drivers/net/ethernet/microchip/lan865x/lan865x.c
> +++ b/drivers/net/ethernet/microchip/lan865x/lan865x.c
[ ... ]
> @@ -235,7 +240,8 @@ static void lan865x_multicast_work_handler(struct work_struct *work)
> if (lan865x_clear_all_multicast_addr(priv))
> return;
> }
> - ret = oa_tc6_write_register(priv->tc6, LAN865X_REG_MAC_NET_CFG, regval);
> + ret = oa_tc6_write_register_mms(priv->tc6, LAN865X_REG_MAC_NET_CFG,
> + OA_TC6_PHY_C45_MAC_MMS1, regval);
> if (ret)
> netdev_err(priv->netdev, "Failed to enable promiscuous/multicast/normal mode: %d\n",
> ret);
[Severity: High]
This isn't a bug introduced by this patch, but while reviewing the changes
around the multicast work handler, I noticed an issue with the teardown order
in lan865x_remove().
Can a use-after-free occur here?
drivers/net/ethernet/microchip/lan865x/lan865x.c:lan865x_remove() {
...
cancel_work_sync(&priv->multicast_work);
unregister_netdev(priv->netdev);
oa_tc6_exit(priv->tc6);
free_netdev(priv->netdev);
}
Since cancel_work_sync() is called before unregister_netdev(), couldn't
user-space trigger a configuration change (like toggling promiscuity via
ip link) during this window?
This would call ndo_set_rx_mode and reschedule the multicast work.
When free_netdev() subsequently frees the priv structure, the queued work
would remain on the workqueue, potentially accessing the freed priv pointer
when it later executes.
Should unregister_netdev() be called before cancel_work_sync() so the device
is no longer visible to user-space, preventing further ndo_set_rx_mode calls?
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260614-s2500-mac-phy-support-v5-0-89874b72f725@onsemi.com?part=8
^ permalink raw reply
* 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
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