* Re: [PATCH v2 08/13] i3c: dw-i3c-master: Add SETAASA as supported CCC
From: Frank Li @ 2026-04-10 2:41 UTC (permalink / raw)
To: Akhil R
Cc: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Rafael J . Wysocki, Robert Moore, Len Brown, Guenter Roeck,
Philipp Zabel, Eric Biggers, Sakari Ailus, Wolfram Sang,
Miquel Raynal, linux-i3c, devicetree, linux-kernel, linux-acpi,
acpica-devel, linux-hwmon
In-Reply-To: <20260409105747.48158-9-akhilrajeev@nvidia.com>
On Thu, Apr 09, 2026 at 04:27:38PM +0530, Akhil R wrote:
> Add SETAASA and SETHID to the supported list of CCC commands for
> DesignWare I3C host controller.
>
> SETAASA is a broadcast command that assigns predefined static
> addresses to all I3C devices on the bus. SETHID is to stop HID
> bit flipping by the SPD Hub on which the SPD devices are connected.
can you wrap commit message at 75 char.
Add add extra empty line between paragraph.
Frank
> It is a prerequisite command to be sent before SETAASA as recommended
> by JESD300-5 and JESD403 sideband bus specifications.
>
> Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
> ---
> drivers/i3c/master/dw-i3c-master.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/i3c/master/dw-i3c-master.c b/drivers/i3c/master/dw-i3c-master.c
> index d6bdb32397fb..05ccdf177b6d 100644
> --- a/drivers/i3c/master/dw-i3c-master.c
> +++ b/drivers/i3c/master/dw-i3c-master.c
> @@ -308,6 +308,8 @@ static bool dw_i3c_master_supports_ccc_cmd(struct i3c_master_controller *m,
> case I3C_CCC_GETSTATUS:
> case I3C_CCC_GETMXDS:
> case I3C_CCC_GETHDRCAP:
> + case I3C_CCC_SETAASA:
> + case I3C_CCC_VENDOR(0, true): /* SETHID */
> return true;
> default:
> return false;
> --
> 2.50.1
>
^ permalink raw reply
* Re: [PATCH v2 09/13] i3c: dw-i3c-master: Add a quirk to skip clock and reset
From: Frank Li @ 2026-04-10 2:45 UTC (permalink / raw)
To: Akhil R
Cc: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Rafael J . Wysocki, Robert Moore, Len Brown, Guenter Roeck,
Philipp Zabel, Eric Biggers, Sakari Ailus, Wolfram Sang,
Miquel Raynal, linux-i3c, devicetree, linux-kernel, linux-acpi,
acpica-devel, linux-hwmon
In-Reply-To: <20260409105747.48158-10-akhilrajeev@nvidia.com>
On Thu, Apr 09, 2026 at 04:27:39PM +0530, Akhil R wrote:
> Some ACPI-enumerated devices like Tegra410 do not have clock and reset
> resources exposed via the clk/reset frameworks. Add a match data for
why not export fix clock at ACPI?
> such devices to skip acquiring clock and reset controls during probe.
>
> Move match data parsing before clock/reset acquisition so the quirk is
> available early enough. When the quirk is set, fall back to reading
> the clock rate from the "clock-frequency" device property instead.
"clock-frequency" is legacy proptery.
Frank
>
> Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
> ---
> drivers/i3c/master/dw-i3c-master.c | 60 +++++++++++++++++++-----------
> 1 file changed, 39 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/i3c/master/dw-i3c-master.c b/drivers/i3c/master/dw-i3c-master.c
> index 05ccdf177b6d..a62eec6d2ac0 100644
> --- a/drivers/i3c/master/dw-i3c-master.c
> +++ b/drivers/i3c/master/dw-i3c-master.c
> @@ -241,6 +241,7 @@
> /* List of quirks */
> #define AMD_I3C_OD_PP_TIMING BIT(1)
> #define DW_I3C_DISABLE_RUNTIME_PM_QUIRK BIT(2)
> +#define DW_I3C_ACPI_SKIP_CLK_RST BIT(3)
>
> struct dw_i3c_cmd {
> u32 cmd_lo;
> @@ -560,13 +561,26 @@ static void dw_i3c_master_set_intr_regs(struct dw_i3c_master *master)
> writel(IBI_REQ_REJECT_ALL, master->regs + IBI_MR_REQ_REJECT);
> }
>
> +static unsigned long dw_i3c_master_get_core_rate(struct dw_i3c_master *master)
> +{
> + unsigned int core_rate_prop;
> +
> + if (!(master->quirks & DW_I3C_ACPI_SKIP_CLK_RST))
> + return clk_get_rate(master->core_clk);
> +
> + if (device_property_read_u32(master->dev, "clock-frequency", &core_rate_prop))
> + return 0;
> +
> + return core_rate_prop;
> +}
> +
> static int dw_i3c_clk_cfg(struct dw_i3c_master *master)
> {
> unsigned long core_rate, core_period;
> u32 scl_timing;
> u8 hcnt, lcnt;
>
> - core_rate = clk_get_rate(master->core_clk);
> + core_rate = dw_i3c_master_get_core_rate(master);
> if (!core_rate)
> return -EINVAL;
>
> @@ -619,7 +633,7 @@ static int dw_i2c_clk_cfg(struct dw_i3c_master *master)
> u16 hcnt, lcnt;
> u32 scl_timing;
>
> - core_rate = clk_get_rate(master->core_clk);
> + core_rate = dw_i3c_master_get_core_rate(master);
> if (!core_rate)
> return -EINVAL;
>
> @@ -1600,21 +1614,34 @@ int dw_i3c_common_probe(struct dw_i3c_master *master,
> if (IS_ERR(master->regs))
> return PTR_ERR(master->regs);
>
> - master->core_clk = devm_clk_get_enabled(&pdev->dev, NULL);
> - if (IS_ERR(master->core_clk))
> - return PTR_ERR(master->core_clk);
> + if (has_acpi_companion(&pdev->dev)) {
> + quirks = (unsigned long)device_get_match_data(&pdev->dev);
> + } else if (pdev->dev.of_node) {
> + drvdata = device_get_match_data(&pdev->dev);
> + if (drvdata)
> + quirks = drvdata->flags;
> + }
> + master->quirks = quirks;
> +
> + if (master->quirks & DW_I3C_ACPI_SKIP_CLK_RST) {
> + master->core_clk = NULL;
> + master->core_rst = NULL;
> + } else {
> + master->core_clk = devm_clk_get_enabled(&pdev->dev, NULL);
> + if (IS_ERR(master->core_clk))
> + return PTR_ERR(master->core_clk);
> +
> + master->core_rst = devm_reset_control_get_optional_exclusive(&pdev->dev,
> + "core_rst");
> + if (IS_ERR(master->core_rst))
> + return PTR_ERR(master->core_rst);
> + reset_control_deassert(master->core_rst);
> + }
>
> master->pclk = devm_clk_get_optional_enabled(&pdev->dev, "pclk");
> if (IS_ERR(master->pclk))
> return PTR_ERR(master->pclk);
>
> - master->core_rst = devm_reset_control_get_optional_exclusive(&pdev->dev,
> - "core_rst");
> - if (IS_ERR(master->core_rst))
> - return PTR_ERR(master->core_rst);
> -
> - reset_control_deassert(master->core_rst);
> -
> spin_lock_init(&master->xferqueue.lock);
> INIT_LIST_HEAD(&master->xferqueue.list);
>
> @@ -1647,15 +1674,6 @@ int dw_i3c_common_probe(struct dw_i3c_master *master,
> master->maxdevs = ret >> 16;
> master->free_pos = GENMASK(master->maxdevs - 1, 0);
>
> - if (has_acpi_companion(&pdev->dev)) {
> - quirks = (unsigned long)device_get_match_data(&pdev->dev);
> - } else if (pdev->dev.of_node) {
> - drvdata = device_get_match_data(&pdev->dev);
> - if (drvdata)
> - quirks = drvdata->flags;
> - }
> - master->quirks = quirks;
> -
> /* Keep controller enabled by preventing runtime suspend */
> if (master->quirks & DW_I3C_DISABLE_RUNTIME_PM_QUIRK)
> pm_runtime_get_noresume(&pdev->dev);
> --
> 2.50.1
>
^ permalink raw reply
* Re: [PATCH v2 10/13] i3c: dw-i3c-master: Add ACPI ID for Tegra410
From: Frank Li @ 2026-04-10 2:47 UTC (permalink / raw)
To: Akhil R
Cc: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Rafael J . Wysocki, Robert Moore, Len Brown, Guenter Roeck,
Philipp Zabel, Eric Biggers, Sakari Ailus, Wolfram Sang,
Miquel Raynal, linux-i3c, devicetree, linux-kernel, linux-acpi,
acpica-devel, linux-hwmon
In-Reply-To: <20260409105747.48158-11-akhilrajeev@nvidia.com>
On Thu, Apr 09, 2026 at 04:27:40PM +0530, Akhil R wrote:
> Update variable names to generic names and add Tegra410 ACPI ID to
> support the I3C controller in Tegra410 which is a DesignWare I3C host
> controller.
>
> Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> drivers/i3c/master/dw-i3c-master.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/i3c/master/dw-i3c-master.c b/drivers/i3c/master/dw-i3c-master.c
> index a62eec6d2ac0..e0ca30308cbb 100644
> --- a/drivers/i3c/master/dw-i3c-master.c
> +++ b/drivers/i3c/master/dw-i3c-master.c
> @@ -1869,11 +1869,12 @@ static const struct of_device_id dw_i3c_master_of_match[] = {
> };
> MODULE_DEVICE_TABLE(of, dw_i3c_master_of_match);
>
> -static const struct acpi_device_id amd_i3c_device_match[] = {
> +static const struct acpi_device_id dw_i3c_master_acpi_match[] = {
> { "AMDI0015", AMD_I3C_OD_PP_TIMING },
> + { "NVDA2018", DW_I3C_ACPI_SKIP_CLK_RST },
> { }
> };
> -MODULE_DEVICE_TABLE(acpi, amd_i3c_device_match);
> +MODULE_DEVICE_TABLE(acpi, dw_i3c_master_acpi_match);
>
> static struct platform_driver dw_i3c_driver = {
> .probe = dw_i3c_probe,
> @@ -1882,7 +1883,7 @@ static struct platform_driver dw_i3c_driver = {
> .driver = {
> .name = "dw-i3c-master",
> .of_match_table = dw_i3c_master_of_match,
> - .acpi_match_table = amd_i3c_device_match,
> + .acpi_match_table = dw_i3c_master_acpi_match,
> .pm = &dw_i3c_pm_ops,
> },
> };
> --
> 2.50.1
>
^ permalink raw reply
* [PATCH] riscv: dts: tenstorrent: Add PMU node to blackhole for Linux perf support
From: Anirudh Srinivasan @ 2026-04-10 2:49 UTC (permalink / raw)
To: Drew Fustini, Joel Stanley, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti
Cc: linux-riscv, devicetree, linux-kernel, Michael Neuling,
Anirudh Srinivasan
From: Michael Neuling <mikey@neuling.org>
Add a riscv,pmu device tree node with SBI PMU event mappings for the
SiFive X280 hardware performance counters. This enables OpenSBI to
expose the SBI PMU extension, allowing Linux perf to use the 4
programmable counters (mhpmcounter3-6) across 3 event classes:
instruction commit, microarchitectural, and memory system events.
Event encodings are derived from the SiFive Tenstorrent X280 MC Manual
(21G3.04.00) Table 13, section 3.10.5.
Assisted-by: Claude:claude-opus-4-6[1m]
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Anirudh Srinivasan <asrinivasan@oss.tenstorrent.com>
---
Added a dependency of [1] to b4 so that checkpatch doesn't complain
about the Assisted-by tag
[1] https://lore.kernel.org/all/20260311152039.254244-1-sashal@kernel.org/
---
arch/riscv/boot/dts/tenstorrent/blackhole.dtsi | 48 ++++++++++++++++++++++++++
1 file changed, 48 insertions(+)
diff --git a/arch/riscv/boot/dts/tenstorrent/blackhole.dtsi b/arch/riscv/boot/dts/tenstorrent/blackhole.dtsi
index 6408810d8d80d..5f709e45d9b28 100644
--- a/arch/riscv/boot/dts/tenstorrent/blackhole.dtsi
+++ b/arch/riscv/boot/dts/tenstorrent/blackhole.dtsi
@@ -77,6 +77,54 @@ cpu3_intc: interrupt-controller {
};
};
+ pmu {
+ compatible = "riscv,pmu";
+ riscv,event-to-mhpmevent =
+ /* SBI_PMU_HW_CPU_CYCLES -> CPU cycles */
+ <0x00001 0x00000000 0x0001>,
+ /* SBI_PMU_HW_INSTRUCTIONS -> Instructions executed */
+ <0x00002 0x00000000 0x0004>,
+ /* SBI_PMU_HW_CACHE_REFERENCES -> I-cache/ITIM busy | D-cache/DTIM busy */
+ <0x00003 0x00000000 0x1801>,
+ /* SBI_PMU_HW_CACHE_MISSES -> I-cache miss | D-cache miss */
+ <0x00004 0x00000000 0x0302>,
+ /* SBI_PMU_HW_BRANCH_INSTRUCTIONS -> Conditional branch retired */
+ <0x00005 0x00000000 0x4000>,
+ /*
+ * SBI_PMU_HW_BRANCH_MISSES ->
+ * Branch direction misprediction | Branch/jump target misprediction
+ */
+ <0x00006 0x00000000 0x6001>,
+ /* L1D_READ_MISS -> Data cache miss or MMIO access */
+ <0x10001 0x00000000 0x0202>,
+ /* L1D_WRITE_ACCESS -> Data cache write-back */
+ <0x10002 0x00000000 0x0402>,
+ /* L1I_READ_MISS -> Instruction cache miss */
+ <0x10009 0x00000000 0x0102>,
+ /* LL_READ_MISS -> UTLB miss */
+ <0x10011 0x00000000 0x2002>,
+ /* DTLB_READ_MISS -> Data TLB miss */
+ <0x10019 0x00000000 0x1002>,
+ /* ITLB_READ_MISS -> Instruction TLB miss */
+ <0x10021 0x00000000 0x0802>;
+ riscv,event-to-mhpmcounters =
+ <0x00001 0x00001 0x01>,
+ <0x00002 0x00002 0x04>,
+ <0x00003 0x00006 0x78>,
+ <0x10001 0x10002 0x78>,
+ <0x10009 0x10009 0x78>,
+ <0x10011 0x10011 0x78>,
+ <0x10019 0x10019 0x78>,
+ <0x10021 0x10021 0x78>;
+ riscv,raw-event-to-mhpmcounters =
+ /* Class 0: Instruction Commit Events, bits 8-25 variant */
+ <0x0 0x0 0xffffffff 0xfc0000ff 0x78>,
+ /* Class 1: Microarchitectural Events, bits 8-18 variant */
+ <0x0 0x1 0xffffffff 0xfff800ff 0x78>,
+ /* Class 2: Memory System Events, bits 8-13 variant */
+ <0x0 0x2 0xffffffff 0xffffc0ff 0x78>;
+ };
+
soc {
#address-cells = <2>;
#size-cells = <2>;
---
base-commit: 559f264e403e4d58d56a17595c60a1de011c5e20
change-id: 20260409-blackhole_pmu-adaf4ee64836
prerequisite-patch-id: 42ee07d35f532e172a464c2b371dec76d7ac18f1
Best regards,
--
Anirudh Srinivasan <asrinivasan@oss.tenstorrent.com>
^ permalink raw reply related
* Re: [PATCH net-next v3 00/12] net: airoha: Support multiple net_devices connected to the same GDM port
From: Jakub Kicinski @ 2026-04-10 2:56 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Christian Marangi,
Benjamin Larsson, linux-arm-kernel, linux-mediatek, netdev,
devicetree, Xuegang Lu
In-Reply-To: <20260406-airoha-eth-multi-serdes-v3-0-ab6ea49d59ff@kernel.org>
On Mon, 06 Apr 2026 12:34:05 +0200 Lorenzo Bianconi wrote:
> EN7581 or AN7583 SoCs support connecting multiple external SerDes (e.g.
> Ethernet or USB SerDes) to GDM3 or GDM4 ports via a hw arbiter that
> manages the traffic in a TDM manner. As a result multiple net_devices can
> connect to the same GDM{3,4} port and there is a theoretical "1:n"
> relation between GDM ports and net_devices.
Still waiting for the device tree review. I'm going to blindly send out
the Sashiko review, please comment if any of it makes sense?
^ permalink raw reply
* Re: [PATCH net-next v3 01/12] dt-bindings: net: airoha: Add EN7581 ethernet-ports properties
From: Jakub Kicinski @ 2026-04-10 2:57 UTC (permalink / raw)
To: lorenzo
Cc: Jakub Kicinski, andrew+netdev, davem, edumazet, pabeni, robh,
krzk+dt, conor+dt, ansuelsmth, benjamin.larsson, linux-arm-kernel,
linux-mediatek, netdev, devicetree
In-Reply-To: <20260406-airoha-eth-multi-serdes-v3-1-ab6ea49d59ff@kernel.org>
This is an AI-generated review of your patch. The human sending this
email says "For your consideration."
---
dt-bindings: net: airoha: Add EN7581 ethernet-ports properties
This commit introduces the ethernet-port property to model a net_device
connected via an external arbiter to the GDM3 or GDM4 ports on EN7581
and AN7583 SoCs.
> diff --git a/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml b/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml
> index fbe2ddcdd909c..ebbd433e9c9fb 100644
> --- a/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml
> +++ b/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml
> @@ -130,6 +130,30 @@ patternProperties:
> maximum: 4
> description: GMAC port identifier
>
> + '#address-cells':
> + const: 1
> + '#size-cells':
> + const: 0
> +
> + patternProperties:
> + "^ethernet-port@[0-5]$":
The commit message states that GDM1 and GDM2 do not support connection
with the external arbiter. However, since this pattern property appears to
be placed inside the generic ^ethernet@[1-4]$ block, does this allow a
device tree to incorrectly configure ethernet-port subnodes on ethernet@1
or ethernet@2 and still pass schema validation?
Could this be restricted to GDM3 and GDM4, perhaps by splitting the
patternProperties or using an if/then block based on the reg property?
> + type: object
> + unevaluatedProperties: false
> + $ref: ethernet-controller.yaml#
Does referencing ethernet-controller.yaml cause a validation conflict here?
The ethernet-controller.yaml schema enforces a strict nodename pattern
of ^ethernet(@.*)?$. Since these new nodes use the -port suffix and are
named ethernet-port@X, will they unconditionally fail the node name
validation enforced by the referenced schema during dt_binding_check?
[ ... ]
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net-next v3 02/12] net: airoha: Set PPE cpu port for GDM2 if loopback is enabled
From: Jakub Kicinski @ 2026-04-10 2:57 UTC (permalink / raw)
To: lorenzo
Cc: Jakub Kicinski, andrew+netdev, davem, edumazet, pabeni, robh,
krzk+dt, conor+dt, ansuelsmth, benjamin.larsson, linux-arm-kernel,
linux-mediatek, netdev, devicetree
In-Reply-To: <20260406-airoha-eth-multi-serdes-v3-2-ab6ea49d59ff@kernel.org>
This is an AI-generated review of your patch. The human sending this
email says "For your consideration."
---
net: airoha: Move airoha_qdma pointer in airoha_gdm_dev struct
This commit moves the airoha_qdma pointer from the airoha_gdm_port struct
to the airoha_gdm_dev struct. This ensures the QDMA block used depends on
the specific net_device WAN/LAN configuration.
[ ... ]
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
[ ... ]
> @@ -1497,9 +1498,10 @@ static void airoha_qdma_stop_napi(struct airoha_qdma *qdma)
> }
> }
>
> -static void airoha_update_hw_stats(struct airoha_gdm_port *port)
> +static void airoha_update_hw_stats(struct airoha_gdm_dev *dev)
> {
> - struct airoha_eth *eth = port->qdma->eth;
> + struct airoha_gdm_port *port = dev->port;
> + struct airoha_eth *eth = dev->eth;
> u32 val, i = 0;
>
> spin_lock(&port->stats.lock);
This isn't a bug introduced by this patch, but does this spin_lock()
carry a deadlock risk?
Because ndo_get_stats64() can be called from atomic context (e.g., from a
softirq), if a process context caller holds port->stats.lock and is
interrupted by a softirq on the same CPU that also triggers dev_get_stats(),
the softirq could spin forever waiting for the lock.
Should this be upgraded to spin_lock_bh() to ensure local softirqs are
disabled during the critical section?
[ ... ]
> --- a/drivers/net/ethernet/airoha/airoha_eth.h
> +++ b/drivers/net/ethernet/airoha/airoha_eth.h
> @@ -534,12 +534,12 @@ struct airoha_qdma {
>
> struct airoha_gdm_dev {
> struct airoha_gdm_port *port;
> + struct airoha_qdma *qdma;
> struct net_device *dev;
> struct airoha_eth *eth;
> };
>
> struct airoha_gdm_port {
> - struct airoha_qdma *qdma;
> struct airoha_gdm_dev *dev;
> int id;
This isn't a bug introduced by this patch, but since the qdma pointer
is being moved to better align with the hardware structure, should
qos_sq_bmap, cpu_tx_packets, and fwd_tx_packets be moved to
struct airoha_qdma as well?
Because QDMA1 is shared by all WAN ports (GDM 2, 3, 4) and qos_sq_bmap
is currently tracked per-port instead of per-QDMA, each WAN port
independently allocates QDMA1 channels starting from index 0. Does this
cause different ports to overwrite each other's hardware QoS configurations
in the shared QDMA1 block?
Furthermore, cpu_tx_packets and fwd_tx_packets cache per-channel ETS
hardware counters but are single u64 scalar variables in the port structure.
When querying stats for multiple channels, do these scalar caches get
overwritten with values from completely different channels, resulting in
incorrect delta calculations?
^ permalink raw reply
* Re: [PATCH net-next v3 04/12] net: airoha: Rely on net_device pointer in HTB callbacks
From: Jakub Kicinski @ 2026-04-10 2:57 UTC (permalink / raw)
To: lorenzo
Cc: Jakub Kicinski, andrew+netdev, davem, edumazet, pabeni, robh,
krzk+dt, conor+dt, ansuelsmth, benjamin.larsson, linux-arm-kernel,
linux-mediatek, netdev, devicetree
In-Reply-To: <20260406-airoha-eth-multi-serdes-v3-4-ab6ea49d59ff@kernel.org>
This is an AI-generated review of your patch. The human sending this
email says "For your consideration."
---
net: airoha: Introduce WAN device flag
This commit introduces a WAN flag to specify whether a device is used to
transmit or receive WAN or LAN traffic. It enables specifying multiple LAN
devices but limits the configuration to a single WAN device.
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 5b0cd37b155e4..9988011dca53f 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -1796,36 +1796,77 @@ static int airoha_set_gdm2_loopback(struct airoha_gdm_dev *dev)
[ ... ]
> +static int airoha_dev_init(struct net_device *netdev)
> +{
> + struct airoha_gdm_dev *dev = netdev_priv(netdev);
> + struct airoha_gdm_port *port = dev->port;
>
> switch (port->id) {
> case AIROHA_GDM3_IDX:
> - case AIROHA_GDM4_IDX:
> - /* If GDM2 is active we can't enable loopback */
> - if (!eth->ports[1]) {
> - int err;
> + case AIROHA_GDM4_IDX: {
> + struct airoha_eth *eth = dev->eth;
>
> - err = airoha_set_gdm2_loopback(dev);
> - if (err)
> - return err;
> - }
> + if (eth->ports[1] || airoha_get_wan_gdm_dev(eth))
> + break;
If a board's Device Tree enables both GDM3 and GDM4, and GDM2 is not present,
does this sequence permanently assign the WAN role to GDM3 since it is
initialized first? Is there a Device Tree property or fallback configuration
mechanism to allow users to specify GDM4 as the WAN port instead?
> + fallthrough;
> + }
> + case AIROHA_GDM2_IDX:
> + /* GDM2 is always used as wan */
> + dev->flags |= PRIV_FLAG_WAN;
> break;
> default:
> break;
> }
>
> - for (i = 0; i < eth->soc->num_ppe; i++)
> - airoha_ppe_set_cpu_port(dev, i, airoha_get_fe_port(dev));
> + airoha_dev_set_qdma(dev);
> + airoha_set_macaddr(dev, netdev->dev_addr);
Since the commit message notes it is possible to specify multiple LAN
devices, does unconditionally calling airoha_set_macaddr() for each
device overwrite the single shared hardware LAN MAC register?
If so, could this cause only the last initialized LAN device to have its MAC
correctly programmed into the hardware, leading to dropped unicast
packets for the other LAN interfaces?
> +
> + if (!airoha_is_lan_gdm_dev(dev) &&
> + (port->id == AIROHA_GDM3_IDX || port->id == AIROHA_GDM4_IDX)) {
> + int err;
[ ... ]
^ permalink raw reply
* Re: [PATCH net-next v3 09/12] net: airoha: Support multiple net_devices for a single FE GDM port
From: Jakub Kicinski @ 2026-04-10 2:57 UTC (permalink / raw)
To: lorenzo
Cc: Jakub Kicinski, andrew+netdev, davem, edumazet, pabeni, robh,
krzk+dt, conor+dt, ansuelsmth, benjamin.larsson, linux-arm-kernel,
linux-mediatek, netdev, devicetree
In-Reply-To: <20260406-airoha-eth-multi-serdes-v3-9-ab6ea49d59ff@kernel.org>
This is an AI-generated review of your patch. The human sending this
email says "For your consideration."
---
net: airoha: Support multiple net_devices for a single FE GDM port
This commit introduces support for mapping multiple net_device interfaces
to a single Frame Engine (FE) GDM port via an external hardware arbiter.
It updates the rx/tx paths, port allocation, and registration logic to
handle the new net_device array.
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
[ ... ]
> @@ -615,9 +617,8 @@ static int airoha_qdma_rx_process(struct airoha_queue *q, int budget)
> u32 hash, reason, msg1 = le32_to_cpu(desc->msg1);
> struct page *page = virt_to_head_page(e->buf);
> u32 desc_ctrl = le32_to_cpu(desc->ctrl);
> - struct airoha_gdm_port *port;
> - struct net_device *netdev;
> - int data_len, len, p;
> + struct airoha_gdm_dev *dev;
> + int data_len, len;
>
> if (!(desc_ctrl & QDMA_DESC_DONE_MASK))
> break;
While looking at this code, I noticed an issue that predates this patch.
Can the lack of a memory barrier after checking the descriptor ownership bit
cause stale reads?
The driver checks QDMA_DESC_DONE_MASK to verify that the hardware has finished
writing the descriptor. However, it reads desc->msg1 before this check and
without a dma_rmb():
u32 hash, reason, msg1 = le32_to_cpu(desc->msg1);
struct page *page = virt_to_head_page(e->buf);
u32 desc_ctrl = le32_to_cpu(desc->ctrl);
if (!(desc_ctrl & QDMA_DESC_DONE_MASK))
break;
Since weakly ordered architectures can reorder memory reads, could the CPU
prefetch msg1 before the DMA engine writes the new descriptor values, leading
to routing the packet to the wrong gdm_dev?
[ ... ]
> @@ -1764,9 +1765,7 @@ static int airoha_set_gdm2_loopback(struct airoha_gdm_dev *dev)
> airoha_fe_clear(eth, REG_FE_VIP_PORT_EN, BIT(AIROHA_GDM2_IDX));
> airoha_fe_clear(eth, REG_FE_IFC_PORT_EN, BIT(AIROHA_GDM2_IDX));
>
> - /* XXX: handle XSI_USB_PORT and XSI_PCE1_PORT */
> - nbq = port->id == AIROHA_GDM3_IDX && airoha_is_7581(eth) ? 4 : 0;
> - src_port = eth->soc->ops.get_src_port_id(port, nbq);
> + src_port = eth->soc->ops.get_src_port_id(port, dev->nbq);
> if (src_port < 0)
> return src_port;
Can configuring the loopback for one device break connectivity for other
devices sharing the same port?
When multiple net_devices (like PCIE0 and PCIE1 on GDM3) open and call
airoha_set_gdm2_loopback(), they modify global hardware registers such as
REG_FE_WAN_PORT.
Since WAN0_MASK is unconditionally updated to track the current device's
src_port:
airoha_fe_rmw(eth, REG_FE_WAN_PORT,
WAN1_EN_MASK | WAN1_MASK | WAN0_MASK,
FIELD_PREP(WAN0_MASK, src_port));
won't the last configured device clobber the hardware state for the others?
[ ... ]
> @@ -1987,7 +1986,8 @@ static netdev_tx_t airoha_dev_xmit(struct sk_buff *skb,
> }
>
> fport = airoha_get_fe_port(dev);
> - msg1 = FIELD_PREP(QDMA_ETH_TXMSG_FPORT_MASK, fport) |
> + msg1 = FIELD_PREP(QDMA_ETH_TXMSG_NBOQ_MASK, dev->nbq) |
> + FIELD_PREP(QDMA_ETH_TXMSG_FPORT_MASK, fport) |
> FIELD_PREP(QDMA_ETH_TXMSG_METER_MASK, 0x7f);
>
> q = &qdma->q_tx[qid];
Does sharing the hardware QDMA TX queues among multiple net_device instances
introduce a permanent transmit stall?
In airoha_dev_xmit(), if a shared hardware queue is full, the driver stops the
netdev_queue of the specific netdev making the call:
if (q->queued + nr_frags >= q->ndesc) {
/* not enough space in the queue */
netif_tx_stop_queue(txq);
spin_unlock_bh(&q->lock);
return NETDEV_TX_BUSY;
}
However, the TX completion handler (airoha_tx_irq_process()) only wakes the
queue of the netdev attached to the completed packet. If an interface's TX
queue is stopped but it has no pending packets in the hardware queue (because
another interface filled it), will it ever get woken up?
[ ... ]
> @@ -2955,11 +2958,25 @@ static int airoha_alloc_gdm_device(struct airoha_eth *eth,
> netdev->dev_addr);
> }
>
> + /* Allowed nbq for EN7581 on GDM3 port are 4 and 5 for PCIE0
> + * and PCIE1 respectively.
> + */
> + index = nbq;
> + if (index && airoha_is_7581(eth) && port->id == AIROHA_GDM3_IDX)
> + index -= 4;
> +
> + if (index >= ARRAY_SIZE(port->devs) || port->devs[index]) {
> + dev_err(eth->dev, "invalid nbq id: %d\n", nbq);
> + return -EINVAL;
> + }
> +
> + netdev->dev.of_node = of_node_get(np);
> dev = netdev_priv(netdev);
Does this code leak the of_node reference?
The node reference is explicitly incremented via of_node_get(np). The networking
core does not automatically drop explicit of_node references on free_netdev().
Without a matching of_node_put() in the error paths or the driver's teardown
function (airoha_remove()), will this reference permanently leak when the device
is destroyed?
[ ... ]
> @@ -3003,7 +3021,43 @@ static int airoha_alloc_gdm_port(struct airoha_eth *eth,
> if (err)
> return err;
>
> - return airoha_alloc_gdm_device(eth, port, np);
> + for_each_child_of_node(np, node) {
> + /* Multiple external serdes connected to the FE GDM port via an
> + * external arbiter.
> + */
> + const __be32 *nbq_ptr;
> + int nbq;
> +
> + if (!of_device_is_compatible(node, "airoha,eth-port"))
> + continue;
> +
> + d++;
> + if (!of_device_is_available(node))
> + continue;
> +
> + nbq_ptr = of_get_property(node, "reg", NULL);
> + if (!nbq_ptr) {
> + dev_err(eth->dev, "missing nbq id\n");
> + of_node_put(node);
> + return -EINVAL;
> + }
> +
> + /* Verify the provided nbq parameter is valid */
> + nbq = be32_to_cpup(nbq_ptr);
> + err = eth->soc->ops.get_src_port_id(port, nbq);
> + if (err < 0) {
> + of_node_put(node);
> + return err;
> + }
> +
> + err = airoha_alloc_gdm_device(eth, port, nbq, node);
> + if (err) {
> + of_node_put(node);
> + return err;
> + }
> + }
> +
> + return !d ? airoha_alloc_gdm_device(eth, port, 0, np) : 0;
> }
Does passing 0 for nbq in the fallback path break older device trees on the
EN7581 SoC?
Later, when the interface is brought up, airoha_set_gdm2_loopback() calls
airoha_en7581_get_src_port_id(), which returns -EINVAL for GDM3 if nbq is
not 4 or 5:
switch (port->id) {
case AIROHA_GDM3_IDX:
/* 7581 SoC supports PCIe serdes on GDM3 port */
if (nbq == 4)
return HSGMII_LAN_7581_PCIE0_SRCPORT;
if (nbq == 5)
return HSGMII_LAN_7581_PCIE1_SRCPORT;
break;
If nbq is hardcoded to 0 for legacy DTs, won't this cause interface
initialization to fail unconditionally for GDM3?
^ permalink raw reply
* Re: [PATCH net-next v3 10/12] net: airoha: Do not stop GDM port if it is shared
From: Jakub Kicinski @ 2026-04-10 2:57 UTC (permalink / raw)
To: lorenzo
Cc: Jakub Kicinski, andrew+netdev, davem, edumazet, pabeni, robh,
krzk+dt, conor+dt, ansuelsmth, benjamin.larsson, linux-arm-kernel,
linux-mediatek, netdev, devicetree, Xuegang Lu
In-Reply-To: <20260406-airoha-eth-multi-serdes-v3-10-ab6ea49d59ff@kernel.org>
This is an AI-generated review of your patch. The human sending this
email says "For your consideration."
---
net: airoha: Do not stop GDM port if it is shared
Theoretically, in the current codebase, two independent net_devices can
be connected to the same GDM port so we need to check the GDM port is not
used by any other running net_device before setting the forward
configuration to FE_PSE_PORT_DROP.
Tested-by: Xuegang Lu <xuegang.lu@airoha.com>
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index fd27ba13029bd..5b0cd37b155e4 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
[ ... ]
> @@ -1688,18 +1693,18 @@ static int airoha_dev_stop(struct net_device *netdev)
> struct airoha_gdm_dev *dev = netdev_priv(netdev);
> struct airoha_gdm_port *port = dev->port;
> struct airoha_qdma *qdma = dev->qdma;
> - int i, err;
> + int i;
>
> netif_tx_disable(netdev);
> - err = airoha_set_vip_for_gdm_port(dev, false);
> - if (err)
> - return err;
> -
> for (i = 0; i < ARRAY_SIZE(qdma->q_tx); i++)
> netdev_tx_reset_subqueue(netdev, i);
>
> - airoha_set_gdm_port_fwd_cfg(qdma->eth, REG_GDM_FWD_CFG(port->id),
> - FE_PSE_PORT_DROP);
> + if (atomic_dec_and_test(&port->users)) {
> + airoha_set_vip_for_gdm_port(dev, false);
> + airoha_set_gdm_port_fwd_cfg(qdma->eth,
> + REG_GDM_FWD_CFG(port->id),
> + FE_PSE_PORT_DROP);
> + }
>
> if (atomic_dec_and_test(&qdma->users)) {
> airoha_qdma_clear(qdma, REG_QDMA_GLOBAL_CFG,
> GLOBAL_CFG_TX_DMA_EN_MASK |
> GLOBAL_CFG_RX_DMA_EN_MASK);
>
> for (i = 0; i < ARRAY_SIZE(qdma->q_tx); i++) {
> if (!qdma->q_tx[i].ndesc)
> continue;
>
> airoha_qdma_cleanup_tx_queue(&qdma->q_tx[i]);
> }
> }
This problem wasn't introduced by this patch, but does the QDMA teardown
path have a DMA corruption vulnerability here?
When GLOBAL_CFG_TX_DMA_EN_MASK is cleared, it fails to poll
GLOBAL_CFG_TX_DMA_BUSY_MASK, proceeding to unmap memory while the hardware
DMA engine may still be processing in-flight descriptors.
Furthermore, airoha_qdma_cleanup_tx_queue() unmaps the DMA addresses and
frees the SKBs, but it does not appear to clear the physical hardware
descriptors or reset the hardware ring pointers (REG_TX_CPU_IDX /
REG_TX_DMA_IDX).
When the device is later reopened in airoha_dev_open(),
GLOBAL_CFG_TX_DMA_EN_MASK is set again without re-initializing the rings.
Will the hardware DMA engine resume fetching from its previous index,
processing stale descriptors whose backing memory was already unmapped
and freed?
[ ... ]
> @@ -1851,10 +1856,22 @@ static void airoha_dev_get_stats64(struct net_device *netdev,
> static int airoha_dev_change_mtu(struct net_device *netdev, int mtu)
> {
> struct airoha_gdm_dev *dev = netdev_priv(netdev);
> + u32 cur_len, len = ETH_HLEN + mtu + ETH_FCS_LEN;
> struct airoha_gdm_port *port = dev->port;
> - u32 len = ETH_HLEN + mtu + ETH_FCS_LEN;
> struct airoha_eth *eth = dev->eth;
>
> + cur_len = FIELD_GET(GDM_LONG_LEN_MASK,
> + airoha_fe_rr(eth, REG_GDM_LEN_CFG(port->id)));
> + if (len < cur_len) {
> + u8 port_refcnt = atomic_read(&port->users);
> +
> + /* We can decrease the device MTU just if the GDM port is
> + * not shared or if the other device is not running.
> + */
> + if (port_refcnt > 1 || (port_refcnt && !netif_running(netdev)))
> + return -EBUSY;
> + }
> +
Does this MTU decrease validation create a state trap on shared ports?
If both eth0 and eth1 (sharing a port) are up, and a user increases eth0 MTU
to 9000, the hardware MTU updates to 9000. If the user then tries to lower
eth0 MTU back to 1500, len < cur_len evaluates to true. Because eth1 is also
up (port_refcnt > 1), this returns -EBUSY.
This would prevent either interface from decreasing its MTU without fully
bringing down the sibling interface.
Should the software netdev->mtu be decoupled from the hardware validation,
allowing valid MTU changes in software while dynamically programming the
hardware MTU to the maximum of all currently up interfaces on the shared
port?
^ permalink raw reply
* Re: [PATCH net-next v3 00/12] net: airoha: Support multiple net_devices connected to the same GDM port
From: Jakub Kicinski @ 2026-04-10 2:59 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Christian Marangi,
Benjamin Larsson, linux-arm-kernel, linux-mediatek, netdev,
devicetree, Xuegang Lu
In-Reply-To: <20260406-airoha-eth-multi-serdes-v3-0-ab6ea49d59ff@kernel.org>
On Mon, 06 Apr 2026 12:34:05 +0200 Lorenzo Bianconi wrote:
> EN7581 or AN7583 SoCs support connecting multiple external SerDes (e.g.
> Ethernet or USB SerDes) to GDM3 or GDM4 ports via a hw arbiter that
> manages the traffic in a TDM manner. As a result multiple net_devices can
> connect to the same GDM{3,4} port and there is a theoretical "1:n"
> relation between GDM ports and net_devices.
Looks like this driver uses page pool.
If you're sharing the same page pool across multiple netdevs
it must not be linked to a netdev.
^ permalink raw reply
* RE: [PATCH V2 0/8] PCI: imx6: Integrate pwrctrl API and update device trees
From: Sherry Sun @ 2026-04-10 3:00 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
Frank Li, s.hauer@pengutronix.de, kernel@pengutronix.de,
festevam@gmail.com, lpieralisi@kernel.org, kwilczynski@kernel.org,
bhelgaas@google.com, Hongxing Zhu, l.stach@pengutronix.de,
imx@lists.linux.dev, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <omtn42mopdz7igg7jaqwehd67l6xc77zk7zzqwkufgnsycvadg@5kodhpgfesre>
> Subject: Re: [PATCH V2 0/8] PCI: imx6: Integrate pwrctrl API and update device
> trees
>
> On Thu, Apr 02, 2026 at 06:09:59PM +0800, Sherry Sun wrote:
> > Note: This patch set depends on my previous patch set [1] which adds
> > Root Port device tree nodes and support parsing the reset property in
> > new Root Port binding in pci-imx6 driver.
> >
> > This series integrates the PCI pwrctrl framework into the pci-imx6
> > driver and updates i.MX EVK board device trees to support it.
> >
> > Patches 2-8 update device trees for i.MX EVK boards which maintained
> > by NXP to move power supply properties from the PCIe controller node
> > to the Root Port child node, which is required for pwrctrl framework.
> > Affected boards:
> > - i.MX6Q/DL SABRESD
> > - i.MX6SX SDB
> > - i.MX8MM EVK
> > - i.MX8MP EVK
> > - i.MX8MQ EVK
> > - i.MX8DXL/QM/QXP EVK
> > - i.MX95 15x15/19x19 EVK
> >
> > The driver maintains legacy regulator handling for device trees that
> > haven't been updated yet. Both old and new device tree structures are
> > supported.
> >
>
> Thanks for the work! Due to some recently merged patches, this series (Patch
> 1) doesn't apply on top of pci/controller/dwc-imx6 branch. Please rebase and
> resend!
>
> - Mani
Hi Mani, thanks for the reminder.
Actually this patch set depends on my PERST# patch set [1], which adds
support for Root Port dts nodes and correctly adjusts the sequence of PERST#
assert/deassert and regulator/clock enable in pci-imx6 driver.
I will resend this series once the PERST# patch set been accepted.
[1] https://lore.kernel.org/all/20260410023055.2439146-1-sherry.sun@nxp.com/
Best Regards
Sherry
^ permalink raw reply
* Re: [PATCH v1 1/2] dt-bindings: i2c: ls2x-i2c: Add clock- related properties
From: Hongliang Wang @ 2026-04-10 3:04 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Binbin Zhou, Andi Shyti, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-i2c, devicetree, loongarch
In-Reply-To: <dc1c0b6d-b6e6-4a88-8e50-e8316e3dcf5e@kernel.org>
Hi, Krzysztof
On 2026/4/9 下午8:11, Krzysztof Kozlowski wrote:
> On 09/04/2026 14:03, Hongliang Wang wrote:
>> I have a question, the input clock of i2c controller can be described by
>> "clocks",
>> but there is no existing attribute can describe the divisor of the input
>> clock,
>> Can I define a new attribute named "clock-div" to describe it in DT
>> bindings?
>> or do you have any standard solutions for the divisor problem? Thank you.
>>
> You should determine/calculate the divisor in the driver code, depending
> on clocks and bus frequencies. You don't need a property for that, usually.
Not only clocks and bus frequencies, but also a third property is required.
The frequency divison calculation formula of i2c is
Prcescale = clock_a/(clock_div*clock_s)-1
There is three parameters in this formula:
clock_a represents the input clock, which is described by "clocks",
clock_s represents the i2c bus frequency, which is described by
"clock-frequency",
but there is no existing property to describe clock_div, which has
different value
on different platform (for example, it is 5 on 7a1000/7a2000, 4 on
2K1000/2K2000,
5.5 on 2K3000.), So I need a property to describe clock_div in this formula.
> Best regards,
> Krzysztof
Best regards,
Hongliang Wang
^ permalink raw reply
* Re: [PATCH v1 1/2] dt-bindings: i2c: ls2x-i2c: Add clock- related properties
From: Hongliang Wang @ 2026-04-10 3:06 UTC (permalink / raw)
To: Yao Zi, Krzysztof Kozlowski
Cc: Binbin Zhou, Andi Shyti, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-i2c, devicetree, loongarch
In-Reply-To: <adfF4y8_GhtExZMf@pie>
Hi, Yao Zi
On 2026/4/9 下午11:29, Yao Zi wrote:
> On Thu, Apr 09, 2026 at 08:03:47PM +0800, Hongliang Wang wrote:
>> Hi, Krzysztof
>>
>> On 2026/3/31 下午3:11, Hongliang Wang wrote:
>>> On 2026/3/30 下午3:23, Krzysztof Kozlowski wrote:
>>>> On 30/03/2026 09:18, Hongliang Wang wrote:
>>>>> On 2026/3/27 下午2:39, Krzysztof Kozlowski wrote:
>>>>>> On 27/03/2026 04:09, Hongliang Wang wrote:
>>>>>>> The initial idea was that this patch could be used for
>>>>>>> both ACPI and DTS.
>>>>>>>>>> The i2c-ls2x driver is compatible with both Loongson 2K and 3A+7A
>>>>>>>>>> platform, parse
>>>>>>>>>> the same parameters regardless of dts or
>>>>>>>>>> acpi parameter passing, So
>>>>>>>>>> clock-input
>>>>>>>>>> and clock-div attributes are defined to
>>>>>>>>>> describe input clock of i2c
>>>>>>>>>> controller and
>>>>>>>>>> divisor of input clock. It can be used on
>>>>>>>>>> both 2K and 3A+7A platform.
>>>>>>>>> And you cannot use them in DTS.
>>>>>>> OK
>>>>>>>> I need to keep guessing what you want to achieve,
>>>>>>>> because neither your
>>>>>>>> message nor commit text was explicit
>>>>>>> What I want to achieve is to describe the input clock
>>>>>>> and divisor of I2C
>>>>>>> controller
>>>>>> Input clocks are defined as clock inputs obviously in DT, not as
>>>>>> integers. Bindings need to describe the hardware, so start with that.
>>>>> I can describe the hardware in loongson,ls2x-i2c.yaml, and I
>>>>> would like to
>>>>> confirm with you what final implementation plan you agree to? clock
>>>>> framework
>>>>> or custom clock-input an clock-div attributes? if clock framework, how
>>>>> can it
>>>>> also be used for ACPI?
>>>> And you ask DT maintainer for that? It's not relevant. You sent DT
>>>> bindings patch, so this patch must be correct and we discuss this patch
>>>> here.
>>> I don't. My idea is that if the clock input attribute can't be used for
>>> both
>>> dts and acpi, then clock framework will be used for dts and new define
>>> attribute
>>> will be used for acpi. I will first implement the hardware description
>>> and clock
>>> framework in Bindings.
>>>> Best regards,
>>>> Krzysztof
>>> Best regards,
>>> Hongliang Wang
>>>
>> I have a question, the input clock of i2c controller can be described by
>> "clocks",
>> but there is no existing attribute can describe the divisor of the input
>> clock,
> From the description of 7A1000's user manual (section 2.3
> "时钟功能描述"), it seems the divider isn't part of the I2C controller,
> but instead is an on-chip divider with fixed 1/2 factor, feeding both
> "MISC" block (including I2C) and SPI.
>
>> Can I define a new attribute named "clock-div" to describe it in DT
>> bindings?
>> or do you have any standard solutions for the divisor problem? Thank you.
> If these devicetree-based Loongson platforms follow a similar pattern as
> the bridge chip, then the divisor shouldn't be described in the I2C
> controller node. You may want to include a "fixed-factor-clock" node to
> match the hardware.
>
Sorry, I didn't describe it clearly, The divisor I described doesn't
refer to
the fixed 1/2 factor feeding MISC block(including I2C). What I have
described
is included in the formula in section 10.2 of the 7a1000 user manual.
Prcescale = clock_a/(clock_div*clock_s)-1
clock_a represents the input clock(it is the fixed 1/2 factor feeding
MISC block
(including I2C), 50M on 7a1000), which is described by "clocks",
clock_s represents the i2c bus frequency, which is described by
"clock-frequency",
The divisor I described is clock_div in formula. which has different
value on
different platform. for example, it is 5 on 7a1000/7a2000, 4 on
2K1000/2K2000,
5.5 on 2K3000. I need a property to describe clock_div in this formula.
>> Best regards,
>> Hongliang Wang
>>
>>
>>
> Regards,
> Yao Zi
Best regards,
Hongliang Wang
^ permalink raw reply
* [PATCH 0/7] arm64: dts: qcom: Add label properties to CoreSight devices
From: Jie Gan @ 2026-04-10 3:08 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang
Cc: linux-arm-msm, devicetree, linux-kernel, Jie Gan
The CoreSight framework and userspace tools identify trace devices by
their base address, which is not human-readable. The label property
provides a stable, descriptive name for each TPDM and CTI device,
allowing tools to refer to devices by name rather than address.
This series adds label properties to TPDM and CTI nodes across seven
Qualcomm platforms:
lemans
talos
monaco
kodiak
kaanapali
sm8750
hamoa
With the change, we will have a sysfs node for each Coresight device:
root@qemuarm64:/sys/bus/coresight/devices/tpdm0# cat label
tpdm_spdm
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
Jie Gan (7):
arm64: dts: qcom: lemans: Add label properties to CoreSight devices
arm64: dts: qcom: talos: Add label properties to CoreSight devices
arm64: dts: qcom: monaco: Add label properties to CoreSight devices
arm64: dts: qcom: kodiak: Add label properties to CoreSight devices
arm64: dts: qcom: kaanapali: Add label properties to CoreSight devices
arm64: dts: qcom: sm8750: Add label properties to CoreSight devices
arm64: dts: qcom: hamoa: Add label properties to CoreSight devices
arch/arm64/boot/dts/qcom/hamoa.dtsi | 30 +++++++++++++++++
arch/arm64/boot/dts/qcom/kaanapali.dtsi | 35 +++++++++++++++++++
arch/arm64/boot/dts/qcom/kodiak.dtsi | 12 +++++++
arch/arm64/boot/dts/qcom/lemans.dtsi | 14 ++++++++
arch/arm64/boot/dts/qcom/monaco.dtsi | 29 ++++++++++++++++
arch/arm64/boot/dts/qcom/sm8750.dtsi | 27 +++++++++++++++
arch/arm64/boot/dts/qcom/talos.dtsi | 59 +++++++++++++++++++++++++++++++++
7 files changed, 206 insertions(+)
---
base-commit: f3e6330d7fe42b204af05a2dbc68b379e0ad179e
change-id: 20260409-add-label-to-coresight-device-b17a2ba6030e
Best regards,
--
Jie Gan <jie.gan@oss.qualcomm.com>
^ permalink raw reply
* [PATCH 1/7] arm64: dts: qcom: lemans: Add label properties to CoreSight devices
From: Jie Gan @ 2026-04-10 3:08 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang
Cc: linux-arm-msm, devicetree, linux-kernel, Jie Gan
In-Reply-To: <20260410-add-label-to-coresight-device-v1-0-d71a6759dbc2@oss.qualcomm.com>
Add label properties to TPDM and CTI nodes in the lemans device tree to
provide human-readable identifiers for each CoreSight device. These
labels allow userspace tools and the CoreSight framework to identify
devices by name rather than by base address.
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/lemans.dtsi | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/lemans.dtsi b/arch/arm64/boot/dts/qcom/lemans.dtsi
index fe6e76351823..7cdca20708cc 100644
--- a/arch/arm64/boot/dts/qcom/lemans.dtsi
+++ b/arch/arm64/boot/dts/qcom/lemans.dtsi
@@ -2847,6 +2847,7 @@ tpdm@4003000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_dcc";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -2906,6 +2907,7 @@ tpdm@400f000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_spdm";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -3374,6 +3376,7 @@ tpdm@4b09000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_0";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -3394,6 +3397,7 @@ tpdm@4b0a000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_1";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -3414,6 +3418,7 @@ tpdm@4b0b000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_2";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -3434,6 +3439,7 @@ tpdm@4b0c000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_3";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -3454,6 +3460,7 @@ tpdm@4b0d000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_1";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -3474,6 +3481,7 @@ aoss_cti: cti@4b13000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_aoss";
};
funnel@4b83000 {
@@ -3795,6 +3803,7 @@ tpdm@6860000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_actpm";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -3815,6 +3824,7 @@ tpdm@6861000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_apss";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -3897,6 +3907,7 @@ tpdm@68a0000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_llm_silver";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -3917,6 +3928,7 @@ tpdm@68b0000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_llm_gold";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -3937,6 +3949,7 @@ tpdm@68c0000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_llm_ext";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -8590,6 +8603,7 @@ arch_timer: timer {
turing-llm-tpdm {
compatible = "qcom,coresight-static-tpdm";
+ label = "tpdm_cdsp_llm_0";
qcom,cmb-element-bits = <32>;
--
2.34.1
^ permalink raw reply related
* [PATCH 2/7] arm64: dts: qcom: talos: Add label properties to CoreSight devices
From: Jie Gan @ 2026-04-10 3:08 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang
Cc: linux-arm-msm, devicetree, linux-kernel, Jie Gan
In-Reply-To: <20260410-add-label-to-coresight-device-v1-0-d71a6759dbc2@oss.qualcomm.com>
Add label properties to CTI and TPDM nodes in the talos device tree to
provide human-readable identifiers for each CoreSight device. These
labels allow userspace tools and the CoreSight framework to identify
devices by name rather than by base address.
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/talos.dtsi | 59 +++++++++++++++++++++++++++++++++++++
1 file changed, 59 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/talos.dtsi b/arch/arm64/boot/dts/qcom/talos.dtsi
index ff5afbfce2a4..019911f3f923 100644
--- a/arch/arm64/boot/dts/qcom/talos.dtsi
+++ b/arch/arm64/boot/dts/qcom/talos.dtsi
@@ -2180,6 +2180,7 @@ cti@6010000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_qdss";
};
cti@6011000 {
@@ -2188,6 +2189,7 @@ cti@6011000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_qdss_1";
};
cti@6012000 {
@@ -2196,6 +2198,7 @@ cti@6012000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_qdss_2";
};
cti@6013000 {
@@ -2204,6 +2207,7 @@ cti@6013000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_qdss_3";
};
cti@6014000 {
@@ -2212,6 +2216,7 @@ cti@6014000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_qdss_4";
};
cti@6015000 {
@@ -2220,6 +2225,7 @@ cti@6015000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_qdss_5";
};
cti@6016000 {
@@ -2228,6 +2234,7 @@ cti@6016000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_qdss_6";
};
cti@6017000 {
@@ -2236,6 +2243,7 @@ cti@6017000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_qdss_7";
};
cti@6018000 {
@@ -2244,6 +2252,7 @@ cti@6018000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_qdss_8";
};
cti@6019000 {
@@ -2252,6 +2261,7 @@ cti@6019000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_qdss_9";
};
cti@601a000 {
@@ -2260,6 +2270,7 @@ cti@601a000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_qdss_10";
};
cti@601b000 {
@@ -2268,6 +2279,7 @@ cti@601b000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_qdss_11";
};
cti@601c000 {
@@ -2276,6 +2288,7 @@ cti@601c000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_qdss_12";
};
cti@601d000 {
@@ -2284,6 +2297,7 @@ cti@601d000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_qdss_13";
};
cti@601e000 {
@@ -2292,6 +2306,7 @@ cti@601e000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_qdss_14";
};
cti@601f000 {
@@ -2300,6 +2315,7 @@ cti@601f000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_qdss_15";
};
funnel@6041000 {
@@ -2532,6 +2548,7 @@ cti@683b000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_qdsp6";
};
tpdm@6840000 {
@@ -2540,6 +2557,7 @@ tpdm@6840000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_vsense";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -2560,6 +2578,7 @@ tpdm@684c000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_prng";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -2579,6 +2598,7 @@ tpdm@6850000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_pimem";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -2600,6 +2620,7 @@ tpdm@6860000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_cdsp";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -2643,6 +2664,7 @@ cti@6867000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_cdsp";
};
tpdm@6870000 {
@@ -2651,6 +2673,7 @@ tpdm@6870000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_dcc";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -2671,6 +2694,7 @@ tpdm@699c000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_wcss";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -2693,6 +2717,7 @@ tpdm@69c0000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_monaq";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -2736,6 +2761,7 @@ tpdm@69d0000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_qm";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -2756,6 +2782,7 @@ tpdm@6a00000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_ddr";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -2776,6 +2803,7 @@ cti@6a02000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_ddr_dl0";
};
cti@6a03000 {
@@ -2784,6 +2812,7 @@ cti@6a03000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_ddr_dl0_1";
};
cti@6a10000 {
@@ -2792,6 +2821,7 @@ cti@6a10000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_ddr_dl1";
};
cti@6a11000 {
@@ -2800,6 +2830,7 @@ cti@6a11000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_ddr_dl1_1";
};
funnel@6a05000 {
@@ -2870,6 +2901,7 @@ tpdm@6b02000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_0";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -2890,6 +2922,7 @@ tpdm@6b03000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_1";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -2910,6 +2943,7 @@ cti@6b04000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_swao";
};
cti@6b05000 {
@@ -2918,6 +2952,7 @@ cti@6b05000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_swao_1";
};
cti@6b06000 {
@@ -2926,6 +2961,7 @@ cti@6b06000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_swao_2";
};
cti@6b07000 {
@@ -2934,6 +2970,7 @@ cti@6b07000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_swao_3";
};
funnel@6b08000 {
@@ -3040,6 +3077,7 @@ cti@6b21000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_aop_m3";
};
tpdm@6b48000 {
@@ -3048,6 +3086,7 @@ tpdm@6b48000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_west";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -3067,6 +3106,7 @@ cti@6c13000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_titan";
/* Not all required clocks can be enabled from the OS */
status = "fail";
@@ -3078,6 +3118,7 @@ cti@6c20000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_venus";
status = "disabled";
};
@@ -3087,6 +3128,7 @@ tpdm@6c28000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_center";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -3106,6 +3148,7 @@ cti@6c29000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_dlct";
};
cti@6c2a000 {
@@ -3114,6 +3157,7 @@ cti@6c2a000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_dlct_1";
};
cti@7020000 {
@@ -3122,6 +3166,7 @@ cti@7020000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_apss_apb_2";
};
etm@7040000 {
@@ -3150,6 +3195,7 @@ cti@7120000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_apss_apb_3";
};
etm@7140000 {
@@ -3178,6 +3224,7 @@ cti@7220000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_apss_apb_4";
};
etm@7240000 {
@@ -3206,6 +3253,7 @@ cti@7320000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_apss_apb_5";
};
etm@7340000 {
@@ -3234,6 +3282,7 @@ cti@7420000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_apss_apb_6";
};
etm@7440000 {
@@ -3262,6 +3311,7 @@ cti@7520000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_apss_apb_7";
};
etm@7540000 {
@@ -3290,6 +3340,7 @@ cti@7620000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_apss_apb_8";
};
etm@7640000 {
@@ -3318,6 +3369,7 @@ cti@7720000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_apss_apb_9";
};
etm@7740000 {
@@ -3492,6 +3544,7 @@ tpdm@7830000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_olc";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -3535,6 +3588,7 @@ tpdm@7860000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_apss";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -3578,6 +3632,7 @@ tpdm@78a0000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_llm_silver";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -3597,6 +3652,7 @@ tpdm@78b0000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_llm_gold";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -3664,6 +3720,7 @@ cti@78e0000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_apss";
};
cti@78f0000 {
@@ -3672,6 +3729,7 @@ cti@78f0000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_apss_1";
};
cti@7900000 {
@@ -3680,6 +3738,7 @@ cti@7900000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_apss_2";
};
remoteproc_cdsp: remoteproc@8300000 {
--
2.34.1
^ permalink raw reply related
* [PATCH 3/7] arm64: dts: qcom: monaco: Add label properties to CoreSight devices
From: Jie Gan @ 2026-04-10 3:08 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang
Cc: linux-arm-msm, devicetree, linux-kernel, Jie Gan
In-Reply-To: <20260410-add-label-to-coresight-device-v1-0-d71a6759dbc2@oss.qualcomm.com>
Add label properties to TPDM and CTI nodes in the monaco device tree to
provide human-readable identifiers for each CoreSight device. These
labels allow userspace tools and the CoreSight framework to identify
devices by name rather than by base address.
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/monaco.dtsi | 29 +++++++++++++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/monaco.dtsi b/arch/arm64/boot/dts/qcom/monaco.dtsi
index 7b1d57460f1e..3e076a1df1b9 100644
--- a/arch/arm64/boot/dts/qcom/monaco.dtsi
+++ b/arch/arm64/boot/dts/qcom/monaco.dtsi
@@ -3045,6 +3045,7 @@ tpdm@400f000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_spdm";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -3307,6 +3308,7 @@ tpdm@4841000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_prng";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -3326,6 +3328,7 @@ tpdm@4850000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_pimem";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -3347,6 +3350,7 @@ tpdm@4860000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_dl_ch_south";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -3440,6 +3444,7 @@ tpdm@4980000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_cdsp";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -3483,6 +3488,7 @@ tpdm@4ac0000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_mmnoc_0";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -3555,6 +3561,7 @@ tpdm@4ad0000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_dlct";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -3807,6 +3814,7 @@ tpdm@4b09000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_0";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -3826,6 +3834,7 @@ tpdm@4b0a000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_1";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -3845,6 +3854,7 @@ tpdm@4b0b000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_2";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -3864,6 +3874,7 @@ tpdm@4b0c000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_3";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -3883,6 +3894,7 @@ tpdm@4b0d000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_1";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -3902,6 +3914,7 @@ cti@4b13000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_aoss";
};
tpdm@4b80000 {
@@ -3910,6 +3923,7 @@ tpdm@4b80000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_cdsp_0";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -3977,6 +3991,7 @@ cti@4b8b000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_cdsp_1";
};
tpdm@4c40000 {
@@ -3985,6 +4000,7 @@ tpdm@4c40000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_gpdsp_0";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -4078,6 +4094,7 @@ tpdm@4c50000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_dl_south";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -4150,6 +4167,7 @@ tpdm@4e00000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_ddr";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -4240,6 +4258,7 @@ tpdm@4e10000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_ddr_ch0";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -4283,6 +4302,7 @@ tpdm@4e20000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_ddr_ch1";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -4608,6 +4628,7 @@ cti@682b000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_apss";
};
tpdm@6860000 {
@@ -4616,6 +4637,7 @@ tpdm@6860000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_actpm";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -4635,6 +4657,7 @@ tpdm@6861000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_apss";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -4715,6 +4738,7 @@ tpdm@68a0000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_llm_gold";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -4734,6 +4758,7 @@ tpdm@68b0000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_llm_silver";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -4753,6 +4778,7 @@ tpdm@68c0000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_ext_dsb";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -4772,6 +4798,7 @@ cti@68e0000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_llm_gold";
};
cti@68f0000 {
@@ -4780,6 +4807,7 @@ cti@68f0000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_llm_silver";
};
cti@6900000 {
@@ -4788,6 +4816,7 @@ cti@6900000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_ext_dsb";
};
sdhc_1: mmc@87c4000 {
--
2.34.1
^ permalink raw reply related
* [PATCH 4/7] arm64: dts: qcom: kodiak: Add label properties to CoreSight devices
From: Jie Gan @ 2026-04-10 3:08 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang
Cc: linux-arm-msm, devicetree, linux-kernel, Jie Gan
In-Reply-To: <20260410-add-label-to-coresight-device-v1-0-d71a6759dbc2@oss.qualcomm.com>
Add label properties to TPDM and CTI nodes in the kodiak device tree to
provide human-readable identifiers for each CoreSight device. These
labels allow userspace tools and the CoreSight framework to identify
devices by name rather than by base address.
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/kodiak.dtsi | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
index 988ca5f7c8a0..3a2c28752e31 100644
--- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
+++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
@@ -3513,6 +3513,7 @@ tpdm@600f000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_spdm";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -3532,6 +3533,7 @@ cti@6010000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_qdss";
};
funnel@6041000 {
@@ -3681,6 +3683,7 @@ cti@6b00000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_swao";
};
cti@6b01000 {
@@ -3689,6 +3692,7 @@ cti@6b01000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_swao_1";
};
cti@6b02000 {
@@ -3697,6 +3701,7 @@ cti@6b02000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_swao_2";
};
cti@6b03000 {
@@ -3705,6 +3710,7 @@ cti@6b03000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_swao_3";
};
funnel@6b04000 {
@@ -3859,6 +3865,7 @@ tpdm@6b09000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_0";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -3878,6 +3885,7 @@ tpdm@6b0a000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_1";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -3897,6 +3905,7 @@ tpdm@6b0b000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_2";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -3916,6 +3925,7 @@ tpdm@6b0c000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_3";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -3935,6 +3945,7 @@ tpdm@6b0d000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_1";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -3954,6 +3965,7 @@ cti@6b11000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_aoss";
};
etm@7040000 {
--
2.34.1
^ permalink raw reply related
* [PATCH 5/7] arm64: dts: qcom: kaanapali: Add label properties to CoreSight devices
From: Jie Gan @ 2026-04-10 3:08 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang
Cc: linux-arm-msm, devicetree, linux-kernel, Jie Gan
In-Reply-To: <20260410-add-label-to-coresight-device-v1-0-d71a6759dbc2@oss.qualcomm.com>
Add label properties to TPDM nodes in the kaanapali device tree to
provide human-readable identifiers for each CoreSight device. These
labels allow userspace tools and the CoreSight framework to identify
devices by name rather than by base address.
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/kaanapali.dtsi | 35 +++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
index 7cc326aa1a1a..0d5714ddef9d 100644
--- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
+++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
@@ -4201,6 +4201,7 @@ tpdm@10003000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_dcc";
qcom,cmb-element-bits = <32>;
@@ -4256,6 +4257,7 @@ tpdm@1000f000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_spdm";
qcom,cmb-element-bits = <32>;
@@ -4319,6 +4321,7 @@ tpdm@11000000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_modem_0";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -4407,6 +4410,7 @@ tpdm@1102c000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_gcc";
qcom,dsb-msrs-num = <32>;
@@ -4425,6 +4429,7 @@ tpdm@11180000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_cdsp";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -4444,6 +4449,7 @@ tpdm@11183000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_cdsp_cmsr1";
qcom,dsb-element-bits = <32>;
qcom,cmb-element-bits = <32>;
@@ -4463,6 +4469,7 @@ tpdm@11184000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_cdsp_cmsr2";
qcom,dsb-element-bits = <32>;
qcom,cmb-element-bits = <32>;
@@ -4482,6 +4489,7 @@ tpdm@11185000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_cdsp_dpm1";
qcom,cmb-element-bits = <64>;
@@ -4500,6 +4508,7 @@ tpdm@11186000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_cdsp_dpm2";
qcom,cmb-element-bits = <64>;
@@ -4619,6 +4628,7 @@ tpdm@111a3000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_pmu";
qcom,dsb-msrs-num = <32>;
@@ -4637,6 +4647,7 @@ tpdm@111a4000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_qrng";
out-ports {
port {
@@ -4653,6 +4664,7 @@ tpdm@111a5000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_dlmm";
qcom,dsb-msrs-num = <32>;
@@ -4671,6 +4683,7 @@ tpdm@111a6000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_north_dsb";
qcom,dsb-msrs-num = <32>;
@@ -4689,6 +4702,7 @@ tpdm@111a7000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_south_dsb";
qcom,dsb-msrs-num = <32>;
@@ -4707,6 +4721,7 @@ tpdm@111a8000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_rdpm_cx";
out-ports {
port {
@@ -4723,6 +4738,7 @@ tpdm@111a9000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_rdpm_mxa";
out-ports {
port {
@@ -4739,6 +4755,7 @@ tpdm@111aa000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_rdpm_mxc";
out-ports {
port {
@@ -4755,6 +4772,7 @@ tpdm@111ab000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_ipcc_cmb0";
out-ports {
port {
@@ -4771,6 +4789,7 @@ tpdm@111ac000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_ipcc_cmb1";
out-ports {
port {
@@ -4787,6 +4806,7 @@ tpdm@111ad000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_ipcc_cmb2";
out-ports {
port {
@@ -4803,6 +4823,7 @@ tpdm@111ae000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_ipcc_cmb3";
out-ports {
port {
@@ -4819,6 +4840,7 @@ tpdm@111af000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_ipcc_cmb4";
out-ports {
port {
@@ -4835,6 +4857,7 @@ tpdm@111b3000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_pcie_rscc";
out-ports {
port {
@@ -5024,6 +5047,7 @@ tpdm@111d0000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_qm";
out-ports {
port {
@@ -5040,6 +5064,7 @@ tpdm@11303000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_4";
qcom,cmb-element-bits = <64>;
@@ -5181,6 +5206,7 @@ tpdm@11309000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_0";
qcom,cmb-element-bits = <64>;
@@ -5199,6 +5225,7 @@ tpdm@1130a000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_1";
qcom,cmb-element-bits = <64>;
@@ -5217,6 +5244,7 @@ tpdm@1130b000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_2";
qcom,cmb-element-bits = <64>;
@@ -5235,6 +5263,7 @@ tpdm@1130c000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_3";
qcom,cmb-element-bits = <64>;
@@ -5253,6 +5282,7 @@ tpdm@1130d000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_1";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -5272,6 +5302,7 @@ tpdm@11422000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_ipa";
qcom,dsb-msrs-num = <32>;
@@ -6958,6 +6989,7 @@ timer {
tpdm-cdsp-llm {
compatible = "qcom,coresight-static-tpdm";
+ label = "tpdm_cdsp_llm";
qcom,cmb-element-bits = <32>;
out-ports {
@@ -6971,6 +7003,7 @@ tpdm_cdsp_llm_out: endpoint {
tpdm-cdsp-llm2 {
compatible = "qcom,coresight-static-tpdm";
+ label = "tpdm_cdsp_llm2";
qcom,cmb-element-bits = <32>;
out-ports {
@@ -6984,6 +7017,7 @@ tpdm_cdsp_llm2_out: endpoint {
tpdm-modem1 {
compatible = "qcom,coresight-static-tpdm";
+ label = "tpdm_modem_1";
qcom,cmb-element-bits = <32>;
out-ports {
@@ -6997,6 +7031,7 @@ tpdm_modem1_out: endpoint {
tpdm-modem2 {
compatible = "qcom,coresight-static-tpdm";
+ label = "tpdm_modem_2";
qcom,cmb-element-bits = <64>;
out-ports {
--
2.34.1
^ permalink raw reply related
* [PATCH 6/7] arm64: dts: qcom: sm8750: Add label properties to CoreSight devices
From: Jie Gan @ 2026-04-10 3:08 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang
Cc: linux-arm-msm, devicetree, linux-kernel, Jie Gan
In-Reply-To: <20260410-add-label-to-coresight-device-v1-0-d71a6759dbc2@oss.qualcomm.com>
Add label properties to TPDM and CTI nodes in the sm8750 device tree to
provide human-readable identifiers for each CoreSight device. These
labels allow userspace tools and the CoreSight framework to identify
devices by name rather than by base address.
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/sm8750.dtsi | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8750.dtsi b/arch/arm64/boot/dts/qcom/sm8750.dtsi
index 18fb52c14acd..c13e9a6bc68e 100644
--- a/arch/arm64/boot/dts/qcom/sm8750.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8750.dtsi
@@ -4112,6 +4112,7 @@ tpdm@1000f000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_spdm";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -4176,6 +4177,7 @@ tpdm@10800000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_modem_0";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -4256,6 +4258,7 @@ cti@1080b000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_mss_qdsp6";
};
tpdm@1082c000 {
@@ -4264,6 +4267,7 @@ tpdm@1082c000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_gcc";
qcom,dsb-msrs-num = <32>;
@@ -4282,6 +4286,7 @@ tpdm@10841000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_prng";
qcom,cmb-msrs-num = <32>;
@@ -4300,6 +4305,7 @@ tpdm@1084e000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_mm_bcv";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -4319,6 +4325,7 @@ tpdm@1084f000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_mm_lmh";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -4338,6 +4345,7 @@ tpdm@10850000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_mm_dpm";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -4402,6 +4410,7 @@ tpdm@10980000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_cdsp";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -4490,6 +4499,7 @@ cti@1098b000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_cdsp_qdsp";
};
tpdm@109a3000 {
@@ -4498,6 +4508,7 @@ tpdm@109a3000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_pmu";
qcom,cmb-msrs-num = <32>;
qcom,dsb-msrs-num = <32>;
@@ -4517,6 +4528,7 @@ tpdm@109a4000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_ipcc";
qcom,cmb-msrs-num = <32>;
@@ -4535,6 +4547,7 @@ tpdm@109a5000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_dlmm";
qcom,dsb-msrs-num = <32>;
@@ -4553,6 +4566,7 @@ tpdm@109a6000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_north_dsb";
qcom,dsb-msrs-num = <32>;
@@ -4571,6 +4585,7 @@ tpdm@109a7000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_south_dsb";
qcom,dsb-msrs-num = <32>;
@@ -4589,6 +4604,7 @@ tpdm@109a8000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_rdpm_cmb0";
qcom,cmb-msrs-num = <32>;
@@ -4607,6 +4623,7 @@ tpdm@109a9000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_rdpm_cmb1";
qcom,cmb-msrs-num = <32>;
@@ -4625,6 +4642,7 @@ tpdm@109aa000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_rdpm_cmb2";
qcom,cmb-msrs-num = <32>;
@@ -4776,6 +4794,7 @@ tpdm@109d0000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_qm";
qcom,dsb-msrs-num = <32>;
@@ -4909,6 +4928,7 @@ tpdm@10b09000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_0";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -4928,6 +4948,7 @@ tpdm@10b0a000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_1";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -4947,6 +4968,7 @@ tpdm@10b0b000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_2";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -4966,6 +4988,7 @@ tpdm@10b0c000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_3";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -4985,6 +5008,7 @@ tpdm@10b0d000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_1";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -6801,6 +6825,7 @@ timer {
tpdm-cdsp-llm {
compatible = "qcom,coresight-static-tpdm";
+ label = "tpdm_cdsp_llm";
qcom,cmb-element-bits = <32>;
out-ports {
@@ -6814,6 +6839,7 @@ tpdm_cdsp_llm_out: endpoint {
tpdm-cdsp-llm2 {
compatible = "qcom,coresight-static-tpdm";
+ label = "tpdm_cdsp_llm2";
qcom,cmb-element-bits = <32>;
out-ports {
@@ -6827,6 +6853,7 @@ tpdm_cdsp_llm2_out: endpoint {
tpdm-modem1 {
compatible = "qcom,coresight-static-tpdm";
+ label = "tpdm_modem_1";
qcom,dsb-element-bits = <32>;
out-ports {
--
2.34.1
^ permalink raw reply related
* [PATCH 7/7] arm64: dts: qcom: hamoa: Add label properties to CoreSight devices
From: Jie Gan @ 2026-04-10 3:08 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang
Cc: linux-arm-msm, devicetree, linux-kernel, Jie Gan
In-Reply-To: <20260410-add-label-to-coresight-device-v1-0-d71a6759dbc2@oss.qualcomm.com>
Add label properties to TPDM and CTI nodes in the hamoa device tree to
provide human-readable identifiers for each CoreSight device. These
labels allow userspace tools and the CoreSight framework to identify
devices by name rather than by base address.
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/hamoa.dtsi | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
index 051dee076416..f10af9db8bd4 100644
--- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
+++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
@@ -6882,6 +6882,7 @@ tpdm@10003000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_dcc";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -6939,6 +6940,7 @@ tpdm@1000f000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_spdm";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -7077,6 +7079,7 @@ tpdm@10800000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_rpdm_mxa";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -7096,6 +7099,7 @@ tpdm@1082c000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_gcc";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -7115,6 +7119,7 @@ tpdm@10841000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_prng";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -7134,6 +7139,7 @@ tpdm@10844000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_lpass";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -7177,6 +7183,7 @@ cti@1098b000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_cdsp_cscti";
};
tpdm@109d0000 {
@@ -7185,6 +7192,7 @@ tpdm@109d0000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_qm";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -7205,6 +7213,7 @@ tpdm@10ac0000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_dl_south_0";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -7225,6 +7234,7 @@ tpdm@10ac1000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_dl_south_1";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -7459,6 +7469,7 @@ tpdm@10b09000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_0";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -7478,6 +7489,7 @@ tpdm@10b0a000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_1";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -7497,6 +7509,7 @@ tpdm@10b0b000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_2";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -7516,6 +7529,7 @@ tpdm@10b0c000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_3";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -7535,6 +7549,7 @@ tpdm@10b0d000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_1";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -7554,6 +7569,7 @@ tpdm@10b20000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_ddr_lpi";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -7624,6 +7640,7 @@ tpdm@10c08000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_dlmm";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -7672,6 +7689,7 @@ tpdm@10c28000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_dlct";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -7691,6 +7709,7 @@ tpdm@10c29000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_ipcc";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -7824,6 +7843,7 @@ tpdm@10c38000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_rdpm";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -7843,6 +7863,7 @@ tpdm@10c39000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_rdpm_mx";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -7939,6 +7960,7 @@ tpdm@10cc1000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_tmess_0";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -8043,6 +8065,7 @@ tpdm@10d08000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_llcc_0";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -8062,6 +8085,7 @@ tpdm@10d09000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_llcc_1";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -8081,6 +8105,7 @@ tpdm@10d0a000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_llcc_2";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -8100,6 +8125,7 @@ tpdm@10d0b000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_llcc_3";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -8119,6 +8145,7 @@ tpdm@10d0c000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_llcc_4";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -8138,6 +8165,7 @@ tpdm@10d0d000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_llcc_5";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -8157,6 +8185,7 @@ tpdm@10d0e000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_llcc_6";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -8176,6 +8205,7 @@ tpdm@10d0f000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_llcc_7";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
--
2.34.1
^ permalink raw reply related
* Re: [net-next,PATCH v6 1/3] dt-bindings: net: realtek,rtl82xx: Keep property list sorted
From: patchwork-bot+netdevbpf @ 2026-04-10 3:10 UTC (permalink / raw)
To: Marek Vasut
Cc: netdev, robh, davem, olek2, andrew, conor+dt, edumazet,
f.fainelli, hkallweit1, ivan.galkin, kuba, krzk+dt, michael,
pabeni, linux, vladimir.oltean, devicetree
In-Reply-To: <20260405233008.148974-1-marek.vasut@mailbox.org>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 6 Apr 2026 01:29:56 +0200 you wrote:
> Sort the documented properties alphabetically, no functional change.
>
> Acked-by: Rob Herring (Arm) <robh@kernel.org>
> Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
> ---
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Aleksander Jan Bajkowski <olek2@wp.pl>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Florian Fainelli <f.fainelli@gmail.com>
> Cc: Heiner Kallweit <hkallweit1@gmail.com>
> Cc: Ivan Galkin <ivan.galkin@axis.com>
> Cc: Jakub Kicinski <kuba@kernel.org>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Michael Klein <michael@fossekall.de>
> Cc: Paolo Abeni <pabeni@redhat.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: Vladimir Oltean <vladimir.oltean@nxp.com>
> Cc: devicetree@vger.kernel.org
> Cc: netdev@vger.kernel.org
>
> [...]
Here is the summary with links:
- [net-next,v6,1/3] dt-bindings: net: realtek,rtl82xx: Keep property list sorted
https://git.kernel.org/netdev/net-next/c/4de7a8acd18e
- [net-next,v6,2/3] dt-bindings: net: realtek,rtl82xx: Document realtek,*-ssc-enable property
https://git.kernel.org/netdev/net-next/c/bfb859a5cb49
- [net-next,v6,3/3] net: phy: realtek: Add property to enable SSC
https://git.kernel.org/netdev/net-next/c/84c5a3f00084
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [PATCH v4 0/3] thermal: spacemit: Add support for SpacemiT K1 SoC thermal sensor
From: Shuwei Wu @ 2026-04-10 3:31 UTC (permalink / raw)
To: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Yixun Lan,
Shuwei Wu, Philipp Zabel, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti
Cc: linux-pm, devicetree, linux-riscv, spacemit, linux-kernel,
Krzysztof Kozlowski, Vincent Legoll, Gong Shuai, Anand Moon,
Troy Mitchell, Yao Zi
Introduce support for the on-die thermal sensor found
on the SpacemiT K1 SoC.
Include the device tree binding documentation in YAML format, the
thermal sensor driver implementation, and the device tree changes to
enable the sensor on K1 SoC.
---
Changes in v4:
- Add 'depends on THERMAL_OF' in Kconfig to ensure functional dependency
- Link to v3: https://lore.kernel.org/spacemit/20260119-patchv2-k1-thermal-v3-0-3d82c9ebe8a4@163.com/
Changes in v3:
- Fix indentation and variable types
- Simplify clock management and redundant assignments
- Link to v2: https://lore.kernel.org/r/20251216-patchv2-k1-thermal-v1-0-d4b31fe9c904@163.com
Changes in v2:
- Move driver to drivers/thermal/spacemit/ and update Kconfig/Makefile
- Address reviewer feedback on style and structure
- Improve variable naming and comments
- Link to v1: https://lore.kernel.org/r/20251127-b4-k1-thermal-v1-0-f32ce47b1aba@163.com
Signed-off-by: Shuwei Wu <shuwei.wu@mailbox.org>
---
Shuwei Wu (3):
dt-bindings: thermal: Add SpacemiT K1 thermal sensor
thermal: spacemit: k1: Add thermal sensor support
riscv: dts: spacemit: Add thermal sensor for K1 SoC
.../bindings/thermal/spacemit,k1-tsensor.yaml | 76 ++++++
arch/riscv/boot/dts/spacemit/k1.dtsi | 101 ++++++++
drivers/thermal/Kconfig | 2 +
drivers/thermal/Makefile | 1 +
drivers/thermal/spacemit/Kconfig | 19 ++
drivers/thermal/spacemit/Makefile | 3 +
drivers/thermal/spacemit/k1_tsensor.c | 281 +++++++++++++++++++++
7 files changed, 483 insertions(+)
---
base-commit: a55f7f5f29b32c2c53cc291899cf9b0c25a07f7c
change-id: 20260409-k1-thermal-fa1a6bc8b65e
Best regards,
--
Shuwei Wu <shuwei.wu@mailbox.org>
^ permalink raw reply
* [PATCH v4 1/3] dt-bindings: thermal: Add SpacemiT K1 thermal sensor
From: Shuwei Wu @ 2026-04-10 3:31 UTC (permalink / raw)
To: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Yixun Lan,
Shuwei Wu, Philipp Zabel, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti
Cc: linux-pm, devicetree, linux-riscv, spacemit, linux-kernel,
Krzysztof Kozlowski, Vincent Legoll, Gong Shuai
In-Reply-To: <20260410-k1-thermal-v1-0-12c87dd063c3@mailbox.org>
Document the SpacemiT K1 Thermal Sensor, which supports
monitoring temperatures for five zones: soc, package, gpu, cluster0,
and cluster1.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Shuwei Wu <shuwei.wu@mailbox.org>
Tested-by: Vincent Legoll <legoll@online.fr> # OrangePi-RV2
Tested-by: Gong Shuai <gsh517025@gmail.com>
---
Changes in v2:
- Rename binding file to spacemit,k1-tsensor.yaml and update compatible
---
.../bindings/thermal/spacemit,k1-tsensor.yaml | 76 ++++++++++++++++++++++
1 file changed, 76 insertions(+)
diff --git a/Documentation/devicetree/bindings/thermal/spacemit,k1-tsensor.yaml b/Documentation/devicetree/bindings/thermal/spacemit,k1-tsensor.yaml
new file mode 100644
index 000000000000..6dad76a7dd36
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/spacemit,k1-tsensor.yaml
@@ -0,0 +1,76 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/thermal/spacemit,k1-tsensor.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SpacemiT K1 Thermal Sensor
+
+description:
+ The SpacemiT K1 Thermal Sensor monitors the temperature of the SoC
+ using multiple internal sensors (e.g., soc, package, gpu, clusters).
+
+maintainers:
+ - Shuwei Wu <shuwei.wu@mailbox.org>
+
+$ref: thermal-sensor.yaml#
+
+properties:
+ compatible:
+ const: spacemit,k1-tsensor
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Core clock for thermal sensor
+ - description: Bus clock for thermal sensor
+
+ clock-names:
+ items:
+ - const: core
+ - const: bus
+
+ interrupts:
+ maxItems: 1
+
+ resets:
+ items:
+ - description: Reset for the thermal sensor
+
+ "#thermal-sensor-cells":
+ const: 1
+ description:
+ The first cell indicates the sensor ID.
+ 0 = soc
+ 1 = package
+ 2 = gpu
+ 3 = cluster0
+ 4 = cluster1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+ - resets
+ - "#thermal-sensor-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/spacemit,k1-syscon.h>
+
+ thermal@d4018000 {
+ compatible = "spacemit,k1-tsensor";
+ reg = <0xd4018000 0x100>;
+ clocks = <&syscon_apbc CLK_TSEN>,
+ <&syscon_apbc CLK_TSEN_BUS>;
+ clock-names = "core", "bus";
+ interrupts = <61>;
+ resets = <&syscon_apbc RESET_TSEN>;
+ #thermal-sensor-cells = <1>;
+ };
--
2.53.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox