* RE: (subset) [PATCH v10 0/5] Add MIPI CSI-2 support for i.MX8ULP
From: G.N. Zhou (OSS) @ 2026-03-27 3:07 UTC (permalink / raw)
To: Frank Li, Rui Miguel Silva, Laurent Pinchart, Martin Kepplinger,
Purism Kernel Team, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Philipp Zabel,
G.N. Zhou (OSS)
Cc: linux-media@vger.kernel.org, devicetree@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Conor Dooley
In-Reply-To: <acVXhxohG8RS67_U@lizhi-Precision-Tower-5810>
Hi Frank,
> -----Original Message-----
> From: Frank Li <frank.li@nxp.com>
> Sent: Thursday, March 26, 2026 11:58 PM
> To: Rui Miguel Silva <rmfrfs@gmail.com>; Laurent Pinchart
> <laurent.pinchart@ideasonboard.com>; Martin Kepplinger
> <martink@posteo.de>; Purism Kernel Team <kernel@puri.sm>; Mauro
> Carvalho Chehab <mchehab@kernel.org>; Rob Herring <robh@kernel.org>;
> Krzysztof Kozlowski <krzk+dt@kernel.org>; Conor Dooley
> <conor+dt@kernel.org>; Shawn Guo <shawnguo@kernel.org>; Sascha Hauer
> <s.hauer@pengutronix.de>; Pengutronix Kernel Team
> <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>; Philipp
> Zabel <p.zabel@pengutronix.de>; G.N. Zhou (OSS)
> <guoniu.zhou@oss.nxp.com>
> Cc: linux-media@vger.kernel.org; devicetree@vger.kernel.org;
> imx@lists.linux.dev; linux-arm-kernel@lists.infradead.org; linux-
> kernel@vger.kernel.org; Conor Dooley <conor.dooley@microchip.com>
> Subject: Re: (subset) [PATCH v10 0/5] Add MIPI CSI-2 support for i.MX8ULP
>
> On Thu, Mar 26, 2026 at 11:20:54AM -0400, Frank Li wrote:
> >
> > On Fri, 05 Dec 2025 17:07:42 +0800, Guoniu Zhou wrote:
> > > The serial adds MIPI CSI-2 support for i.MX8ULP.
> > >
> > >
> >
> > Applied, thanks!
> >
> > [5/5] arm64: dts: imx8ulp: Add CSI and ISI Nodes
> > commit: 73f3ca0f85285b2fc4ea05affb9a44bf899cd595
> >
> > Add extra empty line between reg and child node.
>
> Guoniu Zhou:
>
> I have to drop this one because miss <dt-bindings/reset/imx8ulp-pcc-reset.h>
>
> Do you miss some dependence?
Thanks for reporting this issue. You're right that this patch was based on a
tree that still contained include/dt-bindings/reset/imx8ulp-pcc-reset.h.
However, Rob's recent series [1] removed this header file as part of the
dt-bindings cleanup work. I'll send a new version that addresses this change.
[1] https://lore.kernel.org/all/20251212231203.727227-1-robh@kernel.org/
>
> Frank
> >
> > Best regards,
> > --
> > Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* [PATCH v2 3/3] remoteproc: imx_rproc: Add support for i.MX94
From: Peng Fan (OSS) @ 2026-03-27 2:42 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Daniel Baluta
Cc: linux-remoteproc, devicetree, imx, linux-arm-kernel, linux-kernel,
Peng Fan
In-Reply-To: <20260327-imx943-rproc-v2-0-a547a3588730@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
Add basic remoteproc support for the i.MX94 M-core processors, including
address translation tables(dev addr is from view of remote processor,
sys addr is from view of main processor) and device configuration data for
the CM70, CM71, and CM33S cores.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
drivers/remoteproc/imx_rproc.c | 71 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 71 insertions(+)
diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index d8ead42640881bd523d605fa7002935ef6e98077..525a92e03e8ab540697a3ef1f593b079f55e10ee 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -145,6 +145,47 @@ static const struct imx_rproc_att imx_rproc_att_imx95_m7[] = {
{ 0x80000000, 0x80000000, 0x50000000, 0 },
};
+static const struct imx_rproc_att imx_rproc_att_imx94_m70[] = {
+ /* dev addr , sys addr , size , flags */
+ /* TCM CODE NON-SECURE */
+ { 0x00000000, 0x203C0000, 0x00040000, ATT_OWN | ATT_IOMEM },
+ /* TCM SYS NON-SECURE*/
+ { 0x20000000, 0x20400000, 0x00040000, ATT_OWN | ATT_IOMEM },
+
+ /* DDR */
+ { 0x80000000, 0x80000000, 0x50000000, 0 },
+};
+
+static const struct imx_rproc_att imx_rproc_att_imx94_m71[] = {
+ /* dev addr , sys addr , size , flags */
+ /* TCM CODE NON-SECURE */
+ { 0x00000000, 0x202C0000, 0x00040000, ATT_OWN | ATT_IOMEM },
+ /* TCM SYS NON-SECURE*/
+ { 0x20000000, 0x20300000, 0x00040000, ATT_OWN | ATT_IOMEM },
+
+ /* DDR */
+ { 0x80000000, 0x80000000, 0x50000000, 0 },
+};
+
+static const struct imx_rproc_att imx_rproc_att_imx94_m33s[] = {
+ /* dev addr , sys addr , size , flags */
+ /* TCM CODE NON-SECURE */
+ { 0x0FFC0000, 0x209C0000, 0x00040000, ATT_OWN | ATT_IOMEM },
+ /* TCM CODE SECURE */
+ { 0x1FFC0000, 0x209C0000, 0x00040000, ATT_OWN | ATT_IOMEM },
+
+ /* TCM SYS NON-SECURE */
+ { 0x20000000, 0x20A00000, 0x00040000, ATT_OWN | ATT_IOMEM },
+ /* TCM SYS SECURE */
+ { 0x30000000, 0x20A00000, 0x00040000, ATT_OWN | ATT_IOMEM },
+
+ /* M33S OCRAM */
+ { 0x20800000, 0x20800000, 0x180000, ATT_OWN | ATT_IOMEM },
+
+ /* DDR */
+ { 0x80000000, 0x80000000, 0x50000000, 0 },
+};
+
static const struct imx_rproc_att imx_rproc_att_imx93[] = {
/* dev addr , sys addr , size , flags */
/* TCM CODE NON-SECURE */
@@ -1466,6 +1507,33 @@ static const struct imx_rproc_dcfg imx_rproc_cfg_imx93 = {
.flags = IMX_RPROC_NEED_CLKS,
};
+static const struct imx_rproc_dcfg imx_rproc_cfg_imx94_m70 = {
+ .att = imx_rproc_att_imx94_m70,
+ .att_size = ARRAY_SIZE(imx_rproc_att_imx94_m70),
+ .ops = &imx_rproc_ops_sm_lmm,
+ .cpuid = 1,
+ .lmid = 2,
+ .reset_vector_mask = GENMASK_U32(31, 16),
+};
+
+static const struct imx_rproc_dcfg imx_rproc_cfg_imx94_m71 = {
+ .att = imx_rproc_att_imx94_m71,
+ .att_size = ARRAY_SIZE(imx_rproc_att_imx94_m71),
+ .ops = &imx_rproc_ops_sm_lmm,
+ .cpuid = 7,
+ .lmid = 3,
+ .reset_vector_mask = GENMASK_U32(31, 16),
+};
+
+static const struct imx_rproc_dcfg imx_rproc_cfg_imx94_m33s = {
+ .att = imx_rproc_att_imx94_m33s,
+ .att_size = ARRAY_SIZE(imx_rproc_att_imx94_m33s),
+ .ops = &imx_rproc_ops_sm_lmm,
+ .cpuid = 8,
+ .lmid = 1,
+ .reset_vector_mask = GENMASK_U32(31, 16),
+};
+
static const struct imx_rproc_dcfg imx_rproc_cfg_imx95_m7 = {
.att = imx_rproc_att_imx95_m7,
.att_size = ARRAY_SIZE(imx_rproc_att_imx95_m7),
@@ -1489,6 +1557,9 @@ static const struct of_device_id imx_rproc_of_match[] = {
{ .compatible = "fsl,imx8qm-cm4", .data = &imx_rproc_cfg_imx8qm },
{ .compatible = "fsl,imx8ulp-cm33", .data = &imx_rproc_cfg_imx8ulp },
{ .compatible = "fsl,imx93-cm33", .data = &imx_rproc_cfg_imx93 },
+ { .compatible = "fsl,imx94-cm70", .data = &imx_rproc_cfg_imx94_m70 },
+ { .compatible = "fsl,imx94-cm71", .data = &imx_rproc_cfg_imx94_m71 },
+ { .compatible = "fsl,imx94-cm33s", .data = &imx_rproc_cfg_imx94_m33s },
{ .compatible = "fsl,imx95-cm7", .data = &imx_rproc_cfg_imx95_m7 },
{},
};
--
2.37.1
^ permalink raw reply related
* [PATCH v2 2/3] remoteproc: imx_rproc: Pass bootaddr to SM CPU/LMM reset vector
From: Peng Fan (OSS) @ 2026-03-27 2:42 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Daniel Baluta
Cc: linux-remoteproc, devicetree, imx, linux-arm-kernel, linux-kernel,
Peng Fan
In-Reply-To: <20260327-imx943-rproc-v2-0-a547a3588730@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
Cortex-M[7,33] processors use a fixed reset vector table format:
0x00 Initial SP value
0x04 Reset vector
0x08 NMI
0x0C ...
...
IRQ[n]
In ELF images, the corresponding layout is:
reset_vectors: --> hardware reset address
.word __stack_end__
.word Reset_Handler
.word NMI_Handler
.word HardFault_Handler
...
.word UART_IRQHandler
.word SPI_IRQHandler
...
Reset_Handler: --> ELF entry point address
...
The hardware fetches the first two words from reset_vectors and populates
SP with __stack_end__ and PC with Reset_Handler. Execution proceeds from
Reset_Handler.
However, the ELF entry point does not always match the hardware reset
address. For example, on i.MX94 CM33S:
ELF entry point: 0x0ffc211d
hardware reset base: 0x0ffc0000 (default reset value, sw programmable)
To derive the correct hardware reset address, the unused lower bits must
be masked off. The boot code should apply a SoC-specific mask before
programming the reset address registers, e.g.:
reset_address = entry & reset_vector_mask
Current driver always programs the reset vector as 0. But i.MX94 CM33S's
default reset base is 0x0ffc0000, so the correct reset vector must be
passed to the SM API; otherwise the M33 Sync core cannot boot successfully.
rproc_elf_get_boot_addr() returns the ELF entry point, which is not the
hardware reset vector address. To derive the proper reset vector, this
patch introduces imx_rproc_get_boot_addr(), which masks the ELF entry
point using the SoC‑specific 'reset_vector_mask'. The resulting reset
vector address is then passed to the SM CPU/LMM reset vector API calls.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
drivers/remoteproc/imx_rproc.c | 17 ++++++++++++++---
drivers/remoteproc/imx_rproc.h | 2 ++
2 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 0dd80e688b0ea3df4c66e5726884dc86c8a5a881..d8ead42640881bd523d605fa7002935ef6e98077 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -345,7 +345,7 @@ static int imx_rproc_sm_cpu_start(struct rproc *rproc)
const struct imx_rproc_dcfg *dcfg = priv->dcfg;
int ret;
- ret = scmi_imx_cpu_reset_vector_set(dcfg->cpuid, 0, true, false, false);
+ ret = scmi_imx_cpu_reset_vector_set(dcfg->cpuid, rproc->bootaddr, true, false, false);
if (ret) {
dev_err(priv->dev, "Failed to set reset vector cpuid(%u): %d\n", dcfg->cpuid, ret);
return ret;
@@ -365,7 +365,7 @@ static int imx_rproc_sm_lmm_start(struct rproc *rproc)
* If the remoteproc core can't start the M7, it will already be
* handled in imx_rproc_sm_lmm_prepare().
*/
- ret = scmi_imx_lmm_reset_vector_set(dcfg->lmid, dcfg->cpuid, 0, 0);
+ ret = scmi_imx_lmm_reset_vector_set(dcfg->lmid, dcfg->cpuid, 0, rproc->bootaddr);
if (ret) {
dev_err(dev, "Failed to set reset vector lmid(%u), cpuid(%u): %d\n",
dcfg->lmid, dcfg->cpuid, ret);
@@ -739,6 +739,17 @@ imx_rproc_elf_find_loaded_rsc_table(struct rproc *rproc, const struct firmware *
return rproc_elf_find_loaded_rsc_table(rproc, fw);
}
+static u64 imx_rproc_get_boot_addr(struct rproc *rproc, const struct firmware *fw)
+{
+ struct imx_rproc *priv = rproc->priv;
+ u32 reset_vector_mask = GENMASK_U32(31, 0);
+
+ if (priv->dcfg->reset_vector_mask)
+ reset_vector_mask = priv->dcfg->reset_vector_mask;
+
+ return rproc_elf_get_boot_addr(rproc, fw) & reset_vector_mask;
+}
+
static const struct rproc_ops imx_rproc_ops = {
.prepare = imx_rproc_prepare,
.attach = imx_rproc_attach,
@@ -752,7 +763,7 @@ static const struct rproc_ops imx_rproc_ops = {
.find_loaded_rsc_table = imx_rproc_elf_find_loaded_rsc_table,
.get_loaded_rsc_table = imx_rproc_get_loaded_rsc_table,
.sanity_check = rproc_elf_sanity_check,
- .get_boot_addr = rproc_elf_get_boot_addr,
+ .get_boot_addr = imx_rproc_get_boot_addr,
};
static int imx_rproc_addr_init(struct imx_rproc *priv,
diff --git a/drivers/remoteproc/imx_rproc.h b/drivers/remoteproc/imx_rproc.h
index d37e6f90548cec727b4aeb874680b42af85bdbb4..0d7d48352a1091ad24e8e083172ce6da6d26ae10 100644
--- a/drivers/remoteproc/imx_rproc.h
+++ b/drivers/remoteproc/imx_rproc.h
@@ -41,6 +41,8 @@ struct imx_rproc_dcfg {
/* For System Manager(SM) based SoCs */
u32 cpuid; /* ID of the remote core */
u32 lmid; /* ID of the Logcial Machine */
+ /* reset_vector = elf_entry_addr & reset_vector_mask */
+ u32 reset_vector_mask;
};
#endif /* _IMX_RPROC_H */
--
2.37.1
^ permalink raw reply related
* [PATCH v2 1/3] dt-bindings: remoteproc: imx-rproc: Support i.MX94
From: Peng Fan (OSS) @ 2026-03-27 2:42 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Daniel Baluta
Cc: linux-remoteproc, devicetree, imx, linux-arm-kernel, linux-kernel,
Peng Fan
In-Reply-To: <20260327-imx943-rproc-v2-0-a547a3588730@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
Add compatible string for:
Cortex-M7 core[0,1] in i.MX94
Cortex-M33 Sync core in i.MX94
To i.MX94, Cortex-M7 core0 and core1 have different memory view from
Cortex-A55 core, so different compatible string is used.
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
index ce8ec0119469c8fc0979a192b6e3d3a03108d7d2..c18f71b648890da9c25a2f3309d8dbec5bb8d226 100644
--- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
@@ -28,6 +28,9 @@ properties:
- fsl,imx8qxp-cm4
- fsl,imx8ulp-cm33
- fsl,imx93-cm33
+ - fsl,imx94-cm33s
+ - fsl,imx94-cm70
+ - fsl,imx94-cm71
- fsl,imx95-cm7
clocks:
--
2.37.1
^ permalink raw reply related
* [PATCH v2 0/3] Add i.MX94 remoteproc support and reset vector handling improvements
From: Peng Fan (OSS) @ 2026-03-27 2:42 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Daniel Baluta
Cc: linux-remoteproc, devicetree, imx, linux-arm-kernel, linux-kernel,
Peng Fan
This series adds remoteproc support for the i.MX94 family, including the
CM70, CM71, and CM33S cores, and derive the hardware reset vector for
Cortex‑M processors whose ELF entry point does not directly correspond to
the actual reset address.
Background:
Cortex‑M processors fetch their initial SP and PC from a fixed reset vector
table. While ELF images embed the entry point (e_entry), this value is
not always aligned to the hardware reset address. On platforms such as
i.MX94 CM33S, masking is required to compute the correct reset vector
address before programming the SoC reset registers.
Similarly, on i.MX95, the existing implementation always programs a reset
vector of 0x0, which only works when executing entirely from TCM. When
firmware is loaded into DDR, the driver must pass the correct reset vector
to the SM CPU/LMM interfaces.
Summary of patches:
[1]dt-bindings: remoteproc: imx-rproc: Introduce fsl,reset-vector-mask
Adds a new DT property allowing SoCs to specify a mask for deriving the
hardware reset vector from the ELF entry point.
[2]remoteproc: imx_rproc: Pass bootaddr to SM CPU/LMM reset vector
Ensures the correct reset vector is passed to SM APIs by introducing a
driver‑level helper (imx_rproc_get_boot_addr()) that applies the
reset‑vector mask.
[3]remoteproc: imx_rproc: Add support for i.MX94 remoteproc
Adds address translation tables and configuration data for CM70, CM71,
and CM33S, enabling full remoteproc operation on i.MX94.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
Changes in v2:
- Drop fsl,reset-vector-mask by using fixed value in driver for per device
- Add R-b for i.MX94 dt-binding
- Update commit log to include dev addr and sys addr
- Link to v1: https://lore.kernel.org/r/20260312-imx943-rproc-v1-0-3e66596592a8@nxp.com
---
Peng Fan (3):
dt-bindings: remoteproc: imx-rproc: Support i.MX94
remoteproc: imx_rproc: Pass bootaddr to SM CPU/LMM reset vector
remoteproc: imx_rproc: Add support for i.MX94
.../bindings/remoteproc/fsl,imx-rproc.yaml | 3 +
drivers/remoteproc/imx_rproc.c | 88 +++++++++++++++++++++-
drivers/remoteproc/imx_rproc.h | 2 +
3 files changed, 90 insertions(+), 3 deletions(-)
---
base-commit: a2f31c83962f7f298b2975ab004810f3ac4875dc
change-id: 20260311-imx943-rproc-2050e00b65f7
Best regards,
--
Peng Fan <peng.fan@nxp.com>
^ permalink raw reply
* Re: [PATCH 2/2] dts: riscv: spacemit: k3: Add i2c nodes
From: Yixun Lan @ 2026-03-27 2:39 UTC (permalink / raw)
To: Andi Shyti
Cc: Troy Mitchell, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
linux-i2c, devicetree, linux-riscv, spacemit, linux-kernel
In-Reply-To: <acWxqkR8Z0rwe4hI@zenone.zhora.eu>
Hi Andi,
On 23:23 Thu 26 Mar , Andi Shyti wrote:
> Hi Yixun,
>
> > > + i2c2: i2c@d4012000 {
> > > + compatible = "spacemit,k3-i2c", "spacemit,k1-i2c";
> > > + reg = <0x0 0xd4012000 0x0 0x38>;
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + interrupts = <38 IRQ_TYPE_LEVEL_HIGH>;
> > > + clocks = <&syscon_apbc CLK_APBC_TWSI2>,
> > > + <&syscon_apbc CLK_APBC_TWSI2_BUS>;
> > > + clock-names = "func", "bus";
> > > + clock-frequency = <400000>;
> > > + resets = <&syscon_apbc RESET_APBC_TWSI2>;
> > > + status = "disabled";
> > > + };
> > I think we should add a comment here to explain why there isn't i2c3.
> > Otherwise, LGTM.
>
> are you going to add a comment here?
>
I will explain and re-spin a v2, and add a short comment for this:
- i2c3 is reserved for secure domain which not available from linux
- i2c7 simply does not exist from hardware perspective, K3 SoC want to
keep align with K1 to use same index of I2C controller for the pmic
> > Reviewed-by: Troy Mitchell <troy.mitchell@linux.spacemit.com>
>
--
Yixun Lan (dlan)
^ permalink raw reply
* Re: [PATCH v12 2/7] qcom-tgu: Add TGU driver
From: Jie Gan @ 2026-03-27 2:35 UTC (permalink / raw)
To: Songwei Chai, andersson, alexander.shishkin, mike.leach,
konrad.dybcio, suzuki.poulose, james.clark, krzk+dt, conor+dt
Cc: linux-kernel, linux-arm-kernel, linux-arm-msm, coresight,
devicetree, gregkh
In-Reply-To: <20260317032639.2393221-3-songwei.chai@oss.qualcomm.com>
On 3/17/2026 11:26 AM, Songwei Chai wrote:
> Add driver to support device TGU (Trigger Generation Unit).
> TGU is a Data Engine which can be utilized to sense a plurality of
> signals and create a trigger into the CTI or generate interrupts to
> processors. Add probe/enable/disable functions for tgu.
>
> Signed-off-by: Songwei Chai <songwei.chai@oss.qualcomm.com>
> ---
> .../ABI/testing/sysfs-bus-amba-devices-tgu | 9 +
> drivers/Makefile | 1 +
> drivers/hwtracing/Kconfig | 2 +
> drivers/hwtracing/qcom/Kconfig | 18 ++
> drivers/hwtracing/qcom/Makefile | 3 +
> drivers/hwtracing/qcom/tgu.c | 183 ++++++++++++++++++
> drivers/hwtracing/qcom/tgu.h | 51 +++++
> 7 files changed, 267 insertions(+)
> create mode 100644 Documentation/ABI/testing/sysfs-bus-amba-devices-tgu
> create mode 100644 drivers/hwtracing/qcom/Kconfig
> create mode 100644 drivers/hwtracing/qcom/Makefile
> create mode 100644 drivers/hwtracing/qcom/tgu.c
> create mode 100644 drivers/hwtracing/qcom/tgu.h
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-amba-devices-tgu b/Documentation/ABI/testing/sysfs-bus-amba-devices-tgu
> new file mode 100644
> index 000000000000..ead237bb7d89
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-bus-amba-devices-tgu
> @@ -0,0 +1,9 @@
> +What: /sys/bus/amba/devices/<tgu-name>/enable_tgu
> +Date: March 2026
> +KernelVersion 7.1
missed ":" in all patches.
Thanks,
Jie
> +Contact: Jinlong Mao <jinlong.mao@oss.qualcomm.com>, Songwei Chai <songwei.chai@oss.qualcomm.com>
> +Description:
> + (RW) Set/Get the enable/disable status of TGU
> + Accepts only one of the 2 values - 0 or 1.
> + 0 : disable TGU.
> + 1 : enable TGU.
> diff --git a/drivers/Makefile b/drivers/Makefile
> index 53fbd2e0acdd..82b712a12a26 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -177,6 +177,7 @@ obj-$(CONFIG_RAS) += ras/
> obj-$(CONFIG_USB4) += thunderbolt/
> obj-$(CONFIG_CORESIGHT) += hwtracing/coresight/
> obj-y += hwtracing/intel_th/
> +obj-y += hwtracing/qcom/
> obj-$(CONFIG_STM) += hwtracing/stm/
> obj-$(CONFIG_HISI_PTT) += hwtracing/ptt/
> obj-y += android/
> diff --git a/drivers/hwtracing/Kconfig b/drivers/hwtracing/Kconfig
> index 911ee977103c..8a640218eed8 100644
> --- a/drivers/hwtracing/Kconfig
> +++ b/drivers/hwtracing/Kconfig
> @@ -7,4 +7,6 @@ source "drivers/hwtracing/intel_th/Kconfig"
>
> source "drivers/hwtracing/ptt/Kconfig"
>
> +source "drivers/hwtracing/qcom/Kconfig"
> +
> endmenu
> diff --git a/drivers/hwtracing/qcom/Kconfig b/drivers/hwtracing/qcom/Kconfig
> new file mode 100644
> index 000000000000..d6f6d4b0f28e
> --- /dev/null
> +++ b/drivers/hwtracing/qcom/Kconfig
> @@ -0,0 +1,18 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +#
> +# QCOM specific hwtracing drivers
> +#
> +menu "Qualcomm specific hwtracing drivers"
> +
> +config QCOM_TGU
> + tristate "QCOM Trigger Generation Unit driver"
> + help
> + This driver provides support for Trigger Generation Unit that is
> + used to detect patterns or sequences on a given set of signals.
> + TGU is used to monitor a particular bus within a given region to
> + detect illegal transaction sequences or slave responses. It is also
> + used to monitor a data stream to detect protocol violations and to
> + provide a trigger point for centering data around a specific event
> + within the trace data buffer.
> +
> +endmenu
> diff --git a/drivers/hwtracing/qcom/Makefile b/drivers/hwtracing/qcom/Makefile
> new file mode 100644
> index 000000000000..5a0a868c1ea0
> --- /dev/null
> +++ b/drivers/hwtracing/qcom/Makefile
> @@ -0,0 +1,3 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +obj-$(CONFIG_QCOM_TGU) += tgu.o
> diff --git a/drivers/hwtracing/qcom/tgu.c b/drivers/hwtracing/qcom/tgu.c
> new file mode 100644
> index 000000000000..58c19f12f3d7
> --- /dev/null
> +++ b/drivers/hwtracing/qcom/tgu.c
> @@ -0,0 +1,183 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +#include <linux/amba/bus.h>
> +#include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/pm_runtime.h>
> +
> +#include "tgu.h"
> +
> +static void tgu_write_all_hw_regs(struct tgu_drvdata *drvdata)
> +{
> + TGU_UNLOCK(drvdata->base);
> + /* Enable TGU to program the triggers */
> + writel(1, drvdata->base + TGU_CONTROL);
> + TGU_LOCK(drvdata->base);
> +}
> +
> +static int tgu_enable(struct device *dev)
> +{
> + struct tgu_drvdata *drvdata = dev_get_drvdata(dev);
> +
> + guard(spinlock)(&drvdata->lock);
> + if (drvdata->enabled)
> + return -EBUSY;
> +
> + tgu_write_all_hw_regs(drvdata);
> + drvdata->enabled = true;
> +
> + return 0;
> +}
> +
> +static void tgu_do_disable(struct tgu_drvdata *drvdata)
> +{
> + TGU_UNLOCK(drvdata->base);
> + writel(0, drvdata->base + TGU_CONTROL);
> + TGU_LOCK(drvdata->base);
> +
> + drvdata->enabled = false;
> +}
> +
> +static void tgu_disable(struct device *dev)
> +{
> + struct tgu_drvdata *drvdata = dev_get_drvdata(dev);
> +
> + guard(spinlock)(&drvdata->lock);
> + if (!drvdata->enabled)
> + return;
> +
> + tgu_do_disable(drvdata);
> +}
> +
> +static ssize_t enable_tgu_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct tgu_drvdata *drvdata = dev_get_drvdata(dev);
> + bool enabled;
> +
> + guard(spinlock)(&drvdata->lock);
> + enabled = drvdata->enabled;
> +
> + return sysfs_emit(buf, "%d\n", !!enabled);
> +}
> +
> +/* enable_tgu_store - Configure Trace and Gating Unit (TGU) triggers. */
> +static ssize_t enable_tgu_store(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf,
> + size_t size)
> +{
> + unsigned long val;
> + int ret;
> +
> + ret = kstrtoul(buf, 0, &val);
> + if (ret || val > 1)
> + return -EINVAL;
> +
> + if (val) {
> + ret = pm_runtime_resume_and_get(dev);
> + if (ret)
> + return ret;
> + ret = tgu_enable(dev);
> + if (ret) {
> + pm_runtime_put(dev);
> + return ret;
> + }
> + } else {
> + tgu_disable(dev);
> + pm_runtime_put(dev);
> + }
> +
> + return size;
> +}
> +static DEVICE_ATTR_RW(enable_tgu);
> +
> +static struct attribute *tgu_common_attrs[] = {
> + &dev_attr_enable_tgu.attr,
> + NULL,
> +};
> +
> +static const struct attribute_group tgu_common_grp = {
> + .attrs = tgu_common_attrs,
> + NULL,
> +};
> +
> +static const struct attribute_group *tgu_attr_groups[] = {
> + &tgu_common_grp,
> + NULL,
> +};
> +
> +static int tgu_probe(struct amba_device *adev, const struct amba_id *id)
> +{
> + struct device *dev = &adev->dev;
> + struct tgu_drvdata *drvdata;
> + int ret;
> +
> + drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
> + if (!drvdata)
> + return -ENOMEM;
> +
> + drvdata->dev = &adev->dev;
> + dev_set_drvdata(dev, drvdata);
> +
> + drvdata->base = devm_ioremap_resource(dev, &adev->res);
> + if (IS_ERR(drvdata->base))
> + return PTR_ERR(drvdata->base);
> +
> + spin_lock_init(&drvdata->lock);
> +
> + ret = sysfs_create_groups(&dev->kobj, tgu_attr_groups);
> + if (ret) {
> + dev_err(dev, "failed to create sysfs groups: %d\n", ret);
> + return ret;
> + }
> +
> + drvdata->enabled = false;
> +
> + pm_runtime_put(&adev->dev);
> +
> + return 0;
> +}
> +
> +static void tgu_remove(struct amba_device *adev)
> +{
> + struct device *dev = &adev->dev;
> +
> + sysfs_remove_groups(&dev->kobj, tgu_attr_groups);
> +
> + tgu_disable(dev);
> +}
> +
> +static const struct amba_id tgu_ids[] = {
> + {
> + .id = 0x000f0e00,
> + .mask = 0x000fffff,
> + },
> + { 0, 0, NULL },
> +};
> +
> +MODULE_DEVICE_TABLE(amba, tgu_ids);
> +
> +static struct amba_driver tgu_driver = {
> + .drv = {
> + .name = "qcom-tgu",
> + .suppress_bind_attrs = true,
> + },
> + .probe = tgu_probe,
> + .remove = tgu_remove,
> + .id_table = tgu_ids,
> +};
> +
> +module_amba_driver(tgu_driver);
> +
> +MODULE_AUTHOR("Songwei Chai <songwei.chai@oss.qualcomm.com>");
> +MODULE_AUTHOR("Jinlong Mao <jinlong.mao@oss.qualcomm.com>");
> +MODULE_DESCRIPTION("Qualcomm Trigger Generation Unit driver");
> +MODULE_LICENSE("GPL");
> diff --git a/drivers/hwtracing/qcom/tgu.h b/drivers/hwtracing/qcom/tgu.h
> new file mode 100644
> index 000000000000..dd7533b9d735
> --- /dev/null
> +++ b/drivers/hwtracing/qcom/tgu.h
> @@ -0,0 +1,51 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +#ifndef _QCOM_TGU_H
> +#define _QCOM_TGU_H
> +
> +/* Register addresses */
> +#define TGU_CONTROL 0x0000
> +#define TGU_LAR 0xfb0
> +#define TGU_UNLOCK_OFFSET 0xc5acce55
> +
> +static inline void TGU_LOCK(void __iomem *addr)
> +{
> + do {
> + /* Wait for things to settle */
> + mb();
> + writel_relaxed(0x0, addr + TGU_LAR);
> + } while (0);
> +}
> +
> +static inline void TGU_UNLOCK(void __iomem *addr)
> +{
> + do {
> + writel_relaxed(TGU_UNLOCK_OFFSET, addr + TGU_LAR);
> + /* Make sure everyone has seen this */
> + mb();
> + } while (0);
> +}
> +
> +/**
> + * struct tgu_drvdata - Data structure for a TGU (Trigger Generator Unit)
> + * @base: Memory-mapped base address of the TGU device
> + * @dev: Pointer to the associated device structure
> + * @lock: Spinlock for handling concurrent access to private data
> + * @enabled: Flag indicating whether the TGU device is enabled
> + *
> + * This structure defines the data associated with a TGU device,
> + * including its base address, device pointers, clock, spinlock for
> + * synchronization, trigger data pointers, maximum limits for various
> + * trigger-related parameters, and enable status.
> + */
> +struct tgu_drvdata {
> + void __iomem *base;
> + struct device *dev;
> + spinlock_t lock;
> + bool enabled;
> +};
> +
> +#endif
^ permalink raw reply
* Re: [PATCH v12 7/7] qcom-tgu: Add reset node to initialize
From: Jie Gan @ 2026-03-27 2:26 UTC (permalink / raw)
To: Songwei Chai, andersson, alexander.shishkin, mike.leach,
konrad.dybcio, suzuki.poulose, james.clark, krzk+dt, conor+dt
Cc: linux-kernel, linux-arm-kernel, linux-arm-msm, coresight,
devicetree, gregkh
In-Reply-To: <20260317032639.2393221-8-songwei.chai@oss.qualcomm.com>
On 3/17/2026 11:26 AM, Songwei Chai wrote:
> Add reset node to initialize the value of
> priority/condition_decode/condition_select/timer/counter nodes.
>
> Signed-off-by: Songwei Chai <songwei.chai@oss.qualcomm.com>
> ---
> .../ABI/testing/sysfs-bus-amba-devices-tgu | 7 ++
> drivers/hwtracing/qcom/tgu.c | 77 +++++++++++++++++++
> 2 files changed, 84 insertions(+)
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-amba-devices-tgu b/Documentation/ABI/testing/sysfs-bus-amba-devices-tgu
> index 5370882333bc..1dcb8fb71cd9 100644
> --- a/Documentation/ABI/testing/sysfs-bus-amba-devices-tgu
> +++ b/Documentation/ABI/testing/sysfs-bus-amba-devices-tgu
> @@ -42,3 +42,10 @@ KernelVersion 7.1
> Contact: Jinlong Mao <jinlong.mao@oss.qualcomm.com>, Songwei Chai <songwei.chai@oss.qualcomm.com>
> Description:
> (RW) Set/Get the counter value with specific step for TGU.
> +
> +What: /sys/bus/amba/devices/<tgu-name>/reset_tgu
> +Date: March 2026
> +KernelVersion 7.1
> +Contact: Jinlong Mao <jinlong.mao@oss.qualcomm.com>, Songwei Chai <songwei.chai@oss.qualcomm.com>
> +Description:
> + (Write) Write 1 to reset the dataset for TGU.
> diff --git a/drivers/hwtracing/qcom/tgu.c b/drivers/hwtracing/qcom/tgu.c
> index 4539415571f6..e28e6d27cf56 100644
> --- a/drivers/hwtracing/qcom/tgu.c
> +++ b/drivers/hwtracing/qcom/tgu.c
> @@ -410,8 +410,85 @@ static ssize_t enable_tgu_store(struct device *dev,
> }
> static DEVICE_ATTR_RW(enable_tgu);
>
> +/* reset_tgu_store - Reset Trace and Gating Unit (TGU) configuration. */
> +static ssize_t reset_tgu_store(struct device *dev,
> + struct device_attribute *attr, const char *buf,
> + size_t size)
> +{
> + struct tgu_drvdata *drvdata = dev_get_drvdata(dev);
> + struct value_table *vt = drvdata->value_table;
> + u32 *cond_decode = drvdata->value_table->condition_decode;
> + bool need_pm_put = false;
> + unsigned long value;
> + int i, j, ret;
> +
> + if (kstrtoul(buf, 0, &value) || value != 1)
> + return -EINVAL;
> +
> + spin_lock(&drvdata->lock);
> + if (!drvdata->enabled) {
> + spin_unlock(&drvdata->lock);
> + ret = pm_runtime_resume_and_get(drvdata->dev);
> + if (ret)
> + return ret;
> + need_pm_put = true;
> + spin_lock(&drvdata->lock);
> + }
> +
> + tgu_do_disable(drvdata);
need_pm_put flag is not set when reset a enabled device. I think we also
need do pm_runtime_put after we did tgu_do_disable for an enabled device
because we have pm_runtime_resume_and_get while enabling it.
Thanks,
Jie
> +
> + if (vt->priority) {
> + size_t size = MAX_PRIORITY * drvdata->num_step *
> + drvdata->num_reg * sizeof(unsigned int);
> + memset(vt->priority, 0, size);
> + }
> +
> + if (vt->condition_decode) {
> + size_t size = drvdata->num_condition_decode *
> + drvdata->num_step * sizeof(unsigned int);
> + memset(vt->condition_decode, 0, size);
> + }
> +
> + /* Initialize all condition registers to NOT(value=0x1000000) */
> + for (i = 0; i < drvdata->num_step; i++) {
> + for (j = 0; j < drvdata->num_condition_decode; j++) {
> + cond_decode[calculate_array_location(drvdata, i,
> + TGU_CONDITION_DECODE, j)] = 0x1000000;
> + }
> + }
> +
> + if (vt->condition_select) {
> + size_t size = drvdata->num_condition_select *
> + drvdata->num_step * sizeof(unsigned int);
> + memset(vt->condition_select, 0, size);
> + }
> +
> + if (vt->timer) {
> + size_t size = (drvdata->num_step) * (drvdata->num_timer) *
> + sizeof(unsigned int);
> + memset(vt->timer, 0, size);
> + }
> +
> + if (vt->counter) {
> + size_t size = (drvdata->num_step) * (drvdata->num_counter) *
> + sizeof(unsigned int);
> + memset(vt->counter, 0, size);
> + }
> +
> + spin_unlock(&drvdata->lock);
> +
> + dev_dbg(dev, "Qualcomm-TGU reset complete\n");
> +
> + if (need_pm_put)
> + pm_runtime_put(drvdata->dev);
> +
> + return size;
> +}
> +static DEVICE_ATTR_WO(reset_tgu);
> +
> static struct attribute *tgu_common_attrs[] = {
> &dev_attr_enable_tgu.attr,
> + &dev_attr_reset_tgu.attr,
> NULL,
> };
>
^ permalink raw reply
* Re: [PATCH v5 2/2] phy: qcom-mipi-csi2: Add a CSI2 MIPI DPHY driver
From: Hangxiang Ma @ 2026-03-27 2:23 UTC (permalink / raw)
To: Bryan O'Donoghue, Vinod Koul, Kishon Vijay Abraham I,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong
Cc: Bryan O'Donoghue, Vladimir Zapolskiy, linux-arm-msm,
linux-phy, linux-media, devicetree, linux-kernel
In-Reply-To: <20260326-x1e-csi2-phy-v5-2-0c0fc7f5c01b@linaro.org>
On 3/26/2026 9:04 AM, Bryan O'Donoghue wrote:
> +#include <linux/delay.h>
> +#include <linux/interrupt.h>
> +#include <linux/io.h>
> +#include <linux/time64.h>
> +
> +#include "phy-qcom-mipi-csi2.h"
> +
> +#define CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(offset, n) ((offset) + 0x4 * (n))
> +#define CSIPHY_3PH_CMN_CSI_COMMON_CTRL0_PHY_SW_RESET BIT(0)
> +#define CSIPHY_3PH_CMN_CSI_COMMON_CTRL5_CLK_ENABLE BIT(7)
> +#define CSIPHY_3PH_CMN_CSI_COMMON_CTRL6_COMMON_PWRDN_B BIT(0)
> +#define CSIPHY_3PH_CMN_CSI_COMMON_CTRL6_SHOW_REV_ID BIT(1)
> +#define CSIPHY_3PH_CMN_CSI_COMMON_CTRL10_IRQ_CLEAR_CMD BIT(0)
> +#define CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(offset, n) ((offset) + 0xb0 + 0x4 * (n))
>
Hi Bryan, one minor observation on the following macro:
CSIPHY_3PH_CMN_CSI_COMMON_STATUSn
The 0xb0 offset implicitly assumes a fixed distance between the
common_ctrl and common_status register blocks. This holds for the PHYs
covered by this series, but on some other platforms (e.g. Kaanapali,
Pakala) the offset differs.
That said, I think keeping this fixed value is reasonable for the scope
of the current PHY series, and it does help keep the macro set simple.
It might just be worth documenting this assumption (e.g. via a comment
or in the commit message).
Alternatively, if future PHY variants need to support different layouts,
this could be made more extensible by moving the status base offset into
the per-PHY data (similar to other register layout parameters). But I
don’t think that needs to block the current series.
Related patch before:
<https://lore.kernel.org/all/20260112-camss-extended-csiphy-macro-v2-1-ee7342f2aaf5@oss.qualcomm.com/>
Best Regards,
Hangxiang
^ permalink raw reply
* Re: [PATCH v12 2/7] qcom-tgu: Add TGU driver
From: Jie Gan @ 2026-03-27 2:16 UTC (permalink / raw)
To: Songwei Chai, andersson, alexander.shishkin, mike.leach,
konrad.dybcio, suzuki.poulose, james.clark, krzk+dt, conor+dt
Cc: linux-kernel, linux-arm-kernel, linux-arm-msm, coresight,
devicetree, gregkh
In-Reply-To: <20260317032639.2393221-3-songwei.chai@oss.qualcomm.com>
On 3/17/2026 11:26 AM, Songwei Chai wrote:
> Add driver to support device TGU (Trigger Generation Unit).
> TGU is a Data Engine which can be utilized to sense a plurality of
> signals and create a trigger into the CTI or generate interrupts to
> processors. Add probe/enable/disable functions for tgu.
>
> Signed-off-by: Songwei Chai <songwei.chai@oss.qualcomm.com>
> ---
> .../ABI/testing/sysfs-bus-amba-devices-tgu | 9 +
> drivers/Makefile | 1 +
> drivers/hwtracing/Kconfig | 2 +
> drivers/hwtracing/qcom/Kconfig | 18 ++
> drivers/hwtracing/qcom/Makefile | 3 +
> drivers/hwtracing/qcom/tgu.c | 183 ++++++++++++++++++
> drivers/hwtracing/qcom/tgu.h | 51 +++++
> 7 files changed, 267 insertions(+)
> create mode 100644 Documentation/ABI/testing/sysfs-bus-amba-devices-tgu
> create mode 100644 drivers/hwtracing/qcom/Kconfig
> create mode 100644 drivers/hwtracing/qcom/Makefile
> create mode 100644 drivers/hwtracing/qcom/tgu.c
> create mode 100644 drivers/hwtracing/qcom/tgu.h
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-amba-devices-tgu b/Documentation/ABI/testing/sysfs-bus-amba-devices-tgu
> new file mode 100644
> index 000000000000..ead237bb7d89
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-bus-amba-devices-tgu
> @@ -0,0 +1,9 @@
> +What: /sys/bus/amba/devices/<tgu-name>/enable_tgu
> +Date: March 2026
> +KernelVersion 7.1
> +Contact: Jinlong Mao <jinlong.mao@oss.qualcomm.com>, Songwei Chai <songwei.chai@oss.qualcomm.com>
> +Description:
> + (RW) Set/Get the enable/disable status of TGU
> + Accepts only one of the 2 values - 0 or 1.
> + 0 : disable TGU.
> + 1 : enable TGU.
> diff --git a/drivers/Makefile b/drivers/Makefile
> index 53fbd2e0acdd..82b712a12a26 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -177,6 +177,7 @@ obj-$(CONFIG_RAS) += ras/
> obj-$(CONFIG_USB4) += thunderbolt/
> obj-$(CONFIG_CORESIGHT) += hwtracing/coresight/
> obj-y += hwtracing/intel_th/
> +obj-y += hwtracing/qcom/
> obj-$(CONFIG_STM) += hwtracing/stm/
> obj-$(CONFIG_HISI_PTT) += hwtracing/ptt/
> obj-y += android/
> diff --git a/drivers/hwtracing/Kconfig b/drivers/hwtracing/Kconfig
> index 911ee977103c..8a640218eed8 100644
> --- a/drivers/hwtracing/Kconfig
> +++ b/drivers/hwtracing/Kconfig
> @@ -7,4 +7,6 @@ source "drivers/hwtracing/intel_th/Kconfig"
>
> source "drivers/hwtracing/ptt/Kconfig"
>
> +source "drivers/hwtracing/qcom/Kconfig"
> +
> endmenu
> diff --git a/drivers/hwtracing/qcom/Kconfig b/drivers/hwtracing/qcom/Kconfig
> new file mode 100644
> index 000000000000..d6f6d4b0f28e
> --- /dev/null
> +++ b/drivers/hwtracing/qcom/Kconfig
> @@ -0,0 +1,18 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +#
> +# QCOM specific hwtracing drivers
> +#
> +menu "Qualcomm specific hwtracing drivers"
> +
> +config QCOM_TGU
> + tristate "QCOM Trigger Generation Unit driver"
> + help
> + This driver provides support for Trigger Generation Unit that is
> + used to detect patterns or sequences on a given set of signals.
> + TGU is used to monitor a particular bus within a given region to
> + detect illegal transaction sequences or slave responses. It is also
> + used to monitor a data stream to detect protocol violations and to
> + provide a trigger point for centering data around a specific event
> + within the trace data buffer.
> +
> +endmenu
> diff --git a/drivers/hwtracing/qcom/Makefile b/drivers/hwtracing/qcom/Makefile
> new file mode 100644
> index 000000000000..5a0a868c1ea0
> --- /dev/null
> +++ b/drivers/hwtracing/qcom/Makefile
> @@ -0,0 +1,3 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +obj-$(CONFIG_QCOM_TGU) += tgu.o
> diff --git a/drivers/hwtracing/qcom/tgu.c b/drivers/hwtracing/qcom/tgu.c
> new file mode 100644
> index 000000000000..58c19f12f3d7
> --- /dev/null
> +++ b/drivers/hwtracing/qcom/tgu.c
> @@ -0,0 +1,183 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +#include <linux/amba/bus.h>
> +#include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/pm_runtime.h>
> +
> +#include "tgu.h"
> +
> +static void tgu_write_all_hw_regs(struct tgu_drvdata *drvdata)
> +{
> + TGU_UNLOCK(drvdata->base);
> + /* Enable TGU to program the triggers */
> + writel(1, drvdata->base + TGU_CONTROL);
> + TGU_LOCK(drvdata->base);
> +}
> +
> +static int tgu_enable(struct device *dev)
> +{
> + struct tgu_drvdata *drvdata = dev_get_drvdata(dev);
> +
> + guard(spinlock)(&drvdata->lock);
> + if (drvdata->enabled)
> + return -EBUSY;
> +
> + tgu_write_all_hw_regs(drvdata);
> + drvdata->enabled = true;
> +
> + return 0;
> +}
> +
> +static void tgu_do_disable(struct tgu_drvdata *drvdata)
> +{
> + TGU_UNLOCK(drvdata->base);
> + writel(0, drvdata->base + TGU_CONTROL);
> + TGU_LOCK(drvdata->base);
> +
> + drvdata->enabled = false;
> +}
> +
> +static void tgu_disable(struct device *dev)
> +{
> + struct tgu_drvdata *drvdata = dev_get_drvdata(dev);
> +
> + guard(spinlock)(&drvdata->lock);
> + if (!drvdata->enabled)
> + return;
> +
> + tgu_do_disable(drvdata);
> +}
> +
> +static ssize_t enable_tgu_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct tgu_drvdata *drvdata = dev_get_drvdata(dev);
> + bool enabled;
> +
> + guard(spinlock)(&drvdata->lock);
> + enabled = drvdata->enabled;
> +
> + return sysfs_emit(buf, "%d\n", !!enabled);
> +}
> +
> +/* enable_tgu_store - Configure Trace and Gating Unit (TGU) triggers. */
> +static ssize_t enable_tgu_store(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf,
> + size_t size)
> +{
> + unsigned long val;
> + int ret;
> +
> + ret = kstrtoul(buf, 0, &val);
> + if (ret || val > 1)
> + return -EINVAL;
> +
> + if (val) {
> + ret = pm_runtime_resume_and_get(dev);
> + if (ret)
> + return ret;
> + ret = tgu_enable(dev);
> + if (ret) {
> + pm_runtime_put(dev);
> + return ret;
> + }
> + } else {
> + tgu_disable(dev);
> + pm_runtime_put(dev);
Sorry I didnt observe this issue with my previous check.
echo 0 to the disabled device will result in the pm_runtime reference
number goes to negative. We dont need pm_runtime_put(dev) when we try to
disable a diabled device.
Thanks,
Jie
> + }
> +
> + return size;
> +}
> +static DEVICE_ATTR_RW(enable_tgu);
> +
> +static struct attribute *tgu_common_attrs[] = {
> + &dev_attr_enable_tgu.attr,
> + NULL,
> +};
> +
> +static const struct attribute_group tgu_common_grp = {
> + .attrs = tgu_common_attrs,
> + NULL,
> +};
> +
> +static const struct attribute_group *tgu_attr_groups[] = {
> + &tgu_common_grp,
> + NULL,
> +};
> +
> +static int tgu_probe(struct amba_device *adev, const struct amba_id *id)
> +{
> + struct device *dev = &adev->dev;
> + struct tgu_drvdata *drvdata;
> + int ret;
> +
> + drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
> + if (!drvdata)
> + return -ENOMEM;
> +
> + drvdata->dev = &adev->dev;
> + dev_set_drvdata(dev, drvdata);
> +
> + drvdata->base = devm_ioremap_resource(dev, &adev->res);
> + if (IS_ERR(drvdata->base))
> + return PTR_ERR(drvdata->base);
> +
> + spin_lock_init(&drvdata->lock);
> +
> + ret = sysfs_create_groups(&dev->kobj, tgu_attr_groups);
> + if (ret) {
> + dev_err(dev, "failed to create sysfs groups: %d\n", ret);
> + return ret;
> + }
> +
> + drvdata->enabled = false;
> +
> + pm_runtime_put(&adev->dev);
> +
> + return 0;
> +}
> +
> +static void tgu_remove(struct amba_device *adev)
> +{
> + struct device *dev = &adev->dev;
> +
> + sysfs_remove_groups(&dev->kobj, tgu_attr_groups);
> +
> + tgu_disable(dev);
> +}
> +
> +static const struct amba_id tgu_ids[] = {
> + {
> + .id = 0x000f0e00,
> + .mask = 0x000fffff,
> + },
> + { 0, 0, NULL },
> +};
> +
> +MODULE_DEVICE_TABLE(amba, tgu_ids);
> +
> +static struct amba_driver tgu_driver = {
> + .drv = {
> + .name = "qcom-tgu",
> + .suppress_bind_attrs = true,
> + },
> + .probe = tgu_probe,
> + .remove = tgu_remove,
> + .id_table = tgu_ids,
> +};
> +
> +module_amba_driver(tgu_driver);
> +
> +MODULE_AUTHOR("Songwei Chai <songwei.chai@oss.qualcomm.com>");
> +MODULE_AUTHOR("Jinlong Mao <jinlong.mao@oss.qualcomm.com>");
> +MODULE_DESCRIPTION("Qualcomm Trigger Generation Unit driver");
> +MODULE_LICENSE("GPL");
> diff --git a/drivers/hwtracing/qcom/tgu.h b/drivers/hwtracing/qcom/tgu.h
> new file mode 100644
> index 000000000000..dd7533b9d735
> --- /dev/null
> +++ b/drivers/hwtracing/qcom/tgu.h
> @@ -0,0 +1,51 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +#ifndef _QCOM_TGU_H
> +#define _QCOM_TGU_H
> +
> +/* Register addresses */
> +#define TGU_CONTROL 0x0000
> +#define TGU_LAR 0xfb0
> +#define TGU_UNLOCK_OFFSET 0xc5acce55
> +
> +static inline void TGU_LOCK(void __iomem *addr)
> +{
> + do {
> + /* Wait for things to settle */
> + mb();
> + writel_relaxed(0x0, addr + TGU_LAR);
> + } while (0);
> +}
> +
> +static inline void TGU_UNLOCK(void __iomem *addr)
> +{
> + do {
> + writel_relaxed(TGU_UNLOCK_OFFSET, addr + TGU_LAR);
> + /* Make sure everyone has seen this */
> + mb();
> + } while (0);
> +}
> +
> +/**
> + * struct tgu_drvdata - Data structure for a TGU (Trigger Generator Unit)
> + * @base: Memory-mapped base address of the TGU device
> + * @dev: Pointer to the associated device structure
> + * @lock: Spinlock for handling concurrent access to private data
> + * @enabled: Flag indicating whether the TGU device is enabled
> + *
> + * This structure defines the data associated with a TGU device,
> + * including its base address, device pointers, clock, spinlock for
> + * synchronization, trigger data pointers, maximum limits for various
> + * trigger-related parameters, and enable status.
> + */
> +struct tgu_drvdata {
> + void __iomem *base;
> + struct device *dev;
> + spinlock_t lock;
> + bool enabled;
> +};
> +
> +#endif
^ permalink raw reply
* Re: [PATCH v2 0/4] Add RZ/G3L GFX support
From: Adrián Larumbe @ 2026-03-27 2:14 UTC (permalink / raw)
To: Biju
Cc: David Airlie, Simona Vetter, Steven Price, Boris Brezillon,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Biju Das, dri-devel, devicetree, linux-kernel,
linux-renesas-soc, Prabhakar Mahadev Lad
In-Reply-To: <20260320164158.487406-1-biju.das.jz@bp.renesas.com>
Applied to drm-misc-next.
On 20.03.2026 16:41, Biju wrote:
> From: Biju Das <biju.das.jz@bp.renesas.com>
>
> The Renesas RZ/G3L SoC includes the Arm Mali-G31 GPU as a 3D Graphics
> Engine (GE3D). The Arm Mali-G31 GPU is a graphics acceleration platform
> that is based on open standards. It supports 2D graphics, 3D graphics, and
> General Purpose computing on GPU (GPGPU). Add the binding and driver
> support for suspend/resume functionality along with some improvements in
> panfrost driver.
>
> v1->v2:
> * Dropped duplicate err assignment
> * Changed the format string of dev_err to "%d" and simplify the dev_err()
> line by using err rather than the same PTR_ERR().
> * Collected tags
>
> Biju Das (4):
> dt-bindings: gpu: mali-bifrost: Add compatible for RZ/G3L SoC
> drm/panfrost: Drop redundant optional clock checks in runtime PM
> drm/panfrost: Add bus_ace optional clock support for RZ/G2L
> drm/panfrost: Add GPU_PM_RT support for RZ/G3L SoC
>
> .../bindings/gpu/arm,mali-bifrost.yaml | 2 ++
> drivers/gpu/drm/panfrost/panfrost_device.c | 34 ++++++++++++++-----
> drivers/gpu/drm/panfrost/panfrost_device.h | 1 +
> drivers/gpu/drm/panfrost/panfrost_drv.c | 1 +
> 4 files changed, 30 insertions(+), 8 deletions(-)
>
> --
> 2.43.0
Adrian Larumbe
^ permalink raw reply
* RE: [PATCH v3 net-next 02/14] dt-bindings: net: dsa: add NETC switch
From: Wei Fang @ 2026-03-27 2:09 UTC (permalink / raw)
To: Frank Li
Cc: Claudiu Manoil, Vladimir Oltean, Clark Wang,
andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, f.fainelli@gmail.com,
chleroy@kernel.org, horms@kernel.org, linux@armlinux.org.uk,
andrew@lunn.ch, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev
In-Reply-To: <acWR0QwRSnupmCvI@lizhi-Precision-Tower-5810>
> On Thu, Mar 26, 2026 at 02:29:05PM +0800, Wei Fang wrote:
> > Add bindings for NETC switch. This switch is a PCIe function of NETC
> > IP, it supports advanced QoS with 8 traffic classes and 4 drop
> > resilience levels, and a full range of TSN standards capabilities.
> > The switch CPU
>
> Nit: double space before TSN.
Thanks for catching this, I will fix it.
>
> > port connects to an internal ENETC port, which is also a PCIe function
> > of NETC IP. So these two ports use a light-weight "pseudo MAC" instead
> > of a back-to-back MAC, because the "pseudo MAC" provides the
> > delineation between switch and ENETC, this translates to lower power
> > (less logic and
>
> what's means "this translates", do you means "this help reduce power and
> latency."
This sentence is excerpted from the NETC Block Guide. It is equivalent to
"it means".
>
> > memory) and lower delay (as there is no serialization delay across
> > this link).
> >
> > Signed-off-by: Wei Fang <wei.fang@nxp.com>
> > ---
> > .../bindings/net/dsa/nxp,netc-switch.yaml | 130 ++++++++++++++++++
> > 1 file changed, 130 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/net/dsa/nxp,netc-switch.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/net/dsa/nxp,netc-switch.yaml
> > b/Documentation/devicetree/bindings/net/dsa/nxp,netc-switch.yaml
> > new file mode 100644
> > index 000000000000..e34a4e3504c3
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/dsa/nxp,netc-switch.yaml
> > @@ -0,0 +1,130 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/net/dsa/nxp,netc-switch.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: NETC Switch family
> > +
> > +description:
>
> Nit use ">" for multi paragraph.
Okay, I suppose I also need to add '>' to the below description of
"dsa,member" property.
>
> others look good
>
> Reviewed-by: Frank Li <Frank.Li@nxp.com>
>
> > + The NETC presents itself as a multi-function PCIe Root Complex
> > + Integrated Endpoint (RCiEP) and provides full 802.1Q Ethernet
> > + switch functionality, advanced QoS with 8 traffic classes and 4
> > + drop resilience levels, and a full range of TSN standards capabilities.
> > +
> > + The CPU port of the switch connects to an internal ENETC. The
> > + switch and the internal ENETC are fully integrated into the NETC
> > + IP, a back-to-back MAC is not required. Instead, a light-weight
> > + "pseudo MAC" provides the delineation between the switch and ENETC.
> > + This translates to lower power (less logic and memory) and lower
> > + delay (as there is no serialization delay across this link).
> > +
> > +maintainers:
> > + - Wei Fang <wei.fang@nxp.com>
> > +
> > +properties:
> > + compatible:
> > + enum:
> > + - pci1131,eef2
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + dsa,member:
> > + description:
> > + The property indicates DSA cluster and switch index. For NETC switch,
> > + the valid range of the switch index is 1 ~ 7, the index is reflected
> > + in the switch tag as an indication of the switch ID where the frame
> > + originated. The value 0 is reserved for ENETC VEPA switch, whose ID
> > + is hardwired to zero.
> > +
> > +$ref: dsa.yaml#
> > +
> > +patternProperties:
> > + "^(ethernet-)?ports$":
> > + type: object
> > + additionalProperties: true
> > + patternProperties:
> > + "^(ethernet-)?port@[0-9a-f]$":
> > + type: object
> > +
> > + $ref: dsa-port.yaml#
> > +
> > + properties:
> > + clocks:
> > + items:
> > + - description: MAC transmit/receive reference clock.
> > +
> > + clock-names:
> > + items:
> > + - const: ref
> > +
> > + mdio:
> > + $ref: /schemas/net/mdio.yaml#
> > + unevaluatedProperties: false
> > + description:
> > + Optional child node for switch port, otherwise use NETC
> EMDIO.
> > +
> > + unevaluatedProperties: false
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - dsa,member
> > +
> > +allOf:
> > + - $ref: /schemas/pci/pci-device.yaml
> > +
> > +unevaluatedProperties: false
> > +
> > +examples:
> > + - |
> > + pcie {
> > + #address-cells = <3>;
> > + #size-cells = <2>;
> > +
> > + ethernet-switch@0,2 {
> > + compatible = "pci1131,eef2";
> > + reg = <0x200 0 0 0 0>;
> > + dsa,member = <0 1>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_switch>;
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port@0 {
> > + reg = <0>;
> > + phy-handle = <ðphy0>;
> > + phy-mode = "mii";
> > + };
> > +
> > + port@1 {
> > + reg = <1>;
> > + phy-handle = <ðphy1>;
> > + phy-mode = "mii";
> > + };
> > +
> > + port@2 {
> > + reg = <2>;
> > + clocks = <&scmi_clk 103>;
> > + clock-names = "ref";
> > + phy-handle = <ðphy2>;
> > + phy-mode = "rgmii-id";
> > + };
> > +
> > + port@3 {
> > + reg = <3>;
> > + ethernet = <&enetc3>;
> > + phy-mode = "internal";
> > +
> > + fixed-link {
> > + speed = <2500>;
> > + full-duplex;
> > + pause;
> > + };
> > + };
> > + };
> > + };
> > + };
> > --
> > 2.34.1
> >
^ permalink raw reply
* Re: [PATCH v1 1/2] dt-bindings: i2c: ls2x-i2c: Add clock- related properties
From: Hongliang Wang @ 2026-03-27 2:08 UTC (permalink / raw)
To: Andi Shyti
Cc: Krzysztof Kozlowski, Binbin Zhou, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-i2c, devicetree,
loongarch
In-Reply-To: <acTeJvyLty4K9kFn@zenone.zhora.eu>
On 2026/3/26 下午3:21, Andi Shyti wrote:
> Hi Hongliang,
>
>> Consider the clock framework relies on the device tree, and can only be used
>> on
>> Loongson 2K platform with dts parameter mechanism, It cannot be used on
>> Loongson
>> 3A+7A platform with the acpi parameter mechanism.
>> 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.
> Thanks for the explanation, but please do consider Krzysztof's
> review. Without him agreeing on the change I can't take your
> patch.
>
> If you have questions, please ask.
OK, thank you
> Andi
^ permalink raw reply
* Re: [PATCH v1 1/2] dt-bindings: i2c: ls2x-i2c: Add clock- related properties
From: Hongliang Wang @ 2026-03-27 2:06 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Binbin Zhou, Andi Shyti, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-i2c, devicetree, loongarch
In-Reply-To: <4516aba8-e776-41e1-ad26-c6f817b11b58@kernel.org>
On 2026/3/26 下午8:23, Krzysztof Kozlowski wrote:
> On 26/03/2026 12:48, Hongliang Wang wrote:
>> Hi Krzysztof and Andi,
>>
>> Sorry, I didn't express myself clearly. The purpose of defining clock-input and
>> clock-div properties is to use them in both acpi and dts. If these properties
>> cannot be used in dts, can I first use them in acpi? and second, use clock
>> framework in dts.
> I already asked you:
> 1. Stop requesting read receipts on your email
OK, I have set my email and removed the read receipts.
> 2. Don't top post.
OK
>
> I already told you also why these cannot be in DTS. Respond to technical
> arguments, not top-post of what you want.
OK
>
> Best regards,
> Krzysztof
Best regards,
Hongliang Wang
^ permalink raw reply
* Re: [PATCH 2/2] dts: riscv: spacemit: k3: Add i2c nodes
From: Yixun Lan @ 2026-03-27 2:05 UTC (permalink / raw)
To: Andi Shyti
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Troy Mitchell,
linux-i2c, devicetree, linux-riscv, spacemit, linux-kernel
In-Reply-To: <acWx_31uT2ffcaSN@zenone.zhora.eu>
Hi Andi,
On 23:24 Thu 26 Mar , Andi Shyti wrote:
> Hi agagin,
>
> On Thu, Mar 26, 2026 at 11:22:31PM +0100, Andi Shyti wrote:
> > On Wed, Mar 25, 2026 at 09:49:25AM +0000, Yixun Lan wrote:
> > > Populate all I2C devicetree nodes for SpacemiT K3 SoC.
> > >
> > > Signed-off-by: Yixun Lan <dlan@kernel.org>
> >
> > this second patch does not apply on my i2c branch. I'm missing
> > some other patches on k3.
> >
> > Can you please rebase it on top of my i2c/i2c-host branch,
> > otherwise I will need to wait for the merge window to open in
> > order to take this.
>
> sorry, this has to go through some other path, I'm going to take
> patch 1.
Right, I will take care of it, DT patch should go via SpacemiT SoC tree.
--
Yixun Lan (dlan)
^ permalink raw reply
* [PATCH] ARM: dts: aspeed: g6: Add missing uart nodes
From: Jammy Huang @ 2026-03-27 1:58 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery
Cc: devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
Jammy Huang
Add nodes for uart10/11/12/13.
Signed-off-by: Jammy Huang <jammy_huang@aspeedtech.com>
---
arch/arm/boot/dts/aspeed/aspeed-g6.dtsi | 56 +++++++++++++++++++++++++++++++++
1 file changed, 56 insertions(+)
diff --git a/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi b/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
index 189bc3bbb47..0ffe386fa9d 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
+++ b/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
@@ -835,6 +835,62 @@ uart9: serial@1e790300 {
status = "disabled";
};
+ uart10: serial@1e790400 {
+ compatible = "ns16550a";
+ reg = <0x1e790400 0x20>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ interrupts = <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&syscon ASPEED_CLK_GATE_UART10CLK>;
+ no-loopback-test;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart10_default>;
+
+ status = "disabled";
+ };
+
+ uart11: serial@1e790500 {
+ compatible = "ns16550a";
+ reg = <0x1e790500 0x20>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&syscon ASPEED_CLK_GATE_UART11CLK>;
+ no-loopback-test;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart11_default>;
+
+ status = "disabled";
+ };
+
+ uart12: serial@1e790600 {
+ compatible = "ns16550a";
+ reg = <0x1e790600 0x20>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ interrupts = <GIC_SPI 63 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&syscon ASPEED_CLK_GATE_UART12CLK>;
+ no-loopback-test;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart12g1_default>;
+
+ status = "disabled";
+ };
+
+ uart13: serial@1e790700 {
+ compatible = "ns16550a";
+ reg = <0x1e790700 0x20>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ interrupts = <GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&syscon ASPEED_CLK_GATE_UART13CLK>;
+ no-loopback-test;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart13g1_default>;
+
+ status = "disabled";
+ };
+
i2c: bus@1e78a000 {
compatible = "simple-bus";
#address-cells = <1>;
---
base-commit: 5ee8dbf54602dc340d6235b1d6aa17c0f283f48c
change-id: 20260327-upstream_g6_dts_uart-78a5ce3b2873
Best regards,
--
Jammy Huang <jammy_huang@aspeedtech.com>
^ permalink raw reply related
* Re: [PATCH net-next v2 4/4] net: phy: Introduce Airoha AN8801/R Gigabit Ethernet PHY driver
From: Jakub Kicinski @ 2026-03-27 1:43 UTC (permalink / raw)
To: Louis-Alexis Eyraud
Cc: Andrew Lunn, Andrew Lunn, David S. Miller, Eric Dumazet,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
AngeloGioacchino Del Regno, Heiner Kallweit, Russell King,
kevin-kw.huang, macpaul.lin, matthias.bgg, kernel, netdev,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel
In-Reply-To: <3688a285-7f98-4afa-80ad-697094cd7b97@lunn.ch>
On Thu, 26 Mar 2026 13:47:43 +0100 Andrew Lunn wrote:
> > + if (phydev->link && prev_speed != phydev->speed) {
> > + val = phydev->speed == SPEED_1000 ?
> > + AN8801_BPBUS_LINK_MODE_1000 : 0;
> > +
> > + return an8801_buckpbus_reg_rmw(phydev,
> > + AN8801_BPBUS_REG_LINK_MODE,
> > + AN8801_BPBUS_LINK_MODE_1000,
> > + val);
> > + };
>
> This is unusual. What is it doing? Please add a comment.
Also - nit spurious ; after if () {}
^ permalink raw reply
* Re: [PATCH v5 0/3] iio: adc: ltc2309: add support driver for ltc2305
From: Kyle Hsieh @ 2026-03-27 1:32 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Liam Beguin, linux-iio, devicetree, linux-kernel
In-Reply-To: <20260325195035.26214c91@jic23-huawei>
On Thu, Mar 26, 2026 at 3:50 AM Jonathan Cameron <jic23@kernel.org> wrote:
>
> On Wed, 25 Mar 2026 10:24:19 +0800
> Kyle Hsieh <kylehsieh1995@gmail.com> wrote:
>
> > The series add support for ltc2305 controller from
> > Linear Technology Corporation(lltc).
> > This is low noise, low power, 2 channels 12-bit successive
> > approximation ADCs.
> >
> > Signed-off-by: Kyle Hsieh <kylehsieh1995@gmail.com>
> Applied to the togreg branch of iio.git.
>
> To hussle things along a touch I skipped the normal pushing
> it out as testing first (what could possibly go wrong ;)
>
> Jonathan
Hi Jonathan,
I'm glad to see this series moving forward.
Thanks for your help!
Best regards,
Kyle
>
> > ---
> > Changes in v5:
> > - Split the patch series to refactor LTC2309 channel enums first.
> > - Explicitly assign hex values to channel enums based on datasheet.
> > - Add support for LTC2305 on top of the refactored driver.
> > - Link to v4: https://lore.kernel.org/r/20260311-add_ltc2305_driver-v4-0-bc350d347f33@gmail.com
> >
> > Changes in v4:
> > - Fix build warning in ltc2309_probe(): initialize 'chip_info'.
> > - Link to v3: https://lore.kernel.org/r/20260126-add_ltc2305_driver-v3-0-951349a87f97@gmail.com
> >
> > Changes in v3:
> > - Modify ltc2305 channel mask to compatible ltc2309.
> > - Link to v2: https://lore.kernel.org/r/20251224-add_ltc2305_driver-v2-0-061f78cf45a3@gmail.com
> >
> > Changes in v2:
> > - Reordered chip descriptions and code from low to high order.
> > - Renamed chip info structure to use ltc2309 driver prefix.
> > - Switched to i2c_get_match_data().
> > - Removed unused variables.
> > - Added chip info to i2c_device_id table.
> > - Link to v1: https://lore.kernel.org/r/20251223-add_ltc2305_driver-v1-0-dfa0827fd620@gmail.com
> >
> > ---
> > Kyle Hsieh (3):
> > dt-bindings: adc: ltc2497: add support for ltc2305
> > iio: adc: ltc2309: explicitly assign hex values to channel enums
> > iio: adc: ltc2309: add support for ltc2305
> >
> > .../devicetree/bindings/iio/adc/lltc,ltc2497.yaml | 7 ++
> > drivers/iio/adc/ltc2309.c | 81 ++++++++++++++++------
> > 2 files changed, 67 insertions(+), 21 deletions(-)
> > ---
> > base-commit: 9448598b22c50c8a5bb77a9103e2d49f134c9578
> > change-id: 20251223-add_ltc2305_driver-728fa9161bc7
> >
> > Best regards,
>
^ permalink raw reply
* Re: [PATCH net-next v15 0/3] Add support for Nuvoton MA35D1 GMAC
From: patchwork-bot+netdevbpf @ 2026-03-27 1:20 UTC (permalink / raw)
To: Joey Lu
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, robh, krzk+dt,
conor+dt, mcoquelin.stm32, richardcochran, alexandre.torgue,
joabreu, ychuang3, schung, yclu4, peppe.cavallaro,
linux-arm-kernel, netdev, devicetree, linux-kernel, openbmc,
linux-stm32
In-Reply-To: <20260323101756.81849-1-a0987203069@gmail.com>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 23 Mar 2026 18:17:53 +0800 you wrote:
> This patch series is submitted to add GMAC support for Nuvoton MA35D1
> SoC platform. This work involves implementing a GMAC driver glue layer
> based on Synopsys DWMAC driver framework to leverage MA35D1's dual GMAC
> interface capabilities.
>
> Overview:
> 1. Added a GMAC driver glue layer for MA35D1 SoC, providing support for
> the platform's two GMAC interfaces.
> 2. Added device tree settings, with specific configurations for our
> development boards:
> a. SOM board: Configured for two RGMII interfaces.
> b. IoT board: Configured with one RGMII and one RMII interface.
> 3. Added dt-bindings for the GMAC interfaces.
>
> [...]
Here is the summary with links:
- [net-next,v15,1/3] dt-bindings: net: nuvoton: Add schema for Nuvoton MA35 family GMAC
https://git.kernel.org/netdev/net-next/c/8454478ef9ab
- [net-next,v15,2/3] arm64: dts: nuvoton: Add Ethernet nodes
(no matching commit)
- [net-next,v15,3/3] net: stmmac: dwmac-nuvoton: Add dwmac glue for Nuvoton MA35 family
https://git.kernel.org/netdev/net-next/c/4d7c557f58ef
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v5 1/2] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema
From: Bryan O'Donoghue @ 2026-03-27 1:03 UTC (permalink / raw)
To: Vladimir Zapolskiy, Bryan O'Donoghue, Vinod Koul,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Neil Armstrong
Cc: linux-arm-msm, linux-phy, linux-media, devicetree, linux-kernel
In-Reply-To: <99287afe-90cb-44d5-91db-14c6b0f729fd@linaro.org>
On 26/03/2026 14:49, Vladimir Zapolskiy wrote:
> Here the description of hardware is done, and my point is that the new
> PHY_QCOM_CSI2_MODE_SPLIT_DPHY phy type is simply not needed, since it's
> possible to give a proper description of hardware without this invention.
Perhaps I'm not understanding you.
If we use PHY_TYPE_DPHY
include/dt-bindings/phy/phy.h:#define PHY_TYPE_DPHY 10
We _must_ then add SPLIT_MODE to phy.h if/when we implement that
support. Which means successfully arguing the toss of weather SPLIT_MODE
is a Qualcommism - a vendor specific mode or not.
<&phy PHY_TYPE_DPHY> committed to an upstream dts will then need to be
supported perpetually.
So for example qrb5615 - kona/rb5 support split mode.
Pretend go with <&phy PHY_TYPE_DPHY>; and retrofit individual PHY
support to this platform.
Grand so far.
The pretend we want to switch from one sensor to a split-mode sensor on
the existing mezzanine.
Then we need a representation of split mode in phy.h to represent that
in DT.
<&phy PHY_TYPE_DPHY_SPLIT_MODE>;
Except split-mode is not an appropriate mode to define in phy.h since it
is vendor specific - even if a few vendors support it, its not a generic
PHY mode.
Hence we would have an enormously difficult time justifying adding that
mode to phy.h and rightly so.
>> https://review.lineageos.org/c/LineageOS/
>> android_kernel_motorola_sm6375/+/423960/1/drivers/cam_sensor_module/
>> cam_csiphy/cam_csiphy_core.c#b285
>>
>> There is disjunction all over this file depending on the mode.
>>
>> https://review.lineageos.org/c/LineageOS/
>> android_kernel_motorola_sm6375/+/423960/1/drivers/cam_sensor_module/
>> cam_csiphy/cam_csiphy_core.c#b767
OTOH
- SPLIT_MODE will certainly require _both_ separate init sequences
and specific logical disjunction for additional configuration steps
lane-assignment and masking, etc.
- That phy.h isn't the right location for SPLIT_MODE as its vendor
specific. Just look at the modes we have for the USB PHYs
same logic => include/dt-bindings/phy/phy-qcom-qmp.h same
raison d'être
- And that specifying PHY_TYPE_DPHY now binds us into an ABI that we
cannot subsequently change - it will not be possible to introduce
include/dt-bindings/phy/phy-qcom-mipi-csi2.h later on with our mode
So therefore include/dt-bindings/phy/phy-qcom-mipi-csi2.h + PHY modes is
the logical outcome.
---
bod
^ permalink raw reply
* Re: [PATCH v4 2/4] dt-bindings: hwmon: Add Sensirion SHT30 series
From: Roman Gushchin @ 2026-03-27 0:46 UTC (permalink / raw)
To: Conor Dooley
Cc: Guenter Roeck, Zaixiang Xu, robh, krzk+dt, conor+dt, linux-hwmon,
devicetree, linux-kernel
In-Reply-To: <20260327-clubbing-crushed-e73c4c994737@spud>
Hello,
The pseudo-commit message is intentional, Chris Mason initially
prompted it, and I'm honestly just using his format. The intention
here is to ensure the LLM reviews the correct commit and at least
understands what it's doing. Idk if it's really useful with Sashiko,
but it's there and hopefully not too distracting.
Re previous versions: it's not implemented yet, but I plan to add this
eventually.
Thanks!
On Thu, Mar 26, 2026 at 5:03 PM Conor Dooley <conor@kernel.org> wrote:
>
> On Thu, Mar 26, 2026 at 04:55:39PM -0700, Guenter Roeck wrote:
> > On 3/26/26 10:45, Conor Dooley wrote:
> > > On Thu, Mar 26, 2026 at 05:42:30PM +0000, Conor Dooley wrote:
> > > > On Wed, Mar 25, 2026 at 06:05:22PM -0700, Guenter Roeck wrote:
> > > > > On 3/25/26 11:20, Conor Dooley wrote:
> > > > > > On Wed, Mar 25, 2026 at 05:08:08PM +0800, Zaixiang Xu wrote:
> > > > > > > Add YAML devicetree binding schema for Sensirion SHT30 series.
> > > > > > > Use fallback compatibles for compatible chips and add optional
> > > > > > > interrupts and vdd-supply properties.
> > > > > > >
> > > > > > > Reported-by: kernel test robot <lkp@intel.com>
> > > > > > > Closes: https://lore.kernel.org/r/202603212044.BRPaiz86-lkp@intel.com/
> > > > > >
> > > > > > The robot did not report that this binding was missing.
> > > > > > It also told you not to add these tags.
> > > > > >
> > > > > > You also ignored my and Krzysztof's reviews.
> > > > > >
> > > > > > NAK.
> > > > > >
> > > > >
> > > > > Maybe we should just point to AI feedback:
> > > > >
> > > > > https://sashiko.dev/#/patchset/1774429690-129139-1-git-send-email-zaixiang.xu.dev%40gmail.com
> > > > >
> > > > > and only get involved after AI does not report any problems.
> > > > >
> > > >
> > > > The presentation of info in that is weird, it creates a pseudo-commit
> > > > message, and then goes on to talk about things that the pseudo-commit
> > > > message has had culled.
> > >
> > > How good is this LLM stuff at figuring out if previous review feedback
> > > has been resolved? Or is it not capable of looking at earlier revisions?
> >
> >
> > Both are interesting questions. For the first one, I had noticed that, but
> > to me it seemed that the pseudo-commit message is an attempt to create a concise
> > version of the commit message, and I have not seen evidence that the later
> > comments did not also apply to the real commit message.
>
> Yeah, the comments did apply to the real commit message. I was just
> confusing to me to see what looked to me like a commit message not
> contain the info that was being referred to later on. I thought that the
> LLM was hallucinating the comments until I went back to this mail and
> realised the text was here.
>
> >
> > Anyway, copying Roman for feedback on both.
> >
> > Thanks,
> > Guenter
> >
^ permalink raw reply
* Re: [PATCH v4 3/7] pinctrl: extract pinctrl_generic_to_map() from pinctrl_generic_pins_function_dt_node_to_map()
From: Conor Dooley @ 2026-03-27 0:09 UTC (permalink / raw)
To: Frank Li
Cc: Peter Rosin, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rafał Miłecki, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, linux-kernel, linux-gpio,
devicetree, imx, linux-arm-kernel, Haibo Chen
In-Reply-To: <20260325-pinctrl-mux-v4-3-043c2c82e623@nxp.com>
[-- Attachment #1: Type: text/plain, Size: 6834 bytes --]
On Wed, Mar 25, 2026 at 07:04:12PM -0400, Frank Li wrote:
> Refactor pinctrl_generic_pins_function_dt_subnode_to_map() by separating DT
> parsing logic from map creation. Introduce a new helper
> pinctrl_generic_to_map() to handle mapping to kernel data structures, while
> keeping DT property parsing in the subnode function.
>
> Improve code structure and enables easier reuse for platforms using
> different DT properties (e.g. pinmux) without modifying the
> dt_node_to_map-style callback API. Avoid unnecessary coupling to
> pinctrl_generic_pins_function_dt_node_to_map(), which provides
> functionality not needed when the phandle target is unambiguous.
>
> Maximize code reuse and provide a cleaner extension point for future
> pinctrl drivers.
>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
> ---
> change in v4
> - new patch
> ---
> drivers/pinctrl/pinconf.h | 18 ++++++++
> drivers/pinctrl/pinctrl-generic.c | 91 ++++++++++++++++++++++++---------------
> 2 files changed, 74 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/pinctrl/pinconf.h b/drivers/pinctrl/pinconf.h
> index 2880adef476e68950ffdd540ea42cdee6a16ec27..ffdabddb9660324ed8886a2e8dcacff7e1c6c529 100644
> --- a/drivers/pinctrl/pinconf.h
> +++ b/drivers/pinctrl/pinconf.h
> @@ -166,6 +166,13 @@ int pinctrl_generic_pins_function_dt_node_to_map(struct pinctrl_dev *pctldev,
> struct device_node *np,
> struct pinctrl_map **maps,
> unsigned int *num_maps);
> +
> +int
> +pinctrl_generic_to_map(struct pinctrl_dev *pctldev, struct device_node *parent,
> + struct device_node *np, struct pinctrl_map **maps,
> + unsigned int *num_maps, unsigned int *num_reserved_maps,
> + const char **group_name, unsigned int ngroups,
> + const char **functions, unsigned int *pins);
> #else
> static inline int
> pinctrl_generic_pins_function_dt_node_to_map(struct pinctrl_dev *pctldev,
> @@ -175,4 +182,15 @@ pinctrl_generic_pins_function_dt_node_to_map(struct pinctrl_dev *pctldev,
> {
> return -ENOTSUPP;
> }
> +
> +static inline int
> +pinctrl_generic_to_map(struct pinctrl_dev *pctldev, struct device_node *parent,
> + struct device_node *np, struct pinctrl_map **maps,
> + unsigned int *num_maps, unsigned int *num_reserved_maps,
> + const char **group_name, unsigned int ngroups,
> + const char **functions, unsigned int *pins,
> + void *function_data)
> +{
> + return -ENOTSUPP;
> +}
> #endif
> diff --git a/drivers/pinctrl/pinctrl-generic.c b/drivers/pinctrl/pinctrl-generic.c
> index efb39c6a670331775855efdc8566102b5c6202ef..20a216ae63e91b69985ea4cfcd0b57103c6ca950 100644
> --- a/drivers/pinctrl/pinctrl-generic.c
> +++ b/drivers/pinctrl/pinctrl-generic.c
> @@ -17,29 +17,18 @@
> #include "pinctrl-utils.h"
> #include "pinmux.h"
>
> -static int pinctrl_generic_pins_function_dt_subnode_to_map(struct pinctrl_dev *pctldev,
> - struct device_node *parent,
> - struct device_node *np,
> - struct pinctrl_map **maps,
> - unsigned int *num_maps,
> - unsigned int *num_reserved_maps,
> - const char **group_names,
> - unsigned int ngroups)
> +int
> +pinctrl_generic_to_map(struct pinctrl_dev *pctldev, struct device_node *parent,
> + struct device_node *np, struct pinctrl_map **maps,
> + unsigned int *num_maps, unsigned int *num_reserved_maps,
> + const char **group_names, unsigned int ngroups,
> + const char **functions, unsigned int *pins)
npins needs to be an argument to this function also, otherwise
pinctrl_generic_add_group() uses it uninitialised...
> {
> struct device *dev = pctldev->dev;
> - const char **functions;
> + int npins, ret, reserve = 1;
...because you're declaring it here when it's something set by the dt
parsing code in pinctrl_generic_pins_function_dt_subnode_to_map()...
> + unsigned int num_configs;
> const char *group_name;
> unsigned long *configs;
> - unsigned int num_configs, pin, *pins;
> - int npins, ret, reserve = 1;
> -
> - npins = of_property_count_u32_elems(np, "pins");
> -
> - if (npins < 1) {
> - dev_err(dev, "invalid pinctrl group %pOFn.%pOFn %d\n",
> - parent, np, npins);
> - return npins;
> - }
>
> group_name = devm_kasprintf(dev, GFP_KERNEL, "%pOFn.%pOFn", parent, np);
> if (!group_name)
> @@ -51,22 +40,6 @@ static int pinctrl_generic_pins_function_dt_subnode_to_map(struct pinctrl_dev *p
> if (!pins)
> return -ENOMEM;
>
> - functions = devm_kcalloc(dev, npins, sizeof(*functions), GFP_KERNEL);
> - if (!functions)
> - return -ENOMEM;
> -
> - for (int i = 0; i < npins; i++) {
> - ret = of_property_read_u32_index(np, "pins", i, &pin);
> - if (ret)
> - return ret;
> -
> - pins[i] = pin;
> -
> - ret = of_property_read_string(np, "function", &functions[i]);
> - if (ret)
> - return ret;
> - }
> -
> ret = pinctrl_utils_reserve_map(pctldev, maps, num_reserved_maps, num_maps, reserve);
> if (ret)
> return ret;
> @@ -103,6 +76,54 @@ static int pinctrl_generic_pins_function_dt_subnode_to_map(struct pinctrl_dev *p
> return 0;
> };
>
> +static int
> +pinctrl_generic_pins_function_dt_subnode_to_map(struct pinctrl_dev *pctldev,
> + struct device_node *parent,
> + struct device_node *np,
> + struct pinctrl_map **maps,
> + unsigned int *num_maps,
> + unsigned int *num_reserved_maps,
> + const char **group_names,
> + unsigned int ngroups)
> +{
> + struct device *dev = pctldev->dev;
> + unsigned int pin, *pins;
> + const char **functions;
> + int npins, ret;
> +
> + npins = of_property_count_u32_elems(np, "pins");
...down here.
> +
> + if (npins < 1) {
> + dev_err(dev, "invalid pinctrl group %pOFn.%pOFn %d\n",
> + parent, np, npins);
> + return npins;
> + }
> +
> + pins = devm_kcalloc(dev, npins, sizeof(*pins), GFP_KERNEL);
> + if (!pins)
> + return -ENOMEM;
> +
> + functions = devm_kcalloc(dev, npins, sizeof(*functions), GFP_KERNEL);
> + if (!functions)
> + return -ENOMEM;
> +
> + for (int i = 0; i < npins; i++) {
> + ret = of_property_read_u32_index(np, "pins", i, &pin);
> + if (ret)
> + return ret;
> +
> + pins[i] = pin;
> +
> + ret = of_property_read_string(np, "function", &functions[i]);
> + if (ret)
> + return ret;
> + }
> +
> + return pinctrl_generic_to_map(pctldev, parent, np, maps, num_maps,
> + num_reserved_maps, group_names, ngroups,
> + functions, pins);
> +}
> +
> /*
> * For platforms that do not define groups or functions in the driver, but
> * instead use the devicetree to describe them. This function will, unlike
>
> --
> 2.43.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v4 3/7] pinctrl: extract pinctrl_generic_to_map() from pinctrl_generic_pins_function_dt_node_to_map()
From: Conor Dooley @ 2026-03-27 0:06 UTC (permalink / raw)
To: Frank Li
Cc: Peter Rosin, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rafał Miłecki, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, linux-kernel, linux-gpio,
devicetree, imx, linux-arm-kernel, Haibo Chen
In-Reply-To: <acWNOhnBvA5l9NW3@lizhi-Precision-Tower-5810>
[-- Attachment #1: Type: text/plain, Size: 5910 bytes --]
On Thu, Mar 26, 2026 at 03:47:06PM -0400, Frank Li wrote:
> On Thu, Mar 26, 2026 at 06:55:01PM +0000, Conor Dooley wrote:
> > On Thu, Mar 26, 2026 at 06:52:12PM +0000, Conor Dooley wrote:
> > > On Wed, Mar 25, 2026 at 07:04:12PM -0400, Frank Li wrote:
> > >
> > > > diff --git a/drivers/pinctrl/pinctrl-generic.c b/drivers/pinctrl/pinctrl-generic.c
> > > > index efb39c6a670331775855efdc8566102b5c6202ef..20a216ae63e91b69985ea4cfcd0b57103c6ca950 100644
> > > > --- a/drivers/pinctrl/pinctrl-generic.c
> > > > +++ b/drivers/pinctrl/pinctrl-generic.c
> > > > @@ -17,29 +17,18 @@
> > > > #include "pinctrl-utils.h"
> > > > #include "pinmux.h"
> > > >
> > > > -static int pinctrl_generic_pins_function_dt_subnode_to_map(struct pinctrl_dev *pctldev,
> > >
> > > > +int
> > > > +pinctrl_generic_to_map(struct pinctrl_dev *pctldev, struct device_node *parent,
> > >
> > > Can you drop this stylistic change please? The
> >
> > Whoops, cut myself off. To be clear, what I am asking for is to keep the
> > "int" etc on the same line as the function name. This function is new,
> > but you did it for the existing function too and the comparison is here.
> >
> > >
> > > > + struct device_node *np, struct pinctrl_map **maps,
> > > > + unsigned int *num_maps, unsigned int *num_reserved_maps,
> > > > + const char **group_names, unsigned int ngroups,
> > > > + const char **functions, unsigned int *pins)
> > > > {
> > > > struct device *dev = pctldev->dev;
> > > > - const char **functions;
> > > > + int npins, ret, reserve = 1;
> > > > + unsigned int num_configs;
> > > > const char *group_name;
> > > > unsigned long *configs;
> > > > - unsigned int num_configs, pin, *pins;
> > > > - int npins, ret, reserve = 1;
> > > > -
> > > > - npins = of_property_count_u32_elems(np, "pins");
> > > > -
> > > > - if (npins < 1) {
> > > > - dev_err(dev, "invalid pinctrl group %pOFn.%pOFn %d\n",
> > > > - parent, np, npins);
> > > > - return npins;
> > > > - }
> > > >
> > > > group_name = devm_kasprintf(dev, GFP_KERNEL, "%pOFn.%pOFn", parent, np);
> > > > if (!group_name)
> > > > @@ -51,22 +40,6 @@ static int pinctrl_generic_pins_function_dt_subnode_to_map(struct pinctrl_dev *p
> > > > if (!pins)
> > > > return -ENOMEM;
> > >
> > > This looks suspect. You've left the pins allocation behind:
> > > pins = devm_kcalloc(dev, npins, sizeof(*pins), GFP_KERNEL);
> > > if (!pins)
> > > return -ENOMEM;
> > > but pinctrl_generic_pins_function_dt_subnode_to_map() has already
> > > populated this array before calling the function.
>
> what's means?
It means you broke my driver by not removing this allocation from
pinctrl_generic_to_map().
>
> pinctrl_generic_pins_function_dt_subnode_to_map()
> {
> pins = devm_kcalloc(dev, npins, sizeof(*pins), GFP_KERNEL);
> ...
> pinctrl_generic_to_map();
> }
>
> pinctrl_generic_pins_function_dt_subnode_to_map() have not use this array.
I have no idea what this statement means.
>
> Frank
> > >
> > > Also, this should probably be
> > > Suggested-by: Conor Dooley <conor.dooley@microchip.com>
> > >
> > > Cheers,
> > > Conor.
> > >
> > > >
> > > > - functions = devm_kcalloc(dev, npins, sizeof(*functions), GFP_KERNEL);
> > > > - if (!functions)
> > > > - return -ENOMEM;
> > > > -
> > > > - for (int i = 0; i < npins; i++) {
> > > > - ret = of_property_read_u32_index(np, "pins", i, &pin);
> > > > - if (ret)
> > > > - return ret;
> > > > -
> > > > - pins[i] = pin;
> > > > -
> > > > - ret = of_property_read_string(np, "function", &functions[i]);
> > > > - if (ret)
> > > > - return ret;
> > > > - }
> > > > -
> > > > ret = pinctrl_utils_reserve_map(pctldev, maps, num_reserved_maps, num_maps, reserve);
> > > > if (ret)
> > > > return ret;
> > > > @@ -103,6 +76,54 @@ static int pinctrl_generic_pins_function_dt_subnode_to_map(struct pinctrl_dev *p
> > > > return 0;
> > > > };
> > > >
> > > > +static int
> > > > +pinctrl_generic_pins_function_dt_subnode_to_map(struct pinctrl_dev *pctldev,
> > > > + struct device_node *parent,
> > > > + struct device_node *np,
> > > > + struct pinctrl_map **maps,
> > > > + unsigned int *num_maps,
> > > > + unsigned int *num_reserved_maps,
> > > > + const char **group_names,
> > > > + unsigned int ngroups)
> > > > +{
> > > > + struct device *dev = pctldev->dev;
> > > > + unsigned int pin, *pins;
> > > > + const char **functions;
> > > > + int npins, ret;
> > > > +
> > > > + npins = of_property_count_u32_elems(np, "pins");
> > > > +
> > > > + if (npins < 1) {
> > > > + dev_err(dev, "invalid pinctrl group %pOFn.%pOFn %d\n",
> > > > + parent, np, npins);
> > > > + return npins;
> > > > + }
> > > > +
> > > > + pins = devm_kcalloc(dev, npins, sizeof(*pins), GFP_KERNEL);
> > > > + if (!pins)
> > > > + return -ENOMEM;
> > > > +
> > > > + functions = devm_kcalloc(dev, npins, sizeof(*functions), GFP_KERNEL);
> > > > + if (!functions)
> > > > + return -ENOMEM;
> > > > +
> > > > + for (int i = 0; i < npins; i++) {
> > > > + ret = of_property_read_u32_index(np, "pins", i, &pin);
> > > > + if (ret)
> > > > + return ret;
> > > > +
> > > > + pins[i] = pin;
> > > > +
> > > > + ret = of_property_read_string(np, "function", &functions[i]);
> > > > + if (ret)
> > > > + return ret;
> > > > + }
> > > > +
> > > > + return pinctrl_generic_to_map(pctldev, parent, np, maps, num_maps,
> > > > + num_reserved_maps, group_names, ngroups,
> > > > + functions, pins);
> > > > +}
> > > > +
> > > > /*
> > > > * For platforms that do not define groups or functions in the driver, but
> > > > * instead use the devicetree to describe them. This function will, unlike
> > > >
> > > > --
> > > > 2.43.0
> > > >
> >
> >
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v4 2/4] dt-bindings: hwmon: Add Sensirion SHT30 series
From: Conor Dooley @ 2026-03-27 0:03 UTC (permalink / raw)
To: Guenter Roeck
Cc: Zaixiang Xu, robh, krzk+dt, conor+dt, linux-hwmon, devicetree,
linux-kernel, Roman Gushchin
In-Reply-To: <ba8848a3-03f0-4113-8db4-d6dd46a57959@roeck-us.net>
[-- Attachment #1: Type: text/plain, Size: 2281 bytes --]
On Thu, Mar 26, 2026 at 04:55:39PM -0700, Guenter Roeck wrote:
> On 3/26/26 10:45, Conor Dooley wrote:
> > On Thu, Mar 26, 2026 at 05:42:30PM +0000, Conor Dooley wrote:
> > > On Wed, Mar 25, 2026 at 06:05:22PM -0700, Guenter Roeck wrote:
> > > > On 3/25/26 11:20, Conor Dooley wrote:
> > > > > On Wed, Mar 25, 2026 at 05:08:08PM +0800, Zaixiang Xu wrote:
> > > > > > Add YAML devicetree binding schema for Sensirion SHT30 series.
> > > > > > Use fallback compatibles for compatible chips and add optional
> > > > > > interrupts and vdd-supply properties.
> > > > > >
> > > > > > Reported-by: kernel test robot <lkp@intel.com>
> > > > > > Closes: https://lore.kernel.org/r/202603212044.BRPaiz86-lkp@intel.com/
> > > > >
> > > > > The robot did not report that this binding was missing.
> > > > > It also told you not to add these tags.
> > > > >
> > > > > You also ignored my and Krzysztof's reviews.
> > > > >
> > > > > NAK.
> > > > >
> > > >
> > > > Maybe we should just point to AI feedback:
> > > >
> > > > https://sashiko.dev/#/patchset/1774429690-129139-1-git-send-email-zaixiang.xu.dev%40gmail.com
> > > >
> > > > and only get involved after AI does not report any problems.
> > > >
> > >
> > > The presentation of info in that is weird, it creates a pseudo-commit
> > > message, and then goes on to talk about things that the pseudo-commit
> > > message has had culled.
> >
> > How good is this LLM stuff at figuring out if previous review feedback
> > has been resolved? Or is it not capable of looking at earlier revisions?
>
>
> Both are interesting questions. For the first one, I had noticed that, but
> to me it seemed that the pseudo-commit message is an attempt to create a concise
> version of the commit message, and I have not seen evidence that the later
> comments did not also apply to the real commit message.
Yeah, the comments did apply to the real commit message. I was just
confusing to me to see what looked to me like a commit message not
contain the info that was being referred to later on. I thought that the
LLM was hallucinating the comments until I went back to this mail and
realised the text was here.
>
> Anyway, copying Roman for feedback on both.
>
> Thanks,
> Guenter
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v4 2/4] dt-bindings: hwmon: Add Sensirion SHT30 series
From: Guenter Roeck @ 2026-03-26 23:55 UTC (permalink / raw)
To: Conor Dooley
Cc: Zaixiang Xu, robh, krzk+dt, conor+dt, linux-hwmon, devicetree,
linux-kernel, Roman Gushchin
In-Reply-To: <20260326-opposing-footsie-33a0deb2ba90@spud>
On 3/26/26 10:45, Conor Dooley wrote:
> On Thu, Mar 26, 2026 at 05:42:30PM +0000, Conor Dooley wrote:
>> On Wed, Mar 25, 2026 at 06:05:22PM -0700, Guenter Roeck wrote:
>>> On 3/25/26 11:20, Conor Dooley wrote:
>>>> On Wed, Mar 25, 2026 at 05:08:08PM +0800, Zaixiang Xu wrote:
>>>>> Add YAML devicetree binding schema for Sensirion SHT30 series.
>>>>> Use fallback compatibles for compatible chips and add optional
>>>>> interrupts and vdd-supply properties.
>>>>>
>>>>> Reported-by: kernel test robot <lkp@intel.com>
>>>>> Closes: https://lore.kernel.org/r/202603212044.BRPaiz86-lkp@intel.com/
>>>>
>>>> The robot did not report that this binding was missing.
>>>> It also told you not to add these tags.
>>>>
>>>> You also ignored my and Krzysztof's reviews.
>>>>
>>>> NAK.
>>>>
>>>
>>> Maybe we should just point to AI feedback:
>>>
>>> https://sashiko.dev/#/patchset/1774429690-129139-1-git-send-email-zaixiang.xu.dev%40gmail.com
>>>
>>> and only get involved after AI does not report any problems.
>>>
>>
>> The presentation of info in that is weird, it creates a pseudo-commit
>> message, and then goes on to talk about things that the pseudo-commit
>> message has had culled.
>
> How good is this LLM stuff at figuring out if previous review feedback
> has been resolved? Or is it not capable of looking at earlier revisions?
Both are interesting questions. For the first one, I had noticed that, but
to me it seemed that the pseudo-commit message is an attempt to create a concise
version of the commit message, and I have not seen evidence that the later
comments did not also apply to the real commit message.
Anyway, copying Roman for feedback on both.
Thanks,
Guenter
^ 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