* [PATCH v4 5/5] arm64: dts: ti: k3-j722s-main: use J722S compatibles for WIZ, gmii-sel and CPSW3G
From: Nora Schiffer @ 2026-04-07 11:42 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Vinod Koul,
Neil Armstrong
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Siddharth Vadapalli, Roger Quadros, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux, Nora Schiffer
In-Reply-To: <cover.1775559102.git.nora.schiffer@ew.tq-group.com>
Update WIZ, gmii-sel and CPSW3G to use the J722S-specific compatible
strings, enabling SGMII support. The fallback compatibles preserve
compatibility of the updated Device Trees with older kernels.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
---
arch/arm64/boot/dts/ti/k3-j722s-main.dtsi | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-j722s-main.dtsi b/arch/arm64/boot/dts/ti/k3-j722s-main.dtsi
index 9ee5d0c8ffd1e..70f430aa3a944 100644
--- a/arch/arm64/boot/dts/ti/k3-j722s-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j722s-main.dtsi
@@ -18,7 +18,7 @@ serdes_refclk: clk-0 {
&cbass_main {
serdes_wiz0: phy@f000000 {
- compatible = "ti,am64-wiz-10g";
+ compatible = "ti,j722s-wiz-10g", "ti,am64-wiz-10g";
ranges = <0x0f000000 0x0 0x0f000000 0x00010000>;
#address-cells = <1>;
#size-cells = <1>;
@@ -56,7 +56,7 @@ serdes0: serdes@f000000 {
};
serdes_wiz1: phy@f010000 {
- compatible = "ti,am64-wiz-10g";
+ compatible = "ti,j722s-wiz-10g", "ti,am64-wiz-10g";
ranges = <0x0f010000 0x0 0x0f010000 0x00010000>;
#address-cells = <1>;
#size-cells = <1>;
@@ -451,6 +451,14 @@ pcie0_ctrl: pcie0-ctrl@4070 {
};
};
+&cpsw3g {
+ compatible = "ti,j722s-cpsw-nuss", "ti,am642-cpsw-nuss";
+};
+
+&phy_gmii_sel {
+ compatible = "ti,j722s-phy-gmii-sel", "ti,am654-phy-gmii-sel";
+};
+
&oc_sram {
reg = <0x00 0x70000000 0x00 0x40000>;
ranges = <0x00 0x00 0x70000000 0x40000>;
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
^ permalink raw reply related
* [PATCH v4 4/5] phy: ti: gmii-sel: add support for J722S SoC family
From: Nora Schiffer @ 2026-04-07 11:42 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Vinod Koul,
Neil Armstrong
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Siddharth Vadapalli, Roger Quadros, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux, Nora Schiffer
In-Reply-To: <cover.1775559102.git.nora.schiffer@ew.tq-group.com>
The J722S gmii-sel is mostly identical to the AM64's, but additionally
supports SGMII.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
---
drivers/phy/ti/phy-gmii-sel.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/phy/ti/phy-gmii-sel.c b/drivers/phy/ti/phy-gmii-sel.c
index 6213c2b6005a5..c2865a6b1d7fb 100644
--- a/drivers/phy/ti/phy-gmii-sel.c
+++ b/drivers/phy/ti/phy-gmii-sel.c
@@ -251,6 +251,15 @@ struct phy_gmii_sel_soc_data phy_gmii_sel_soc_am654 = {
.regfields = phy_gmii_sel_fields_am654,
};
+static const
+struct phy_gmii_sel_soc_data phy_gmii_sel_soc_j722s = {
+ .use_of_data = true,
+ .features = BIT(PHY_GMII_SEL_RGMII_ID_MODE) |
+ BIT(PHY_GMII_SEL_FIXED_TX_DELAY),
+ .regfields = phy_gmii_sel_fields_am654,
+ .extra_modes = BIT(PHY_INTERFACE_MODE_SGMII),
+};
+
static const
struct phy_gmii_sel_soc_data phy_gmii_sel_cpsw5g_soc_j7200 = {
.use_of_data = true,
@@ -307,6 +316,10 @@ static const struct of_device_id phy_gmii_sel_id_table[] = {
.compatible = "ti,am654-phy-gmii-sel",
.data = &phy_gmii_sel_soc_am654,
},
+ {
+ .compatible = "ti,j722s-phy-gmii-sel",
+ .data = &phy_gmii_sel_soc_j722s,
+ },
{
.compatible = "ti,j7200-cpsw5g-phy-gmii-sel",
.data = &phy_gmii_sel_cpsw5g_soc_j7200,
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
^ permalink raw reply related
* [PATCH v4 1/5] dt-bindings: phy: ti: phy-j721e-wiz: Add ti,j722s-wiz-10g compatible
From: Nora Schiffer @ 2026-04-07 11:42 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Vinod Koul,
Neil Armstrong
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Siddharth Vadapalli, Roger Quadros, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux, Nora Schiffer
In-Reply-To: <cover.1775559102.git.nora.schiffer@ew.tq-group.com>
The J722S WIZ is mostly identical to the AM64's, but additionally supports
SGMII. The AM64 compatible ti,am64-wiz-10g is used as a fallback.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
---
.../bindings/phy/ti,phy-j721e-wiz.yaml | 19 ++++++++++++-------
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml b/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml
index 3f16ff14484d2..0653252c18d8e 100644
--- a/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml
+++ b/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml
@@ -12,13 +12,18 @@ maintainers:
properties:
compatible:
- enum:
- - ti,j721e-wiz-16g
- - ti,j721e-wiz-10g
- - ti,j721s2-wiz-10g
- - ti,am64-wiz-10g
- - ti,j7200-wiz-10g
- - ti,j784s4-wiz-10g
+ oneOf:
+ - enum:
+ - ti,j721e-wiz-16g
+ - ti,j721e-wiz-10g
+ - ti,j721s2-wiz-10g
+ - ti,am64-wiz-10g
+ - ti,j7200-wiz-10g
+ - ti,j784s4-wiz-10g
+ - items:
+ - enum:
+ - ti,j722s-wiz-10g
+ - const: ti,am64-wiz-10g
power-domains:
maxItems: 1
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
^ permalink raw reply related
* [PATCH v4 3/5] phy: ti: phy-j721e-wiz: add support for J722S SoC family
From: Nora Schiffer @ 2026-04-07 11:42 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Vinod Koul,
Neil Armstrong
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Siddharth Vadapalli, Roger Quadros, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux, Nora Schiffer
In-Reply-To: <cover.1775559102.git.nora.schiffer@ew.tq-group.com>
The J722S WIZ is mostly identical to the AM64's, but additionally supports
SGMII.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
---
drivers/phy/ti/phy-j721e-wiz.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/drivers/phy/ti/phy-j721e-wiz.c b/drivers/phy/ti/phy-j721e-wiz.c
index 6b584706b913a..7531a8a049123 100644
--- a/drivers/phy/ti/phy-j721e-wiz.c
+++ b/drivers/phy/ti/phy-j721e-wiz.c
@@ -331,6 +331,7 @@ enum wiz_type {
J721E_WIZ_16G,
J721E_WIZ_10G, /* Also for J7200 SR1.0 */
AM64_WIZ_10G,
+ J722S_WIZ_10G,
J7200_WIZ_10G, /* J7200 SR2.0 */
J784S4_WIZ_10G,
J721S2_WIZ_10G,
@@ -1020,6 +1021,7 @@ static void wiz_clock_cleanup(struct wiz *wiz, struct device_node *node)
switch (wiz->type) {
case AM64_WIZ_10G:
+ case J722S_WIZ_10G:
case J7200_WIZ_10G:
case J784S4_WIZ_10G:
case J721S2_WIZ_10G:
@@ -1089,6 +1091,7 @@ static void wiz_clock_init(struct wiz *wiz)
switch (wiz->type) {
case AM64_WIZ_10G:
+ case J722S_WIZ_10G:
case J7200_WIZ_10G:
switch (rate) {
case REF_CLK_100MHZ:
@@ -1158,6 +1161,7 @@ static int wiz_clock_probe(struct wiz *wiz, struct device_node *node)
switch (wiz->type) {
case AM64_WIZ_10G:
+ case J722S_WIZ_10G:
case J7200_WIZ_10G:
case J784S4_WIZ_10G:
case J721S2_WIZ_10G:
@@ -1246,6 +1250,14 @@ static int wiz_phy_fullrt_div(struct wiz *wiz, int lane)
if (wiz->lane_phy_type[lane] == PHY_TYPE_SGMII)
return regmap_field_write(wiz->p0_fullrt_div[lane], 0x2);
break;
+
+ case J722S_WIZ_10G:
+ if (wiz->lane_phy_type[lane] == PHY_TYPE_PCIE)
+ return regmap_field_write(wiz->p0_fullrt_div[lane], 0x1);
+ if (wiz->lane_phy_type[lane] == PHY_TYPE_SGMII)
+ return regmap_field_write(wiz->p0_fullrt_div[lane], 0x2);
+ break;
+
default:
return 0;
}
@@ -1350,6 +1362,15 @@ static struct wiz_data am64_10g_data = {
.clk_div_sel_num = WIZ_DIV_NUM_CLOCKS_10G,
};
+static struct wiz_data j722s_10g_data = {
+ .type = J722S_WIZ_10G,
+ .pll0_refclk_mux_sel = &pll0_refclk_mux_sel,
+ .pll1_refclk_mux_sel = &pll1_refclk_mux_sel,
+ .refclk_dig_sel = &refclk_dig_sel_10g,
+ .clk_mux_sel = clk_mux_sel_10g,
+ .clk_div_sel_num = WIZ_DIV_NUM_CLOCKS_10G,
+};
+
static struct wiz_data j7200_pg2_10g_data = {
.type = J7200_WIZ_10G,
.pll0_refclk_mux_sel = &sup_pll0_refclk_mux_sel,
@@ -1389,6 +1410,9 @@ static const struct of_device_id wiz_id_table[] = {
{
.compatible = "ti,am64-wiz-10g", .data = &am64_10g_data,
},
+ {
+ .compatible = "ti,j722s-wiz-10g", .data = &j722s_10g_data,
+ },
{
.compatible = "ti,j7200-wiz-10g", .data = &j7200_pg2_10g_data,
},
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
^ permalink raw reply related
* [PATCH v4 2/5] dt-bindings: phy: ti: phy-gmii-sel: Add ti,j722s-phy-gmii-sel compatible
From: Nora Schiffer @ 2026-04-07 11:42 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Vinod Koul,
Neil Armstrong
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Siddharth Vadapalli, Roger Quadros, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux, Nora Schiffer
In-Reply-To: <cover.1775559102.git.nora.schiffer@ew.tq-group.com>
The J722S gmii-sel is mostly identical to the AM64's, but additionally
supports SGMII. The AM64 compatible ti,am654-phy-gmii-sel is used as a
fallback.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
---
.../bindings/phy/ti,phy-gmii-sel.yaml | 23 +++++++++++--------
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml b/Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml
index be41b4547ec6d..60b644a4c6390 100644
--- a/Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml
+++ b/Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml
@@ -47,15 +47,20 @@ description: |
properties:
compatible:
- enum:
- - ti,am3352-phy-gmii-sel
- - ti,dra7xx-phy-gmii-sel
- - ti,am43xx-phy-gmii-sel
- - ti,dm814-phy-gmii-sel
- - ti,am654-phy-gmii-sel
- - ti,j7200-cpsw5g-phy-gmii-sel
- - ti,j721e-cpsw9g-phy-gmii-sel
- - ti,j784s4-cpsw9g-phy-gmii-sel
+ oneOf:
+ - enum:
+ - ti,am3352-phy-gmii-sel
+ - ti,dra7xx-phy-gmii-sel
+ - ti,am43xx-phy-gmii-sel
+ - ti,dm814-phy-gmii-sel
+ - ti,am654-phy-gmii-sel
+ - ti,j7200-cpsw5g-phy-gmii-sel
+ - ti,j721e-cpsw9g-phy-gmii-sel
+ - ti,j784s4-cpsw9g-phy-gmii-sel
+ - items:
+ - enum:
+ - ti,j722s-phy-gmii-sel
+ - const: ti,am654-phy-gmii-sel
reg:
maxItems: 1
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
^ permalink raw reply related
* [PATCH v4 0/5] J722S SGMII support
From: Nora Schiffer @ 2026-04-07 11:42 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Vinod Koul,
Neil Armstrong
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Siddharth Vadapalli, Roger Quadros, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux, Nora Schiffer
The J722S CPSW and SERDES are very similar to the variants found on the
AM64, but they additionally support SGMII. Introduce new compatible
strings for the J722S to add this support to the drivers.
This is a prerequisite for the Single-Pair Ethernet interface of the
TQ-Systems MBa67xx baseboard for the TQMa67xx SoM, which will be
submitted separately.
For SGMII to actually work on the J722S, the am65-cpsw needs to be extended
as well, which has been submitted for net-next:
https://patchwork.kernel.org/project/netdevbpf/list/?series=1078111
Fallback compatible strings allow for the patches to be applied in any
order and to go through different trees without breaking existing
functionality.
v4:
- remove redundant items: level from DT binding YAMLs
v3:
- Drop am65-cpsw changes from this series, they need to go through net-next
- Fix missing PHY_GMII_SEL_RGMII_ID_MODE and PHY_GMII_SEL_FIXED_TX_DELAY in
gmii-sel driver for RGMII delay mode configuration
v2:
- Keep support for the AM64 compatible strings as a fallback, adjust commit
messages
- Drop reference to AM64_CPSW_QUIRK_CUT_THRU flag, which only exists in the
TI vendor kernel
Nora Schiffer (5):
dt-bindings: phy: ti: phy-j721e-wiz: Add ti,j722s-wiz-10g compatible
dt-bindings: phy: ti: phy-gmii-sel: Add ti,j722s-phy-gmii-sel
compatible
phy: ti: phy-j721e-wiz: add support for J722S SoC family
phy: ti: gmii-sel: add support for J722S SoC family
arm64: dts: ti: k3-j722s-main: use J722S compatibles for WIZ, gmii-sel
and CPSW3G
.../bindings/phy/ti,phy-gmii-sel.yaml | 23 +++++++++++-------
.../bindings/phy/ti,phy-j721e-wiz.yaml | 19 +++++++++------
arch/arm64/boot/dts/ti/k3-j722s-main.dtsi | 12 ++++++++--
drivers/phy/ti/phy-gmii-sel.c | 13 ++++++++++
drivers/phy/ti/phy-j721e-wiz.c | 24 +++++++++++++++++++
5 files changed, 73 insertions(+), 18 deletions(-)
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
^ permalink raw reply
* Re: [RFC PATCH 09/15] Introduce structured tag value definition
From: Herve Codina @ 2026-04-07 11:42 UTC (permalink / raw)
To: Luca Ceresoli
Cc: David Gibson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Ayush Singh, Geert Uytterhoeven, devicetree-compiler, devicetree,
linux-kernel, devicetree-spec, Hui Pu, Ian Ray, Thomas Petazzoni
In-Reply-To: <DHHWXWJD78XO.5RNDZHYZE0U4@bootlin.com>
Hi Luca,
On Wed, 01 Apr 2026 17:11:35 +0200
"Luca Ceresoli" <luca.ceresoli@bootlin.com> wrote:
> On Tue Feb 10, 2026 at 6:33 PM CET, Herve Codina wrote:
> > The goal of structured tag values is to ease the introduction of new
> > tags in future releases with the capability for an already existing
> > release to ignore those structured tags. In order to do that data length
> > related to the unknown tag needs to be identify.
> ^
> identified
Will be fixed in the next iteration.
>
> > Also a flag is present
> "Also add a flag"
Will be updated in the next iteration.
>
> > to tell an old release if this tag can be simply skipped or must lead to
> > an error.
> >
> > Structured tag value is defined on 32bit and is defined as follow:
> >
> > Bits | 31 | 30 | 29 28 | 27 0|
> > ------+----+----------+-------------------+--------+
> > Fields| 1 | CAN_SKIP | DATA_LNG_ENCODING | TAG_ID |
> > ------+----+----------+-------------------+--------+
> >
> > Bit 31 is always set to 1 to identified a structured tag value.
> ^
> identify
>
> > Bit 30 (CAN_SKIP) is set to 1 if the tag can be safely ignore when its
> ^
> ignored
Both will be fixed in the next iteration.
>
>
> > TAG_ID value is not a known value (unknown tag). If the CAN_SKIP bit is
> > set to 0 this tag must not be ignored and an error should be reported
> > when its TAG_ID value is not a known value (unknown tag).
> >
> > Bits 29..28 (DATA_LNG_ENCODING) indicates the length of the data related
>
> I think "LEN" is more common than "LNG".
Agree, will be changed.
...
> >
> > +/* Tag values flags */
> > +#define FDT_TAG_STRUCTURED (1<<31)
> > +#define FDT_TAG_SKIP_SAFE (1<<30)
>
> This is called CAN_SKIP in the commit message and SKIP_SAFE here. Using a
> consistent name would be better IMO.
I will use SKIP_SAFE and so update the commit message accordingly in the next
iteration.
>
> > +#define FDT_TAG_DATA_MASK (3<<28)
> > +#define FDT_TAG_DATA_NONE (0<<28)
> > +#define FDT_TAG_DATA_1CELL (1<<28)
> > +#define FDT_TAG_DATA_2CELLS (2<<28)
> > +#define FDT_TAG_DATA_LNG (3<<28)
>
> I find _LNG (or _LEN) misleading: this is not the length, but rather an
> enum value telling you the length is stored in the next cell. What about
> FDT_TAG_DATA_VARLEN?
Yes indeed, VARLEN is better.
I will use FDT_TAG_DATA_VARLEN in the next iteration.
Best regards,
Hervé
^ permalink raw reply
* Re: [PATCH v3] Add remoteproc PAS loader for SoCCP on Glymur DT
From: Konrad Dybcio @ 2026-04-07 11:41 UTC (permalink / raw)
To: Ananthu C V, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Sibi Sankar
In-Reply-To: <20260403-glymur-soccp-v3-1-f0e8d57f11ba@oss.qualcomm.com>
On 4/3/26 1:39 PM, Ananthu C V wrote:
> From: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
>
> Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
> Co-developed-by: Ananthu C V <ananthu.cv@oss.qualcomm.com>
> Signed-off-by: Ananthu C V <ananthu.cv@oss.qualcomm.com>
> ---
[...]
> + remoteproc_soccp: remoteproc-soccp@d00000 {
remoteproc-soccp@ ->remoteproc@
> + compatible = "qcom,glymur-soccp-pas", "qcom,kaanapali-soccp-pas";
> + reg = <0x0 0x00d00000 0x0 0x200000>;
> +
> + interrupts-extended = <&intc GIC_SPI 167 IRQ_TYPE_EDGE_RISING>,
> + <&soccp_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
> + <&soccp_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
> + <&soccp_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
> + <&soccp_smp2p_in 3 IRQ_TYPE_EDGE_RISING>,
> + <&soccp_smp2p_in 9 IRQ_TYPE_EDGE_RISING>;
> + interrupt-names = "wdog",
> + "fatal",
> + "ready",
> + "handover",
> + "stop-ack",
> + "pong";
> +
> + clocks = <&rpmhcc RPMH_CXO_CLK>;
> + clock-names = "xo";
> +
> + power-domains = <&rpmhpd RPMHPD_CX>,
> + <&rpmhpd RPMHPD_MX>;
> + power-domain-names = "cx",
> + "mx";
> +
> + memory-region = <&soccp_mem>,
> + <&soccpdtb_mem>;
> +
> + qcom,smem-states = <&soccp_smp2p_out 0>,
> + <&soccp_smp2p_out 8>;
> + qcom,smem-state-names = "stop",
> + "ping";
> +
> + status = "disabled";
Let's drop this line, no one should desire to run a system without SoCCP
> +
> + glink-edge {
> + interrupts-extended = <&ipcc IPCC_MPROC_SOCCP
> + IPCC_MPROC_SIGNAL_GLINK_QMP
> + IRQ_TYPE_EDGE_RISING>;
> + mboxes = <&ipcc IPCC_MPROC_SOCCP
> + IPCC_MPROC_SIGNAL_GLINK_QMP>;
> + qcom,remote-pid = <19>;
> + label = "soccp";
> +
> + };
Stray \n above
Konrad
^ permalink raw reply
* [PATCH] dt-binding: leds: publish common bindings under dual license
From: Corvin Köhne @ 2026-04-07 11:39 UTC (permalink / raw)
To: linux-kernel
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Rob Herring, open list:LED SUBSYSTEM, Krzysztof Kozlowski,
Conor Dooley, Pavel Machek, Lee Jones, Corvin Köhne,
Ashley Towns, Dan Murphy, Gergo Koteles, Greg Kroah-Hartman,
INAGAKI Hiroshi, Jacek Anaszewski, Jacek Anaszewski,
Linus Torvalds, Olliver Schinagl, Pavel Machek,
Rafał Miłecki, Roderick Colenbrander
From: Corvin Köhne <c.koehne@beckhoff.com>
Changes leds/common.h DT binding header file to be published under GPLv2
or BSD-2-Clause license terms. This change allows this common LED
bindings header file to be used in software components as bootloaders
and OSes that are not published under GPLv2 terms.
All contributors to leds/common.h file in copy.
Cc: Ashley Towns <mail@ashleytowns.id.au>
Cc: Dan Murphy <dmurphy@ti.com>
Cc: Gergo Koteles <soyer@irl.hu>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: INAGAKI Hiroshi <musashino.open@gmail.com>
Cc: Jacek Anaszewski <j.anaszewski@samsung.com>
Cc: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Olliver Schinagl <oliver@schinagl.nl>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Rafał Miłecki <rafal@milecki.pl>
Cc: Roderick Colenbrander <roderick@gaikai.com>
Cc: Lee Jones <lee@kernel.org>
Cc: Rob Herring <robh@kernel.org>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: linux-leds@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Corvin Köhne <c.koehne@beckhoff.com>
---
include/dt-bindings/leds/common.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/dt-bindings/leds/common.h b/include/dt-bindings/leds/common.h
index 4f017bea0123..b7bafbaf7df3 100644
--- a/include/dt-bindings/leds/common.h
+++ b/include/dt-bindings/leds/common.h
@@ -1,4 +1,4 @@
-/* SPDX-License-Identifier: GPL-2.0 */
+/* SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) */
/*
* This header provides macros for the common LEDs device tree bindings.
*
--
2.47.3
^ permalink raw reply related
* Re: [PATCH 5/5] arm64: dts: qcom: qcs8550: add QCS8550 RB5Gen2 board support
From: Joe Sandom @ 2026-04-07 11:39 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <ehlhjfzekjnscro4ffydjhzfuiqhfkuyuxrk42x53cturzi4do@74y5k5ee6bv7>
On Sun, Apr 05, 2026 at 12:20:23AM +0300, Dmitry Baryshkov wrote:
> On Sat, Apr 04, 2026 at 10:50:58AM +0100, Joe Sandom via B4 Relay wrote:
> > From: Joe Sandom <jsandom@axon.com>
> >
> > The RB5gen2 is an embedded development platform for the
> > QCS8550, based on the Snapdragon 8 Gen 2 SoC (SM8550).
> >
> > This change implements the main board, the vision mezzanine
> > will be supported in a follow up patch.
> >
> > The main board has the following features:
> > - Qualcomm Dragonwing QCS8550 SoC
> > - Adreno GPU 740
> > - Spectra ISP
> > - Adreno VPU 8550
> > - Adreno DPU 1295
> > - 1 x 1GbE Ethernet (USB Ethernet)
> > - WIFI 7 + Bluetooth 5.4
> > - 1 x USB 2.0 Micro B (Debug)
> > - 1 x USB 3.0 Type C (ADB, DP out)
> > - 2 x USB 3.0 Type A
> > - 1 x HDMI 1.4 Type A
> > - 1 x DP 1.4 Type C
> > - 2 x WSA8845 Speaker amplifiers
> > - 2 x Speaker connectors
> > - 1 x On Board PDM MIC
> > - Accelerometer + Gyro Sensor
> > - 96Boards compatible low-speed and high-speed connectors [1]
> > - 7 x LED indicators (4 user, 2 radio, 1 power)
> > - Buttons for power, volume up/down, force USB boot
> > - 3 x Dip switches
> >
> > On-Board PMICs:
> > - PMK8550 2.1
> > - PM8550 2.0
> > - PM8550VS 2.0 x4
> > - PM8550VE 2.0
> > - PM8550B 2.0
> > - PMR735D 2.0
> > - PM8010 1.1 x2
> >
> > Product Page: [2]
> >
> > [1] https://urldefense.com/v3/__https://www.96boards.org/specifications/__;!!K76kBA!1fgy0ADknA_DP0VqDvEXe9TuFrmdabqHK1RDt53uY9WoeXsV1Bm8UJUetOp2eUzEDZ-FiipcbKzEafTxbNkQjsehrU6oWw$
> > [2] https://urldefense.com/v3/__https://www.thundercomm.com/product/qualcomm-rb5-gen-2-development-kit__;!!K76kBA!1fgy0ADknA_DP0VqDvEXe9TuFrmdabqHK1RDt53uY9WoeXsV1Bm8UJUetOp2eUzEDZ-FiipcbKzEafTxbNkQjsftljQwig$
> >
> > Signed-off-by: Joe Sandom <jsandom@axon.com>
> > ---
> > arch/arm64/boot/dts/qcom/Makefile | 1 +
> > arch/arm64/boot/dts/qcom/qcs8550-rb5gen2.dts | 1610 ++++++++++++++++++++++++++
> > 2 files changed, 1611 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> > index 4ba8e73064194926096b98b9556a3207e8f24d72..f8c65771f76629d7fafee15ac8d7bb62cd24a20f 100644
> > --- a/arch/arm64/boot/dts/qcom/Makefile
> > +++ b/arch/arm64/boot/dts/qcom/Makefile
> > @@ -184,6 +184,7 @@ qcs8300-ride-el2-dtbs := qcs8300-ride.dtb monaco-el2.dtbo
> >
> > dtb-$(CONFIG_ARCH_QCOM) += qcs8300-ride-el2.dtb
> > dtb-$(CONFIG_ARCH_QCOM) += qcs8550-aim300-aiot.dtb
> > +dtb-$(CONFIG_ARCH_QCOM) += qcs8550-rb5gen2.dtb
> > dtb-$(CONFIG_ARCH_QCOM) += qcs9100-ride.dtb
> > dtb-$(CONFIG_ARCH_QCOM) += qcs9100-ride-r3.dtb
> >
> > diff --git a/arch/arm64/boot/dts/qcom/qcs8550-rb5gen2.dts b/arch/arm64/boot/dts/qcom/qcs8550-rb5gen2.dts
> > new file mode 100644
> > index 0000000000000000000000000000000000000000..280fbd3a09997e3e2613498e25ac188680484cc4
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/qcom/qcs8550-rb5gen2.dts
> > @@ -0,0 +1,1610 @@
> > +// SPDX-License-Identifier: BSD-3-Clause
> > +/*
> > + * Copyright (c) 2026 Axon Enterprise, Inc.
> > + */
> > +
> > +/dts-v1/;
> > +
> > +#include <dt-bindings/leds/common.h>
> > +#include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
> > +#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
> > +#include "qcs8550.dtsi"
> > +#include "pm8010.dtsi"
> > +#include "pm8550.dtsi"
> > +#include "pm8550b.dtsi"
> > +#define PMK8550VE_SID 5
> > +#include "pm8550ve.dtsi"
> > +#include "pm8550vs.dtsi"
> > +#include "pmk8550.dtsi"
> > +#include "pmr735d_a.dtsi"
> > +#include "pmr735d_b.dtsi"
> > +
> > +/ {
> > + model = "Qualcomm Technologies, Inc. QCS8550 RB5Gen2";
> > + compatible = "qcom,qcs8550-rb5gen2", "qcom,qcs8550", "qcom,sm8550";
> > + chassis-type = "embedded";
> > +
> > + aliases {
> > + serial0 = &uart7;
> > + };
> > +
> > + chosen {
> > + stdout-path = "serial0:115200n8";
> > + };
> > +
> > + clocks {
> > + clk40m: can-clk {
> > + compatible = "fixed-clock";
> > + clock-frequency = <40000000>;
> > + #clock-cells = <0>;
> > + };
> > + };
> > +
> > + gpio-keys {
> > + compatible = "gpio-keys";
> > +
> > + pinctrl-0 = <&volume_up_n>;
> > + pinctrl-names = "default";
> > +
> > + key-volume-up {
> > + label = "Volume Up";
> > + linux,code = <KEY_VOLUMEUP>;
> > + gpios = <&pm8550_gpios 6 GPIO_ACTIVE_LOW>;
> > + debounce-interval = <15>;
> > + linux,can-disable;
> > + wakeup-source;
> > + };
> > + };
> > +
> > + hdmi-connector {
> > + compatible = "hdmi-connector";
> > + type = "a";
> > +
> > + port {
> > + hdmi_con: endpoint {
> > + remote-endpoint = <<9611_out>;
> > + };
> > + };
> > + };
> > +
> > + /* Lontium LT9611UXC fails FW upgrade and has timeouts with geni-i2c */
> > + /* Workaround is to use bit-banged I2C */
> > + i2c_hub_3_gpio: i2c {
> > + compatible = "i2c-gpio";
> > +
> > + sda-gpios = <&tlmm 22 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
> > + scl-gpios = <&tlmm 23 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > +
> > + leds {
> > + compatible = "gpio-leds";
> > +
> > + led-0 {
> > + label = "green:status-3";
> > + function = LED_FUNCTION_STATUS;
> > + color = <LED_COLOR_ID_GREEN>;
> > + gpios = <&pm8550_gpios 2 GPIO_ACTIVE_HIGH>;
> > + default-state = "off";
> > + };
> > +
> > + led-1 {
> > + label = "blue:bt-power";
> > + function = LED_FUNCTION_BLUETOOTH;
> > + color = <LED_COLOR_ID_BLUE>;
> > + gpios = <&pm8550b_gpios 7 GPIO_ACTIVE_HIGH>;
> > + linux,default-trigger = "bluetooth-power";
> > + default-state = "off";
> > + };
> > +
> > + led-2 {
> > + label = "yellow:wlan";
> > + function = LED_FUNCTION_WLAN;
> > + color = <LED_COLOR_ID_YELLOW>;
> > + gpios = <&pm8550b_gpios 9 GPIO_ACTIVE_HIGH>;
> > + linux,default-trigger = "phy0tx";
> > + default-state = "off";
> > + };
> > + };
> > +
> > + lt9611_1v2: lt9611-regulator-1v2 {
> > + compatible = "regulator-fixed";
> > + regulator-name = "LT9611_1V2";
> > +
> > + regulator-min-microvolt = <1200000>;
> > + regulator-max-microvolt = <1200000>;
> > +
> > + vin-supply = <&vreg_l14b_3p2>;
> > + };
> > +
> > + lt9611_3v3: lt9611-regulator-3v3 {
> > + compatible = "regulator-fixed";
> > + regulator-name = "LT9611_3V3";
> > +
> > + regulator-min-microvolt = <3300000>;
> > + regulator-max-microvolt = <3300000>;
> > +
> > + vin-supply = <&vreg_l14b_3p2>;
> > + };
> > +
> > + pmic-glink {
> > + compatible = "qcom,sm8550-pmic-glink", "qcom,pmic-glink";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + connector@0 {
> > + compatible = "usb-c-connector";
> > + reg = <0>;
> > + power-role = "dual";
> > + data-role = "dual";
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port@0 {
> > + reg = <0>;
> > +
> > + pmic_glink_hs_in: endpoint {
> > + remote-endpoint = <&usb_1_dwc3_hs>;
> > + };
> > + };
> > +
> > + port@1 {
> > + reg = <1>;
> > +
> > + pmic_glink_ss_in: endpoint {
> > + remote-endpoint = <&redriver_usb_con_ss>;
> > + };
> > + };
> > +
> > + port@2 {
> > + reg = <2>;
> > +
> > + pmic_glink_sbu_in: endpoint {
> > + remote-endpoint = <&redriver_usb_con_sbu>;
> > + };
> > + };
> > + };
> > + };
> > + };
> > +
> > + pcie_upd_1p05: regulator-pcie-upd-1p05 {
> > + compatible = "regulator-fixed";
> > + regulator-name = "PCIE_UPD_1P05";
> > + gpio = <&tlmm 179 GPIO_ACTIVE_HIGH>;
> > + vin-supply = <&vdd_ntn_0p9>;
> > + regulator-min-microvolt = <1050000>;
> > + regulator-max-microvolt = <1050000>;
> > + enable-active-high;
> > + regulator-enable-ramp-delay = <5000>;
> > + pinctrl-0 = <&upd_1p05_en>;
> > + pinctrl-names = "default";
> > + };
> > +
> > + pcie_upd_3p3: regulator-pcie-upd-3p3 {
> > + compatible = "regulator-fixed";
> > + regulator-name = "PCIE_UPD_3P3";
> > + gpio = <&tlmm 13 GPIO_ACTIVE_HIGH>;
> > + vin-supply = <&pcie_upd_1p05>;
> > + regulator-min-microvolt = <3300000>;
> > + regulator-max-microvolt = <3300000>;
> > + enable-active-high;
> > + regulator-enable-ramp-delay = <10000>;
> > + pinctrl-0 = <&upd_3p3_en>;
> > + pinctrl-names = "default";
> > + };
> > +
> > + upd_reset: regulator-upd-reset {
> > + compatible = "regulator-fixed";
> > + regulator-name = "UPD_RESET";
>
> Reset usually isn't a regulator.
Ack.
>
> > + gpio = <&tlmm 182 GPIO_ACTIVE_HIGH>;
> > + vin-supply = <&pcie_upd_3p3>;
> > + regulator-min-microvolt = <3300000>;
> > + regulator-max-microvolt = <3300000>;
> > + enable-active-high;
> > + regulator-enable-ramp-delay = <10000>;
> > + regulator-boot-on;
> > + regulator-always-on;
>
> Especially since it's not controlled.
Fair point. Will address this in v2
>
> > + pinctrl-0 = <&upd_ponrst>;
> > + pinctrl-names = "default";
> > + };
> > +
> > + usbhub_reset: regulator-usbhub-reset {
> > + compatible = "regulator-fixed";
> > + regulator-name = "USBHUB_RESET";
>
> Same here.
This will be removed entirely in v2. Checking the schematic again,
this is not actually needed
>
> > + gpio = <&tlmm 41 GPIO_ACTIVE_LOW>;
> > + regulator-min-microvolt = <3300000>;
> > + regulator-max-microvolt = <3300000>;
> > + regulator-boot-on;
> > + regulator-always-on;
> > + startup-delay-us = <1500>;
> > + off-on-delay-us = <1500>;
> > + pinctrl-0 = <&usbhub_rst>;
> > + pinctrl-names = "default";
> > + };
> > +
> > + vdd_ntn_0p9: regulator-vdd-ntn-0p9 {
> > + compatible = "regulator-fixed";
> > + regulator-name = "VDD_NTN_0P9";
> > + vin-supply = <&vdd_ntn_1p8>;
> > + regulator-min-microvolt = <899400>;
> > + regulator-max-microvolt = <899400>;
> > + regulator-enable-ramp-delay = <4300>;
> > + };
> > +
> > + vdd_ntn_1p8: regulator-vdd-ntn-1p8 {
> > + compatible = "regulator-fixed";
> > + regulator-name = "VDD_NTN_1P8";
> > + gpio = <&tlmm 67 GPIO_ACTIVE_HIGH>;
> > + regulator-min-microvolt = <1800000>;
> > + regulator-max-microvolt = <1800000>;
> > + enable-active-high;
> > + pinctrl-0 = <&ntn0_en>;
> > + pinctrl-names = "default";
> > + regulator-enable-ramp-delay = <10000>;
> > + };
> > +
> > + vdd_ntn1_0p9: regulator-vdd-ntn1-0p9 {
> > + compatible = "regulator-fixed";
> > + regulator-name = "VDD_NTN1_0P9";
> > + vin-supply = <&vdd_ntn1_1p8>;
> > + regulator-min-microvolt = <899400>;
> > + regulator-max-microvolt = <899400>;
> > + regulator-enable-ramp-delay = <4300>;
> > + };
> > +
> > + vdd_ntn1_1p8: regulator-vdd-ntn1-1p8 {
> > + compatible = "regulator-fixed";
> > + regulator-name = "VDD_NTN1_1P8";
> > + gpio = <&tlmm 42 GPIO_ACTIVE_HIGH>;
> > + regulator-min-microvolt = <1800000>;
> > + regulator-max-microvolt = <1800000>;
> > + enable-active-high;
> > + pinctrl-0 = <&ntn1_en>;
> > + pinctrl-names = "default";
> > + regulator-enable-ramp-delay = <10000>;
> > + };
> > +
> > + vph_pwr: regulator-vph-pwr {
> > + compatible = "regulator-fixed";
> > + regulator-name = "vph_pwr";
> > + regulator-min-microvolt = <3700000>;
> > + regulator-max-microvolt = <3700000>;
> > +
> > + regulator-always-on;
> > + regulator-boot-on;
> > + };
> > +
> > + sound {
> > + compatible = "qcom,sm8550-sndcard", "qcom,sm8450-sndcard";
> > + model = "QCS8550-RB5Gen2";
> > + audio-routing = "SpkrLeft IN", "WSA_SPK1 OUT",
> > + "SpkrRight IN", "WSA_SPK2 OUT",
> > + "VA DMIC0", "vdd-micb",
> > + "VA DMIC1", "vdd-micb";
> > +
> > + wsa-dai-link {
> > + link-name = "WSA Playback";
> > +
> > + cpu {
> > + sound-dai = <&q6apmbedai WSA_CODEC_DMA_RX_0>;
> > + };
> > +
> > + codec {
> > + sound-dai = <&left_spkr>, <&right_spkr>,
> > + <&swr0 0>, <&lpass_wsamacro 0>;
> > + };
> > +
> > + platform {
> > + sound-dai = <&q6apm>;
> > + };
> > + };
> > +
> > + va-dai-link {
> > + link-name = "VA Capture";
> > +
> > + cpu {
> > + sound-dai = <&q6apmbedai VA_CODEC_DMA_TX_0>;
> > + };
> > +
> > + codec {
> > + sound-dai = <&lpass_vamacro 0>;
> > + };
> > +
> > + platform {
> > + sound-dai = <&q6apm>;
> > + };
> > + };
> > + };
> > +
> > + wcn7850-pmu {
> > + compatible = "qcom,wcn7850-pmu";
> > +
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&wlan_en>, <&bt_default>, <&pmk8550_sleep_clk>;
>
> swctrl?
Bundled into bt_default since it's tied to BT
>
> > +
> > + wlan-enable-gpios = <&tlmm 80 GPIO_ACTIVE_HIGH>;
> > + bt-enable-gpios = <&tlmm 81 GPIO_ACTIVE_HIGH>;
>
> swctrl?
Thanks. Will add this in v2.
>
> > +
> > + vdd-supply = <&vreg_s5g_0p85>;
> > + vddio-supply = <&vreg_l15b_1p8>;
> > + vddaon-supply = <&vreg_s2g_0p852>;
> > + vdddig-supply = <&vreg_s4e_0p95>;
> > + vddrfa1p2-supply = <&vreg_s4g_1p25>;
> > + vddrfa1p8-supply = <&vreg_s6g_1p86>;
>
> [...]
>
> > +
> > +&gpi_dma1 {
> > + status = "okay";
> > +};
> > +
> > +&gpi_dma2 {
> > + status = "okay";
> > +};
> > +
> > +&gpu {
> > + status = "okay";
> > +};
> > +
> > +&gpu_zap_shader {
> > + firmware-name = "qcom/qcs8550/a740_zap.mbn";
> > +};
> > +
> > +&i2c_hub_2 {
> > + clock-frequency = <100000>;
> > +
> > + status = "okay";
> > +
> > + typec-mux@1c {
> > + compatible = "onnn,nb7vpq904m";
> > + reg = <0x1c>;
> > +
> > + vcc-supply = <&vreg_l15b_1p8>;
> > +
> > + retimer-switch;
> > + orientation-switch;
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port@0 {
> > + reg = <0>;
> > +
> > + redriver_usb_con_ss: endpoint {
> > + remote-endpoint = <&pmic_glink_ss_in>;
> > + };
> > + };
> > +
> > + port@1 {
> > + reg = <1>;
> > +
> > + redriver_phy_con_ss: endpoint {
> > + remote-endpoint = <&usb_dp_qmpphy_out>;
> > + data-lanes = <0 1 2 3>;
> > + };
> > + };
> > +
> > + port@2 {
> > + reg = <2>;
> > +
> > + redriver_usb_con_sbu: endpoint {
> > + remote-endpoint = <&pmic_glink_sbu_in>;
> > + };
> > + };
> > + };
> > + };
> > +};
> > +
> > +&i2c_hub_3_gpio {
> > + clock-frequency = <400000>;
> > +
> > + status = "okay";
> > +
> > + lt9611_codec: hdmi-bridge@2b {
> > + compatible = "lontium,lt9611uxc";
> > + reg = <0x2b>;
> > +
> > + interrupts-extended = <&tlmm 40 IRQ_TYPE_EDGE_FALLING>;
> > + reset-gpios = <&tlmm 7 GPIO_ACTIVE_HIGH>;
> > +
> > + vdd-supply = <<9611_1v2>;
> > + vcc-supply = <<9611_3v3>;
> > +
> > + pinctrl-names = "default";
> > + pinctrl-0 = <<9611_irq_pin <9611_rst_pin>;
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port@0 {
> > + reg = <0>;
> > +
> > + lt9611_a: endpoint {
> > + remote-endpoint = <&mdss_dsi0_out>;
> > + };
> > + };
> > +
> > + port@2 {
> > + reg = <2>;
> > +
> > + lt9611_out: endpoint {
> > + remote-endpoint = <&hdmi_con>;
> > + };
> > + };
> > + };
> > + };
> > +};
> > +
> > +&i2c_hub_4 {
> > + status = "okay";
> > +};
> > +
> > +&i2c_master_hub_0 {
> > + status = "okay";
> > +};
> > +
> > +&ipa {
> > + qcom,gsi-loader = "self";
> > + memory-region = <&ipa_fw_mem>;
>
> These two should be a part of sm8550.dtsi
Ack. Will put this in a separate commit and also tidy up hdk/qrd.
>
> > + firmware-name = "qcom/qcs8550/ipa_fws.mbn";
> > +
> > + status = "okay";
> > +};
> > +
> > +&iris {
> > + status = "okay";
> > +};
> > +
> > +&lpass_vamacro {
> > + pinctrl-0 = <&dmic01_default>;
> > + pinctrl-names = "default";
> > +
> > + qcom,dmic-sample-rate = <4800000>;
> > +
> > + vdd-micb-supply = <&vreg_l15b_1p8>;
> > +};
> > +
> > +&mdss {
> > + status = "okay";
> > +};
> > +
> > +&mdss_dsi0 {
> > + vdda-supply = <&vreg_l3e_1p2>;
> > +
> > + status = "okay";
> > +};
> > +
> > +&mdss_dsi0_out {
> > + remote-endpoint = <<9611_a>;
> > + data-lanes = <0 1 2 3>;
> > +};
> > +
> > +&mdss_dsi0_phy {
> > + vdds-supply = <&vreg_l1e_0p88>;
> > +
> > + status = "okay";
> > +};
> > +
> > +&mdss_dp0 {
> > + status = "okay";
> > +};
> > +
> > +&pcie0 {
> > + wake-gpios = <&tlmm 96 GPIO_ACTIVE_HIGH>;
> > + perst-gpios = <&tlmm 94 GPIO_ACTIVE_LOW>;
> > +
> > + pinctrl-0 = <&pcie0_default_state>;
> > + pinctrl-names = "default";
> > +
> > + iommu-map = <0x0 &apps_smmu 0x1400 0x1>,
> > + <0x100 &apps_smmu 0x1401 0x1>,
> > + <0x208 &apps_smmu 0x1402 0x1>,
> > + <0x210 &apps_smmu 0x1403 0x1>,
> > + <0x218 &apps_smmu 0x1404 0x1>,
> > + <0x300 &apps_smmu 0x1407 0x1>,
> > + <0x400 &apps_smmu 0x1408 0x1>,
> > + <0x500 &apps_smmu 0x140c 0x1>,
> > + <0x501 &apps_smmu 0x140e 0x1>;
> > +
> > + /delete-property/ msi-map;
>
> Why?
I tried extending the msi-map to cover the RIDs from the QPS615
PCIe switch (matching the iommu-map entries), but this caused
ITS MAPD command timeouts. From what I could gather, deleting
msi-map forces the PCIe controller to fall back to the internal
iMSI-RX module, where this worked properly.
For reference, I checked the RB3gen2 since it also uses a QPS615
and there doesn't seem to be any msi-map defined (in kodiak.dtsi).
Any recommendations to resolve this properly?
>
> > +
> > + status = "okay";
> > +};
> > +
> [...]
> > +
> > +&pcie1 {
> > + wake-gpios = <&tlmm 99 GPIO_ACTIVE_HIGH>;
> > + perst-gpios = <&tlmm 97 GPIO_ACTIVE_LOW>;
> > +
> > + pinctrl-0 = <&pcie1_default_state>;
> > + pinctrl-names = "default";
> > +
> > + iommu-map = <0x0 &apps_smmu 0x1480 0x1>,
> > + <0x100 &apps_smmu 0x1481 0x1>,
> > + <0x208 &apps_smmu 0x1482 0x1>,
> > + <0x210 &apps_smmu 0x1483 0x1>,
> > + <0x218 &apps_smmu 0x1484 0x1>,
> > + <0x300 &apps_smmu 0x1487 0x1>,
> > + <0x400 &apps_smmu 0x1488 0x1>,
> > + <0x500 &apps_smmu 0x148c 0x1>,
> > + <0x501 &apps_smmu 0x148e 0x1>;
> > +
> > + /delete-property/ msi-map;
>
> Why?
Same as above, for the RB5gen2, both PCIE0 and PCIE1 have QPS615
PCIE switches.
>
> > +
> > + status = "okay";
> > +};
> > +
> > +&pcie1_phy {
> > + vdda-phy-supply = <&vreg_l3c_0p9>;
> > + vdda-pll-supply = <&vreg_l3e_1p2>;
> > + vdda-qref-supply = <&vreg_l1e_0p88>;
> > +
> > + status = "okay";
> > +};
> > +
>
> [...]
>
> > +
> > +&remoteproc_adsp {
> > + firmware-name = "qcom/qcs8550/adsp.mdt",
> > + "qcom/qcs8550/adsp_dtb.mdt";
>
> MBN, please align vertically on the quote mark. The same for CDSP and
> modem.
Ack. Will correct this for v2.
>
>
> > + status = "okay";
> > +};
> > +
> > +&remoteproc_cdsp {
> > + firmware-name = "qcom/qcs8550/cdsp.mdt",
> > + "qcom/qcs8550/cdsp_dtb.mdt";
> > + status = "okay";
> > +};
> > +
> > +&remoteproc_mpss {
> > + firmware-name = "qcom/qcs8550/modem.mdt",
> > + "qcom/qcs8550/modem_dtb.mdt";
> > + status = "okay";
> > +};
> > +
>
> --
> With best wishes
> Dmitry
^ permalink raw reply
* Re: [PATCH v2 1/3] arm64: dts: qcom: kaanapali: Add USB support for Kaanapali SoC
From: Konrad Dybcio @ 2026-04-07 11:37 UTC (permalink / raw)
To: Krishna Kurapati, Aiqun(Maria) Yu, Jingyi Wang
Cc: linux-arm-msm, devicetree, Konrad Dybcio, Bjorn Andersson,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-kernel,
Ronak Raheja, Jingyi Wang
In-Reply-To: <3a415fae-bafc-4e23-bfca-564bff90cf2d@oss.qualcomm.com>
On 4/6/26 7:52 PM, Krishna Kurapati wrote:
>
>
> On 3/30/2026 2:48 PM, Konrad Dybcio wrote:
>> On 3/29/26 7:52 PM, Krishna Kurapati wrote:
>>> From: Ronak Raheja <ronak.raheja@oss.qualcomm.com>
>>>
>>> Add the base USB devicetree definitions for Kaanapali platform. The overall
>>> chipset contains a single DWC3 USB3 controller (rev. 200a), SS QMP PHY
>>> (rev. v8) and M31 eUSB2 PHY.
>>>
>>> Signed-off-by: Ronak Raheja <ronak.raheja@oss.qualcomm.com>
>>> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
>>> Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
>>> ---
>>
>> [...]
>>
>>> + usb: usb@a600000 {
>>> + compatible = "qcom,kaanapali-dwc3", "qcom,snps-dwc3";
>>> + reg = <0x0 0x0a600000 0x0 0xfc100>;
>>
>> Following the woes on Hamoa, can the platform suspend and wake up
>> succesfully with the flattened DT node?
>>
>
> There is a crash on resume when I tested but it comes up even without my changes:
>
> [ 65.263890] Call trace:
> [ 65.266489] kthreads_update_affinity+0x94/0x158 (P)
> [ 65.271664] kthreads_online_cpu+0x14/0x84
> [ 65.275951] cpuhp_invoke_callback+0xdc/0x1dc
> [ 65.280514] cpuhp_thread_fun+0x11c/0x168
> [ 65.284717] smpboot_thread_fn+0x1e4/0x24c
> [ 65.289019] kthread+0x104/0x124
> [ 65.292411] ret_from_fork+0x10/0x20
> [ 65.296156] Code: f94002f7 eb1602ff 540003a0 f85f82e8 (b9402d09)
> [ 65.302490] ---[ end trace 0000000000000000 ]---
>
> Hence I believe my changes are not causing any crash.
Oh.. that's.. not good.. I was hoping someone tested that..
+Maria, Jingyi for awareness
Konrad
^ permalink raw reply
* Re: [PATCH 1/2] mmc: cqe: Add CQE DT support for cadence controller
From: Krzysztof Kozlowski @ 2026-04-07 11:30 UTC (permalink / raw)
To: rohan1sj, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Masahiro Yamada, Adrian Hunter
Cc: linux-mmc, devicetree, linux-kernel, Milind Parab,
Swapnil Jakhade, Manikandan Pillai
In-Reply-To: <20260407-cdns_sdhci_cqe-support-v1-1-13efc0810631@cadence.com>
On 07/04/2026 13:18, rohan1sj via B4 Relay wrote:
> From: rohan1sj <rohan1sj@cadence.com>
>
Please use subject prefixes matching the subsystem. You can get them for
example with `git log --oneline -- DIRECTORY_OR_FILE` on the directory
your patch is touching. For bindings, the preferred subjects are
explained here:
https://www.kernel.org/doc/html/latest/devicetree/bindings/submitting-patches.html#i-for-patch-submitters
> Add DT config required to support CQE as present in
> cadence eMMC host controller
What is DT config?
Which devices? Say something useful here.
>
> Signed-off-by: rohan1sj <rohan1sj@cadence.com>
Please use known identity.
> ---
> .../devicetree/bindings/mmc/cdns,sdhci.yaml | 32 +++++++++++++++++++++-
> 1 file changed, 31 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml b/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml
> index ac75d694611a..c0d8aefe20c2 100644
> --- a/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml
> +++ b/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml
> @@ -24,6 +24,10 @@ properties:
> minItems: 1
> maxItems: 2
>
> + reg-names:
> + minItems: 1
> + maxItems: 2
List would have to be here.
> +
> interrupts:
> maxItems: 1
>
> @@ -139,7 +143,19 @@ allOf:
> else:
> properties:
> reg:
> - maxItems: 1
> + oneOf:
> + - items:
> + - description: Host controller registers
> + - items:
> + - description: Host controller registers
> + - description: CQE (Command Queue Engine) registers
So just one list with minItems
> + reg-names:
> + oneOf:
> + - items:
> + - const: sdhci
> + - items:
> + - const: sdhci
core
> + - const: cqhci
cqe
Anyway, reg-names here are pointless. They should be in top-level.
You also need to disallow the reg-names for Pensando, because it has
completely different.
>
> unevaluatedProperties: false
>
> @@ -156,3 +172,17 @@ examples:
> mmc-hs400-1_8v;
> cdns,phy-dll-delay-sdclk = <0>;
> };
> +
> + - |
> + emmc_cqe: mmc@5b000000 {
> + compatible = "socionext,uniphier-sd4hc", "cdns,sd4hc";
> + reg = <0x5b000000 0x400>, <0x5b000400 0x060>;
No need for new example. Just correct existing one.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/2] mmc: cqe: Add CQE support for cadence mmc driver
From: Krzysztof Kozlowski @ 2026-04-07 11:30 UTC (permalink / raw)
To: rohan1sj, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Masahiro Yamada, Adrian Hunter
Cc: linux-mmc, devicetree, linux-kernel, Milind Parab,
Swapnil Jakhade, Manikandan Pillai
In-Reply-To: <20260407-cdns_sdhci_cqe-support-v1-2-13efc0810631@cadence.com>
On 07/04/2026 13:18, rohan1sj via B4 Relay wrote:
> +static int sdhci_cdns_cqe_add_host(struct sdhci_host *host, struct platform_device *pdev)
> +{
> + struct cqhci_host *cq_host;
> + bool dma64;
> + int ret;
> +
> + /* setup SDHCI host first */
> + ret = sdhci_setup_host(host);
> +
> + if (ret)
> + return ret;
> +
> + /* Init CQE */
> + cq_host = cqhci_pltfm_init(pdev);
> + if (IS_ERR(cq_host)) {
> + ret = PTR_ERR(cq_host);
> + goto cleanup;
> + }
> +
> + dma64 = host->flags & SDHCI_USE_64_BIT_DMA;
> + if (dma64)
> + cq_host->caps |= CQHCI_TASK_DESC_SZ_128;
> +
> + cq_host->ops = &sdhci_cdns_cqhci_ops;
> +
> + host->mmc->caps2 |= MMC_CAP2_CQE | MMC_CAP2_CQE_DCMD;
> +
> + /* Finally initialize CQHCI */
> + ret = cqhci_init(cq_host, host->mmc, dma64);
> + if (ret) {
> + dev_err(mmc_dev(host->mmc), "Failed to initialize CQHCI: %d\n", ret);
So here error msg
> + goto cleanup;
> + }
> +
> + /* add host to MMC subsystem */
> + ret = __sdhci_add_host(host);
> + if (ret)
> + goto cleanup;
> +
> + dev_info(mmc_dev(host->mmc), "CQE init: success\n");
dev_dbg
This does not look like useful printk message. Drivers should be silent
on success:
https://elixir.bootlin.com/linux/v6.15-rc7/source/Documentation/process/coding-style.rst#L913
https://elixir.bootlin.com/linux/v6.15-rc7/source/Documentation/process/debugging/driver_development_debugging_guide.rst#L79
> + return 0;
> +
> +cleanup:
> + dev_err(mmc_dev(host->mmc), "CQE init: failed for %s\n", mmc_hostname(host->mmc));
And here also error message. Why twice?
And if it is probe path, why aren't you using dev_err_probe()?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] arm64: dts: qcom: kodiak: Add iface clock for ice sdhc
From: Kuldeep Singh @ 2026-04-07 11:26 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <a940926f-901d-4907-b029-e4c6fc62625f@oss.qualcomm.com>
On 4/7/2026 4:48 PM, Konrad Dybcio wrote:
> On 4/7/26 1:09 PM, Kuldeep Singh wrote:
>>>> diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
>>>> index dda4697a61b7..5e6b659e8719 100644
>>>> --- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
>>>> +++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
>>>> @@ -1082,7 +1082,8 @@ sdhc_ice: crypto@7c8000 {
>>>> compatible = "qcom,sc7280-inline-crypto-engine",
>>>> "qcom,inline-crypto-engine";
>>>> reg = <0x0 0x007c8000 0x0 0x18000>;
>>>> - clocks = <&gcc GCC_SDCC1_ICE_CORE_CLK>;
>>>> + clocks = <&gcc GCC_SDCC1_ICE_CORE_CLK>, <&gcc GCC_SDCC1_AHB_CLK>;
>>>> + clock-names = "core", "iface";
>>>
>>> nit: one a line would be preferred, please fix that up as you seemingly
>>> need a v2 anyway
>>
>> Hi Konrad, Didn't get your comment completely.
>>
>> Do I need to send v2 to just fix clock entries in 2 lines?
>> Or some other comment to address and send v2 for that?
>> I don't see any other comment on patchset to address.
>
> I didn't see your reply to Dmitry's initial comment about the DT bindings
> requiring an update.
Here's my reply to Dmitry's comment.
https://lore.kernel.org/linux-arm-msm/f05ac643-1ec4-4700-aace-c1a9d0cd9e07@oss.qualcomm.com/
Bindings are updated with maxItems:2 in dependent patch series.
--
Regards
Kuldeep
^ permalink raw reply
* Re: [PATCH v5 3/3] arm64: dts: qcom: lemans-evk-ifp-mezzanine: Enable mdss1 display Port
From: Konrad Dybcio @ 2026-04-07 11:26 UTC (permalink / raw)
To: Mani Chandana Ballary Kuntumalla, dmitry.baryshkov,
marijn.suijten, swboyd, mripard, abel.vesa, andersson,
konradybcio, robh, krzk+dt, conor+dt, robin.clark, jessica.zhang,
abhinav.kumar, sean, airlied, simona, alex.vinarskis
Cc: Vishnu Saini, linux-arm-msm, devicetree, linux-kernel,
linux-arm-kernel, freedreno, dri-devel, quic_rajeevny,
quic_vproddut, quic_riteshk
In-Reply-To: <20260402095003.3758176-4-quic_mkuntuma@quicinc.com>
On 4/2/26 11:50 AM, Mani Chandana Ballary Kuntumalla wrote:
> From: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
>
> Enable DP controllers, DPTX0 and DPTX1 alongside
> their corresponding PHYs of mdss1 which corresponds to eDP2
> and eDP3.
>
> Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
> Signed-off-by: Mani Chandana Ballary Kuntumalla <quic_mkuntuma@quicinc.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v5 2/3] arm64: dts: qcom: lemans-ride: Enable mdss1 display Port
From: Konrad Dybcio @ 2026-04-07 11:25 UTC (permalink / raw)
To: Mani Chandana Ballary Kuntumalla, dmitry.baryshkov,
marijn.suijten, swboyd, mripard, abel.vesa, andersson,
konradybcio, robh, krzk+dt, conor+dt, robin.clark, jessica.zhang,
abhinav.kumar, sean, airlied, simona, alex.vinarskis
Cc: linux-arm-msm, devicetree, linux-kernel, linux-arm-kernel,
freedreno, dri-devel, quic_rajeevny, quic_vproddut, quic_riteshk
In-Reply-To: <20260402095003.3758176-3-quic_mkuntuma@quicinc.com>
On 4/2/26 11:50 AM, Mani Chandana Ballary Kuntumalla wrote:
> This change enables DP controllers, DPTX0 and DPTX1 alongside
> their corresponding PHYs of mdss1 which corresponds to edp2
> and edp3.
>
> Signed-off-by: Mani Chandana Ballary Kuntumalla <quic_mkuntuma@quicinc.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: sc8280xp: Add ADSP FastRPC node
From: Konrad Dybcio @ 2026-04-07 11:23 UTC (permalink / raw)
To: Pengyu Luo, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Srinivas Kandagatla,
Ekansh Gupta
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <66e25445-e7f8-405e-b208-e69b6b401f90@oss.qualcomm.com>
On 4/7/26 1:22 PM, Konrad Dybcio wrote:
> On 4/3/26 2:07 PM, Pengyu Luo wrote:
>> Add the FastRPC node to enable offloading compute tasks to the ADSP
>> via the FastRPC framework.
>>
>> Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com>
>> ---
>> arch/arm64/boot/dts/qcom/sc8280xp.dtsi | 27 ++++++++++++++++++++++++++
>> 1 file changed, 27 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
>> index 761f229e8f47..ee02acd18856 100644
>> --- a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
>> @@ -2966,6 +2966,33 @@ IPCC_MPROC_SIGNAL_GLINK_QMP
>> label = "lpass";
>> qcom,remote-pid = <2>;
>>
>> + fastrpc {
>> + compatible = "qcom,fastrpc";
>> + qcom,glink-channels = "fastrpcglink-apps-dsp";
>> + label = "adsp";
>> + qcom,non-secure-domain;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + compute-cb@3 {
>> + compatible = "qcom,fastrpc-compute-cb";
>> + reg = <3>;
>> + iommus = <&apps_smmu 0x0c03 0x0>;
>
> These are SIDs destined for the CDSP.. (how) have you tested this
> patch?
>
> +Srini, Ekansh I can't quite decode which SIDs are "allowed" for FastRPC
> on Hamoa's ADSP.. could you please help here?
As I hit enter, I noticed this is indeed not hamoa and these numbers
were just coincidental..
The patch is alright
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: sc8280xp: Add ADSP FastRPC node
From: Konrad Dybcio @ 2026-04-07 11:22 UTC (permalink / raw)
To: Pengyu Luo, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Srinivas Kandagatla,
Ekansh Gupta
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260403120753.105869-1-mitltlatltl@gmail.com>
On 4/3/26 2:07 PM, Pengyu Luo wrote:
> Add the FastRPC node to enable offloading compute tasks to the ADSP
> via the FastRPC framework.
>
> Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com>
> ---
> arch/arm64/boot/dts/qcom/sc8280xp.dtsi | 27 ++++++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> index 761f229e8f47..ee02acd18856 100644
> --- a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> @@ -2966,6 +2966,33 @@ IPCC_MPROC_SIGNAL_GLINK_QMP
> label = "lpass";
> qcom,remote-pid = <2>;
>
> + fastrpc {
> + compatible = "qcom,fastrpc";
> + qcom,glink-channels = "fastrpcglink-apps-dsp";
> + label = "adsp";
> + qcom,non-secure-domain;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + compute-cb@3 {
> + compatible = "qcom,fastrpc-compute-cb";
> + reg = <3>;
> + iommus = <&apps_smmu 0x0c03 0x0>;
These are SIDs destined for the CDSP.. (how) have you tested this
patch?
+Srini, Ekansh I can't quite decode which SIDs are "allowed" for FastRPC
on Hamoa's ADSP.. could you please help here?
Konrad
^ permalink raw reply
* Re: [PATCH v5 2/2] dt-bindings: pinctrl: pinctrl-max77620: convert to DT schema
From: Svyatoslav Ryhel @ 2026-04-07 11:20 UTC (permalink / raw)
To: Linus Walleij
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Liam Girdwood,
Mark Brown, linux-gpio, devicetree, linux-kernel
In-Reply-To: <CAD++jL=SQsfwOiaTQqzPmbuUECtNi6qO+yuYXgTps0c5SV1OYg@mail.gmail.com>
вт, 7 квіт. 2026 р. о 12:59 Linus Walleij <linusw@kernel.org> пише:
>
> On Mon, Apr 6, 2026 at 9:51 AM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
>
> > Convert pinctrl-max77620 devicetree bindings for the MAX77620 PMIC from
> > TXT to YAML format. This patch does not change any functionality; the
> > bindings remain the same.
> >
> > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
>
> LGTM but waiting for DT maintainers to look at it before merging.
>
> Can I merge this one patch separately to the pinctrl tree?
>
Yes, if DT maintainers find this patch acceptable, it should be merged
into pinctrl tree since all remaining patches of the original patchset
were already picked and applied.
> Yours,
> Linus Walleij
^ permalink raw reply
* Re: [PATCH 1/2] arm64: dts: qcom: kodiak: Add iface clock for ice sdhc
From: Konrad Dybcio @ 2026-04-07 11:18 UTC (permalink / raw)
To: Kuldeep Singh, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <a2e2df62-42f7-464d-8833-8eabc7d92ecb@oss.qualcomm.com>
On 4/7/26 1:09 PM, Kuldeep Singh wrote:
>>> diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
>>> index dda4697a61b7..5e6b659e8719 100644
>>> --- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
>>> +++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
>>> @@ -1082,7 +1082,8 @@ sdhc_ice: crypto@7c8000 {
>>> compatible = "qcom,sc7280-inline-crypto-engine",
>>> "qcom,inline-crypto-engine";
>>> reg = <0x0 0x007c8000 0x0 0x18000>;
>>> - clocks = <&gcc GCC_SDCC1_ICE_CORE_CLK>;
>>> + clocks = <&gcc GCC_SDCC1_ICE_CORE_CLK>, <&gcc GCC_SDCC1_AHB_CLK>;
>>> + clock-names = "core", "iface";
>>
>> nit: one a line would be preferred, please fix that up as you seemingly
>> need a v2 anyway
>
> Hi Konrad, Didn't get your comment completely.
>
> Do I need to send v2 to just fix clock entries in 2 lines?
> Or some other comment to address and send v2 for that?
> I don't see any other comment on patchset to address.
I didn't see your reply to Dmitry's initial comment about the DT bindings
requiring an update.
I'd prefer if you sent a v2 with that formatting change. Patches will not be
merged for some ~3 weeks now, due to the kernel release cycle so it'll have
to wait a bit anyway
Konrad
^ permalink raw reply
* [PATCH 2/2] mmc: cqe: Add CQE support for cadence mmc driver
From: rohan1sj via B4 Relay @ 2026-04-07 11:18 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Masahiro Yamada, Adrian Hunter
Cc: linux-mmc, devicetree, linux-kernel, Milind Parab,
Swapnil Jakhade, Manikandan Pillai, rohan1sj
In-Reply-To: <20260407-cdns_sdhci_cqe-support-v1-0-13efc0810631@cadence.com>
From: rohan1sj <rohan1sj@cadence.com>
Add Command Queuing Engine (CQE) support for cadence driver
Signed-off-by: rohan1sj <rohan1sj@cadence.com>
---
drivers/mmc/host/sdhci-cadence.c | 118 ++++++++++++++++++++++++++++++++++++++-
1 file changed, 115 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/sdhci-cadence.c b/drivers/mmc/host/sdhci-cadence.c
index 435603c8c00b..14b12272dae9 100644
--- a/drivers/mmc/host/sdhci-cadence.c
+++ b/drivers/mmc/host/sdhci-cadence.c
@@ -15,6 +15,8 @@
#include <linux/reset.h>
#include "sdhci-pltfm.h"
+#include "sdhci-cqhci.h"
+#include "cqhci.h"
/* HRS - Host Register Set (specific to Cadence) */
#define SDHCI_CDNS_HRS04 0x10 /* PHY access port */
@@ -36,6 +38,10 @@
#define SDHCI_CDNS_HRS06_MODE_MMC_HS400 0x5
#define SDHCI_CDNS_HRS06_MODE_MMC_HS400ES 0x6
+/* Host capabilities not covered by the standard capability registers (SRS16-SRS18) */
+#define SDHCI_CDNS_HRS30 0x78 /* Host capabilities */
+#define SDHCI_CDNS_HRS30_CQE_SUPPORTED BIT(0)
+
/* Read block gap */
#define SDHCI_CDNS_HRS37 0x94 /* interface mode select */
#define SDHCI_CDNS_HRS37_MODE_DS 0x0
@@ -88,6 +94,7 @@ struct sdhci_cdns_priv {
void __iomem *ctl_addr; /* write control */
spinlock_t wrlock; /* write lock */
bool enhanced_strobe;
+ bool cqe_support; /* Command Queuing Engine support */
void (*priv_writel)(struct sdhci_cdns_priv *priv, u32 val, void __iomem *reg);
struct reset_control *rst_hw;
unsigned int nr_phy_params;
@@ -385,6 +392,73 @@ static void sdhci_cdns_set_uhs_signaling(struct sdhci_host *host,
sdhci_set_uhs_signaling(host, timing);
}
+static u32 sdhci_cdns_cqhci_irq(struct sdhci_host *host, u32 intmask)
+{
+ int cmd_err = 0;
+ int data_err = 0;
+
+ /* return original intmask to be handled by other handlers if it's not a CQE interrupt */
+ if (!sdhci_cqe_irq(host, intmask, &cmd_err, &data_err))
+ return intmask;
+
+ cqhci_irq(host->mmc, intmask, cmd_err, data_err);
+
+ return 0;
+}
+
+static const struct cqhci_host_ops sdhci_cdns_cqhci_ops = {
+ .enable = sdhci_cqe_enable,
+ .disable = sdhci_cqe_disable,
+};
+
+static int sdhci_cdns_cqe_add_host(struct sdhci_host *host, struct platform_device *pdev)
+{
+ struct cqhci_host *cq_host;
+ bool dma64;
+ int ret;
+
+ /* setup SDHCI host first */
+ ret = sdhci_setup_host(host);
+
+ if (ret)
+ return ret;
+
+ /* Init CQE */
+ cq_host = cqhci_pltfm_init(pdev);
+ if (IS_ERR(cq_host)) {
+ ret = PTR_ERR(cq_host);
+ goto cleanup;
+ }
+
+ dma64 = host->flags & SDHCI_USE_64_BIT_DMA;
+ if (dma64)
+ cq_host->caps |= CQHCI_TASK_DESC_SZ_128;
+
+ cq_host->ops = &sdhci_cdns_cqhci_ops;
+
+ host->mmc->caps2 |= MMC_CAP2_CQE | MMC_CAP2_CQE_DCMD;
+
+ /* Finally initialize CQHCI */
+ ret = cqhci_init(cq_host, host->mmc, dma64);
+ if (ret) {
+ dev_err(mmc_dev(host->mmc), "Failed to initialize CQHCI: %d\n", ret);
+ goto cleanup;
+ }
+
+ /* add host to MMC subsystem */
+ ret = __sdhci_add_host(host);
+ if (ret)
+ goto cleanup;
+
+ dev_info(mmc_dev(host->mmc), "CQE init: success\n");
+ return 0;
+
+cleanup:
+ dev_err(mmc_dev(host->mmc), "CQE init: failed for %s\n", mmc_hostname(host->mmc));
+ sdhci_cleanup_host(host);
+ return ret;
+}
+
/* Elba control register bits [6:3] are byte-lane enables */
#define ELBA_BYTE_ENABLE_MASK(x) ((x) << 3)
@@ -474,9 +548,10 @@ static const struct sdhci_ops sdhci_cdns_ops = {
.set_clock = sdhci_set_clock,
.get_timeout_clock = sdhci_cdns_get_timeout_clock,
.set_bus_width = sdhci_set_bus_width,
- .reset = sdhci_reset,
+ .reset = sdhci_and_cqhci_reset,
.platform_execute_tuning = sdhci_cdns_execute_tuning,
.set_uhs_signaling = sdhci_cdns_set_uhs_signaling,
+ .irq = sdhci_cdns_cqhci_irq,
};
static const struct sdhci_cdns_drv_data sdhci_cdns_uniphier_drv_data = {
@@ -553,6 +628,8 @@ static int sdhci_cdns_probe(struct platform_device *pdev)
int ret;
struct device *dev = &pdev->dev;
static const u16 version = SDHCI_SPEC_400 << SDHCI_SPEC_VER_SHIFT;
+ bool cqe_enabled;
+ u32 host_caps;
clk = devm_clk_get_enabled(dev, NULL);
if (IS_ERR(clk))
@@ -608,7 +685,35 @@ static int sdhci_cdns_probe(struct platform_device *pdev)
host->mmc_host_ops.card_hw_reset = sdhci_cdns_mmc_hw_reset;
}
- return sdhci_add_host(host);
+ host_caps = readl(priv->hrs_addr + SDHCI_CDNS_HRS30);
+ cqe_enabled = host_caps & SDHCI_CDNS_HRS30_CQE_SUPPORTED;
+
+ if (cqe_enabled) {
+ priv->cqe_support = true;
+ ret = sdhci_cdns_cqe_add_host(host, pdev);
+ } else {
+ ret = sdhci_add_host(host);
+ }
+
+ return ret;
+}
+
+static int sdhci_cdns_suspend(struct device *dev)
+{
+ struct sdhci_host *host = dev_get_drvdata(dev);
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ struct sdhci_cdns_priv *priv = sdhci_pltfm_priv(pltfm_host);
+ int ret;
+
+ if (priv->cqe_support) {
+ ret = cqhci_suspend(host->mmc);
+ if (ret)
+ return ret;
+ }
+
+ ret = sdhci_pltfm_suspend(dev);
+
+ return ret;
}
static int sdhci_cdns_resume(struct device *dev)
@@ -630,6 +735,13 @@ static int sdhci_cdns_resume(struct device *dev)
if (ret)
goto disable_clk;
+ /* Resume CQE if enabled */
+ if (priv->cqe_support) {
+ ret = cqhci_resume(host->mmc);
+ if (ret)
+ goto disable_clk;
+ }
+
return 0;
disable_clk:
@@ -638,7 +750,7 @@ static int sdhci_cdns_resume(struct device *dev)
return ret;
}
-static DEFINE_SIMPLE_DEV_PM_OPS(sdhci_cdns_pm_ops, sdhci_pltfm_suspend, sdhci_cdns_resume);
+static DEFINE_SIMPLE_DEV_PM_OPS(sdhci_cdns_pm_ops, sdhci_cdns_suspend, sdhci_cdns_resume);
static const struct of_device_id sdhci_cdns_match[] = {
{
--
2.34.1
^ permalink raw reply related
* [PATCH 1/2] mmc: cqe: Add CQE DT support for cadence controller
From: rohan1sj via B4 Relay @ 2026-04-07 11:18 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Masahiro Yamada, Adrian Hunter
Cc: linux-mmc, devicetree, linux-kernel, Milind Parab,
Swapnil Jakhade, Manikandan Pillai, rohan1sj
In-Reply-To: <20260407-cdns_sdhci_cqe-support-v1-0-13efc0810631@cadence.com>
From: rohan1sj <rohan1sj@cadence.com>
Add DT config required to support CQE as present in
cadence eMMC host controller
Signed-off-by: rohan1sj <rohan1sj@cadence.com>
---
.../devicetree/bindings/mmc/cdns,sdhci.yaml | 32 +++++++++++++++++++++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml b/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml
index ac75d694611a..c0d8aefe20c2 100644
--- a/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml
+++ b/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml
@@ -24,6 +24,10 @@ properties:
minItems: 1
maxItems: 2
+ reg-names:
+ minItems: 1
+ maxItems: 2
+
interrupts:
maxItems: 1
@@ -139,7 +143,19 @@ allOf:
else:
properties:
reg:
- maxItems: 1
+ oneOf:
+ - items:
+ - description: Host controller registers
+ - items:
+ - description: Host controller registers
+ - description: CQE (Command Queue Engine) registers
+ reg-names:
+ oneOf:
+ - items:
+ - const: sdhci
+ - items:
+ - const: sdhci
+ - const: cqhci
unevaluatedProperties: false
@@ -156,3 +172,17 @@ examples:
mmc-hs400-1_8v;
cdns,phy-dll-delay-sdclk = <0>;
};
+
+ - |
+ emmc_cqe: mmc@5b000000 {
+ compatible = "socionext,uniphier-sd4hc", "cdns,sd4hc";
+ reg = <0x5b000000 0x400>, <0x5b000400 0x060>;
+ reg-names = "sdhci", "cqhci";
+ interrupts = <0 79 4>;
+ clocks = <&clk 4>;
+ bus-width = <8>;
+ mmc-ddr-1_8v;
+ mmc-hs200-1_8v;
+ mmc-hs400-1_8v;
+ cdns,phy-dll-delay-sdclk = <0>;
+ };
--
2.34.1
^ permalink raw reply related
* [PATCH 0/2] CQE support for cadence eMMC host controller
From: rohan1sj via B4 Relay @ 2026-04-07 11:18 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Masahiro Yamada, Adrian Hunter
Cc: linux-mmc, devicetree, linux-kernel, Milind Parab,
Swapnil Jakhade, Manikandan Pillai, rohan1sj
Add support for Command Queuing Engine(CQE) feature. Supported in
cadence controller but driver lacks the support for it
Signed-off-by: rohan1sj <rohan1sj@cadence.com>
---
rohan1sj (2):
mmc: cqe: Add CQE DT support for cadence controller
mmc: cqe: Add CQE support for cadence mmc driver
.../devicetree/bindings/mmc/cdns,sdhci.yaml | 32 +++++-
drivers/mmc/host/sdhci-cadence.c | 118 ++++++++++++++++++++-
2 files changed, 146 insertions(+), 4 deletions(-)
---
base-commit: 05f7e89ab9731565d8a62e3b5d1ec206485eeb0b
change-id: 20260406-cdns_sdhci_cqe-support-41327016d9df
Best regards,
--
rohan1sj <rohan1sj@cadence.com>
^ permalink raw reply
* RE: [PATCH 0/3] Add support for Renesas CAN-FD Bus-Off recovery mode selection
From: Biju Das @ 2026-04-07 11:12 UTC (permalink / raw)
To: Marc Kleine-Budde, biju.das.au
Cc: Vincent Mailhol, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, magnus.damm, Fabrizio Castro,
linux-can@vger.kernel.org, devicetree@vger.kernel.org,
linux-renesas-soc@vger.kernel.org, linux-kernel@vger.kernel.org,
Prabhakar Mahadev Lad
In-Reply-To: <20260403-camouflaged-original-tortoise-ec0f7b-mkl@pengutronix.de>
Hi Marc Kleine-Budde,
Thanks for the feedback.
> -----Original Message-----
> From: Marc Kleine-Budde <mkl@pengutronix.de>
> Sent: 03 April 2026 22:45
> Subject: Re: [PATCH 0/3] Add support for Renesas CAN-FD Bus-Off recovery mode selection
>
> On 03.04.2026 10:49:57, Biju wrote:
> > From: Biju Das <biju.das.jz@bp.renesas.com>
> >
> > The CAN-FD IP supports the below Bus-Off recovery modes:
> > 1) ISO11898-1 compliant
> > 2) Entry to Channel Halt mode automatically at bus-off entry
> > 3) Entry to Channel Halt mode automatically at bus-off end
> > 4) Entry to Channel Halt mode (in bus-off state) by program request
> >
> > Add support for Bus-Off recovery mode selection via the
> > renesas,bus-off-recovery-mode device tree property. If the property is
> > absent, it defaults to RCANFD_CCTR_BOM_BENTRY (entry to Channel Halt
> > mode automatically at bus-off entry) for backward compatibility.
>
> Using DT properties for configuration is not the best way to go.
From a product perspective, how can we satisfy the below requirements,
given that this is to be done statically?
Some customers want Bus-Off recovery to be compliant with ISO 11898-1,
compared to the existing behavior of switching to halt mode automatically
after entering the bus-off state.
In Channel Halt mode, all channel CAN communication is suspended, but all
status and flag registers remain unchanged during Channel Halt mode entry.
>
> Can you explain a bit more what the controller does in the different modes?
● CFDCnCTR.BOM[1:0] = 00b:
Bus-Off recovery is compliant to ISO 11898-1, namely the CAN channel re-enters
CAN communication (error activestate) after 11 consecutive recessive bits are
detected 128 times. TEC and REC counters are initialized to 0. The Bus-
Off Recovery Flag CFDCnERFL.BORF is set in this case.
● CFDCnCTR.BOM[1:0] = 01b: Existing case
The CAN channel changes the value of the CFDCnCTR.CHMDC[1:0] bits within the
CAN Channel Control Register to 10b and switches immediately to Channel Halt
mode automatically after entering bus-off state. TEC and REC counters are
initialized to 0 and the Bus-Off Recovery Flag CFDCnERFL.BORF is not set
in this case.
● CFDCnCTR.BOM[1:0] = 10b:
The CAN channel changes the value of the CFDCnCTR.CHMDC[1:0] bits within the
CAN Channel Control Register to 10b as soon as it reaches bus-off state and
enters Channel Halt mode automatically after the CAN channel has completed
the bus-off recovery sequence (after 11 consecutive recessive bits are
detected 128 times). TEC and REC counters are initialized to 0 and the Bus-Off
Recovery Flag CFDCnERFL.BORF is set in this case.
● CFDCnCTR.BOM[1:0] = 11b:
Bus-off recovery is initiated but CAN channel can immediately enter Channel
Halt mode when still in bus-off state if a request is made to enter Channel
Halt mode. TEC and REC counters are initialized to 0 and the Bus-Off Recovery
Flag CFDCnERFL.BORF is not set. Without setting CFDCnCTR.CHMDC[1:0] = 10b and
when 11 recessive bits is detected 128 times continuously, transition
conditions become the same as CFDCnCTR.BOM[1:0] = 00b.
>
> In the current driver when the bus off IRQ (RCANFD_CERFL_BOEF) fires, the driver calls can_bus_off(),
> which triggers the configured bus off handling.
Agreed.
>
> What the Linux driver should do is once the HW is in bus off mode, switch off the HW and let
> the .do_set_mode(CAN_MODE_START) callback restart the hardware.
We do have .do_set_mode, which restarts the hardware if restart_ms is set.
BOM case 00b:
After entering the bus-off state, when 11 successive recessive bits are detected 128 times, and
if we start the transmission, it enters the transmit state.
BOM cases {01b, 10b}: It automatically enters halt mode.
BOM case 11b:
The CAN channel transitions to Channel Halt mode as soon as Channel Halt mode is requested by
the CPU (without waiting for the completion of the bus-off recovery).
If the CPU does not set Channel Halt mode, then it behaves the same as BOM case 00b.
Cheers,
Biju
^ permalink raw reply
* [PATCH net-next v4 1/2] dt-bindings: net: ti: k3-am654-cpsw-nuss: Add ti,j722s-cpsw-nuss compatible
From: Nora Schiffer @ 2026-04-07 10:48 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: Nishanth Menon, Vignesh Raghavendra, Tero Kristo,
Siddharth Vadapalli, Roger Quadros, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-arm-kernel, linux, Nora Schiffer
The J722S CPSW3G is mostly identical to the AM64's, but additionally
supports SGMII. The AM64 compatible ti,am642-cpsw-nuss is used as a
fallback.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
---
v2: keep ti,am642-cpsw-nuss as a fallback
v3: resubmission for net-next, no changes
v4: remove redundant items: level
.../bindings/net/ti,k3-am654-cpsw-nuss.yaml | 19 ++++++++++++-------
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml b/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml
index a959c1d7e643a..c409c6310ed40 100644
--- a/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml
+++ b/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml
@@ -53,13 +53,18 @@ properties:
"#size-cells": true
compatible:
- enum:
- - ti,am642-cpsw-nuss
- - ti,am654-cpsw-nuss
- - ti,j7200-cpswxg-nuss
- - ti,j721e-cpsw-nuss
- - ti,j721e-cpswxg-nuss
- - ti,j784s4-cpswxg-nuss
+ oneOf:
+ - enum:
+ - ti,am642-cpsw-nuss
+ - ti,am654-cpsw-nuss
+ - ti,j7200-cpswxg-nuss
+ - ti,j721e-cpsw-nuss
+ - ti,j721e-cpswxg-nuss
+ - ti,j784s4-cpswxg-nuss
+ - items:
+ - enum:
+ - ti,j722s-cpsw-nuss
+ - const: ti,am642-cpsw-nuss
reg:
maxItems: 1
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox