* Re: [PATCH 3/3] net: stmmac: dwmac-socfpga: Add mac-mode DT property support
From: Nazle Asmade, Muhammad Nazim Amirul @ 2026-07-01 1:32 UTC (permalink / raw)
To: Maxime Chevallier, Andrew Lunn
Cc: dinguyen@kernel.org, rmk+kernel@armlinux.org.uk,
krzk+dt@kernel.org, conor+dt@kernel.org, robh@kernel.org,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, andrew+netdev@lunn.ch,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <e691298f-b3e5-4c1a-8270-a821c1f46a2b@bootlin.com>
On 30/6/2026 11:42 pm, Maxime Chevallier wrote:
>
>
> On 6/30/26 17:13, Nazle Asmade, Muhammad Nazim Amirul wrote:
>
>> Yes, Agilex5 has the same concept. The GMII-to-RGMII converter is a
>> Quartus soft IP instantiated in the FPGA fabric — equivalent to the
>> CycloneV EMAC splitter. The XGMAC outputs GMII signals to the FPGA
>> fabric, the soft IP converts them to RGMII, and the RGMII signals then
>> go through the FPGA HVIO pins to the external Marvell 88E1512 PHY.
>
> Does this converter need any special config, and does it expose any
> control registers ? or is it fully autonomous ?
>
> If it's fully autonomous, can you detect its presence through some
> capability registers or something like that ?
>
>
> Maxime
>
Hi Maxime,
Per my knowledge, the converter is fully autonomous with no control
registers and no software configuration required.
Speed switching is handled entirely in hardware — the XGMAC's mac_speed
output signals are wired directly in the FPGA fabric to the converter's
speed input. No driver intervention is needed on speed changes.
There are no capability registers and no way to detect its presence in
hardware. It is a property of the FPGA design, not the HPS silicon.
BR,
Nazim Amirul
^ permalink raw reply
* [PATCH v4 0/5] Fix traceNoC probe issue on multiple QCOM platforms
From: Jie Gan @ 2026-07-01 1:53 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang, Jingyi Wang, Jie Gan, Abel Vesa,
Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Yuanfang Zhang, Abel Vesa, Alexander Shishkin
Cc: Konrad Dybcio, linux-arm-msm, devicetree, linux-kernel, coresight,
linux-arm-kernel
The CoreSight TNOC (Trace Network-On-Chip) binding so far only allowed the
two-string AMBA form "qcom,coresight-tnoc", "arm,primecell". That form
forces the device onto the AMBA bus, where the driver must read the
peripheral ID from the device registers during probe. On several QCOM
platforms this AMBA peripheral-ID probing fails, so the traceNoC device
never probes and its trace path is unavailable.
This series introduces a standalone "qcom,coresight-agtnoc" compatible
that describes the Aggregator TNOC as a plain platform device. Without
"arm,primecell" the device is created on the platform bus and probes
through the platform driver, bypassing the AMBA peripheral-ID read while
remaining a fully functional Aggregator TNOC that allocates a system
trace ID (ATID).
The series is organized as: binding first, then the driver support for the
new compatible, followed by the per-platform DT fixes that switch the
affected nodes over to it.
- Patch 1 (dt-bindings) converts the compatible to a oneOf and adds the
standalone qcom,coresight-agtnoc form alongside the existing AMBA form,
updates the select block, and adds an example node.
- Patch 2 (driver) adds qcom,coresight-agtnoc to the platform driver's
match table and renames the itnoc-specific names to generic tnoc names,
since the platform driver now serves both the Interconnect and Aggregator
TNOC. It also restricts the ATID-unsupported handling to
qcom,coresight-itnoc only, so the standalone Aggregator TNOC is no longer
wrongly covered and correctly allocates a trace ID.
- Patches 3-4 (kaanapali, sm8750) switch the traceNoC nodes from the AMBA
form to the standalone qcom,coresight-agtnoc compatible, fixing the probe
failure on those platforms.
- Patch 5 (glymur) switches the node from qcom,coresight-itnoc to
qcom,coresight-agtnoc. This node is actually an Aggregator TNOC (its
tn_ag_* endpoints show aggregation), so it should expose a system trace
ID rather than being treated as an Interconnect TNOC.
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
Changes in v4:
- rewrite the commit message for the patch 3 - patch 5.
- free the allocated ATID in remove path.
- Link to v3: https://lore.kernel.org/r/20260630-fix-tracenoc-probe-issue-v3-0-7201e1841e94@oss.qualcomm.com
Changes in v3:
- add standalone compatible for AG traceNoC device, allow it to be
probed with platform driver.
- add fix patches for sm8750 and Glymur platforms
- Link to v2: https://lore.kernel.org/r/20260624-fix-tracenoc-probe-issue-v2-0-786520f62f21@oss.qualcomm.com
Changes in v2:
- address the ATID issue reported by Sashiko.
- update binding to accept arm,primecell-periphid property.
- Link to v1: https://lore.kernel.org/r/20260624-fix-tracenoc-probe-issue-v1-1-bcc785198fc5@oss.qualcomm.com
---
Jie Gan (5):
dt-bindings: arm: coresight-tnoc: Add standalone qcom,coresight-agtnoc compatible
coresight: tnoc: add AG tnoc standalone compatible to the platform driver
arm64: dts: qcom: kaanapali: fix traceNoC probe issue
arm64: dts: qcom: sm8750: fix traceNoC probe issue
arm64: dts: qcom: glymur: use Aggregator TNOC compatible
.../bindings/arm/qcom,coresight-tnoc.yaml | 39 ++++++++++++++++++++--
arch/arm64/boot/dts/qcom/glymur.dtsi | 6 ++--
arch/arm64/boot/dts/qcom/kaanapali.dtsi | 2 +-
arch/arm64/boot/dts/qcom/sm8750.dtsi | 2 +-
drivers/hwtracing/coresight/coresight-tnoc.c | 37 ++++++++++----------
5 files changed, 61 insertions(+), 25 deletions(-)
---
base-commit: 4e5dfb7c84012007c3c7061126491bbc92d71bf1
change-id: 20260624-fix-tracenoc-probe-issue-c6429da28df4
Best regards,
--
Jie Gan <jie.gan@oss.qualcomm.com>
^ permalink raw reply
* [PATCH v4 1/5] dt-bindings: arm: coresight-tnoc: Add standalone qcom,coresight-agtnoc compatible
From: Jie Gan @ 2026-07-01 1:53 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang, Jingyi Wang, Jie Gan, Abel Vesa,
Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Yuanfang Zhang, Abel Vesa, Alexander Shishkin
Cc: Konrad Dybcio, linux-arm-msm, devicetree, linux-kernel, coresight,
linux-arm-kernel
In-Reply-To: <20260701-fix-tracenoc-probe-issue-v4-0-aefab449a470@oss.qualcomm.com>
The TNOC compatible previously only allowed the two-string AMBA form
"qcom,coresight-tnoc", "arm,primecell", which forces the device onto the
AMBA bus.
Convert the compatible to a oneOf and add a standalone
"qcom,coresight-agtnoc" compatible alongside the existing AMBA form. The
standalone string carries no "arm,primecell" entry, so the device is
created on the platform bus instead of the AMBA bus.
Add "qcom,coresight-agtnoc" to the select block so the schema matches
nodes that use only the standalone compatible, and add an example node
demonstrating the standalone form.
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
.../bindings/arm/qcom,coresight-tnoc.yaml | 39 ++++++++++++++++++++--
1 file changed, 36 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-tnoc.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-tnoc.yaml
index ef648a15b806..7e6e4b17a6c1 100644
--- a/Documentation/devicetree/bindings/arm/qcom,coresight-tnoc.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom,coresight-tnoc.yaml
@@ -29,6 +29,7 @@ select:
contains:
enum:
- qcom,coresight-tnoc
+ - qcom,coresight-agtnoc
required:
- compatible
@@ -37,9 +38,11 @@ properties:
pattern: "^tn(@[0-9a-f]+)$"
compatible:
- items:
- - const: qcom,coresight-tnoc
- - const: arm,primecell
+ oneOf:
+ - items:
+ - const: qcom,coresight-tnoc
+ - const: arm,primecell
+ - const: qcom,coresight-agtnoc
reg:
maxItems: 1
@@ -110,4 +113,34 @@ examples:
};
};
};
+
+ - |
+ tn@10980000 {
+ compatible = "qcom,coresight-agtnoc";
+ reg = <0x10980000 0x4200>;
+
+ clocks = <&aoss_qmp>;
+ clock-names = "apb_pclk";
+
+ in-ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ tn_ag_in_tpdm_mss: endpoint {
+ remote-endpoint = <&tpdm_mss_out_tn_ag>;
+ };
+ };
+ };
+
+ out-ports {
+ port {
+ tn_ag_out_funnel_in2: endpoint {
+ remote-endpoint = <&funnel_in2_in_tn_ag>;
+ };
+ };
+ };
+ };
...
--
2.34.1
^ permalink raw reply related
* [PATCH v4 2/5] coresight: tnoc: add AG tnoc standalone compatible to the platform driver
From: Jie Gan @ 2026-07-01 1:53 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang, Jingyi Wang, Jie Gan, Abel Vesa,
Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Yuanfang Zhang, Abel Vesa, Alexander Shishkin
Cc: Konrad Dybcio, linux-arm-msm, devicetree, linux-kernel, coresight,
linux-arm-kernel
In-Reply-To: <20260701-fix-tracenoc-probe-issue-v4-0-aefab449a470@oss.qualcomm.com>
The Aggregator TNOC can be described either as an AMBA device using the
"qcom,coresight-tnoc", "arm,primecell" compatible or as a standalone
platform device using the new "qcom,coresight-agtnoc" compatible. The
latter avoids the AMBA bus and the associated peripheral-ID probing.
Add "qcom,coresight-agtnoc" to the platform driver's match table so the
Aggregator TNOC can probe through the platform driver, and rename the
platform driver and its callbacks from the "itnoc"-specific names to
generic "tnoc" names, since the driver now serves both the Interconnect
and Aggregator TNOC. The platform driver name is updated to
"coresight-tnoc" accordingly.
Restrict the ATID-unsupported handling to the Interconnect TNOC. The
previous check disabled ATID for every non-AMBA device, which would
wrongly cover the standalone Aggregator TNOC. Only "qcom,coresight-itnoc"
lacks aggregation and ATID functionality, so key the check on that
compatible and let every other form allocate a trace ID.
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
drivers/hwtracing/coresight/coresight-tnoc.c | 37 +++++++++++++++-------------
1 file changed, 20 insertions(+), 17 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-tnoc.c b/drivers/hwtracing/coresight/coresight-tnoc.c
index 9e8de4323d28..4ccd5f38b92a 100644
--- a/drivers/hwtracing/coresight/coresight-tnoc.c
+++ b/drivers/hwtracing/coresight/coresight-tnoc.c
@@ -130,7 +130,7 @@ static int trace_noc_init_default_data(struct trace_noc_drvdata *drvdata)
{
int atid;
- if (!dev_is_amba(drvdata->dev)) {
+ if (of_device_is_compatible(drvdata->dev->of_node, "qcom,coresight-itnoc")) {
drvdata->atid = -EOPNOTSUPP;
return 0;
}
@@ -278,7 +278,7 @@ static struct amba_driver trace_noc_driver = {
.id_table = trace_noc_ids,
};
-static int itnoc_probe(struct platform_device *pdev)
+static int tnoc_platform_probe(struct platform_device *pdev)
{
struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
int ret;
@@ -295,16 +295,18 @@ static int itnoc_probe(struct platform_device *pdev)
return ret;
}
-static void itnoc_remove(struct platform_device *pdev)
+static void tnoc_platform_remove(struct platform_device *pdev)
{
struct trace_noc_drvdata *drvdata = platform_get_drvdata(pdev);
coresight_unregister(drvdata->csdev);
pm_runtime_disable(&pdev->dev);
+ if (drvdata->atid > 0)
+ coresight_trace_id_put_system_id(drvdata->atid);
}
#ifdef CONFIG_PM
-static int itnoc_runtime_suspend(struct device *dev)
+static int tnoc_runtime_suspend(struct device *dev)
{
struct trace_noc_drvdata *drvdata = dev_get_drvdata(dev);
@@ -313,7 +315,7 @@ static int itnoc_runtime_suspend(struct device *dev)
return 0;
}
-static int itnoc_runtime_resume(struct device *dev)
+static int tnoc_runtime_resume(struct device *dev)
{
struct trace_noc_drvdata *drvdata = dev_get_drvdata(dev);
@@ -321,35 +323,36 @@ static int itnoc_runtime_resume(struct device *dev)
}
#endif
-static const struct dev_pm_ops itnoc_dev_pm_ops = {
- SET_RUNTIME_PM_OPS(itnoc_runtime_suspend, itnoc_runtime_resume, NULL)
+static const struct dev_pm_ops tnoc_dev_pm_ops = {
+ SET_RUNTIME_PM_OPS(tnoc_runtime_suspend, tnoc_runtime_resume, NULL)
};
-static const struct of_device_id itnoc_of_match[] = {
+static const struct of_device_id tnoc_of_match[] = {
{ .compatible = "qcom,coresight-itnoc" },
+ { .compatible = "qcom,coresight-agtnoc" },
{}
};
-MODULE_DEVICE_TABLE(of, itnoc_of_match);
+MODULE_DEVICE_TABLE(of, tnoc_of_match);
-static struct platform_driver itnoc_driver = {
- .probe = itnoc_probe,
- .remove = itnoc_remove,
+static struct platform_driver tnoc_platform_driver = {
+ .probe = tnoc_platform_probe,
+ .remove = tnoc_platform_remove,
.driver = {
- .name = "coresight-itnoc",
- .of_match_table = itnoc_of_match,
+ .name = "coresight-tnoc",
+ .of_match_table = tnoc_of_match,
.suppress_bind_attrs = true,
- .pm = &itnoc_dev_pm_ops,
+ .pm = &tnoc_dev_pm_ops,
},
};
static int __init tnoc_init(void)
{
- return coresight_init_driver("tnoc", &trace_noc_driver, &itnoc_driver);
+ return coresight_init_driver("tnoc", &trace_noc_driver, &tnoc_platform_driver);
}
static void __exit tnoc_exit(void)
{
- coresight_remove_driver(&trace_noc_driver, &itnoc_driver);
+ coresight_remove_driver(&trace_noc_driver, &tnoc_platform_driver);
}
module_init(tnoc_init);
module_exit(tnoc_exit);
--
2.34.1
^ permalink raw reply related
* [PATCH v4 3/5] arm64: dts: qcom: kaanapali: fix traceNoC probe issue
From: Jie Gan @ 2026-07-01 1:53 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang, Jingyi Wang, Jie Gan, Abel Vesa,
Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Yuanfang Zhang, Abel Vesa, Alexander Shishkin
Cc: Konrad Dybcio, linux-arm-msm, devicetree, linux-kernel, coresight,
linux-arm-kernel
In-Reply-To: <20260701-fix-tracenoc-probe-issue-v4-0-aefab449a470@oss.qualcomm.com>
The traceNoC node used the "qcom,coresight-tnoc", "arm,primecell"
compatible, which places the device on the AMBA bus. To bind an AMBA
device, the bus first reads the peripheral and component ID registers
(PID/CID) at the top of the device's register block and matches them
against the primecell ID. On this platform the traceNoC does not expose
a valid CID in that register, so the read never yields the expected
primecell value, the AMBA match fails, and the device is left stuck in
deferred probe indefinitely.
The Aggregator TNOC is fully described by the "qcom,coresight-agtnoc"
compatible, which binds via the platform driver by compatible string and
does not rely on reading the primecell ID register at all. Switch the
node to that standalone compatible so the device probes on hardware that
does not expose a readable CID, while remaining an Aggregator TNOC that
retains ATID functionality.
Fixes: f73959d86c15 ("arm64: dts: qcom: kaanapali: add coresight nodes")
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/kaanapali.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
index 7aa9653bd456..e98f4aa4b141 100644
--- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
+++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
@@ -5004,7 +5004,7 @@ tpdm_pcie_rscc_out: endpoint {
};
tn@111b8000 {
- compatible = "qcom,coresight-tnoc", "arm,primecell";
+ compatible = "qcom,coresight-agtnoc";
reg = <0x0 0x111b8000 0x0 0x4200>;
clocks = <&aoss_qmp>;
--
2.34.1
^ permalink raw reply related
* [PATCH v4 4/5] arm64: dts: qcom: sm8750: fix traceNoC probe issue
From: Jie Gan @ 2026-07-01 1:53 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang, Jingyi Wang, Jie Gan, Abel Vesa,
Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Yuanfang Zhang, Abel Vesa, Alexander Shishkin
Cc: Konrad Dybcio, linux-arm-msm, devicetree, linux-kernel, coresight,
linux-arm-kernel
In-Reply-To: <20260701-fix-tracenoc-probe-issue-v4-0-aefab449a470@oss.qualcomm.com>
The traceNoC node used the "qcom,coresight-tnoc", "arm,primecell"
compatible, which places the device on the AMBA bus. To bind an AMBA
device, the bus first reads the peripheral and component ID registers
(PID/CID) at the top of the device's register block and matches them
against the primecell ID. On this platform the traceNoC does not expose
a valid CID in that register, so the read never yields the expected
primecell value, the AMBA match fails, and the device is left stuck in
deferred probe indefinitely.
The Aggregator TNOC is fully described by the "qcom,coresight-agtnoc"
compatible, which binds via the platform driver by compatible string and
does not rely on reading the primecell ID register at all. Switch the
node to that standalone compatible so the device probes on hardware that
does not expose a readable CID, while remaining an Aggregator TNOC that
retains ATID functionality.
Fixes: ebd1eb365cae ("arm64: qcom: dts: sm8750: add coresight nodes")
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/sm8750.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8750.dtsi b/arch/arm64/boot/dts/qcom/sm8750.dtsi
index fafed417c66f..d58483f9f93a 100644
--- a/arch/arm64/boot/dts/qcom/sm8750.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8750.dtsi
@@ -4687,7 +4687,7 @@ tpdm_rdpm_cmb2_out: endpoint {
};
tn@109ab000 {
- compatible = "qcom,coresight-tnoc", "arm,primecell";
+ compatible = "qcom,coresight-agtnoc";
reg = <0x0 0x109ab000 0x0 0x4200>;
clocks = <&aoss_qmp>;
--
2.34.1
^ permalink raw reply related
* [PATCH v4 5/5] arm64: dts: qcom: glymur: use Aggregator TNOC compatible
From: Jie Gan @ 2026-07-01 1:53 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang, Jingyi Wang, Jie Gan, Abel Vesa,
Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Yuanfang Zhang, Abel Vesa, Alexander Shishkin
Cc: Konrad Dybcio, linux-arm-msm, devicetree, linux-kernel, coresight,
linux-arm-kernel
In-Reply-To: <20260701-fix-tracenoc-probe-issue-v4-0-aefab449a470@oss.qualcomm.com>
The traceNoC node is the system-level Aggregator TNOC, so it must own a
valid ATID that tags the whole aggregation path. It is marked compatible
with "qcom,coresight-itnoc", an Interconnect TNOC, which is never
assigned an ATID. As a result the aggregator has no trace ID and cannot
tag the merged trace.
An Interconnect TNOC is a subsystem-level aggregator: it merges trace
from the ATB sources within its subsystem (TPDMs and other ATB masters)
and forwards the combined stream to the system-level Aggregator TNOC. It
carries no ATID of its own, because the Aggregator TNOC downstream in the
path already owns the ATID.
Switch the node to "qcom,coresight-agtnoc" so it is described as the
Aggregator TNOC it is and is assigned a system trace ID. Rename the node
to "tn" and use the "apb_pclk" clock name as required by the Aggregator
TNOC binding.
Fixes: 1f7d0c42a08d ("arm64: dts: qcom: glymur: add coresight nodes")
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/glymur.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
index 20b49af7298e..d612e8ed54c8 100644
--- a/arch/arm64/boot/dts/qcom/glymur.dtsi
+++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
@@ -6038,12 +6038,12 @@ qm_tpdm_out: endpoint {
};
};
- itnoc@11200000 {
- compatible = "qcom,coresight-itnoc";
+ tn@11200000 {
+ compatible = "qcom,coresight-agtnoc";
reg = <0x0 0x11200000 0x0 0x3c00>;
clocks = <&aoss_qmp>;
- clock-names = "apb";
+ clock-names = "apb_pclk";
in-ports {
#address-cells = <1>;
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v14 00/44] arm64: Support for Arm CCA in KVM
From: Kohei Enju @ 2026-07-01 2:15 UTC (permalink / raw)
To: Steven Price
Cc: kvm, kvmarm, Catalin Marinas, Marc Zyngier, Will Deacon,
James Morse, Oliver Upton, Suzuki K Poulose, Zenghui Yu,
linux-arm-kernel, linux-kernel, Joey Gouly, Alexandru Elisei,
Christoffer Dall, Fuad Tabba, linux-coco, Ganapatrao Kulkarni,
Gavin Shan, Shanker Donthineni, Alper Gun, Aneesh Kumar K . V,
Emi Kisanuki, Vishal Annapurve, WeiLin.Chang, Lorenzo.Pieralisi2
In-Reply-To: <20260513131757.116630-1-steven.price@arm.com>
On 05/13 14:17, Steven Price wrote:
> This series adds support for running protected VMs using KVM under the
> Arm Confidential Compute Architecture (CCA).
>
> This is rebased on v7.1-rc1, but still targets RMM v2.0-bet1[1].
>
> The major updates from v13 remain but have been more fully implemented:
> the RMM uses the host's page size, range based RMI APIs mean we don't
> have to break everything down to base page sizes, the GIC state is
> passed via system registers, and the uAPI has been simplified.
>
> The main changes since v13 are:
>
> * The RMI definitions and wrappers have been fully updated for RMM
> v2.0-bet1. In particular the temporary RMM v1.0 SMC compatibility
> patch has been dropped.
>
> * The PSCI completion ioctl has been removed. RMM v2.0-bet1 still
> requires the host to provide the target REC for PSCI calls which
> name another vCPU, but KVM now performs the RMI PSCI completion
> automatically before entering the REC again. Userspace no longer
> needs to issue KVM_ARM_VCPU_RMI_PSCI_COMPLETE. A future spec should
> remove the need for the host to provide the MPIDR mapping.
>
> * The generic RMI init, RMM configuration, GPT setup,
> delegate/undelegate helpers and SRO infrastructure have moved out of
> KVM into arch/arm64/kernel/rmi.c. RMI is expected to be used by
> features outside KVM, so this code should be available even when KVM
> is not built.
>
> * RMI_GRANULE_TRACKING_GET has been updated to work on a range, this
> allows it to work when the region is not aligned to the tracking
> size. Solves the problem reported by Mathieu[2].
>
> * SRO support has been moved earlier in the series and improved. It
> provides a cleaner way for the host to provide the RMM with the extra
> memory it requires. However support is still incomplete where the
> TF-RMM code does not yet implement it. This is noted by FIXMEs in the
> code.
>
> * The ARM VM type encoding has been reworked to coexist with the
> upstream pKVM KVM_VM_TYPE_ARM_PROTECTED bit.
>
> * The private-memory documentation now notes that arm64 uses
> KVM_CAP_MEMORY_ATTRIBUTES.
>
> * PMU support is dropped for now. It will be added later in a separate
> series. Similarly for selecting the hash algorithm and RPV.
Hi Steven,
Is there any plan to add support for selecting the MEC policy (shared or
private)? We have been working on adding support for this on top of your
series. If this is not already in the works, we may upstream our
implementation later.
Thanks,
Kohei
>
> There are also the usual rebase updates and smaller fixes, including
> changes to the RMM v2.0-bet1 range APIs, removal of REC auxiliary
> granule handling, fixes to the address range descriptor encoding, and
> cleanups around realm stage-2 teardown.
>
> Stateful RMI Operations
> -----------------------
>
> The RMM v2.0 spec introduces Stateful RMI Operations (SROs), which allow
> the RMM to complete an operation over several SMC calls while requesting
> or returning memory to the host. This allows interrupts to be handled in
> the middle of an operation and lets the RMM dynamically allocate memory
> for internal tracking purposes. For example, RMI_REC_CREATE no longer
> needs auxiliary granules to be provided up front, and can instead
> request memory during the operation.
>
> This series includes the generic SRO infrastructure in
> arch/arm64/kernel/rmi.c and uses it for REC create/destroy. The other
> cases are not yet used by TF-RMM and a future revision will be needed to
> finish those paths in Linux.
>
> This series is based on v7.1-rc1. It is also available as a git
> repository:
>
> https://gitlab.arm.com/linux-arm/linux-cca cca-host/v14
>
> Work in progress changes for kvmtool are available from the git
> repository below:
>
> https://gitlab.arm.com/linux-arm/kvmtool-cca cca/v12
>
> The TF-RMM has not yet merged the RMM v2.0 support, so you will need to
> use a branch with RMM v2.0-bet1 support. At the time of writing the
> following branch is being used:
>
> https://git.trustedfirmware.org/TF-RMM/tf-rmm.git topics/rmm-v2.0-poc_2
> (tested on commit 3340667a291a)
>
> There is a kvm-unit-test branch which has been updated to support the
> attestation used in RMMv2.0 available here:
>
> https://gitlab.arm.com/linux-arm/kvm-unit-tests-cca cca/v4
>
> [1] https://developer.arm.com/documentation/den0137/2-0bet1/
> [2] https://lore.kernel.org/all/acrj-cKphy4hJsEG@p14s/
^ permalink raw reply
* RE: [PATCH V4 2/8] PCI: imx6: Add skip_pwrctrl_off flag support
From: Sherry Sun @ 2026-07-01 2:21 UTC (permalink / raw)
To: Bjorn Helgaas, Sherry Sun (OSS)
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
Frank Li, s.hauer@pengutronix.de, kernel@pengutronix.de,
festevam@gmail.com, Amitkumar Karwar, Neeraj Sanjay Kale,
marcel@holtmann.org, luiz.dentz@gmail.com, Hongxing Zhu,
l.stach@pengutronix.de, lpieralisi@kernel.org,
kwilczynski@kernel.org, mani@kernel.org, bhelgaas@google.com,
brgl@kernel.org, imx@lists.linux.dev, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-bluetooth@vger.kernel.org,
linux-pm@vger.kernel.org, Ryder Lee,
linux-mediatek@lists.infradead.org
In-Reply-To: <20260630174316.GA162203@bhelgaas>
> Subject: Re: [PATCH V4 2/8] PCI: imx6: Add skip_pwrctrl_off flag support
>
> [+cc Mediatek folks]
>
> On Tue, Jun 30, 2026 at 06:31:33PM +0800, Sherry Sun (OSS) wrote:
> > From: Sherry Sun <sherry.sun@nxp.com>
> >
> > Use dw_pcie_rp::skip_pwrctrl_off to avoid powering off devices during
> > suspend to preserve wakeup capability of the devices and also not to
> > power on the devices in the init path.
>
> Only pci-imx6.c, pcie-qcom.c, and pcie-mediatek-gen3.c use pci-pwrctrl. pcie-
> qcom.c already has similar skip_pwrctrl_off checks, but pcie-mediatek-gen3.c
> does not. Does it need them?
I think that's depends on if the controller have the usercases such as M.2 keyE
connector without auxiliary power and required to support PCIe L2 link state
and wake-up mechanisms.
Best Regards
Sherry
^ permalink raw reply
* [PATCH v3] phy: Add USB3 PHY support to Google Tensor SoC USB PHY driver
From: RD Babiera @ 2026-07-01 2:28 UTC (permalink / raw)
To: vkoul, peter.griffin, andre.draszik, tudor.ambarus, p.zabel,
neil.armstrong
Cc: badhri, linux-arm-kernel, linux-samsung-soc, linux-phy,
linux-kernel, RD Babiera
Add USB3 PHY support for the Google Tensor G5 USB PHY driver.
This patch adds functionality for the usb3_tca register, usb3 clock,
and usb3 reset as defined in google,lga-usb-phy.yaml. Kconfig now lists
USB SuperSpeed support.
Refactor the probe sequence to initialize the USB2 and USB3 PHYs, and then
initialize clocks and resets for both PHYs afterwards.
Refactor set_vbus_valid to reduce duplicated code.
Implement USB3 phy_ops for phy_init, phy_exit, and phy_power_on.
combo_phy_state enum is added to track PHY bringup state across
PHY API calls.
Signed-off-by: RD Babiera <rdbabiera@google.com>
---
Changes since v1:
* Removed mix of goto-based and scope-based cleanup from usb3 phy_init
* Removed unused usb3_core resource from probe
* Added combo_phy_state enum to interally track ComboPHY bringup state
to allow google_usb_set_orientation() to change TCA orientation.
* Modify Kconfig documentation to reflect SuperSpeed support
Changes since v2:
* google_usb3_phy_init now sets USBDP_TOP_CFG_REG_PMGT_REF_CLK_REQ_N
to false if phy_init fails elsewhere.
* google_usb3_phy_init errors are now handled via DEFINE_FREE structures.
This affects set_pmgt_ref_clk_req_n, clk_bulk_prepare_enable, and
reset_control_bulk_deassert.
* google_usb2_phy_init also handles undoing clk_bulk_prepare_enable via
DEFINE_FREE structure.
* google_usb3_phy_power_on allows program_tca_locked in the
COMBO_PHY_TCA_READY state. Waiting for PoR=>NC is only performed once.
* Note: there are checkpatch errors for the DEFINE_FREE macros resulting
in "ERROR: trailing statements should be on next line". Other cases of
DEFINE_FREE where the line limit would otherwise exceed 100 columns
have the indentation done the same way.
---
drivers/phy/Kconfig | 2 +-
drivers/phy/phy-google-usb.c | 404 +++++++++++++++++++++++++++++++----
2 files changed, 368 insertions(+), 38 deletions(-)
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 19f3b7d12b7d..d2d401129af7 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -100,7 +100,7 @@ config PHY_GOOGLE_USB
the G5 generation (Laguna). This driver provides the PHY interfaces
to interact with the SNPS eUSB2 and USB 3.2/DisplayPort Combo PHY,
both of which are integrated with the DWC3 USB DRD controller.
- This driver currently supports USB high-speed.
+ This driver currently supports USB high-speed and SuperSpeed.
config USB_LGM_PHY
tristate "INTEL Lightning Mountain USB PHY Driver"
diff --git a/drivers/phy/phy-google-usb.c b/drivers/phy/phy-google-usb.c
index ab20bc20f19e..610e3b6f465f 100644
--- a/drivers/phy/phy-google-usb.c
+++ b/drivers/phy/phy-google-usb.c
@@ -20,6 +20,7 @@
#include <linux/reset.h>
#include <linux/usb/typec_mux.h>
+/* USB_CFG_CSR */
#define USBCS_USB2PHY_CFG19_OFFSET 0x0
#define USBCS_USB2PHY_CFG19_PHY_CFG_PLL_FB_DIV GENMASK(19, 8)
@@ -28,11 +29,41 @@
#define USBCS_USB2PHY_CFG21_REF_FREQ_SEL GENMASK(15, 13)
#define USBCS_USB2PHY_CFG21_PHY_TX_DIG_BYPASS_SEL BIT(19)
+/* USBDP_TOP */
#define USBCS_PHY_CFG1_OFFSET 0x28
+#define USBCS_PHY_CFG1_PHY0_MPLLA_SSC_EN BIT(1)
+#define USBCS_PHY_CFG1_PHY0_SRAM_BYPASS_MODE GENMASK(11, 10)
+#define SRAM_BYPASS_MODE_BYPASS_FIRMWARE BIT(0)
+#define SRAM_BYPASS_MODE_BYPASS_CONTEXT BIT(1)
#define USBCS_PHY_CFG1_SYS_VBUSVALID BIT(17)
+#define USBDP_TOP_CFG_REG_OFFSET 0x44
+#define USBDP_TOP_CFG_REG_PMGT_REF_CLK_REQ_N BIT(0)
+
+#define PHY_POWER_CONFIG_REG1_OFFSET 0x48
+#define PHY_POWER_CONFIG_REG1_PG_MODE_EN BIT(1)
+#define PHY_POWER_CONFIG_REG1_UPCS_PIPE_CONFIG GENMASK(31, 14)
+#define UPCS_PIPE_CONFIG_ISO_CPM BIT(5)
+#define UPCS_PIPE_CONFIG_PG_MODE_STATIC BIT(6)
+#define UPCS_PIPE_CONFIG_LANE_RESET_NO_PG_EXIT BIT(9)
+
+/* USB3_TCA */
+#define TCA_INTR_STS_OFFSET 0x8
+#define TCA_INTR_STS_XA_ACT_EVT BIT(0)
+#define TCA_TCPC_OFFSET 0x14
+#define TCA_TCPC_MUX_CONTROL GENMASK(2, 0)
+#define TCA_TCPC_MUX_CONTROL_USB_ONLY 0x1
+#define TCA_TCPC_CONNECTOR_ORIENTATION BIT(3)
+#define TCA_TCPC_VALID BIT(4)
+#define TCA_PSTATE_0_OFFSET 0x50
+#define TCA_PSTATE_0_UPCS_LANE0_PHYSTATUS BIT(8)
+
+#define GPHY_TCA_DELAY_US 10
+#define GPHY_TCA_TIMEOUT_US 2500000
+
enum google_usb_phy_id {
GOOGLE_USB2_PHY,
+ GOOGLE_USB3_PHY,
GOOGLE_USB_PHY_NUM,
};
@@ -46,34 +77,172 @@ struct google_usb_phy_instance {
struct reset_control_bulk_data *rsts;
};
+struct google_usb_phy_config {
+ const char * const *clk_names;
+ unsigned int num_clks;
+ const char * const *rst_names;
+ unsigned int num_rsts;
+};
+
+static const char * const u2phy_clk_names[] = {
+ "usb2",
+ "usb2_apb",
+};
+static const char * const u3phy_clk_names[] = {
+ "usb3"
+};
+static const char * const u2phy_rst_names[] = {
+ "usb2",
+ "usb2_apb",
+};
+static const char * const u3phy_rst_names[] = {
+ "usb3"
+};
+
+static const struct google_usb_phy_config phy_configs[GOOGLE_USB_PHY_NUM] = {
+ [GOOGLE_USB2_PHY] = {
+ .clk_names = u2phy_clk_names,
+ .num_clks = ARRAY_SIZE(u2phy_clk_names),
+ .rst_names = u2phy_rst_names,
+ .num_rsts = ARRAY_SIZE(u2phy_rst_names),
+ },
+ [GOOGLE_USB3_PHY] = {
+ .clk_names = u3phy_clk_names,
+ .num_clks = ARRAY_SIZE(u3phy_clk_names),
+ .rst_names = u3phy_rst_names,
+ .num_rsts = ARRAY_SIZE(u3phy_rst_names),
+ },
+};
+
+static inline void google_usb_phy_clk_disable(struct google_usb_phy_instance *inst)
+{
+ clk_bulk_disable_unprepare(inst->num_clks, inst->clks);
+}
+DEFINE_FREE(inst_clk_disable, struct google_usb_phy_instance *,
+ if (_T) google_usb_phy_clk_disable(_T))
+
+static inline void google_usb_phy_rst_disable(struct google_usb_phy_instance *inst)
+{
+ reset_control_bulk_assert(inst->num_rsts, inst->rsts);
+}
+DEFINE_FREE(inst_rst_disable, struct google_usb_phy_instance *,
+ if (_T) google_usb_phy_rst_disable(_T))
+
+/*
+ * combo_phy_state
+ * COMBO_PHY_IDLE: The ComboPHY has been torn down and USB3 has not completed
+ * bringup
+ * COMBO_PHY_INIT_DONE: The ComboPHY bringup sequence is complete.
+ * COMBO_PHY_TCA_READY: The PoR => NC transition is complete, and the TCA can be
+ * moved into USB.
+ */
+enum combo_phy_state {
+ COMBO_PHY_IDLE,
+ COMBO_PHY_INIT_DONE,
+ COMBO_PHY_TCA_READY,
+};
+
struct google_usb_phy {
struct device *dev;
struct regmap *usb_cfg_regmap;
unsigned int usb2_cfg_offset;
void __iomem *usbdp_top_base;
+ void __iomem *usb3_tca_base;
struct google_usb_phy_instance *insts;
/*
* Protect phy registers from concurrent access, specifically via
- * google_usb_set_orientation callback.
+ * google_usb_set_orientation callback. phy_mutex also protects
+ * concurrent access to phy_state.
*/
struct mutex phy_mutex;
struct typec_switch_dev *sw;
enum typec_orientation orientation;
+ enum combo_phy_state phy_state;
};
static void set_vbus_valid(struct google_usb_phy *gphy)
{
u32 reg;
- if (gphy->orientation == TYPEC_ORIENTATION_NONE) {
- reg = readl(gphy->usbdp_top_base + USBCS_PHY_CFG1_OFFSET);
+ reg = readl(gphy->usbdp_top_base + USBCS_PHY_CFG1_OFFSET);
+ if (gphy->orientation == TYPEC_ORIENTATION_NONE)
reg &= ~USBCS_PHY_CFG1_SYS_VBUSVALID;
- writel(reg, gphy->usbdp_top_base + USBCS_PHY_CFG1_OFFSET);
- } else {
- reg = readl(gphy->usbdp_top_base + USBCS_PHY_CFG1_OFFSET);
+ else
reg |= USBCS_PHY_CFG1_SYS_VBUSVALID;
- writel(reg, gphy->usbdp_top_base + USBCS_PHY_CFG1_OFFSET);
- }
+ writel(reg, gphy->usbdp_top_base + USBCS_PHY_CFG1_OFFSET);
+}
+
+static void set_sram_bypass(struct google_usb_phy *gphy, u32 bypass)
+{
+ u32 reg;
+
+ reg = readl(gphy->usbdp_top_base + USBCS_PHY_CFG1_OFFSET);
+ reg &= ~USBCS_PHY_CFG1_PHY0_SRAM_BYPASS_MODE;
+ reg |= FIELD_PREP(USBCS_PHY_CFG1_PHY0_SRAM_BYPASS_MODE, bypass);
+ writel(reg, gphy->usbdp_top_base + USBCS_PHY_CFG1_OFFSET);
+}
+
+static void set_pmgt_ref_clk_req_n(struct google_usb_phy *gphy, bool resume)
+{
+ u32 reg;
+
+ reg = readl(gphy->usbdp_top_base + USBDP_TOP_CFG_REG_OFFSET);
+ if (resume)
+ reg |= USBDP_TOP_CFG_REG_PMGT_REF_CLK_REQ_N;
+ else
+ reg &= ~USBDP_TOP_CFG_REG_PMGT_REF_CLK_REQ_N;
+ writel(reg, gphy->usbdp_top_base + USBDP_TOP_CFG_REG_OFFSET);
+}
+
+static inline void disable_pmgt_ref_clk_req_n(struct google_usb_phy *gphy)
+{
+ set_pmgt_ref_clk_req_n(gphy, false);
+}
+DEFINE_FREE(pmgt_ref_clk_req_n, struct google_usb_phy *, if (_T) disable_pmgt_ref_clk_req_n(_T))
+
+static int wait_tca_xa_ack(struct google_usb_phy *gphy)
+{
+ int ret;
+ u32 reg;
+
+ ret = readl_poll_timeout(gphy->usb3_tca_base + TCA_INTR_STS_OFFSET,
+ reg, !!(reg & TCA_INTR_STS_XA_ACT_EVT),
+ GPHY_TCA_DELAY_US, GPHY_TCA_TIMEOUT_US);
+ if (ret)
+ dev_err(gphy->dev, "tca xa_ack timeout, ret=%d", ret);
+
+ return ret;
+}
+
+static int program_tca_locked(struct google_usb_phy *gphy)
+ __must_hold(&gphy->phy_mutex)
+{
+ int ret;
+ u32 reg;
+
+ reg = readl(gphy->usb3_tca_base + TCA_INTR_STS_OFFSET);
+ writel(reg, gphy->usb3_tca_base + TCA_INTR_STS_OFFSET);
+
+ reg = readl(gphy->usb3_tca_base + TCA_TCPC_OFFSET);
+ reg &= ~TCA_TCPC_MUX_CONTROL;
+ reg |= FIELD_PREP(TCA_TCPC_MUX_CONTROL, TCA_TCPC_MUX_CONTROL_USB_ONLY);
+ if (gphy->orientation == TYPEC_ORIENTATION_REVERSE)
+ reg |= TCA_TCPC_CONNECTOR_ORIENTATION;
+ else
+ reg &= ~TCA_TCPC_CONNECTOR_ORIENTATION;
+ reg |= TCA_TCPC_VALID;
+ writel(reg, gphy->usb3_tca_base + TCA_TCPC_OFFSET);
+
+ ret = wait_tca_xa_ack(gphy);
+ dev_dbg(gphy->dev, "TCA switch %s, mux %lu, orientation %s",
+ ret ? "failed" : "success",
+ FIELD_GET(TCA_TCPC_MUX_CONTROL, reg),
+ FIELD_GET(TCA_TCPC_CONNECTOR_ORIENTATION, reg) ? "reverse" : "normal");
+
+ reg = readl(gphy->usb3_tca_base + TCA_INTR_STS_OFFSET);
+ writel(reg, gphy->usb3_tca_base + TCA_INTR_STS_OFFSET);
+
+ return ret;
}
static int google_usb_set_orientation(struct typec_switch_dev *sw,
@@ -92,6 +261,9 @@ static int google_usb_set_orientation(struct typec_switch_dev *sw,
set_vbus_valid(gphy);
+ if (gphy->phy_state == COMBO_PHY_TCA_READY && orientation != TYPEC_ORIENTATION_NONE)
+ return program_tca_locked(gphy);
+
return 0;
}
@@ -122,17 +294,18 @@ static int google_usb2_phy_init(struct phy *_phy)
ret = clk_bulk_prepare_enable(inst->num_clks, inst->clks);
if (ret)
return ret;
+ struct google_usb_phy_instance *clk_dev __free(inst_clk_disable) = inst;
ret = reset_control_bulk_deassert(inst->num_rsts, inst->rsts);
- if (ret) {
- clk_bulk_disable_unprepare(inst->num_clks, inst->clks);
+ if (ret)
return ret;
- }
regmap_read(gphy->usb_cfg_regmap, gphy->usb2_cfg_offset + USBCS_USB2PHY_CFG21_OFFSET, ®);
reg |= USBCS_USB2PHY_CFG21_PHY_ENABLE;
regmap_write(gphy->usb_cfg_regmap, gphy->usb2_cfg_offset + USBCS_USB2PHY_CFG21_OFFSET, reg);
+ retain_and_null_ptr(clk_dev);
+
return 0;
}
@@ -161,6 +334,116 @@ static const struct phy_ops google_usb2_phy_ops = {
.exit = google_usb2_phy_exit,
};
+static int google_usb3_phy_init(struct phy *_phy)
+{
+ struct google_usb_phy_instance *inst = phy_get_drvdata(_phy);
+ struct google_usb_phy *gphy = inst->parent;
+ int ret = 0;
+ u32 reg;
+
+ dev_dbg(gphy->dev, "initializing usb3 phy\n");
+
+ guard(mutex)(&gphy->phy_mutex);
+
+ if (gphy->phy_state != COMBO_PHY_IDLE) {
+ dev_warn(gphy->dev, "usb3 phy init called when combo phy state is not idle");
+ return 0;
+ }
+
+ reg = readl(gphy->usbdp_top_base + PHY_POWER_CONFIG_REG1_OFFSET);
+ reg |= PHY_POWER_CONFIG_REG1_PG_MODE_EN;
+ reg &= ~PHY_POWER_CONFIG_REG1_UPCS_PIPE_CONFIG;
+ reg |= FIELD_PREP(PHY_POWER_CONFIG_REG1_UPCS_PIPE_CONFIG,
+ (UPCS_PIPE_CONFIG_ISO_CPM |
+ UPCS_PIPE_CONFIG_PG_MODE_STATIC |
+ UPCS_PIPE_CONFIG_LANE_RESET_NO_PG_EXIT));
+ writel(reg, gphy->usbdp_top_base + PHY_POWER_CONFIG_REG1_OFFSET);
+
+ set_vbus_valid(gphy);
+
+ reg = readl(gphy->usbdp_top_base + USBCS_PHY_CFG1_OFFSET);
+ reg |= USBCS_PHY_CFG1_PHY0_MPLLA_SSC_EN;
+ writel(reg, gphy->usbdp_top_base + USBCS_PHY_CFG1_OFFSET);
+
+ set_sram_bypass(gphy, SRAM_BYPASS_MODE_BYPASS_FIRMWARE |
+ SRAM_BYPASS_MODE_BYPASS_CONTEXT);
+ set_pmgt_ref_clk_req_n(gphy, true);
+ struct google_usb_phy *pmgt_ref_clk_req_dev __free(pmgt_ref_clk_req_n) = gphy;
+
+ ret = clk_bulk_prepare_enable(inst->num_clks, inst->clks);
+ if (ret)
+ return ret;
+ struct google_usb_phy_instance *clk_dev __free(inst_clk_disable) = inst;
+
+ ret = reset_control_bulk_deassert(inst->num_rsts, inst->rsts);
+ if (ret)
+ return ret;
+ struct google_usb_phy_instance *rst_dev __free(inst_rst_disable) = inst;
+
+ ret = readl_poll_timeout(gphy->usb3_tca_base + TCA_PSTATE_0_OFFSET,
+ reg, !(reg & TCA_PSTATE_0_UPCS_LANE0_PHYSTATUS),
+ GPHY_TCA_DELAY_US, GPHY_TCA_TIMEOUT_US);
+ if (ret) {
+ dev_err(gphy->dev, "wait for lane0 phystatus timed out");
+ return ret;
+ }
+
+ gphy->phy_state = COMBO_PHY_INIT_DONE;
+
+ retain_and_null_ptr(rst_dev);
+ retain_and_null_ptr(clk_dev);
+ retain_and_null_ptr(pmgt_ref_clk_req_dev);
+
+ return 0;
+}
+
+static int google_usb3_phy_exit(struct phy *_phy)
+{
+ struct google_usb_phy_instance *inst = phy_get_drvdata(_phy);
+ struct google_usb_phy *gphy = inst->parent;
+
+ dev_dbg(gphy->dev, "exiting usb3 phy\n");
+
+ guard(mutex)(&gphy->phy_mutex);
+
+ set_pmgt_ref_clk_req_n(gphy, false);
+ reset_control_bulk_assert(inst->num_rsts, inst->rsts);
+ clk_bulk_disable_unprepare(inst->num_clks, inst->clks);
+
+ gphy->phy_state = COMBO_PHY_IDLE;
+
+ return 0;
+}
+
+static int google_usb3_phy_power_on(struct phy *_phy)
+{
+ struct google_usb_phy_instance *inst = phy_get_drvdata(_phy);
+ struct google_usb_phy *gphy = inst->parent;
+ int ret;
+
+ dev_dbg(gphy->dev, "power on usb3 phy\n");
+
+ guard(mutex)(&gphy->phy_mutex);
+
+ if (gphy->phy_state != COMBO_PHY_TCA_READY) {
+ /* Wait for PoR -> NC transitions*/
+ ret = wait_tca_xa_ack(gphy);
+ if (ret) {
+ dev_err(gphy->dev, "PoR->NC transition timeout");
+ return ret;
+ }
+ gphy->phy_state = COMBO_PHY_TCA_READY;
+ }
+
+ return program_tca_locked(gphy);
+}
+
+static const struct phy_ops google_usb3_phy_ops = {
+ .init = google_usb3_phy_init,
+ .exit = google_usb3_phy_exit,
+ .power_on = google_usb3_phy_power_on,
+};
+
static struct phy *google_usb_phy_xlate(struct device *dev,
const struct of_phandle_args *args)
{
@@ -173,14 +456,61 @@ static struct phy *google_usb_phy_xlate(struct device *dev,
return gphy->insts[args->args[0]].phy;
}
+static int google_usb_phy_parse_clocks(struct google_usb_phy *gphy)
+{
+ struct device *dev = gphy->dev;
+ int id, i, ret;
+
+ for (id = 0; id < GOOGLE_USB_PHY_NUM; id++) {
+ const struct google_usb_phy_config *cfg = &phy_configs[id];
+ struct google_usb_phy_instance *inst = &gphy->insts[id];
+
+ inst->num_clks = cfg->num_clks;
+ inst->clks = devm_kcalloc(dev, inst->num_clks, sizeof(*inst->clks), GFP_KERNEL);
+ if (!inst->clks)
+ return -ENOMEM;
+
+ for (i = 0; i < inst->num_clks; i++)
+ inst->clks[i].id = cfg->clk_names[i];
+
+ ret = devm_clk_bulk_get(dev, inst->num_clks, inst->clks);
+ if (ret)
+ return dev_err_probe(dev, ret, "failed to get phy%d clks\n", id);
+ }
+
+ return 0;
+}
+
+static int google_usb_phy_parse_resets(struct google_usb_phy *gphy)
+{
+ struct device *dev = gphy->dev;
+ int id, i, ret;
+
+ for (id = 0; id < GOOGLE_USB_PHY_NUM; id++) {
+ const struct google_usb_phy_config *cfg = &phy_configs[id];
+ struct google_usb_phy_instance *inst = &gphy->insts[id];
+
+ inst->num_rsts = cfg->num_rsts;
+ inst->rsts = devm_kcalloc(dev, inst->num_rsts, sizeof(*inst->rsts), GFP_KERNEL);
+ if (!inst->rsts)
+ return -ENOMEM;
+
+ for (i = 0; i < inst->num_rsts; i++)
+ inst->rsts[i].id = cfg->rst_names[i];
+ ret = devm_reset_control_bulk_get_exclusive(dev, inst->num_rsts, inst->rsts);
+ if (ret)
+ return dev_err_probe(dev, ret, "failed to get phy%d resets\n", id);
+ }
+
+ return 0;
+}
+
static int google_usb_phy_probe(struct platform_device *pdev)
{
struct typec_switch_desc sw_desc = { };
- struct google_usb_phy_instance *inst;
struct phy_provider *phy_provider;
struct device *dev = &pdev->dev;
struct google_usb_phy *gphy;
- struct phy *phy;
u32 args[1];
int ret;
@@ -212,39 +542,39 @@ static int google_usb_phy_probe(struct platform_device *pdev)
return dev_err_probe(dev, PTR_ERR(gphy->usbdp_top_base),
"invalid usbdp top\n");
+ gphy->usb3_tca_base = devm_platform_ioremap_resource_byname(pdev,
+ "usb3_tca");
+ if (IS_ERR(gphy->usb3_tca_base))
+ return dev_err_probe(dev, PTR_ERR(gphy->usb3_tca_base),
+ "invalid usb3 tca\n");
+
gphy->insts = devm_kcalloc(dev, GOOGLE_USB_PHY_NUM, sizeof(*gphy->insts), GFP_KERNEL);
if (!gphy->insts)
return -ENOMEM;
- inst = &gphy->insts[GOOGLE_USB2_PHY];
- inst->parent = gphy;
- inst->index = GOOGLE_USB2_PHY;
- phy = devm_phy_create(dev, NULL, &google_usb2_phy_ops);
- if (IS_ERR(phy))
- return dev_err_probe(dev, PTR_ERR(phy),
+ gphy->insts[GOOGLE_USB2_PHY].phy = devm_phy_create(dev, NULL, &google_usb2_phy_ops);
+ gphy->insts[GOOGLE_USB2_PHY].index = GOOGLE_USB2_PHY;
+ gphy->insts[GOOGLE_USB2_PHY].parent = gphy;
+ if (IS_ERR(gphy->insts[GOOGLE_USB2_PHY].phy))
+ return dev_err_probe(dev, PTR_ERR(gphy->insts[GOOGLE_USB2_PHY].phy),
"failed to create usb2 phy instance\n");
- inst->phy = phy;
- phy_set_drvdata(phy, inst);
+ phy_set_drvdata(gphy->insts[GOOGLE_USB2_PHY].phy, &gphy->insts[GOOGLE_USB2_PHY]);
- inst->num_clks = 2;
- inst->clks = devm_kcalloc(dev, inst->num_clks, sizeof(*inst->clks), GFP_KERNEL);
- if (!inst->clks)
- return -ENOMEM;
- inst->clks[0].id = "usb2";
- inst->clks[1].id = "usb2_apb";
- ret = devm_clk_bulk_get(dev, inst->num_clks, inst->clks);
+ gphy->insts[GOOGLE_USB3_PHY].phy = devm_phy_create(dev, NULL, &google_usb3_phy_ops);
+ gphy->insts[GOOGLE_USB3_PHY].index = GOOGLE_USB3_PHY;
+ gphy->insts[GOOGLE_USB3_PHY].parent = gphy;
+ if (IS_ERR(gphy->insts[GOOGLE_USB3_PHY].phy))
+ return dev_err_probe(dev, PTR_ERR(gphy->insts[GOOGLE_USB3_PHY].phy),
+ "failed to create usb3 phy instance\n");
+ phy_set_drvdata(gphy->insts[GOOGLE_USB3_PHY].phy, &gphy->insts[GOOGLE_USB3_PHY]);
+
+ ret = google_usb_phy_parse_clocks(gphy);
if (ret)
- return dev_err_probe(dev, ret, "failed to get u2 phy clks\n");
+ return ret;
- inst->num_rsts = 2;
- inst->rsts = devm_kcalloc(dev, inst->num_rsts, sizeof(*inst->rsts), GFP_KERNEL);
- if (!inst->rsts)
- return -ENOMEM;
- inst->rsts[0].id = "usb2";
- inst->rsts[1].id = "usb2_apb";
- ret = devm_reset_control_bulk_get_exclusive(dev, inst->num_rsts, inst->rsts);
+ ret = google_usb_phy_parse_resets(gphy);
if (ret)
- return dev_err_probe(dev, ret, "failed to get u2 phy resets\n");
+ return ret;
phy_provider = devm_of_phy_provider_register(dev, google_usb_phy_xlate);
if (IS_ERR(phy_provider))
base-commit: 2ace2e949979b82f82f12dd76d7c5a6145246ca3
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply related
* RE: [PATCH V4 1/8] PCI: imx6: Move pci_pwrctrl_create_devices() to imx_pcie_probe()
From: Sherry Sun @ 2026-07-01 2:08 UTC (permalink / raw)
To: Bjorn Helgaas, Sherry Sun (OSS)
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
Frank Li, s.hauer@pengutronix.de, kernel@pengutronix.de,
festevam@gmail.com, Amitkumar Karwar, Neeraj Sanjay Kale,
marcel@holtmann.org, luiz.dentz@gmail.com, Hongxing Zhu,
l.stach@pengutronix.de, lpieralisi@kernel.org,
kwilczynski@kernel.org, mani@kernel.org, bhelgaas@google.com,
brgl@kernel.org, imx@lists.linux.dev, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-bluetooth@vger.kernel.org,
linux-pm@vger.kernel.org
In-Reply-To: <20260630173745.GA155769@bhelgaas>
> Subject: Re: [PATCH V4 1/8] PCI: imx6: Move pci_pwrctrl_create_devices() to
> imx_pcie_probe()
>
> On Tue, Jun 30, 2026 at 06:31:32PM +0800, Sherry Sun (OSS) wrote:
> > From: Sherry Sun <sherry.sun@nxp.com>
> >
> > Move pci_pwrctrl_create_devices() to imx_pcie_probe() so that it is
> > only called once during probe, similar to other regulator_get calls.
>
> Can we say something in the subject about the purpose of this? "Move X to
> Y" summarizes the code change but not the motivation.
>
> I guess previously pci_pwrctrl_create_devices() would be called during probe
> and then again during resume, and we don't want it called during resume?
Your understanding is correct; I will improve the commit message to include
motivation. Thanks!
Best Regards
Sherry
^ permalink raw reply
* Re: [PATCH 2/3] arm64: dts: socfpga: agilex5: Add SoCDK TSN Config2 board
From: Nazle Asmade, Muhammad Nazim Amirul @ 2026-07-01 1:54 UTC (permalink / raw)
To: Andrew Lunn
Cc: dinguyen@kernel.org, maxime.chevallier@bootlin.com,
rmk+kernel@armlinux.org.uk, krzk+dt@kernel.org,
conor+dt@kernel.org, robh@kernel.org, davem@davemloft.net,
edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
andrew+netdev@lunn.ch, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <e4cf8d95-0467-4bdc-8e19-228ced3a8bbc@lunn.ch>
On 30/6/2026 11:25 pm, Andrew Lunn wrote:
> On Tue, Jun 30, 2026 at 02:39:50PM +0000, Nazle Asmade, Muhammad Nazim Amirul wrote:
>> On 30/6/2026 9:58 pm, Andrew Lunn wrote:
>>>> + * gmac1 is the TSN port. The MAC operates in GMII mode internally
>>>> + * while the PHY-side interface is RGMII, so mac-mode and phy-mode differ.
>>>> + */
>>>> +&gmac1 {
>>>> + status = "okay";
>>>> + phy-mode = "rgmii"; /* TX/RX clock delays provided by Agilex5 I/O hardware */
>>> Could you provide more details about this. I want to understand the
>>> big picture.
>>>
>>> Normally we talk about the PCB providing the delays. This sounds like
>>> it is the FPGA? So i need convincing this is correct.
>> Hi Andrew,
>>
>> Thanks for your quick review and yes, it is the FPGA — specifically a
>> soft IP block in the FPGA fabric that implements the RGMII clock delays
>> and is configured before Linux boots via the FPGA bitstream. The driver
>> must not add additional delays on top.
>
> So it depends on how the converter block is described, but ....
>
> From a big picture, MAC and PHY pair, it is the MAC which
> implements the delays.
>
> https://elixir.bootlin.com/linux/v6.15/source/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L346
>
> # There are a small number of cases where the MAC has hard coded
> # delays which cannot be disabled. The 'phy-mode' only describes the
> # PCB. The inability to disable the delays in the MAC does not change
> # the meaning of 'phy-mode'. It does however mean that a 'phy-mode' of
> # 'rgmii' is now invalid, it cannot be supported, since both the PCB
> # and the MAC and PHY adding delays cannot result in a functional
> # link. Thus the MAC should report a fatal error for any modes which
> # cannot be supported. When the MAC implements the delay, it must
> # ensure that the PHY does not also implement the same delay. So it
> # must modify the phy-mode it passes to the PHY, removing the delay it
> # has added. Failure to remove the delay will result in a
> # non-functioning link.
>
> Andrew
>
> ---
> pw-bot: cr
Hi Andrew,
The delays are provided by the FPGA GMII-to-RGMII converter soft IP,
which is hardcoded in the FPGA bitstream and cannot be disabled or
modified from the driver side.
Using phy-mode = "rgmii" is intentional here — it prevents the PHY from
adding its own internal delays on top, since the FPGA converter already
provides the full required delay. This is consistent with how all other
Agilex5 SoCDK board variants are described, as seen in commit
c5637e5ceb4b ("arm64: dts: socfpga: agilex5: Fix phy-mode to rgmii as HW
provides clock delay") already in Dinh Nguyen's tree, which applies the
same rationale across all Agilex5 boards.
BR,
Nazim Amirul
^ permalink raw reply
* Re: [PATCH v6 5/5] watchdog: aaeon: Add watchdog driver for SRG-IMX8P MCU
From: Guenter Roeck @ 2026-07-01 2:50 UTC (permalink / raw)
To: Thomas Perrot (Schneider Electric), Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Linus Walleij,
Bartosz Golaszewski, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
Jérémie Dautheribes, Wim Van Sebroeck, Lee Jones
Cc: devicetree, linux-kernel, linux-gpio, imx, linux-arm-kernel,
linux-watchdog, Thomas Petazzoni, Miquel Raynal
In-Reply-To: <20260630-dev-b4-aaeon-mcu-driver-v6-5-d66b5fcbd2f0@bootlin.com>
On 6/30/26 05:51, Thomas Perrot (Schneider Electric) wrote:
> Add watchdog driver for the Aaeon SRG-IMX8P embedded controller.
> This driver provides system monitoring and recovery capabilities
> through the MCU's watchdog timer.
>
> The watchdog supports start, stop, and ping operations with a maximum
> hardware heartbeat of 25 seconds and a default timeout of 240 seconds.
> The software timeout can be changed via the WDIOC_SETTIMEOUT ioctl,
> the DT timeout-sec property, or the watchdog_timeout kernel boot
> parameter.
>
> Co-developed-by: Jérémie Dautheribes (Schneider Electric) <jeremie.dautheribes@bootlin.com>
> Signed-off-by: Jérémie Dautheribes (Schneider Electric) <jeremie.dautheribes@bootlin.com>
> Signed-off-by: Thomas Perrot (Schneider Electric) <thomas.perrot@bootlin.com>
> Acked-by: Guenter Roeck <linux@roeck-us.net>
> ---
> MAINTAINERS | 1 +
> drivers/watchdog/Kconfig | 10 +++
> drivers/watchdog/Makefile | 1 +
> drivers/watchdog/aaeon_mcu_wdt.c | 144 +++++++++++++++++++++++++++++++++++++++
> 4 files changed, 156 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 2538f8c4bc14..7b92af42c9fd 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -193,6 +193,7 @@ S: Maintained
> F: Documentation/devicetree/bindings/mfd/aaeon,srg-imx8p-mcu.yaml
> F: drivers/gpio/gpio-aaeon-mcu.c
> F: drivers/mfd/aaeon-mcu.c
> +F: drivers/watchdog/aaeon_mcu_wdt.c
> F: include/linux/mfd/aaeon-mcu.h
>
> AAEON UPBOARD FPGA MFD DRIVER
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index d3b9df7d466b..f67a0b453316 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -420,6 +420,16 @@ config SL28CPLD_WATCHDOG
>
> # ARM Architecture
>
> +config AAEON_MCU_WATCHDOG
> + tristate "Aaeon MCU Watchdog"
> + depends on MFD_AAEON_MCU
> + select WATCHDOG_CORE
> + help
> + Select this option to enable watchdog timer support for the Aaeon
> + SRG-IMX8P onboard microcontroller (MCU). This driver provides
> + watchdog functionality through the MCU, allowing system monitoring
> + and automatic recovery from system hangs.
> +
> config AIROHA_WATCHDOG
> tristate "Airoha EN7581 Watchdog"
> depends on ARCH_AIROHA || COMPILE_TEST
> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> index ba52099b1253..2deec425d3ea 100644
> --- a/drivers/watchdog/Makefile
> +++ b/drivers/watchdog/Makefile
> @@ -37,6 +37,7 @@ obj-$(CONFIG_USBPCWATCHDOG) += pcwd_usb.o
> # ALPHA Architecture
>
> # ARM Architecture
> +obj-$(CONFIG_AAEON_MCU_WATCHDOG) += aaeon_mcu_wdt.o
> obj-$(CONFIG_ARM_SP805_WATCHDOG) += sp805_wdt.o
> obj-$(CONFIG_ARM_SBSA_WATCHDOG) += sbsa_gwdt.o
> obj-$(CONFIG_ARMADA_37XX_WATCHDOG) += armada_37xx_wdt.o
> diff --git a/drivers/watchdog/aaeon_mcu_wdt.c b/drivers/watchdog/aaeon_mcu_wdt.c
> new file mode 100644
> index 000000000000..347ee8269bfd
> --- /dev/null
> +++ b/drivers/watchdog/aaeon_mcu_wdt.c
> @@ -0,0 +1,144 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Aaeon MCU Watchdog driver
> + *
> + * Copyright (C) 2026 Bootlin
> + * Author: Jérémie Dautheribes <jeremie.dautheribes@bootlin.com>
> + * Author: Thomas Perrot <thomas.perrot@bootlin.com>
> + */
> +
> +#include <linux/mfd/aaeon-mcu.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <linux/watchdog.h>
> +
> +#define AAEON_MCU_PING_WDT 0x73
> +
> +#define AAEON_MCU_WDT_TIMEOUT 240
> +#define AAEON_MCU_WDT_HEARTBEAT_MS 25000
> +#define AAEON_MCU_WDT_MIN_TIMEOUT 1
> +#define AAEON_MCU_WDT_MAX_TIMEOUT 3600
> +
> +static unsigned int timeout;
> +module_param(timeout, uint, 0);
> +MODULE_PARM_DESC(timeout, "Watchdog timeout in seconds");
> +
> +struct aaeon_mcu_wdt {
> + struct watchdog_device wdt;
> + struct regmap *regmap;
> +};
> +
> +static int aaeon_mcu_wdt_cmd(struct aaeon_mcu_wdt *data, u8 opcode, u8 arg)
> +{
> + return regmap_write(data->regmap, AAEON_MCU_REG(opcode, arg), 0);
> +}
> +
> +static int aaeon_mcu_wdt_start(struct watchdog_device *wdt)
> +{
> + struct aaeon_mcu_wdt *data = watchdog_get_drvdata(wdt);
> +
> + return aaeon_mcu_wdt_cmd(data, AAEON_MCU_CONTROL_WDT_OPCODE, 0x01);
> +}
> +
> +static int aaeon_mcu_wdt_status(struct watchdog_device *wdt, bool *enabled)
> +{
> + struct aaeon_mcu_wdt *data = watchdog_get_drvdata(wdt);
> + unsigned int rsp;
> + int ret;
> +
> + ret = regmap_read(data->regmap,
> + AAEON_MCU_REG(AAEON_MCU_CONTROL_WDT_OPCODE, 0x02),
> + &rsp);
> + if (ret)
> + return ret;
> +
> + *enabled = rsp == 0x01;
> + return 0;
> +}
> +
> +static int aaeon_mcu_wdt_stop(struct watchdog_device *wdt)
> +{
> + struct aaeon_mcu_wdt *data = watchdog_get_drvdata(wdt);
> +
> + return aaeon_mcu_wdt_cmd(data, AAEON_MCU_CONTROL_WDT_OPCODE, 0x00);
> +}
> +
> +static int aaeon_mcu_wdt_ping(struct watchdog_device *wdt)
> +{
> + struct aaeon_mcu_wdt *data = watchdog_get_drvdata(wdt);
> +
> + return aaeon_mcu_wdt_cmd(data, AAEON_MCU_PING_WDT, 0x00);
> +}
> +
> +static const struct watchdog_info aaeon_mcu_wdt_info = {
> + .identity = "Aaeon MCU Watchdog",
> + .options = WDIOF_KEEPALIVEPING | WDIOF_MAGICCLOSE | WDIOF_SETTIMEOUT
> +};
> +
> +static const struct watchdog_ops aaeon_mcu_wdt_ops = {
> + .owner = THIS_MODULE,
> + .start = aaeon_mcu_wdt_start,
> + .stop = aaeon_mcu_wdt_stop,
> + .ping = aaeon_mcu_wdt_ping,
> +};
> +
> +static int aaeon_mcu_wdt_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct watchdog_device *wdt;
> + struct aaeon_mcu_wdt *data;
> + bool enabled;
> + int ret;
> +
> + data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
> + if (!data)
> + return -ENOMEM;
> +
> + data->regmap = dev_get_regmap(dev->parent, NULL);
> + if (!data->regmap)
> + return -ENODEV;
> +
> + wdt = &data->wdt;
> + wdt->parent = dev;
> + wdt->info = &aaeon_mcu_wdt_info;
> + wdt->ops = &aaeon_mcu_wdt_ops;
> + /*
> + * The MCU firmware has a fixed hardware timeout of 25 seconds that
> + * cannot be changed. The watchdog core handles automatic pinging to
> + * support software timeouts longer than the hardware limit. The default
> + * software timeout of 240 seconds can be overridden via the DT
> + * timeout-sec property or the watchdog_timeout kernel boot parameter.
> + */
> + wdt->timeout = AAEON_MCU_WDT_TIMEOUT;
> + wdt->min_timeout = AAEON_MCU_WDT_MIN_TIMEOUT;
> + wdt->max_timeout = AAEON_MCU_WDT_MAX_TIMEOUT;
> + wdt->max_hw_heartbeat_ms = AAEON_MCU_WDT_HEARTBEAT_MS;
Either max_timeout or max_hw_heartbeat_ms should be set, but not both.
From the include file:
* @max_timeout:The watchdog devices maximum timeout value (in seconds)
* as configurable from user space. Only relevant if
* max_hw_heartbeat_ms is not provided.
In other words, max_timeout is ignored by the watchdog core.
> + watchdog_init_timeout(wdt, timeout, dev);
As pointed out by Sashiko, this will not initialize the timeout from
devicetree. You'll need to either adjust the code or the comment above.
Thanks,
Guenter
> +
> + watchdog_set_drvdata(wdt, data);
> + watchdog_stop_on_reboot(wdt);
> +
> + ret = aaeon_mcu_wdt_status(wdt, &enabled);
> + if (ret)
> + return ret;
> +
> + if (enabled)
> + set_bit(WDOG_HW_RUNNING, &wdt->status);
> +
> + return devm_watchdog_register_device(dev, wdt);
> +}
> +
> +static struct platform_driver aaeon_mcu_wdt_driver = {
> + .driver = {
> + .name = "aaeon-mcu-wdt",
> + },
> + .probe = aaeon_mcu_wdt_probe,
> +};
> +
> +module_platform_driver(aaeon_mcu_wdt_driver);
> +
> +MODULE_ALIAS("platform:aaeon-mcu-wdt");
> +MODULE_DESCRIPTION("Aaeon MCU Watchdog Driver");
> +MODULE_AUTHOR("Jérémie Dautheribes <jeremie.dautheribes@bootlin.com>");
> +MODULE_LICENSE("GPL");
>
^ permalink raw reply
* Re: [PATCH v6 00/20] dma-mapping: Use DMA_ATTR_CC_SHARED through direct, pool and swiotlb paths
From: Aneesh Kumar K.V @ 2026-07-01 3:09 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Alexey Kardashevskiy, Catalin Marinas, iommu, linux-arm-kernel,
linux-kernel, linux-coco, Robin Murphy, Marek Szyprowski,
Will Deacon, Marc Zyngier, Steven Price, Suzuki K Poulose,
Jiri Pirko, Mostafa Saleh, Petr Tesarik, Dan Williams, Xu Yilun,
linuxppc-dev, linux-s390, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Alexander Gordeev,
Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86
In-Reply-To: <20260630174216.GK7525@ziepe.ca>
Jason Gunthorpe <jgg@ziepe.ca> writes:
> On Mon, Jun 29, 2026 at 12:16:30PM +0530, Aneesh Kumar K.V wrote:
>> >> Thinking about this more, I guess we should mark the swiotlb as
>> >> cc_shared only with CC_ATTR_GUEST_MEM_ENCRYPT instead of
>> >> CC_ATTR_MEM_ENCRYPT as we have below.
>> >
>> > The name cc_shared should be used for GUEST scenarios only.
>> >
>> > I guess there is some merit in keeping swiotlb using "decrypted" to
>> > mean it usinig pgprot_decrypted and set_memory_decyped() which AMD
>> > gives meaning to on both host and guest.
>>
>> Are you suggesting to change the struct io_tlb_mem::cc_shared back to
>> struct io_tlb_mem::unencrypted?.
>
> Yes
>
>> > IDK what AMD should do on the host by default. I guess it should setup
>> > a swiotlb pool of low dma addrs "unencrypted", but not "cc_shared"?
>> >
>>
>> If by low DMA address you mean using an address with the C-bit
>> cleared.
>
> Yes
>
>> The current code already does this and uses the swiotlb pool correctly
>> on SME.
>
> Well, through the force_dma_unencrypted() hack...
>
>> The challenge arises when we want to force SWIOTLB
>> bouncing even for devices that can handle encrypted DMA addresses (more
>> on that below). For such a config force_dma_uencrypted(dev) will return
>> false and swiotlb will be marked cc_shared/decrypted = true; This trip
>> the new check we added.
>
> Yes, because cc_shared (guest) and unencrypted (host) are very
> different things and we've mixed them:
>
>> if (unlikely(mem->cc_shared != force_dma_unencrypted(dev)))
>
> I'm aruging force_dma_unencrypted should mean cc_shared and be
> guest_only, but the SME hack breaks this.
>
>> We can also do
>>
>> if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT)) {
>> /* swiotlb pool is incorrect for this device */
>> if (unlikely(mem->cc_shared != force_dma_unencrypted(dev)))
>> return (phys_addr_t)DMA_MAPPING_ERROR;
>>
>> /* Force attrs to match the kind of memory in the pool */
>> if (mem->cc_shared)
>> *attrs |= DMA_ATTR_CC_SHARED;
>> else
>> *attrs &= ~DMA_ATTR_CC_SHARED;
>> } else {
>> /*
>> * Host memory encryption where device requires an
>> * unencrypted dma_addr_t due to dma mask limit
>> */
>> if (force_dma_unencrypted(dev))
>> *attrs |= DMA_ATTR_CC_SHARED;
>> else
>> *attrs &= ~DMA_ATTR_CC_SHARED;
>> }
>
> If we do this I would like to split the force_dma_.. functions into
> guest and host, ie force_dma_cc_shared() and force_host_decrypted()
>
> To make it clear there are two very different things here.
>
I have now folded the below change into
modified kernel/dma/swiotlb.c
@@ -1514,9 +1514,23 @@ phys_addr_t swiotlb_tbl_map_single(struct device *dev, phys_addr_t orig_addr,
if (cc_platform_has(CC_ATTR_MEM_ENCRYPT))
pr_warn_once("Memory encryption is active and system is using DMA bounce buffers\n");
- /* swiotlb pool is incorrect for this device */
- if (unlikely(mem->cc_shared != force_dma_unencrypted(dev)))
- return (phys_addr_t)DMA_MAPPING_ERROR;
+ if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT)) {
+
+ /* swiotlb pool is incorrect for this device */
+ if (unlikely(mem->cc_shared != force_dma_unencrypted(dev)))
+ return (phys_addr_t)DMA_MAPPING_ERROR;
+
+ } else if (cc_platform_has(CC_ATTR_HOST_MEM_ENCRYPT)) {
+ /*
+ * On hosts with memory encryption, SWIOTLB-backed memory is
+ * unencrypted. DMA addresses returned for bounce buffers must
+ * therefore be marked unencrypted, even for devices that can
+ * address encrypted memory. This also preserves swiotlb=force
+ * behavior for those devices.
+ */
+ if (unlikely(!mem->cc_shared))
+ return (phys_addr_t)DMA_MAPPING_ERROR;
+ }
[PATCH] dma: swiotlb: track pool encryption state and honor DMA_ATTR_CC_SHARED
This is the only code path where we need to special-case host memory
encryption. For this reason, I have avoided renaming
io_tlb_mem::cc_shared to io_tlb_mem::unencrypted. I can send a v7 with
the above and we can review the changes based on that?
-aneesh
^ permalink raw reply
* Re: [PATCH 0/3] arm64: dts/net: stmmac: Add Agilex5 SoCDK TSN Config2 board support
From: Nazle Asmade, Muhammad Nazim Amirul @ 2026-07-01 2:09 UTC (permalink / raw)
To: Maxime Chevallier, dinguyen@kernel.org
Cc: rmk+kernel@armlinux.org.uk, krzk+dt@kernel.org,
conor+dt@kernel.org, robh@kernel.org, davem@davemloft.net,
edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
andrew+netdev@lunn.ch, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <563ac947-0c5d-47ee-aedc-66baf4d32648@bootlin.com>
On 30/6/2026 9:53 pm, Maxime Chevallier wrote:
> Hi,
>
> On 6/30/26 15:31, muhammad.nazim.amirul.nazle.asmade@altera.com wrote:
>> From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
>>
>> The Intel SoCFPGA Agilex5 SoCDK TSN Config2 board uses a dual-port
>> Ethernet setup where gmac1 (TSN port) operates with different MAC-side
>> and PHY-side interface modes: GMII internally in the MAC, and RGMII
>> towards the PHY.
>
> There's the same behaviour on Gen5, e.g. CycloneV where we have the
> "EMAC splitter". Based on wether or not we have that splitter in DT,
> we override the INTF_SEL bits to set GMII as the MAC output, the splitter
> converting that to RGMII/SGMII.
>
> Is there something similar on this AgileX5 version by any chance, for
> which we could reuse the logic ?
>
> I know that on CycloneV you also need to adjust that GMII -> RGMII/SGMII
> splitter whenever the speed changes, is that different on agileX5 ? have
> you tested 10/100Mbps ?
>
> Thanks,
>
> Maxime
Hi Maxime,
Yes, we have tested all three speeds.
10Mbps: Link Up - 10Mbps/Full, throughput ~9.35 Mbits/sec 100Mbps: Link
Up - 100Mbps/Full, throughput ~94 Mbits/sec 1000Mbps: Link Up -
1Gbps/Full, throughput ~930 Mbits/sec
BR,
Nazim
^ permalink raw reply
* [PATCH v3 2/2] i2c: cadence: Add support for Axiado AX3000
From: Swark Yang @ 2026-07-01 4:48 UTC (permalink / raw)
To: Michal Simek, Andi Shyti, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-kernel, linux-i2c, devicetree, linux-kernel, openbmc,
Swark Yang
In-Reply-To: <20260630-axiado-ax3000-cadence-i2c-support-v3-0-4e217cfe5904@axiado.com>
The Axiado AX3000 SoC integrates a Cadence I2C controller
that supports SMBus Quick commands.
Introduce the "axiado,ax3000-i2c" compatible string and
add a new quirk CDNS_I2C_ENABLE_SMBUS_QUICK to enable
this functionality. This allows the controller to support
I2C_FUNC_SMBUS_QUICK, enabling features such as bus scanning
via quick write commands.
Additionally, enabling SMBus Quick emulation in the I2C core exposes
the controller to potential 0-length reads. Because the Cadence IP
does not natively support 0-length reads (writing 0 to the transfer
size register leaves the hardware in an unsupported state), this patch
also populates the adapter quirks with I2C_AQ_NO_ZERO_LEN_READ.
This ensures 0-length reads are safely rejected by the core, preventing
potential bus hangs.
Signed-off-by: Swark Yang <syang@axiado.com>
---
drivers/i2c/busses/i2c-cadence.c | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/drivers/i2c/busses/i2c-cadence.c b/drivers/i2c/busses/i2c-cadence.c
index 0fb728ade92e..1964ea1650c5 100644
--- a/drivers/i2c/busses/i2c-cadence.c
+++ b/drivers/i2c/busses/i2c-cadence.c
@@ -128,6 +128,7 @@
#define CDNS_I2C_TIMEOUT_MAX 0xFF
#define CDNS_I2C_BROKEN_HOLD_BIT BIT(0)
+#define CDNS_I2C_ENABLE_SMBUS_QUICK BIT(1)
#define CDNS_I2C_POLL_US 100000
#define CDNS_I2C_POLL_US_ATOMIC 10
#define CDNS_I2C_TIMEOUT_US 500000
@@ -1175,10 +1176,14 @@ static int cdns_i2c_master_xfer_atomic(struct i2c_adapter *adap, struct i2c_msg
*/
static u32 cdns_i2c_func(struct i2c_adapter *adap)
{
+ struct cdns_i2c *id = adap->algo_data;
u32 func = I2C_FUNC_I2C | I2C_FUNC_10BIT_ADDR |
(I2C_FUNC_SMBUS_EMUL & ~I2C_FUNC_SMBUS_QUICK) |
I2C_FUNC_SMBUS_BLOCK_DATA;
+ if (id->quirks & CDNS_I2C_ENABLE_SMBUS_QUICK)
+ func |= I2C_FUNC_SMBUS_QUICK;
+
#if IS_ENABLED(CONFIG_I2C_SLAVE)
func |= I2C_FUNC_SLAVE;
#endif
@@ -1442,9 +1447,24 @@ static const struct cdns_platform_data r1p10_i2c_def = {
.quirks = CDNS_I2C_BROKEN_HOLD_BIT,
};
+static const struct cdns_platform_data ax3000_i2c_def = {
+ .quirks = CDNS_I2C_ENABLE_SMBUS_QUICK,
+};
+
+/*
+ * The controller does not support zero-length reads. Enabling SMBus Quick
+ * commands would otherwise let the core emulate a Quick read as a zero-length
+ * read message, which writes 0 to the transfer size register and leaves the
+ * hardware in an unsupported state. Reject such transfers in the core.
+ */
+static const struct i2c_adapter_quirks cdns_i2c_quirks = {
+ .flags = I2C_AQ_NO_ZERO_LEN_READ,
+};
+
static const struct of_device_id cdns_i2c_of_match[] = {
{ .compatible = "cdns,i2c-r1p10", .data = &r1p10_i2c_def },
{ .compatible = "cdns,i2c-r1p14",},
+ { .compatible = "axiado,ax3000-i2c", .data = &ax3000_i2c_def },
{ /* end of table */ }
};
MODULE_DEVICE_TABLE(of, cdns_i2c_of_match);
@@ -1510,6 +1530,9 @@ static int cdns_i2c_probe(struct platform_device *pdev)
id->quirks = data->quirks;
}
+ if (id->quirks & CDNS_I2C_ENABLE_SMBUS_QUICK)
+ id->adap.quirks = &cdns_i2c_quirks;
+
id->rinfo.pinctrl = devm_pinctrl_get(&pdev->dev);
if (IS_ERR(id->rinfo.pinctrl)) {
int err = PTR_ERR(id->rinfo.pinctrl);
--
2.34.1
^ permalink raw reply related
* [PATCH v3 0/2] i2c: cadence: Add support for Axiado AX3000
From: Swark Yang @ 2026-07-01 4:48 UTC (permalink / raw)
To: Michal Simek, Andi Shyti, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-kernel, linux-i2c, devicetree, linux-kernel, openbmc,
Swark Yang, Conor Dooley
This patch series adds support for the Cadence I2C controller
integrated into the Axiado AX3000 SoC and enables SMBus Quick
command functionality.
The Axiado AX3000 utilizes the Cadence I2C IP core (version r1p14).
While it is largely compatible with the existing i2c-cadence
driver logic, the AX3000 hardware specifically supports SMBus Quick
commands. This feature is currently disabled by default in the
i2c-cadence driver (masked out from I2C_FUNC_SMBUS_EMUL).
To enable this functionality, this series introduces a new
platform-specific quirk (CDNS_I2C_ENABLE_SMBUS_QUICK) and
uses driver match data for the "axiado,ax3000-i2c" compatible string.
This allows tools like 'i2cdetect' to properly scan the bus using
quick write commands.
The DT binding update follows the recommended fallback structure,
referencing the 'cdns,i2c-r1p14' fallback to ensure compatibility with
older kernels while allowing the new quirk to be enabled on AX3000.
Patch breakdown:
Patch 1: dt-bindings: i2c: cadence: Add Axiado AX3000
Patch 2: i2c: cadence: Add support for Axiado AX3000
These patches are expected to go via the I2C subsystem tree.
Feedback is welcome.
Signed-off-by: Swark Yang <syang@axiado.com>
---
Changes in v3:
- Addressed Sashiko AI bot report: Populated adapter quirks with I2C_AQ_NO_ZERO_LEN_READ to safely reject 0-length reads and prevent potential bus hangs.
- Note on AI review: The bot also reported a pre-existing UAF vulnerability triggered by 0-length reads. Since this v3 patch prevents the core from passing 0-length reads to the driver, this specific trigger path is mitigated for AX3000. Atomic transfer issues are left out of scope for this hardware enablement series.
- Renamed the quirk macro to CDNS_I2C_ENABLE_SMBUS_QUICK for consistency.
- Link to v2: https://lore.kernel.org/r/20260611-axiado-ax3000-cadence-i2c-support-v2-0-cfdad0534afa@axiado.com
Changes in v2:
- Collected Conor Dooley's Acked-by for Patch 1.
- No functional code changes (sent primarily as a RESEND to update status).
- Link to v1: https://lore.kernel.org/r/20260504-axiado-ax3000-cadence-i2c-support-v1-0-97ed2fdc0b7b@axiado.com
---
Swark Yang (2):
dt-bindings: i2c: cadence: Add Axiado AX3000
i2c: cadence: Add support for Axiado AX3000
.../devicetree/bindings/i2c/cdns,i2c-r1p10.yaml | 10 +++++++---
drivers/i2c/busses/i2c-cadence.c | 23 ++++++++++++++++++++++
2 files changed, 30 insertions(+), 3 deletions(-)
---
base-commit: 63804fed149a6750ffd28610c5c1c98cce6bd377
change-id: 20260111-axiado-ax3000-cadence-i2c-support-53ec117bb074
Best regards,
--
Swark Yang <syang@axiado.com>
^ permalink raw reply
* [PATCH v3 1/2] dt-bindings: i2c: cadence: Add Axiado AX3000
From: Swark Yang @ 2026-07-01 4:48 UTC (permalink / raw)
To: Michal Simek, Andi Shyti, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-kernel, linux-i2c, devicetree, linux-kernel, openbmc,
Swark Yang, Conor Dooley
In-Reply-To: <20260630-axiado-ax3000-cadence-i2c-support-v3-0-4e217cfe5904@axiado.com>
The Axiado AX3000 SoC integrates the Cadence I2C controller.
Add a specific compatible string "axiado,ax3000-i2c" to support
its hardware features, including SMBus Quick command capability.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Swark Yang <syang@axiado.com>
---
Documentation/devicetree/bindings/i2c/cdns,i2c-r1p10.yaml | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/i2c/cdns,i2c-r1p10.yaml b/Documentation/devicetree/bindings/i2c/cdns,i2c-r1p10.yaml
index 9f1d35ce1fe8..de2110376a3f 100644
--- a/Documentation/devicetree/bindings/i2c/cdns,i2c-r1p10.yaml
+++ b/Documentation/devicetree/bindings/i2c/cdns,i2c-r1p10.yaml
@@ -14,9 +14,13 @@ allOf:
properties:
compatible:
- enum:
- - cdns,i2c-r1p10 # cadence i2c controller version 1.0
- - cdns,i2c-r1p14 # cadence i2c controller version 1.4
+ oneOf:
+ - items:
+ - const: axiado,ax3000-i2c
+ - const: cdns,i2c-r1p14
+ - enum:
+ - cdns,i2c-r1p10 # cadence i2c controller version 1.0
+ - cdns,i2c-r1p14 # cadence i2c controller version 1.4
reg:
maxItems: 1
--
2.34.1
^ permalink raw reply related
* [PATCH v5] dmaengine: sun6i-dma: Fix reclaim descriptors while terminating DMA
From: Hongling Zeng @ 2026-07-01 4:57 UTC (permalink / raw)
To: vkoul, Frank.Li, wens, jernej.skrabec, samuel, mripard, arnd
Cc: dmaengine, linux-arm-kernel, linux-sunxi, linux-kernel,
zhongling0719, Hongling Zeng, Frank Li, Frank Li
When terminating DMA transfers, active descriptors are not properly
reclaimed. Only cyclic descriptors were handled, leaving non-cyclic
descriptors and their LLI chains to be permanently leaked.
Fix by using vchan_terminate_vdesc() which handles both cyclic and
non-cyclic descriptors by adding them to desc_terminated queue for
proper cleanup.
Add pchan->desc != pchan->done check to prevent double-adding completed
descriptors, which would corrupt the list.
Fixes: 555859308723 ("dmaengine: sun6i: Add driver for the Allwinner A31 DMA controller")
Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Suggested-by: Frank Li <Frank.li@oss.nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
---
Change in v2;
-Add pchan->desc != pchan->done check to prevent race condition
where completed descriptors could be double-added to desc_completed
list, causing list corruption
---
Change in v3:
-Fix by using vchan_terminate_vdesc() as suggested by Frank Li
---
Change in v4:
-Correct the commit message
---
Chaneg in v5:
-Correct the subject
-Add reviewed-by
---
drivers/dma/sun6i-dma.c | 13 +++++--------
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
index 7a79f346250a..134ae840f176 100644
--- a/drivers/dma/sun6i-dma.c
+++ b/drivers/dma/sun6i-dma.c
@@ -946,16 +946,13 @@ static int sun6i_dma_terminate_all(struct dma_chan *chan)
spin_lock_irqsave(&vchan->vc.lock, flags);
- if (vchan->cyclic) {
- vchan->cyclic = false;
- if (pchan && pchan->desc) {
- struct virt_dma_desc *vd = &pchan->desc->vd;
- struct virt_dma_chan *vc = &vchan->vc;
-
- list_add_tail(&vd->node, &vc->desc_completed);
- }
+ if (pchan && pchan->desc && pchan->desc != pchan->done) {
+ struct virt_dma_desc *vd = &pchan->desc->vd;
+
+ vchan_terminate_vdesc(vd);
}
+ vchan->cyclic = false;
vchan_get_all_descriptors(&vchan->vc, &head);
if (pchan) {
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v4] dmaengine: sun6i-dma: Fix memory leak in sun6i_dma_terminate_all
From: Hongling Zeng @ 2026-07-01 5:01 UTC (permalink / raw)
To: Vinod Koul, Hongling Zeng
Cc: Frank.Li, wens, jernej.skrabec, samuel, mripard, arnd, dmaengine,
linux-arm-kernel, linux-sunxi, linux-kernel, Frank Li
In-Reply-To: <akOptOSkd7o0Vivk@vaman>
在 2026年06月30日 19:34, Vinod Koul 写道:
> On 18-06-26, 10:06, Hongling Zeng wrote:
>> When terminating DMA transfers, active descriptors are not properly
>> reclaimed. Only cyclic descriptors were handled, leaving non-cyclic
>> descriptors and their LLI chains to be permanently leaked.
>>
>> Fix by using vchan_terminate_vdesc() which handles both cyclic and
>> non-cyclic descriptors by adding them to desc_terminated queue for
>> proper cleanup.
>>
>> Add pchan->desc != pchan->done check to prevent double-adding completed
>> descriptors, which would corrupt the list.
> Thanks for the patch. Please consider revising the subject which should
> describe the changes in the patch and not the fix/issue.
>
> A better one would be "fix reclaim descriptors while terminating"
Thank you for the suggestion. I'll update the subject in v5 to describe
the changes rather than the issue.
>> Fixes: 555859308723 ("dmaengine: sun6i: Add driver for the Allwinner A31 DMA controller")
>> Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
>> Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
>> Suggested-by: Frank Li <Frank.li@oss.nxp.com>
>>
>> ---
>> Change in v2;
>> -Add pchan->desc != pchan->done check to prevent race condition
>> where completed descriptors could be double-added to desc_completed
>> list, causing list corruption
>> ---
>> Change in v3:
>> -Fix by using vchan_terminate_vdesc() as suggested by Frank Li
>> ---
>> Change in v4:
>> -Correct the commit message
>> ---
>> drivers/dma/sun6i-dma.c | 13 +++++--------
>> 1 file changed, 5 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
>> index 7a79f346250a..134ae840f176 100644
>> --- a/drivers/dma/sun6i-dma.c
>> +++ b/drivers/dma/sun6i-dma.c
>> @@ -946,16 +946,13 @@ static int sun6i_dma_terminate_all(struct dma_chan *chan)
>>
>> spin_lock_irqsave(&vchan->vc.lock, flags);
>>
>> - if (vchan->cyclic) {
>> - vchan->cyclic = false;
>> - if (pchan && pchan->desc) {
>> - struct virt_dma_desc *vd = &pchan->desc->vd;
>> - struct virt_dma_chan *vc = &vchan->vc;
>> -
>> - list_add_tail(&vd->node, &vc->desc_completed);
>> - }
>> + if (pchan && pchan->desc && pchan->desc != pchan->done) {
>> + struct virt_dma_desc *vd = &pchan->desc->vd;
>> +
>> + vchan_terminate_vdesc(vd);
>> }
>>
>> + vchan->cyclic = false;
>> vchan_get_all_descriptors(&vchan->vc, &head);
>>
>> if (pchan) {
>> --
>> 2.25.1
^ permalink raw reply
* RE: [PATCH v6 2/9] dt-bindings: media: nxp: Add Wave6 video codec device
From: Nas Chung @ 2026-07-01 5:14 UTC (permalink / raw)
To: Rob Herring
Cc: mchehab@kernel.org, hverkuil@xs4all.nl, krzk+dt@kernel.org,
conor+dt@kernel.org, shawnguo@kernel.org, s.hauer@pengutronix.de,
linux-media@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-imx@nxp.com,
linux-arm-kernel@lists.infradead.org, jackson.lee, lafley.kim,
marek.vasut@mailbox.org
In-Reply-To: <20260630161335.GA3699737-robh@kernel.org>
Hi, Rob.
>-----Original Message-----
>From: Rob Herring <robh@kernel.org>
>Sent: Wednesday, July 1, 2026 1:14 AM
>
>On Wed, Jun 24, 2026 at 04:20:36PM +0900, Nas Chung wrote:
>> Add documentation for the Chips&Media Wave6 video codec on NXP i.MX SoCs.
>>
>> The hardware contains one control register region and four interface
>> register regions for a shared video processing engine. The control region
>> manages shared resources such as firmware memory, while each interface
>> region has its own MMIO range and interrupt.
>>
>> The control region and each interface region are distinct DMA requesters
>> and can be associated with separate IOMMU stream IDs. Represent the
>> control region as the parent node and the interface register regions as
>> child nodes to describe these resources.
>>
>> Signed-off-by: Nas Chung <nas.chung@chipsnmedia.com>
>> ---
>> .../bindings/media/nxp,imx95-vpu.yaml | 163 ++++++++++++++++++
>> MAINTAINERS | 7 +
>> 2 files changed, 170 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/media/nxp,imx95-
>vpu.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/media/nxp,imx95-vpu.yaml
>b/Documentation/devicetree/bindings/media/nxp,imx95-vpu.yaml
>> new file mode 100644
>> index 000000000000..9a5ca53e15a3
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/nxp,imx95-vpu.yaml
>> @@ -0,0 +1,163 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/media/nxp,imx95-vpu.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Chips&Media Wave6 Series multi-standard codec IP on NXP i.MX SoCs
>> +
>> +maintainers:
>> + - Nas Chung <nas.chung@chipsnmedia.com>
>> + - Jackson Lee <jackson.lee@chipsnmedia.com>
>> +
>> +description:
>> + The Chips&Media Wave6 codec IP is a multi-standard video
>encoder/decoder.
>> + On NXP i.MX SoCs, the Wave6 codec IP exposes one control register
>region and
>> + four interface register regions for a shared video processing engine.
>> + The parent node describes the control region, which has its own MMIO
>range and
>> + manages shared resources such as firmware memory. The child nodes
>describe the
>> + interface register regions. Each interface region has its own MMIO
>range and
>> + interrupt.
>> + The control region and the interface regions are distinct DMA
>requesters.
>> + The control region and each interface region can be associated with
>separate
>> + IOMMU stream IDs, allowing DMA isolation between them.
>> +
>> +properties:
>> + compatible:
>> + enum:
>> + - nxp,imx95-vpu
>> +
>> + reg:
>> + maxItems: 1
>> +
>> + clocks:
>> + items:
>> + - description: VPU core clock
>> + - description: VPU associated block clock
>> +
>> + clock-names:
>> + items:
>> + - const: core
>> + - const: vpublk
>> +
>> + power-domains:
>> + items:
>> + - description: Main VPU power domain
>> + - description: Performance power domain
>> +
>> + power-domain-names:
>> + items:
>> + - const: vpu
>> + - const: perf
>> +
>> + memory-region:
>> + maxItems: 1
>> +
>> + sram:
>> + $ref: /schemas/types.yaml#/definitions/phandle
>
>Already has a type. You just need to define how many phandles (maxItems: 1).
Thanks for your feedback.
I see sram-consumer.yaml provides the type now.
I'll address this in v7.
>
>> + description:
>> + phandle to the SRAM node used to store reference data, reducing DMA
>> + memory bandwidth.
>
>Drop 'phandle to the SRAM node'
Okay.
Thanks.
Nas.
>
>Rob
^ permalink raw reply
* Re: [PATCH v2] wifi: mt76: add wcid publish check in mt76_sta_add
From: Jiajia Liu @ 2026-07-01 5:39 UTC (permalink / raw)
To: Thorsten Leemhuis
Cc: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Shayne Chen,
Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno,
Ming Yen Hsieh, Leon Yen, linux-wireless, linux-kernel,
linux-arm-kernel, linux-mediatek, Linux kernel regressions list
In-Reply-To: <b143b62e-ca11-4f00-ad60-f71ae55213b9@leemhuis.info>
On Tue, Jun 30, 2026 at 01:29:51PM +0200, Thorsten Leemhuis wrote:
> On 5/28/26 05:38, Jiajia Liu wrote:
> > Since mt7925_mac_sta_add publishes wcid, add publish check in mt76_sta_add
> > to avoid reinitializing the wcid->poll_list.
> >
> > Found dev->sta_poll_list corruption when using mt7925 and 7.1-rc4.
>
> Jiajia Liu, Felox: given that the problem seems to be in 7.1, should we
> ask the stable team to pick this regression fix up, as this change was
> mainlined (as 20b126920a259d ("wifi: mt76: add wcid publish check in
> mt76_sta_add") [v7.2-rc1]), but lacks both a Fixes and a Stable tag?
Yes. It seems to be related to cbf5e61da660 ("wifi: mt76: initialize
more wcid fields mt76_wcid_init") [v6.14-rc1]. But I didn't reproduce
when I checked it out and tested. So Fixes was not added.
>
> Ciao, Thorsten
>
> > According to the corruption information, prev->next was changed to itself.
> >
> > wlan0: disconnect from AP 90:fb:5d:94:8b:e3 for new auth to 90:fb:5d:94:8b:e2
> > wlan0: authenticate with 90:fb:5d:94:8b:e2 (local address=84:9e:56:9c:7e:6b)
> > wlan0: send auth to 90:fb:5d:94:8b:e2 (try 1/3)
> > slab kmalloc-8k start ffff8c80958a6000 pointer offset 4160 size 8192
> > list_add corruption. prev->next should be next (ffff8c808a7488f8), but was ffff8c80958a7040. (prev=ffff8c80958a7040).
> >
> > mt76_wcid_add_poll+0x95/0xd0 [mt76]
> > mt7925_mac_add_txs.part.0+0xa5/0xe0 [mt7925_common]
> > mt7925_rx_check+0xa7/0xc0 [mt7925_common]
> > mt76_dma_rx_poll+0x50d/0x790 [mt76]
> > mt792x_poll_rx+0x52/0xe0 [mt792x_lib]
> >
> > Signed-off-by: Jiajia Liu <liujiajia@kylinos.cn>
> > ---
> >
> > Changes in v2:
> > - use dev->wcid table instead of adding MT_WCID_FLAG_DRV_PUBLSH for
> > wcid publish check suggested by Sean
> > - subject and commit message update
> >
> > ---
> > drivers/net/wireless/mediatek/mt76/mac80211.c | 15 ++++++++++++---
> > 1 file changed, 12 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/net/wireless/mediatek/mt76/mac80211.c b/drivers/net/wireless/mediatek/mt76/mac80211.c
> > index 4ae5e4715a9c..b78b4cd206e0 100644
> > --- a/drivers/net/wireless/mediatek/mt76/mac80211.c
> > +++ b/drivers/net/wireless/mediatek/mt76/mac80211.c
> > @@ -1576,6 +1576,7 @@ mt76_sta_add(struct mt76_phy *phy, struct ieee80211_vif *vif,
> > {
> > struct mt76_wcid *wcid = (struct mt76_wcid *)sta->drv_priv;
> > struct mt76_dev *dev = phy->dev;
> > + struct mt76_wcid *published;
> > int ret;
> > int i;
> >
> > @@ -1595,11 +1596,19 @@ mt76_sta_add(struct mt76_phy *phy, struct ieee80211_vif *vif,
> > mtxq->wcid = wcid->idx;
> > }
> >
> > - ewma_signal_init(&wcid->rssi);
> > - rcu_assign_pointer(dev->wcid[wcid->idx], wcid);
> > + published = rcu_dereference_protected(dev->wcid[wcid->idx],
> > + lockdep_is_held(&dev->mutex));
> > + if (published != wcid) {
> > + WARN_ON_ONCE(published);
> > + ewma_signal_init(&wcid->rssi);
> > + rcu_assign_pointer(dev->wcid[wcid->idx], wcid);
> > + mt76_wcid_init(wcid, phy->band_idx);
> > + } else {
> > + wcid->phy_idx = phy->band_idx;
> > + }
> > +
> > phy->num_sta++;
> >
> > - mt76_wcid_init(wcid, phy->band_idx);
> > out:
> > mutex_unlock(&dev->mutex);
> >
^ permalink raw reply
* RE: [PATCH v6 2/9] dt-bindings: media: nxp: Add Wave6 video codec device
From: Nas Chung @ 2026-07-01 5:39 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Conor Dooley, mchehab@kernel.org, hverkuil@xs4all.nl,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
shawnguo@kernel.org, s.hauer@pengutronix.de,
linux-media@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-imx@nxp.com,
linux-arm-kernel@lists.infradead.org, jackson.lee, lafley.kim,
marek.vasut@mailbox.org
In-Reply-To: <20260625-artificial-coot-of-climate-efbecd@quoll>
Hi, Krzysztof.
>-----Original Message-----
>From: Krzysztof Kozlowski <krzk@kernel.org>
>Sent: Thursday, June 25, 2026 3:29 PM
>
>On Thu, Jun 25, 2026 at 01:43:33AM +0000, Nas Chung wrote:
>> >> + sram:
>> >> + $ref: /schemas/types.yaml#/definitions/phandle
>> >> + description:
>> >> + phandle to the SRAM node used to store reference data, reducing
>DMA
>> >> + memory bandwidth.
>> >> +
>> >> + iommus:
>> >> + maxItems: 1
>> >> +
>> >> + "#cooling-cells":
>> >> + const: 2
>> >> +
>> >> + "#address-cells":
>> >> + const: 2
>> >> +
>> >> + "#size-cells":
>> >> + const: 2
>> >> +
>> >> + ranges: true
>> >> +
>> >> +patternProperties:
>> >> + "^interface@[0-9a-f]+$":
>> >
>> >I have to wonder if this interface business is required at all.
>> >Why can this not go into the parent, with each region fetchable via
>> >reg-names, interrupt-names and iommu-names?
>>
>> Thanks for your feedback.
>>
>> I did try the flat model, but the blocker is the IOMMU.
>>
>> The control region and four interface regions are independent DMA
>requesters
>> with distinct stream IDs, and each interface can be assigned to a
>different VM,
>> driving the video core with its own isolated memory.
>>
>> If all stream IDs are listed under the parent's iommus, they bind to a
>> single device and share one domain, so the isolation is lost.
>> This is the main reason I added the interface nodes.
>
>Feels similar to issue Qualcomm has. I rejected such subnodes and
>Qualcomm came with a solution in DMA IOMMU code, but that solution was
>rejected by DMA folks:
>https://lore.kernel.org/all/c7b956a9-d3e8-4e18-b780-
>5d08f5cd2ca1@kernel.org/
>
>I don't have proper arguments to convince DMA folks, thus I agree for
>Qualcomm for the subnodes. It should be fine here as well, in such case.
Thanks for sharing this.
I'll keep the subnodes and note this rationale in the v7 cover letter.
Thanks.
Nas.
>
>Best regards,
>Krzysztof
^ permalink raw reply
* Re: [PATCH v3 1/5] dmaengine: sun6i-dma: Refactor to support A733 interrupt and register handling
From: Enzo Adriano @ 2026-07-01 5:47 UTC (permalink / raw)
To: Yuanshen Cao, Andre Przywara
Cc: conor+dt, mripard, krzk+dt, robh, samuel, wens, jernej.skrabec,
Frank.Li, vkoul, dmaengine, linux-arm-kernel, linux-sunxi,
devicetree, linux-kernel, Frank Li
In-Reply-To: <akQuefaUpt6OPNSo@b82beb281c41>
Hi Yuanshen, Andre,
I applied the v3 series locally on top of dc59e4fea9d8. The
series applied cleanly, the focused DMA binding check passed, and
a focused drivers/dma/sun6i-dma.o build passed. I have not done a
hardware DMA runtime test, so this is only static review plus
build/schema validation.
On the IRQ accessor shape, I think Andre's data-driven direction is
a good fit for the enable/status register differences. The
A733-specific values look like data: enable offset 0x134, status
offset 0x138, stride 0x40. A small helper using cfg offsets/stride
would keep the call sites readable without needing per-compatible
read/write accessors. I would keep dump_com_regs separate unless
there is a clean table-driven way to express the genuinely different
dump layout.
While comparing this with the public Sun60iw2 BSP, I think the same
respin should also fix the interrupt channel decode path that Sashiko
pointed out. The series encodes the interrupt register as:
irq_reg = pchan->idx / sdev->cfg->num_channels_per_reg;
irq_offset = pchan->idx % sdev->cfg->num_channels_per_reg;
but the interrupt handler still decodes with:
pchan = sdev->pchans + j;
For A733, num_channels_per_reg is 1, so j is always 0 and each IRQ
status register would map back to pchans[0]. The public Sun60iw2 BSP
uses the inverse mapping:
pchan = sdev->pchans + (i * sdev->cfg->channum_per_reg + j);
That matches the encode path and looks like the shape needed here as
well. The register-loop bounds probably want the same treatment:
derive the number of IRQ status registers from the real channel count,
not from an implicitly exact division.
^ permalink raw reply
* Re: [PATCH v2 0/6] clk: sun6i-rtc: Add support for Allwinner A733 SoC
From: Enzo Adriano @ 2026-07-01 5:47 UTC (permalink / raw)
To: Jerome Brunet
Cc: Junhui Liu, Alexandre Belloni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Michael Turquette, Stephen Boyd, Maxime Ripard, linux-rtc,
devicetree, linux-arm-kernel, linux-sunxi, linux-kernel,
linux-clk
In-Reply-To: <20260629-a733-rtc-v2-0-7b72112784f8@baylibre.com>
Hi Jerome,
Thanks for reworking the A733 RTC support.
I ran v2 on a Radxa Cubie A7S. This is local validation evidence
only, not a hardware Tested-by.
For the A7S integration test, I stacked the series with the currently
visible public A733 CCU/PRCM v1 and pinctrl v1 prerequisites. Focused
RTC binding validation, targeted RTC/clk builds, and a Cubie A7S DTB
build all pass, and focused CHECK_DTBS=y shows no RTC, main CCU, or
R-CCU findings. The remaining findings in that base are unrelated
A733-wide schema gaps.
On A7S hardware the artifact boots cleanly to shell and the RTC driver
probes and registers as rtc0. While the board stays powered, RTC read,
write, and a short readback all work correctly; the readback advances
as expected.
I am deliberately not adding a Tested-by. The RTC value does not
survive a full power removal on this board: the published Cubie A7S
V1.10 schematic exposes the PMIC BKUPBAT pin but does not show a
connected backup battery or supercap path, and Radxa's A7S
documentation describes no populated RTC backup battery interface. So
I can confirm the driver is runtime-functional while powered, but I
cannot honestly attest cold-power persistence on this board.
Happy to rerun only the persistence phase if a valid VRTC/BKUPBAT
backup supply is identified or fitted.
^ 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