[PATCH 11/11] net: dwc_eth_qos: Add support of STM32MP13xx platform

[Marek Vasut]

From: Christophe Roullier 

Add compatible "st,stm32mp13-dwmac" to manage STM32MP13 boards.

Signed-off-by: Christophe Roullier 
Signed-off-by: Marek Vasut  # Rebase, reshuffle, squash code
---
Cc: Christophe Roullier 
Cc: Joe Hershberger 
Cc: Patrice Chotard 
Cc: Patrick Delaunay 
Cc: Ramon Fried 
Cc: u-b...@dh-electronics.com
Cc: uboot-st...@st-md-mailman.stormreply.com
---
 drivers/net/dwc_eth_qos.c   |  4 
 drivers/net/dwc_eth_qos.h   |  1 +
 drivers/net/dwc_eth_qos_stm32.c | 11 +++
 3 files changed, 16 insertions(+)

diff --git a/drivers/net/dwc_eth_qos.c b/drivers/net/dwc_eth_qos.c
index 203bfc0848c..e02317905e5 100644
--- a/drivers/net/dwc_eth_qos.c
+++ b/drivers/net/dwc_eth_qos.c
@@ -1505,6 +1505,10 @@ static const struct udevice_id eqos_ids[] = {
},
 #endif
 #if IS_ENABLED(CONFIG_DWC_ETH_QOS_STM32)
+   {
+   .compatible = "st,stm32mp13-dwmac",
+   .data = (ulong)_stm32mp13_config
+   },
{
.compatible = "st,stm32mp1-dwmac",
.data = (ulong)_stm32mp15_config
diff --git a/drivers/net/dwc_eth_qos.h b/drivers/net/dwc_eth_qos.h
index bafd0d339fb..8b3d0d464d3 100644
--- a/drivers/net/dwc_eth_qos.h
+++ b/drivers/net/dwc_eth_qos.h
@@ -290,5 +290,6 @@ int eqos_null_ops(struct udevice *dev);
 extern struct eqos_config eqos_imx_config;
 extern struct eqos_config eqos_rockchip_config;
 extern struct eqos_config eqos_qcom_config;
+extern struct eqos_config eqos_stm32mp13_config;
 extern struct eqos_config eqos_stm32mp15_config;
 extern struct eqos_config eqos_jh7110_config;
diff --git a/drivers/net/dwc_eth_qos_stm32.c b/drivers/net/dwc_eth_qos_stm32.c
index 00bf6d45568..e167a7ba901 100644
--- a/drivers/net/dwc_eth_qos_stm32.c
+++ b/drivers/net/dwc_eth_qos_stm32.c
@@ -314,6 +314,17 @@ static struct eqos_ops eqos_stm32_ops = {
.eqos_get_tick_clk_rate = eqos_get_tick_clk_rate_stm32
 };
 
+struct eqos_config __maybe_unused eqos_stm32mp13_config = {
+   .reg_access_always_ok = false,
+   .mdio_wait = 1,
+   .swr_wait = 50,
+   .config_mac = EQOS_MAC_RXQ_CTRL0_RXQ0EN_ENABLED_DCB,
+   .config_mac_mdio = EQOS_MAC_MDIO_ADDRESS_CR_250_300,
+   .axi_bus_width = EQOS_AXI_WIDTH_32,
+   .interface = dev_read_phy_mode,
+   .ops = _stm32_ops
+};
+
 struct eqos_config __maybe_unused eqos_stm32mp15_config = {
.reg_access_always_ok = false,
.mdio_wait = 1,
-- 
2.43.0

[PATCH 10/11] net: dwc_eth_qos: Add DT parsing for STM32MP13xx platform

[Marek Vasut]

From: Christophe Roullier 

Manage 2 ethernet instances, select which instance to configure with mask
If mask is not present in DT, it is stm32mp15 platform.

Signed-off-by: Christophe Roullier 
Signed-off-by: Marek Vasut  # Rework the code
---
Cc: Christophe Roullier 
Cc: Joe Hershberger 
Cc: Patrice Chotard 
Cc: Patrick Delaunay 
Cc: Ramon Fried 
Cc: u-b...@dh-electronics.com
Cc: uboot-st...@st-md-mailman.stormreply.com
---
 drivers/net/dwc_eth_qos_stm32.c | 82 ++---
 1 file changed, 66 insertions(+), 16 deletions(-)

diff --git a/drivers/net/dwc_eth_qos_stm32.c b/drivers/net/dwc_eth_qos_stm32.c
index 4db18130765..00bf6d45568 100644
--- a/drivers/net/dwc_eth_qos_stm32.c
+++ b/drivers/net/dwc_eth_qos_stm32.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -33,11 +34,16 @@
 
 /* SYSCFG registers */
 #define SYSCFG_PMCSETR 0x04
-#define SYSCFG_PMCCLRR 0x44
+#define SYSCFG_PMCCLRR_MP130x08
+#define SYSCFG_PMCCLRR_MP150x44
+
+#define SYSCFG_PMCSETR_ETH1_MASK   GENMASK(23, 16)
+#define SYSCFG_PMCSETR_ETH2_MASK   GENMASK(31, 24)
 
 #define SYSCFG_PMCSETR_ETH_CLK_SEL BIT(16)
 #define SYSCFG_PMCSETR_ETH_REF_CLK_SEL BIT(17)
 
+/* STM32MP15xx specific bit */
 #define SYSCFG_PMCSETR_ETH_SELMII  BIT(20)
 
 #define SYSCFG_PMCSETR_ETH_SEL_MASKGENMASK(23, 21)
@@ -45,6 +51,11 @@
 #define SYSCFG_PMCSETR_ETH_SEL_RGMII   0x1
 #define SYSCFG_PMCSETR_ETH_SEL_RMII0x4
 
+/* CLOCK feed to PHY */
+#define ETH_CK_F_25M   2500
+#define ETH_CK_F_50M   5000
+#define ETH_CK_F_125M  12500
+
 static ulong eqos_get_tick_clk_rate_stm32(struct udevice *dev)
 {
struct eqos_priv __maybe_unused *eqos = dev_get_priv(dev);
@@ -130,34 +141,65 @@ static int eqos_probe_syscfg_stm32(struct udevice *dev,
 {
/* Ethernet 50MHz RMII clock selection */
const bool eth_ref_clk_sel = dev_read_bool(dev, "st,eth-ref-clk-sel");
+   /* SoC is STM32MP13xx with two ethernet MACs */
+   const bool is_mp13 = device_is_compatible(dev, "st,stm32mp13-dwmac");
/* Gigabit Ethernet 125MHz clock selection. */
const bool eth_clk_sel = dev_read_bool(dev, "st,eth-clk-sel");
-   u8 *syscfg;
+   /* Ethernet PHY have no crystal */
+   const bool ext_phyclk = dev_read_bool(dev, "st,ext-phyclk");
+   struct eqos_priv *eqos = dev_get_priv(dev);
+   struct regmap *regmap;
+   u32 regmap_mask;
+   ulong rate = 0;
u32 value;
 
-   syscfg = (u8 *)syscon_get_first_range(STM32MP_SYSCON_SYSCFG);
-   if (!syscfg)
-   return -ENODEV;
+   regmap = syscon_regmap_lookup_by_phandle(dev, "st,syscon");
+   if (IS_ERR(regmap))
+   return PTR_ERR(regmap);
+
+   regmap_mask = dev_read_u32_index_default(dev, "st,syscon", 2,
+SYSCFG_PMCSETR_ETH1_MASK);
+
+   if (clk_valid(>clk_ck))
+   rate = clk_get_rate(>clk_ck);
 
switch (interface_type) {
case PHY_INTERFACE_MODE_MII:
dev_dbg(dev, "PHY_INTERFACE_MODE_MII\n");
value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK,
   SYSCFG_PMCSETR_ETH_SEL_GMII_MII);
-   value |= SYSCFG_PMCSETR_ETH_REF_CLK_SEL;
+   /*
+* STM32MP15xx supports both MII and GMII, STM32MP13xx MII only.
+* SYSCFG_PMCSETR ETH_SELMII is present only on STM32MP15xx and
+* acts as a selector between 0:GMII and 1:MII. As STM32MP13xx
+* supports only MII, ETH_SELMII is not present.
+*/
+   if (!is_mp13)   /* Select MII mode on STM32MP15xx */
+   value |= SYSCFG_PMCSETR_ETH_SELMII;
break;
-   case PHY_INTERFACE_MODE_GMII:
+   case PHY_INTERFACE_MODE_GMII:   /* STM32MP15xx only */
dev_dbg(dev, "PHY_INTERFACE_MODE_GMII\n");
value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK,
   SYSCFG_PMCSETR_ETH_SEL_GMII_MII);
-   if (eth_clk_sel)
+   /*
+* If eth_clk_sel is set, use internal ETH_CLKx clock from RCC,
+* otherwise use external clock from IO pin (requires matching
+* GPIO block AF setting of that pin).
+*/
+   if (rate == ETH_CK_F_25M && (eth_clk_sel || ext_phyclk))
value |= SYSCFG_PMCSETR_ETH_CLK_SEL;
break;
case PHY_INTERFACE_MODE_RMII:
dev_dbg(dev, "PHY_INTERFACE_MODE_RMII\n");
value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK,
   SYSCFG_PMCSETR_ETH_SEL_RMII);
-   if (eth_ref_clk_sel)
+   /*
+* If eth_ref_clk_sel is set, use internal clock from RCC,
+* otherwise use external clock from 

[PATCH 09/11] net: dwc_eth_qos: Request clk-ck earlier in probe on STM32

[Marek Vasut]

From: Patrick Delaunay 

Request the clk-ck earlier in probe in preparation for obtaining
the clock rate from these clk-ck in eqos_probe_syscfg_stm32() in
the follow up patch.

Signed-off-by: Patrick Delaunay 
---
Cc: Christophe Roullier 
Cc: Joe Hershberger 
Cc: Patrice Chotard 
Cc: Patrick Delaunay 
Cc: Ramon Fried 
Cc: u-b...@dh-electronics.com
Cc: uboot-st...@st-md-mailman.stormreply.com
---
 drivers/net/dwc_eth_qos_stm32.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/net/dwc_eth_qos_stm32.c b/drivers/net/dwc_eth_qos_stm32.c
index 33477925ff1..4db18130765 100644
--- a/drivers/net/dwc_eth_qos_stm32.c
+++ b/drivers/net/dwc_eth_qos_stm32.c
@@ -201,6 +201,11 @@ static int eqos_probe_resources_stm32(struct udevice *dev)
return -EINVAL;
}
 
+   /* Get ETH_CLK clocks (optional) */
+   ret = clk_get_by_name(dev, "eth-ck", >clk_ck);
+   if (ret)
+   dev_dbg(dev, "No phy clock provided %d", ret);
+
ret = eqos_probe_syscfg_stm32(dev, interface);
if (ret)
return -EINVAL;
@@ -223,11 +228,6 @@ static int eqos_probe_resources_stm32(struct udevice *dev)
goto err_probe;
}
 
-   /*  Get ETH_CLK clocks (optional) */
-   ret = clk_get_by_name(dev, "eth-ck", >clk_ck);
-   if (ret)
-   dev_warn(dev, "No phy clock provided %d\n", ret);
-
dev_dbg(dev, "%s: OK\n", __func__);
 
return 0;
-- 
2.43.0

[PATCH 08/11] net: dwc_eth_qos: Constify st, eth-* values parsed out of DT

[Marek Vasut]

Use const bool for the values parsed out of DT. Drop the duplicate
assignment of false into those bool variables, assign them directly
with the content parsed out of DT. Abbreviate the variable name too.

Signed-off-by: Marek Vasut 
---
Cc: Christophe Roullier 
Cc: Joe Hershberger 
Cc: Patrice Chotard 
Cc: Patrick Delaunay 
Cc: Ramon Fried 
Cc: u-b...@dh-electronics.com
Cc: uboot-st...@st-md-mailman.stormreply.com
---
 drivers/net/dwc_eth_qos_stm32.c | 18 +++---
 1 file changed, 7 insertions(+), 11 deletions(-)

diff --git a/drivers/net/dwc_eth_qos_stm32.c b/drivers/net/dwc_eth_qos_stm32.c
index 72f65f80540..33477925ff1 100644
--- a/drivers/net/dwc_eth_qos_stm32.c
+++ b/drivers/net/dwc_eth_qos_stm32.c
@@ -128,17 +128,13 @@ static int eqos_stop_clks_stm32(struct udevice *dev)
 static int eqos_probe_syscfg_stm32(struct udevice *dev,
   phy_interface_t interface_type)
 {
-   bool eth_ref_clk_sel_reg = false;
-   bool eth_clk_sel_reg = false;
+   /* Ethernet 50MHz RMII clock selection */
+   const bool eth_ref_clk_sel = dev_read_bool(dev, "st,eth-ref-clk-sel");
+   /* Gigabit Ethernet 125MHz clock selection. */
+   const bool eth_clk_sel = dev_read_bool(dev, "st,eth-clk-sel");
u8 *syscfg;
u32 value;
 
-   /* Gigabit Ethernet 125MHz clock selection. */
-   eth_clk_sel_reg = dev_read_bool(dev, "st,eth-clk-sel");
-
-   /* Ethernet 50Mhz RMII clock selection */
-   eth_ref_clk_sel_reg = dev_read_bool(dev, "st,eth-ref-clk-sel");
-
syscfg = (u8 *)syscon_get_first_range(STM32MP_SYSCON_SYSCFG);
if (!syscfg)
return -ENODEV;
@@ -154,14 +150,14 @@ static int eqos_probe_syscfg_stm32(struct udevice *dev,
dev_dbg(dev, "PHY_INTERFACE_MODE_GMII\n");
value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK,
   SYSCFG_PMCSETR_ETH_SEL_GMII_MII);
-   if (eth_clk_sel_reg)
+   if (eth_clk_sel)
value |= SYSCFG_PMCSETR_ETH_CLK_SEL;
break;
case PHY_INTERFACE_MODE_RMII:
dev_dbg(dev, "PHY_INTERFACE_MODE_RMII\n");
value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK,
   SYSCFG_PMCSETR_ETH_SEL_RMII);
-   if (eth_ref_clk_sel_reg)
+   if (eth_ref_clk_sel)
value |= SYSCFG_PMCSETR_ETH_REF_CLK_SEL;
break;
case PHY_INTERFACE_MODE_RGMII:
@@ -171,7 +167,7 @@ static int eqos_probe_syscfg_stm32(struct udevice *dev,
dev_dbg(dev, "PHY_INTERFACE_MODE_RGMII\n");
value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK,
   SYSCFG_PMCSETR_ETH_SEL_RGMII);
-   if (eth_clk_sel_reg)
+   if (eth_clk_sel)
value |= SYSCFG_PMCSETR_ETH_CLK_SEL;
break;
default:
-- 
2.43.0

[PATCH 07/11] net: dwc_eth_qos: Use consistent logging prints

[Marek Vasut]

Use dev_*() only to print all the logs from this glue code,
instead of mixing dev_*(), log_*(), pr_*() all in one code.

Signed-off-by: Marek Vasut 
---
Cc: Christophe Roullier 
Cc: Joe Hershberger 
Cc: Patrice Chotard 
Cc: Patrick Delaunay 
Cc: Ramon Fried 
Cc: u-b...@dh-electronics.com
Cc: uboot-st...@st-md-mailman.stormreply.com
---
 drivers/net/dwc_eth_qos_stm32.c | 52 ++---
 1 file changed, 28 insertions(+), 24 deletions(-)

diff --git a/drivers/net/dwc_eth_qos_stm32.c b/drivers/net/dwc_eth_qos_stm32.c
index 38037c47954..72f65f80540 100644
--- a/drivers/net/dwc_eth_qos_stm32.c
+++ b/drivers/net/dwc_eth_qos_stm32.c
@@ -63,36 +63,36 @@ static int eqos_start_clks_stm32(struct udevice *dev)
if (!CONFIG_IS_ENABLED(CLK))
return 0;
 
-   debug("%s(dev=%p):\n", __func__, dev);
+   dev_dbg(dev, "%s:\n", __func__);
 
ret = clk_enable(>clk_master_bus);
if (ret < 0) {
-   pr_err("clk_enable(clk_master_bus) failed: %d", ret);
+   dev_err(dev, "clk_enable(clk_master_bus) failed: %d\n", ret);
goto err;
}
 
ret = clk_enable(>clk_rx);
if (ret < 0) {
-   pr_err("clk_enable(clk_rx) failed: %d", ret);
+   dev_err(dev, "clk_enable(clk_rx) failed: %d\n", ret);
goto err_disable_clk_master_bus;
}
 
ret = clk_enable(>clk_tx);
if (ret < 0) {
-   pr_err("clk_enable(clk_tx) failed: %d", ret);
+   dev_err(dev, "clk_enable(clk_tx) failed: %d\n", ret);
goto err_disable_clk_rx;
}
 
if (clk_valid(>clk_ck) && !eqos->clk_ck_enabled) {
ret = clk_enable(>clk_ck);
if (ret < 0) {
-   pr_err("clk_enable(clk_ck) failed: %d", ret);
+   dev_err(dev, "clk_enable(clk_ck) failed: %d\n", ret);
goto err_disable_clk_tx;
}
eqos->clk_ck_enabled = true;
}
 
-   debug("%s: OK\n", __func__);
+   dev_dbg(dev, "%s: OK\n", __func__);
return 0;
 
 err_disable_clk_tx:
@@ -102,7 +102,8 @@ err_disable_clk_rx:
 err_disable_clk_master_bus:
clk_disable(>clk_master_bus);
 err:
-   debug("%s: FAILED: %d\n", __func__, ret);
+   dev_dbg(dev, "%s: FAILED: %d\n", __func__, ret);
+
return ret;
 }
 
@@ -113,13 +114,14 @@ static int eqos_stop_clks_stm32(struct udevice *dev)
if (!CONFIG_IS_ENABLED(CLK))
return 0;
 
-   debug("%s(dev=%p):\n", __func__, dev);
+   dev_dbg(dev, "%s:\n", __func__);
 
clk_disable(>clk_tx);
clk_disable(>clk_rx);
clk_disable(>clk_master_bus);
 
-   debug("%s: OK\n", __func__);
+   dev_dbg(dev, "%s: OK\n", __func__);
+
return 0;
 }
 
@@ -143,20 +145,20 @@ static int eqos_probe_syscfg_stm32(struct udevice *dev,
 
switch (interface_type) {
case PHY_INTERFACE_MODE_MII:
-   log_debug("PHY_INTERFACE_MODE_MII\n");
+   dev_dbg(dev, "PHY_INTERFACE_MODE_MII\n");
value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK,
   SYSCFG_PMCSETR_ETH_SEL_GMII_MII);
value |= SYSCFG_PMCSETR_ETH_REF_CLK_SEL;
break;
case PHY_INTERFACE_MODE_GMII:
-   log_debug("PHY_INTERFACE_MODE_GMII\n");
+   dev_dbg(dev, "PHY_INTERFACE_MODE_GMII\n");
value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK,
   SYSCFG_PMCSETR_ETH_SEL_GMII_MII);
if (eth_clk_sel_reg)
value |= SYSCFG_PMCSETR_ETH_CLK_SEL;
break;
case PHY_INTERFACE_MODE_RMII:
-   log_debug("PHY_INTERFACE_MODE_RMII\n");
+   dev_dbg(dev, "PHY_INTERFACE_MODE_RMII\n");
value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK,
   SYSCFG_PMCSETR_ETH_SEL_RMII);
if (eth_ref_clk_sel_reg)
@@ -166,15 +168,15 @@ static int eqos_probe_syscfg_stm32(struct udevice *dev,
case PHY_INTERFACE_MODE_RGMII_ID:
case PHY_INTERFACE_MODE_RGMII_RXID:
case PHY_INTERFACE_MODE_RGMII_TXID:
-   log_debug("PHY_INTERFACE_MODE_RGMII\n");
+   dev_dbg(dev, "PHY_INTERFACE_MODE_RGMII\n");
value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK,
   SYSCFG_PMCSETR_ETH_SEL_RGMII);
if (eth_clk_sel_reg)
value |= SYSCFG_PMCSETR_ETH_CLK_SEL;
break;
default:
-   log_debug("Do not manage %d interface\n",
- interface_type);
+   dev_dbg(dev, "Do not manage %d interface\n",
+   interface_type);
/* Do not manage others interfaces */
return -EINVAL;
}
@@ -194,12 +196,12 @@ static int 

[PATCH 06/11] net: dwc_eth_qos: Move log_debug statements on top of case block

[Marek Vasut]

Move the log_debug() calls on top of the bit manipulation code.
No functional change.

Signed-off-by: Marek Vasut 
---
Cc: Christophe Roullier 
Cc: Joe Hershberger 
Cc: Patrice Chotard 
Cc: Patrick Delaunay 
Cc: Ramon Fried 
Cc: u-b...@dh-electronics.com
Cc: uboot-st...@st-md-mailman.stormreply.com
---
 drivers/net/dwc_eth_qos_stm32.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/dwc_eth_qos_stm32.c b/drivers/net/dwc_eth_qos_stm32.c
index 7545026b158..38037c47954 100644
--- a/drivers/net/dwc_eth_qos_stm32.c
+++ b/drivers/net/dwc_eth_qos_stm32.c
@@ -143,34 +143,34 @@ static int eqos_probe_syscfg_stm32(struct udevice *dev,
 
switch (interface_type) {
case PHY_INTERFACE_MODE_MII:
+   log_debug("PHY_INTERFACE_MODE_MII\n");
value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK,
   SYSCFG_PMCSETR_ETH_SEL_GMII_MII);
value |= SYSCFG_PMCSETR_ETH_REF_CLK_SEL;
-   log_debug("PHY_INTERFACE_MODE_MII\n");
break;
case PHY_INTERFACE_MODE_GMII:
+   log_debug("PHY_INTERFACE_MODE_GMII\n");
value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK,
   SYSCFG_PMCSETR_ETH_SEL_GMII_MII);
if (eth_clk_sel_reg)
value |= SYSCFG_PMCSETR_ETH_CLK_SEL;
-   log_debug("PHY_INTERFACE_MODE_GMII\n");
break;
case PHY_INTERFACE_MODE_RMII:
+   log_debug("PHY_INTERFACE_MODE_RMII\n");
value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK,
   SYSCFG_PMCSETR_ETH_SEL_RMII);
if (eth_ref_clk_sel_reg)
value |= SYSCFG_PMCSETR_ETH_REF_CLK_SEL;
-   log_debug("PHY_INTERFACE_MODE_RMII\n");
break;
case PHY_INTERFACE_MODE_RGMII:
case PHY_INTERFACE_MODE_RGMII_ID:
case PHY_INTERFACE_MODE_RGMII_RXID:
case PHY_INTERFACE_MODE_RGMII_TXID:
+   log_debug("PHY_INTERFACE_MODE_RGMII\n");
value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK,
   SYSCFG_PMCSETR_ETH_SEL_RGMII);
if (eth_clk_sel_reg)
value |= SYSCFG_PMCSETR_ETH_CLK_SEL;
-   log_debug("PHY_INTERFACE_MODE_RGMII\n");
break;
default:
log_debug("Do not manage %d interface\n",
-- 
2.43.0

[PATCH 05/11] net: dwc_eth_qos: Use FIELD_PREP for ETH_SEL bitfield

[Marek Vasut]

Use FIELD_PREP to configure content of ETH_SEL bitfield in SYSCFG_PMCSETR
register. No functional change.

Signed-off-by: Marek Vasut 
---
Cc: Christophe Roullier 
Cc: Joe Hershberger 
Cc: Patrice Chotard 
Cc: Patrick Delaunay 
Cc: Ramon Fried 
Cc: u-b...@dh-electronics.com
Cc: uboot-st...@st-md-mailman.stormreply.com
---
 drivers/net/dwc_eth_qos_stm32.c | 33 -
 1 file changed, 16 insertions(+), 17 deletions(-)

diff --git a/drivers/net/dwc_eth_qos_stm32.c b/drivers/net/dwc_eth_qos_stm32.c
index d7ec0c9be36..7545026b158 100644
--- a/drivers/net/dwc_eth_qos_stm32.c
+++ b/drivers/net/dwc_eth_qos_stm32.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "dwc_eth_qos.h"
@@ -40,9 +41,9 @@
 #define SYSCFG_PMCSETR_ETH_SELMII  BIT(20)
 
 #define SYSCFG_PMCSETR_ETH_SEL_MASKGENMASK(23, 21)
-#define SYSCFG_PMCSETR_ETH_SEL_GMII_MII0
-#define SYSCFG_PMCSETR_ETH_SEL_RGMII   BIT(21)
-#define SYSCFG_PMCSETR_ETH_SEL_RMIIBIT(23)
+#define SYSCFG_PMCSETR_ETH_SEL_GMII_MII0x0
+#define SYSCFG_PMCSETR_ETH_SEL_RGMII   0x1
+#define SYSCFG_PMCSETR_ETH_SEL_RMII0x4
 
 static ulong eqos_get_tick_clk_rate_stm32(struct udevice *dev)
 {
@@ -142,35 +143,33 @@ static int eqos_probe_syscfg_stm32(struct udevice *dev,
 
switch (interface_type) {
case PHY_INTERFACE_MODE_MII:
-   value = SYSCFG_PMCSETR_ETH_SEL_GMII_MII |
-   SYSCFG_PMCSETR_ETH_REF_CLK_SEL;
+   value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK,
+  SYSCFG_PMCSETR_ETH_SEL_GMII_MII);
+   value |= SYSCFG_PMCSETR_ETH_REF_CLK_SEL;
log_debug("PHY_INTERFACE_MODE_MII\n");
break;
case PHY_INTERFACE_MODE_GMII:
+   value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK,
+  SYSCFG_PMCSETR_ETH_SEL_GMII_MII);
if (eth_clk_sel_reg)
-   value = SYSCFG_PMCSETR_ETH_SEL_GMII_MII |
-   SYSCFG_PMCSETR_ETH_CLK_SEL;
-   else
-   value = SYSCFG_PMCSETR_ETH_SEL_GMII_MII;
+   value |= SYSCFG_PMCSETR_ETH_CLK_SEL;
log_debug("PHY_INTERFACE_MODE_GMII\n");
break;
case PHY_INTERFACE_MODE_RMII:
+   value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK,
+  SYSCFG_PMCSETR_ETH_SEL_RMII);
if (eth_ref_clk_sel_reg)
-   value = SYSCFG_PMCSETR_ETH_SEL_RMII |
-   SYSCFG_PMCSETR_ETH_REF_CLK_SEL;
-   else
-   value = SYSCFG_PMCSETR_ETH_SEL_RMII;
+   value |= SYSCFG_PMCSETR_ETH_REF_CLK_SEL;
log_debug("PHY_INTERFACE_MODE_RMII\n");
break;
case PHY_INTERFACE_MODE_RGMII:
case PHY_INTERFACE_MODE_RGMII_ID:
case PHY_INTERFACE_MODE_RGMII_RXID:
case PHY_INTERFACE_MODE_RGMII_TXID:
+   value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK,
+  SYSCFG_PMCSETR_ETH_SEL_RGMII);
if (eth_clk_sel_reg)
-   value = SYSCFG_PMCSETR_ETH_SEL_RGMII |
-   SYSCFG_PMCSETR_ETH_CLK_SEL;
-   else
-   value = SYSCFG_PMCSETR_ETH_SEL_RGMII;
+   value |= SYSCFG_PMCSETR_ETH_CLK_SEL;
log_debug("PHY_INTERFACE_MODE_RGMII\n");
break;
default:
-- 
2.43.0

[PATCH 04/11] net: dwc_eth_qos: Scrub ifdeffery

[Marek Vasut]

Replace ifdef CONFIG_CLK with if (CONFIG_IS_ENABLED(CLK)) to improve code
build coverage. Some of the functions printed debug("%s: OK\n", __func__);
on exit with and without CLK enabled, some did not, make it consistent and
print nothing if CLK is disabled.

Signed-off-by: Marek Vasut 
---
Cc: Christophe Roullier 
Cc: Joe Hershberger 
Cc: Patrice Chotard 
Cc: Patrick Delaunay 
Cc: Ramon Fried 
Cc: u-b...@dh-electronics.com
Cc: uboot-st...@st-md-mailman.stormreply.com
---
 drivers/net/dwc_eth_qos_stm32.c | 25 -
 1 file changed, 12 insertions(+), 13 deletions(-)

diff --git a/drivers/net/dwc_eth_qos_stm32.c b/drivers/net/dwc_eth_qos_stm32.c
index 7520a136ed0..d7ec0c9be36 100644
--- a/drivers/net/dwc_eth_qos_stm32.c
+++ b/drivers/net/dwc_eth_qos_stm32.c
@@ -46,21 +46,22 @@
 
 static ulong eqos_get_tick_clk_rate_stm32(struct udevice *dev)
 {
-#ifdef CONFIG_CLK
-   struct eqos_priv *eqos = dev_get_priv(dev);
+   struct eqos_priv __maybe_unused *eqos = dev_get_priv(dev);
+
+   if (!CONFIG_IS_ENABLED(CLK))
+   return 0;
 
return clk_get_rate(>clk_master_bus);
-#else
-   return 0;
-#endif
 }
 
 static int eqos_start_clks_stm32(struct udevice *dev)
 {
-#ifdef CONFIG_CLK
-   struct eqos_priv *eqos = dev_get_priv(dev);
+   struct eqos_priv __maybe_unused *eqos = dev_get_priv(dev);
int ret;
 
+   if (!CONFIG_IS_ENABLED(CLK))
+   return 0;
+
debug("%s(dev=%p):\n", __func__, dev);
 
ret = clk_enable(>clk_master_bus);
@@ -89,12 +90,10 @@ static int eqos_start_clks_stm32(struct udevice *dev)
}
eqos->clk_ck_enabled = true;
}
-#endif
 
debug("%s: OK\n", __func__);
return 0;
 
-#ifdef CONFIG_CLK
 err_disable_clk_tx:
clk_disable(>clk_tx);
 err_disable_clk_rx:
@@ -104,20 +103,20 @@ err_disable_clk_master_bus:
 err:
debug("%s: FAILED: %d\n", __func__, ret);
return ret;
-#endif
 }
 
 static int eqos_stop_clks_stm32(struct udevice *dev)
 {
-#ifdef CONFIG_CLK
-   struct eqos_priv *eqos = dev_get_priv(dev);
+   struct eqos_priv __maybe_unused *eqos = dev_get_priv(dev);
+
+   if (!CONFIG_IS_ENABLED(CLK))
+   return 0;
 
debug("%s(dev=%p):\n", __func__, dev);
 
clk_disable(>clk_tx);
clk_disable(>clk_rx);
clk_disable(>clk_master_bus);
-#endif
 
debug("%s: OK\n", __func__);
return 0;
-- 
2.43.0

[PATCH 03/11] net: dwc_eth_qos: Fold board_interface_eth_init into STM32 glue code

[Marek Vasut]

Move board_interface_eth_init() into eqos_probe_syscfg_stm32() in STM32
driver glue code. The eqos_probe_syscfg_stm32() parses STM32 specific DT
properties of this MAC and configures SYSCFG registers accordingly, there
is nothing board specific happening in this function, move it into generic
driver code instead. Drop the now unused duplicates from board files.

Signed-off-by: Marek Vasut 
---
Cc: Christophe Roullier 
Cc: Joe Hershberger 
Cc: Patrice Chotard 
Cc: Patrick Delaunay 
Cc: Ramon Fried 
Cc: u-b...@dh-electronics.com
Cc: uboot-st...@st-md-mailman.stormreply.com
---
 board/dhelectronics/dh_stm32mp1/board.c | 82 ---
 board/st/stm32mp1/stm32mp1.c| 82 ---
 drivers/net/dwc_eth_qos_stm32.c | 86 -
 3 files changed, 84 insertions(+), 166 deletions(-)

diff --git a/board/dhelectronics/dh_stm32mp1/board.c 
b/board/dhelectronics/dh_stm32mp1/board.c
index d1f662d9701..f179c857116 100644
--- a/board/dhelectronics/dh_stm32mp1/board.c
+++ b/board/dhelectronics/dh_stm32mp1/board.c
@@ -48,12 +48,10 @@
 
 /* SYSCFG registers */
 #define SYSCFG_BOOTR   0x00
-#define SYSCFG_PMCSETR 0x04
 #define SYSCFG_IOCTRLSETR  0x18
 #define SYSCFG_ICNR0x1C
 #define SYSCFG_CMPCR   0x20
 #define SYSCFG_CMPENSETR   0x24
-#define SYSCFG_PMCCLRR 0x44
 
 #define SYSCFG_BOOTR_BOOT_MASK GENMASK(2, 0)
 #define SYSCFG_BOOTR_BOOTPD_SHIFT  4
@@ -69,16 +67,6 @@
 
 #define SYSCFG_CMPENSETR_MPU_ENBIT(0)
 
-#define SYSCFG_PMCSETR_ETH_CLK_SEL BIT(16)
-#define SYSCFG_PMCSETR_ETH_REF_CLK_SEL BIT(17)
-
-#define SYSCFG_PMCSETR_ETH_SELMII  BIT(20)
-
-#define SYSCFG_PMCSETR_ETH_SEL_MASKGENMASK(23, 21)
-#define SYSCFG_PMCSETR_ETH_SEL_GMII_MII0
-#define SYSCFG_PMCSETR_ETH_SEL_RGMII   BIT(21)
-#define SYSCFG_PMCSETR_ETH_SEL_RMIIBIT(23)
-
 #define KS_CCR 0x08
 #define KS_CCR_EEPROM  BIT(9)
 #define KS_BE0 BIT(12)
@@ -679,76 +667,6 @@ void board_quiesce_devices(void)
 #endif
 }
 
-/* eth init function : weak called in eqos driver */
-int board_interface_eth_init(struct udevice *dev,
-phy_interface_t interface_type)
-{
-   u8 *syscfg;
-   u32 value;
-   bool eth_clk_sel_reg = false;
-   bool eth_ref_clk_sel_reg = false;
-
-   /* Gigabit Ethernet 125MHz clock selection. */
-   eth_clk_sel_reg = dev_read_bool(dev, "st,eth-clk-sel");
-
-   /* Ethernet 50Mhz RMII clock selection */
-   eth_ref_clk_sel_reg =
-   dev_read_bool(dev, "st,eth-ref-clk-sel");
-
-   syscfg = (u8 *)syscon_get_first_range(STM32MP_SYSCON_SYSCFG);
-
-   if (!syscfg)
-   return -ENODEV;
-
-   switch (interface_type) {
-   case PHY_INTERFACE_MODE_MII:
-   value = SYSCFG_PMCSETR_ETH_SEL_GMII_MII |
-   SYSCFG_PMCSETR_ETH_REF_CLK_SEL;
-   debug("%s: PHY_INTERFACE_MODE_MII\n", __func__);
-   break;
-   case PHY_INTERFACE_MODE_GMII:
-   if (eth_clk_sel_reg)
-   value = SYSCFG_PMCSETR_ETH_SEL_GMII_MII |
-   SYSCFG_PMCSETR_ETH_CLK_SEL;
-   else
-   value = SYSCFG_PMCSETR_ETH_SEL_GMII_MII;
-   debug("%s: PHY_INTERFACE_MODE_GMII\n", __func__);
-   break;
-   case PHY_INTERFACE_MODE_RMII:
-   if (eth_ref_clk_sel_reg)
-   value = SYSCFG_PMCSETR_ETH_SEL_RMII |
-   SYSCFG_PMCSETR_ETH_REF_CLK_SEL;
-   else
-   value = SYSCFG_PMCSETR_ETH_SEL_RMII;
-   debug("%s: PHY_INTERFACE_MODE_RMII\n", __func__);
-   break;
-   case PHY_INTERFACE_MODE_RGMII:
-   case PHY_INTERFACE_MODE_RGMII_ID:
-   case PHY_INTERFACE_MODE_RGMII_RXID:
-   case PHY_INTERFACE_MODE_RGMII_TXID:
-   if (eth_clk_sel_reg)
-   value = SYSCFG_PMCSETR_ETH_SEL_RGMII |
-   SYSCFG_PMCSETR_ETH_CLK_SEL;
-   else
-   value = SYSCFG_PMCSETR_ETH_SEL_RGMII;
-   debug("%s: PHY_INTERFACE_MODE_RGMII\n", __func__);
-   break;
-   default:
-   debug("%s: Do not manage %d interface\n",
- __func__, interface_type);
-   /* Do not manage others interfaces */
-   return -EINVAL;
-   }
-
-   /* clear and set ETH configuration bits */
-   writel(SYSCFG_PMCSETR_ETH_SEL_MASK | SYSCFG_PMCSETR_ETH_SELMII |
-  SYSCFG_PMCSETR_ETH_REF_CLK_SEL | SYSCFG_PMCSETR_ETH_CLK_SEL,
-  syscfg + SYSCFG_PMCCLRR);
-   writel(value, syscfg + SYSCFG_PMCSETR);
-
-   return 0;
-}
-
 #if defined(CONFIG_OF_BOARD_SETUP)
 int ft_board_setup(void *blob, struct bd_info *bd)
 {
diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c
index 

[PATCH 02/11] net: dwc_eth_qos: Rename eqos_stm32_config to eqos_stm32mp15_config

[Marek Vasut]

The current glue code is specific to STM32MP15xx, the upcoming STM32MP13xx
will introduce another entry specific to the STM32MP13xx. Rename the current
entry to eqos_stm32mp15_config in preparation for STM32MP13xx addition. No
functional change.

Signed-off-by: Marek Vasut 
---
Cc: Christophe Roullier 
Cc: Joe Hershberger 
Cc: Patrice Chotard 
Cc: Patrick Delaunay 
Cc: Ramon Fried 
Cc: u-b...@dh-electronics.com
Cc: uboot-st...@st-md-mailman.stormreply.com
---
 drivers/net/dwc_eth_qos.c   | 2 +-
 drivers/net/dwc_eth_qos.h   | 2 +-
 drivers/net/dwc_eth_qos_stm32.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/dwc_eth_qos.c b/drivers/net/dwc_eth_qos.c
index 533c2bf070b..203bfc0848c 100644
--- a/drivers/net/dwc_eth_qos.c
+++ b/drivers/net/dwc_eth_qos.c
@@ -1507,7 +1507,7 @@ static const struct udevice_id eqos_ids[] = {
 #if IS_ENABLED(CONFIG_DWC_ETH_QOS_STM32)
{
.compatible = "st,stm32mp1-dwmac",
-   .data = (ulong)_stm32_config
+   .data = (ulong)_stm32mp15_config
},
 #endif
 #if IS_ENABLED(CONFIG_DWC_ETH_QOS_IMX)
diff --git a/drivers/net/dwc_eth_qos.h b/drivers/net/dwc_eth_qos.h
index a6087f191ab..bafd0d339fb 100644
--- a/drivers/net/dwc_eth_qos.h
+++ b/drivers/net/dwc_eth_qos.h
@@ -290,5 +290,5 @@ int eqos_null_ops(struct udevice *dev);
 extern struct eqos_config eqos_imx_config;
 extern struct eqos_config eqos_rockchip_config;
 extern struct eqos_config eqos_qcom_config;
-extern struct eqos_config eqos_stm32_config;
+extern struct eqos_config eqos_stm32mp15_config;
 extern struct eqos_config eqos_jh7110_config;
diff --git a/drivers/net/dwc_eth_qos_stm32.c b/drivers/net/dwc_eth_qos_stm32.c
index cfda757133e..fd29a604987 100644
--- a/drivers/net/dwc_eth_qos_stm32.c
+++ b/drivers/net/dwc_eth_qos_stm32.c
@@ -184,7 +184,7 @@ static struct eqos_ops eqos_stm32_ops = {
.eqos_get_tick_clk_rate = eqos_get_tick_clk_rate_stm32
 };
 
-struct eqos_config __maybe_unused eqos_stm32_config = {
+struct eqos_config __maybe_unused eqos_stm32mp15_config = {
.reg_access_always_ok = false,
.mdio_wait = 1,
.swr_wait = 50,
-- 
2.43.0

[PATCH 01/11] net: dwc_eth_qos: Split STM32 glue into separate file

[Marek Vasut]

Move STM32 glue code into separate file to contain the STM32 specific
code outside of the DWMAC core code. No functional change.

Signed-off-by: Marek Vasut 
---
Cc: Christophe Roullier 
Cc: Joe Hershberger 
Cc: Patrice Chotard 
Cc: Patrick Delaunay 
Cc: Ramon Fried 
Cc: u-b...@dh-electronics.com
Cc: uboot-st...@st-md-mailman.stormreply.com
---
 drivers/net/Makefile|   1 +
 drivers/net/dwc_eth_qos.c   | 165 ---
 drivers/net/dwc_eth_qos.h   |   1 +
 drivers/net/dwc_eth_qos_stm32.c | 196 
 4 files changed, 198 insertions(+), 165 deletions(-)
 create mode 100644 drivers/net/dwc_eth_qos_stm32.c

diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 6677366ebd6..dc3404519d6 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_DWC_ETH_QOS_IMX) += dwc_eth_qos_imx.o
 obj-$(CONFIG_DWC_ETH_QOS_ROCKCHIP) += dwc_eth_qos_rockchip.o
 obj-$(CONFIG_DWC_ETH_QOS_QCOM) += dwc_eth_qos_qcom.o
 obj-$(CONFIG_DWC_ETH_QOS_STARFIVE) += dwc_eth_qos_starfive.o
+obj-$(CONFIG_DWC_ETH_QOS_STM32) += dwc_eth_qos_stm32.o
 obj-$(CONFIG_E1000) += e1000.o
 obj-$(CONFIG_E1000_SPI) += e1000_spi.o
 obj-$(CONFIG_EEPRO100) += eepro100.o
diff --git a/drivers/net/dwc_eth_qos.c b/drivers/net/dwc_eth_qos.c
index 9b3bce1dc87..533c2bf070b 100644
--- a/drivers/net/dwc_eth_qos.c
+++ b/drivers/net/dwc_eth_qos.c
@@ -295,58 +295,6 @@ err:
 #endif
 }
 
-static int eqos_start_clks_stm32(struct udevice *dev)
-{
-#ifdef CONFIG_CLK
-   struct eqos_priv *eqos = dev_get_priv(dev);
-   int ret;
-
-   debug("%s(dev=%p):\n", __func__, dev);
-
-   ret = clk_enable(>clk_master_bus);
-   if (ret < 0) {
-   pr_err("clk_enable(clk_master_bus) failed: %d", ret);
-   goto err;
-   }
-
-   ret = clk_enable(>clk_rx);
-   if (ret < 0) {
-   pr_err("clk_enable(clk_rx) failed: %d", ret);
-   goto err_disable_clk_master_bus;
-   }
-
-   ret = clk_enable(>clk_tx);
-   if (ret < 0) {
-   pr_err("clk_enable(clk_tx) failed: %d", ret);
-   goto err_disable_clk_rx;
-   }
-
-   if (clk_valid(>clk_ck) && !eqos->clk_ck_enabled) {
-   ret = clk_enable(>clk_ck);
-   if (ret < 0) {
-   pr_err("clk_enable(clk_ck) failed: %d", ret);
-   goto err_disable_clk_tx;
-   }
-   eqos->clk_ck_enabled = true;
-   }
-#endif
-
-   debug("%s: OK\n", __func__);
-   return 0;
-
-#ifdef CONFIG_CLK
-err_disable_clk_tx:
-   clk_disable(>clk_tx);
-err_disable_clk_rx:
-   clk_disable(>clk_rx);
-err_disable_clk_master_bus:
-   clk_disable(>clk_master_bus);
-err:
-   debug("%s: FAILED: %d\n", __func__, ret);
-   return ret;
-#endif
-}
-
 static int eqos_stop_clks_tegra186(struct udevice *dev)
 {
 #ifdef CONFIG_CLK
@@ -365,22 +313,6 @@ static int eqos_stop_clks_tegra186(struct udevice *dev)
return 0;
 }
 
-static int eqos_stop_clks_stm32(struct udevice *dev)
-{
-#ifdef CONFIG_CLK
-   struct eqos_priv *eqos = dev_get_priv(dev);
-
-   debug("%s(dev=%p):\n", __func__, dev);
-
-   clk_disable(>clk_tx);
-   clk_disable(>clk_rx);
-   clk_disable(>clk_master_bus);
-#endif
-
-   debug("%s: OK\n", __func__);
-   return 0;
-}
-
 static int eqos_start_resets_tegra186(struct udevice *dev)
 {
struct eqos_priv *eqos = dev_get_priv(dev);
@@ -493,17 +425,6 @@ static ulong eqos_get_tick_clk_rate_tegra186(struct 
udevice *dev)
 #endif
 }
 
-static ulong eqos_get_tick_clk_rate_stm32(struct udevice *dev)
-{
-#ifdef CONFIG_CLK
-   struct eqos_priv *eqos = dev_get_priv(dev);
-
-   return clk_get_rate(>clk_master_bus);
-#else
-   return 0;
-#endif
-}
-
 static int eqos_set_full_duplex(struct udevice *dev)
 {
struct eqos_priv *eqos = dev_get_priv(dev);
@@ -1415,57 +1336,6 @@ err_free_reset_eqos:
return ret;
 }
 
-static int eqos_probe_resources_stm32(struct udevice *dev)
-{
-   struct eqos_priv *eqos = dev_get_priv(dev);
-   int ret;
-   phy_interface_t interface;
-
-   debug("%s(dev=%p):\n", __func__, dev);
-
-   interface = eqos->config->interface(dev);
-
-   if (interface == PHY_INTERFACE_MODE_NA) {
-   pr_err("Invalid PHY interface\n");
-   return -EINVAL;
-   }
-
-   ret = board_interface_eth_init(dev, interface);
-   if (ret)
-   return -EINVAL;
-
-   ret = clk_get_by_name(dev, "stmmaceth", >clk_master_bus);
-   if (ret) {
-   pr_err("clk_get_by_name(master_bus) failed: %d", ret);
-   goto err_probe;
-   }
-
-   ret = clk_get_by_name(dev, "mac-clk-rx", >clk_rx);
-   if (ret) {
-   pr_err("clk_get_by_name(rx) failed: %d", ret);
-   goto err_probe;
-   }
-
-   ret = clk_get_by_name(dev, "mac-clk-tx", >clk_tx);
-   if (ret) {
-   

[PATCH 00/11] net: dwc_eth_qos: Clean up STM32 glue code and add STM32MP13xx support

[Marek Vasut]

Split off STM32 glue code from the DWMAC driver into separate
file, similar to what other SoCs already do, to avoid mixing
the ST specifics with generic DWMAC core code.

Clean the STM32 DWMAC board code which is currently duplicated
in multiple board files, move it into the newly separated glue
code, since the code is not board specific, it is only generic
DT parsing and generic register programming.

Add STM32MP13xx support based on ST downstream patches on top,
although that part is mostly rewritten from scratch.

Christophe Roullier (2):
  net: dwc_eth_qos: Add DT parsing for STM32MP13xx platform
  net: dwc_eth_qos: Add support of STM32MP13xx platform

Marek Vasut (8):
  net: dwc_eth_qos: Split STM32 glue into separate file
  net: dwc_eth_qos: Rename eqos_stm32_config to eqos_stm32mp15_config
  net: dwc_eth_qos: Fold board_interface_eth_init into STM32 glue code
  net: dwc_eth_qos: Scrub ifdeffery
  net: dwc_eth_qos: Use FIELD_PREP for ETH_SEL bitfield
  net: dwc_eth_qos: Move log_debug statements on top of case block
  net: dwc_eth_qos: Use consistent logging prints
  net: dwc_eth_qos: Constify st,eth-* values parsed out of DT

Patrick Delaunay (1):
  net: dwc_eth_qos: Request clk-ck earlier in probe on STM32

 board/dhelectronics/dh_stm32mp1/board.c |  82 --
 board/st/stm32mp1/stm32mp1.c|  82 --
 drivers/net/Makefile|   1 +
 drivers/net/dwc_eth_qos.c   | 171 +---
 drivers/net/dwc_eth_qos.h   |   2 +
 drivers/net/dwc_eth_qos_stm32.c | 337 
 6 files changed, 345 insertions(+), 330 deletions(-)
 create mode 100644 drivers/net/dwc_eth_qos_stm32.c

Cc: Christophe Roullier 
Cc: Joe Hershberger 
Cc: Patrice Chotard 
Cc: Patrick Delaunay 
Cc: Ramon Fried 
Cc: u-b...@dh-electronics.com
Cc: uboot-st...@st-md-mailman.stormreply.com

-- 
2.43.0

RE: [PATCH 2/2] clk: clk-imx8qm: Add LPUART IPG entries

[Peng Fan]

> Subject: [PATCH 2/2] clk: clk-imx8qm: Add LPUART IPG entries
> 
> Since commit cc7df0b9e8bc ("serial: lpuart: Enable IPG clock") the apalis-
> imx8qm board no longer boots.
> 
> The reason is that the imx8qm clock driver does not handle the LPUART IPG
> clocks inside get_rate(), set_rate() and enable() functions.
> 
> Fix the boot regression by adding the LPUART IPG entries.
> 
> Fixes: cc7df0b9e8bc ("serial: lpuart: Enable IPG clock")
> Reported-by: Marcel Ziswiler 
> Signed-off-by: Fabio Estevam 

Reviewed-by: Peng Fan 
> ---
>  drivers/clk/imx/clk-imx8qm.c | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/imx/clk-imx8qm.c b/drivers/clk/imx/clk-imx8qm.c
> index 6c05d07c340..01e33de9d63 100644
> --- a/drivers/clk/imx/clk-imx8qm.c
> +++ b/drivers/clk/imx/clk-imx8qm.c
> @@ -95,20 +95,23 @@ ulong imx8_clk_get_rate(struct clk *clk)
>   resource = SC_R_SDHC_2;
>   pm_clk = SC_PM_CLK_PER;
>   break;
> - case IMX8QM_UART0_IPG_CLK:
>   case IMX8QM_UART0_CLK:
> + case IMX8QM_UART0_IPG_CLK:
>   resource = SC_R_UART_0;
>   pm_clk = SC_PM_CLK_PER;
>   break;
>   case IMX8QM_UART1_CLK:
> + case IMX8QM_UART1_IPG_CLK:
>   resource = SC_R_UART_1;
>   pm_clk = SC_PM_CLK_PER;
>   break;
>   case IMX8QM_UART2_CLK:
> + case IMX8QM_UART2_IPG_CLK:
>   resource = SC_R_UART_2;
>   pm_clk = SC_PM_CLK_PER;
>   break;
>   case IMX8QM_UART3_CLK:
> + case IMX8QM_UART3_IPG_CLK:
>   resource = SC_R_UART_3;
>   pm_clk = SC_PM_CLK_PER;
>   break;
> @@ -181,18 +184,22 @@ ulong imx8_clk_set_rate(struct clk *clk, unsigned
> long rate)
>   pm_clk = SC_PM_CLK_PER;
>   break;
>   case IMX8QM_UART0_CLK:
> + case IMX8QM_UART0_IPG_CLK:
>   resource = SC_R_UART_0;
>   pm_clk = SC_PM_CLK_PER;
>   break;
>   case IMX8QM_UART1_CLK:
> + case IMX8QM_UART1_IPG_CLK:
>   resource = SC_R_UART_1;
>   pm_clk = SC_PM_CLK_PER;
>   break;
>   case IMX8QM_UART2_CLK:
> + case IMX8QM_UART2_IPG_CLK:
>   resource = SC_R_UART_2;
>   pm_clk = SC_PM_CLK_PER;
>   break;
>   case IMX8QM_UART3_CLK:
> + case IMX8QM_UART3_IPG_CLK:
>   resource = SC_R_UART_3;
>   pm_clk = SC_PM_CLK_PER;
>   break;
> @@ -283,18 +290,22 @@ int __imx8_clk_enable(struct clk *clk, bool enable)
>   pm_clk = SC_PM_CLK_PER;
>   break;
>   case IMX8QM_UART0_CLK:
> + case IMX8QM_UART0_IPG_CLK:
>   resource = SC_R_UART_0;
>   pm_clk = SC_PM_CLK_PER;
>   break;
>   case IMX8QM_UART1_CLK:
> + case IMX8QM_UART1_IPG_CLK:
>   resource = SC_R_UART_1;
>   pm_clk = SC_PM_CLK_PER;
>   break;
>   case IMX8QM_UART2_CLK:
> + case IMX8QM_UART2_IPG_CLK:
>   resource = SC_R_UART_2;
>   pm_clk = SC_PM_CLK_PER;
>   break;
>   case IMX8QM_UART3_CLK:
> + case IMX8QM_UART3_IPG_CLK:
>   resource = SC_R_UART_3;
>   pm_clk = SC_PM_CLK_PER;
>   break;
> --
> 2.34.1

RE: [PATCH 1/2] clk: clk-imx8qxp: Add LPUART IPG entries

[Peng Fan]

> Subject: [PATCH 1/2] clk: clk-imx8qxp: Add LPUART IPG entries
> 
> Since commit cc7df0b9e8bc ("serial: lpuart: Enable IPG clock") the colibri-
> imx8qxp board no longer boots.
> 
> The reason is that the imx8qxp clock driver does not handle the LPUART IPG
> clocks inside get_rate(), set_rate() and enable() functions.
> 
> Fix the boot regression by adding the LPUART IPG entries.
> 
> Fixes: cc7df0b9e8bc ("serial: lpuart: Enable IPG clock")
> Reported-by: Marcel Ziswiler 
> Signed-off-by: Fabio Estevam 

Reviewed-by: Peng Fan 
> ---
>  drivers/clk/imx/clk-imx8qxp.c | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/imx/clk-imx8qxp.c b/drivers/clk/imx/clk-imx8qxp.c
> index 8bf7e325481..d900d4cd528 100644
> --- a/drivers/clk/imx/clk-imx8qxp.c
> +++ b/drivers/clk/imx/clk-imx8qxp.c
> @@ -88,20 +88,23 @@ ulong imx8_clk_get_rate(struct clk *clk)
>   resource = SC_R_SDHC_1;
>   pm_clk = SC_PM_CLK_PER;
>   break;
> - case IMX8QXP_UART0_IPG_CLK:
>   case IMX8QXP_UART0_CLK:
> + case IMX8QXP_UART0_IPG_CLK:
>   resource = SC_R_UART_0;
>   pm_clk = SC_PM_CLK_PER;
>   break;
>   case IMX8QXP_UART1_CLK:
> + case IMX8QXP_UART1_IPG_CLK:
>   resource = SC_R_UART_1;
>   pm_clk = SC_PM_CLK_PER;
>   break;
>   case IMX8QXP_UART2_CLK:
> + case IMX8QXP_UART2_IPG_CLK:
>   resource = SC_R_UART_2;
>   pm_clk = SC_PM_CLK_PER;
>   break;
>   case IMX8QXP_UART3_CLK:
> + case IMX8QXP_UART3_IPG_CLK:
>   resource = SC_R_UART_3;
>   pm_clk = SC_PM_CLK_PER;
>   break;
> @@ -170,18 +173,22 @@ ulong imx8_clk_set_rate(struct clk *clk, unsigned
> long rate)
>   pm_clk = SC_PM_CLK_PER;
>   break;
>   case IMX8QXP_UART0_CLK:
> + case IMX8QXP_UART0_IPG_CLK:
>   resource = SC_R_UART_0;
>   pm_clk = SC_PM_CLK_PER;
>   break;
>   case IMX8QXP_UART1_CLK:
> + case IMX8QXP_UART1_IPG_CLK:
>   resource = SC_R_UART_1;
>   pm_clk = SC_PM_CLK_PER;
>   break;
>   case IMX8QXP_UART2_CLK:
> + case IMX8QXP_UART2_IPG_CLK:
>   resource = SC_R_UART_2;
>   pm_clk = SC_PM_CLK_PER;
>   break;
>   case IMX8QXP_UART3_CLK:
> + case IMX8QXP_UART3_IPG_CLK:
>   resource = SC_R_UART_3;
>   pm_clk = SC_PM_CLK_PER;
>   break;
> @@ -263,18 +270,22 @@ int __imx8_clk_enable(struct clk *clk, bool enable)
>   pm_clk = SC_PM_CLK_PER;
>   break;
>   case IMX8QXP_UART0_CLK:
> + case IMX8QXP_UART0_IPG_CLK:
>   resource = SC_R_UART_0;
>   pm_clk = SC_PM_CLK_PER;
>   break;
>   case IMX8QXP_UART1_CLK:
> + case IMX8QXP_UART1_IPG_CLK:
>   resource = SC_R_UART_1;
>   pm_clk = SC_PM_CLK_PER;
>   break;
>   case IMX8QXP_UART2_CLK:
> + case IMX8QXP_UART2_IPG_CLK:
>   resource = SC_R_UART_2;
>   pm_clk = SC_PM_CLK_PER;
>   break;
>   case IMX8QXP_UART3_CLK:
> + case IMX8QXP_UART3_IPG_CLK:
>   resource = SC_R_UART_3;
>   pm_clk = SC_PM_CLK_PER;
>   break;
> --
> 2.34.1

Re: [RFC 2/5] riscv: set fdtfile on Milk-V Mars

[Heinrich Schuchardt]

On 3/8/24 23:37, E Shattow wrote:

Sharing the info from Mars CM Lite 4GB:
EEPROM INFO
Vendor : MILK-V
Product full SN: MARC-V10-2340-D004E016-06DF
data version: 0x2
PCB revision: 0xc1
BOM revision: A
Ethernet MAC0 address: 6c:cf:39:00:83:11
Ethernet MAC1 address: 6c:cf:39:00:83:12
EEPROM INFO

I do not like this practice of force setting fdtfile environment 
variable. If I set fdtfile from u-boot prompt and saveenv, I expect that 
my action as the user will persist over a reboot but instead it gets 
ignored and overwritten by this strategy. Is this necessary to happen 
before the boot scripts?


We could check if $fdtfile is already set before the update.

This would require that the default environment does not include it. Cf.

include/configs/starfive-visionfive2.h:51:
"fdtfile=" CONFIG_DEFAULT_FDT_FILE "\0" \

Best regards

Heinrich



On Sun, Mar 3, 2024 at 5:02 AM Heinrich Schuchardt 
> wrote:


Set environment variable fdtfile to the correct value for the Milk-V
Mars
board.

Signed-off-by: Heinrich Schuchardt
mailto:heinrich.schucha...@canonical.com>>
---
  .../visionfive2/starfive_visionfive2.c        | 43 +--
  1 file changed, 30 insertions(+), 13 deletions(-)

diff --git a/board/starfive/visionfive2/starfive_visionfive2.c
b/board/starfive/visionfive2/starfive_visionfive2.c
index 78e118d5a05..9970e309690 100644
--- a/board/starfive/visionfive2/starfive_visionfive2.c
+++ b/board/starfive/visionfive2/starfive_visionfive2.c
@@ -9,6 +9,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -17,6 +18,8 @@
  DECLARE_GLOBAL_DATA_PTR;
  #define JH7110_L2_PREFETCHER_BASE_ADDR         0x203
  #define JH7110_L2_PREFETCHER_HART_OFFSET       0x2000
+#define FDTFILE_MILK_V_MARS \
+       "starfive/jh7110-milkv-mars.dtb"
  #define FDTFILE_VISIONFIVE2_1_2A \
         "starfive/jh7110-starfive-visionfive-2-v1.2a.dtb"
  #define FDTFILE_VISIONFIVE2_1_3B \
@@ -48,20 +51,34 @@ static void set_fdtfile(void)
  {
         u8 version;
         const char *fdtfile;
+       const char *product_id;

-       version = get_pcb_revision_from_eeprom();
-       switch (version) {
-       case 'a':
-       case 'A':
-               fdtfile = FDTFILE_VISIONFIVE2_1_2A;
-               break;
-
-       case 'b':
-       case 'B':
-       default:
-               fdtfile = FDTFILE_VISIONFIVE2_1_3B;
-               break;
-       };
+       product_id = get_product_id_from_eeprom();
+       if (!product_id) {
+               log_err("Can't read EEPROM\n");
+               return;
+       }
+       if (!strncmp(product_id, "MARS", 4)) {
+               fdtfile = FDTFILE_MILK_V_MARS;
+       } else if (!strncmp(product_id, "VF7110", 6)) {
+               version = get_pcb_revision_from_eeprom();
+
+               switch (version) {
+               case 'a':
+               case 'A':
+                       fdtfile = FDTFILE_VISIONFIVE2_1_2A;
+                       break;
+
+               case 'b':
+               case 'B':
+               default:
+                       fdtfile = FDTFILE_VISIONFIVE2_1_3B;
+                       break;
+               }
+       } else {
+               log_err("Unknown product\n");
+               return;
+       }

         env_set("fdtfile", fdtfile);
  }
-- 
2.43.0

Re: [RFC 5/5] doc: describe Milk-V Mars board

[Heinrich Schuchardt]

On 3/8/24 22:48, E Shattow wrote:
Yes this reference to GPIO high/low states is clearer to understand. 
Have you tested the DIP switch functionality to confirm?; It is not 
shown in the MilkV documentation or outdated schematics and I don't have 
a Mars to test. I did find function descriptions from what is likely 
cut-and-paste of VisionFive2 board reference.


Ref: 
https://github.com/milkv-mars/mars-files/blob/main/Mars_hardware_schematics/Mars_V1.11_20230821.pdf  Sheet 7 of 22 JH7110 GPIOs

There is a schematic for SW2 (bootloader button?) that lists an inset table:
* - GPIO_1
   - GPIO_0
   - Boot
* - 0
   - 0
   - Flash
* - 0
   - 1
   - SD
* - 1
   - 0
   - eMMC
* - 1
   - 1
   - UART

That circuit on SW2 appears to pull high both RGPIO_1 and RGPIO_0 with 
transistors. Again, no DIP switch as this is an earlier revision.


Ref: 
https://doc-en.rvspace.org/VisionFive2/Developer_Guide/JH7110_Boot_UG.pdf   page 9 table 1-4:
RGPIO1=0x0 RGPIO0=0x0 Boot Source: Quad SPI NOR flash memory, Read SPL 
from Sector 0.
RGPIO1=0x1 RGPIO0=0x1 Boot Source: UART0, (description of UART Xmodem 
function).


Following in the same document on page 13 figure 2-1 Boot Flow:
JH7110supportsthefollowingbootdevices.
QSPIFlash(ForSPL + OpenSBI + 
U-Boot)+NVMe/SDCard/eMMC(ForKernel+FileSystemandlater)
Note: 
System will detect in sequence whether it can boot from the following 
device sequence: NVMe > SD > eMMC.

For example,if the boot program is found on the SD, eMMC will be ignored.


The GPIOs select from where U-Boot SPL is loaded. Currently U-Boot SPL 
loads main U-Boot from the same device. But you could change it to scan 
multiple devices for main U-Boot.


Once you have successfully loaded main U-Boot, main U-Boot will scan the 
different boot devices. This includes NVME, eMMC, SD, USB, Network.


Currently upstream U-Boot development is moving from hard coded 
sequences in board files to configurable boot sequences.




Again in this document Figure 4-2 on page 17 is a visual listing of the 
DIP switch positions for QSPI, SDIO, eMMC, and UART boot modes, of the 
VisionFive2 board.


These are just the same switches as on the Milk-V.



The only consistent physical interface over VisionFive2, Mars, Star64, 
Mars CM all is RGPIO1=L RGPIO0=L SPI and RGPIO1=H RGPIO1=H UART; either 
by DIP switch or pushbutton attached circuit. So, I question our 
assumptions about what the actual behavior is for RGPIO1=H RGPIO0=L 
pairing and RGPIO1=L RGPIO0=H, and in what circumstance would there be 
followed a device sequence as suggested by the JH7110 reference. Why 
does the StarFive documentation list a JH7110 boot device sequence if 
there is also these H+L or L+H pairings to choose the device?


As said the device sequence including NVMe is not realized by the code 
loading U-Boot SPL. It is realized in main U-Boot.


Best regards

Heinrich



On Thu, Mar 7, 2024 at 6:37 PM Heinrich Schuchardt 
> wrote:


On 3/8/24 00:20, E Shattow wrote:
 >
 > On Sun, Mar 3, 2024 at 5:02 AM Heinrich Schuchardt
 > mailto:heinrich.schucha...@canonical.com>
 > >> wrote:
 > ...
 >
 >     +The board provides the DIP switches MSEL[1:0] to select the boot
 >     device out of
 >     +SPI flash, eMMC, SD-card, UART. To select booting from
SD-card set
 >     the DIP
 >     +switches MSEL[1:0] to 10.
 >
 >
 > This does not match the [Milk-V Mars vendor
 >
documentation](https://milkv.io/docs/mars/getting-started/bootloader

 > >). Maybe you
have
 > a different board revision?

Thank you for reviewing.

My board revision is V1.21 according to the silk screen.

The Milk-V Mars has DIP switches for the boot selection as shown in
https://gist.github.com/xypron/e28f95b1ed6911aeb9699ba63ae1a885


If you look at the photo
https://milkv.io/assets/images/mars-icon-04-e8814f18158a0e9d4387f4fa330693f1.webp 

in the https://milkv.io/mars  page, it also
shows DIP switches (in the
SPI-Flash position) on a rev 1.2 board.

Did you see a board without DIP switches being sold?

The silk screen markings on the board and the switch don't match.
The same confusion exists on the VisionFive2.

So maybe I should better write in a table:

SPI-Flash:
GPIO0=L
GPIO1=L

SD-Card:
GPIO0=H
   

Re: [RFC 2/5] riscv: set fdtfile on Milk-V Mars

[E Shattow]

Sharing the info from Mars CM Lite 4GB:
EEPROM INFO
Vendor : MILK-V
Product full SN: MARC-V10-2340-D004E016-06DF
data version: 0x2
PCB revision: 0xc1
BOM revision: A
Ethernet MAC0 address: 6c:cf:39:00:83:11
Ethernet MAC1 address: 6c:cf:39:00:83:12
EEPROM INFO

I do not like this practice of force setting fdtfile environment variable.
If I set fdtfile from u-boot prompt and saveenv, I expect that my action as
the user will persist over a reboot but instead it gets ignored and
overwritten by this strategy. Is this necessary to happen before the boot
scripts?

On Sun, Mar 3, 2024 at 5:02 AM Heinrich Schuchardt <
heinrich.schucha...@canonical.com> wrote:

> Set environment variable fdtfile to the correct value for the Milk-V Mars
> board.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  .../visionfive2/starfive_visionfive2.c| 43 +--
>  1 file changed, 30 insertions(+), 13 deletions(-)
>
> diff --git a/board/starfive/visionfive2/starfive_visionfive2.c
> b/board/starfive/visionfive2/starfive_visionfive2.c
> index 78e118d5a05..9970e309690 100644
> --- a/board/starfive/visionfive2/starfive_visionfive2.c
> +++ b/board/starfive/visionfive2/starfive_visionfive2.c
> @@ -9,6 +9,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -17,6 +18,8 @@
>  DECLARE_GLOBAL_DATA_PTR;
>  #define JH7110_L2_PREFETCHER_BASE_ADDR 0x203
>  #define JH7110_L2_PREFETCHER_HART_OFFSET   0x2000
> +#define FDTFILE_MILK_V_MARS \
> +   "starfive/jh7110-milkv-mars.dtb"
>  #define FDTFILE_VISIONFIVE2_1_2A \
> "starfive/jh7110-starfive-visionfive-2-v1.2a.dtb"
>  #define FDTFILE_VISIONFIVE2_1_3B \
> @@ -48,20 +51,34 @@ static void set_fdtfile(void)
>  {
> u8 version;
> const char *fdtfile;
> +   const char *product_id;
>
> -   version = get_pcb_revision_from_eeprom();
> -   switch (version) {
> -   case 'a':
> -   case 'A':
> -   fdtfile = FDTFILE_VISIONFIVE2_1_2A;
> -   break;
> -
> -   case 'b':
> -   case 'B':
> -   default:
> -   fdtfile = FDTFILE_VISIONFIVE2_1_3B;
> -   break;
> -   };
> +   product_id = get_product_id_from_eeprom();
> +   if (!product_id) {
> +   log_err("Can't read EEPROM\n");
> +   return;
> +   }
> +   if (!strncmp(product_id, "MARS", 4)) {
> +   fdtfile = FDTFILE_MILK_V_MARS;
> +   } else if (!strncmp(product_id, "VF7110", 6)) {
> +   version = get_pcb_revision_from_eeprom();
> +
> +   switch (version) {
> +   case 'a':
> +   case 'A':
> +   fdtfile = FDTFILE_VISIONFIVE2_1_2A;
> +   break;
> +
> +   case 'b':
> +   case 'B':
> +   default:
> +   fdtfile = FDTFILE_VISIONFIVE2_1_3B;
> +   break;
> +   }
> +   } else {
> +   log_err("Unknown product\n");
> +   return;
> +   }
>
> env_set("fdtfile", fdtfile);
>  }
> --
> 2.43.0
>
>

Re: [PATCH v3 0/2] Fix Android A/B backup

[Sam Protsenko]

On Fri, Mar 8, 2024 at 1:24 PM McAllister, Colin
 wrote:
>
> > Ah, ok, I see you replied to my comment here.
>
> Yes, sorry. Outlook is terrible to send inline responses too. I figured
> just adding responses in the patch contents would be better. Next time I'll 
> submit
> my patch with a different email :)
>
> > So when that config option is not defined at all, the build still
> > works, right?
>
> Yes, the default value for CONFIG_ANDROID_AB_BACKUP_OFFSET is 0x0, which
> would evaluate to a false bool value in the if conditions. I did do some
> testing with the config value not defined for my board and confirmed
> back-up data is not used.
>

Looks good to me, thanks.

> In your other emails you include your reviewed-by tag. For clarity, Am I
> supposed to append my patches and upload a new version? This is my
> first time contributing to u-boot, so I'm still learning the workflow. I
> didn't see anything glancing through the "Sending patches" page in the
> U-Boot documentation.
>

Welcome to the community! And thanks for your patches :) U-Boot
workflow is quite similar to Linux kernel one. It's useful to collect
all tags when sending out your next version. When the maintainer takes
your patch, they usually also apply all R-b tags for the final patch
version, so you only have to worry about that when sending out a new
version. I know that U-Boot contributors are often using `patman' tool
[1] for submitting patches (and corresponding updated versions), and
I'm pretty sure it collects all pending tags automatically for you.
FWIW, I'm not experienced with `patman', as I'm trying to use somehow
unified submitting process for both U-Boot and Linux kernel, and I
know that using `patman' is sometimes discouraged in Linux kernel
community.

[1] https://docs.u-boot.org/en/latest/develop/patman.html

[snip]

Re: [RFC 5/5] doc: describe Milk-V Mars board

[E Shattow]

Yes this reference to GPIO high/low states is clearer to understand. Have
you tested the DIP switch functionality to confirm?; It is not shown in the
MilkV documentation or outdated schematics and I don't have a Mars to test.
I did find function descriptions from what is likely cut-and-paste of
VisionFive2 board reference.

Ref:
https://github.com/milkv-mars/mars-files/blob/main/Mars_hardware_schematics/Mars_V1.11_20230821.pdf
Sheet 7 of 22 JH7110 GPIOs
There is a schematic for SW2 (bootloader button?) that lists an inset table:
* - GPIO_1
  - GPIO_0
  - Boot
* - 0
  - 0
  - Flash
* - 0
  - 1
  - SD
* - 1
  - 0
  - eMMC
* - 1
  - 1
  - UART

That circuit on SW2 appears to pull high both RGPIO_1 and RGPIO_0 with
transistors. Again, no DIP switch as this is an earlier revision.

Ref:
https://doc-en.rvspace.org/VisionFive2/Developer_Guide/JH7110_Boot_UG.pdf
page 9 table 1-4:
RGPIO1=0x0 RGPIO0=0x0 Boot Source: Quad SPI NOR flash memory, Read SPL from
Sector 0.
RGPIO1=0x1 RGPIO0=0x1 Boot Source: UART0, (description of UART Xmodem
function).

Following in the same document on page 13 figure 2-1 Boot Flow:
JH7110 supports the following boot devices.
QSPI Flash (For SPL + OpenSBI + U-Boot) + NVMe/SD Card/eMMC (For Kernel + Fi
le System and later)
Note: System will detect in sequence whether it can boot from the following
device sequence: NVMe > SD > eMMC. For example, if the boot program is found
on the SD, eMMC will be ignored.

Again in this document Figure 4-2 on page 17 is a visual listing of the DIP
switch positions for QSPI, SDIO, eMMC, and UART boot modes, of the
VisionFive2 board.

The only consistent physical interface over VisionFive2, Mars, Star64, Mars
CM all is RGPIO1=L RGPIO0=L SPI and RGPIO1=H RGPIO1=H UART; either by DIP
switch or pushbutton attached circuit. So, I question our assumptions about
what the actual behavior is for RGPIO1=H RGPIO0=L pairing and RGPIO1=L
RGPIO0=H, and in what circumstance would there be followed a device
sequence as suggested by the JH7110 reference. Why does the StarFive
documentation list a JH7110 boot device sequence if there is also these H+L
or L+H pairings to choose the device?

On Thu, Mar 7, 2024 at 6:37 PM Heinrich Schuchardt <
heinrich.schucha...@canonical.com> wrote:

> On 3/8/24 00:20, E Shattow wrote:
> >
> > On Sun, Mar 3, 2024 at 5:02 AM Heinrich Schuchardt
> >  > > wrote:
> > ...
> >
> > +The board provides the DIP switches MSEL[1:0] to select the boot
> > device out of
> > +SPI flash, eMMC, SD-card, UART. To select booting from SD-card set
> > the DIP
> > +switches MSEL[1:0] to 10.
> >
> >
> > This does not match the [Milk-V Mars vendor
> > documentation](https://milkv.io/docs/mars/getting-started/bootloader
> > ). Maybe you
> have
> > a different board revision?
>
> Thank you for reviewing.
>
> My board revision is V1.21 according to the silk screen.
>
> The Milk-V Mars has DIP switches for the boot selection as shown in
> https://gist.github.com/xypron/e28f95b1ed6911aeb9699ba63ae1a885
>
> If you look at the photo
>
> https://milkv.io/assets/images/mars-icon-04-e8814f18158a0e9d4387f4fa330693f1.webp
> in the https://milkv.io/mars page, it also shows DIP switches (in the
> SPI-Flash position) on a rev 1.2 board.
>
> Did you see a board without DIP switches being sold?
>
> The silk screen markings on the board and the switch don't match.
> The same confusion exists on the VisionFive2.
>
> So maybe I should better write in a table:
>
> SPI-Flash:
> GPIO0=L
> GPIO1=L
>
> SD-Card:
> GPIO0=H
> GPIO1=L
>
> eMMC:
> GPIO0=L
> GPIO1=H
>
> UART:
> GPIO0=H
> GPIO1=H
>
> Best regards
>
> Heinrich
>

Re: [PATCH 1/2] arm64: Reduce add_map() complexity

[Fabio Estevam]

Hi Paul and Tom,

On Tue, Feb 14, 2023 at 10:38 AM Ying-Chun Liu (PaulLiu)
 wrote:
>
> From: Marc Zyngier 
>
> In the add_map() function, for each level it populates, it iterates from
> the root of the PT tree, making it ineficient if a mapping needs to occur
> past level 1.
>
> Instead, replace it with a recursive (and much simpler) algorithm
> that keeps the complexity as low as possible. With this, mapping
> 512GB at level 2 goes from several seconds down to not measurable
> on an A55 machine.
>
> We keep the block mappings at level 1 for now though.
>
> Signed-off-by: Marc Zyngier 
> Signed-off-by: Pierre-Clément Tosi 
> [ Paul: pick from the Android tree. Fixup Pierre's commit. Rebase to the
>   upstream ]
> Signed-off-by: Ying-Chun Liu (PaulLiu) 
> Cc: Tom Rini 
> Link: 
> https://android.googlesource.com/platform/external/u-boot/+/96ad729cf4cab53bdff8222bb3eb256f38b5c3a6
> Link: 
> https://android.googlesource.com/platform/external/u-boot/+/6be9330601d81545c7c941e3609f35bf68a09059

I know this is an old thread, but this commit causes the following
boot regression on a colibri-imx8qxp board:

U-Boot 2024.04-rc3-00070-gecc9298a893b (Mar 08 2024 - 17:15:31 -0300)

CPU:   NXP i.MX8QXP RevC A35 at 1200 MHz at 51C

DRAM:  2 GiB
"Error" handler, esr 0xbf00
elr: 80020914 lr : 800209c0 (reloc)
elr: ffec4914 lr : ffec49c0
x0 : 006070800401 x1 : 7000
x2 : 1000 x3 : 0002
x4 : 4000 x5 : 00600401
x6 : 0c00 x7 : fff45140
x8 : 0060 x9 : fff45100
x10: 0a200023 x11: 0002
x12: 0002 x13: 800a10e8
x14:  x15: ffec4cb8
x16: 80056a88 x17: 
x18: fd6c1d70 x19: 0f60
x20:  x21: 00600401
x22: 70a0 x23: 0020
x24: 4c28 x25: 001f
x26: 0003 x27: 70a0
x28: 0002 x29: fd6bbfd0

Code: 1100047a a90573fb aa0103fb 2a0303fc (b5000113)
Resetting CPU ...

resetting ...

Reverting this commit on top of master fixes the boot regression.

Any ideas?

Thanks

[PATCH 2/2] clk: clk-imx8qm: Add LPUART IPG entries

[Fabio Estevam]

Since commit cc7df0b9e8bc ("serial: lpuart: Enable IPG clock") 
the apalis-imx8qm board no longer boots.

The reason is that the imx8qm clock driver does not handle the
LPUART IPG clocks inside get_rate(), set_rate() and enable() functions.

Fix the boot regression by adding the LPUART IPG entries.

Fixes: cc7df0b9e8bc ("serial: lpuart: Enable IPG clock")
Reported-by: Marcel Ziswiler 
Signed-off-by: Fabio Estevam 
---
 drivers/clk/imx/clk-imx8qm.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/imx/clk-imx8qm.c b/drivers/clk/imx/clk-imx8qm.c
index 6c05d07c340..01e33de9d63 100644
--- a/drivers/clk/imx/clk-imx8qm.c
+++ b/drivers/clk/imx/clk-imx8qm.c
@@ -95,20 +95,23 @@ ulong imx8_clk_get_rate(struct clk *clk)
resource = SC_R_SDHC_2;
pm_clk = SC_PM_CLK_PER;
break;
-   case IMX8QM_UART0_IPG_CLK:
case IMX8QM_UART0_CLK:
+   case IMX8QM_UART0_IPG_CLK:
resource = SC_R_UART_0;
pm_clk = SC_PM_CLK_PER;
break;
case IMX8QM_UART1_CLK:
+   case IMX8QM_UART1_IPG_CLK:
resource = SC_R_UART_1;
pm_clk = SC_PM_CLK_PER;
break;
case IMX8QM_UART2_CLK:
+   case IMX8QM_UART2_IPG_CLK:
resource = SC_R_UART_2;
pm_clk = SC_PM_CLK_PER;
break;
case IMX8QM_UART3_CLK:
+   case IMX8QM_UART3_IPG_CLK:
resource = SC_R_UART_3;
pm_clk = SC_PM_CLK_PER;
break;
@@ -181,18 +184,22 @@ ulong imx8_clk_set_rate(struct clk *clk, unsigned long 
rate)
pm_clk = SC_PM_CLK_PER;
break;
case IMX8QM_UART0_CLK:
+   case IMX8QM_UART0_IPG_CLK:
resource = SC_R_UART_0;
pm_clk = SC_PM_CLK_PER;
break;
case IMX8QM_UART1_CLK:
+   case IMX8QM_UART1_IPG_CLK:
resource = SC_R_UART_1;
pm_clk = SC_PM_CLK_PER;
break;
case IMX8QM_UART2_CLK:
+   case IMX8QM_UART2_IPG_CLK:
resource = SC_R_UART_2;
pm_clk = SC_PM_CLK_PER;
break;
case IMX8QM_UART3_CLK:
+   case IMX8QM_UART3_IPG_CLK:
resource = SC_R_UART_3;
pm_clk = SC_PM_CLK_PER;
break;
@@ -283,18 +290,22 @@ int __imx8_clk_enable(struct clk *clk, bool enable)
pm_clk = SC_PM_CLK_PER;
break;
case IMX8QM_UART0_CLK:
+   case IMX8QM_UART0_IPG_CLK:
resource = SC_R_UART_0;
pm_clk = SC_PM_CLK_PER;
break;
case IMX8QM_UART1_CLK:
+   case IMX8QM_UART1_IPG_CLK:
resource = SC_R_UART_1;
pm_clk = SC_PM_CLK_PER;
break;
case IMX8QM_UART2_CLK:
+   case IMX8QM_UART2_IPG_CLK:
resource = SC_R_UART_2;
pm_clk = SC_PM_CLK_PER;
break;
case IMX8QM_UART3_CLK:
+   case IMX8QM_UART3_IPG_CLK:
resource = SC_R_UART_3;
pm_clk = SC_PM_CLK_PER;
break;
-- 
2.34.1

[PATCH 1/2] clk: clk-imx8qxp: Add LPUART IPG entries

[Fabio Estevam]

Since commit cc7df0b9e8bc ("serial: lpuart: Enable IPG clock") 
the colibri-imx8qxp board no longer boots.

The reason is that the imx8qxp clock driver does not handle the
LPUART IPG clocks inside get_rate(), set_rate() and enable() functions.

Fix the boot regression by adding the LPUART IPG entries.

Fixes: cc7df0b9e8bc ("serial: lpuart: Enable IPG clock")
Reported-by: Marcel Ziswiler 
Signed-off-by: Fabio Estevam 
---
 drivers/clk/imx/clk-imx8qxp.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/imx/clk-imx8qxp.c b/drivers/clk/imx/clk-imx8qxp.c
index 8bf7e325481..d900d4cd528 100644
--- a/drivers/clk/imx/clk-imx8qxp.c
+++ b/drivers/clk/imx/clk-imx8qxp.c
@@ -88,20 +88,23 @@ ulong imx8_clk_get_rate(struct clk *clk)
resource = SC_R_SDHC_1;
pm_clk = SC_PM_CLK_PER;
break;
-   case IMX8QXP_UART0_IPG_CLK:
case IMX8QXP_UART0_CLK:
+   case IMX8QXP_UART0_IPG_CLK:
resource = SC_R_UART_0;
pm_clk = SC_PM_CLK_PER;
break;
case IMX8QXP_UART1_CLK:
+   case IMX8QXP_UART1_IPG_CLK:
resource = SC_R_UART_1;
pm_clk = SC_PM_CLK_PER;
break;
case IMX8QXP_UART2_CLK:
+   case IMX8QXP_UART2_IPG_CLK:
resource = SC_R_UART_2;
pm_clk = SC_PM_CLK_PER;
break;
case IMX8QXP_UART3_CLK:
+   case IMX8QXP_UART3_IPG_CLK:
resource = SC_R_UART_3;
pm_clk = SC_PM_CLK_PER;
break;
@@ -170,18 +173,22 @@ ulong imx8_clk_set_rate(struct clk *clk, unsigned long 
rate)
pm_clk = SC_PM_CLK_PER;
break;
case IMX8QXP_UART0_CLK:
+   case IMX8QXP_UART0_IPG_CLK:
resource = SC_R_UART_0;
pm_clk = SC_PM_CLK_PER;
break;
case IMX8QXP_UART1_CLK:
+   case IMX8QXP_UART1_IPG_CLK:
resource = SC_R_UART_1;
pm_clk = SC_PM_CLK_PER;
break;
case IMX8QXP_UART2_CLK:
+   case IMX8QXP_UART2_IPG_CLK:
resource = SC_R_UART_2;
pm_clk = SC_PM_CLK_PER;
break;
case IMX8QXP_UART3_CLK:
+   case IMX8QXP_UART3_IPG_CLK:
resource = SC_R_UART_3;
pm_clk = SC_PM_CLK_PER;
break;
@@ -263,18 +270,22 @@ int __imx8_clk_enable(struct clk *clk, bool enable)
pm_clk = SC_PM_CLK_PER;
break;
case IMX8QXP_UART0_CLK:
+   case IMX8QXP_UART0_IPG_CLK:
resource = SC_R_UART_0;
pm_clk = SC_PM_CLK_PER;
break;
case IMX8QXP_UART1_CLK:
+   case IMX8QXP_UART1_IPG_CLK:
resource = SC_R_UART_1;
pm_clk = SC_PM_CLK_PER;
break;
case IMX8QXP_UART2_CLK:
+   case IMX8QXP_UART2_IPG_CLK:
resource = SC_R_UART_2;
pm_clk = SC_PM_CLK_PER;
break;
case IMX8QXP_UART3_CLK:
+   case IMX8QXP_UART3_IPG_CLK:
resource = SC_R_UART_3;
pm_clk = SC_PM_CLK_PER;
break;
-- 
2.34.1

[PATCH] stv0991: Remove stv0991 board and architecture code

[Tom Rini]

This architecture and related board are unmaintained currently and have
been for a long time. Remove them.

Signed-off-by: Tom Rini 
---
 MAINTAINERS   |   7 -
 arch/arm/Kconfig  |  15 --
 arch/arm/cpu/armv7/Makefile   |   1 -
 arch/arm/cpu/armv7/stv0991/Makefile   |   7 -
 arch/arm/cpu/armv7/stv0991/clock.c|  42 --
 arch/arm/cpu/armv7/stv0991/lowlevel.S |  11 --
 arch/arm/cpu/armv7/stv0991/pinmux.c   |  66 -
 arch/arm/cpu/armv7/stv0991/reset.c|  27 
 arch/arm/cpu/armv7/stv0991/timer.c| 114 ---
 arch/arm/dts/Makefile |   1 -
 arch/arm/dts/stv0991.dts  |  55 
 arch/arm/include/asm/arch-stv0991/gpio.h  |  21 ---
 arch/arm/include/asm/arch-stv0991/hardware.h  |  72 --
 .../include/asm/arch-stv0991/stv0991_cgu.h| 130 --
 .../include/asm/arch-stv0991/stv0991_creg.h   | 103 --
 .../include/asm/arch-stv0991/stv0991_defs.h   |  14 --
 .../include/asm/arch-stv0991/stv0991_gpt.h|  41 --
 .../include/asm/arch-stv0991/stv0991_periph.h |  45 --
 .../include/asm/arch-stv0991/stv0991_wdru.h   |  27 
 board/st/stv0991/Kconfig  |  15 --
 board/st/stv0991/MAINTAINERS  |   6 -
 board/st/stv0991/Makefile |   6 -
 board/st/stv0991/stv0991.c| 119 
 configs/stv0991_defconfig |  44 --
 include/configs/stv0991.h |  25 
 25 files changed, 1014 deletions(-)
 delete mode 100644 arch/arm/cpu/armv7/stv0991/Makefile
 delete mode 100644 arch/arm/cpu/armv7/stv0991/clock.c
 delete mode 100644 arch/arm/cpu/armv7/stv0991/lowlevel.S
 delete mode 100644 arch/arm/cpu/armv7/stv0991/pinmux.c
 delete mode 100644 arch/arm/cpu/armv7/stv0991/reset.c
 delete mode 100644 arch/arm/cpu/armv7/stv0991/timer.c
 delete mode 100644 arch/arm/dts/stv0991.dts
 delete mode 100644 arch/arm/include/asm/arch-stv0991/gpio.h
 delete mode 100644 arch/arm/include/asm/arch-stv0991/hardware.h
 delete mode 100644 arch/arm/include/asm/arch-stv0991/stv0991_cgu.h
 delete mode 100644 arch/arm/include/asm/arch-stv0991/stv0991_creg.h
 delete mode 100644 arch/arm/include/asm/arch-stv0991/stv0991_defs.h
 delete mode 100644 arch/arm/include/asm/arch-stv0991/stv0991_gpt.h
 delete mode 100644 arch/arm/include/asm/arch-stv0991/stv0991_periph.h
 delete mode 100644 arch/arm/include/asm/arch-stv0991/stv0991_wdru.h
 delete mode 100644 board/st/stv0991/Kconfig
 delete mode 100644 board/st/stv0991/MAINTAINERS
 delete mode 100644 board/st/stv0991/Makefile
 delete mode 100644 board/st/stv0991/stv0991.c
 delete mode 100644 configs/stv0991_defconfig
 delete mode 100644 include/configs/stv0991.h

diff --git a/MAINTAINERS b/MAINTAINERS
index fbb82b3df5d4..e90cc094a7f1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -683,13 +683,6 @@ F: tools/stm32image.c
 N: stm
 N: stm32
 
-
-ARM STM STV0991
-M: Vikas Manocha 
-S: Maintained
-F: arch/arm/cpu/armv7/stv0991/
-F: arch/arm/include/asm/arch-stv0991/
-
 ARM SUNXI
 M: Jagan Teki 
 M: Andre Przywara 
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 65fa7ba4ce77..d15ccc7bb284 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -631,20 +631,6 @@ config ARCH_ORION5X
select SPL_SEPARATE_BSS if SPL
select TIMER
 
-config TARGET_STV0991
-   bool "Support stv0991"
-   select CPU_V7A
-   select DM
-   select DM_SERIAL
-   select DM_SPI
-   select DM_SPI_FLASH
-   select GPIO_EXTRA_HEADER
-   select PL01X_SERIAL
-   select MTD
-   select SPI
-   select SPI_FLASH
-   imply CMD_DM
-
 config ARCH_BCM283X
bool "Broadcom BCM283X family"
select DM
@@ -2358,7 +2344,6 @@ source "board/samsung/common/Kconfig"
 source "board/siemens/common/Kconfig"
 source "board/seeed/npi_imx6ull/Kconfig"
 source "board/socionext/developerbox/Kconfig"
-source "board/st/stv0991/Kconfig"
 source "board/tcl/sl50/Kconfig"
 source "board/traverse/ten64/Kconfig"
 source "board/variscite/dart_6ul/Kconfig"
diff --git a/arch/arm/cpu/armv7/Makefile b/arch/arm/cpu/armv7/Makefile
index 653eef8ad79e..99cf9eb515f9 100644
--- a/arch/arm/cpu/armv7/Makefile
+++ b/arch/arm/cpu/armv7/Makefile
@@ -37,7 +37,6 @@ obj-$(if $(filter bcm281xx,$(SOC)),y) += bcm281xx/
 obj-$(if $(filter bcmcygnus,$(SOC)),y) += bcmcygnus/
 obj-$(if $(filter bcmnsp,$(SOC)),y) += bcmnsp/
 obj-$(if $(filter ls102xa,$(SOC)),y) += ls102xa/
-obj-$(if $(filter stv0991,$(SOC)),y) += stv0991/
 obj-$(CONFIG_ARCH_SUNXI) += sunxi/
 obj-$(CONFIG_VF610) += vf610/
 obj-$(CONFIG_ARCH_S5P4418) += s5p4418/
diff --git a/arch/arm/cpu/armv7/stv0991/Makefile 
b/arch/arm/cpu/armv7/stv0991/Makefile
deleted file mode 100644
index 3be5eba4b122..
--- a/arch/arm/cpu/armv7/stv0991/Makefile
+++ /dev/null
@@ -1,7 +0,0 @@
-# 

Re: [PATCH 1/2] opos6uldev: make the LCD work again

[Tom Rini]

On Fri, Mar 08, 2024 at 01:21:15PM +, Conor Dooley wrote:
> On Fri, Mar 01, 2024 at 01:54:13PM -0500, Tom Rini wrote:
> > On Fri, Mar 01, 2024 at 01:32:53PM +, Conor Dooley wrote:
> > > > > > > > > > On Wed, 28 Feb 2024 at 18:40, Tom Rini  
> > > > > > > > > > wrote:
> > > > > > > > > > > I think the commit in question can be
> > > > > > > > > > > summarized as "remove a bunch of explicit HW information 
> > > > > > > > > > > because there's
> > > > > > > > > > > now a Linux Kernel driver that determines that 
> > > > > > > > > > > dynamically". What do we
> > > > > > > > > > > do next? The old information is in a presumably valid 
> > > > > > > > > > > binding still, can
> > > > > > > > > > > we just put it back and comment that consumers outside of 
> > > > > > > > > > > Linux use this
> > > > > > > > > > > still so it's not removed again later? Or am I just 
> > > > > > > > > > > missing where we can
> > > > > > > > > > > instead get this information from the DT still and not 
> > > > > > > > > > > need to come up
> > > > > > > > > > > with a new driver and subsystems?
> > > 
> > > I don't think this is an accurate summary. The "explict hw information"
> > > was never allowed for an imx6ul, only for some older devices, so "the
> > > old information is in a presumably valid binding" is not accurate.
> > > See 7b920aae917d ("dt-bindings: mxsfb: Add new bindings for the MXSFB
> > > driver") for when doing things that way was deprecated. The imx6ul was
> > > only documented several years after it was introduced (so likely several
> > > years after it started incorrectly using that binding).
> > > 
> > > Seeing that, I am not sure that I would even question the kernel patch
> > > cited above, the change was done for binding compliance and I would not
> > > be inclined to think twice, given the bindings are the ABI.
> 
> Reading this back today, it took me second to recall what I meant by
> "question". What I meant was that during a review I would would see a
> patch changing this to comply with the bindings and think nothing of it,
> not that removing it was a unquestionably correct thing to do.
> 
> > So part of the problem I see here is that legacy platforms (which to me
> > is a large chunk of 32bit ARM) are trickier. I'm not asking for anything
> > more to be done in this example to be clear (I think the new panel-dpi
> > binding is what U-Boot needs to implement and solve the issue here).
> > 
> > But I don't think the fact that the old binding was handled
> > suboptimally means that its usage should be ignored.
> 
> What often happens is that Linux retains support for the old way of
> doing things but the dts is updated to the documented way. I'm not
> really sure how to deal with this kind of thing, other than being extra
> diligent about reviewing cleanup work that may impact other users of the
> dts sources and letting the linux platform maintainers know if something
> gets broken in U-Boot.

I think that's perhaps the crux of the issue. Since the kernel is the
definitive source of the dtb files too, cleanups of the sources can
impact other projects (U-Boot, OpenBSD, etc) who might not have been
aware the binding was deprecated/etc.

> > They were added in
> > 2017 which is after they were deprecated and not caught then. I consider
> > that to mean it was still valid.
> 
> I don't agree that that makes it valid, but I can see how it would be
> assumed to be valid by other users of the dts file.

Yes, fair.

> > And I also assume that today we have
> > the tooling to catch that and not let it in, in the first place.
> 
> Unfortunately, not really. The tooling is capable of spotting these
> things, but it totally depends on the effort people have put in to
> that platform as to whether or not the single to noise ratio actually
> allows a maintainer to spot when these things are introduced.
> The RISC-V platforms, Samsung and some others have really good
> compliance, but other platforms like aspeed or at91 have so many
> warnings etc that it is very very difficult for the platform maintainers
> to actually spot things like these being added.

OK.

> > Time will tell now how bumpy a ride things end up being as I do agree
> > that getting all the DTS files following the ABI correctly is an
> > important goal.
> 
> Fixing up a platform is utterly mind-numbing work that requires
> understanding datasheets and bindings for really varied hardware, so
> it's best done by either the platform maintainers or piecemeal by people
> that want to improve one particular board. It's gonna take a long time
> to get "all" files following the ABI, particularly away from the ones
> the linux dt-maintainers take more of an interest in.
> Next time we get a new grad starting I might subject them to some
> cleanup activities, they'll have to learn about dt at some point anyway
> ;)

It's all tricky and complex, yup :(

> Sorta unrelated to the above, but related to the OF_UPSTREAM stuff is
> that I do notice a bit 

Re: [PATCH v3 0/2] Fix Android A/B backup

[McAllister, Colin]

> Ah, ok, I see you replied to my comment here.

Yes, sorry. Outlook is terrible to send inline responses too. I figured
just adding responses in the patch contents would be better. Next time I'll 
submit
my patch with a different email :)

> So when that config option is not defined at all, the build still
> works, right?

Yes, the default value for CONFIG_ANDROID_AB_BACKUP_OFFSET is 0x0, which
would evaluate to a false bool value in the if conditions. I did do some
testing with the config value not defined for my board and confirmed
back-up data is not used.

In your other emails you include your reviewed-by tag. For clarity, Am I
supposed to append my patches and upload a new version? This is my
first time contributing to u-boot, so I'm still learning the workflow. I
didn't see anything glancing through the "Sending patches" page in the
U-Boot documentation.

Best,
Colin


From: Sam Protsenko 
Sent: Friday, March 8, 2024 11:54
To: McAllister, Colin
Cc: u-boot@lists.denx.de; jpewhac...@gmail.com; s...@chromium.org; Mattijs 
Korpershoek; Igor Opaniuk
Subject: Re: [PATCH v3 0/2] Fix Android A/B backup

On Fri, Mar 8, 2024 at 11: 00 AM Colin McAllister  wrote: > > - Addresses compiler error due to missing semicolon > - Removes 
use of preprocessor macros with ANDROID_AB_BACKUP_OFFSET > > Bug


On Fri, Mar 8, 2024 at 11:00 AM Colin McAllister
 wrote:
>
> - Addresses compiler error due to missing semicolon
> - Removes use of preprocessor macros with ANDROID_AB_BACKUP_OFFSET
>
> Bug was found by noticing a semicolon was missing and not causing a
> compiler error when CONFIG_ANDROID_AB_BACKUP_OFFSET was set. I submitted
> a patch to fix the semicolon before fixing the #if's. Testing the latter
> patch without the former with ANDORID_AB_BACKUP_OFFSET set will cause a
> compiler error.
>
> What's changed in V2?
> -
>
> The second verison of changes removes the #if preprocessor macros to use
> C conditionals instead. There was some minor refactoring required to get
> this to work, so I did more thourough testing to ensure the backup data
> works as expected.
>
> I also realized that CONFIG_VAL is not needed because there's no reason
> for the SPL or TPL to have different values for the backup address. I
> opted to just use CONFIG_ANDROID_AB_BACKUP_OFFSET directly.
>
> What's changed in V3?
> -
>
> Added "Fixes:" tag to patches. Performed additonal testing as described
> in the second paragraph in the testing notes below.
>
> I opted to not use CONFIG_IS_ENABLED because that macro appears to only
> be intended for y/n configurations. See note at top of linux/kconfig.h:
>
> "Note that these only work with boolean and tristate options."

Ah, ok, I see you replied to my comment here. So when that config
option is not defined at all, the build still works, right? One way to
test that would be to use buildman tool for all boards. Although I
have to say it might be very time consuming (I usually run it
overnight), so I'm not asking you to do it in this case, it's just
FYI.

>
> How was this patch series tested?
> -
>
> I built for my target with CONFIG_ANDROID_AB_BACKUP_OFFSET set to
> 0x1000. I first verified that the device can normally boot. I then ran
> dd before rebooting to corrupt the primary data. I confirmed that the
> backup was used to properly restore the primary. I then corrupted both
> the primary and backup data and confirmed that the primary and backup
> were both reinitialized to default values. Lastly, I corrupted the
> backup data and not the primary data and confirmed that the backup was
> restored the primary data.
>
> Addtionally, I disabled CONFIG_ANDROID_AB_BACKUP_OFFSET for my device
> and confirmed that after I corrupt the primary data, no backup is used.
> When the primary data is not corrupt, the device boots normally. This is
> what I would expect, because CONFIG_ANDROID_AB_BACKUP_OFFSET's default
> value is 0x0, which would evaluate to false for all C if conditions.
>
> Colin McAllister (2):
>   android_ab: Add missing semicolon
>   android_ab: Fix ANDROID_AB_BACKUP_OFFSET
>
>  boot/android_ab.c | 97 ++-
>  1 file changed, 45 insertions(+), 52 deletions(-)
>
> --
> 2.43.2
>
>
> 
>
> CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use 
> of the intended recipient(s) and contain information that may be Garmin 
> confidential and/or Garmin legally privileged. If you have received this 
> email in error, please notify the sender by reply email and delete the 
> message. Any disclosure, copying, distribution or use of this communication 
> (including attachments) by someone other than the intended recipient is 
> prohibited. Thank you.

Re: [PATCH v2 1/2] arm: socfpga: arria10: add option to reprogram the FPGA every reboot

[Marek Vasut]

On 3/8/24 6:12 PM, Michał Barnaś wrote:

Add Kconfig that enables FPGA reprogramming with warm boot on Arria 10.
This option allows to change the bitstream on the filesystem and apply
changes with warm reboot without the need for a power cycle.

Signed-off-by: Michał Barnaś 
---

Changes in v2:
- Rebase on current master branch

  arch/arm/mach-socfpga/Kconfig   | 8 
  arch/arm/mach-socfpga/spl_a10.c | 8 
  2 files changed, 16 insertions(+)

diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig
index 114d243812..89303f1f16 100644
--- a/arch/arm/mach-socfpga/Kconfig
+++ b/arch/arm/mach-socfpga/Kconfig
@@ -80,6 +80,14 @@ config TARGET_SOCFPGA_ARRIA10
imply FPGA_SOCFPGA
imply SPL_USE_TINY_PRINTF
  
+config TARGET_SOCFPGA_ARRIA10_ALWAYS_REPROGRAM


This is not TARGET (as in SoC), but a regular config option, so please 
drop the TARGET_ prefix .



+   bool "Always reprogram Arria 10 FPGA"
+   depends on TARGET_SOCFPGA_ARRIA10
+   help
+ Arria 10 FPGA is only programmed during the cold boot.
+ This option forces the FPGA to be reprogrammed every reboot,
+ allowing to change the bitstream and apply it with warm reboot.
+
  config TARGET_SOCFPGA_CYCLONE5
bool
select TARGET_SOCFPGA_GEN5
diff --git a/arch/arm/mach-socfpga/spl_a10.c b/arch/arm/mach-socfpga/spl_a10.c
index 9edbbf4a29..d5d3327a42 100644
--- a/arch/arm/mach-socfpga/spl_a10.c
+++ b/arch/arm/mach-socfpga/spl_a10.c
@@ -122,7 +122,11 @@ void spl_board_init(void)
arch_early_init_r();
  
  	/* If the full FPGA is already loaded, ie.from EPCQ, config fpga pins */

+#ifdef CONFIG_TARGET_SOCFPGA_ARRIA10_ALWAYS_REPROGRAM
+   if (is_regular_boot_valid()) {
+#else
if (is_fpgamgr_user_mode()) {
+#endif


Use CONFIG_IS_ENABLED() or IS_ENABLED() macro please .

Re: [PATCH v3 6/6] tee: remove common.h inclusion

[Sam Protsenko]

On Mon, Mar 4, 2024 at 11:46 AM Igor Opaniuk  wrote:
>
> The usage of the common.h include file is deprecated [1], and has already
> been removed from several files.
> Get rid of all inclusions in the "drivers/tee" directory, and replace it
> with required include files directly where needed.
>
> [1] doc/develop/codingstyle.rst
>
> Signed-off-by: Igor Opaniuk 
> ---

Reviewed-by: Sam Protsenko 

>
> Changes in v2:
> - Fixed chimp_optee.c:37:9: error: implicit declaration of function 'memset'
>
>  drivers/tee/broadcom/chimp_optee.c | 3 ++-
>  drivers/tee/optee/core.c   | 1 -
>  drivers/tee/optee/i2c.c| 1 -
>  drivers/tee/optee/rpmb.c   | 1 -
>  drivers/tee/optee/supplicant.c | 2 +-
>  drivers/tee/sandbox.c  | 2 +-
>  drivers/tee/tee-uclass.c   | 1 -
>  7 files changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/tee/broadcom/chimp_optee.c 
> b/drivers/tee/broadcom/chimp_optee.c
> index 37f9b094f76..bd146ef2899 100644
> --- a/drivers/tee/broadcom/chimp_optee.c
> +++ b/drivers/tee/broadcom/chimp_optee.c
> @@ -3,9 +3,10 @@
>   * Copyright 2020 Broadcom.
>   */
>
> -#include 
>  #include 
>  #include 
> +#include 
> +#include 
>
>  #ifdef CONFIG_CHIMP_OPTEE
>
> diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
> index 47f845cffe3..5fc0505c788 100644
> --- a/drivers/tee/optee/core.c
> +++ b/drivers/tee/optee/core.c
> @@ -3,7 +3,6 @@
>   * Copyright (c) 2018-2020 Linaro Limited
>   */
>
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/tee/optee/i2c.c b/drivers/tee/optee/i2c.c
> index ef4e10f9912..e3fb99897c5 100644
> --- a/drivers/tee/optee/i2c.c
> +++ b/drivers/tee/optee/i2c.c
> @@ -3,7 +3,6 @@
>   * Copyright (c) 2020 Foundries.io Ltd
>   */
>
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/tee/optee/rpmb.c b/drivers/tee/optee/rpmb.c
> index 5bc13757ea8..bacced6af6c 100644
> --- a/drivers/tee/optee/rpmb.c
> +++ b/drivers/tee/optee/rpmb.c
> @@ -3,7 +3,6 @@
>   * Copyright (c) 2018 Linaro Limited
>   */
>
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/tee/optee/supplicant.c b/drivers/tee/optee/supplicant.c
> index f9dd874b594..8a426f53ba8 100644
> --- a/drivers/tee/optee/supplicant.c
> +++ b/drivers/tee/optee/supplicant.c
> @@ -3,10 +3,10 @@
>   * Copyright (c) 2018, Linaro Limited
>   */
>
> -#include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>
>  #include "optee_msg.h"
> diff --git a/drivers/tee/sandbox.c b/drivers/tee/sandbox.c
> index ec66401878c..8ad7c09efdd 100644
> --- a/drivers/tee/sandbox.c
> +++ b/drivers/tee/sandbox.c
> @@ -2,7 +2,7 @@
>  /*
>   * Copyright (C) 2018 Linaro Limited
>   */
> -#include 
> +
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/tee/tee-uclass.c b/drivers/tee/tee-uclass.c
> index 52412a4098e..0194d732193 100644
> --- a/drivers/tee/tee-uclass.c
> +++ b/drivers/tee/tee-uclass.c
> @@ -5,7 +5,6 @@
>
>  #define LOG_CATEGORY UCLASS_TEE
>
> -#include 
>  #include 
>  #include 
>  #include 
> --
> 2.34.1
>

Re: [PATCH v3 2/2] android_ab: Fix ANDROID_AB_BACKUP_OFFSET

[Sam Protsenko]

On Fri, Mar 8, 2024 at 11:50 AM Sam Protsenko
 wrote:
>
> On Fri, Mar 8, 2024 at 11:00 AM Colin McAllister
>  wrote:
> >
> > Currently, setting CONFIG_AB_BACKUP_OFFSET in a target's defconfig will
> > not actually enable the #if protected code in android_ab.c. This is
> > because "CONFIG_" should have been prepended to the config macro, or the
> > macros defined in kconfig.h could have been used.
> >
> > The code included by ANDROID_AB_BACKUP_OFFSET has been refactored to no
> > longer be conditionally compiled by preprocessor conditionals and
> > instead use C conditionals. This better aligns with the Linux kernel
> > style guide.
> >
> > Fixes: 3430f24bc6 ("android_ab: Try backup booloader_message")
> > Signed-off-by: Colin McAllister 
> > Cc: Joshua Watt 
> > Cc: Simon Glass 
> > ---
> > v2:
> >   - Replaced #if conditionals with C if conditionals
> >   - Opted to use CONFIG_ANDROID_AB_BACKUP_OFFSET directly instead of
> > macros in kconfig.h as CONFIG_ANDROID_AB_BACKUP_OFFSET is not a
> > boolean or tristate value and doesn't have different values when
> > building SPL or TPL.
> > v3:
> >   - Added "Fixes:" tag
>
> Can you please also address my comment about CONFIG_IS_ENABLED() in
> the previous mail? It might be just an answer if you think there are
> no issues with that, not necessarily v4.
>

Ok, I just saw your reply in patch #0. Given that you tested that this
change doesn't break any other boards/configuration (e.g. when the
mentioned config is not defined), feel free to add:

Reviewed-by: Sam Protsenko 

> [snip]

Re: [PATCH v3 11/20] rockchip: rk3588: fix non-working SD controller if booting from other media

[Quentin Schulz]

Hi Kever,

On 3/8/24 11:05, Kever Yang wrote:

Hi Quentin,

On 2024/2/21 18:37, Quentin Schulz wrote:

From: Quentin Schulz

Rockchip SoCs have some jtag/sdmmc autoswitching that simply doesn't
work really well.[00] The Linux kernel disables it for all SoCs[01], so
U-Boot needs to do the same in order to fix issues related to SD card on
RK3588. This autoswitching is enabled (by default) via the force_jtag
bitfield in SYS_GRF_SOC_CON6 in the TRM part1.

The conditions to enter forced JTAG mode are the following:
- force_jtag is 1
- GPIO4_D2 is muxed for SDMMC function
- GPIO3_D3 is muxed for SDMMC function
- SDMMC_DET is inactive


I have explain the reason and send fix for other boards  in kernel for 
why the force jtag


function not working correctly, see patch [1] and I copy the commit 
message here:


RK3588 has force_jtage feature which is enable JTAG function via sdmmc
pins automatically when there is no SD card insert, this feature will
need the GPIO0A4 works in sdmmc_det function like other mmc signal instead
of GPIO function, or else the force_jtag can not auto be disabled when
SD card insert.

For the rk3588 boards available on mainline kernel, 10 boards enable SD 
card function
and 9 of then use GPIO0A4 as sdmmc_det, they should all able to use the 
force_jtag after

my patch apply.
The jaguar-rk3588 still have the issue because there is no sdmmc_det used.
The condition of force JTAG mode work correctly is :
- force_jtag in grf is 1;
- all the SDMMC signal including SDMMC_DET set as SDMMC function in GRF 
IOC/IOMUX reg;


So please update the commit message and it would be better to move this 
setting in jaguar-rk3588 board


Thanks, it's a tiny bit clearer to me now. We never exit this JTAG mode 
on Jaguar because we have GPIO0A4 floating (with internal pull-down). On 
Tiger (patches coming this month I hope), it's hardwired to ground but 
we use a different GPIO as card detect, so we'll have a similar issue. 
In any case, thanks for the explanation.


Though, I do not understand why you absolutely want this force_jtag to 
be always enabled. It is a debug feature.


Even more so, this is a security issue. I don't think anyone wants to 
have the JTAG enabled if the user plays with the card detect pin or boot 
without an SD card connected. I really insist this should be enabled on 
the SoC level, the same way that the Linux kernel does it.


We could compromise on a Kconfig symbol to enable force_jtag for people 
who want it but still default to disabled on the SoC level, but I'm not 
really seeing a reason for it.


so that other board can enable force_jtag with only modify kernel but 
not both kernel and U-Boot.


If you want JTAG support in U-Boot, you would patch U-Boot. If you want 
JTAG support in the kernel, you would patch the kernel. If you want it 
in both, you'd patch both. I'm not sure to understand what disabling 
force_jtag in U-Boot has to do with force_jtag enabled from the Linux 
kernel, what am I missing here?


Cheers,
Quentin

Re: [PATCH v3 0/2] Fix Android A/B backup

[Sam Protsenko]

On Fri, Mar 8, 2024 at 11:00 AM Colin McAllister
 wrote:
>
> - Addresses compiler error due to missing semicolon
> - Removes use of preprocessor macros with ANDROID_AB_BACKUP_OFFSET
>
> Bug was found by noticing a semicolon was missing and not causing a
> compiler error when CONFIG_ANDROID_AB_BACKUP_OFFSET was set. I submitted
> a patch to fix the semicolon before fixing the #if's. Testing the latter
> patch without the former with ANDORID_AB_BACKUP_OFFSET set will cause a
> compiler error.
>
> What's changed in V2?
> -
>
> The second verison of changes removes the #if preprocessor macros to use
> C conditionals instead. There was some minor refactoring required to get
> this to work, so I did more thourough testing to ensure the backup data
> works as expected.
>
> I also realized that CONFIG_VAL is not needed because there's no reason
> for the SPL or TPL to have different values for the backup address. I
> opted to just use CONFIG_ANDROID_AB_BACKUP_OFFSET directly.
>
> What's changed in V3?
> -
>
> Added "Fixes:" tag to patches. Performed additonal testing as described
> in the second paragraph in the testing notes below.
>
> I opted to not use CONFIG_IS_ENABLED because that macro appears to only
> be intended for y/n configurations. See note at top of linux/kconfig.h:
>
> "Note that these only work with boolean and tristate options."

Ah, ok, I see you replied to my comment here. So when that config
option is not defined at all, the build still works, right? One way to
test that would be to use buildman tool for all boards. Although I
have to say it might be very time consuming (I usually run it
overnight), so I'm not asking you to do it in this case, it's just
FYI.

>
> How was this patch series tested?
> -
>
> I built for my target with CONFIG_ANDROID_AB_BACKUP_OFFSET set to
> 0x1000. I first verified that the device can normally boot. I then ran
> dd before rebooting to corrupt the primary data. I confirmed that the
> backup was used to properly restore the primary. I then corrupted both
> the primary and backup data and confirmed that the primary and backup
> were both reinitialized to default values. Lastly, I corrupted the
> backup data and not the primary data and confirmed that the backup was
> restored the primary data.
>
> Addtionally, I disabled CONFIG_ANDROID_AB_BACKUP_OFFSET for my device
> and confirmed that after I corrupt the primary data, no backup is used.
> When the primary data is not corrupt, the device boots normally. This is
> what I would expect, because CONFIG_ANDROID_AB_BACKUP_OFFSET's default
> value is 0x0, which would evaluate to false for all C if conditions.
>
> Colin McAllister (2):
>   android_ab: Add missing semicolon
>   android_ab: Fix ANDROID_AB_BACKUP_OFFSET
>
>  boot/android_ab.c | 97 ++-
>  1 file changed, 45 insertions(+), 52 deletions(-)
>
> --
> 2.43.2
>
>
> 
>
> CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use 
> of the intended recipient(s) and contain information that may be Garmin 
> confidential and/or Garmin legally privileged. If you have received this 
> email in error, please notify the sender by reply email and delete the 
> message. Any disclosure, copying, distribution or use of this communication 
> (including attachments) by someone other than the intended recipient is 
> prohibited. Thank you.

Re: [PATCH v3 2/2] android_ab: Fix ANDROID_AB_BACKUP_OFFSET

[Sam Protsenko]

On Fri, Mar 8, 2024 at 11:00 AM Colin McAllister
 wrote:
>
> Currently, setting CONFIG_AB_BACKUP_OFFSET in a target's defconfig will
> not actually enable the #if protected code in android_ab.c. This is
> because "CONFIG_" should have been prepended to the config macro, or the
> macros defined in kconfig.h could have been used.
>
> The code included by ANDROID_AB_BACKUP_OFFSET has been refactored to no
> longer be conditionally compiled by preprocessor conditionals and
> instead use C conditionals. This better aligns with the Linux kernel
> style guide.
>
> Fixes: 3430f24bc6 ("android_ab: Try backup booloader_message")
> Signed-off-by: Colin McAllister 
> Cc: Joshua Watt 
> Cc: Simon Glass 
> ---
> v2:
>   - Replaced #if conditionals with C if conditionals
>   - Opted to use CONFIG_ANDROID_AB_BACKUP_OFFSET directly instead of
> macros in kconfig.h as CONFIG_ANDROID_AB_BACKUP_OFFSET is not a
> boolean or tristate value and doesn't have different values when
> building SPL or TPL.
> v3:
>   - Added "Fixes:" tag

Can you please also address my comment about CONFIG_IS_ENABLED() in
the previous mail? It might be just an answer if you think there are
no issues with that, not necessarily v4.

[snip]

Re: [PATCH v3 1/2] android_ab: Add missing semicolon

[Sam Protsenko]

On Fri, Mar 8, 2024 at 11:00 AM Colin McAllister
 wrote:
>
> Found a missing semicolon in code protected by a #if that will never
> evaluate to true due to a separate issue. Fixing this issue before
> addressing the #if.
>
> Fixes: 3430f24bc6 ("android_ab: Try backup booloader_message")
> Signed-off-by: Colin McAllister 
> Cc: Joshua Watt 
> Cc: Simon Glass 
> ---

My R-b tag wasn't added in v3, adding it here so that whoever applies
this patch can add it as well:

Reviewed-by: Sam Protsenko 

> v2: No changes
> v3: Added "Fixes:" tag
>
>  boot/android_ab.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/boot/android_ab.c b/boot/android_ab.c
> index c9df6d2b4b..9a3d15ec60 100644
> --- a/boot/android_ab.c
> +++ b/boot/android_ab.c
> @@ -221,7 +221,7 @@ int ab_select_slot(struct blk_desc *dev_desc, struct 
> disk_partition *part_info,
>  #if ANDROID_AB_BACKUP_OFFSET
> crc32_le = ab_control_compute_crc(backup_abc);
> if (backup_abc->crc32_le != crc32_le) {
> -   log_err("ANDROID: Invalid backup CRC-32 ")
> +   log_err("ANDROID: Invalid backup CRC-32 ");
> log_err("expected %.8x, found %.8x),",
> crc32_le, backup_abc->crc32_le);
>  #endif
> --
> 2.43.2
>
>
> 
>
> CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use 
> of the intended recipient(s) and contain information that may be Garmin 
> confidential and/or Garmin legally privileged. If you have received this 
> email in error, please notify the sender by reply email and delete the 
> message. Any disclosure, copying, distribution or use of this communication 
> (including attachments) by someone other than the intended recipient is 
> prohibited. Thank you.

Re: [PATCH 0/3] Fix driver for misc/atsha204a

[Michał Barnaś]

Thank you very much!

On Tue, Mar 5, 2024 at 2:17 PM Tom Rini  wrote:
>
> On Mon, 19 Feb 2024 16:32:01 +, Michał Barnaś wrote:
>
> > Fix the driver to behave like the chip datasheet requires.
> > Improve wake up function to send low signal on SDA line for at least
> > 60us as chip requires to wake up. Fix sleep function to move the chip
> > into sleep mode, not into idle mode. Remove unnecessary for loop,
> > which would never run for more than one iteration.
> >
> >
> > [...]
>
> Applied to u-boot/next, thanks!
>
> --
> Tom
>
>

[PATCH v2 2/2] chameleonv3: set in defconfig for FPGA to reprogram every reboot

[Michał Barnaś]

Set CONFIG_TARGET_SOCFPGA_ARRIA10_ALWAYS_REPROGRAM as enabled in
chameleon v3 board's defconfig.

Signed-off-by: Michał Barnaś 
---

(no changes since v1)

 configs/socfpga_chameleonv3_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/socfpga_chameleonv3_defconfig 
b/configs/socfpga_chameleonv3_defconfig
index 6ea61ca6ea..25615bb4b4 100644
--- a/configs/socfpga_chameleonv3_defconfig
+++ b/configs/socfpga_chameleonv3_defconfig
@@ -7,6 +7,7 @@ CONFIG_DEFAULT_DEVICE_TREE="socfpga_arria10_chameleonv3_480_2"
 CONFIG_SPL_TEXT_BASE=0xFFE0
 CONFIG_SPL_DRIVERS_MISC=y
 CONFIG_TARGET_SOCFPGA_CHAMELEONV3=y
+CONFIG_TARGET_SOCFPGA_ARRIA10_ALWAYS_REPROGRAM=y
 CONFIG_SPL_FS_FAT=y
 CONFIG_FIT=y
 CONFIG_SPL_FIT=y
-- 
2.44.0.278.ge034bb2e1d-goog

[PATCH v2 1/2] arm: socfpga: arria10: add option to reprogram the FPGA every reboot

[Michał Barnaś]

Add Kconfig that enables FPGA reprogramming with warm boot on Arria 10.
This option allows to change the bitstream on the filesystem and apply
changes with warm reboot without the need for a power cycle.

Signed-off-by: Michał Barnaś 
---

Changes in v2:
- Rebase on current master branch

 arch/arm/mach-socfpga/Kconfig   | 8 
 arch/arm/mach-socfpga/spl_a10.c | 8 
 2 files changed, 16 insertions(+)

diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig
index 114d243812..89303f1f16 100644
--- a/arch/arm/mach-socfpga/Kconfig
+++ b/arch/arm/mach-socfpga/Kconfig
@@ -80,6 +80,14 @@ config TARGET_SOCFPGA_ARRIA10
imply FPGA_SOCFPGA
imply SPL_USE_TINY_PRINTF
 
+config TARGET_SOCFPGA_ARRIA10_ALWAYS_REPROGRAM
+   bool "Always reprogram Arria 10 FPGA"
+   depends on TARGET_SOCFPGA_ARRIA10
+   help
+ Arria 10 FPGA is only programmed during the cold boot.
+ This option forces the FPGA to be reprogrammed every reboot,
+ allowing to change the bitstream and apply it with warm reboot.
+
 config TARGET_SOCFPGA_CYCLONE5
bool
select TARGET_SOCFPGA_GEN5
diff --git a/arch/arm/mach-socfpga/spl_a10.c b/arch/arm/mach-socfpga/spl_a10.c
index 9edbbf4a29..d5d3327a42 100644
--- a/arch/arm/mach-socfpga/spl_a10.c
+++ b/arch/arm/mach-socfpga/spl_a10.c
@@ -122,7 +122,11 @@ void spl_board_init(void)
arch_early_init_r();
 
/* If the full FPGA is already loaded, ie.from EPCQ, config fpga pins */
+#ifdef CONFIG_TARGET_SOCFPGA_ARRIA10_ALWAYS_REPROGRAM
+   if (is_regular_boot_valid()) {
+#else
if (is_fpgamgr_user_mode()) {
+#endif
ret = config_pins(gd->fdt_blob, "shared");
if (ret)
return;
@@ -130,7 +134,11 @@ void spl_board_init(void)
ret = config_pins(gd->fdt_blob, "fpga");
if (ret)
return;
+#ifdef CONFIG_TARGET_SOCFPGA_ARRIA10_ALWAYS_REPROGRAM
+   } else {
+#else
} else if (!is_fpgamgr_early_user_mode()) {
+#endif
/* Program IOSSM(early IO release) or full FPGA */
fpgamgr_program(buf, FPGA_BUFSIZ, 0);
 
-- 
2.44.0.278.ge034bb2e1d-goog

[PATCH v2 0/2] arm: socfpga: arria10: allow to reprogram FPGA with warm reboot

[Michał Barnaś]

By default, the board requires power cycle (cold boot) to program the
FPGA with bitstream. This change adds Kconfig that allows to enable
reprogramming the FPGA with every boot. This makes the update process
of the bitstream on the filesystem to be applied with simple system
reboot.

Changes in v2:
- Rebase on current master branch

Michał Barnaś (2):
  arm: socfpga: arria10: add option to reprogram the FPGA every reboot
  chameleonv3: set in defconfig for FPGA to reprogram every reboot

 arch/arm/mach-socfpga/Kconfig | 8 
 arch/arm/mach-socfpga/spl_a10.c   | 8 
 configs/socfpga_chameleonv3_defconfig | 1 +
 3 files changed, 17 insertions(+)

-- 
2.44.0.278.ge034bb2e1d-goog

[PATCH v3 2/2] android_ab: Fix ANDROID_AB_BACKUP_OFFSET

[Colin McAllister]

Currently, setting CONFIG_AB_BACKUP_OFFSET in a target's defconfig will
not actually enable the #if protected code in android_ab.c. This is
because "CONFIG_" should have been prepended to the config macro, or the
macros defined in kconfig.h could have been used.

The code included by ANDROID_AB_BACKUP_OFFSET has been refactored to no
longer be conditionally compiled by preprocessor conditionals and
instead use C conditionals. This better aligns with the Linux kernel
style guide.

Fixes: 3430f24bc6 ("android_ab: Try backup booloader_message")
Signed-off-by: Colin McAllister 
Cc: Joshua Watt 
Cc: Simon Glass 
---
v2:
  - Replaced #if conditionals with C if conditionals
  - Opted to use CONFIG_ANDROID_AB_BACKUP_OFFSET directly instead of
macros in kconfig.h as CONFIG_ANDROID_AB_BACKUP_OFFSET is not a
boolean or tristate value and doesn't have different values when
building SPL or TPL.
v3:
  - Added "Fixes:" tag

 boot/android_ab.c | 97 ++-
 1 file changed, 45 insertions(+), 52 deletions(-)

diff --git a/boot/android_ab.c b/boot/android_ab.c
index 9a3d15ec60..f547aa64e4 100644
--- a/boot/android_ab.c
+++ b/boot/android_ab.c
@@ -187,13 +187,12 @@ int ab_select_slot(struct blk_desc *dev_desc, struct 
disk_partition *part_info,
   bool dec_tries)
 {
struct bootloader_control *abc = NULL;
+   struct bootloader_control *backup_abc = NULL;
u32 crc32_le;
int slot, i, ret;
bool store_needed = false;
+   bool valid_backup = false;
char slot_suffix[4];
-#if ANDROID_AB_BACKUP_OFFSET
-   struct bootloader_control *backup_abc = NULL;
-#endif

ret = ab_control_create_from_disk(dev_desc, part_info, , 0);
if (ret < 0) {
@@ -205,53 +204,49 @@ int ab_select_slot(struct blk_desc *dev_desc, struct 
disk_partition *part_info,
return ret;
}

-#if ANDROID_AB_BACKUP_OFFSET
-   ret = ab_control_create_from_disk(dev_desc, part_info, _abc,
- ANDROID_AB_BACKUP_OFFSET);
-   if (ret < 0) {
-   free(abc);
-   return ret;
+   if (CONFIG_ANDROID_AB_BACKUP_OFFSET) {
+   ret = ab_control_create_from_disk(dev_desc, part_info, 
_abc,
+ 
CONFIG_ANDROID_AB_BACKUP_OFFSET);
+   if (ret < 0) {
+   free(abc);
+   return ret;
+   }
}
-#endif

crc32_le = ab_control_compute_crc(abc);
if (abc->crc32_le != crc32_le) {
log_err("ANDROID: Invalid CRC-32 (expected %.8x, found %.8x),",
crc32_le, abc->crc32_le);
-#if ANDROID_AB_BACKUP_OFFSET
-   crc32_le = ab_control_compute_crc(backup_abc);
-   if (backup_abc->crc32_le != crc32_le) {
-   log_err("ANDROID: Invalid backup CRC-32 ");
-   log_err("expected %.8x, found %.8x),",
-   crc32_le, backup_abc->crc32_le);
-#endif
-
-   log_err("re-initializing A/B metadata.\n");
+   if (CONFIG_ANDROID_AB_BACKUP_OFFSET) {
+   crc32_le = ab_control_compute_crc(backup_abc);
+   if (backup_abc->crc32_le != crc32_le) {
+   log_err(" ANDROID: Invalid backup CRC-32 ");
+   log_err("(expected %.8x, found %.8x),",
+   crc32_le, backup_abc->crc32_le);
+   } else {
+   valid_backup = true;
+   log_info(" copying A/B metadata from 
backup.\n");
+   memcpy(abc, backup_abc, sizeof(*abc));
+   }
+   }

+   if (!valid_backup) {
+   log_err(" re-initializing A/B metadata.\n");
ret = ab_control_default(abc);
if (ret < 0) {
-#if ANDROID_AB_BACKUP_OFFSET
-   free(backup_abc);
-#endif
+   if (CONFIG_ANDROID_AB_BACKUP_OFFSET)
+   free(backup_abc);
free(abc);
return -ENODATA;
}
-#if ANDROID_AB_BACKUP_OFFSET
-   } else {
-   /*
-* Backup is valid. Copy it to the primary
-*/
-   memcpy(abc, backup_abc, sizeof(*abc));
}
-#endif
store_needed = true;
}

if (abc->magic != BOOT_CTRL_MAGIC) {
log_err("ANDROID: Unknown A/B metadata: %.8x\n", abc->magic);
-#if ANDROID_AB_BACKUP_OFFSET
-   free(backup_abc);
-#endif
+   if (CONFIG_ANDROID_AB_BACKUP_OFFSET)
+   free(backup_abc);
  

[PATCH v3 1/2] android_ab: Add missing semicolon

[Colin McAllister]

Found a missing semicolon in code protected by a #if that will never
evaluate to true due to a separate issue. Fixing this issue before
addressing the #if.

Fixes: 3430f24bc6 ("android_ab: Try backup booloader_message")
Signed-off-by: Colin McAllister 
Cc: Joshua Watt 
Cc: Simon Glass 
---
v2: No changes
v3: Added "Fixes:" tag

 boot/android_ab.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/boot/android_ab.c b/boot/android_ab.c
index c9df6d2b4b..9a3d15ec60 100644
--- a/boot/android_ab.c
+++ b/boot/android_ab.c
@@ -221,7 +221,7 @@ int ab_select_slot(struct blk_desc *dev_desc, struct 
disk_partition *part_info,
 #if ANDROID_AB_BACKUP_OFFSET
crc32_le = ab_control_compute_crc(backup_abc);
if (backup_abc->crc32_le != crc32_le) {
-   log_err("ANDROID: Invalid backup CRC-32 ")
+   log_err("ANDROID: Invalid backup CRC-32 ");
log_err("expected %.8x, found %.8x),",
crc32_le, backup_abc->crc32_le);
 #endif
--
2.43.2




CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of 
the intended recipient(s) and contain information that may be Garmin 
confidential and/or Garmin legally privileged. If you have received this email 
in error, please notify the sender by reply email and delete the message. Any 
disclosure, copying, distribution or use of this communication (including 
attachments) by someone other than the intended recipient is prohibited. Thank 
you.

[PATCH v3 0/2] Fix Android A/B backup

[Colin McAllister]

- Addresses compiler error due to missing semicolon
- Removes use of preprocessor macros with ANDROID_AB_BACKUP_OFFSET

Bug was found by noticing a semicolon was missing and not causing a
compiler error when CONFIG_ANDROID_AB_BACKUP_OFFSET was set. I submitted
a patch to fix the semicolon before fixing the #if's. Testing the latter
patch without the former with ANDORID_AB_BACKUP_OFFSET set will cause a
compiler error.

What's changed in V2?
-

The second verison of changes removes the #if preprocessor macros to use
C conditionals instead. There was some minor refactoring required to get
this to work, so I did more thourough testing to ensure the backup data
works as expected.

I also realized that CONFIG_VAL is not needed because there's no reason
for the SPL or TPL to have different values for the backup address. I
opted to just use CONFIG_ANDROID_AB_BACKUP_OFFSET directly.

What's changed in V3?
-

Added "Fixes:" tag to patches. Performed additonal testing as described
in the second paragraph in the testing notes below.

I opted to not use CONFIG_IS_ENABLED because that macro appears to only
be intended for y/n configurations. See note at top of linux/kconfig.h:

"Note that these only work with boolean and tristate options."

How was this patch series tested?
-

I built for my target with CONFIG_ANDROID_AB_BACKUP_OFFSET set to
0x1000. I first verified that the device can normally boot. I then ran
dd before rebooting to corrupt the primary data. I confirmed that the
backup was used to properly restore the primary. I then corrupted both
the primary and backup data and confirmed that the primary and backup
were both reinitialized to default values. Lastly, I corrupted the
backup data and not the primary data and confirmed that the backup was
restored the primary data.

Addtionally, I disabled CONFIG_ANDROID_AB_BACKUP_OFFSET for my device
and confirmed that after I corrupt the primary data, no backup is used.
When the primary data is not corrupt, the device boots normally. This is
what I would expect, because CONFIG_ANDROID_AB_BACKUP_OFFSET's default
value is 0x0, which would evaluate to false for all C if conditions.

Colin McAllister (2):
  android_ab: Add missing semicolon
  android_ab: Fix ANDROID_AB_BACKUP_OFFSET

 boot/android_ab.c | 97 ++-
 1 file changed, 45 insertions(+), 52 deletions(-)

--
2.43.2




CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of 
the intended recipient(s) and contain information that may be Garmin 
confidential and/or Garmin legally privileged. If you have received this email 
in error, please notify the sender by reply email and delete the message. Any 
disclosure, copying, distribution or use of this communication (including 
attachments) by someone other than the intended recipient is prohibited. Thank 
you.

Re: [PATCH v2] rockchip: load env from boot MMC device

[Quentin Schulz]

Hi Ben,

On 3/8/24 04:00, Ben Wolsieffer wrote:

[Some people who received this message don't often get email from 
benwolsief...@gmail.com. Learn why this is important at 
https://aka.ms/LearnAboutSenderIdentification ]

Currently, if the environment is stored on an MMC device, the device
number is hardcoded by CONFIG_SYS_MMC_ENV_DEV. This is problematic
because many boards can choose between booting from an SD card or a
removable eMMC. For example, the Rock64 defconfig sets
CONFIG_SYS_MMC_ENV_DEV=1, which corresponds to the SD card. If an eMMC
is used as the boot device and no SD card is installed, it is impossible
to save the environment.

To avoid this problem, we can choose the environment MMC device based on
the boot device. The theobroma-systems boards already contain code to do
this, so this commit simply moves it to the common Rockchip board file,
with some refactoring. I also removed another implementation of
mmc_get_env_dev() from tinker_rk3288 that performed MMC boot device
detection by reading a bootrom register.

This has been tested on a Rock64v2.

Signed-off-by: Ben Wolsieffer 


Minor (optional I believe) comments below but for the "logic" part:

Reviewed-by: Quentin Schulz 


---
v2:
* Use #ifdef rather than if(CONFIG_IS_ENABLED(...))
* Add a debug message if boot device is not found

  arch/arm/mach-rockchip/board.c   | 31 
  board/rockchip/tinker_rk3288/tinker-rk3288.c | 12 
  board/theobroma-systems/common/common.c  | 30 ---
  3 files changed, 31 insertions(+), 42 deletions(-)

diff --git a/arch/arm/mach-rockchip/board.c b/arch/arm/mach-rockchip/board.c
index 2620530e03..8aa09f44b3 100644
--- a/arch/arm/mach-rockchip/board.c
+++ b/arch/arm/mach-rockchip/board.c
@@ -6,6 +6,7 @@
  #include 
  #include 
  #include 
+#include 


c.f. 
https://docs.u-boot.org/en/latest/develop/codingstyle.html#include-files


"""
In all cases, they should be listed in alphabetical order. First comes 
headers which are located directly in our top-level include diretory. 
This excludes the common.h header file which is to be removed. Second 
are headers within subdirectories, Finally directory-local includes 
should be listed.

"""

So it should be after
asm/arch-rockchip/misc.h
and before
power/regulator.h


  #include 
  #include 
  #include 
@@ -349,3 +350,33 @@ __weak int board_rng_seed(struct abuf *buf)
 return 0;
  }
  #endif
+
+int mmc_get_env_dev(void)
+{
+   int devnum;
+   const char *boot_device;
+   struct udevice *dev;
+


This rule isn't written in the coding style I think, but some kernel 
people like the reverse Christmas tree order.


So, here it'd be:
"""
+   const char *boot_device;
+   struct udevice *dev;
+   int devnum;
"""

Cheers,
Quentin

Re: [PATCH 5/6] arm: fix __efi_runtime_start/end definitions

[Ilias Apalodimas]

On Fri, 8 Mar 2024 at 16:14, Ilias Apalodimas
 wrote:
>
> On Fri, 8 Mar 2024 at 15:22, Ilias Apalodimas
>  wrote:
> >
> > Hi Sam,
> >
> > On Thu, 7 Mar 2024 at 08:50, Ilias Apalodimas
> >  wrote:
> > >
> > >
> > >
> > > On Thu, 7 Mar 2024 at 00:19, Sam Edwards  wrote:
> > >>
> > >>
> > >>
> > >> On 3/6/24 02:13, Ilias Apalodimas wrote:
> > >> > Hi Sam,
> > >> >
> > >> > Again thank you for the elaborate review. This really helps a lot.
> > >> >
> > >> > On Wed, 6 Mar 2024 at 10:14, Sam Edwards  wrote:
> > >> >>
> > >> >>
> > >> >>
> > >> >> On 3/4/24 02:01, Ilias Apalodimas wrote:
> > >> >>> __efi_runtime_start/end are defined as c variables for arm7 only in
> > >> >>> order to force the compiler emit relative references. However, 
> > >> >>> defining
> > >> >>> those within a section definition will do the same thing. On top of 
> > >> >>> that
> > >> >>> the v8 linker scripts define it as a symbol.
> > >> >>>
> > >> >>> So let's remove the special sections from the linker scripts, the
> > >> >>> variable definitions from sections.c and define them as a symbols 
> > >> >>> within
> > >> >>> the correct section.
> > >> >>>
> > >> >>> Signed-off-by: Ilias Apalodimas 
> > >> >> Tested-by: Sam Edwards  # Binary output identical
> > >> >>
> > >> >> Thanks for the cleanup,
> > >> >> Sam
> > >> >>
> > >> >>> ---
> > >> >>>arch/arm/cpu/u-boot.lds| 12 +++-
> > >> >>>arch/arm/lib/sections.c|  2 --
> > >> >>>arch/arm/mach-zynq/u-boot.lds  | 12 +++-
> > >> >>>include/asm-generic/sections.h |  1 +
> > >> >>>4 files changed, 7 insertions(+), 20 deletions(-)
> > >> >>>
> > >> >>> diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds
> > >> >>> index 7c6e7891d360..df55bb716e35 100644
> > >> >>> --- a/arch/arm/cpu/u-boot.lds
> > >> >>> +++ b/arch/arm/cpu/u-boot.lds
> > >> >>> @@ -43,18 +43,12 @@ SECTIONS
> > >> >>>}
> > >> >>>
> > >> >>>/* This needs to come before *(.text*) */
> > >> >>> - .__efi_runtime_start : {
> > >> >>> - *(.__efi_runtime_start)
> > >> >>> - }
> > >> >>> -
> > >> >>> - .efi_runtime : {
> > >> >>> + .efi_runtime ALIGN(4) : {
> > >> >>
> > >> >> Do we truly require the ALIGN(4)? If I understand correctly, by 
> > >> >> default,
> > >> >> the linker calculates the alignment of an output section as the least
> > >> >> common multiple of the input sections' alignment requirements -- 
> > >> >> meaning
> > >> >> most (perhaps all) of our ALIGN()s today are redundant.
> > >> >
> > >> > I don't think we do. But I preserved those for a few reasons.
> > >> >
> > >> >>   For the time
> > >> >> being, I'm in favor of merging existing `. = ALIGN(x)` into each
> > >> >> following section for clarity and to avoid the testing overhead of
> > >> >> removing them in the same patch as other changes. However, in the near
> > >> >> future (perhaps even as "near" as v2 of this series?), I'd also like 
> > >> >> to
> > >> >> see a patch that eliminates unnecessary ALIGN()s altogether. 
> > >> >> Introducing
> > >> >> additional ALIGN()s where we already know they aren't needed may be a
> > >> >> step away from that goal.
> > >> >
> > >> > So as you already mentioned the reason I preserved this is:
> > >> > - Reduce the testing overhead by preserving the same layout for now
> > >> > - In the future, I am playing around with the idea of mapping U-Boot
> > >> > (not SPL but the relocated full U-Boot) in sections with proper memory
> > >> > permissions (R), RW^X etc). In that case, we will need a 4k section
> > >> > alignment and we can repurpose the ALIGN(4/8) to
> > >> > ALIGN(CONSTANT(COMMONPAGESIZE)).
> > >> >
> > >> > Thoughts?
> > >>
> > >> Ah, right: I had forgotten for a moment that the ultimate goal was to
> > >> clean up the memory protection bit situation.
> > >>
> > >> Okay, as long as that future cleanup will also remove all unnecessary
> > >> uses of ALIGN() (i.e. any that don't result in an actual change in
> > >> memory layout) then that sounds great to me.
> > >
> > >
> > > Yep will do
> > >
> > >>
> > >> Reviewed-by: Sam Edwards 
> >
> > Thanks. However, I noticed the alignment rule was wrong
> > it needs to be '.efi_runtime : ALIGN(4)' instead of '.efi_runtime ALIGN(4) 
> > :'.
> > The latter will define the start address instead of specifying the 
> > alignment.
> > Due to what you mentioned above this (that we don't really need the
> > ALIGN(4) the resulting binary is unaffected.
>
> To be exact, it will work because ALIGN returns the current location
> counter aligned upward to the specified value.

But thinking about it a bit more, I'll just get rid of the redundant
ALIGN as you suggested. I don't think it makes sense to keep or force
the output section alignment just because in the future we want to fix
page permissions.
We can always re-introduce it when stricter (4k) alignment is required for that

Cheers
/Ilias

>
>
> >
> > Thanks
> > /Ilias
> >
> > >
> > >
> > >
> > >
> > > Thanks!
> > >
> > >>

Re: [PATCH 2/2] phy: rockchip-inno-usb2: Limit changes made to regs

[Jonas Karlman]

Hi Kever,

On 2024-03-08 10:06, Kever Yang wrote:
> Hi Jonas,
> 
> On 2024/2/26 06:10, Jonas Karlman wrote:
>> The USB2PHY regs already contain working default reset values for RK3328
>> and RK35xx as evidenced by the fact that this driver never has changed a
>> single value for these SoCs.
> 
> I would prefer to keep it as is for now, I think these configs are 
> needed for the phy init,

This driver currenly only use the phy_sus and bvalid_det_en/clr regs.
The bvalid_det_en/clr regs is related to interrupts, something this
driver does not use, and in mainline linux they are only applied to
otg/peripheral ports and not to all ports like in u-boot.

My understanding is that the phy_sus reg is intented to control phy
suspend mode, currently that is what the rk3399 and rk3588 variant is
doing. However, for the other socs it tries to control phy suspend and
also set values for other bits in the same hw reg.

I think it is better to clean this up to make it work consistent and/or
limit what bits we write now, instead of possibly introducing new issues
because of the GRF fix in the first patch of this series.

> 
> but I'm not sure these configs are all default correct after sw/hw  
> reset/reboot and for
> 
> all the SoC versions.

By default the phy seem to work for otg or host mode after a reset for
all SoCs currently supported by this driver. I have tested this using
host/otg/peripheral mode on RK3308, RK3328, RK3399, RK356x and RK3588.

The missing RK3308 parts will be added in a separate series.

> 
>> Reduce to only configure utmi_suspend_n and utmi_sel bits similar to
>> what is currently done on RK3399.
> I don't understand, you also remove configs for rk3399 in this patch, 
> isn't it?
>> Also add missing clkout_ctl for RK3588.
> This is necessary, would be better  send as a separate patch.
>>
>> When enabled utmi_suspend_n is changed to normal mode and utmi_sel to
>> use otg/host controller utmi interface to phy. When disabled
>> utmi_suspend_n is changed to suspend mode and utmi_sel to use GRF utmi
>> interface to phy.
> 
> I don't understand this change for not much knowledge on utmi interface, 
> any issue if we use the old config?

If I remember correctly I had some issue with otg when existing values
where written to hw reg, and the working hw reset default value did not
fully match the values defined for phy_sys on some port of rk3328 and/or
rk356x.

This patch fixes the inconsistent meaning/affect of phy_sus reg for all
socs, instead of having different and possible unintended behaviour
depending on the soc.

> 
> If necessary, should send as a separate patch.

Ensuring that the phy is configured in a similar way accross soc was the
main intent for this patch, not sure how to split this in another way.

Regards,
Jonas

> 
> 
> Thanks,
> - Kever
>>
>> Signed-off-by: Jonas Karlman 
>> ---
>>   drivers/phy/rockchip/phy-rockchip-inno-usb2.c | 117 +++---
>>   1 file changed, 14 insertions(+), 103 deletions(-)
>>
>> diff --git a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c 
>> b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
>> index 7317128d135e..d392aed2d4de 100644
>> --- a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
>> +++ b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
>> @@ -35,16 +35,6 @@ struct usb2phy_reg {
>>   
>>   struct rockchip_usb2phy_port_cfg {
>>  struct usb2phy_reg  phy_sus;
>> -struct usb2phy_reg  bvalid_det_en;
>> -struct usb2phy_reg  bvalid_det_st;
>> -struct usb2phy_reg  bvalid_det_clr;
>> -struct usb2phy_reg  ls_det_en;
>> -struct usb2phy_reg  ls_det_st;
>> -struct usb2phy_reg  ls_det_clr;
>> -struct usb2phy_reg  utmi_avalid;
>> -struct usb2phy_reg  utmi_bvalid;
>> -struct usb2phy_reg  utmi_ls;
>> -struct usb2phy_reg  utmi_hstdet;
>>   };
>>   
>>   struct rockchip_usb2phy_cfg {
>> @@ -131,7 +121,6 @@ static int rockchip_usb2phy_init(struct phy *phy)
>>   {
>>  struct udevice *parent = dev_get_parent(phy->dev);
>>  struct rockchip_usb2phy *priv = dev_get_priv(parent);
>> -const struct rockchip_usb2phy_port_cfg *port_cfg = us2phy_get_port(phy);
>>  int ret;
>>   
>>  ret = clk_enable(>phyclk);
>> @@ -140,14 +129,6 @@ static int rockchip_usb2phy_init(struct phy *phy)
>>  return ret;
>>  }
>>   
>> -if (phy->id == USB2PHY_PORT_OTG) {
>> -property_enable(priv->reg_base, _cfg->bvalid_det_clr, 
>> true);
>> -property_enable(priv->reg_base, _cfg->bvalid_det_en, true);
>> -} else if (phy->id == USB2PHY_PORT_HOST) {
>> -property_enable(priv->reg_base, _cfg->bvalid_det_clr, 
>> true);
>> -property_enable(priv->reg_base, _cfg->bvalid_det_en, true);
>> -}
>> -
>>  return 0;
>>   }
>>   
>> @@ -351,27 +332,13 @@ bind_fail:
>>   static const struct rockchip_usb2phy_cfg rk3328_usb2phy_cfgs[] = {
>>  {
>>  .reg = 0x100,
>> -.clkout_ctl = { 0x108, 4, 4, 1, 0 },

Re: [PATCH] fdt_support: fix fdt_copy_fixed_partitions function()

[Dragan Simic]

Hello Patrice,

Please, see my comment below.

On 2024-03-08 14:34, Patrice Chotard wrote:

Move variable declaration at the beginning of the function.

Fixes: 163c5f60ebb4 ("fdt_support: add fdt_copy_fixed_partitions 
function")


Signed-off-by: Patrice Chotard 
---

 boot/fdt_support.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/boot/fdt_support.c b/boot/fdt_support.c
index 090d82ee80a..f948cf8cd42 100644
--- a/boot/fdt_support.c
+++ b/boot/fdt_support.c
@@ -1053,9 +1053,10 @@ void fdt_fixup_mtdparts(void *blob, const
struct node_info *node_info,
 int fdt_copy_fixed_partitions(void *blob)
 {
ofnode node, subnode;
+   const u32 *reg;
int off, suboff, res;
char path[256];
-   int address_cells, size_cells;
+   int address_cells, size_cells, len;
u8 i, j, child_count;

node = ofnode_by_compatible(ofnode_null(), "fixed-partitions");
@@ -1101,9 +1102,6 @@ int fdt_copy_fixed_partitions(void *blob)
if (!ofnode_valid(subnode))
break;

-   const u32 *reg;
-   int len;
-


Perhaps it would be better to keep these two variables local
to the block they're used in.  I mean, in this case it isn't
a big deal anyway, but results in a bit cleaner code.

 			suboff = fdt_find_or_add_subnode(blob, off, 
ofnode_get_name(subnode));

res = fdt_setprop_string(blob, suboff, "label",
 ofnode_read_string(subnode, 
"label"));

Re: [PATCH 3/3] ARM: dts: stm32: Fix partition node name for stm32mp15xx-dhcom-u-boot

[Marek Vasut]

On 3/8/24 2:50 PM, Patrice Chotard wrote:

Fix flash@0 partition node name with correct offset.

Fixes: 90f992e6a58c ("arm: dts: stm32: Add partitions in flash0 and nand
node for stm32mp15xx-dhcom/dhcor")

Signed-off-by: Patrice Chotard 


Reviewed-by: Marek Vasut 

Re: [PATCH 2/3] ARM: dts: stm32: Fix partition node name for stm32mp15xx-dhcor-u-boot

[Marek Vasut]

On 3/8/24 2:50 PM, Patrice Chotard wrote:

Fix flash@0 partition node name with correct offset.

Fixes: 90f992e6a58c ("arm: dts: stm32: Add partitions in flash0 and nand node 
for
stm32mp15xx-dhcom/dhcor")

Signed-off-by: Patrice Chotard 


Reviewed-by: Marek Vasut 

[PATCH 1/2] mmc: stm32_sdmmc2: Add "st,stm32mp25-sdmmc2" compatible

[Patrice Chotard]

From: Patrick Delaunay 

Add compatible used for STM32MP25 family.

Signed-off-by: Patrick Delaunay 
Signed-off-by: Patrice Chotard 
---

 drivers/mmc/stm32_sdmmc2.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mmc/stm32_sdmmc2.c b/drivers/mmc/stm32_sdmmc2.c
index a2b111a8435..d4982a14281 100644
--- a/drivers/mmc/stm32_sdmmc2.c
+++ b/drivers/mmc/stm32_sdmmc2.c
@@ -789,6 +789,7 @@ static int stm32_sdmmc2_bind(struct udevice *dev)
 
 static const struct udevice_id stm32_sdmmc2_ids[] = {
{ .compatible = "st,stm32-sdmmc2" },
+   { .compatible = "st,stm32mp25-sdmmc2" },
{ }
 };
 
-- 
2.25.1

[PATCH 2/2] mmc: stm32_sdmmc2: Fix AARCH64 compilation warnings

[Patrice Chotard]

When building with AARCH64 defconfig, we got warnings, fix them.

Signed-off-by: Patrice Chotard 
---

 drivers/mmc/stm32_sdmmc2.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/mmc/stm32_sdmmc2.c b/drivers/mmc/stm32_sdmmc2.c
index d4982a14281..39ae79ba129 100644
--- a/drivers/mmc/stm32_sdmmc2.c
+++ b/drivers/mmc/stm32_sdmmc2.c
@@ -220,9 +220,9 @@ static void stm32_sdmmc2_start_data(struct udevice *dev,
 
if (data->flags & MMC_DATA_READ) {
data_ctrl |= SDMMC_DCTRL_DTDIR;
-   idmabase0 = (u32)data->dest;
+   idmabase0 = (u32)(long)data->dest;
} else {
-   idmabase0 = (u32)data->src;
+   idmabase0 = (u32)(long)data->src;
}
 
/* Set the SDMMC DataLength value */
@@ -463,8 +463,8 @@ retry_cmd:
 
stm32_sdmmc2_start_cmd(dev, cmd, cmdat, );
 
-   dev_dbg(dev, "send cmd %d data: 0x%x @ 0x%x\n",
-   cmd->cmdidx, data ? ctx.data_length : 0, (unsigned int)data);
+   dev_dbg(dev, "send cmd %d data: 0x%x @ 0x%p\n",
+   cmd->cmdidx, data ? ctx.data_length : 0, data);
 
ret = stm32_sdmmc2_end_cmd(dev, cmd, );
 
-- 
2.25.1

[PATCH] toradex: tdx-cfg-block: add 0087 i.mx8m mini product variant

[Joao Paulo Goncalves]

From: Joao Paulo Goncalves 

Add new product id 0087 Verdin iMX8M Mini Quad 2GB IT.

Signed-off-by: Joao Paulo Goncalves 
---
 board/toradex/common/tdx-cfg-block.c | 1 +
 board/toradex/common/tdx-cfg-block.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/board/toradex/common/tdx-cfg-block.c 
b/board/toradex/common/tdx-cfg-block.c
index 4a7de5483d2..dcf00d2b632 100644
--- a/board/toradex/common/tdx-cfg-block.c
+++ b/board/toradex/common/tdx-cfg-block.c
@@ -157,6 +157,7 @@ const struct toradex_som toradex_modules[] = {
[84] = { "Apalis iMX6D 1GB IT",  
TARGET_IS_ENABLED(APALIS_IMX6) },
[85] = { "Apalis iMX6Q 2GB IT",  
TARGET_IS_ENABLED(APALIS_IMX6) },
[86] = { "Verdin iMX8M Mini DualLite 2GB IT",
TARGET_IS_ENABLED(VERDIN_IMX8MM)   },
+   [87] = { "Verdin iMX8M Mini Quad 2GB IT",
TARGET_IS_ENABLED(VERDIN_IMX8MM)   },
 };
 
 struct pid4list {
diff --git a/board/toradex/common/tdx-cfg-block.h 
b/board/toradex/common/tdx-cfg-block.h
index 021cc21b5e2..183ee0f2dc9 100644
--- a/board/toradex/common/tdx-cfg-block.h
+++ b/board/toradex/common/tdx-cfg-block.h
@@ -112,6 +112,7 @@ enum {
APALIS_IMX6D_IT_NOWINCE,
APALIS_IMX6Q_IT_NOWINCE, /* 85 */
VERDIN_IMX8MMDL_2G_IT,
+   VERDIN_IMX8MMQ_2G_IT_NO_CAN,
 };
 
 enum {
-- 
2.34.1

Re: [PATCH 5/6] arm: fix __efi_runtime_start/end definitions

[Ilias Apalodimas]

On Fri, 8 Mar 2024 at 15:22, Ilias Apalodimas
 wrote:
>
> Hi Sam,
>
> On Thu, 7 Mar 2024 at 08:50, Ilias Apalodimas
>  wrote:
> >
> >
> >
> > On Thu, 7 Mar 2024 at 00:19, Sam Edwards  wrote:
> >>
> >>
> >>
> >> On 3/6/24 02:13, Ilias Apalodimas wrote:
> >> > Hi Sam,
> >> >
> >> > Again thank you for the elaborate review. This really helps a lot.
> >> >
> >> > On Wed, 6 Mar 2024 at 10:14, Sam Edwards  wrote:
> >> >>
> >> >>
> >> >>
> >> >> On 3/4/24 02:01, Ilias Apalodimas wrote:
> >> >>> __efi_runtime_start/end are defined as c variables for arm7 only in
> >> >>> order to force the compiler emit relative references. However, defining
> >> >>> those within a section definition will do the same thing. On top of 
> >> >>> that
> >> >>> the v8 linker scripts define it as a symbol.
> >> >>>
> >> >>> So let's remove the special sections from the linker scripts, the
> >> >>> variable definitions from sections.c and define them as a symbols 
> >> >>> within
> >> >>> the correct section.
> >> >>>
> >> >>> Signed-off-by: Ilias Apalodimas 
> >> >> Tested-by: Sam Edwards  # Binary output identical
> >> >>
> >> >> Thanks for the cleanup,
> >> >> Sam
> >> >>
> >> >>> ---
> >> >>>arch/arm/cpu/u-boot.lds| 12 +++-
> >> >>>arch/arm/lib/sections.c|  2 --
> >> >>>arch/arm/mach-zynq/u-boot.lds  | 12 +++-
> >> >>>include/asm-generic/sections.h |  1 +
> >> >>>4 files changed, 7 insertions(+), 20 deletions(-)
> >> >>>
> >> >>> diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds
> >> >>> index 7c6e7891d360..df55bb716e35 100644
> >> >>> --- a/arch/arm/cpu/u-boot.lds
> >> >>> +++ b/arch/arm/cpu/u-boot.lds
> >> >>> @@ -43,18 +43,12 @@ SECTIONS
> >> >>>}
> >> >>>
> >> >>>/* This needs to come before *(.text*) */
> >> >>> - .__efi_runtime_start : {
> >> >>> - *(.__efi_runtime_start)
> >> >>> - }
> >> >>> -
> >> >>> - .efi_runtime : {
> >> >>> + .efi_runtime ALIGN(4) : {
> >> >>
> >> >> Do we truly require the ALIGN(4)? If I understand correctly, by default,
> >> >> the linker calculates the alignment of an output section as the least
> >> >> common multiple of the input sections' alignment requirements -- meaning
> >> >> most (perhaps all) of our ALIGN()s today are redundant.
> >> >
> >> > I don't think we do. But I preserved those for a few reasons.
> >> >
> >> >>   For the time
> >> >> being, I'm in favor of merging existing `. = ALIGN(x)` into each
> >> >> following section for clarity and to avoid the testing overhead of
> >> >> removing them in the same patch as other changes. However, in the near
> >> >> future (perhaps even as "near" as v2 of this series?), I'd also like to
> >> >> see a patch that eliminates unnecessary ALIGN()s altogether. Introducing
> >> >> additional ALIGN()s where we already know they aren't needed may be a
> >> >> step away from that goal.
> >> >
> >> > So as you already mentioned the reason I preserved this is:
> >> > - Reduce the testing overhead by preserving the same layout for now
> >> > - In the future, I am playing around with the idea of mapping U-Boot
> >> > (not SPL but the relocated full U-Boot) in sections with proper memory
> >> > permissions (R), RW^X etc). In that case, we will need a 4k section
> >> > alignment and we can repurpose the ALIGN(4/8) to
> >> > ALIGN(CONSTANT(COMMONPAGESIZE)).
> >> >
> >> > Thoughts?
> >>
> >> Ah, right: I had forgotten for a moment that the ultimate goal was to
> >> clean up the memory protection bit situation.
> >>
> >> Okay, as long as that future cleanup will also remove all unnecessary
> >> uses of ALIGN() (i.e. any that don't result in an actual change in
> >> memory layout) then that sounds great to me.
> >
> >
> > Yep will do
> >
> >>
> >> Reviewed-by: Sam Edwards 
>
> Thanks. However, I noticed the alignment rule was wrong
> it needs to be '.efi_runtime : ALIGN(4)' instead of '.efi_runtime ALIGN(4) :'.
> The latter will define the start address instead of specifying the alignment.
> Due to what you mentioned above this (that we don't really need the
> ALIGN(4) the resulting binary is unaffected.

To be exact, it will work because ALIGN returns the current location
counter aligned upward to the specified value.


>
> Thanks
> /Ilias
>
> >
> >
> >
> >
> > Thanks!
> >
> >>
> >> Cheers,
> >> Sam
> >>
> >> >
> >> > Thanks
> >> > /Ilias
> >> >
> >> >>
> >> >>> + __efi_runtime_start = .;
> >> >>>*(.text.efi_runtime*)
> >> >>>*(.rodata.efi_runtime*)
> >> >>>*(.data.efi_runtime*)
> >> >>> - }
> >> >>> -
> >> >>> - .__efi_runtime_stop : {
> >> >>> - *(.__efi_runtime_stop)
> >> >>> + __efi_runtime_stop = .;
> >> >>>}
> >> >>>
> >> >>>.text_rest :
> >> >>> diff --git a/arch/arm/lib/sections.c b/arch/arm/lib/sections.c
> >> >>> index 1ee3dd3667ba..a4d4202e99f5 100644
> >> >>> --- a/arch/arm/lib/sections.c
> >> >>> +++ b/arch/arm/lib/sections.c
> >> >>> 

[PATCH 3/3] ARM: dts: stm32: Fix partition node name for stm32mp15xx-dhcom-u-boot

[Patrice Chotard]

Fix flash@0 partition node name with correct offset.

Fixes: 90f992e6a58c ("arm: dts: stm32: Add partitions in flash0 and nand
node for stm32mp15xx-dhcom/dhcor")

Signed-off-by: Patrice Chotard 
---

 arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi 
b/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
index 2f70b0690d2..1b445619325 100644
--- a/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
@@ -106,15 +106,15 @@
label = "fsbl2";
reg = <0x0004 0x0004>;
};
-   partition@50 {
+   partition@8 {
label = "uboot";
reg = <0x0008 0x0016>;
};
-   partition@90 {
+   partition@1e {
label = "env1";
reg = <0x001E 0x0001>;
};
-   partition@98 {
+   partition@1f {
label = "env2";
reg = <0x001F 0x0001>;
};
-- 
2.25.1

[PATCH 1/3] ARM: dts: stm32: Fix partition node name for stm32mp157c-ev1-u-boot

[Patrice Chotard]

Fix flash@0 and nand@0 partition node name with correct offset.

Fixes: e91d3c61767b ("arm: dts: stm32: Add partitions in flash0 and nand
node for stm32mp15xx-ev1")

Signed-off-by: Patrice Chotard 
---

 arch/arm/dts/stm32mp157c-ev1-u-boot.dtsi | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/dts/stm32mp157c-ev1-u-boot.dtsi 
b/arch/arm/dts/stm32mp157c-ev1-u-boot.dtsi
index 139940bd5d4..3515347e91d 100644
--- a/arch/arm/dts/stm32mp157c-ev1-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157c-ev1-u-boot.dtsi
@@ -33,11 +33,11 @@
label = "fsbl1";
reg = <0x 0x0004>;
};
-   partition@8 {
+   partition@4 {
label = "fsbl2";
reg = <0x0004 0x0004>;
};
-   partition@10 {
+   partition@8 {
label = "ssbl";
reg = <0x0008 0x0020>;
};
@@ -58,7 +58,7 @@
label = "fsbl2";
reg = <0x0004 0x0004>;
};
-   partition@10 {
+   partition@8 {
label = "fip";
reg = <0x0008 0x0040>;
};
@@ -112,7 +112,7 @@
label = "fip2";
reg = <0x0060 0x0040>;
};
-   partition@120 {
+   partition@a0 {
label = "UBI";
reg = <0x00a0 0x3f60>;
};
-- 
2.25.1

[PATCH 2/3] ARM: dts: stm32: Fix partition node name for stm32mp15xx-dhcor-u-boot

[Patrice Chotard]

Fix flash@0 partition node name with correct offset.

Fixes: 90f992e6a58c ("arm: dts: stm32: Add partitions in flash0 and nand node 
for
stm32mp15xx-dhcom/dhcor")

Signed-off-by: Patrice Chotard 
---

 arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi 
b/arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi
index 552b35db3c7..ba84db679e1 100644
--- a/arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi
@@ -42,15 +42,15 @@
label = "fsbl2";
reg = <0x0004 0x0004>;
};
-   partition@50 {
+   partition@8 {
label = "uboot";
reg = <0x0008 0x0016>;
};
-   partition@90 {
+   partition@1e {
label = "env1";
reg = <0x001E 0x0001>;
};
-   partition@98 {
+   partition@1f {
label = "env2";
reg = <0x001F 0x0001>;
};
-- 
2.25.1

[PATCH] fdt_support: fix fdt_copy_fixed_partitions function()

[Patrice Chotard]

Move variable declaration at the beginning of the function.

Fixes: 163c5f60ebb4 ("fdt_support: add fdt_copy_fixed_partitions function")

Signed-off-by: Patrice Chotard 
---

 boot/fdt_support.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/boot/fdt_support.c b/boot/fdt_support.c
index 090d82ee80a..f948cf8cd42 100644
--- a/boot/fdt_support.c
+++ b/boot/fdt_support.c
@@ -1053,9 +1053,10 @@ void fdt_fixup_mtdparts(void *blob, const struct 
node_info *node_info,
 int fdt_copy_fixed_partitions(void *blob)
 {
ofnode node, subnode;
+   const u32 *reg;
int off, suboff, res;
char path[256];
-   int address_cells, size_cells;
+   int address_cells, size_cells, len;
u8 i, j, child_count;
 
node = ofnode_by_compatible(ofnode_null(), "fixed-partitions");
@@ -1101,9 +1102,6 @@ int fdt_copy_fixed_partitions(void *blob)
if (!ofnode_valid(subnode))
break;
 
-   const u32 *reg;
-   int len;
-
suboff = fdt_find_or_add_subnode(blob, off, 
ofnode_get_name(subnode));
res = fdt_setprop_string(blob, suboff, "label",
 ofnode_read_string(subnode, 
"label"));
-- 
2.25.1

Re: [PATCH] Makefile: Improve generated_defconfig file handling

[Andrew Davis]

On 3/7/24 9:38 PM, Sam Protsenko wrote:

Commit 2027e99e61aa ("Makefile: Run defconfig files through the C
preprocessor") adds `generated_defconfig' file, but fails to clean that
up. It might be useful to have that file around after `make' is done,
but it's better to clean that up on `make clean'. Also we probably want
to hide it in `git status' list. This patch makes the described changes,
and also adds `-P' parameter to the CPP command that produces the
`generated_defconfig' to avoid generating linemarkers.



All look like sensible improvements to me,

Acked-by: Andrew Davis 


Signed-off-by: Sam Protsenko 
Fixes: 2027e99e61aa ("Makefile: Run defconfig files through the C preprocessor")
---
  .gitignore   | 1 +
  Makefile | 1 +
  scripts/kconfig/Makefile | 2 +-
  3 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/.gitignore b/.gitignore
index 330148119264..d9a64d742fd7 100644
--- a/.gitignore
+++ b/.gitignore
@@ -63,6 +63,7 @@ fit-dtb.blob*
  /spl/
  /tpl/
  /defconfig
+/generated_defconfig
  
  #

  # Generated include files
diff --git a/Makefile b/Makefile
index a2bc9d590329..6fd0e92c7d5a 100644
--- a/Makefile
+++ b/Makefile
@@ -2205,6 +2205,7 @@ clean: $(clean-dirs)
-o -name modules.builtin -o -name '.tmp_*.o.*' \
-o -name 'dsdt_generated.aml' -o -name 'dsdt_generated.asl.tmp' 
\
-o -name 'dsdt_generated.c' \
+   -o -name 'generated_defconfig' \
-o -name '*.efi' -o -name '*.gcno' -o -name '*.so' \) \
-type f -print | xargs rm -f
  
diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile

index 5ce5845e8247..079add4d5dab 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -93,7 +93,7 @@ endif
  endif
  
  %_defconfig: $(obj)/conf

-   $(Q)$(CPP) -nostdinc -I $(srctree) -undef -x assembler-with-cpp 
$(srctree)/arch/$(SRCARCH)/configs/$@ -o generated_defconfig
+   $(Q)$(CPP) -nostdinc -P -I $(srctree) -undef -x assembler-with-cpp 
$(srctree)/arch/$(SRCARCH)/configs/$@ -o generated_defconfig
$(Q)$< $(silent) --defconfig=generated_defconfig $(Kconfig)
  
  # Added for U-Boot (backward compatibility)

Re: [PATCH v3 6/6] tee: remove common.h inclusion

[Ilias Apalodimas]

On Mon, 4 Mar 2024 at 19:45, Igor Opaniuk  wrote:
>
> The usage of the common.h include file is deprecated [1], and has already
> been removed from several files.
> Get rid of all inclusions in the "drivers/tee" directory, and replace it
> with required include files directly where needed.
>
> [1] doc/develop/codingstyle.rst
>
> Signed-off-by: Igor Opaniuk 
> ---
>
> Changes in v2:
> - Fixed chimp_optee.c:37:9: error: implicit declaration of function 'memset'

Ci is happy now
Reviewed-by: Ilias Apalodimas 


>
>  drivers/tee/broadcom/chimp_optee.c | 3 ++-
>  drivers/tee/optee/core.c   | 1 -
>  drivers/tee/optee/i2c.c| 1 -
>  drivers/tee/optee/rpmb.c   | 1 -
>  drivers/tee/optee/supplicant.c | 2 +-
>  drivers/tee/sandbox.c  | 2 +-
>  drivers/tee/tee-uclass.c   | 1 -
>  7 files changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/tee/broadcom/chimp_optee.c 
> b/drivers/tee/broadcom/chimp_optee.c
> index 37f9b094f76..bd146ef2899 100644
> --- a/drivers/tee/broadcom/chimp_optee.c
> +++ b/drivers/tee/broadcom/chimp_optee.c
> @@ -3,9 +3,10 @@
>   * Copyright 2020 Broadcom.
>   */
>
> -#include 
>  #include 
>  #include 
> +#include 
> +#include 
>
>  #ifdef CONFIG_CHIMP_OPTEE
>
> diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
> index 47f845cffe3..5fc0505c788 100644
> --- a/drivers/tee/optee/core.c
> +++ b/drivers/tee/optee/core.c
> @@ -3,7 +3,6 @@
>   * Copyright (c) 2018-2020 Linaro Limited
>   */
>
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/tee/optee/i2c.c b/drivers/tee/optee/i2c.c
> index ef4e10f9912..e3fb99897c5 100644
> --- a/drivers/tee/optee/i2c.c
> +++ b/drivers/tee/optee/i2c.c
> @@ -3,7 +3,6 @@
>   * Copyright (c) 2020 Foundries.io Ltd
>   */
>
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/tee/optee/rpmb.c b/drivers/tee/optee/rpmb.c
> index 5bc13757ea8..bacced6af6c 100644
> --- a/drivers/tee/optee/rpmb.c
> +++ b/drivers/tee/optee/rpmb.c
> @@ -3,7 +3,6 @@
>   * Copyright (c) 2018 Linaro Limited
>   */
>
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/tee/optee/supplicant.c b/drivers/tee/optee/supplicant.c
> index f9dd874b594..8a426f53ba8 100644
> --- a/drivers/tee/optee/supplicant.c
> +++ b/drivers/tee/optee/supplicant.c
> @@ -3,10 +3,10 @@
>   * Copyright (c) 2018, Linaro Limited
>   */
>
> -#include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>
>  #include "optee_msg.h"
> diff --git a/drivers/tee/sandbox.c b/drivers/tee/sandbox.c
> index ec66401878c..8ad7c09efdd 100644
> --- a/drivers/tee/sandbox.c
> +++ b/drivers/tee/sandbox.c
> @@ -2,7 +2,7 @@
>  /*
>   * Copyright (C) 2018 Linaro Limited
>   */
> -#include 
> +
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/tee/tee-uclass.c b/drivers/tee/tee-uclass.c
> index 52412a4098e..0194d732193 100644
> --- a/drivers/tee/tee-uclass.c
> +++ b/drivers/tee/tee-uclass.c
> @@ -5,7 +5,6 @@
>
>  #define LOG_CATEGORY UCLASS_TEE
>
> -#include 
>  #include 
>  #include 
>  #include 
> --
> 2.34.1
>

Re: [PATCH 5/6] arm: fix __efi_runtime_start/end definitions

[Ilias Apalodimas]

Hi Sam,

On Thu, 7 Mar 2024 at 08:50, Ilias Apalodimas
 wrote:
>
>
>
> On Thu, 7 Mar 2024 at 00:19, Sam Edwards  wrote:
>>
>>
>>
>> On 3/6/24 02:13, Ilias Apalodimas wrote:
>> > Hi Sam,
>> >
>> > Again thank you for the elaborate review. This really helps a lot.
>> >
>> > On Wed, 6 Mar 2024 at 10:14, Sam Edwards  wrote:
>> >>
>> >>
>> >>
>> >> On 3/4/24 02:01, Ilias Apalodimas wrote:
>> >>> __efi_runtime_start/end are defined as c variables for arm7 only in
>> >>> order to force the compiler emit relative references. However, defining
>> >>> those within a section definition will do the same thing. On top of that
>> >>> the v8 linker scripts define it as a symbol.
>> >>>
>> >>> So let's remove the special sections from the linker scripts, the
>> >>> variable definitions from sections.c and define them as a symbols within
>> >>> the correct section.
>> >>>
>> >>> Signed-off-by: Ilias Apalodimas 
>> >> Tested-by: Sam Edwards  # Binary output identical
>> >>
>> >> Thanks for the cleanup,
>> >> Sam
>> >>
>> >>> ---
>> >>>arch/arm/cpu/u-boot.lds| 12 +++-
>> >>>arch/arm/lib/sections.c|  2 --
>> >>>arch/arm/mach-zynq/u-boot.lds  | 12 +++-
>> >>>include/asm-generic/sections.h |  1 +
>> >>>4 files changed, 7 insertions(+), 20 deletions(-)
>> >>>
>> >>> diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds
>> >>> index 7c6e7891d360..df55bb716e35 100644
>> >>> --- a/arch/arm/cpu/u-boot.lds
>> >>> +++ b/arch/arm/cpu/u-boot.lds
>> >>> @@ -43,18 +43,12 @@ SECTIONS
>> >>>}
>> >>>
>> >>>/* This needs to come before *(.text*) */
>> >>> - .__efi_runtime_start : {
>> >>> - *(.__efi_runtime_start)
>> >>> - }
>> >>> -
>> >>> - .efi_runtime : {
>> >>> + .efi_runtime ALIGN(4) : {
>> >>
>> >> Do we truly require the ALIGN(4)? If I understand correctly, by default,
>> >> the linker calculates the alignment of an output section as the least
>> >> common multiple of the input sections' alignment requirements -- meaning
>> >> most (perhaps all) of our ALIGN()s today are redundant.
>> >
>> > I don't think we do. But I preserved those for a few reasons.
>> >
>> >>   For the time
>> >> being, I'm in favor of merging existing `. = ALIGN(x)` into each
>> >> following section for clarity and to avoid the testing overhead of
>> >> removing them in the same patch as other changes. However, in the near
>> >> future (perhaps even as "near" as v2 of this series?), I'd also like to
>> >> see a patch that eliminates unnecessary ALIGN()s altogether. Introducing
>> >> additional ALIGN()s where we already know they aren't needed may be a
>> >> step away from that goal.
>> >
>> > So as you already mentioned the reason I preserved this is:
>> > - Reduce the testing overhead by preserving the same layout for now
>> > - In the future, I am playing around with the idea of mapping U-Boot
>> > (not SPL but the relocated full U-Boot) in sections with proper memory
>> > permissions (R), RW^X etc). In that case, we will need a 4k section
>> > alignment and we can repurpose the ALIGN(4/8) to
>> > ALIGN(CONSTANT(COMMONPAGESIZE)).
>> >
>> > Thoughts?
>>
>> Ah, right: I had forgotten for a moment that the ultimate goal was to
>> clean up the memory protection bit situation.
>>
>> Okay, as long as that future cleanup will also remove all unnecessary
>> uses of ALIGN() (i.e. any that don't result in an actual change in
>> memory layout) then that sounds great to me.
>
>
> Yep will do
>
>>
>> Reviewed-by: Sam Edwards 

Thanks. However, I noticed the alignment rule was wrong
it needs to be '.efi_runtime : ALIGN(4)' instead of '.efi_runtime ALIGN(4) :'.
The latter will define the start address instead of specifying the alignment.
Due to what you mentioned above this (that we don't really need the
ALIGN(4) the resulting binary is unaffected.

Thanks
/Ilias

>
>
>
>
> Thanks!
>
>>
>> Cheers,
>> Sam
>>
>> >
>> > Thanks
>> > /Ilias
>> >
>> >>
>> >>> + __efi_runtime_start = .;
>> >>>*(.text.efi_runtime*)
>> >>>*(.rodata.efi_runtime*)
>> >>>*(.data.efi_runtime*)
>> >>> - }
>> >>> -
>> >>> - .__efi_runtime_stop : {
>> >>> - *(.__efi_runtime_stop)
>> >>> + __efi_runtime_stop = .;
>> >>>}
>> >>>
>> >>>.text_rest :
>> >>> diff --git a/arch/arm/lib/sections.c b/arch/arm/lib/sections.c
>> >>> index 1ee3dd3667ba..a4d4202e99f5 100644
>> >>> --- a/arch/arm/lib/sections.c
>> >>> +++ b/arch/arm/lib/sections.c
>> >>> @@ -25,6 +25,4 @@ char __secure_start[0] __section(".__secure_start");
>> >>>char __secure_end[0] __section(".__secure_end");
>> >>>char __secure_stack_start[0] __section(".__secure_stack_start");
>> >>>char __secure_stack_end[0] __section(".__secure_stack_end");
>> >>> -char __efi_runtime_start[0] __section(".__efi_runtime_start");
>> >>> -char __efi_runtime_stop[0] __section(".__efi_runtime_stop");
>> >>>char _end[0] __section(".__end");
>> >>> 

Re: [PATCH 1/2] opos6uldev: make the LCD work again

[Conor Dooley]

On Fri, Mar 01, 2024 at 01:54:13PM -0500, Tom Rini wrote:
> On Fri, Mar 01, 2024 at 01:32:53PM +, Conor Dooley wrote:
> > > > > > > > > On Wed, 28 Feb 2024 at 18:40, Tom Rini  
> > > > > > > > > wrote:
> > > > > > > > > > I think the commit in question can be
> > > > > > > > > > summarized as "remove a bunch of explicit HW information 
> > > > > > > > > > because there's
> > > > > > > > > > now a Linux Kernel driver that determines that 
> > > > > > > > > > dynamically". What do we
> > > > > > > > > > do next? The old information is in a presumably valid 
> > > > > > > > > > binding still, can
> > > > > > > > > > we just put it back and comment that consumers outside of 
> > > > > > > > > > Linux use this
> > > > > > > > > > still so it's not removed again later? Or am I just missing 
> > > > > > > > > > where we can
> > > > > > > > > > instead get this information from the DT still and not need 
> > > > > > > > > > to come up
> > > > > > > > > > with a new driver and subsystems?
> > 
> > I don't think this is an accurate summary. The "explict hw information"
> > was never allowed for an imx6ul, only for some older devices, so "the
> > old information is in a presumably valid binding" is not accurate.
> > See 7b920aae917d ("dt-bindings: mxsfb: Add new bindings for the MXSFB
> > driver") for when doing things that way was deprecated. The imx6ul was
> > only documented several years after it was introduced (so likely several
> > years after it started incorrectly using that binding).
> > 
> > Seeing that, I am not sure that I would even question the kernel patch
> > cited above, the change was done for binding compliance and I would not
> > be inclined to think twice, given the bindings are the ABI.

Reading this back today, it took me second to recall what I meant by
"question". What I meant was that during a review I would would see a
patch changing this to comply with the bindings and think nothing of it,
not that removing it was a unquestionably correct thing to do.

> So part of the problem I see here is that legacy platforms (which to me
> is a large chunk of 32bit ARM) are trickier. I'm not asking for anything
> more to be done in this example to be clear (I think the new panel-dpi
> binding is what U-Boot needs to implement and solve the issue here).
> 
> But I don't think the fact that the old binding was handled
> suboptimally means that its usage should be ignored.

What often happens is that Linux retains support for the old way of
doing things but the dts is updated to the documented way. I'm not
really sure how to deal with this kind of thing, other than being extra
diligent about reviewing cleanup work that may impact other users of the
dts sources and letting the linux platform maintainers know if something
gets broken in U-Boot.

> They were added in
> 2017 which is after they were deprecated and not caught then. I consider
> that to mean it was still valid.

I don't agree that that makes it valid, but I can see how it would be
assumed to be valid by other users of the dts file.

> And I also assume that today we have
> the tooling to catch that and not let it in, in the first place.

Unfortunately, not really. The tooling is capable of spotting these
things, but it totally depends on the effort people have put in to
that platform as to whether or not the single to noise ratio actually
allows a maintainer to spot when these things are introduced.
The RISC-V platforms, Samsung and some others have really good
compliance, but other platforms like aspeed or at91 have so many
warnings etc that it is very very difficult for the platform maintainers
to actually spot things like these being added.

> Time will tell now how bumpy a ride things end up being as I do agree
> that getting all the DTS files following the ABI correctly is an
> important goal.

Fixing up a platform is utterly mind-numbing work that requires
understanding datasheets and bindings for really varied hardware, so
it's best done by either the platform maintainers or piecemeal by people
that want to improve one particular board. It's gonna take a long time
to get "all" files following the ABI, particularly away from the ones
the linux dt-maintainers take more of an interest in.
Next time we get a new grad starting I might subject them to some
cleanup activities, they'll have to learn about dt at some point anyway
;)

Sorta unrelated to the above, but related to the OF_UPSTREAM stuff is
that I do notice a bit of an attitude of "U-Boot bundles the dtb with
the binary, so it's okay to break U-Boot because they have a copy of
the old dts and we can update both code and dts at the same time in
the 'future'". I can't cite anything off the top of my head, but I've
not been reviewing binding patches for all that long and it has been
said multiple times.
I'm not entirely sure how to handle that sort of situation, "force" the
submitter to send patches to U-Boot before I ack the binding?

I do skim all the patch subjects that get sent 

Re: [PATCH] mtd: rawnand: stm32_fmc2: add MP25 support

[Patrice CHOTARD]

On 3/6/24 10:54, Christophe Kerello wrote:
> FMC2 IP supports up to 4 chip select. On MP1 SoC, only 2 of them are
> available when on MP25 SoC, the 4 chip select are available.
> 
> Let's use a platform data structure for parameters that will differ.
> 
> Signed-off-by: Christophe Kerello 
> ---
> 
>  drivers/mtd/nand/raw/stm32_fmc2_nand.c | 47 ++
>  1 file changed, 40 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/mtd/nand/raw/stm32_fmc2_nand.c 
> b/drivers/mtd/nand/raw/stm32_fmc2_nand.c
> index 3528824575b..d284b8cbb12 100644
> --- a/drivers/mtd/nand/raw/stm32_fmc2_nand.c
> +++ b/drivers/mtd/nand/raw/stm32_fmc2_nand.c
> @@ -34,7 +34,7 @@
>  #define FMC2_RB_DELAY_US 30
>  
>  /* Max chip enable */
> -#define FMC2_MAX_CE  2
> +#define FMC2_MAX_CE  4
>  
>  /* Timings */
>  #define FMC2_THIZ1
> @@ -160,6 +160,11 @@ static inline struct stm32_fmc2_nand 
> *to_fmc2_nand(struct nand_chip *chip)
>   return container_of(chip, struct stm32_fmc2_nand, chip);
>  }
>  
> +struct stm32_fmc2_nfc_data {
> + int max_ncs;
> + struct udevice *(*get_cdev)(struct udevice *dev);
> +};
> +
>  struct stm32_fmc2_nfc {
>   struct nand_hw_control base;
>   struct stm32_fmc2_nand nand;
> @@ -169,6 +174,7 @@ struct stm32_fmc2_nfc {
>   fdt_addr_t cmd_base[FMC2_MAX_CE];
>   fdt_addr_t addr_base[FMC2_MAX_CE];
>   struct clk clk;
> + const struct stm32_fmc2_nfc_data *data;
>  
>   u8 cs_assigned;
>   int cs_sel;
> @@ -815,7 +821,7 @@ static int stm32_fmc2_nfc_parse_child(struct 
> stm32_fmc2_nfc *nfc, ofnode node)
>   }
>  
>   for (i = 0; i < nand->ncs; i++) {
> - if (cs[i] >= FMC2_MAX_CE) {
> + if (cs[i] >= nfc->data->max_ncs) {
>   log_err("Invalid reg value: %d\n", nand->cs_used[i]);
>   return -EINVAL;
>   }
> @@ -906,10 +912,18 @@ static int stm32_fmc2_nfc_probe(struct udevice *dev)
>   spin_lock_init(>controller.lock);
>   init_waitqueue_head(>controller.wq);
>  
> - cdev = stm32_fmc2_nfc_get_cdev(dev);
> - if (!cdev)
> + nfc->data = (void *)dev_get_driver_data(dev);
> + if (!nfc->data)
>   return -EINVAL;
>  
> + if (nfc->data->get_cdev) {
> + cdev = nfc->data->get_cdev(dev);
> + if (!cdev)
> + return -EINVAL;
> + } else {
> + cdev = dev->parent;
> + }
> +
>   ret = stm32_fmc2_nfc_parse_dt(dev, nfc);
>   if (ret)
>   return ret;
> @@ -921,7 +935,7 @@ static int stm32_fmc2_nfc_probe(struct udevice *dev)
>   if (dev == cdev)
>   start_region = 1;
>  
> - for (chip_cs = 0, mem_region = start_region; chip_cs < FMC2_MAX_CE;
> + for (chip_cs = 0, mem_region = start_region; chip_cs < 
> nfc->data->max_ncs;
>chip_cs++, mem_region += 3) {
>   if (!(nfc->cs_assigned & BIT(chip_cs)))
>   continue;
> @@ -1033,9 +1047,28 @@ static int stm32_fmc2_nfc_probe(struct udevice *dev)
>   return nand_register(0, mtd);
>  }
>  
> +static const struct stm32_fmc2_nfc_data stm32_fmc2_nfc_mp1_data = {
> + .max_ncs = 2,
> + .get_cdev = stm32_fmc2_nfc_get_cdev,
> +};
> +
> +static const struct stm32_fmc2_nfc_data stm32_fmc2_nfc_mp25_data = {
> + .max_ncs = 4,
> +};
> +
>  static const struct udevice_id stm32_fmc2_nfc_match[] = {
> - { .compatible = "st,stm32mp15-fmc2" },
> - { .compatible = "st,stm32mp1-fmc2-nfc" },
> + {
> + .compatible = "st,stm32mp15-fmc2",
> + .data = (ulong)_fmc2_nfc_mp1_data,
> + },
> + {
> + .compatible = "st,stm32mp1-fmc2-nfc",
> + .data = (ulong)_fmc2_nfc_mp1_data,
> + },
> + {
> + .compatible = "st,stm32mp25-fmc2-nfc",
> + .data = (ulong)_fmc2_nfc_mp25_data,
> + },
>   { /* Sentinel */ }
>  };
>  
Reviewed-by: Patrice Chotard 

Thanks
Patrice

Re: [PATCH v1 2/2] memory: stm32-fmc2-ebi: add MP25 RIF support

[Patrice CHOTARD]

On 3/6/24 10:50, Christophe Kerello wrote:
> The FMC2 revision 2 supports security and isolation compliant with
> the Resource Isolation Framework (RIF). From RIF point of view,
> the FMC2 is composed of several independent resources, listed below,
> which can be assigned to different security and compartment domains:
>  - 0: Common FMC_CFGR register.
>  - 1: EBI controller for Chip Select 1.
>  - 2: EBI controller for Chip Select 2.
>  - 3: EBI controller for Chip Select 3.
>  - 4: EBI controller for Chip Select 4.
>  - 5: NAND controller.
> 
> Signed-off-by: Christophe Kerello 
> ---
> 
>  drivers/memory/stm32-fmc2-ebi.c | 140 +++-
>  1 file changed, 138 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/memory/stm32-fmc2-ebi.c b/drivers/memory/stm32-fmc2-ebi.c
> index c7db16463e8..1ce96077858 100644
> --- a/drivers/memory/stm32-fmc2-ebi.c
> +++ b/drivers/memory/stm32-fmc2-ebi.c
> @@ -23,8 +23,14 @@
>  #define FMC2_BTR(x)  ((x) * 0x8 + FMC2_BTR1)
>  #define FMC2_PCSCNTR 0x20
>  #define FMC2_CFGR0x20
> +#define FMC2_SR  0x84
>  #define FMC2_BWTR1   0x104
>  #define FMC2_BWTR(x) ((x) * 0x8 + FMC2_BWTR1)
> +#define FMC2_SECCFGR 0x300
> +#define FMC2_CIDCFGR00x30c
> +#define FMC2_CIDCFGR(x)  ((x) * 0x8 + FMC2_CIDCFGR0)
> +#define FMC2_SEMCR0  0x310
> +#define FMC2_SEMCR(x)((x) * 0x8 + FMC2_SEMCR0)
>  
>  /* Register: FMC2_BCR1 */
>  #define FMC2_BCR1_CCLKEN BIT(20)
> @@ -67,8 +73,23 @@
>  #define FMC2_CFGR_CCLKEN BIT(20)
>  #define FMC2_CFGR_FMC2EN BIT(31)
>  
> +/* Register: FMC2_SR */
> +#define FMC2_SR_ISOSTGENMASK(1, 0)
> +
> +/* Register: FMC2_CIDCFGR */
> +#define FMC2_CIDCFGR_CFENBIT(0)
> +#define FMC2_CIDCFGR_SEMEN   BIT(1)
> +#define FMC2_CIDCFGR_SCIDGENMASK(6, 4)
> +#define FMC2_CIDCFGR_SEMWLC1 BIT(17)
> +
> +/* Register: FMC2_SEMCR */
> +#define FMC2_SEMCR_SEM_MUTEX BIT(0)
> +#define FMC2_SEMCR_SEMCIDGENMASK(6, 4)
> +
>  #define FMC2_MAX_EBI_CE  4
>  #define FMC2_MAX_BANKS   5
> +#define FMC2_MAX_RESOURCES   6
> +#define FMC2_CID11
>  
>  #define FMC2_BCR_CPSIZE_00x0
>  #define FMC2_BCR_CPSIZE_128  0x1
> @@ -163,6 +184,7 @@ struct stm32_fmc2_ebi_data {
>   u32 fmc2_enable_reg;
>   u32 fmc2_enable_bit;
>   int (*nwait_used_by_ctrls)(struct stm32_fmc2_ebi *ebi);
> + int (*check_rif)(struct stm32_fmc2_ebi *ebi, u32 resource);
>  };
>  
>  struct stm32_fmc2_ebi {
> @@ -170,6 +192,7 @@ struct stm32_fmc2_ebi {
>   fdt_addr_t io_base;
>   const struct stm32_fmc2_ebi_data *data;
>   u8 bank_assigned;
> + bool access_granted;
>  };
>  
>  /*
> @@ -241,6 +264,28 @@ static int stm32_fmc2_ebi_check_sync_trans(struct 
> stm32_fmc2_ebi *ebi,
>   return -EINVAL;
>  }
>  
> +static int stm32_fmc2_ebi_mp25_check_cclk(struct stm32_fmc2_ebi *ebi,
> +   const struct stm32_fmc2_prop *prop,
> +   int cs)
> +{
> + if (!ebi->access_granted)
> + return -EACCES;
> +
> + return stm32_fmc2_ebi_check_sync_trans(ebi, prop, cs);
> +}
> +
> +static int stm32_fmc2_ebi_mp25_check_clk_period(struct stm32_fmc2_ebi *ebi,
> + const struct stm32_fmc2_prop 
> *prop,
> + int cs)
> +{
> + u32 cfgr = readl(ebi->io_base + FMC2_CFGR);
> +
> + if (cfgr & FMC2_CFGR_CCLKEN && !ebi->access_granted)
> + return -EACCES;
> +
> + return stm32_fmc2_ebi_check_sync_trans(ebi, prop, cs);
> +}
> +
>  static int stm32_fmc2_ebi_check_async_trans(struct stm32_fmc2_ebi *ebi,
>   const struct stm32_fmc2_prop *prop,
>   int cs)
> @@ -960,7 +1005,7 @@ static const struct stm32_fmc2_prop 
> stm32_fmc2_mp25_child_props[] = {
>   .bprop = true,
>   .reg_type = FMC2_REG_CFGR,
>   .reg_mask = FMC2_CFGR_CCLKEN,
> - .check = stm32_fmc2_ebi_check_sync_trans,
> + .check = stm32_fmc2_ebi_mp25_check_cclk,
>   .set = stm32_fmc2_ebi_set_bit_field,
>   },
>   {
> @@ -1058,7 +1103,7 @@ static const struct stm32_fmc2_prop 
> stm32_fmc2_mp25_child_props[] = {
>   {
>   .name = "st,fmc2-ebi-cs-clk-period-ns",
>   .reset_val = FMC2_CFGR_CLKDIV_MAX + 1,
> - .check = stm32_fmc2_ebi_check_sync_trans,
> + .check = stm32_fmc2_ebi_mp25_check_clk_period,
>   .calculate = stm32_fmc2_ebi_ns_to_clock_cycles,
>   .set = stm32_fmc2_ebi_mp25_set_clk_period,
>   },
> @@ 

Re: [PATCH 0/4] Simplefb and fb reservation related updates

[Devarsh Thakkar]

Hi Tom, Anatolij, Simon,

On 22/02/24 18:38, Devarsh Thakkar wrote:
> This adds support for simple-framebuffer reservation using video handoff
> when splash is enabled at SPL stage.
> 
> Also adds helper function to only enable framebuffer reservation without
> enabling simple-framebuffer in case user want to continue display
> bootloader splash without displaying anything else in between until
> kernel boots up.
> 
> Lastly, it enables above support on AM62x.
> 

I saw a RB on first 3 patches so just wanted to check if it looks good to you
too then is it possible to pull in the first 3 patches if no further comments ?

Regards
Devarsh

> Devarsh Thakkar (4):
>   boot: fdt_simplefb: Enumerate framebuffer info from video handoff
>   video: Assume video to be active if SPL is passing video hand-off
>   boot: Move framebuffer reservation to separate helper
>   board: ti: am62x: evm: Update simple-framebuffer node in device-tree
> 
>  board/ti/am62x/evm.c | 19 +++
>  boot/fdt_simplefb.c  | 46 
>  boot/fdt_support.c   | 21 
>  drivers/video/video-uclass.c |  4 
>  include/fdt_support.h|  2 ++
>  5 files changed, 72 insertions(+), 20 deletions(-)
> 

Re: [PATCH v1 1/2] memory: stm32-fmc2-ebi: add MP25 support

[Patrice CHOTARD]

On 3/6/24 10:50, Christophe Kerello wrote:
> Add the support of the revision 2 of FMC2 IP.
>  - PCSCNTR register has been removed,
>  - CFGR register has been added,
>  - the bit used to enable the IP has moved from BCR1 to CFGR,
>  - the timeout for CEx deassertion has moved from PCSCNTR to BCRx,
>  - the continuous clock enable has moved from BCR1 to CFGR,
>  - the clk divide ratio has moved from BCR1 to CFGR.
> 
> The MP1 SoCs have only one signal to manage all the controllers (NWAIT).
> The MP25 SOC has one RNB signal for the NAND controller and one NWAIT
> signal for the memory controller.
> 
> Let's use a platform data structure for parameters that will differ
> between MP1 and MP25.
> 
> Signed-off-by: Christophe Kerello 
> 
> ---
> 
>  drivers/memory/stm32-fmc2-ebi.c | 313 ++--
>  1 file changed, 301 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/memory/stm32-fmc2-ebi.c b/drivers/memory/stm32-fmc2-ebi.c
> index a722a3836f7..c7db16463e8 100644
> --- a/drivers/memory/stm32-fmc2-ebi.c
> +++ b/drivers/memory/stm32-fmc2-ebi.c
> @@ -22,6 +22,7 @@
>  #define FMC2_BCR(x)  ((x) * 0x8 + FMC2_BCR1)
>  #define FMC2_BTR(x)  ((x) * 0x8 + FMC2_BTR1)
>  #define FMC2_PCSCNTR 0x20
> +#define FMC2_CFGR0x20
>  #define FMC2_BWTR1   0x104
>  #define FMC2_BWTR(x) ((x) * 0x8 + FMC2_BWTR1)
>  
> @@ -44,6 +45,7 @@
>  #define FMC2_BCR_ASYNCWAIT   BIT(15)
>  #define FMC2_BCR_CPSIZE  GENMASK(18, 16)
>  #define FMC2_BCR_CBURSTRWBIT(19)
> +#define FMC2_BCR_CSCOUNT GENMASK(21, 20)
>  #define FMC2_BCR_NBLSET  GENMASK(23, 22)
>  
>  /* Register: FMC2_BTRx/FMC2_BWTRx */
> @@ -60,6 +62,11 @@
>  #define FMC2_PCSCNTR_CSCOUNT GENMASK(15, 0)
>  #define FMC2_PCSCNTR_CNTBEN(x)   BIT((x) + 16)
>  
> +/* Register: FMC2_CFGR */
> +#define FMC2_CFGR_CLKDIV GENMASK(19, 16)
> +#define FMC2_CFGR_CCLKEN BIT(20)
> +#define FMC2_CFGR_FMC2EN BIT(31)
> +
>  #define FMC2_MAX_EBI_CE  4
>  #define FMC2_MAX_BANKS   5
>  
> @@ -76,6 +83,11 @@
>  #define FMC2_BCR_MTYP_PSRAM  0x1
>  #define FMC2_BCR_MTYP_NOR0x2
>  
> +#define FMC2_BCR_CSCOUNT_0   0x0
> +#define FMC2_BCR_CSCOUNT_1   0x1
> +#define FMC2_BCR_CSCOUNT_64  0x2
> +#define FMC2_BCR_CSCOUNT_256 0x3
> +
>  #define FMC2_BXTR_EXTMOD_A   0x0
>  #define FMC2_BXTR_EXTMOD_B   0x1
>  #define FMC2_BXTR_EXTMOD_C   0x2
> @@ -90,6 +102,7 @@
>  #define FMC2_BTR_CLKDIV_MAX  0xf
>  #define FMC2_BTR_DATLAT_MAX  0xf
>  #define FMC2_PCSCNTR_CSCOUNT_MAX 0xff
> +#define FMC2_CFGR_CLKDIV_MAX 0xf
>  
>  enum stm32_fmc2_ebi_bank {
>   FMC2_EBI1 = 0,
> @@ -103,7 +116,8 @@ enum stm32_fmc2_ebi_register_type {
>   FMC2_REG_BCR = 1,
>   FMC2_REG_BTR,
>   FMC2_REG_BWTR,
> - FMC2_REG_PCSCNTR
> + FMC2_REG_PCSCNTR,
> + FMC2_REG_CFGR
>  };
>  
>  enum stm32_fmc2_ebi_transaction_type {
> @@ -134,9 +148,27 @@ enum stm32_fmc2_ebi_cpsize {
>   FMC2_CPSIZE_1024 = 1024
>  };
>  
> +enum stm32_fmc2_ebi_cscount {
> + FMC2_CSCOUNT_0 = 0,
> + FMC2_CSCOUNT_1 = 1,
> + FMC2_CSCOUNT_64 = 64,
> + FMC2_CSCOUNT_256 = 256
> +};
> +
> +struct stm32_fmc2_ebi;
> +
> +struct stm32_fmc2_ebi_data {
> + const struct stm32_fmc2_prop *child_props;
> + unsigned int nb_child_props;
> + u32 fmc2_enable_reg;
> + u32 fmc2_enable_bit;
> + int (*nwait_used_by_ctrls)(struct stm32_fmc2_ebi *ebi);
> +};
> +
>  struct stm32_fmc2_ebi {
>   struct clk clk;
>   fdt_addr_t io_base;
> + const struct stm32_fmc2_ebi_data *data;
>   u8 bank_assigned;
>  };
>  
> @@ -296,6 +328,24 @@ static u32 stm32_fmc2_ebi_ns_to_clk_period(struct 
> stm32_fmc2_ebi *ebi,
>   return DIV_ROUND_UP(nb_clk_cycles, clk_period);
>  }
>  
> +static u32 stm32_fmc2_ebi_mp25_ns_to_clk_period(struct stm32_fmc2_ebi *ebi,
> + int cs, u32 setup)
> +{
> + u32 nb_clk_cycles = stm32_fmc2_ebi_ns_to_clock_cycles(ebi, cs, setup);
> + u32 cfgr = readl(ebi->io_base + FMC2_CFGR);
> + u32 clk_period;
> +
> + if (cfgr & FMC2_CFGR_CCLKEN) {
> + clk_period = FIELD_GET(FMC2_CFGR_CLKDIV, cfgr) + 1;
> + } else {
> + u32 btr = readl(ebi->io_base + FMC2_BTR(cs));
> +
> + clk_period = FIELD_GET(FMC2_BTR_CLKDIV, btr) + 1;
> + }
> +
> + return DIV_ROUND_UP(nb_clk_cycles, clk_period);
> +}
> +
>  static int stm32_fmc2_ebi_get_reg(int reg_type, int cs, u32 *reg)
>  {
>   switch (reg_type) {
> @@ -311,6 +361,9 @@ static int stm32_fmc2_ebi_get_reg(int reg_type, int cs, 
> u32 *reg)
>   case FMC2_REG_PCSCNTR:
>   *reg = FMC2_PCSCNTR;
>   break;
> + case FMC2_REG_CFGR:
> +  

Re: [PATCH 4/4] rockchip: Migrate to use DM_USB_GADGET on RK3328

[Jonas Karlman]

Hi Kever,

On 2024-03-08 10:29, Kever Yang wrote:
> 
> On 2024/2/27 07:08, Jonas Karlman wrote:
>> USB gadget is not working fully as expected on RK3328, it uses a
>> board_usb_init() function to initialize the DWC2 OTG port.
>>
>> The board_usb_init() function does not intgrate with the generic phy
>> framework and as a result the USB phy is not properly configured before
>> or after USB gadget use.
>>
>> Having both USB_DWC2 and DWC2_OTG enabled for the same board is also
>> causing some issues.
>>
>> Trying to use rockusb or ums command after usb stop result in a freeze
>> due to usb stop is putting the phy in a suspended state.
>>
>>=> usb start
>>=> usb stop
>>=> ums 0 mmc 0
>>--> freeze due to usb phy is suspended <--
>>
>> Fix this by only using one of USB_DWC2 (host) or DWC2_OTG (peripheral)
>> depending on the most likely usage of the otg port.
>>
>> The nanopi-r2 and orangepi-r1-plus variants share OTG and power using a
>> Type-C connector, mark these boards dr_mode as peripheral, the most
>> likely usage is for recovery and image download.
>>
>> The rock64 and roc-cc currently use dr_mode as host, remove the DWC2_OTG
>> driver from these boards to ensure that the USB_DWC2 driver is used.
>>
>> The rock-pi-e board does not enable the usb20_otg node so both USB_DWC2
>> and DWC2_OTG is removed from this board.
>>
>> Enable RockUSB and UMS on all boards with a otg port in peripheral mode.
>>
>> Also with the migration to DM_USB_GADGET completed the U-Boot specific
>> change to reorder usb nodes in the device tree can be reverted.
>>
>> Signed-off-by: Jonas Karlman 
> Reviewed-by: Kever Yang 

Thanks, I will send a v2 of this patch, that will change to use
XHCI_DWC3 for USB 3.0 host mode instead of DWC3_GENERIC to avoid
generating a build error with dependent patch [1] being rejected.

[1] https://patchwork.ozlabs.org/patch/1903946/

Regards,
Jonas

> 
> Thanks,
> - Kever

[snip]

Re: [PATCH 1/4] rockchip: Update the default USB Product ID value

[Jonas Karlman]

Hi Kever,

On 2024-03-08 10:22, Kever Yang wrote:
> Hi Jonas,
> 
>      Thanks for your patch.
> 
> On 2024/2/27 07:08, Jonas Karlman wrote:
>> RK3036 is using the USB product id normally used by RK3066B, and RK3328
>> is using the product id normally used by RK3368.
>>
>> Fix this and update the default USB_GADGET_PRODUCT_NUM Kconfig option
>> for remaining supported Rockchip SoCs to match the product id used in
>> Mask ROM mode. Also remove a reference to the unknown ROCKCHIP_RK3229
>> symbol.
> 
> RK3229 belongs to RK322X which is reuse with RK3228.
> 
> Note that this ID is used for rockusb gadget, if work as mass storage, 
> it should use other
> 
> ID, or else it will confuse the driver in host side, eg. the Windows 
> driver may not able to
> 
> recognize the device if using two different gadget type with the same ID.

Patch 3 in this series will change to use 0x0010 product id when ums
mode is enabled and fall back to use the USB_GADGET_PRODUCT_NUM for any
other gadget mode.

The ROCKCHIP_RK3229 symbol is not defined or used anywhere U-Boot so the
change in this patch to remove it from the condition should have no
impact. If RK3229 need a special product id separate from 0x320b used by
ROCKCHIP_RK322X, it can be defined in the defconfig for such board.

I tested this on Windows with rockusb and ums on RK3308, RK3328, RK3399
RK356x and RK3588 boards, switching between ums and rockusb should work
as intended, rockusb driver was used in rockusb mode and in ums mode the
device would show up as a disk.

  => rockusb 0 mmc 1
  => ums 0 mmc 1

I think all product id below is correct, but I have not been able to
runtime validate for other SoCs then the ones listed above.

Regards,
Jonas

> 
> 
> Thanks,
> - Kever
>>
>> Signed-off-by: Jonas Karlman 
>> ---
>>   drivers/usb/gadget/Kconfig | 15 ---
>>   1 file changed, 12 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
>> index c72a8047635c..4621a6fd5e64 100644
>> --- a/drivers/usb/gadget/Kconfig
>> +++ b/drivers/usb/gadget/Kconfig
>> @@ -70,12 +70,21 @@ config USB_GADGET_PRODUCT_NUM
>>  hex "Product ID of the USB device"
>>  default 0x701a if ARCH_TEGRA
>>  default 0x1010 if ARCH_SUNXI
>> -default 0x310a if ROCKCHIP_RK3036
>> +default 0x110a if ROCKCHIP_RV1108
>> +default 0x110b if ROCKCHIP_RV1126
>>  default 0x300a if ROCKCHIP_RK3066
>> +default 0x301a if ROCKCHIP_RK3036
>> +default 0x310b if ROCKCHIP_RK3188
>>  default 0x310c if ROCKCHIP_RK3128
>> -default 0x320a if ROCKCHIP_RK3229 || ROCKCHIP_RK3288
>> -default 0x330a if ROCKCHIP_RK3328
>> +default 0x320a if ROCKCHIP_RK3288
>> +default 0x320b if ROCKCHIP_RK322X
>> +default 0x320c if ROCKCHIP_RK3328
>> +default 0x330a if ROCKCHIP_RK3368
>>  default 0x330c if ROCKCHIP_RK3399
>> +default 0x330d if ROCKCHIP_PX30
>> +default 0x330e if ROCKCHIP_RK3308
>> +default 0x350a if ROCKCHIP_RK3568
>> +default 0x350b if ROCKCHIP_RK3588
>>  default 0x0
>>  help
>>Product ID of the USB device emulated, reported to the host device.

Re: [PATCH] arm: stm32: Enable OHCI HCD support on STM32MP15xx DHSOM

[Patrice CHOTARD]

On 3/4/24 19:25, Marek Vasut wrote:
> The OHCI HCD is mandatory for USB 1.1 FS/LS device support, enable it.
> This used to be enabled implicitly before, now that implicit dependency
> disappeared and this got disabled. Enable it manually.
> 
> Signed-off-by: Marek Vasut 
> ---
> Cc: Patrice Chotard 
> Cc: Patrick Delaunay 
> Cc: u-b...@dh-electronics.com
> Cc: uboot-st...@st-md-mailman.stormreply.com
> ---
>  configs/stm32mp15_dhcom_basic_defconfig | 2 ++
>  configs/stm32mp15_dhcor_basic_defconfig | 2 ++
>  2 files changed, 4 insertions(+)
> 
> diff --git a/configs/stm32mp15_dhcom_basic_defconfig 
> b/configs/stm32mp15_dhcom_basic_defconfig
> index 1d241529be7..0bfd3b76d6a 100644
> --- a/configs/stm32mp15_dhcom_basic_defconfig
> +++ b/configs/stm32mp15_dhcom_basic_defconfig
> @@ -164,6 +164,8 @@ CONFIG_DM_USB_GADGET=y
>  CONFIG_SPL_DM_USB_GADGET=y
>  CONFIG_USB_EHCI_HCD=y
>  CONFIG_USB_EHCI_GENERIC=y
> +CONFIG_USB_OHCI_HCD=y
> +CONFIG_USB_OHCI_GENERIC=y
>  CONFIG_USB_DWC2=y
>  CONFIG_USB_HOST_ETHER=y
>  CONFIG_USB_ETHER_ASIX=y
> diff --git a/configs/stm32mp15_dhcor_basic_defconfig 
> b/configs/stm32mp15_dhcor_basic_defconfig
> index 6e0c4a8cf9f..1c1fbc5c7db 100644
> --- a/configs/stm32mp15_dhcor_basic_defconfig
> +++ b/configs/stm32mp15_dhcor_basic_defconfig
> @@ -164,6 +164,8 @@ CONFIG_DM_USB_GADGET=y
>  CONFIG_SPL_DM_USB_GADGET=y
>  CONFIG_USB_EHCI_HCD=y
>  CONFIG_USB_EHCI_GENERIC=y
> +CONFIG_USB_OHCI_HCD=y
> +CONFIG_USB_OHCI_GENERIC=y
>  CONFIG_USB_DWC2=y
>  CONFIG_USB_HOST_ETHER=y
>  CONFIG_USB_ETHER_ASIX=y


Reviewed-by: Patrice Chotard 

Thanks
Patrice

Re: [PATCH] stm32mp: cmd_stm32prog: add dependencies with USB_GADGET_DOWNLOAD

[Patrice CHOTARD]

On 2/7/24 14:12, Patrick Delaunay wrote:
> This patch avoids compilation issue when CONFIG_USB_GADGET is deactivated
> in defconfig, with undefined reference to run_usb_dnl_gadget and to
> g_dnl_set_product.
> 
> Signed-off-by: Patrick Delaunay 
> ---
> 
>  arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig 
> b/arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig
> index 8f91db4b46b9..589276282e44 100644
> --- a/arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig
> +++ b/arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig
> @@ -17,6 +17,7 @@ config CMD_STM32PROG
>  config CMD_STM32PROG_USB
>   bool "support stm32prog over USB"
>   depends on CMD_STM32PROG
> + depends on USB_GADGET_DOWNLOAD
>   default y
>   help
>   activate the command "stm32prog usb" for STM32MP soc family

Reviewed-by: Patrice Chotard 

Thanks
Patrice

[PATCH] stm32mp: Reserve OPTEE area in EFI memory map

[Patrice Chotard]

Since commit 7b78d6438a2b3 ("efi_loader: Reserve unaccessible memory")
memory region above ram_top is tagged in EFI memory map as
EFI_BOOT_SERVICES_DATA.
In case of STM32MP1 platform, above ram_top, there is one reserved-memory
region tagged "no-map" dedicated to OP-TEE (addr=de00 size=200).

Before booting kernel, EFI memory map is first built, the OPTEE region is
tagged as EFI_BOOT_SERVICES_DATA and when reserving LMB, the tag LMB_NONE
is used.

Then after, the LMB are completed by boot_fdt_add_mem_rsv_regions()
which try to add again the same OPTEE region (addr=de00 size=200)
but now with LMB_NOMAP tag which produces the following error message :

"ERROR: reserving fdt memory region failed (addr=de00 size=200 flags=4)"

To avoid this, OPTEE area shouldn't be used by EFI, so we need to mark
it as reserved.

Signed-off-by: Patrice Chotard 
---

 arch/arm/mach-stm32mp/dram_init.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/mach-stm32mp/dram_init.c 
b/arch/arm/mach-stm32mp/dram_init.c
index fb1208fc5d5..f67f54f2ae0 100644
--- a/arch/arm/mach-stm32mp/dram_init.c
+++ b/arch/arm/mach-stm32mp/dram_init.c
@@ -7,6 +7,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -75,3 +76,14 @@ phys_addr_t board_get_usable_ram_top(phys_size_t total_size)
 
return reg + size;
 }
+
+void efi_add_known_memory(void)
+{
+   if (IS_ENABLED(CONFIG_EFI_LOADER))
+   /*
+* Memory over ram_top is reserved to OPTEE.
+* Declare to EFI only memory area below ram_top
+*/
+   efi_add_memory_map(gd->ram_base, gd->ram_top - gd->ram_base,
+  EFI_CONVENTIONAL_MEMORY);
+}
-- 
2.25.1

Re: [PATCH v3 20/20] rockchip: ringneck_px30: update website link

[Kever Yang]

On 2024/2/21 18:37, Quentin Schulz wrote:

From: Quentin Schulz 

The original link returns a custom 404, so let's point to a link that
works today instead.

Cc: Quentin Schulz 
Signed-off-by: Quentin Schulz 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  board/theobroma-systems/ringneck_px30/MAINTAINERS | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/theobroma-systems/ringneck_px30/MAINTAINERS 
b/board/theobroma-systems/ringneck_px30/MAINTAINERS
index 601830fe45b..97baf334d02 100644
--- a/board/theobroma-systems/ringneck_px30/MAINTAINERS
+++ b/board/theobroma-systems/ringneck_px30/MAINTAINERS
@@ -8,4 +8,4 @@ F:  doc/board/theobroma-systems/
  F:include/configs/ringneck_px30.h
  F:arch/arm/dts/px30-ringneck*
  F:configs/ringneck-px30_defconfig
-W: https://www.theobroma-systems.com/px30-uq7#tech-spec
+W: https://theobroma-systems.com/product/ringneck-som-px30-uq7/

Re: [PATCH v3 19/20] rockchip: ringneck_px30: migrate README to doc/board in rST format

[Kever Yang]

On 2024/2/21 18:37, Quentin Schulz wrote:

From: Quentin Schulz 

This migrates the plaintext README in
board/theobroma-systems/ringneck_px30 to doc/board/theobroma-systems and
while doing so, update the instructions and rewrite it in rST.

Cc: Quentin Schulz 
Signed-off-by: Quentin Schulz 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  board/theobroma-systems/ringneck_px30/MAINTAINERS |  1 +
  board/theobroma-systems/ringneck_px30/README  | 70 +
  doc/board/theobroma-systems/index.rst |  1 +
  doc/board/theobroma-systems/ringneck_px30.rst | 95 +++
  4 files changed, 98 insertions(+), 69 deletions(-)

diff --git a/board/theobroma-systems/ringneck_px30/MAINTAINERS 
b/board/theobroma-systems/ringneck_px30/MAINTAINERS
index 06e1beaab14..601830fe45b 100644
--- a/board/theobroma-systems/ringneck_px30/MAINTAINERS
+++ b/board/theobroma-systems/ringneck_px30/MAINTAINERS
@@ -4,6 +4,7 @@ M:  Klaus Goger 
  S:Maintained
  F:board/theobroma-systems/ringneck_px30
  F:board/theobroma-systems/common
+F: doc/board/theobroma-systems/
  F:include/configs/ringneck_px30.h
  F:arch/arm/dts/px30-ringneck*
  F:configs/ringneck-px30_defconfig
diff --git a/board/theobroma-systems/ringneck_px30/README 
b/board/theobroma-systems/ringneck_px30/README
index e756b3a8ffc..915baf4a9a0 100644
--- a/board/theobroma-systems/ringneck_px30/README
+++ b/board/theobroma-systems/ringneck_px30/README
@@ -1,69 +1 @@
-Introduction
-
-
-The PX30-uQ7 (Ringneck) SoM is a µQseven-compatible (40mmx70mm, MXM-230
-connector) system-on-module from Theobroma Systems[1], featuring the
-Rockchip PX30.
-
-It provides the following feature set:
-  * up to 4GB DDR4
-  * up to 128GB on-module eMMC (with 8-bit 1.8V interface)
-  * SD card (on a baseboard) via edge connector
-  * Fast Ethernet with on-module TI DP83825I PHY
-  * MIPI-DSI/LVDS
-  * MIPI-CSI
-  * USB
-- 1x USB 2.0 dual-role
-- 3x USB 2.0 host
-  * on-module companion controller (STM32 Cortex-M0 or ATtiny), implementing:
-- low-power RTC functionality (ISL1208 emulation)
-- fan controller (AMC6821 emulation)
-- USB<->CAN bridge controller (STM32 only)
-  * on-module Espressif ESP32 for Bluetooth + 2.4GHz WiFi
-  * on-module NXP SE05x Secure Element
-
-Here is the step-by-step to boot to U-Boot on px30.
-
-Get the Source and build ATF binary
-===
-
-  > git clone https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git
-
-Compile the ATF
-===
-
-  > cd trusted-firmware-a
-  > make CROSS_COMPILE=aarch64-linux-gnu- PLAT=px30 bl31
-  > cp build/px30/release/bl31/bl31.elf ../u-boot/bl31.elf
-
-Compile the U-Boot
-==
-
-  > cd ../u-boot
-  > make CROSS_COMPILE=aarch64-linux-gnu- ringneck-px30_defconfig all
-
-Flash the image
-===
-
-Copy u-boot-rockchip.bin to offset 32k for SD/eMMC.
-
-SD-Card

-
-  > dd if=u-boot-rockchip.bin of=/dev/sdb seek=64
-
-eMMC
-
-
-rkdeveloptool allows to flash the on-board eMMC via the USB OTG interface with
-help of the Rockchip loader binary.
-
-  > git clone https://github.com/rockchip-linux/rkdeveloptool
-  > cd rkdeveloptool
-  > autoreconf -i && ./configure && make
-  > git clone https://github.com/rockchip-linux/rkbin.git
-  > cd rkbin
-  > ./tools/boot_merger RKBOOT/PX30MINIALL.ini
-  > cd ..
-  > ./rkdeveloptool db rkbin/px30_loader_v1.16.131.bin
-  > ./rkdeveloptool wl 64 ../u-boot-rockchip.bin
+See doc/board/theobroma-systems/ringneck_px30.rst.
diff --git a/doc/board/theobroma-systems/index.rst 
b/doc/board/theobroma-systems/index.rst
index 0720128ad52..b4da2616c37 100644
--- a/doc/board/theobroma-systems/index.rst
+++ b/doc/board/theobroma-systems/index.rst
@@ -8,3 +8,4 @@ Theobroma Systems
  
 jaguar_rk3588

 puma_rk3399
+   ringneck_px30
diff --git a/doc/board/theobroma-systems/ringneck_px30.rst 
b/doc/board/theobroma-systems/ringneck_px30.rst
new file mode 100644
index 000..c16b9ed17ed
--- /dev/null
+++ b/doc/board/theobroma-systems/ringneck_px30.rst
@@ -0,0 +1,95 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+PX30-uQ7 Ringneck
+=
+
+The PX30-uQ7 (Ringneck) SoM is a µQseven-compatible (40mmx70mm, MXM-230
+connector) system-on-module from Theobroma Systems, featuring the Rockchip 
PX30.
+
+It provides the following feature set:
+
+  * up to 4GB DDR4
+  * up to 128GB on-module eMMC (with 8-bit 1.8V interface)
+  * SD card (on a baseboard) via edge connector
+  * Fast Ethernet with on-module TI DP83825I PHY
+  * MIPI-DSI/LVDS
+  * MIPI-CSI
+  * USB
+
+- 1x USB 2.0 dual-role
+- 3x USB 2.0 host
+
+  * on-module companion controller (STM32 Cortex-M0 or ATtiny), implementing:
+
+- low-power RTC functionality (ISL1208 emulation)
+- fan controller (AMC6821 emulation)
+- USB<->CAN bridge controller (STM32 only)
+
+  * on-module Espressif ESP32 for Bluetooth + 2.4GHz WiFi
+  * on-module NXP SE05x Secure Element
+

Re: [PATCH v3 18/20] rockchip: rk3399-puma: migrate README to doc/board in rST format

[Kever Yang]

On 2024/2/21 18:37, Quentin Schulz wrote:

From: Quentin Schulz 

This migrates the plaintext README in
board/theobroma-systems/puma_rk3399 to doc/board/theobroma-systems and
while doing so, update the instructions and rewrite it in rST.

Cc: Quentin Schulz 
Signed-off-by: Quentin Schulz 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  board/theobroma-systems/puma_rk3399/MAINTAINERS |   1 +
  board/theobroma-systems/puma_rk3399/README  |  90 +
  doc/board/theobroma-systems/index.rst   |   1 +
  doc/board/theobroma-systems/puma_rk3399.rst | 126 
  4 files changed, 129 insertions(+), 89 deletions(-)

diff --git a/board/theobroma-systems/puma_rk3399/MAINTAINERS 
b/board/theobroma-systems/puma_rk3399/MAINTAINERS
index 23701b3f0ed..7e84a5be262 100644
--- a/board/theobroma-systems/puma_rk3399/MAINTAINERS
+++ b/board/theobroma-systems/puma_rk3399/MAINTAINERS
@@ -4,6 +4,7 @@ M:  Klaus Goger 
  S:Maintained
  F:board/theobroma-systems/puma_rk3399
  F:board/theobroma-systems/common
+F: doc/board/theobroma-systems
  F:include/configs/puma_rk3399.h
  F:arch/arm/dts/rk3399-puma*
  F:configs/puma-rk3399_defconfig
diff --git a/board/theobroma-systems/puma_rk3399/README 
b/board/theobroma-systems/puma_rk3399/README
index 649aa3c543d..39c9d618866 100644
--- a/board/theobroma-systems/puma_rk3399/README
+++ b/board/theobroma-systems/puma_rk3399/README
@@ -1,89 +1 @@
-Introduction
-
-
-The RK3399-Q7 (Puma) is a system-on-module featuring the Rockchip
-RK3399 in a Qseven-compatible form-factor.
-
-RK3399-Q7 features:
-   * CPU: ARMv8 64bit Big-Little architecture,
-   * Big: dual-core Cortex-A72
-   * Little: quad-core Cortex-A53
-   * IRAM: 200KB
-   * DRAM: 4GB-128MB dual-channel
-   * eMMC: onboard eMMC
-   * SD/MMC
-   * GbE (onboard Micrel KSZ9031) Gigabit ethernet PHY
-   * USB:
-   * USB3.0 dual role port
-   * 2x USB3.0 host, 1x USB2.0 host via onboard USB3.0 hub
-   * Display: HDMI/eDP/MIPI
-   * Camera: 2x CSI (one on the edge connector, one on the Q7 specified 
CSI ZIF)
-   * NOR Flash: onboard SPI NOR
-   * Companion Controller: onboard additional Cortex-M0 microcontroller
-   * RTC
-   * fan controller
-   * CAN
-
-Here is the step-by-step to boot to U-Boot on rk3399.
-
-Get the Source and build ATF binary
-===
-
-  > git clone https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git
-
-Compile the ATF
-===
-
-  > cd trusted-firmware-a
-  > make CROSS_COMPILE=aarch64-linux-gnu- PLAT=rk3399 bl31
-  > cp build/rk3399/release/bl31/bl31.elf ../u-boot/bl31.elf
-
-Compile the U-Boot
-==
-
-  > cd ../u-boot
-  > make CROSS_COMPILE=aarch64-linux-gnu- puma-rk3399_defconfig all
-
-Flash the image
-===
-
-Copy u-boot-rockchip.bin to offset 32k for SD/eMMC.
-Copy u-boot-rockchip-spi.bin to offset 0 for NOR-flash.
-
-SD-Card

-
-  > dd if=u-boot-rockchip.bin of=/dev/sdb seek=64
-
-eMMC
-
-
-rkdeveloptool allows to flash the on-board eMMC via the USB OTG interface with
-help of the Rockchip loader binary.
-
-  > git clone https://github.com/rockchip-linux/rkdeveloptool
-  > cd rkdeveloptool
-  > autoreconf -i && ./configure && make
-  > git clone https://github.com/rockchip-linux/rkbin.git
-  > cd rkbin
-  > ./tools/boot_merger RKBOOT/RK3399MINIALL.ini
-  > cd ..
-  > ./rkdeveloptool db rkbin/rk3399_loader_v1.25.126.bin
-  > ./rkdeveloptool wl 64 ../u-boot-rockchip.bin
-
-NOR-Flash
--
-
-rkdeveloptool allows to flash the on-board SPI via the USB OTG interface with
-help of the Rockchip loader binary.
-
-  > git clone https://github.com/rockchip-linux/rkdeveloptool
-  > cd rkdeveloptool
-  > autoreconf -i && ./configure && make
-  > git clone https://github.com/rockchip-linux/rkbin.git
-  > cd rkbin
-  > ./tools/boot_merger RKBOOT/RK3399MINIALL_SPINOR.ini
-  > cd ..
-  > ./rkdeveloptool db rkbin/rk3399_loader_spinor_v1.25.114.bin
-  > ./rkdeveloptool ef
-  > ./rkdeveloptool wl 0 ../u-boot-rockchip-spi.bin
+See doc/board/theobroma-systems/puma_rk3399.rst.
diff --git a/doc/board/theobroma-systems/index.rst 
b/doc/board/theobroma-systems/index.rst
index 945f7a2f976..0720128ad52 100644
--- a/doc/board/theobroma-systems/index.rst
+++ b/doc/board/theobroma-systems/index.rst
@@ -7,3 +7,4 @@ Theobroma Systems
 :maxdepth: 2
  
 jaguar_rk3588

+   puma_rk3399
diff --git a/doc/board/theobroma-systems/puma_rk3399.rst 
b/doc/board/theobroma-systems/puma_rk3399.rst
new file mode 100644
index 000..5bc6385e451
--- /dev/null
+++ b/doc/board/theobroma-systems/puma_rk3399.rst
@@ -0,0 +1,126 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+RK3399-Q7 Puma
+==
+
+The RK3399-Q7 (Puma) is a system-on-module featuring the Rockchip
+RK3399 in a Qseven-compatible form-factor.
+
+RK3399-Q7 features:
+
+ 

Re: [PATCH v3 17/20] rockchip: puma-rk3399: MAINTAINERS: use glob for dtses

[Kever Yang]

On 2024/2/21 18:37, Quentin Schulz wrote:

From: Quentin Schulz 

There are multiple Device Trees in U-Boot git repo for Puma, so let's
make the MAINTAINERS entry match them all.

Cc: Quentin Schulz 
Signed-off-by: Quentin Schulz 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  board/theobroma-systems/puma_rk3399/MAINTAINERS | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/theobroma-systems/puma_rk3399/MAINTAINERS 
b/board/theobroma-systems/puma_rk3399/MAINTAINERS
index 93f570fc4f9..23701b3f0ed 100644
--- a/board/theobroma-systems/puma_rk3399/MAINTAINERS
+++ b/board/theobroma-systems/puma_rk3399/MAINTAINERS
@@ -5,7 +5,7 @@ S:  Maintained
  F:board/theobroma-systems/puma_rk3399
  F:board/theobroma-systems/common
  F:include/configs/puma_rk3399.h
-F: arch/arm/dts/rk3399-puma.dts
+F: arch/arm/dts/rk3399-puma*
  F:configs/puma-rk3399_defconfig
  W:https://www.theobroma-systems.com/rk3399-q7/tech-specs
  T:git git://git.theobroma-systems.com/puma-u-boot.git

Re: [PATCH v3 16/20] board: rockchip: add Theobroma-Systems RK3588 Jaguar SBC

[Kever Yang]

On 2024/2/21 18:37, Quentin Schulz wrote:

From: Quentin Schulz 

JAGUAR is a Single-Board Computer (SBC) based around the rk3588 SoC and
is targeting Autonomous Mobile Robots (AMR).

It features:
  * LPDDR4X (up to 16GB)
  * 1Gbps Ethernet on RJ45 connector (KSZ9031 or KSZ9131)
  * PCIe 3.0 4-lane on M.2 M-key connector
  * PCIe 2.1 1-lane on M.2 E-key
  * USB 2.0 on M.2 E-key
  * 2x USB3 OTG type-c ports with DP Alt-Mode
  * USB2 host port
  * HDMI output
  * 2x camera connectors, each exposing:
* 2-lane MIPI-CSI
* 1v2, 1v8, 2v8 power rails
* I2C bus
* GPIOs
  * PPS input
  * CAN
  * RS485 UART
  * FAN connector
  * SD card slot
  * eMMC (up to 256GB)
  * RTC backup battery
  * Companion microcontroller
* ISL1208 RTC emulation
* AMC6821 PWM emulation
* On/off buzzer control
  * Secure Element
  * 80-pin Mezzanine connector for daughterboards:
* GPIOs
* 1Gbps Ethernet
* PCIe 2.1 1-lane
* 2x 2-lane MIPI-CSI
* ADC channel
* I2C bus
* PWM
* UART
* SPI
* SDIO
* CAN
* I2S
* 1v8, 3v3, 5v0, dc-in (12-24V) power rails

The Device Tree comes from next-20240110 Linux kernel.

Cc: Quentin Schulz 
Signed-off-by: Quentin Schulz 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  arch/arm/dts/Makefile  |   1 +
  arch/arm/dts/rk3588-jaguar-u-boot.dtsi |  33 +
  arch/arm/dts/rk3588-jaguar.dts | 803 +
  arch/arm/mach-rockchip/rk3588/Kconfig  |  28 +
  board/theobroma-systems/jaguar_rk3588/Kconfig  |  16 +
  board/theobroma-systems/jaguar_rk3588/MAINTAINERS  |  13 +
  board/theobroma-systems/jaguar_rk3588/Makefile |  10 +
  .../jaguar_rk3588/jaguar_rk3588.c  |  53 ++
  configs/jaguar-rk3588_defconfig| 114 +++
  doc/board/index.rst|   1 +
  doc/board/rockchip/rockchip.rst|   1 +
  doc/board/theobroma-systems/index.rst  |   9 +
  doc/board/theobroma-systems/jaguar_rk3588.rst  | 100 +++
  include/configs/jaguar_rk3588.h|  15 +
  14 files changed, 1197 insertions(+)

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index d9725030d5a..dbca55f06e5 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -194,6 +194,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3588) += \
rk3588-edgeble-neu6a-io.dtb \
rk3588-edgeble-neu6b-io.dtb \
rk3588-evb1-v10.dtb \
+   rk3588-jaguar.dtb \
rk3588-nanopc-t6.dtb \
rk3588s-orangepi-5.dtb \
rk3588-orangepi-5-plus.dtb \
diff --git a/arch/arm/dts/rk3588-jaguar-u-boot.dtsi 
b/arch/arm/dts/rk3588-jaguar-u-boot.dtsi
new file mode 100644
index 000..dcda4f99d6e
--- /dev/null
+++ b/arch/arm/dts/rk3588-jaguar-u-boot.dtsi
@@ -0,0 +1,33 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2023 Theobroma Systems Design und Consulting GmbH
+ */
+
+#include "rk3588-u-boot.dtsi"
+
+/ {
+   chosen {
+   u-boot,spl-boot-order = "same-as-spl", , 
+   };
+};
+
+_pwrseq {
+   bootph-pre-ram;
+   bootph-some-ram;
+};
+
+_reset {
+   bootph-pre-ram;
+   bootph-some-ram;
+};
+
+ {
+   bootph-pre-ram;
+   bootph-some-ram;
+};
+
+ {
+   /* U-Boot currently cannot handle anything below HS200 for eMMC on 
RK3588 */
+   /delete-property/ mmc-ddr-1_8v;
+   /delete-property/ cap-mmc-highspeed;
+};
diff --git a/arch/arm/dts/rk3588-jaguar.dts b/arch/arm/dts/rk3588-jaguar.dts
new file mode 100644
index 000..4ce70fb75a3
--- /dev/null
+++ b/arch/arm/dts/rk3588-jaguar.dts
@@ -0,0 +1,803 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2023 Theobroma Systems Design und Consulting GmbH
+ */
+
+/dts-v1/;
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "rk3588.dtsi"
+
+/ {
+   model = "Theobroma Systems RK3588-SBC Jaguar";
+   compatible = "tsd,rk3588-jaguar", "rockchip,rk3588";
+
+   adc-keys {
+   compatible = "adc-keys";
+   io-channels = < 0>;
+   io-channel-names = "buttons";
+   keyup-threshold-microvolt = <180>;
+   poll-interval = <100>;
+
+   /* Can be controlled through SW2 but also GPIO1 on CP2102 on 
P20 */
+   button-bios-disable {
+   label = "BIOS_DISABLE";
+   linux,code = ;
+   press-threshold-microvolt = <0>;
+   };
+   };
+
+   aliases {
+   ethernet0 = 
+   mmc0 = 
+   mmc1 = 
+   rtc0 = _twi;
+   };
+
+   chosen {
+   stdout-path = "serial2:115200n8";
+   };
+
+   /* DCIN is 12-24V but standard is 12V */
+   dc_12v: dc-12v-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "dc_12v";
+   regulator-always-on;
+   

Re: [PATCH v3 15/20] rockchip: rk3588: bind MMC controllers in U-Boot proper pre-reloc

[Kever Yang]

On 2024/2/21 18:37, Quentin Schulz wrote:

From: Quentin Schulz 

Since commit 9e644284ab81 ("dm: core: Report bootph-pre-ram/sram node as
pre-reloc after relocation"), bootph-pre-ram doesn't make U-Boot proper
bind the device before relocation.

While this is usually not much of an issue, it is when there's a lookup
for devices by code running before the relocation. Such is the case of
env_init() which calls env_driver_lookup() which calls
env_get_location() which is a weak symbol and may call
arch_env_get_location() also a weak symbol. Those are two functions that
may traverse UCLASS to find some devices (e.g.
board/theobroma-systems/common/common.c:arch_env_get_location()).

This allows something in the env_init() call stack to be able to use
uclasses for SD and eMMC controller on RK3588S/RK3588. This aligns the
behavior with what seems to be all SoCs except RK356x family.

Additionally, if any other env function (e.g. env_load) were to be used
before relocation, this is also required as otherwise it wouldn't be
able to find the MMC device(s).

Cc: Quentin Schulz 
Signed-off-by: Quentin Schulz 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  arch/arm/dts/rk3588s-u-boot.dtsi | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/arch/arm/dts/rk3588s-u-boot.dtsi b/arch/arm/dts/rk3588s-u-boot.dtsi
index bf3b1ea8a3c..ac67c777ade 100644
--- a/arch/arm/dts/rk3588s-u-boot.dtsi
+++ b/arch/arm/dts/rk3588s-u-boot.dtsi
@@ -188,11 +188,13 @@
  
   {

bootph-pre-ram;
+   bootph-some-ram;
u-boot,spl-fifo-mode;
  };
  
   {

bootph-pre-ram;
+   bootph-some-ram;
u-boot,spl-fifo-mode;
  };
  

Re: [PATCH v3 11/20] rockchip: rk3588: fix non-working SD controller if booting from other media

[Kever Yang]

Hi Quentin,

On 2024/2/21 18:37, Quentin Schulz wrote:

From: Quentin Schulz

Rockchip SoCs have some jtag/sdmmc autoswitching that simply doesn't
work really well.[00] The Linux kernel disables it for all SoCs[01], so
U-Boot needs to do the same in order to fix issues related to SD card on
RK3588. This autoswitching is enabled (by default) via the force_jtag
bitfield in SYS_GRF_SOC_CON6 in the TRM part1.

The conditions to enter forced JTAG mode are the following:
- force_jtag is 1
- GPIO4_D2 is muxed for SDMMC function
- GPIO3_D3 is muxed for SDMMC function
- SDMMC_DET is inactive


I have explain the reason and send fix for other boards  in kernel for 
why the force jtag


function not working correctly, see patch [1] and I copy the commit 
message here:


RK3588 has force_jtage feature which is enable JTAG function via sdmmc
pins automatically when there is no SD card insert, this feature will
need the GPIO0A4 works in sdmmc_det function like other mmc signal instead
of GPIO function, or else the force_jtag can not auto be disabled when
SD card insert.

For the rk3588 boards available on mainline kernel, 10 boards enable SD 
card function
and 9 of then use GPIO0A4 as sdmmc_det, they should all able to use the 
force_jtag after

my patch apply.
The jaguar-rk3588 still have the issue because there is no sdmmc_det used.
The condition of force JTAG mode work correctly is :
- force_jtag in grf is 1;
- all the SDMMC signal including SDMMC_DET set as SDMMC function in GRF 
IOC/IOMUX reg;


So please update the commit message and it would be better to move this 
setting in jaguar-rk3588 board
so that other board can enable force_jtag with only modify kernel but 
not both kernel and U-Boot.


Thanks,
- Kever

[1]https://lkml.org/lkml/2024/2/4/48



SDMMC_DET may be put in the inactive mode by HW design (e.g. because the
detection pin is unused (e.g. card-detect-less designs), or another GPIO
is used instead, and SDMMC_DET is pulled-low by default).

For some reason, when booting from SD card, everything's fine. But when
we don't boot from SD card, U-Boot needs to set it up correctly to allow
accessing SD cards, at the very least for RK3588-Jaguar
(card-detect-less design with SDMMC_DET pulled-low in HW).

Therefore, let's disable the JTAG mode for the SDMMC pins so that the SD
controller can be used either as a fallback mechanism to find U-Boot
proper when the boot medium used to load TPL/SPL cannot find U-Boot
proper, or to be used in U-Boot CLI.

Note that soc_con[0] is reserved. But considering that it's way more
user-friendly to access soc_con1 from the TRM with soc_con[1] than
soc_con[0], and that soc_con0 would actually be located at 4 bytes
before soc_con1, let's just make soc_con0 part of the soc_con array.

[00]https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c9b75d51c940c25587a2ad72ec7ec60490abfb6c
[01]https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/soc/rockchip/grf.c

Cc: Quentin Schulz
Signed-off-by: Quentin Schulz
---
  arch/arm/include/asm/arch-rockchip/grf_rk3588.h | 24 
  arch/arm/mach-rockchip/rk3588/rk3588.c  |  7 +++
  2 files changed, 31 insertions(+)

diff --git a/arch/arm/include/asm/arch-rockchip/grf_rk3588.h 
b/arch/arm/include/asm/arch-rockchip/grf_rk3588.h
index e0694068bb1..f0ecff97f0b 100644
--- a/arch/arm/include/asm/arch-rockchip/grf_rk3588.h
+++ b/arch/arm/include/asm/arch-rockchip/grf_rk3588.h
@@ -32,4 +32,28 @@ struct rk3588_pmu1grf {
  
  check_member(rk3588_pmu1grf, sd_detect_cnt, 0x03b0);
  
+#define SYS_GRF_BASE	0xfd58c000

+
+struct rk3588_sysgrf {
+   unsigned int wdt_con0;
+   unsigned int reserved0[(0x0010 - 0x) / 4 - 1];
+   unsigned int uart_con[2];
+   unsigned int reserved1[(0x00c0 - 0x0014) / 4 - 1];
+   unsigned int gic_con0;
+   unsigned int reserved2[(0x0200 - 0x00c0) / 4 - 1];
+   unsigned int memcfg_con[32];
+   unsigned int reserved3[(0x0300 - 0x027c) / 4 - 1];
+   /* soc_con0 is reserved */
+   unsigned int soc_con[14];
+   unsigned int reserved4[(0x0380 - 0x0334) / 4 - 1];
+   unsigned int soc_status[4];
+   unsigned int reserved5[(0x0500 - 0x038c) / 4 - 1];
+   unsigned int otp_key08;
+   unsigned int otp_key0d;
+   unsigned int otp_key0e;
+   unsigned int reserved6[(0x0600 - 0x0508) / 4 - 1];
+   unsigned int chip_id;
+};
+
+check_member(rk3588_sysgrf, chip_id, 0x0600);
  #endif /*__SOC_ROCKCHIP_RK3588_GRF_H__ */
diff --git a/arch/arm/mach-rockchip/rk3588/rk3588.c 
b/arch/arm/mach-rockchip/rk3588/rk3588.c
index 38e95a6e2b2..c5eeda9d751 100644
--- a/arch/arm/mach-rockchip/rk3588/rk3588.c
+++ b/arch/arm/mach-rockchip/rk3588/rk3588.c
@@ -11,6 +11,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #define FIREWALL_DDR_BASE		0xfe03

  #define FW_DDR_MST5_REG   0x54
@@ -35,6 +36,8 @@
  #define BUS_IOC_GPIO2D_IOMUX_SEL_H0x5c
  #define 

Re: [PATCH 4/4] rockchip: Migrate to use DM_USB_GADGET on RK3328

[Kever Yang]

On 2024/2/27 07:08, Jonas Karlman wrote:

USB gadget is not working fully as expected on RK3328, it uses a
board_usb_init() function to initialize the DWC2 OTG port.

The board_usb_init() function does not intgrate with the generic phy
framework and as a result the USB phy is not properly configured before
or after USB gadget use.

Having both USB_DWC2 and DWC2_OTG enabled for the same board is also
causing some issues.

Trying to use rockusb or ums command after usb stop result in a freeze
due to usb stop is putting the phy in a suspended state.

   => usb start
   => usb stop
   => ums 0 mmc 0
   --> freeze due to usb phy is suspended <--

Fix this by only using one of USB_DWC2 (host) or DWC2_OTG (peripheral)
depending on the most likely usage of the otg port.

The nanopi-r2 and orangepi-r1-plus variants share OTG and power using a
Type-C connector, mark these boards dr_mode as peripheral, the most
likely usage is for recovery and image download.

The rock64 and roc-cc currently use dr_mode as host, remove the DWC2_OTG
driver from these boards to ensure that the USB_DWC2 driver is used.

The rock-pi-e board does not enable the usb20_otg node so both USB_DWC2
and DWC2_OTG is removed from this board.

Enable RockUSB and UMS on all boards with a otg port in peripheral mode.

Also with the migration to DM_USB_GADGET completed the U-Boot specific
change to reorder usb nodes in the device tree can be reverted.

Signed-off-by: Jonas Karlman 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  arch/arm/dts/rk3328-nanopi-r2s-u-boot.dtsi|  4 ++
  .../rk3328-orangepi-r1-plus-lts-u-boot.dtsi   |  4 ++
  .../dts/rk3328-orangepi-r1-plus-u-boot.dtsi   |  4 ++
  arch/arm/dts/rk3328-roc-cc-u-boot.dtsi|  4 ++
  arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi |  9 
  arch/arm/dts/rk3328-rock64-u-boot.dtsi|  4 ++
  arch/arm/dts/rk3328-u-boot.dtsi   |  4 --
  arch/arm/dts/rk3328.dtsi  | 41 ---
  configs/evb-rk3328_defconfig  |  5 ++-
  configs/nanopi-r2c-plus-rk3328_defconfig  |  5 ++-
  configs/nanopi-r2c-rk3328_defconfig   |  5 ++-
  configs/nanopi-r2s-rk3328_defconfig   |  5 ++-
  configs/orangepi-r1-plus-lts-rk3328_defconfig |  5 ++-
  configs/orangepi-r1-plus-rk3328_defconfig |  5 ++-
  configs/roc-cc-rk3328_defconfig   |  7 
  configs/rock-pi-e-rk3328_defconfig|  7 
  configs/rock64-rk3328_defconfig   |  6 ---
  17 files changed, 69 insertions(+), 55 deletions(-)

diff --git a/arch/arm/dts/rk3328-nanopi-r2s-u-boot.dtsi 
b/arch/arm/dts/rk3328-nanopi-r2s-u-boot.dtsi
index cca4f06145cf..4fa170eeaf8d 100644
--- a/arch/arm/dts/rk3328-nanopi-r2s-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-nanopi-r2s-u-boot.dtsi
@@ -15,6 +15,10 @@
bootph-all;
  };
  
+_otg {

+   dr_mode = "peripheral";
+};
+
  _io_sdio {
bootph-pre-ram;
  };
diff --git a/arch/arm/dts/rk3328-orangepi-r1-plus-lts-u-boot.dtsi 
b/arch/arm/dts/rk3328-orangepi-r1-plus-lts-u-boot.dtsi
index 0dbe5a01f986..0a9423cd9c7e 100644
--- a/arch/arm/dts/rk3328-orangepi-r1-plus-lts-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-orangepi-r1-plus-lts-u-boot.dtsi
@@ -33,6 +33,10 @@
bootph-pre-ram;
  };
  
+_otg {

+   dr_mode = "peripheral";
+};
+
  _sd {
bootph-pre-ram;
  };
diff --git a/arch/arm/dts/rk3328-orangepi-r1-plus-u-boot.dtsi 
b/arch/arm/dts/rk3328-orangepi-r1-plus-u-boot.dtsi
index 1af75ada1a62..1096821fc5d3 100644
--- a/arch/arm/dts/rk3328-orangepi-r1-plus-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-orangepi-r1-plus-u-boot.dtsi
@@ -33,6 +33,10 @@
bootph-pre-ram;
  };
  
+_otg {

+   dr_mode = "peripheral";
+};
+
  _sd {
bootph-pre-ram;
  };
diff --git a/arch/arm/dts/rk3328-roc-cc-u-boot.dtsi 
b/arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
index 47d74964fd0c..582d6ba49b4e 100644
--- a/arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
@@ -29,6 +29,10 @@
};
  };
  
+_otg {

+   hnp-srp-disable;
+};
+
  _sd {
bootph-pre-ram;
  };
diff --git a/arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi 
b/arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi
index 9ed0aef1ecc9..d314bfad6fc0 100644
--- a/arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi
@@ -29,6 +29,15 @@
};
  };
  
+_host {

+   phy-supply = <_host_5v>;
+};
+
+_host_5v {
+   /delete-property/ regulator-always-on;
+   /delete-property/ regulator-boot-on;
+};
+
  _sd {
bootph-pre-ram;
  };
diff --git a/arch/arm/dts/rk3328-rock64-u-boot.dtsi 
b/arch/arm/dts/rk3328-rock64-u-boot.dtsi
index 85426495c3d8..551cff6f24f6 100644
--- a/arch/arm/dts/rk3328-rock64-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-rock64-u-boot.dtsi
@@ -55,6 +55,10 @@
bootph-pre-ram;
  };
  
+_otg {

+   hnp-srp-disable;
+};
+
  _sd {
bootph-pre-ram;
  };
diff --git a/arch/arm/dts/rk3328-u-boot.dtsi b/arch/arm/dts/rk3328-u-boot.dtsi
index 

Re: [PATCH 3/4] rockchip: board: Use a common USB Product ID for UMS

[Kever Yang]

On 2024/2/27 07:08, Jonas Karlman wrote:

Change to use the common Product ID 0x0010 when the ums command is used.

This matches downstream vendor U-Boot and is a Product ID that tools
such as rkdeveloptool and RKDevTool will identify as MSC mode.

Signed-off-by: Jonas Karlman 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  arch/arm/mach-rockchip/board.c | 17 -
  1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-rockchip/board.c b/arch/arm/mach-rockchip/board.c
index f84ff542aea9..e9cfba756639 100644
--- a/arch/arm/mach-rockchip/board.c
+++ b/arch/arm/mach-rockchip/board.c
@@ -221,8 +221,23 @@ void enable_caches(void)
  #endif
  
  #if IS_ENABLED(CONFIG_USB_GADGET)

-#if IS_ENABLED(CONFIG_USB_GADGET_DWC2_OTG) && !IS_ENABLED(CONFIG_DM_USB_GADGET)
  #include 
+
+#if IS_ENABLED(CONFIG_USB_GADGET_DOWNLOAD)
+#define ROCKCHIP_G_DNL_UMS_PRODUCT_NUM 0x0010
+
+int g_dnl_bind_fixup(struct usb_device_descriptor *dev, const char *name)
+{
+   if (!strcmp(name, "usb_dnl_ums"))
+   put_unaligned(ROCKCHIP_G_DNL_UMS_PRODUCT_NUM, >idProduct);
+   else
+   put_unaligned(CONFIG_USB_GADGET_PRODUCT_NUM, >idProduct);
+
+   return 0;
+}
+#endif /* CONFIG_USB_GADGET_DOWNLOAD */
+
+#if IS_ENABLED(CONFIG_USB_GADGET_DWC2_OTG) && !IS_ENABLED(CONFIG_DM_USB_GADGET)
  #include 
  #include 
  

Re: [PATCH 2/4] rockchip: board: Prepare for use of DM_USB_GADGET with DWC2_OTG

[Kever Yang]

On 2024/2/27 07:08, Jonas Karlman wrote:

The board_usb_init() and board_usb_cleanup() functions is always
included when USB_GADGET and USB_GADGET_DWC2_OTG is enabled.

Prepare for a change to use DM_USB_GADGET with DWC2_OTG by adding an
extra ifdef condition. The extra separate ifdef for USB_GADGET prepare
for next patch that adds a g_dnl_bind_fixup() function.

Signed-off-by: Jonas Karlman 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  arch/arm/mach-rockchip/board.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-rockchip/board.c b/arch/arm/mach-rockchip/board.c
index dea5805c4665..f84ff542aea9 100644
--- a/arch/arm/mach-rockchip/board.c
+++ b/arch/arm/mach-rockchip/board.c
@@ -220,7 +220,8 @@ void enable_caches(void)
  }
  #endif
  
-#if defined(CONFIG_USB_GADGET) && defined(CONFIG_USB_GADGET_DWC2_OTG)

+#if IS_ENABLED(CONFIG_USB_GADGET)
+#if IS_ENABLED(CONFIG_USB_GADGET_DWC2_OTG) && !IS_ENABLED(CONFIG_DM_USB_GADGET)
  #include 
  #include 
  #include 
@@ -296,6 +297,7 @@ int board_usb_cleanup(int index, enum usb_init_type init)
return 0;
  }
  #endif /* CONFIG_USB_GADGET_DWC2_OTG */
+#endif /* CONFIG_USB_GADGET */
  
  #if IS_ENABLED(CONFIG_FASTBOOT)

  int fastboot_set_reboot_flag(enum fastboot_reboot_reason reason)

Re: [PATCH 1/4] rockchip: Update the default USB Product ID value

[Kever Yang]

Hi Jonas,

    Thanks for your patch.

On 2024/2/27 07:08, Jonas Karlman wrote:

RK3036 is using the USB product id normally used by RK3066B, and RK3328
is using the product id normally used by RK3368.

Fix this and update the default USB_GADGET_PRODUCT_NUM Kconfig option
for remaining supported Rockchip SoCs to match the product id used in
Mask ROM mode. Also remove a reference to the unknown ROCKCHIP_RK3229
symbol.


RK3229 belongs to RK322X which is reuse with RK3228.

Note that this ID is used for rockusb gadget, if work as mass storage, 
it should use other


ID, or else it will confuse the driver in host side, eg. the Windows 
driver may not able to


recognize the device if using two different gadget type with the same ID.


Thanks,
- Kever


Signed-off-by: Jonas Karlman 
---
  drivers/usb/gadget/Kconfig | 15 ---
  1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index c72a8047635c..4621a6fd5e64 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -70,12 +70,21 @@ config USB_GADGET_PRODUCT_NUM
hex "Product ID of the USB device"
default 0x701a if ARCH_TEGRA
default 0x1010 if ARCH_SUNXI
-   default 0x310a if ROCKCHIP_RK3036
+   default 0x110a if ROCKCHIP_RV1108
+   default 0x110b if ROCKCHIP_RV1126
default 0x300a if ROCKCHIP_RK3066
+   default 0x301a if ROCKCHIP_RK3036
+   default 0x310b if ROCKCHIP_RK3188
default 0x310c if ROCKCHIP_RK3128
-   default 0x320a if ROCKCHIP_RK3229 || ROCKCHIP_RK3288
-   default 0x330a if ROCKCHIP_RK3328
+   default 0x320a if ROCKCHIP_RK3288
+   default 0x320b if ROCKCHIP_RK322X
+   default 0x320c if ROCKCHIP_RK3328
+   default 0x330a if ROCKCHIP_RK3368
default 0x330c if ROCKCHIP_RK3399
+   default 0x330d if ROCKCHIP_PX30
+   default 0x330e if ROCKCHIP_RK3308
+   default 0x350a if ROCKCHIP_RK3568
+   default 0x350b if ROCKCHIP_RK3588
default 0x0
help
  Product ID of the USB device emulated, reported to the host device.

Re: [PATCH v2 5/5] power: regulator: tps65941: Add TPS65224 PMIC regulator support

[Dhruva Gole]

Hi,

On Mar 06, 2024 at 19:09:47 +0530, Bhargav Raviprakash wrote:
> Reuse TPS65941 regulator driver to adds support for
> TPS65224 PMIC's regulators. 4 BUCKs and 3 LDOs, where
> BUCK1 and BUCK2 can be configured in dual phase mode.
> 
> Signed-off-by: Bhargav Raviprakash 
> ---
>  drivers/power/regulator/tps65941_regulator.c | 280 ++-
>  1 file changed, 267 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/power/regulator/tps65941_regulator.c 
> b/drivers/power/regulator/tps65941_regulator.c
> index d879c2301b..826bc0c63e 100644
> --- a/drivers/power/regulator/tps65941_regulator.c
> +++ b/drivers/power/regulator/tps65941_regulator.c
> @@ -37,6 +37,8 @@
>  
>  #define TPS65941_BUCK_CONV_OPS_IDX  0
>  #define TPS65941_LDO_CONV_OPS_IDX   0
> +#define TPS65224_LDO_CONV_OPS_IDX   1
> +#define TPS65224_BUCK_CONV_OPS_IDX  1
>  
>  struct tps65941_reg_conv_ops {
>   int volt_mask;
> @@ -55,6 +57,11 @@ static const char tps65941_ldo_ctrl[TPS65941_BUCK_NUM] = 
> {0x1D, 0x1E, 0x1F,
>  static const char tps65941_ldo_vout[TPS65941_BUCK_NUM] = {0x23, 0x24, 0x25,
>   0x26};
>  
> +static inline int tps65941_get_chip_id(struct udevice *dev)
> +{
> + return dev->parent->driver_data;
> +}
> +
>  static int tps65941_buck_enable(struct udevice *dev, int op, bool *enable)
>  {
>   int ret;
> @@ -146,6 +153,112 @@ int tps65941_lookup_slew(int id)
>   }
>  }
>  
> +static int tps65224_buck_volt2val(int idx, int uV)
> +{
> + /* This functions maps a value which is in micro Volts to the VSET 
> value.
> +  * The mapping is as per the datasheet of TPS65224.
> +  */
> +
> + if (uV > TPS65224_BUCK_VOLT_MAX)
> + return -EINVAL;
> +
> + if (idx > 0) {
> + /* Buck2, Buck3 and Buck4 of TPS65224 has a different schema in
> +  * converting b/w micro_volt and VSET hex values
> +  *
> +  * VSET value starts from 0x00 for 0.5V, and for every increment
> +  * in VSET value the output voltage increases by 25mV. This is 
> upto
> +  * 1.15V where VSET is 0x1A.
> +  *
> +  * For 0x1B the output voltage is 1.2V, and for every increment 
> of
> +  * VSET the output voltage increases by 50mV upto the max 
> voltage of
> +  * 3.3V
> +  *
> +  * | Voltage Ranges  | VSET Ranges  | Voltage Step |
> +  * +-+--+--+
> +  * | 0.5V to 1.50V   | 0x00 to 0x1A |  25mV|
> +  * | 1.2V to 3.3V| 0x1B to 0x45 |  50mV|
> +  */
> + if (uV >= 120)
> + return (uV - 120) / 5 + 0x1B;
> + else if (uV >= 50)
> + return (uV - 50) / 25000;
> + else
> + return -EINVAL;
> + }
> +
> + /* Buck1 and Buck12(dual phase) has a different mapping b/w output
> +  * voltage and VSET value.
> +  *
> +  * | Voltage Ranges  | VSET Ranges  | Voltage Step |
> +  * +-+--+--+
> +  * | 0.5V to 0.58V   | 0xA to 0xE   |  20mV|
> +  * | 0.6V to 1.095V  | 0xF to 0x72  |  5mV |
> +  * | 1.1V to 1.65V   | 0x73 to 0xAA |  10mV|
> +  * | 1.6V to 3.3V| 0xAB to 0xFD |  20mV|
> +  *
> +  */
> + if (uV >= 166)
> + return (uV - 166) / 2 + 0xAB;
> + else if (uV >= 110)
> + return (uV - 110) / 1 + 0x73;
> + else if (uV >= 60)
> + return (uV - 60) / 5000 + 0x0F;
> + else if (uV >= 50)
> + return (uV - 50) / 2 + 0x0A;
> + else
> + return -EINVAL;
> +}
> +
> +static int tps65224_buck_val2volt(int idx, int val)
> +{
> + /* This function does the opposite to the tps65224_buck_volt2val 
> function
> +  * described above.
> +  * This maps the VSET value to micro volts. Please refer to the ranges
> +  * mentioned the comments of tps65224_buck_volt2val.
> +  */
> +
> + if (idx > 0) {
> + if (val > TPS65224_BUCK234_VOLT_MAX_HEX)
> + return -EINVAL;
> + else if (val >= 0x1B)
> + return 120 + (val - 0x1B) * 5;
> + else if (val >= 0x00)
> + return 50 + (val - 0x00) * 25000;
> + else
> + return -EINVAL;
> + }
> +
> + if (val > TPS65224_BUCK1_VOLT_MAX_HEX)
> + return -EINVAL;
> + else if (val >= 0xAB)
> + return 166 + (val - 0xAB) * 2;
> + else if (val >= 0x73)
> + return 110 + (val - 0x73) * 1;
> + else if (val >= 0xF)
> + return 60 + (val - 0xF) * 5000;
> + else if (val >= 0xA)
> + return 50 + (val - 0xA) * 2;
> + 

Re: [RFC 3/5] board: starfive: support Milk-V Mars board

[Heinrich Schuchardt]

On 08.03.24 00:03, E Shattow wrote:


On Sun, Mar 3, 2024 at 5:02 AM Heinrich Schuchardt 
> wrote:

...

* The EEPROM is atmel,24c02 according to the vendor U-Boot.

...

The same vendor (Milk-V) U-Boot change is present on their branch for 
Mars CM Lite (which despite the naming has more in common with Pine64 
Star64 than Mars); However on visual inspection the silkscreen markings 
are for 24c04. See: [Photo flatbed scans of Mars CM Lite 4GB rev 
1.01](https://github.com/geerlingguy/sbc-reviews/issues/22#issuecomment-1872478605 ). Can this be determined at runtime, or I must trust that this is not a wrongly marked chip?



On the Milk-V Mars there is a chip marked "24C04F 21626P" like on the 
photo on the CM module from the thread above. This should be the EEPROM.


In some datasheets F is appended to mark the voltage range.

So this atmel,24c02 change seems really only be relevant if you have a 
CM module on a baseboard with an RTC at 0x51.


Best regards

Heinrich

Re: [PATCH 2/2] phy: rockchip-inno-usb2: Limit changes made to regs

[Kever Yang]

Hi Jonas,

On 2024/2/26 06:10, Jonas Karlman wrote:

The USB2PHY regs already contain working default reset values for RK3328
and RK35xx as evidenced by the fact that this driver never has changed a
single value for these SoCs.


I would prefer to keep it as is for now, I think these configs are 
needed for the phy init,


but I'm not sure these configs are all default correct after sw/hw  
reset/reboot and for


all the SoC versions.


Reduce to only configure utmi_suspend_n and utmi_sel bits similar to
what is currently done on RK3399.
I don't understand, you also remove configs for rk3399 in this patch, 
isn't it?

Also add missing clkout_ctl for RK3588.

This is necessary, would be better  send as a separate patch.


When enabled utmi_suspend_n is changed to normal mode and utmi_sel to
use otg/host controller utmi interface to phy. When disabled
utmi_suspend_n is changed to suspend mode and utmi_sel to use GRF utmi
interface to phy.


I don't understand this change for not much knowledge on utmi interface, 
any issue if we use the old config?


If necessary, should send as a separate patch.


Thanks,
- Kever


Signed-off-by: Jonas Karlman 
---
  drivers/phy/rockchip/phy-rockchip-inno-usb2.c | 117 +++---
  1 file changed, 14 insertions(+), 103 deletions(-)

diff --git a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c 
b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
index 7317128d135e..d392aed2d4de 100644
--- a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
@@ -35,16 +35,6 @@ struct usb2phy_reg {
  
  struct rockchip_usb2phy_port_cfg {

struct usb2phy_reg  phy_sus;
-   struct usb2phy_reg  bvalid_det_en;
-   struct usb2phy_reg  bvalid_det_st;
-   struct usb2phy_reg  bvalid_det_clr;
-   struct usb2phy_reg  ls_det_en;
-   struct usb2phy_reg  ls_det_st;
-   struct usb2phy_reg  ls_det_clr;
-   struct usb2phy_reg  utmi_avalid;
-   struct usb2phy_reg  utmi_bvalid;
-   struct usb2phy_reg  utmi_ls;
-   struct usb2phy_reg  utmi_hstdet;
  };
  
  struct rockchip_usb2phy_cfg {

@@ -131,7 +121,6 @@ static int rockchip_usb2phy_init(struct phy *phy)
  {
struct udevice *parent = dev_get_parent(phy->dev);
struct rockchip_usb2phy *priv = dev_get_priv(parent);
-   const struct rockchip_usb2phy_port_cfg *port_cfg = us2phy_get_port(phy);
int ret;
  
  	ret = clk_enable(>phyclk);

@@ -140,14 +129,6 @@ static int rockchip_usb2phy_init(struct phy *phy)
return ret;
}
  
-	if (phy->id == USB2PHY_PORT_OTG) {

-   property_enable(priv->reg_base, _cfg->bvalid_det_clr, 
true);
-   property_enable(priv->reg_base, _cfg->bvalid_det_en, true);
-   } else if (phy->id == USB2PHY_PORT_HOST) {
-   property_enable(priv->reg_base, _cfg->bvalid_det_clr, 
true);
-   property_enable(priv->reg_base, _cfg->bvalid_det_en, true);
-   }
-
return 0;
  }
  
@@ -351,27 +332,13 @@ bind_fail:

  static const struct rockchip_usb2phy_cfg rk3328_usb2phy_cfgs[] = {
{
.reg = 0x100,
-   .clkout_ctl = { 0x108, 4, 4, 1, 0 },
+   .clkout_ctl = { 0x0108, 4, 4, 1, 0 },
.port_cfgs  = {
[USB2PHY_PORT_OTG] = {
-   .phy_sus= { 0x0100, 15, 0, 0, 0x1d1 },
-   .bvalid_det_en  = { 0x0110, 3, 2, 0, 3 },
-   .bvalid_det_st  = { 0x0114, 3, 2, 0, 3 },
-   .bvalid_det_clr = { 0x0118, 3, 2, 0, 3 },
-   .ls_det_en  = { 0x0110, 0, 0, 0, 1 },
-   .ls_det_st  = { 0x0114, 0, 0, 0, 1 },
-   .ls_det_clr = { 0x0118, 0, 0, 0, 1 },
-   .utmi_avalid= { 0x0120, 10, 10, 0, 1 },
-   .utmi_bvalid= { 0x0120, 9, 9, 0, 1 },
-   .utmi_ls= { 0x0120, 5, 4, 0, 1 },
+   .phy_sus= { 0x0100, 1, 0, 2, 1 },
},
[USB2PHY_PORT_HOST] = {
-   .phy_sus= { 0x104, 15, 0, 0, 0x1d1 },
-   .ls_det_en  = { 0x110, 1, 1, 0, 1 },
-   .ls_det_st  = { 0x114, 1, 1, 0, 1 },
-   .ls_det_clr = { 0x118, 1, 1, 0, 1 },
-   .utmi_ls= { 0x120, 17, 16, 0, 1 },
-   .utmi_hstdet= { 0x120, 19, 19, 0, 1 }
+   .phy_sus= { 0x0104, 1, 0, 2, 1 },
}
},
},
@@ -385,19 +352,9 @@ static const struct rockchip_usb2phy_cfg 
rk3399_usb2phy_cfgs[] = {
.port_cfgs  = {

Re: [PATCH v2 1/5] power: tps65941: Add macros of TPS65224 PMIC

[Dhruva Gole]

On Mar 06, 2024 at 19:09:43 +0530, Bhargav Raviprakash wrote:
> Re-use the TPS65941 PMIC driver for TPS65224 PMIC.
> Add additional macros of TPS65224 to aid in the driver
> re-use.
> 
> Signed-off-by: Bhargav Raviprakash 
> ---

Reviewed-by: Dhruva Gole 

>  include/power/tps65941.h | 30 ++
>  1 file changed, 30 insertions(+)
> 

-- 
Best regards,
Dhruva Gole 

Re: [PATCH v2 3/5] power: regulator: tps65941: Added macros for BUCK ID

[Dhruva Gole]

Hi,

On Mar 06, 2024 at 19:09:45 +0530, Bhargav Raviprakash wrote:
> Adds macros for buck and ldo ids and switched to using switch
> case instead of if else in probe functions. Helps in adding
> support for TPS65224 PMIC.
> 
> Signed-off-by: Bhargav Raviprakash 
> ---
>  drivers/power/regulator/tps65941_regulator.c | 54 +++-
>  1 file changed, 42 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/power/regulator/tps65941_regulator.c 
> b/drivers/power/regulator/tps65941_regulator.c
> index b041126775..cf54e30df5 100644
> --- a/drivers/power/regulator/tps65941_regulator.c
> +++ b/drivers/power/regulator/tps65941_regulator.c
> @@ -16,6 +16,25 @@
>  #include 
>  #include 
>  
> +/* Single Phase Buck IDs */
> +#define TPS65941_BUCK_ID_11
> +#define TPS65941_BUCK_ID_22
> +#define TPS65941_BUCK_ID_33
> +#define TPS65941_BUCK_ID_44
> +#define TPS65941_BUCK_ID_55
> +
> +/* Multi Phase Buck IDs */
> +#define TPS65941_BUCK_ID_12  12
> +#define TPS65941_BUCK_ID_34  34
> +#define TPS65941_BUCK_ID_123123
> +#define TPS65941_BUCK_ID_1234  1234
> +
> +/* LDO IDs */
> +#define TPS65941_LDO_ID_1 1
> +#define TPS65941_LDO_ID_2 2
> +#define TPS65941_LDO_ID_3 3
> +#define TPS65941_LDO_ID_4 4
> +
>  static const char tps65941_buck_ctrl[TPS65941_BUCK_NUM] = {0x4, 0x6, 0x8, 
> 0xA,
>   0xC};
>  static const char tps65941_buck_vout[TPS65941_BUCK_NUM] = {0xE, 0x10, 0x12,
> @@ -270,10 +289,15 @@ static int tps65941_ldo_probe(struct udevice *dev)
>   uc_pdata->type = REGULATOR_TYPE_LDO;
>  
>   idx = dev->driver_data;
> - if (idx == 1 || idx == 2 || idx == 3 || idx == 4) {
> + switch (idx) {
> + case TPS65941_LDO_ID_1:
> + case TPS65941_LDO_ID_2:
> + case TPS65941_LDO_ID_3:
> + case TPS65941_LDO_ID_4:
>   debug("Single phase regulator\n");
> - } else {
> - printf("Wrong ID for regulator\n");
> + break;
> + default:
> + pr_err("Wrong ID for regulator\n");
>   return -EINVAL;
>   }
>  
> @@ -292,18 +316,24 @@ static int tps65941_buck_probe(struct udevice *dev)
>   uc_pdata->type = REGULATOR_TYPE_BUCK;
>  
>   idx = dev->driver_data;
> - if (idx == 1 || idx == 2 || idx == 3 || idx == 4 || idx == 5) {
> + switch (idx) {
> + case TPS65941_BUCK_ID_1:
> + case TPS65941_BUCK_ID_2:
> + case TPS65941_BUCK_ID_3:
> + case TPS65941_BUCK_ID_4:
> + case TPS65941_BUCK_ID_5:
>   debug("Single phase regulator\n");
> - } else if (idx == 12) {
> + break;
> + case TPS65941_BUCK_ID_12:
> + case TPS65941_BUCK_ID_123:
> + case TPS65941_BUCK_ID_1234:
>   idx = 1;
> - } else if (idx == 34) {
> + break;
> + case TPS65941_BUCK_ID_34:
>   idx = 3;
> - } else if (idx == 123) {
> - idx = 1;
> - } else if (idx == 1234) {
> - idx = 1;
> - } else {
> - printf("Wrong ID for regulator\n");
> + break;
> + default:
> + pr_err("Wrong ID for regulator\n");
>   return -EINVAL;

Reviewed-by: Dhruva Gole 

-- 
Best regards,
Dhruva Gole 

Re: [PATCH v2 2/5] power: pmic: tps65941: Add TI TPS65224 PMIC

[Dhruva Gole]

On Mar 06, 2024 at 19:09:44 +0530, Bhargav Raviprakash wrote:
> Adds compatible and data field values of TPS65224 driver in
> TPS65941 PMIC driver.
> 
> Signed-off-by: Bhargav Raviprakash 
> ---
>  drivers/power/pmic/tps65941.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/power/pmic/tps65941.c b/drivers/power/pmic/tps65941.c
> index 727b42747a..ef63eb733a 100644
> --- a/drivers/power/pmic/tps65941.c
> +++ b/drivers/power/pmic/tps65941.c
> @@ -75,6 +75,7 @@ static const struct udevice_id tps65941_ids[] = {
>   { .compatible = "ti,tps659412", .data = TPS659411 },
>   { .compatible = "ti,tps659413", .data = TPS659413 },
>   { .compatible = "ti,lp876441",  .data =  LP876441 },
> + { .compatible = "ti,tps65224",  .data =  TPS65224 },

Reviewed-by: Dhruva Gole 

-- 
Best regards,
Dhruva Gole 

Re: [PATCH 1/2] phy: rockchip-inno-usb2: Write to correct GRF

[Kever Yang]

On 2024/2/26 06:10, Jonas Karlman wrote:

On RK3399 the USB2PHY regs are located in the common GRF, remaining SoCs
that is supported by this driver have the USB2PHY regs in a different
GRF.

When support for RK356x, RK3588 and RK3328 was added this driver was
never updated to use correct GRF and have instead incorrectly written
to wrong GRF for these SoCs.

The default reset values for the USB2PHY have made USB mostly working
even when wrong GRF was used, however, following have been observed:

   scanning bus usb@fd84 for devices...
   ERROR:  USB-error: DEVICENOTRESPONDING: Device did not respond to token (IN) 
or did
   not provide a handshake (OUT) (5)
   ERROR: USB-error: DEVICENOTRESPONDING: Device did not respond to token (IN) 
or did
   not provide a handshake (OUT) (5)
   unable to get device descriptor (error=-1)

Fix this by using a regmap from rockchip,usbgrf prop and fall back to
getting a regmap for parent udevice instead of always getting the
common GRF.

Also protect against accidental clear of bit 0 in a reg with offset 0,
only bind driver to enabled otg/host-ports and remove unused headers.

Fixes: 3da15f0b49a2 ("phy: rockchip-inno-usb2: Add USB2 PHY for rk3568")
Fixes: cdf9010f6e17 ("phy: rockchip-inno-usb2: add initial support for rk3588 
PHY")
Fixes: 9aa93d84038b ("phy: rockchip-inno-usb2: Add USB2 PHY for RK3328")
Signed-off-by: Jonas Karlman 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  drivers/phy/rockchip/phy-rockchip-inno-usb2.c | 41 ++-
  1 file changed, 22 insertions(+), 19 deletions(-)

diff --git a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c 
b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
index 70e61eccb79a..7317128d135e 100644
--- a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
@@ -6,23 +6,16 @@
   * Copyright (C) 2020 Amarula Solutions(India)
   */
  
-#include 

  #include 
  #include 
-#include 
  #include 
  #include 
  #include 
  #include 
-#include 
+#include 
  #include 
-#include 
-#include 
-#include 
  #include 
  
-DECLARE_GLOBAL_DATA_PTR;

-
  #define usleep_range(a, b) udelay((b))
  #define BIT_WRITEABLE_SHIFT   16
  
@@ -61,30 +54,39 @@ struct rockchip_usb2phy_cfg {

  };
  
  struct rockchip_usb2phy {

-   void *reg_base;
+   struct regmap *reg_base;
struct clk phyclk;
const struct rockchip_usb2phy_cfg *phy_cfg;
  };
  
-static inline int property_enable(void *reg_base,

+static inline int property_enable(struct regmap *base,
  const struct usb2phy_reg *reg, bool en)
  {
unsigned int val, mask, tmp;
  
+	if (!reg->offset && !reg->enable && !reg->disable)

+   return 0;
+
tmp = en ? reg->enable : reg->disable;
mask = GENMASK(reg->bitend, reg->bitstart);
val = (tmp << reg->bitstart) | (mask << BIT_WRITEABLE_SHIFT);
  
-	return writel(val, reg_base + reg->offset);

+   return regmap_write(base, reg->offset, val);
  }
  
-static inline bool property_enabled(void *reg_base,

+static inline bool property_enabled(struct regmap *base,
const struct usb2phy_reg *reg)
  {
+   int ret;
unsigned int tmp, orig;
unsigned int mask = GENMASK(reg->bitend, reg->bitstart);
  
-	orig = readl(reg_base + reg->offset);

+   if (!reg->offset && !reg->enable && !reg->disable)
+   return false;
+
+   ret = regmap_read(base, reg->offset, );
+   if (ret)
+   return false;
  
  	tmp = (orig & mask) >> reg->bitstart;

return tmp != reg->disable;
@@ -248,7 +250,11 @@ static int rockchip_usb2phy_probe(struct udevice *dev)
unsigned int reg;
int index, ret;
  
-	priv->reg_base = syscon_get_first_range(ROCKCHIP_SYSCON_GRF);

+   if (dev_read_bool(dev, "rockchip,usbgrf"))
+   priv->reg_base =
+   syscon_regmap_lookup_by_phandle(dev, "rockchip,usbgrf");
+   else
+   priv->reg_base = syscon_get_regmap(dev_get_parent(dev));
if (IS_ERR(priv->reg_base))
return PTR_ERR(priv->reg_base);
  
@@ -305,11 +311,8 @@ static int rockchip_usb2phy_bind(struct udevice *dev)

int ret = 0;
  
  	dev_for_each_subnode(node, dev) {

-   if (!ofnode_valid(node)) {
-   dev_info(dev, "subnode %s not found\n", dev->name);
-   ret = -ENXIO;
-   goto bind_fail;
-   }
+   if (!ofnode_is_enabled(node))
+   continue;
  
  		name = ofnode_get_name(node);

dev_dbg(dev, "subnode %s\n", name);

[PATCH] arm64: zynqmp: Describe USB wakeup interrupt

[Michal Simek]

Describe usb wakeup interrupt.

Signed-off-by: Michal Simek 
---

 arch/arm/dts/zynqmp.dtsi | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/arch/arm/dts/zynqmp.dtsi b/arch/arm/dts/zynqmp.dtsi
index daae23c12b79..c19d86e5a0c4 100644
--- a/arch/arm/dts/zynqmp.dtsi
+++ b/arch/arm/dts/zynqmp.dtsi
@@ -1001,10 +1001,11 @@
status = "disabled";
reg = <0x0 0xfe20 0x0 0x4>;
interrupt-parent = <>;
-   interrupt-names = "host", "peripheral", "otg";
+   interrupt-names = "host", "peripheral", "otg", 
"wakeup";
interrupts = ,
 ,
-;
+,
+;
/* iommus = < 0x860>; */
snps,quirk-frame-length-adjustment = <0x20>;
clock-names = "ref";
@@ -1032,10 +1033,11 @@
status = "disabled";
reg = <0x0 0xfe30 0x0 0x4>;
interrupt-parent = <>;
-   interrupt-names = "host", "peripheral", "otg";
+   interrupt-names = "host", "peripheral", "otg", 
"wakeup";
interrupts = ,
 ,
-;
+,
+;
/* iommus = < 0x861>; */
snps,quirk-frame-length-adjustment = <0x20>;
clock-names = "ref";
-- 
2.36.1

[PATCH] arm64: zynqmp: Remove additional compatible string for sc-revB

[Michal Simek]

Based on dt schema there is no need to specify flash via additional
compatible string and generic are enough.

Signed-off-by: Michal Simek 
---

 arch/arm/dts/zynqmp-sc-revB.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/dts/zynqmp-sc-revB.dts b/arch/arm/dts/zynqmp-sc-revB.dts
index de2d7842ae28..c1d713b5d890 100644
--- a/arch/arm/dts/zynqmp-sc-revB.dts
+++ b/arch/arm/dts/zynqmp-sc-revB.dts
@@ -192,7 +192,7 @@
status = "okay";
/* QSPI should also have PINCTRL setup */
flash@0 {
-   compatible = "mt25qu512a", "m25p80", "jedec,spi-nor"; /* 
mt25qu512abb8e12 512Mib */
+   compatible = "m25p80", "jedec,spi-nor"; /* mt25qu512abb8e12 
512Mib */
#address-cells = <1>;
#size-cells = <1>;
reg = <0>;
-- 
2.36.1

[PATCH] arm64: zynqmp: Fix gpio-key DT description

[Michal Simek]

All gpio-key descriptionos with dt-schema.

Signed-off-by: Michal Simek 
---

 arch/arm/dts/zynqmp-sc-revB.dts| 2 +-
 arch/arm/dts/zynqmp-vp-x-a2785-00-revA.dts | 2 +-
 arch/arm/dts/zynqmp-vpk120-revA.dts| 2 +-
 arch/arm/dts/zynqmp-zcu208-revA.dts| 2 +-
 arch/arm/dts/zynqmp-zcu216-revA.dts| 2 +-
 arch/arm/dts/zynqmp-zcu670-revA.dts| 2 +-
 arch/arm/dts/zynqmp-zcu670-revB.dts| 2 +-
 7 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm/dts/zynqmp-sc-revB.dts b/arch/arm/dts/zynqmp-sc-revB.dts
index 8517bdad6f47..de2d7842ae28 100644
--- a/arch/arm/dts/zynqmp-sc-revB.dts
+++ b/arch/arm/dts/zynqmp-sc-revB.dts
@@ -49,7 +49,7 @@
gpio-keys {
compatible = "gpio-keys";
autorepeat;
-   fwuen {
+   key-fwuen {
label = "sw16";
gpios = < 12 GPIO_ACTIVE_LOW>;
linux,code = ;
diff --git a/arch/arm/dts/zynqmp-vp-x-a2785-00-revA.dts 
b/arch/arm/dts/zynqmp-vp-x-a2785-00-revA.dts
index 2a3bbe170472..b626d1aacf58 100644
--- a/arch/arm/dts/zynqmp-vp-x-a2785-00-revA.dts
+++ b/arch/arm/dts/zynqmp-vp-x-a2785-00-revA.dts
@@ -47,7 +47,7 @@
gpio-keys {
compatible = "gpio-keys";
autorepeat;
-   j383 {
+   key-j383 {
label = "j383";
gpios = < 10 GPIO_ACTIVE_HIGH>;
linux,code = ;
diff --git a/arch/arm/dts/zynqmp-vpk120-revA.dts 
b/arch/arm/dts/zynqmp-vpk120-revA.dts
index e0e4f1b13ada..e0632883e4ec 100644
--- a/arch/arm/dts/zynqmp-vpk120-revA.dts
+++ b/arch/arm/dts/zynqmp-vpk120-revA.dts
@@ -47,7 +47,7 @@
gpio-keys {
compatible = "gpio-keys";
autorepeat;
-   sw16 {
+   button-16 {
label = "sw16";
gpios = < 10 GPIO_ACTIVE_HIGH>;
linux,code = ;
diff --git a/arch/arm/dts/zynqmp-zcu208-revA.dts 
b/arch/arm/dts/zynqmp-zcu208-revA.dts
index b4e24745a9a6..a113e475082f 100644
--- a/arch/arm/dts/zynqmp-zcu208-revA.dts
+++ b/arch/arm/dts/zynqmp-zcu208-revA.dts
@@ -46,7 +46,7 @@
gpio-keys {
compatible = "gpio-keys";
autorepeat;
-   sw19 {
+   switch-19 {
label = "sw19";
gpios = < 22 GPIO_ACTIVE_HIGH>;
linux,code = ;
diff --git a/arch/arm/dts/zynqmp-zcu216-revA.dts 
b/arch/arm/dts/zynqmp-zcu216-revA.dts
index 6f593e80841f..4d7d5d2e5eff 100644
--- a/arch/arm/dts/zynqmp-zcu216-revA.dts
+++ b/arch/arm/dts/zynqmp-zcu216-revA.dts
@@ -46,7 +46,7 @@
gpio-keys {
compatible = "gpio-keys";
autorepeat;
-   sw19 {
+   switch-19 {
label = "sw19";
gpios = < 22 GPIO_ACTIVE_HIGH>;
linux,code = ;
diff --git a/arch/arm/dts/zynqmp-zcu670-revA.dts 
b/arch/arm/dts/zynqmp-zcu670-revA.dts
index 7f70904f44e7..def3b53cef7f 100644
--- a/arch/arm/dts/zynqmp-zcu670-revA.dts
+++ b/arch/arm/dts/zynqmp-zcu670-revA.dts
@@ -49,7 +49,7 @@
gpio-keys {
compatible = "gpio-keys";
autorepeat;
-   sw1 {
+   switch-1 {
label = "sw1";
gpios = < 22 GPIO_ACTIVE_HIGH>;
linux,code = ;
diff --git a/arch/arm/dts/zynqmp-zcu670-revB.dts 
b/arch/arm/dts/zynqmp-zcu670-revB.dts
index 0adb2062aef1..41f9a23d06ad 100644
--- a/arch/arm/dts/zynqmp-zcu670-revB.dts
+++ b/arch/arm/dts/zynqmp-zcu670-revB.dts
@@ -49,7 +49,7 @@
gpio-keys {
compatible = "gpio-keys";
autorepeat;
-   sw1 {
+   switch-1 {
label = "sw1";
gpios = < 22 GPIO_ACTIVE_HIGH>;
linux,code = ;
-- 
2.36.1

Re: [PATCH 0/5] net: mdio-uclass: probe generic Ethernet PHY driver & Fix Beagleplay Ethernet

[Roger Quadros]

On 08/03/2024 10:22, Roger Quadros wrote:
> 
> 
> On 05/03/2024 15:24, Roger Quadros wrote:
>> Currently, the GPIO Reset Device Tree properties of the
>> PHY node are ignored when the PHY is probed via mdio-uclass driver [1].
>>
>> To resolve this, for each child of the MDIO bus node, bind and probe
>> the generic Ethernet PHY driver if CONFIG_DM_ETH_PHY is enabled.
>>
>> This should now show the generic_phy_driver in "dm tree"
>> and also apply the GPIO reset before the MDIO bus driver scans the bus
>> for the PHYs.
>>
>>  ethernet  0  [ + ]   am65_cpsw_nuss_port   |   |-- 
>> ethernet@800port@1
>>  bootdev   3  [   ]   eth_bootdev   |   |   `-- 
>> port@1.bootdev
>>  mdio  0  [ + ]   cpsw_mdio |   `-- mdio@f00
>>  eth_phy_ge0  [ + ]   eth_phy_generic_drv   |   |-- 
>> ethernet-phy@0
>>  eth_phy_ge1  [ + ]   eth_phy_generic_drv   |   `-- 
>> ethernet-phy@1
>>
>> To test this on Beagleplay, the following series is required
>>
>> [1] Switch am65-cpsw to DM MDIO
>>  
>> https://lore.kernel.org/all/20240228-for-2024-07-am65-cpsw-mdio-v2-0-f74f972ea...@kernel.org/
>>
>> The last 3 patches are marked [not-for-merge]. They are to show how the
>> whole solution can work to fix Ethernet on Beagleplay, which has been broken
>> so far. Those DT patches will be sent once the device tree changes are merged
>> into Linux tree.
>>
>> Signed-off-by: Roger Quadros 
> 
> Some CI tests failed. I will fix and send v2.
> https://github.com/u-boot/u-boot/pull/495

I'm unsure if the failure is due to this series or not.
https://dev.azure.com/u-boot/u-boot/_build/results?buildId=8023=logs=a1270dec-081b-5c65-5cd5-5e915a842596=69f6cf72-86f3-551a-807d-f28f62a1426f=530

Are these known issues?

=== FAILURES ===
___ test_tpm2_sandbox_self_test_full ___
test/py/tests/test_tpm2.py:115: in test_tpm2_sandbox_self_test_full
output = u_boot_console.run_command('echo $?')
test/py/u_boot_console_base.py:256: in run_command
m = self.p.expect([chunk] + self.bad_patterns)
test/py/u_boot_spawn.py:193: in expect
raise Timeout()
E   u_boot_spawn.Timeout
- Captured stdout call -
/u-boot
sandbox_serial serial: pinctrl_select_state_full: 
uclass_get_device_by_phandle_id: err=-19



 TestEfiSignedImage.test_efi_signed_image_auth5 
test/py/tests/test_efi_secboot/test_signed.py:162: in 
test_efi_signed_image_auth5
output = u_boot_console.run_command_list([
test/py/u_boot_console_base.py:297: in run_command_list
output.append(self.run_command(cmd))
test/py/u_boot_console_base.py:256: in run_command
m = self.p.expect([chunk] + self.bad_patterns)
test/py/u_boot_spawn.py:193: in expect
raise Timeout()
E   u_boot_spawn.Timeout
- Captured stdout call -
/u-boot
sandbox_serial serial: pinctrl_select_state_full: 
uclass_get_device_by_phandle_id: err=-19

> 
>> ---
>> Roger Quadros (5):
>>   net: mdio-uclass: Bind and probe generic Ethernet PHY driver
>>   configs/am62x_beagleplay_a53_defconfig: enable DM_ETH_PHY
>>   [not-for-merge] arm: dts: k3-am62*: sync with linux-next-20240229
>>   [not-for-merge] k3-am625-beagleplay-u-boot: get CPSW Ethernet to work
>>   [not-for-merge] arm: dts: k3-am625-beagleplay: Fix Ethernet PHY reset 
>> GPIO
>>
>>  arch/arm/dts/k3-am62-main.dtsi   | 126 ++---
>>  arch/arm/dts/k3-am62-mcu.dtsi|   4 +-
>>  arch/arm/dts/k3-am62-phycore-som.dtsi|   5 +-
>>  arch/arm/dts/k3-am62-thermal.dtsi|   5 +-
>>  arch/arm/dts/k3-am62-verdin-dev.dtsi |   4 +-
>>  arch/arm/dts/k3-am62-verdin-wifi.dtsi|   1 -
>>  arch/arm/dts/k3-am62-verdin.dtsi |  76 +++---
>>  arch/arm/dts/k3-am62-wakeup.dtsi |  38 +++--
>>  arch/arm/dts/k3-am62.dtsi|   4 +-
>>  arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi |  63 +
>>  arch/arm/dts/k3-am625-beagleplay.dts |  66 -
>>  arch/arm/dts/k3-am625-phyboard-lyra-rdk.dts  | 104 +-
>>  arch/arm/dts/k3-am625-sk.dts |   4 +-
>>  arch/arm/dts/k3-am625.dtsi   |   4 +-
>>  arch/arm/dts/k3-am62a-main.dtsi  | 201 
>> +--
>>  arch/arm/dts/k3-am62a-mcu.dtsi   |   4 +-
>>  arch/arm/dts/k3-am62a-thermal.dtsi   |   5 +-
>>  arch/arm/dts/k3-am62a-wakeup.dtsi|   4 +-
>>  arch/arm/dts/k3-am62a.dtsi   |   4 +-
>>  arch/arm/dts/k3-am62a7-sk.dts| 162 -
>>  arch/arm/dts/k3-am62a7.dtsi  |   4 +-
>>  arch/arm/dts/k3-am62x-sk-common.dtsi |  24 +++-
>>  configs/am62x_beagleplay_a53_defconfig   |   2 +-
>>  net/mdio-uclass.c  

Re: [PATCH 0/5] net: mdio-uclass: probe generic Ethernet PHY driver & Fix Beagleplay Ethernet

[Roger Quadros]

On 05/03/2024 15:24, Roger Quadros wrote:
> Currently, the GPIO Reset Device Tree properties of the
> PHY node are ignored when the PHY is probed via mdio-uclass driver [1].
> 
> To resolve this, for each child of the MDIO bus node, bind and probe
> the generic Ethernet PHY driver if CONFIG_DM_ETH_PHY is enabled.
> 
> This should now show the generic_phy_driver in "dm tree"
> and also apply the GPIO reset before the MDIO bus driver scans the bus
> for the PHYs.
> 
>  ethernet  0  [ + ]   am65_cpsw_nuss_port   |   |-- 
> ethernet@800port@1
>  bootdev   3  [   ]   eth_bootdev   |   |   `-- port@1.bootdev
>  mdio  0  [ + ]   cpsw_mdio |   `-- mdio@f00
>  eth_phy_ge0  [ + ]   eth_phy_generic_drv   |   |-- ethernet-phy@0
>  eth_phy_ge1  [ + ]   eth_phy_generic_drv   |   `-- ethernet-phy@1
> 
> To test this on Beagleplay, the following series is required
> 
> [1] Switch am65-cpsw to DM MDIO
>  
> https://lore.kernel.org/all/20240228-for-2024-07-am65-cpsw-mdio-v2-0-f74f972ea...@kernel.org/
> 
> The last 3 patches are marked [not-for-merge]. They are to show how the
> whole solution can work to fix Ethernet on Beagleplay, which has been broken
> so far. Those DT patches will be sent once the device tree changes are merged
> into Linux tree.
> 
> Signed-off-by: Roger Quadros 

Some CI tests failed. I will fix and send v2.
https://github.com/u-boot/u-boot/pull/495

> ---
> Roger Quadros (5):
>   net: mdio-uclass: Bind and probe generic Ethernet PHY driver
>   configs/am62x_beagleplay_a53_defconfig: enable DM_ETH_PHY
>   [not-for-merge] arm: dts: k3-am62*: sync with linux-next-20240229
>   [not-for-merge] k3-am625-beagleplay-u-boot: get CPSW Ethernet to work
>   [not-for-merge] arm: dts: k3-am625-beagleplay: Fix Ethernet PHY reset 
> GPIO
> 
>  arch/arm/dts/k3-am62-main.dtsi   | 126 ++---
>  arch/arm/dts/k3-am62-mcu.dtsi|   4 +-
>  arch/arm/dts/k3-am62-phycore-som.dtsi|   5 +-
>  arch/arm/dts/k3-am62-thermal.dtsi|   5 +-
>  arch/arm/dts/k3-am62-verdin-dev.dtsi |   4 +-
>  arch/arm/dts/k3-am62-verdin-wifi.dtsi|   1 -
>  arch/arm/dts/k3-am62-verdin.dtsi |  76 +++---
>  arch/arm/dts/k3-am62-wakeup.dtsi |  38 +++--
>  arch/arm/dts/k3-am62.dtsi|   4 +-
>  arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi |  63 +
>  arch/arm/dts/k3-am625-beagleplay.dts |  66 -
>  arch/arm/dts/k3-am625-phyboard-lyra-rdk.dts  | 104 +-
>  arch/arm/dts/k3-am625-sk.dts |   4 +-
>  arch/arm/dts/k3-am625.dtsi   |   4 +-
>  arch/arm/dts/k3-am62a-main.dtsi  | 201 
> +--
>  arch/arm/dts/k3-am62a-mcu.dtsi   |   4 +-
>  arch/arm/dts/k3-am62a-thermal.dtsi   |   5 +-
>  arch/arm/dts/k3-am62a-wakeup.dtsi|   4 +-
>  arch/arm/dts/k3-am62a.dtsi   |   4 +-
>  arch/arm/dts/k3-am62a7-sk.dts| 162 -
>  arch/arm/dts/k3-am62a7.dtsi  |   4 +-
>  arch/arm/dts/k3-am62x-sk-common.dtsi |  24 +++-
>  configs/am62x_beagleplay_a53_defconfig   |   2 +-
>  net/mdio-uclass.c|  41 ++
>  24 files changed, 825 insertions(+), 130 deletions(-)
> ---
> base-commit: 84f5bb0be0ec9fbf98f8f3317b578dfc114cf44e
> change-id: 20240305-for-2024-07-beagleplay-eth-f82a51197937
> 
> Best regards,

-- 
cheers,
-roger