Re: [PATCH 2/2] ARM: imx: Remove PMIC reset configuration from board files

2022-12-12 Thread Peng Fan




On 12/10/2022 3:35 AM, Marek Vasut wrote:

The PCA9450 reset configuration can now be performed by the PCA9450 PMIC
driver itself, remove the hard-coded variant from board code and let the
PMIC driver perform this task using one-liner:

```
$ sed -i '/set WDOG_B_CFG to cold reset/,+2 d' $(git grep -l 
PCA9450_RESET_CTRL.*0xA1 board/)
```

Venice and i.MX93 EVK required slight manual fix up.

Signed-off-by: Marek Vasut 
---
Cc: "NXP i.MX U-Boot Team" 
Cc: "Ying-Chun Liu (PaulLiu)" 
Cc: Fabio Estevam 
Cc: Fabio Estevam 
Cc: Frieder Schrempf 
Cc: Manoj Sai 
Cc: Marcel Ziswiler 
Cc: Matteo Lisi 
Cc: Peng Fan 
Cc: Stefano Babic 
Cc: Tim Harvey 
---
  board/advantech/imx8mp_rsb3720a1/spl.c | 3 ---
  board/dhelectronics/dh_imx8mp/spl.c| 3 ---
  board/engicam/imx8mp/spl.c | 3 ---
  board/freescale/imx8mm_evk/spl.c   | 3 ---
  board/freescale/imx8mn_evk/spl.c   | 3 ---
  board/freescale/imx8mp_evk/spl.c   | 3 ---
  board/freescale/imx93_evk/spl.c| 3 ---
  board/gateworks/venice/spl.c   | 3 ---
  board/kontron/sl-mx8mm/spl.c   | 3 ---
  board/toradex/verdin-imx8mm/spl.c  | 3 ---
  board/toradex/verdin-imx8mp/spl.c  | 3 ---
  11 files changed, 33 deletions(-)

diff --git a/board/advantech/imx8mp_rsb3720a1/spl.c 
b/board/advantech/imx8mp_rsb3720a1/spl.c
index 6cc8c23ecf8..f4257bc993d 100644
--- a/board/advantech/imx8mp_rsb3720a1/spl.c
+++ b/board/advantech/imx8mp_rsb3720a1/spl.c
@@ -209,9 +209,6 @@ int power_init_board(void)
/* To avoid timing risk from SOC to ARM,increase VDD_ARM to OD voltage 
0.95v */
pmic_reg_write(pdev, PCA9450_BUCK2OUT_DVS0, 0x1C);
  
-	/* set WDOG_B_CFG to cold reset */

-   pmic_reg_write(pdev, PCA9450_RESET_CTRL, 0xA1);
-
/* Forced enable the I2C level translator*/
pmic_reg_write(pdev, PCA9450_CONFIG2, 0x03);
  
diff --git a/board/dhelectronics/dh_imx8mp/spl.c b/board/dhelectronics/dh_imx8mp/spl.c

index 60450bfe369..e2aa874723a 100644
--- a/board/dhelectronics/dh_imx8mp/spl.c
+++ b/board/dhelectronics/dh_imx8mp/spl.c
@@ -88,9 +88,6 @@ static int dh_imx8mp_board_power_init(void)
/* To avoid timing risk from SoC to ARM, increase VDD_ARM to OD voltage 
0.95V */
pmic_reg_write(dev, PCA9450_BUCK2OUT_DVS0, 0x1c);
  
-	/* Set WDOG_B_CFG to cold reset. */

-   pmic_reg_write(dev, PCA9450_RESET_CTRL, 0xA1);
-
/* Set LDO4 and CONFIG2 to enable the I2C level translator. */
pmic_reg_write(dev, PCA9450_LDO4CTRL, 0x59);
pmic_reg_write(dev, PCA9450_CONFIG2, 0x1);
diff --git a/board/engicam/imx8mp/spl.c b/board/engicam/imx8mp/spl.c
index 6a16d58ae5a..36b83aace39 100644
--- a/board/engicam/imx8mp/spl.c
+++ b/board/engicam/imx8mp/spl.c
@@ -95,9 +95,6 @@ int power_init_board(void)
pmic_reg_write(p, PCA9450_BUCK6OUT, 0x18);
  #endif
  
-	/* set WDOG_B_CFG to cold reset */

-   pmic_reg_write(p, PCA9450_RESET_CTRL, 0xA1);
-
return 0;
  }
  #endif
diff --git a/board/freescale/imx8mm_evk/spl.c b/board/freescale/imx8mm_evk/spl.c
index b5a2faf3a18..6e9513805cd 100644
--- a/board/freescale/imx8mm_evk/spl.c
+++ b/board/freescale/imx8mm_evk/spl.c
@@ -99,9 +99,6 @@ static int power_init_board(void)
/* set VDD_SNVS_0V8 from default 0.85V */
pmic_reg_write(dev, PCA9450_LDO2CTRL, 0xC0);
  
-	/* set WDOG_B_CFG to cold reset */

-   pmic_reg_write(dev, PCA9450_RESET_CTRL, 0xA1);
-
return 0;
  }
  
diff --git a/board/freescale/imx8mn_evk/spl.c b/board/freescale/imx8mn_evk/spl.c

index 380abecd746..ec0378b5b76 100644
--- a/board/freescale/imx8mn_evk/spl.c
+++ b/board/freescale/imx8mn_evk/spl.c
@@ -95,9 +95,6 @@ int power_init_board(void)
/* enable LDO4 to 1.2v */
pmic_reg_write(dev, PCA9450_LDO4CTRL, 0x44);
  
-	/* set WDOG_B_CFG to cold reset */

-   pmic_reg_write(dev, PCA9450_RESET_CTRL, 0xA1);
-
return 0;
  }
  #endif
diff --git a/board/freescale/imx8mp_evk/spl.c b/board/freescale/imx8mp_evk/spl.c
index f1b285417d0..246826a0d48 100644
--- a/board/freescale/imx8mp_evk/spl.c
+++ b/board/freescale/imx8mp_evk/spl.c
@@ -102,9 +102,6 @@ int power_init_board(void)
/* To avoid timing risk from SOC to ARM,increase VDD_ARM to OD voltage 
0.95v */
pmic_reg_write(p, PCA9450_BUCK2OUT_DVS0, 0x1C);
  
-	/* set WDOG_B_CFG to cold reset */

-   pmic_reg_write(p, PCA9450_RESET_CTRL, 0xA1);
-
return 0;
  }
  #endif
diff --git a/board/freescale/imx93_evk/spl.c b/board/freescale/imx93_evk/spl.c
index 38cfbac6ea6..1aa2977b409 100644
--- a/board/freescale/imx93_evk/spl.c
+++ b/board/freescale/imx93_evk/spl.c
@@ -74,9 +74,6 @@ int power_init_board(void)
  
  	/* I2C_LT_EN*/

pmic_reg_write(dev, 0xa, 0x3);
-
-   /* set WDOG_B_CFG to cold reset */
-   pmic_reg_write(dev, PCA9450_RESET_CTRL, 0xA1);
return 0;
  }
  #endif
diff --git a/board/gateworks/venice/spl.c b/board/gateworks/venice/spl.c
index e06de8bb54c..60830766ca9 100644
--- a/board/gateworks/venice/spl.c
+++ 

Re: [PATCH 1/2] pmic: pca9450: Make warm reset on WDOG_B assertion

2022-12-12 Thread Peng Fan




On 12/10/2022 3:35 AM, Marek Vasut wrote:

The default configuration of the PMIC behavior makes the PMIC
power cycle most regulators on WDOG_B assertion. This power
cycling causes the memory contents of OCRAM to be lost.
Some systems neeeds some memory that survives reset and
reboot, therefore this patch is created.

The implementation is taken almost verbatim from Linux commit
2364a64d0673f ("regulator: pca9450: Make warm reset on WDOG_B assertion")

Signed-off-by: Marek Vasut 
---
Cc: "NXP i.MX U-Boot Team" 
Cc: "Ying-Chun Liu (PaulLiu)" 
Cc: Fabio Estevam 
Cc: Fabio Estevam 
Cc: Frieder Schrempf 
Cc: Manoj Sai 
Cc: Marcel Ziswiler 
Cc: Matteo Lisi 
Cc: Peng Fan 
Cc: Rickard x Andersson 
Cc: Stefano Babic 
Cc: Tim Harvey 
---
  drivers/power/pmic/pca9450.c | 11 ++-
  include/power/pca9450.h  |  4 
  2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/power/pmic/pca9450.c b/drivers/power/pmic/pca9450.c
index a186edc08da..2427abfb7a5 100644
--- a/drivers/power/pmic/pca9450.c
+++ b/drivers/power/pmic/pca9450.c
@@ -86,6 +86,7 @@ static int pca9450_bind(struct udevice *dev)
  static int pca9450_probe(struct udevice *dev)
  {
struct pca9450_priv *priv = dev_get_priv(dev);
+   unsigned int reset_ctrl;
int ret = 0;
  
  	if (CONFIG_IS_ENABLED(DM_GPIO) && CONFIG_IS_ENABLED(DM_REGULATOR_PCA9450)) {

@@ -95,10 +96,18 @@ static int pca9450_probe(struct udevice *dev)
if (IS_ERR(priv->sd_vsel_gpio)) {
ret = PTR_ERR(priv->sd_vsel_gpio);
dev_err(dev, "Failed to request SD_VSEL GPIO: %d\n", 
ret);
+   if (ret)
+   return ret;
}
}
  
-	return ret;

+   if (ofnode_read_bool(dev_ofnode(dev), "nxp,wdog_b-warm-reset"))
+   reset_ctrl = PCA9450_PMIC_RESET_WDOG_B_CFG_WARM;
+   else
+   reset_ctrl = PCA9450_PMIC_RESET_WDOG_B_CFG_COLD_LDO12;
+
+   return pmic_clrsetbits(dev, PCA9450_RESET_CTRL,
+  PCA9450_PMIC_RESET_WDOG_B_CFG_MASK, reset_ctrl);
  }
  
  static struct dm_pmic_ops pca9450_ops = {

diff --git a/include/power/pca9450.h b/include/power/pca9450.h
index fa0405fcb87..6efecee96c8 100644
--- a/include/power/pca9450.h
+++ b/include/power/pca9450.h
@@ -67,4 +67,8 @@ enum {
  #define PCA9450_LDO34_MASK0x1f
  #define PCA9450_LDO5_MASK 0x0f
  
+#define PCA9450_PMIC_RESET_WDOG_B_CFG_MASK		0xc0

+#define PCA9450_PMIC_RESET_WDOG_B_CFG_WARM 0x40
+#define PCA9450_PMIC_RESET_WDOG_B_CFG_COLD_LDO12   0x80
+
  #endif


Reviewed-by: Peng Fan 


Re: [PATCH 2/2] ARM: imx: bootaux: Fix LTO -Wlto-type-mismatch

2022-12-12 Thread Peng Fan




On 12/13/2022 12:46 PM, Marek Vasut wrote:

Commit 56c2dbdabab5 ("imx: bootaux: cleanup code") introduces the
following LTO related warning:

"
arch/arm/mach-imx/imx_bootaux.c:24:31: warning: type of ‘hostmap’ does not 
match original declaration [-Wlto-type-mismatch]
24 | const __weak struct rproc_att hostmap[] = { };
   |   ^
arch/arm/mach-imx/imx8m/soc.c:1590:24: note: array types have different bounds
  1590 | const struct rproc_att hostmap[] = {
   |^
arch/arm/mach-imx/imx8m/soc.c:1590:24: note: ‘hostmap’ was previously declared 
here
../aarch64-linux-gnu/bin/ld: warning: u-boot has a LOAD segment with RWX 
permissions
"

This is because the weak empty array of structures "hostmap" is eventually
replaced by non-empty array of structures with different number of elements.
Fix this by avoiding weak variable size array, instead use a weak function
which returns single pointer to the array.

Fixes: 56c2dbdabab5 ("imx: bootaux: cleanup code")
Signed-off-by: Marek Vasut 
---
Cc: "NXP i.MX U-Boot Team" 
Cc: Fabio Estevam 
Cc: Marek Behún 
Cc: Peng Fan 
Cc: Stefano Babic 
---
  arch/arm/include/asm/mach-imx/sys_proto.h | 2 ++
  arch/arm/mach-imx/imx8m/soc.c | 5 +
  arch/arm/mach-imx/imx_bootaux.c   | 7 +--
  arch/arm/mach-imx/mx7/soc.c   | 5 +
  4 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/mach-imx/sys_proto.h 
b/arch/arm/include/asm/mach-imx/sys_proto.h
index dd0d3f29333..27fdc16cd50 100644
--- a/arch/arm/include/asm/mach-imx/sys_proto.h
+++ b/arch/arm/include/asm/mach-imx/sys_proto.h
@@ -149,6 +149,8 @@ struct rproc_att {
u32 size; /* size of reg range */
  };
  
+const struct rproc_att *imx_bootaux_get_hostmap(void);

+
  struct rom_api {
u16 ver;
u16 tag;
diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-imx/imx8m/soc.c
index a4863281e36..5e92f8143cf 100644
--- a/arch/arm/mach-imx/imx8m/soc.c
+++ b/arch/arm/mach-imx/imx8m/soc.c
@@ -1610,4 +1610,9 @@ const struct rproc_att hostmap[] = {
{ 0x4000, 0x4000, 0x8000 },
{ /* sentinel */ }
  };
+
+const struct rproc_att *imx_bootaux_get_hostmap(void)
+{
+   return hostmap;
+}
  #endif
diff --git a/arch/arm/mach-imx/imx_bootaux.c b/arch/arm/mach-imx/imx_bootaux.c
index 433c1f80cee..888c53d6901 100644
--- a/arch/arm/mach-imx/imx_bootaux.c
+++ b/arch/arm/mach-imx/imx_bootaux.c
@@ -21,11 +21,14 @@
  #define SRC_M4_REG_OFFSET 0
  #endif
  
-const __weak struct rproc_att hostmap[] = { };

+__weak const struct rproc_att *imx_bootaux_get_hostmap(void)
+{
+   return NULL;
+}
  
  static const struct rproc_att *get_host_mapping(unsigned long auxcore)

  {
-   const struct rproc_att *mmap = hostmap;
+   const struct rproc_att *mmap = imx_bootaux_get_hostmap();
  
  	while (mmap && mmap->size) {

if (mmap->da <= auxcore &&
diff --git a/arch/arm/mach-imx/mx7/soc.c b/arch/arm/mach-imx/mx7/soc.c
index 02af0d568f2..689dbefe8ee 100644
--- a/arch/arm/mach-imx/mx7/soc.c
+++ b/arch/arm/mach-imx/mx7/soc.c
@@ -224,6 +224,11 @@ const struct rproc_att hostmap[] = {
{ 0x8000, 0x8000, 0x6000 }, /* DDRC */
{ /* sentinel */ }
  };
+
+const struct rproc_att *imx_bootaux_get_hostmap(void)
+{
+   return hostmap;
+}
  #endif
  
  #if !CONFIG_IS_ENABLED(SKIP_LOWLEVEL_INIT)


Reviewed-by: Peng Fan 


Re: [PATCH 1/2] ARM: imx: bootaux: Fix macro misuse

2022-12-12 Thread Peng Fan




On 12/13/2022 12:46 PM, Marek Vasut wrote:

There are no CONFIG_{TOOLS_,SPL_,TPL_,}IMX8M macros, nor is there one for
ARM64. Use plain IS_ENABLED(CONFIG_IMX8M) and IS_ENABLED(CONFIG_ARM64) to
avoid expanding the {TOOLS_,SPL_,TPL_,} part.

Fixes: 56c2dbdabab5 ("imx: bootaux: cleanup code")
Signed-off-by: Marek Vasut 
---
Cc: "NXP i.MX U-Boot Team" 
Cc: Fabio Estevam 
Cc: Marek Behún 
Cc: Peng Fan 
Cc: Stefano Babic 
---
  arch/arm/mach-imx/imx_bootaux.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-imx/imx_bootaux.c b/arch/arm/mach-imx/imx_bootaux.c
index 8115bf40f1a..433c1f80cee 100644
--- a/arch/arm/mach-imx/imx_bootaux.c
+++ b/arch/arm/mach-imx/imx_bootaux.c
@@ -15,7 +15,7 @@
  #include 
  
  /* Just to avoid build error */

-#if CONFIG_IS_ENABLED(IMX8M)
+#if IS_ENABLED(CONFIG_IMX8M)
  #define SRC_M4C_NON_SCLR_RST_MASK BIT(0)
  #define SRC_M4_ENABLE_MASKBIT(0)
  #define SRC_M4_REG_OFFSET 0
@@ -106,7 +106,7 @@ int arch_auxiliary_core_up(u32 core_id, ulong addr)
if (!pc)
return CMD_RET_FAILURE;
  
-		if (!CONFIG_IS_ENABLED(ARM64))

+   if (!IS_ENABLED(CONFIG_ARM64))
stack = 0x0;
} else {
/*
@@ -128,7 +128,7 @@ int arch_auxiliary_core_up(u32 core_id, ulong addr)
flush_dcache_all();
  
  	/* Enable M4 */

-   if (CONFIG_IS_ENABLED(IMX8M)) {
+   if (IS_ENABLED(CONFIG_IMX8M)) {
arm_smccc_smc(IMX_SIP_SRC, IMX_SIP_SRC_M4_START, 0, 0, 0, 0, 0, 
0, NULL);
} else {
clrsetbits_le32(SRC_BASE_ADDR + SRC_M4_REG_OFFSET,
@@ -143,7 +143,7 @@ int arch_auxiliary_core_check_up(u32 core_id)
struct arm_smccc_res res;
unsigned int val;
  
-	if (CONFIG_IS_ENABLED(IMX8M)) {

+   if (IS_ENABLED(CONFIG_IMX8M)) {
arm_smccc_smc(IMX_SIP_SRC, IMX_SIP_SRC_M4_STARTED, 0, 0, 0, 0, 0, 
0, );
return res.a0;
}


Reviewed-by: Peng Fan 


Re: [PATCH v5 1/3] efi_loader: Add SPI I/O protocol support

2022-12-12 Thread Ilias Apalodimas
Hi Paul,

Apologies for the delayed reply.

[...]

> +static efi_status_t
> +export_spi_peripheral(struct efi_spi_bus *bus, struct udevice *dev)
> +{
> + efi_string_t name_utf16, vendor_utf16, part_number_utf16;
> + struct efi_spi_peripheral_priv *priv;
> + efi_status_t status;
> + efi_handle_t handle = NULL;
> + struct udevice *dev_bus = dev->parent;
> + struct spi_slave *target;
> + const char *name = dev_read_name(dev);
> + const char *vendor = dev_read_string(dev, "u-boot,uefi-spi-vendor");
> + const char *part_number = dev_read_string(dev,
> + "u-boot,uefi-spi-part-number");
> + efi_guid_t *guid = (efi_guid_t *)dev_read_u8_array_ptr(dev,
> + "u-boot,uefi-spi-io-guid", 16);
> +
> + if (device_get_uclass_id(dev) == UCLASS_SPI_EMUL) {
> + debug("Skipping emulated SPI peripheral %s\n", name);
> + goto fail_1;
> + }
> +
> + if (!vendor || !part_number || !guid) {
> + debug("Skipping SPI peripheral %s\n", name);
> + status = EFI_UNSUPPORTED;
> + goto fail_1;
> + }
> +
> + if (!device_active(dev)) {
> + int ret = device_probe(dev);
> + if (ret) {
> + debug("Skipping SPI peripheral %s, probe failed\n",
> +   name);
> + goto fail_1;
> + }
> + }
> +
> + target = dev_get_parent_priv(dev);
> + if (!target) {
> + debug("Skipping uninitialized SPI peripheral %s\n", name);
> + status = EFI_UNSUPPORTED;
> + goto fail_1;
> + }
> +
> + debug("Registering SPI dev %d:%d, name %s\n",
> +   dev_bus->seq_, spi_chip_select(dev), name);
> +
> + priv = calloc(1, sizeof(*priv));
> + if (!priv) {
> + status = EFI_OUT_OF_RESOURCES;
> + goto fail_1;
> + }
> +
> + vendor_utf16 = efi_convert_string(vendor);
> + if (!vendor_utf16) {
> + status = EFI_OUT_OF_RESOURCES;
> + goto fail_2;
> + }
> +
> + part_number_utf16 = efi_convert_string(part_number);
> + if (!part_number_utf16) {
> + status = EFI_OUT_OF_RESOURCES;
> + goto fail_3;
> + }
> +
> + name_utf16 = efi_convert_string(name);
> + if (!name_utf16) {
> + status = EFI_OUT_OF_RESOURCES;
> + goto fail_4;
> + }
> +
> + priv->target = target;
> +
> + efi_spi_init_part(>part, target, vendor_utf16, part_number_utf16);
> +
> + efi_spi_init_peripheral(>peripheral, >part,
> + bus, target, guid, name_utf16);
> +
> + efi_spi_append_peripheral(>peripheral, bus);
> +
> + efi_spi_init_io_protocol(>io_protocol, >peripheral, target);
> +
> + status = efi_install_multiple_protocol_interfaces(, guid,
> +   >io_protocol,
> +   NULL);

There's a protocols installed here as well as in
efi_spi_protocol_register().  But I don't see those being uninstalled
somewhere.  Shouldn't destroy_efi_spi_bus() call
efi_uninstall_multiple_protocol_interfaces() as well ?


> + if (status != EFI_SUCCESS)
> + goto fail_5;
> +
> + debug("Added EFI_SPI_IO_PROTOCOL for %s with guid %pUl\n", name, guid);
> + return EFI_SUCCESS;
> +
> +fail_5:
> + free(name_utf16);
> +fail_4:
> + free(part_number_utf16);
> +fail_3:
> + free(vendor_utf16);
> +fail_2:
> + free(priv);
> +fail_1:
> + return status;
> +}
> +
> +static struct efi_spi_bus *export_spi_bus(int i)
> +{
> + struct efi_spi_bus *bus;
> + struct udevice *dev, *child;
> + const char *name;
> + int r;
> +
> + r = uclass_get_device(UCLASS_SPI, i, );
> + if (r < 0) {
> + debug("Failed to get SPI bus %d\n", i);
> + goto fail_1;
> + }
> +
> + name = dev_read_name(dev);
> + debug("Registering SPI bus %d, name %s\n", i, name);
> +
> + bus = calloc(1, sizeof(*bus));
> + if (!bus)
> + goto fail_1;
> +
> + bus->friendly_name = efi_convert_string(name);
> + if (!bus->friendly_name)
> + goto fail_2;
> +
> + bus->peripheral_list = NULL;
> + bus->clock = efi_spi_bus_clock;
> + bus->clock_parameter = NULL;
> +
> + /* For the purposes of the current implementation, we do not need to
> +  * expose the hardware device path to users of the SPI I/O protocol.
> +  */
> + bus->controller_path = _device_path;
> +
> + device_foreach_child(child, dev) {
> + efi_status_t status = export_spi_peripheral(bus, child);
> +
> + if (status == EFI_OUT_OF_RESOURCES)
> + goto fail_3;
> + }
> +
> + return bus;
> +
> +fail_3:
> + destroy_efi_spi_bus(bus);
> +fail_2:
> + free(bus);
> +fail_1:
> + return NULL;
> +}
> +
> +efi_status_t 

[PATCH v2] board: ti: common: board_detect: Fix EEPROM read quirk for 2-byte

2022-12-12 Thread Neha Malcom Francis
EEPROM detection logic in ti_i2c_eeprom_get() involves figuring out
whether addressing is 1-byte or 2-byte. There are currently different
behaviours seen across boards as documented in commit bf6376642fe8
("board: ti: common: board_detect: Fix EEPROM read quirk"). Adding to
the list, we see that there are 2-byte EEPROMs that read properly
with 1-byte addressing with no offset.

For ti_i2c_eeprom_am6_get where eeprom parse operation is dynamic, the
earlier commit d2ab2a2bafd5 ("board: ti: common: board_detect: Fix
EEPROM read quirk for AM6 style data") tried to resolve this by running
ti_i2c_eeprom_get() twice. However this commit along with its former
commit fails on J7 platforms where EEPROM successfully return back the
header on 1-byte addressing and continues to do so until an offset is
introduced. So the second read incorrectly determines the EEPROM as
1-byte addressing.

A more generic solution is introduced here to solve
this issue: 1-byte read without offset and 1-byte read with offset. If
both passes, it follows 1-byte addressing else we proceed with 2-byte
addressing check.

Tested on J721E, J7200, DRA7xx, AM64x

Signed-off-by: Neha Malcom Francis 
Fixes: d2ab2a2bafd5 (board: ti: common: board_detect: Fix EEPROM read quirk for 
AM6 style data)
Fixes: bf6376642fe8 (board: ti: common: board_detect: Fix EEPROM read quirk)
---
 board/ti/common/board_detect.c | 46 +-
 1 file changed, 34 insertions(+), 12 deletions(-)

Changes since v1:
- modified algorithm for boards that do not have CONFIG_DM_I2C
  enabled as well

diff --git a/board/ti/common/board_detect.c b/board/ti/common/board_detect.c
index c37629fe8a..9b32076ab9 100644
--- a/board/ti/common/board_detect.c
+++ b/board/ti/common/board_detect.c
@@ -87,6 +87,8 @@ static int __maybe_unused ti_i2c_eeprom_get(int bus_addr, int 
dev_addr,
u32 header, u32 size, uint8_t *ep)
 {
int rc;
+   uint8_t offset_test;
+   bool one_byte_addressing = true;
 
 #if CONFIG_IS_ENABLED(DM_I2C)
struct udevice *dev;
@@ -114,8 +116,23 @@ static int __maybe_unused ti_i2c_eeprom_get(int bus_addr, 
int dev_addr,
 */
(void)dm_i2c_read(dev, 0, ep, size);
 
+   if (*((u32 *)ep) != header)
+   one_byte_addressing = false;
+
+   /*
+* Handle case of bad 2 byte eeproms that responds to 1 byte addressing
+* but gets stuck in const addressing when read requests are performed
+* on offsets. We perform an offset test to make sure it is not a 2 byte
+* eeprom that works with 1 byte addressing but just without an offset
+*/
+
+   rc = dm_i2c_read(dev, 0x1, _test, sizeof(offset_test));
+
+   if (*((u32 *)ep) != (header & 0xFF))
+   one_byte_addressing = false;
+
/* Corrupted data??? */
-   if (*((u32 *)ep) != header) {
+   if (!one_byte_addressing) {
/*
 * read the eeprom header using i2c again, but use only a
 * 2 byte address (some newer boards need this..)
@@ -151,8 +168,23 @@ static int __maybe_unused ti_i2c_eeprom_get(int bus_addr, 
int dev_addr,
 */
(void)i2c_read(dev_addr, 0x0, byte, ep, size);
 
+   if (*((u32 *)ep) != header)
+   one_byte_addressing = false;
+
+   /*
+* Handle case of bad 2 byte eeproms that responds to 1 byte addressing
+* but gets stuck in const addressing when read requests are performed
+* on offsets. We perform an offset test to make sure it is not a 2 byte
+* eeprom that works with 1 byte addressing but just without an offset
+*/
+
+   rc = i2c_read(dev, 0x1, byte, _test, sizeof(offset_test));
+
+   if (*((u32 *)ep) != (header & 0xFF))
+   one_byte_addressing = false;
+
/* Corrupted data??? */
-   if (*((u32 *)ep) != header) {
+   if (!one_byte_addressing) {
/*
 * read the eeprom header using i2c again, but use only a
 * 2 byte address (some newer boards need this..)
@@ -444,16 +476,6 @@ int __maybe_unused ti_i2c_eeprom_am6_get(int bus_addr, int 
dev_addr,
if (rc)
return rc;
 
-   /*
-* Handle case of bad 2 byte eeproms that responds to 1 byte addressing
-* but gets stuck in const addressing when read requests are performed
-* on offsets. We re-read the board ID to ensure we have sane data back
-*/
-   rc = ti_i2c_eeprom_get(bus_addr, dev_addr, TI_EEPROM_HEADER_MAGIC,
-  sizeof(board_id), (uint8_t *)_id);
-   if (rc)
-   return rc;
-
if (board_id.header.id != TI_AM6_EEPROM_RECORD_BOARD_ID) {
pr_err("%s: Invalid board ID record!\n", __func__);
return -EINVAL;
-- 
2.34.1



Re: [PATCH] serial: ns16550: Enable clocks during probe

2022-12-12 Thread Stefan Roese

Hi Samuel,

On 12/13/22 02:46, Samuel Holland wrote:

On 12/12/22 12:54, Tom Rini wrote:

On Sun, Nov 27, 2022 at 11:48:34PM -0600, Samuel Holland wrote:


If the UART bus or baud clock has a gate, it must be enabled before the
UART can be used.

Signed-off-by: Samuel Holland 
Reviewed-by: Stefan Roese 


This breaks building on phycore-rk3288


I get:

binman: Error 1 running 'mkimage -d ./mkimage.simple-bin.mkimage -n
rk3288 -T rksd ./idbloader.img': Error: SPL image is too large (size
0x8800 than 0x8000)

Before applying this patch:

$ ls -l spl/u-boot-spl.bin
-rw-r--r-- 1 samuel samuel 32704 Dec 12 19:35 spl/u-boot-spl.bin

So the board was quite close to its SPL size limit already.

I was trying to be general with this patch, but I suppose for my
immediate purposes (Allwinner D1), I only care about the first clock. If
I use clk_get_by_index() instead of clk_get_bulk(), the phycore-rk3288
build passes with 4 bytes to spare:

$ ls -l spl/u-boot-spl.bin
-rw-r--r-- 1 samuel samuel 32760 Dec 12 19:36 spl/u-boot-spl.bin

I will send a v2, but I imagine some other unsuspecting patch will run
into this limit again before long.


Why not enable LTO to save more space. I just checked this on this
platform:

w/o LTO:
spl/u-boot-spl.bin 32604

with LTO enabled:
spl/u-boot-spl.bin 30016

Not tested though.

Thanks,
Stefan


Re: [PATCH] Makefile: With BINMAN_ALLOW_MISSING=1 don't error on missing

2022-12-12 Thread Simon Glass
Hi Tom,

On Mon, 12 Dec 2022 at 16:43, Tom Rini  wrote:
>
> On Tue, Dec 06, 2022 at 10:03:37AM -0500, Tom Rini wrote:
> > On Tue, Dec 06, 2022 at 03:36:49PM +1300, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Tue, 6 Dec 2022 at 15:03, Tom Rini  wrote:
> > > >
> > > > When the user builds with BINMAN_ALLOW_MISSING=1 they're explicitly
> > > > setting the flag to allow for additional binaries to be missing and so
> > > > have acknowledged the output might not work. In this case we want to
> > > > default to not passing a non-zero exit code.
> > > >
> > > > Cc: Simon Glass 
> > > > Reported-by: Peter Robinson 
> > > > Signed-off-by: Tom Rini 
> > > > ---
> > > > This passes CI as-is:
> > > > https://source.denx.de/u-boot/u-boot/-/pipelines/14340
> > > > ---
> > > >  Makefile | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/Makefile b/Makefile
> > > > index de5746399a63..03de1da1bfd0 100644
> > > > --- a/Makefile
> > > > +++ b/Makefile
> > > > @@ -1334,7 +1334,7 @@ cmd_binman = $(srctree)/tools/binman/binman $(if 
> > > > $(BINMAN_DEBUG),-D) \
> > > >  --toolpath $(objtree)/tools \
> > > > $(if $(BINMAN_VERBOSE),-v$(BINMAN_VERBOSE)) \
> > > > build -u -d u-boot.dtb -O . -m \
> > > > -   $(if $(BINMAN_ALLOW_MISSING),--allow-missing 
> > > > --fake-ext-blobs) \
> > > > +   $(if $(BINMAN_ALLOW_MISSING),--allow-missing 
> > > > --ignore-missing) \
> > > > -I . -I $(srctree) -I $(srctree)/board/$(BOARDDIR) \
> > > > -I arch/$(ARCH)/dts -a of-list=$(CONFIG_OF_LIST) \
> > > > $(foreach f,$(BINMAN_INDIRS),-I $(f)) \
> > > > --
> > > > 2.25.1
> > > >
> > >
> > > I believe we need the --fake-ext-blobs flag as well, since otherwise
> > > boards which use tools (like mkimage) on things that don't exist will
> > > not work.
> >
> > So, we need to list out all the use cases perhaps, as we had missed one
> > before. In my mind we have:
> > - Board requires 1 or more blobs, developer will be running this on
> >   hardware, expects output from U-Boot 'make' (or buildman) to boot.
> >   Blobs must be present or non-zero exist status by default.
> >   We didn't have this before, and we do now.
> > - Board requires 1 or more blobs AND has optional blobs, will be running
> >   this on hardware, expects output from U-Boot 'make' (or buildman) to
> >   boot. This is the case we had missed before as allwinner requires bl31
> >   and has optional PMIC firmware. This is the case Peter reported and we
> >   had missed before, which this patch allows for, with the caveat that
> >   if you forget BL31 you're not going to boot and make won't complain
> >   exit-code wise. Another way to resolve this would be a property in the
> >   binman node to mark a blob as optional and warn if missing, rather
> >   than error if missing.
> > - Board requires 1 or more blobs, output will NOT be run. This is the CI
> >   case and the compile testing lots of board cases. This is what CI
> >   passes still, with the above.
> > - Board requires 1 or more blobs, developer will be running this on
> >   hardware, BUT will be injecting the blobs later on. I think this is
> >   the use case you're talking about?
>
> Simon, can you test this last case by chance? I think that's the one
> that's unclear about if this patch breaks or not and I want to know if I
> need to respin to still include the fake blobs flag still too or not.
> Or does anyone else use this case and can test?

Yes I have your email printed out but travel and family things have
made it hard to get to it. I do think you need the flag, but the extra
case you mention need another look and probably a test, as you say.

Regards,
Simon


Re: [PATCH] serial: Do not write additional \r before \n for dm_serial drivers

2022-12-12 Thread Simon Glass
On Sun, 11 Dec 2022 at 12:28, Pali Rohár  wrote:
>
> serial-uclass.c code already puts \r before \n for all dm_serial drivers.
>
> Signed-off-by: Pali Rohár 
> ---
>  drivers/serial/serial_lpuart.c | 3 ---
>  drivers/serial/serial_mpc8xx.c | 3 ---
>  2 files changed, 6 deletions(-)
>

Reviewed-by: Simon Glass 


Re: [PATCH 1/1] cmd: change the return value when argc error

2022-12-12 Thread Simon Glass
On Sat, 10 Dec 2022 at 01:50, Shenlin Liang
 wrote:
>
> When the number of parameters is wrong, the return value should be processed 
> in
> the same way as other cmds, return CMD_RET_USAGE so that it can print the 
> information.
>
> Signed-off-by: Shenlin Liang 
> ---
>  cmd/mvebu/comphy_rx_training.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

Reviewed-by: Simon Glass 


Re: [PATCH] usb: gadget: ether: split start/stop from init/halt

2022-12-12 Thread Marek Vasut

On 12/12/22 16:29, Niel Fourie wrote:

Split out _usb_eth_start() from _usb_eth_init() and
usb_eth_stop() from _usb_eth_halt(). Now _usb_eth_init() only
initialises and registers the gadget device, which _usb_eth_halt()
reverses, and together are used for probing and removing the
device. The _usb_eth_start() and _usb_eth_stop() functions connect
and disconnect the gadget as expected by the start()/stop()
callbacks.

Previously the gadget device was probed on every start() and
removed on every stop(), which is inconsistent with other DM_ETH
drivers. For non-DM gadget drivers the old behaviour has been
retained.


Does this mean the udevice pointer and associated private date are 
retained during the entire operation of the USB gadget , i.e. even 
between stop/start cycles ?


Re: [PATCH v2] net: eth-uclass: revalidate priv after stop() in eth_halt()

2022-12-12 Thread Marek Vasut

On 12/12/22 16:29, Niel Fourie wrote:

In eth_halt(), reread and revalidate priv after calling stop(),
as it may have been freed, leaving a dangling pointer.

In the ethernet gadget implementation, the gadget device gets
probed during start() and removed during stop(), which includes
freeing `uclass_priv_` to which `priv` is pointing. Writing to
`priv` after stop() may corrupt the `fd` member of `struct
malloc_chunk`, which represents the freed block, and could cause
hard-to-debug crashes on subsequent calls to malloc()/free().

Signed-off-by: Niel Fourie 
Cc: Ramon Fried 
Cc: Marek Vasut 
Cc: Lukasz Majewski 
---
Changes for v2:
- Revalidate priv instead of changing state before stop()
- Added explanational comment

This patch my be dropped if the patch which addresses the root cause
("usb: gadget: ether: split start/stop from init/halt") is accepted.

  net/eth-uclass.c | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/net/eth-uclass.c b/net/eth-uclass.c
index f41da4b37b3..7d5783b5cab 100644
--- a/net/eth-uclass.c
+++ b/net/eth-uclass.c
@@ -341,8 +341,11 @@ void eth_halt(void)
priv = dev_get_uclass_priv(current);
if (!priv || !priv->running)
return;
-
eth_get_ops(current)->stop(current);
+   /* Ethernet gadget frees priv during stop, workaround until fixed... */
+   priv = dev_get_uclass_priv(current);
+   if (!priv || !priv->running)
+   return;


Is this fixed by the second patch in this series ?
If so, drop this patch.


[PATCH 2/2] ARM: imx: bootaux: Fix LTO -Wlto-type-mismatch

2022-12-12 Thread Marek Vasut
Commit 56c2dbdabab5 ("imx: bootaux: cleanup code") introduces the
following LTO related warning:

"
arch/arm/mach-imx/imx_bootaux.c:24:31: warning: type of ‘hostmap’ does not 
match original declaration [-Wlto-type-mismatch]
   24 | const __weak struct rproc_att hostmap[] = { };
  |   ^
arch/arm/mach-imx/imx8m/soc.c:1590:24: note: array types have different bounds
 1590 | const struct rproc_att hostmap[] = {
  |^
arch/arm/mach-imx/imx8m/soc.c:1590:24: note: ‘hostmap’ was previously declared 
here
../aarch64-linux-gnu/bin/ld: warning: u-boot has a LOAD segment with RWX 
permissions
"

This is because the weak empty array of structures "hostmap" is eventually
replaced by non-empty array of structures with different number of elements.
Fix this by avoiding weak variable size array, instead use a weak function
which returns single pointer to the array.

Fixes: 56c2dbdabab5 ("imx: bootaux: cleanup code")
Signed-off-by: Marek Vasut 
---
Cc: "NXP i.MX U-Boot Team" 
Cc: Fabio Estevam 
Cc: Marek Behún 
Cc: Peng Fan 
Cc: Stefano Babic 
---
 arch/arm/include/asm/mach-imx/sys_proto.h | 2 ++
 arch/arm/mach-imx/imx8m/soc.c | 5 +
 arch/arm/mach-imx/imx_bootaux.c   | 7 +--
 arch/arm/mach-imx/mx7/soc.c   | 5 +
 4 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/mach-imx/sys_proto.h 
b/arch/arm/include/asm/mach-imx/sys_proto.h
index dd0d3f29333..27fdc16cd50 100644
--- a/arch/arm/include/asm/mach-imx/sys_proto.h
+++ b/arch/arm/include/asm/mach-imx/sys_proto.h
@@ -149,6 +149,8 @@ struct rproc_att {
u32 size; /* size of reg range */
 };
 
+const struct rproc_att *imx_bootaux_get_hostmap(void);
+
 struct rom_api {
u16 ver;
u16 tag;
diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-imx/imx8m/soc.c
index a4863281e36..5e92f8143cf 100644
--- a/arch/arm/mach-imx/imx8m/soc.c
+++ b/arch/arm/mach-imx/imx8m/soc.c
@@ -1610,4 +1610,9 @@ const struct rproc_att hostmap[] = {
{ 0x4000, 0x4000, 0x8000 },
{ /* sentinel */ }
 };
+
+const struct rproc_att *imx_bootaux_get_hostmap(void)
+{
+   return hostmap;
+}
 #endif
diff --git a/arch/arm/mach-imx/imx_bootaux.c b/arch/arm/mach-imx/imx_bootaux.c
index 433c1f80cee..888c53d6901 100644
--- a/arch/arm/mach-imx/imx_bootaux.c
+++ b/arch/arm/mach-imx/imx_bootaux.c
@@ -21,11 +21,14 @@
 #define SRC_M4_REG_OFFSET  0
 #endif
 
-const __weak struct rproc_att hostmap[] = { };
+__weak const struct rproc_att *imx_bootaux_get_hostmap(void)
+{
+   return NULL;
+}
 
 static const struct rproc_att *get_host_mapping(unsigned long auxcore)
 {
-   const struct rproc_att *mmap = hostmap;
+   const struct rproc_att *mmap = imx_bootaux_get_hostmap();
 
while (mmap && mmap->size) {
if (mmap->da <= auxcore &&
diff --git a/arch/arm/mach-imx/mx7/soc.c b/arch/arm/mach-imx/mx7/soc.c
index 02af0d568f2..689dbefe8ee 100644
--- a/arch/arm/mach-imx/mx7/soc.c
+++ b/arch/arm/mach-imx/mx7/soc.c
@@ -224,6 +224,11 @@ const struct rproc_att hostmap[] = {
{ 0x8000, 0x8000, 0x6000 }, /* DDRC */
{ /* sentinel */ }
 };
+
+const struct rproc_att *imx_bootaux_get_hostmap(void)
+{
+   return hostmap;
+}
 #endif
 
 #if !CONFIG_IS_ENABLED(SKIP_LOWLEVEL_INIT)
-- 
2.35.1



[PATCH 1/2] ARM: imx: bootaux: Fix macro misuse

2022-12-12 Thread Marek Vasut
There are no CONFIG_{TOOLS_,SPL_,TPL_,}IMX8M macros, nor is there one for
ARM64. Use plain IS_ENABLED(CONFIG_IMX8M) and IS_ENABLED(CONFIG_ARM64) to
avoid expanding the {TOOLS_,SPL_,TPL_,} part.

Fixes: 56c2dbdabab5 ("imx: bootaux: cleanup code")
Signed-off-by: Marek Vasut 
---
Cc: "NXP i.MX U-Boot Team" 
Cc: Fabio Estevam 
Cc: Marek Behún 
Cc: Peng Fan 
Cc: Stefano Babic 
---
 arch/arm/mach-imx/imx_bootaux.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-imx/imx_bootaux.c b/arch/arm/mach-imx/imx_bootaux.c
index 8115bf40f1a..433c1f80cee 100644
--- a/arch/arm/mach-imx/imx_bootaux.c
+++ b/arch/arm/mach-imx/imx_bootaux.c
@@ -15,7 +15,7 @@
 #include 
 
 /* Just to avoid build error */
-#if CONFIG_IS_ENABLED(IMX8M)
+#if IS_ENABLED(CONFIG_IMX8M)
 #define SRC_M4C_NON_SCLR_RST_MASK  BIT(0)
 #define SRC_M4_ENABLE_MASK BIT(0)
 #define SRC_M4_REG_OFFSET  0
@@ -106,7 +106,7 @@ int arch_auxiliary_core_up(u32 core_id, ulong addr)
if (!pc)
return CMD_RET_FAILURE;
 
-   if (!CONFIG_IS_ENABLED(ARM64))
+   if (!IS_ENABLED(CONFIG_ARM64))
stack = 0x0;
} else {
/*
@@ -128,7 +128,7 @@ int arch_auxiliary_core_up(u32 core_id, ulong addr)
flush_dcache_all();
 
/* Enable M4 */
-   if (CONFIG_IS_ENABLED(IMX8M)) {
+   if (IS_ENABLED(CONFIG_IMX8M)) {
arm_smccc_smc(IMX_SIP_SRC, IMX_SIP_SRC_M4_START, 0, 0, 0, 0, 0, 
0, NULL);
} else {
clrsetbits_le32(SRC_BASE_ADDR + SRC_M4_REG_OFFSET,
@@ -143,7 +143,7 @@ int arch_auxiliary_core_check_up(u32 core_id)
struct arm_smccc_res res;
unsigned int val;
 
-   if (CONFIG_IS_ENABLED(IMX8M)) {
+   if (IS_ENABLED(CONFIG_IMX8M)) {
arm_smccc_smc(IMX_SIP_SRC, IMX_SIP_SRC_M4_STARTED, 0, 0, 0, 0, 
0, 0, );
return res.a0;
}
-- 
2.35.1



[PATCH v1] imx8: scu_api: sync sc_rm_is_pad_owned api change

2022-12-12 Thread Marcel Ziswiler
From: Ye Li 

SCFW has fixed a overflow issue in sc_rm_is_pad_owned API. This
requires u-boot to update API implementation, since it will cause
compatible issue. Otherwise all pad checking will have problem and
cause pad setting not continue.

Due to the compatible issue, the new u-boot only works with new
SCFW (API version: 1.21 and later).

old scfw + old u-boot: API overflow issue
old scfw + new u-boot, or new scfw + old u-boot: API compatible issue
new scfw + new u-boot: Working

Signed-off-by: Ye Li 
Reviewed-by : Jason Liu 
Signed-off-by: Marcel Ziswiler 

---
I stumbled over this one when working on the apalis-imx8 boot issue fix
and support refresh [1] where I noticed that using the latest SCFW
Ethernet won't come up. Through manual testing, I identified SCFW 1.3.1
to still work fine so I settled with that for the time being.
Re-visiting this SCFW incompatibility issue again now I stumbled over
this downstream commit [2] which I believe would be very suitable for
upstreaming as well. With that latest SCFW 1.14.0 works fine again. So
here it goes.

[1] 
https://patchwork.ozlabs.org/project/uboot/cover/20221212000930.45505-1-mar...@ziswiler.com/
[2] 
https://github.com/nxp-imx/uboot-imx/commit/9be6761bccd008de16191aed325004bd982f770f

 arch/arm/include/asm/arch-imx8/sci/rpc.h | 2 +-
 drivers/misc/imx8/scu_api.c  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/arch-imx8/sci/rpc.h 
b/arch/arm/include/asm/arch-imx8/sci/rpc.h
index 9f55904f44..39de7f0e3e 100644
--- a/arch/arm/include/asm/arch-imx8/sci/rpc.h
+++ b/arch/arm/include/asm/arch-imx8/sci/rpc.h
@@ -11,7 +11,7 @@
 /* Defines */
 
 #define SCFW_API_VERSION_MAJOR  1U
-#define SCFW_API_VERSION_MINOR  15U
+#define SCFW_API_VERSION_MINOR  21U
 
 #define SC_RPC_VERSION  1U
 
diff --git a/drivers/misc/imx8/scu_api.c b/drivers/misc/imx8/scu_api.c
index 27ecce710f..8f546e9b3f 100644
--- a/drivers/misc/imx8/scu_api.c
+++ b/drivers/misc/imx8/scu_api.c
@@ -788,7 +788,7 @@ sc_bool_t sc_rm_is_pad_owned(sc_ipc_t ipc, sc_pad_t pad)
RPC_VER() = SC_RPC_VERSION;
RPC_SVC() = (u8)SC_RPC_SVC_RM;
RPC_FUNC() = (u8)RM_FUNC_IS_PAD_OWNED;
-   RPC_U8(, 0U) = (u8)pad;
+   RPC_U16(, 0U) = (u16)pad;
RPC_SIZE() = 2U;
 
ret = misc_call(dev, SC_FALSE, , size, , size);
-- 
2.35.1



Re: [PATCH v1] net: nuvoton: fix build broken for use phy_get_interface_by_name

2022-12-12 Thread Jim Liu
Hi Tom

OK , thanks for your reply.

Best regards,
Jim

On Tue, Dec 13, 2022 at 11:01 AM Tom Rini  wrote:
>
> On Tue, Dec 13, 2022 at 10:56:49AM +0800, Jim Liu wrote:
> > Hi Tom
> >
> > Thanks for your quick response.
> >
> > I add defconfig patch and found this build error and i2c naming issue.
> > https://patchwork.ozlabs.org/project/uboot/patch/20220712092407.16567-2-jjl...@nuvoton.com/
> >
> > So I add patch to fix this build error.
> > -> 
> > https://patchwork.ozlabs.org/project/uboot/patch/20220913062521.6067-1-jjl...@nuvoton.com/
> > -> 
> > https://patchwork.ozlabs.org/project/uboot/patch/20221121085932.29686-1-jjl...@nuvoton.com/
> >
> > i2c patch is already merged.
>
> OK, I'll put it in my list of things to not forget for the next release
> as well.
>
> >
> > Best regards,
> > Jim
> >
> > On Tue, Dec 13, 2022 at 10:02 AM Tom Rini  wrote:
> > >
> > > On Tue, Dec 13, 2022 at 09:48:12AM +0800, Jim Liu wrote:
> > > > Hi Tom
> > > >
> > > > My upstream topic status is Awaiting Upstream.
> > > > What could I do to make it merge fast?
> > > > Your comments are welcome.
> > >
> > > It's in -next now, for v2023.04.  Does this fix some regression already
> > > present in-tree?
> > >
> > > >
> > > > Best regards,
> > > > Jim
> > > >
> > > > On Mon, Nov 21, 2022 at 3:41 PM Jim Liu  wrote:
> > > > >
> > > > > Hi  Ramon
> > > > >
> > > > > My upstream topic status is Awaiting Upstream.
> > > > > What could I do to make it merge fast?
> > > > >
> > > > > Best regards,
> > > > > Jim
> > > > >
> > > > > On Sun, Sep 18, 2022 at 2:07 PM Ramon Fried  
> > > > > wrote:
> > > > > >
> > > > > > On Tue, Sep 13, 2022 at 9:25 AM Jim Liu  
> > > > > > wrote:
> > > > > > >
> > > > > > > The original patch is use phy_get_interface_by_name to set 
> > > > > > > interface.
> > > > > > > The new patch is use dev_read_phy_mode to replace it.
> > > > > > >
> > > > > > > Signed-off-by: Jim Liu 
> > > > > > > ---
> > > > > > >  drivers/net/npcm750_eth.c | 8 
> > > > > > >  1 file changed, 4 insertions(+), 4 deletions(-)
> > > > > > >
> > > > > > > diff --git a/drivers/net/npcm750_eth.c b/drivers/net/npcm750_eth.c
> > > > > > > index 409d5cce4a..bd29a10def 100644
> > > > > > > --- a/drivers/net/npcm750_eth.c
> > > > > > > +++ b/drivers/net/npcm750_eth.c
> > > > > > > @@ -710,12 +710,12 @@ static int 
> > > > > > > npcm750_eth_ofdata_to_platdata(struct udevice *dev)
> > > > > > >
> > > > > > > pdata->phy_interface = -1;
> > > > > > > phy_mode = fdt_getprop(gd->fdt_blob, dev_of_offset(dev), 
> > > > > > > "phy-mode", NULL);
> > > > > > > +
> > > > > > > if (phy_mode)
> > > > > > > -   pdata->phy_interface = 
> > > > > > > phy_get_interface_by_name(phy_mode);
> > > > > > > -   if (pdata->phy_interface == -1) {
> > > > > > > -   printf("%s: Invalid PHY interface '%s'\n", 
> > > > > > > __func__, phy_mode);
> > > > > > > +   pdata->phy_interface = dev_read_phy_mode(dev);
> > > > > > > +
> > > > > > > +   if (pdata->phy_interface == PHY_INTERFACE_MODE_NA)
> > > > > > > return -EINVAL;
> > > > > > > -   }
> > > > > > >
> > > > > > > pdata->max_speed = 0;
> > > > > > > cell = fdt_getprop(gd->fdt_blob, dev_of_offset(dev), 
> > > > > > > "max-speed", NULL);
> > > > > > > --
> > > > > > > 2.17.1
> > > > > > >
> > > > > > Reviewed-by: Ramon Fried 
> > >
> > > --
> > > Tom
>
> --
> Tom


Re: [PATCH v1] net: nuvoton: fix build broken for use phy_get_interface_by_name

2022-12-12 Thread Tom Rini
On Tue, Dec 13, 2022 at 10:56:49AM +0800, Jim Liu wrote:
> Hi Tom
> 
> Thanks for your quick response.
> 
> I add defconfig patch and found this build error and i2c naming issue.
> https://patchwork.ozlabs.org/project/uboot/patch/20220712092407.16567-2-jjl...@nuvoton.com/
> 
> So I add patch to fix this build error.
> -> 
> https://patchwork.ozlabs.org/project/uboot/patch/20220913062521.6067-1-jjl...@nuvoton.com/
> -> 
> https://patchwork.ozlabs.org/project/uboot/patch/20221121085932.29686-1-jjl...@nuvoton.com/
> 
> i2c patch is already merged.

OK, I'll put it in my list of things to not forget for the next release
as well.

> 
> Best regards,
> Jim
> 
> On Tue, Dec 13, 2022 at 10:02 AM Tom Rini  wrote:
> >
> > On Tue, Dec 13, 2022 at 09:48:12AM +0800, Jim Liu wrote:
> > > Hi Tom
> > >
> > > My upstream topic status is Awaiting Upstream.
> > > What could I do to make it merge fast?
> > > Your comments are welcome.
> >
> > It's in -next now, for v2023.04.  Does this fix some regression already
> > present in-tree?
> >
> > >
> > > Best regards,
> > > Jim
> > >
> > > On Mon, Nov 21, 2022 at 3:41 PM Jim Liu  wrote:
> > > >
> > > > Hi  Ramon
> > > >
> > > > My upstream topic status is Awaiting Upstream.
> > > > What could I do to make it merge fast?
> > > >
> > > > Best regards,
> > > > Jim
> > > >
> > > > On Sun, Sep 18, 2022 at 2:07 PM Ramon Fried  
> > > > wrote:
> > > > >
> > > > > On Tue, Sep 13, 2022 at 9:25 AM Jim Liu  wrote:
> > > > > >
> > > > > > The original patch is use phy_get_interface_by_name to set 
> > > > > > interface.
> > > > > > The new patch is use dev_read_phy_mode to replace it.
> > > > > >
> > > > > > Signed-off-by: Jim Liu 
> > > > > > ---
> > > > > >  drivers/net/npcm750_eth.c | 8 
> > > > > >  1 file changed, 4 insertions(+), 4 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/net/npcm750_eth.c b/drivers/net/npcm750_eth.c
> > > > > > index 409d5cce4a..bd29a10def 100644
> > > > > > --- a/drivers/net/npcm750_eth.c
> > > > > > +++ b/drivers/net/npcm750_eth.c
> > > > > > @@ -710,12 +710,12 @@ static int 
> > > > > > npcm750_eth_ofdata_to_platdata(struct udevice *dev)
> > > > > >
> > > > > > pdata->phy_interface = -1;
> > > > > > phy_mode = fdt_getprop(gd->fdt_blob, dev_of_offset(dev), 
> > > > > > "phy-mode", NULL);
> > > > > > +
> > > > > > if (phy_mode)
> > > > > > -   pdata->phy_interface = 
> > > > > > phy_get_interface_by_name(phy_mode);
> > > > > > -   if (pdata->phy_interface == -1) {
> > > > > > -   printf("%s: Invalid PHY interface '%s'\n", 
> > > > > > __func__, phy_mode);
> > > > > > +   pdata->phy_interface = dev_read_phy_mode(dev);
> > > > > > +
> > > > > > +   if (pdata->phy_interface == PHY_INTERFACE_MODE_NA)
> > > > > > return -EINVAL;
> > > > > > -   }
> > > > > >
> > > > > > pdata->max_speed = 0;
> > > > > > cell = fdt_getprop(gd->fdt_blob, dev_of_offset(dev), 
> > > > > > "max-speed", NULL);
> > > > > > --
> > > > > > 2.17.1
> > > > > >
> > > > > Reviewed-by: Ramon Fried 
> >
> > --
> > Tom

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v1] net: nuvoton: fix build broken for use phy_get_interface_by_name

2022-12-12 Thread Jim Liu
Hi Tom

Thanks for your quick response.

I add defconfig patch and found this build error and i2c naming issue.
https://patchwork.ozlabs.org/project/uboot/patch/20220712092407.16567-2-jjl...@nuvoton.com/

So I add patch to fix this build error.
-> 
https://patchwork.ozlabs.org/project/uboot/patch/20220913062521.6067-1-jjl...@nuvoton.com/
-> 
https://patchwork.ozlabs.org/project/uboot/patch/20221121085932.29686-1-jjl...@nuvoton.com/

i2c patch is already merged.

Best regards,
Jim

On Tue, Dec 13, 2022 at 10:02 AM Tom Rini  wrote:
>
> On Tue, Dec 13, 2022 at 09:48:12AM +0800, Jim Liu wrote:
> > Hi Tom
> >
> > My upstream topic status is Awaiting Upstream.
> > What could I do to make it merge fast?
> > Your comments are welcome.
>
> It's in -next now, for v2023.04.  Does this fix some regression already
> present in-tree?
>
> >
> > Best regards,
> > Jim
> >
> > On Mon, Nov 21, 2022 at 3:41 PM Jim Liu  wrote:
> > >
> > > Hi  Ramon
> > >
> > > My upstream topic status is Awaiting Upstream.
> > > What could I do to make it merge fast?
> > >
> > > Best regards,
> > > Jim
> > >
> > > On Sun, Sep 18, 2022 at 2:07 PM Ramon Fried  wrote:
> > > >
> > > > On Tue, Sep 13, 2022 at 9:25 AM Jim Liu  wrote:
> > > > >
> > > > > The original patch is use phy_get_interface_by_name to set interface.
> > > > > The new patch is use dev_read_phy_mode to replace it.
> > > > >
> > > > > Signed-off-by: Jim Liu 
> > > > > ---
> > > > >  drivers/net/npcm750_eth.c | 8 
> > > > >  1 file changed, 4 insertions(+), 4 deletions(-)
> > > > >
> > > > > diff --git a/drivers/net/npcm750_eth.c b/drivers/net/npcm750_eth.c
> > > > > index 409d5cce4a..bd29a10def 100644
> > > > > --- a/drivers/net/npcm750_eth.c
> > > > > +++ b/drivers/net/npcm750_eth.c
> > > > > @@ -710,12 +710,12 @@ static int 
> > > > > npcm750_eth_ofdata_to_platdata(struct udevice *dev)
> > > > >
> > > > > pdata->phy_interface = -1;
> > > > > phy_mode = fdt_getprop(gd->fdt_blob, dev_of_offset(dev), 
> > > > > "phy-mode", NULL);
> > > > > +
> > > > > if (phy_mode)
> > > > > -   pdata->phy_interface = 
> > > > > phy_get_interface_by_name(phy_mode);
> > > > > -   if (pdata->phy_interface == -1) {
> > > > > -   printf("%s: Invalid PHY interface '%s'\n", __func__, 
> > > > > phy_mode);
> > > > > +   pdata->phy_interface = dev_read_phy_mode(dev);
> > > > > +
> > > > > +   if (pdata->phy_interface == PHY_INTERFACE_MODE_NA)
> > > > > return -EINVAL;
> > > > > -   }
> > > > >
> > > > > pdata->max_speed = 0;
> > > > > cell = fdt_getprop(gd->fdt_blob, dev_of_offset(dev), 
> > > > > "max-speed", NULL);
> > > > > --
> > > > > 2.17.1
> > > > >
> > > > Reviewed-by: Ramon Fried 
>
> --
> Tom


Re: [PATCH 1/4] riscv: spl: Introduce SPL_OPENSBI_OS_BOOT

2022-12-12 Thread Rick Chen
> On Mon, Dec 12, 2022 at 03:49:10PM +0800, Rick Chen wrote:
> > > On 12/7/22 01:23, Rick Chen wrote:
> > > > In RISC-V, it only provide normal mode booting currently.
> > > > To speed up the booting process, here provide SPL_OPENSBI_OS_BOOT
> > > > to achieve this feature which will be call Fast-Boot mode. By
> > >
> > > Can you name this something different. We already have something called
> > > fastboot in-tree (the Android-derived protocol) and there's a Microsoft
> > > technology called fastboot (some kind of hibernation). "OS Boot" isn't
> > > very specific either, since we (almost always) boot an OS. Maybe "Eagle
> > > mode" by analogy to Falcon mode, which lets SPL directly boot an OS.
> >
> > I think fast boot is a behavior which shall be interpreted widely but
> > not proprietary.
> > Or maybe I can  rename it as RISC-V Fast Boot to distinguish them.
> >
> > >
> > > (Is this substantially different from falcon mode anyway?)
> >
> > Please see the explanations to Tom.
> >
> > >
> > > > enabling SPL_OPENSBI_OS_BOOT, it will generate linux.itb instead
> > > > of default u-boot.itb after compiling. It initializes memory with
> > > > the U-Boot SPL at the first stage, just like what a regular booting
> > > > process (i.e. Normal Boot) does in the beginning. Instead of jumping
> > > > to the U-Boot proper from OpenSBI before booting Linux Kernel, the
> > > > Fast Boot process jumps directly to Linux Kernel to gain shorter
> > > > booting time.
> > > >
> > > > Signed-off-by: Rick Chen 
> > > > ---
> > > >   common/spl/Kconfig   | 14 ++
> > > >   common/spl/spl_fit.c |  3 ++-
> > > >   common/spl/spl_opensbi.c | 25 -
> > > >   3 files changed, 28 insertions(+), 14 deletions(-)
> > > >
> > > > diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> > > > index 05181bdba3..8805aba1b7 100644
> > > > --- a/common/spl/Kconfig
> > > > +++ b/common/spl/Kconfig
> > > > @@ -1509,6 +1509,20 @@ config SPL_OPENSBI_SCRATCH_OPTIONS
> > > > Options passed to fw_dynamic, for example 
> > > > SBI_SCRATCH_NO_BOOT_PRINTS or
> > > > SBI_SCRATCH_DEBUG_PRINTS.
> > > >
> > > > +config SPL_OPENSBI_OS_BOOT
> > >
> > > Please use the same name for the config as for the description.
> > >
> > > > + bool "openSBI Fast Boot"
> > > > + depends on SPL_OPENSBI
> > > > + help
> > > > +   Enable this openSBI can jump to Linux Kernel directly.
> > >
> > > Can you put some of the explanation from the commit message here?
> >
> > OK, I will move some messages here from commit messages.
> >
> > >
> > > > +
> > > > +config SPL_OPENSBI_FIT_NAME
> > > > + string "SPL openSBI fit image name"
> > > > + depends on SPL_OPENSBI
> > > > + default "linux.itb" if SPL_OPENSBI_OS_BOOT
> > > > + default "u-boot.itb"
> > > > + help
> > > > +   This will help to generate different fit name accordingly.
> > >
> > > Why not SPL_FS_LOAD_PAYLOAD_NAME?
> > >
> > > It looks like the code changes below do not use these configs. Can you
> > > move them to the next patch so it is clearer that they are for binman?
> >
> > I have saw this config, but it does't support SPL_RAM but only for 
> > filesystem
> > That is why I don't leverage it.
> >
> > I can prepare a patch as below if no other concerns:
> >
> > config SPL_FS_LOAD_PAYLOAD_NAME
> > string "File to load for U-Boot from the filesystem"
> > depends on SPL_FS_EXT4 || SPL_FS_FAT || SPL_FS_SQUASHFS || SPL_RAM
> > default "tispl.bin" if SYS_K3_SPL_ATF
> > default "u-boot.itb" if SPL_LOAD_FIT
> > default "linux.itb" if SPL_OPENSBI_OS_BOOT
> > default "u-boot.img"
> > help
> >   Filename to read to load U-Boot when reading from filesystem.
>
> But in the case you have it's for the output name, and not at all about
> what's being loaded from a filesystem yes? This shouldn't be a "SPL_.."

For SPL_RAM purpose,
it is just an output name to distinguish normal boot (u-boot.itb) and
fast boot (linux.itb) indeed.

But for SPL_OPENSBI_OS_BOOT && SPL_MMC && SPL_FAT this combination,
it can help to load linux.itb automatically from SD card.

> option, but should be under arch/riscv/Kconfig somewhere, since it's
> changing the general riscv binman.dtsi file. And on a related note,

I will fall back on the earlier changes and move
SPL_OPENSBI_OS_BOOT and SPL_OPENSBI_FIT_NAME to arch/riscv/Kconfig.

> please make sure that 'make htmldocs' is happy with your documentation
> changes as I think I see some spacing problems in 4/4.

Sorry about the spacing problems. I will check it.

Thanks,
Rick

>
> --
> Tom


Re: [PATCH v1] net: nuvoton: fix build broken for use phy_get_interface_by_name

2022-12-12 Thread Tom Rini
On Tue, Dec 13, 2022 at 09:48:12AM +0800, Jim Liu wrote:
> Hi Tom
> 
> My upstream topic status is Awaiting Upstream.
> What could I do to make it merge fast?
> Your comments are welcome.

It's in -next now, for v2023.04.  Does this fix some regression already
present in-tree?

> 
> Best regards,
> Jim
> 
> On Mon, Nov 21, 2022 at 3:41 PM Jim Liu  wrote:
> >
> > Hi  Ramon
> >
> > My upstream topic status is Awaiting Upstream.
> > What could I do to make it merge fast?
> >
> > Best regards,
> > Jim
> >
> > On Sun, Sep 18, 2022 at 2:07 PM Ramon Fried  wrote:
> > >
> > > On Tue, Sep 13, 2022 at 9:25 AM Jim Liu  wrote:
> > > >
> > > > The original patch is use phy_get_interface_by_name to set interface.
> > > > The new patch is use dev_read_phy_mode to replace it.
> > > >
> > > > Signed-off-by: Jim Liu 
> > > > ---
> > > >  drivers/net/npcm750_eth.c | 8 
> > > >  1 file changed, 4 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/drivers/net/npcm750_eth.c b/drivers/net/npcm750_eth.c
> > > > index 409d5cce4a..bd29a10def 100644
> > > > --- a/drivers/net/npcm750_eth.c
> > > > +++ b/drivers/net/npcm750_eth.c
> > > > @@ -710,12 +710,12 @@ static int npcm750_eth_ofdata_to_platdata(struct 
> > > > udevice *dev)
> > > >
> > > > pdata->phy_interface = -1;
> > > > phy_mode = fdt_getprop(gd->fdt_blob, dev_of_offset(dev), 
> > > > "phy-mode", NULL);
> > > > +
> > > > if (phy_mode)
> > > > -   pdata->phy_interface = 
> > > > phy_get_interface_by_name(phy_mode);
> > > > -   if (pdata->phy_interface == -1) {
> > > > -   printf("%s: Invalid PHY interface '%s'\n", __func__, 
> > > > phy_mode);
> > > > +   pdata->phy_interface = dev_read_phy_mode(dev);
> > > > +
> > > > +   if (pdata->phy_interface == PHY_INTERFACE_MODE_NA)
> > > > return -EINVAL;
> > > > -   }
> > > >
> > > > pdata->max_speed = 0;
> > > > cell = fdt_getprop(gd->fdt_blob, dev_of_offset(dev), 
> > > > "max-speed", NULL);
> > > > --
> > > > 2.17.1
> > > >
> > > Reviewed-by: Ramon Fried 

-- 
Tom


signature.asc
Description: PGP signature


[PATCH v2] serial: ns16550: Enable clocks during probe

2022-12-12 Thread Samuel Holland
If the UART bus clock has a gate, it must be enabled before the UART
can be used.

Signed-off-by: Samuel Holland 
---

Changes in v2:
 - Only enable the first clock, as using the clk_get_bulk() API pushes
   a board (phycore-rk3288) over its SPL size limit.

 drivers/serial/ns16550.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index 7592979cab5..072419343a3 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -507,6 +507,7 @@ int ns16550_serial_probe(struct udevice *dev)
struct ns16550 *const com_port = dev_get_priv(dev);
struct reset_ctl_bulk reset_bulk;
fdt_addr_t addr;
+   struct clk clk;
int ret;
 
/*
@@ -524,6 +525,10 @@ int ns16550_serial_probe(struct udevice *dev)
if (!ret)
reset_deassert_bulk(_bulk);
 
+   ret = clk_get_by_index(dev, 0, );
+   if (!ret)
+   clk_enable();
+
com_port->plat = dev_get_plat(dev);
ns16550_init(com_port, -1);
 
-- 
2.37.4



Re: [PATCH v1] net: nuvoton: fix build broken for use phy_get_interface_by_name

2022-12-12 Thread Jim Liu
Hi Tom

My upstream topic status is Awaiting Upstream.
What could I do to make it merge fast?
Your comments are welcome.

Best regards,
Jim

On Mon, Nov 21, 2022 at 3:41 PM Jim Liu  wrote:
>
> Hi  Ramon
>
> My upstream topic status is Awaiting Upstream.
> What could I do to make it merge fast?
>
> Best regards,
> Jim
>
> On Sun, Sep 18, 2022 at 2:07 PM Ramon Fried  wrote:
> >
> > On Tue, Sep 13, 2022 at 9:25 AM Jim Liu  wrote:
> > >
> > > The original patch is use phy_get_interface_by_name to set interface.
> > > The new patch is use dev_read_phy_mode to replace it.
> > >
> > > Signed-off-by: Jim Liu 
> > > ---
> > >  drivers/net/npcm750_eth.c | 8 
> > >  1 file changed, 4 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/net/npcm750_eth.c b/drivers/net/npcm750_eth.c
> > > index 409d5cce4a..bd29a10def 100644
> > > --- a/drivers/net/npcm750_eth.c
> > > +++ b/drivers/net/npcm750_eth.c
> > > @@ -710,12 +710,12 @@ static int npcm750_eth_ofdata_to_platdata(struct 
> > > udevice *dev)
> > >
> > > pdata->phy_interface = -1;
> > > phy_mode = fdt_getprop(gd->fdt_blob, dev_of_offset(dev), 
> > > "phy-mode", NULL);
> > > +
> > > if (phy_mode)
> > > -   pdata->phy_interface = 
> > > phy_get_interface_by_name(phy_mode);
> > > -   if (pdata->phy_interface == -1) {
> > > -   printf("%s: Invalid PHY interface '%s'\n", __func__, 
> > > phy_mode);
> > > +   pdata->phy_interface = dev_read_phy_mode(dev);
> > > +
> > > +   if (pdata->phy_interface == PHY_INTERFACE_MODE_NA)
> > > return -EINVAL;
> > > -   }
> > >
> > > pdata->max_speed = 0;
> > > cell = fdt_getprop(gd->fdt_blob, dev_of_offset(dev), "max-speed", 
> > > NULL);
> > > --
> > > 2.17.1
> > >
> > Reviewed-by: Ramon Fried 


Re: [PATCH] serial: ns16550: Enable clocks during probe

2022-12-12 Thread Samuel Holland
On 12/12/22 12:54, Tom Rini wrote:
> On Sun, Nov 27, 2022 at 11:48:34PM -0600, Samuel Holland wrote:
> 
>> If the UART bus or baud clock has a gate, it must be enabled before the
>> UART can be used.
>>
>> Signed-off-by: Samuel Holland 
>> Reviewed-by: Stefan Roese 
> 
> This breaks building on phycore-rk3288

I get:

binman: Error 1 running 'mkimage -d ./mkimage.simple-bin.mkimage -n
rk3288 -T rksd ./idbloader.img': Error: SPL image is too large (size
0x8800 than 0x8000)

Before applying this patch:

$ ls -l spl/u-boot-spl.bin
-rw-r--r-- 1 samuel samuel 32704 Dec 12 19:35 spl/u-boot-spl.bin

So the board was quite close to its SPL size limit already.

I was trying to be general with this patch, but I suppose for my
immediate purposes (Allwinner D1), I only care about the first clock. If
I use clk_get_by_index() instead of clk_get_bulk(), the phycore-rk3288
build passes with 4 bytes to spare:

$ ls -l spl/u-boot-spl.bin
-rw-r--r-- 1 samuel samuel 32760 Dec 12 19:36 spl/u-boot-spl.bin

I will send a v2, but I imagine some other unsuspecting patch will run
into this limit again before long.

Regards,
Samuel



Re: [PATCH 1/4] riscv: spl: Introduce SPL_OPENSBI_OS_BOOT

2022-12-12 Thread Rick Chen
Hi Tom

> On Mon, Dec 12, 2022 at 02:45:10PM +0800, Rick Chen wrote:
> > Hi Tom
> >
> > > On Fri, Dec 09, 2022 at 08:48:37AM -0500, Sean Anderson wrote:
> > > > On 12/7/22 01:23, Rick Chen wrote:
> > > > > In RISC-V, it only provide normal mode booting currently.
> > > > > To speed up the booting process, here provide SPL_OPENSBI_OS_BOOT
> > > > > to achieve this feature which will be call Fast-Boot mode. By
> > > >
> > > > Can you name this something different. We already have something called
> > > > fastboot in-tree (the Android-derived protocol) and there's a Microsoft
> > > > technology called fastboot (some kind of hibernation). "OS Boot" isn't
> > > > very specific either, since we (almost always) boot an OS. Maybe "Eagle
> > > > mode" by analogy to Falcon mode, which lets SPL directly boot an OS.
> > > >
> > > > (Is this substantially different from falcon mode anyway?)
> > >
> > > I was kind of wondering if this is different, really, from Falcon Mode.
> > > Falcon Mode didn't initially have to factor in other-firmware as that's
> > > not a hard requirement on arm32 like it is on arm64 or risc-v.  But my
> > > first read of this was that it seems like the RISC-V specific side of
> > > doing Falcon Mode and dealing with the prior stage needs correctly.
> > >
> >
> > Yes. It is a little bit different from the Falcon mode (SPL_OS_BOOT=y).
> > When I try to enable SPL_OS_BOOT, it will encounter that SYS_SPL_ARGS_ADDR 
> > and
> >  jump_to_image_linux() shall be defined but they are un-necessary for 
> > RISC-V.
> > Because the flow of OpenSBI and SPL_OS_BOOT are totally different code
> > flow in board_init_r() of common/spl/spl.c.
> > That is why I added a new symbol called SPL_OPENSBI_OS_BOOT for this
> > RISC-V fast boot implementation.
>
> Those sound like fairly minor challenges for the same fundamental
> concept. We have SYS_SPL_ARGS_ADDR for "where is the device tree to
> pass along". We might need to do a little code re-factoring here. But
> maybe also a little bit of explaining why we wouldn't be booting to the
> OS directly but instead passing back to openSBI to do this? That's not
> normally how RISC-V boots the OS, right? Or am I miss-understanding
> something here?

Because RISC-V Linux runs in S-Mode, it needs OpenSBI which runs in
M-mode to handle SBI calls.
So it can not boot Linux (OS) directly from U-Boot SPL but passing
back to openSBI to do this.

Rick

>
> --
> Tom


Re: Converting to DM SERIAL for Kirkwood boards

2022-12-12 Thread Tony Dinh
Hi Michael,

On Mon, Dec 12, 2022 at 1:03 AM Michael Walle  wrote:
>
> >> On 12/9/22 04:55, Tony Dinh wrote:
> >> > Hi Simon et al,
> >> >
> >> > (Resend to include u-boot mailing list)
> >> >
> >> > I'm in the process of converting Kirkwood boards to use DM SERIAL. I
> >> > could not seem to get it to work, having tried adding
> >> > CONFIG_DM_SERIAL, and also playing with various  related CONFIG
> >> > options  (CONFIG_SPECIFY_CONSOLE_INDEX and CONFIG_CONS_INDEX ). From
> >> > my reading various board configurations that were already converted to
> >> > DM_SERIAL, I'm under the impression that just turning on
> >> > CONFIG_DM_SERIAL would work without any other addition.
> >> >
> >> > The board I'm testing is Zyxel NSA310S Kirkwood 6702 (6192) SoC.
> >> >
> >> > diff --git a/configs/nsa310s_defconfig b/configs/nsa310s_defconfig
> >> > index afa0cad041..e81d1495bd 100644
> >> > --- a/configs/nsa310s_defconfig
> >> > +++ b/configs/nsa310s_defconfig
> >> > @@ -41,7 +41,6 @@ CONFIG_ENV_OVERWRITE=y
> >> >   CONFIG_ENV_IS_IN_NAND=y
> >> >   CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> >> >   CONFIG_NET_RANDOM_ETHADDR=y
> >> > -CONFIG_NETCONSOLE=y
> >> >   CONFIG_SYS_FAULT_ECHO_LINK_DOWN=y
> >> >   CONFIG_SATA_MV=y
> >> >   CONFIG_SYS_SATA_MAX_DEVICE=1
> >> > @@ -53,6 +52,7 @@ CONFIG_MTD_RAW_NAND=y
> >> >   CONFIG_PHY_MARVELL=y
> >> >   CONFIG_MVGBE=y
> >> >   CONFIG_MII=y
> >> > +CONFIG_DM_SERIAL=y
> >> >   CONFIG_SYS_NS16550=y
> >> >   CONFIG_USB=y
> >> >   CONFIG_USB_EHCI_HCD=y
> >> >
> >> > I also added kirkwood-nsa310s-u-boot.dtsi to help in running kwboot.
> >> >
> >> >  {
> >> > u-boot,dm-pre-reloc;
> >> > };
> >> >
> >> > I've tried kwboot the new u-boot image, and also flashed this image to
> >> > NAND, and in both cases, I got a silent serial console. It seems to
> >> > hang up right off the bat. Hope you can help by giving me some
> >> > pointers on how to debug this.
> >>
> >> Might be that the alias is missing and / or that the uart DT node is
> >> not enabled. Please give this test-only patch a try:
> >>
> >> diff --git a/arch/arm/dts/kirkwood-nsa310s.dts
> >> b/arch/arm/dts/kirkwood-nsa310s.dts
> >> index 09ee76c2a2e0..ca7a49af9ba4 100644
> >> --- a/arch/arm/dts/kirkwood-nsa310s.dts
> >> +++ b/arch/arm/dts/kirkwood-nsa310s.dts
> >> @@ -17,6 +17,10 @@
> >>  model = "Zyxel NSA310S";
> >>  compatible = "zyxel,nsa320s", "marvell,kirkwood-88f6702",
> >> "marvell,kirkwood";
> >>
> >> +   aliases {
> >> +   serial0 = 
> >> +   };
> >> +
> >>  memory {
> >>  device_type = "memory";
> >>  reg = <0x 0x1000>;
> >> @@ -317,3 +321,8 @@
> >>{
> >>  status = "okay";
> >>   };
> >> +
> >> + {
> >> +   status = "okay";
> >> +   u-boot,dm-pre-reloc;
> >> +};
> >
> > Thanks for the patch! but the behavior is still the same (silent
> > serial console and hung the board).
> >
> > Thanks,
> > Tony
>
> Maybe this will help:
> https://lore.kernel.org/u-boot/20220817193809.1059688-20-mich...@walle.cc/
>
> The lsxl is also a kirkwood based board.
>

Thanks! indeed that was the malloc problem. This NSA310S board is now
working with DM_SERIAL.

I will test a few more Kirkwood boards and keep everybody posted.

All the best,
Tony

> -michael


Re: [PATCH 1/4] riscv: spl: Introduce SPL_OPENSBI_OS_BOOT

2022-12-12 Thread Rick Chen
Hi Sean,

> On 12/12/22 10:03, Tom Rini wrote:
> > On Mon, Dec 12, 2022 at 02:45:10PM +0800, Rick Chen wrote:
> >> Hi Tom
> >>
> >>> On Fri, Dec 09, 2022 at 08:48:37AM -0500, Sean Anderson wrote:
>  On 12/7/22 01:23, Rick Chen wrote:
> > In RISC-V, it only provide normal mode booting currently.
> > To speed up the booting process, here provide SPL_OPENSBI_OS_BOOT
> > to achieve this feature which will be call Fast-Boot mode. By
> 
>  Can you name this something different. We already have something called
>  fastboot in-tree (the Android-derived protocol) and there's a Microsoft
>  technology called fastboot (some kind of hibernation). "OS Boot" isn't
>  very specific either, since we (almost always) boot an OS. Maybe "Eagle
>  mode" by analogy to Falcon mode, which lets SPL directly boot an OS.
> 
>  (Is this substantially different from falcon mode anyway?)
> >>>
> >>> I was kind of wondering if this is different, really, from Falcon Mode.
> >>> Falcon Mode didn't initially have to factor in other-firmware as that's
> >>> not a hard requirement on arm32 like it is on arm64 or risc-v.  But my
> >>> first read of this was that it seems like the RISC-V specific side of
> >>> doing Falcon Mode and dealing with the prior stage needs correctly.
> >>>
> >>
> >> Yes. It is a little bit different from the Falcon mode (SPL_OS_BOOT=y).
> >> When I try to enable SPL_OS_BOOT, it will encounter that SYS_SPL_ARGS_ADDR 
> >> and
> >>   jump_to_image_linux() shall be defined but they are un-necessary for 
> >> RISC-V.
> >> Because the flow of OpenSBI and SPL_OS_BOOT are totally different code
> >> flow in board_init_r() of common/spl/spl.c.
> >> That is why I added a new symbol called SPL_OPENSBI_OS_BOOT for this
> >> RISC-V fast boot implementation.
> >
> > Those sound like fairly minor challenges for the same fundamental
> > concept. We have SYS_SPL_ARGS_ADDR for "where is the device tree to
> > pass along". We might need to do a little code re-factoring here. But
> > maybe also a little bit of explaining why we wouldn't be booting to the
> > OS directly but instead passing back to openSBI to do this? That's not
> > normally how RISC-V boots the OS, right? Or am I miss-understanding
> > something here?
> >
>
> The usual process is
>
> ROM -> SPL -> SBI -> U-Boot -> Linux

In RISC-V, Linux runs in S-mode, it needs the OpenSBI which plays as
M-mode to deal with SBI calls at run-time.
So the fast boot idea, I just want to bypass U-Boot and jump to Linux
directly and Linux still needs OpenSBI.
Hence SPL_OPENSBI can't be disabled here.

Rick

>
> Where SPL loads SBI and U-Boot and tells SBI "please run U-Boot after you are
> done booting". But the idea here is to load Linux instead of U-Boot. I think
> this is pretty similar to Falcon mode. Actually, when CONFIG_SPL_OPENSBI is
> enabled, I think it's reasonable for falcon mode to do exactly that. People
> who want the SPL -> Linux path can disable SPL_OPENSBI.
>
> --Sean


Re: [PATCH 1/4] riscv: spl: Introduce SPL_OPENSBI_OS_BOOT

2022-12-12 Thread Sean Anderson

On 12/12/22 10:03, Tom Rini wrote:

On Mon, Dec 12, 2022 at 02:45:10PM +0800, Rick Chen wrote:

Hi Tom


On Fri, Dec 09, 2022 at 08:48:37AM -0500, Sean Anderson wrote:

On 12/7/22 01:23, Rick Chen wrote:

In RISC-V, it only provide normal mode booting currently.
To speed up the booting process, here provide SPL_OPENSBI_OS_BOOT
to achieve this feature which will be call Fast-Boot mode. By


Can you name this something different. We already have something called
fastboot in-tree (the Android-derived protocol) and there's a Microsoft
technology called fastboot (some kind of hibernation). "OS Boot" isn't
very specific either, since we (almost always) boot an OS. Maybe "Eagle
mode" by analogy to Falcon mode, which lets SPL directly boot an OS.

(Is this substantially different from falcon mode anyway?)


I was kind of wondering if this is different, really, from Falcon Mode.
Falcon Mode didn't initially have to factor in other-firmware as that's
not a hard requirement on arm32 like it is on arm64 or risc-v.  But my
first read of this was that it seems like the RISC-V specific side of
doing Falcon Mode and dealing with the prior stage needs correctly.



Yes. It is a little bit different from the Falcon mode (SPL_OS_BOOT=y).
When I try to enable SPL_OS_BOOT, it will encounter that SYS_SPL_ARGS_ADDR and
  jump_to_image_linux() shall be defined but they are un-necessary for RISC-V.
Because the flow of OpenSBI and SPL_OS_BOOT are totally different code
flow in board_init_r() of common/spl/spl.c.
That is why I added a new symbol called SPL_OPENSBI_OS_BOOT for this
RISC-V fast boot implementation.


Those sound like fairly minor challenges for the same fundamental
concept. We have SYS_SPL_ARGS_ADDR for "where is the device tree to
pass along". We might need to do a little code re-factoring here. But
maybe also a little bit of explaining why we wouldn't be booting to the
OS directly but instead passing back to openSBI to do this? That's not
normally how RISC-V boots the OS, right? Or am I miss-understanding
something here?



The usual process is

ROM -> SPL -> SBI -> U-Boot -> Linux

Where SPL loads SBI and U-Boot and tells SBI "please run U-Boot after you are
done booting". But the idea here is to load Linux instead of U-Boot. I think
this is pretty similar to Falcon mode. Actually, when CONFIG_SPL_OPENSBI is
enabled, I think it's reasonable for falcon mode to do exactly that. People
who want the SPL -> Linux path can disable SPL_OPENSBI.

--Sean


Re: [PATCH] Makefile: With BINMAN_ALLOW_MISSING=1 don't error on missing

2022-12-12 Thread Tom Rini
On Tue, Dec 06, 2022 at 10:03:37AM -0500, Tom Rini wrote:
> On Tue, Dec 06, 2022 at 03:36:49PM +1300, Simon Glass wrote:
> > Hi Tom,
> > 
> > On Tue, 6 Dec 2022 at 15:03, Tom Rini  wrote:
> > >
> > > When the user builds with BINMAN_ALLOW_MISSING=1 they're explicitly
> > > setting the flag to allow for additional binaries to be missing and so
> > > have acknowledged the output might not work. In this case we want to
> > > default to not passing a non-zero exit code.
> > >
> > > Cc: Simon Glass 
> > > Reported-by: Peter Robinson 
> > > Signed-off-by: Tom Rini 
> > > ---
> > > This passes CI as-is:
> > > https://source.denx.de/u-boot/u-boot/-/pipelines/14340
> > > ---
> > >  Makefile | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/Makefile b/Makefile
> > > index de5746399a63..03de1da1bfd0 100644
> > > --- a/Makefile
> > > +++ b/Makefile
> > > @@ -1334,7 +1334,7 @@ cmd_binman = $(srctree)/tools/binman/binman $(if 
> > > $(BINMAN_DEBUG),-D) \
> > >  --toolpath $(objtree)/tools \
> > > $(if $(BINMAN_VERBOSE),-v$(BINMAN_VERBOSE)) \
> > > build -u -d u-boot.dtb -O . -m \
> > > -   $(if $(BINMAN_ALLOW_MISSING),--allow-missing 
> > > --fake-ext-blobs) \
> > > +   $(if $(BINMAN_ALLOW_MISSING),--allow-missing 
> > > --ignore-missing) \
> > > -I . -I $(srctree) -I $(srctree)/board/$(BOARDDIR) \
> > > -I arch/$(ARCH)/dts -a of-list=$(CONFIG_OF_LIST) \
> > > $(foreach f,$(BINMAN_INDIRS),-I $(f)) \
> > > --
> > > 2.25.1
> > >
> > 
> > I believe we need the --fake-ext-blobs flag as well, since otherwise
> > boards which use tools (like mkimage) on things that don't exist will
> > not work.
> 
> So, we need to list out all the use cases perhaps, as we had missed one
> before. In my mind we have:
> - Board requires 1 or more blobs, developer will be running this on
>   hardware, expects output from U-Boot 'make' (or buildman) to boot.
>   Blobs must be present or non-zero exist status by default.
>   We didn't have this before, and we do now.
> - Board requires 1 or more blobs AND has optional blobs, will be running
>   this on hardware, expects output from U-Boot 'make' (or buildman) to
>   boot. This is the case we had missed before as allwinner requires bl31
>   and has optional PMIC firmware. This is the case Peter reported and we
>   had missed before, which this patch allows for, with the caveat that
>   if you forget BL31 you're not going to boot and make won't complain
>   exit-code wise. Another way to resolve this would be a property in the
>   binman node to mark a blob as optional and warn if missing, rather
>   than error if missing.
> - Board requires 1 or more blobs, output will NOT be run. This is the CI
>   case and the compile testing lots of board cases. This is what CI
>   passes still, with the above.
> - Board requires 1 or more blobs, developer will be running this on
>   hardware, BUT will be injecting the blobs later on. I think this is
>   the use case you're talking about?

Simon, can you test this last case by chance? I think that's the one
that's unclear about if this patch breaks or not and I want to know if I
need to respin to still include the fake blobs flag still too or not.
Or does anyone else use this case and can test?

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] tpm2: ftpm: open session with privileged ree login

2022-12-12 Thread Ilias Apalodimas
On Wed, Dec 07, 2022 at 04:25:33PM +0100, Etienne Carriere wrote:
> Opens the fTPM session with TEE_LOGIN_REE_KERNEL as fTPM may restrict
> access to that login when Linux based OS is running as applications are
> expected to got through the Linux TPMv2 driver.
>
> Signed-off-by: Etienne Carriere 
> ---
>  drivers/tpm/tpm2_ftpm_tee.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/tpm/tpm2_ftpm_tee.c b/drivers/tpm/tpm2_ftpm_tee.c
> index 53e59f42b4..3c4c12983d 100644
> --- a/drivers/tpm/tpm2_ftpm_tee.c
> +++ b/drivers/tpm/tpm2_ftpm_tee.c
> @@ -186,6 +186,7 @@ static int ftpm_tee_probe(struct udevice *dev)
>
>   /* Open a session with the fTPM TA */
>   memset(_arg, 0, sizeof(sess_arg));
> + sess_arg.clnt_login = TEE_LOGIN_REE_KERNEL;
>   tee_optee_ta_uuid_to_octets(sess_arg.uuid, );
>
>   rc = tee_open_session(context->tee_dev, _arg, 0, NULL);
> --
> 2.25.1
>

Reviewed-by: Ilias Apalodimas 



Re: [PATCH] drivers: pci: pcie_dw_common: add upper-limit to iATU

2022-12-12 Thread Tom Rini
On Thu, Oct 20, 2022 at 04:51:09PM +0100, Ben Dooks wrote:

> The 4.6 spec added an upper 32bits to the ATU limit, and since this
> driver is already assuming the unrolled feature added in the 4.8
> specification this really should be set.
> 
> This is causing a bug with testing against the QEMU model as it
> defaults the viewports to fully open and not setting this causes
> the config viewport to become most of memory (obviously stopping
> the emulated system working correctly)
> 
> Signed-off-by: Ben Dooks 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] configs: set CONFIG_LMB_MAX_REGIONS=64 for all mt798[16] boards

2022-12-12 Thread Tom Rini
On Tue, Nov 29, 2022 at 07:37:59PM +, Daniel Golle wrote:

> With recently added wireless offloading features in Linux [1] the
> number of reserved memory regions with MediaTek SoCs supporting
> offloading wireless-to-Ethernet traffic grew beyond the default (8)
> which breaks booting Linux:
> ERROR: Failed to allocate 0xa6ac bytes below 0xc000.
> device tree - allocation error
> FDT creation failed!
> resetting ...
> 
> Raise CONFIG_LMB_MAX_REGIONS to 64 like it is already done for other
> SoCs which require a larger number of reserved memory regions, eg.
> exynos78x0 based a3y17lte, a5y17lte and a7y17lte or dragonboard845c.
> 
> [1]: 
> https://lore.kernel.org/netdev/e3489a697b404bd47447190cd2e5adf090ae61c2.1667687249.git.lore...@kernel.org/
>  
> https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=eed4f1ddad8c5ad7596b229caec8bd7b477b81ee
> 
> Signed-off-by: Daniel Golle 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] arm: mach-omap2: Move common image process functions out of board files

2022-12-12 Thread Tom Rini
On Thu, Oct 20, 2022 at 12:12:19PM -0500, Andrew Davis wrote:

> The functions board_fit_image_post_process() and board_tee_image_process()
> are not actually board specific (despite their names). Any board using the
> OMAP2 family can use these functions. Move them to boot-common.c.
> 
> Signed-off-by: Andrew Davis 
> Reviewed-by: Tom Rini 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 1/2] omap4: make musb probeable by simple bus

2022-12-12 Thread Tom Rini
On Sat, Nov 26, 2022 at 11:30:09PM +0100, Andreas Kemnade wrote:

> Like other peripherals important for booting,
> do not rely on ti-sysc compatibility alone
> 
> Signed-off-by: Andreas Kemnade 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v1] ARM: dts: npcm7xx: add npcm750 gpio node compatible name

2022-12-12 Thread Tom Rini
On Mon, Nov 28, 2022 at 10:34:47AM +0800, Jim Liu wrote:

> Add npcm750 gpio node compatible name
> 
> Signed-off-by: Jim Liu 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v1 2/2] ARM: dts: npcm8xx: add npcm845 function node

2022-12-12 Thread Tom Rini
On Mon, Nov 28, 2022 at 10:32:44AM +0800, Jim Liu wrote:

> 1. add usb phy
> 2. add ehci ohci sdhci
> 3. add pinctrl node
> 4. add fiu node
> 
> Signed-off-by: Jim Liu 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v1 1/2] ARM: config: enable function for nuvoton npcm845 bmc

2022-12-12 Thread Tom Rini
On Mon, Nov 28, 2022 at 10:32:43AM +0800, Jim Liu wrote:

> Signed-off-by: Jim Liu 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] distro/pxeboot: Handle prompt variable

2022-12-12 Thread Tom Rini
On Fri, Nov 18, 2022 at 09:00:27AM +0100, Manuel Traut wrote:

> Regarding the documentation found here:
> https://github.com/u-boot/u-boot/blob/master/common/menu.c#L347
> 
> If both timeout and prompt is set to 0 the default entry shall
> be booted immediately. However the current behaviour is that
> the prompt is shown (tested with distroboot) until the user
> selects an entry (no timeout).
> 
> This change implements a behaviour as documented. It was tested
> with distroboot.
> 
> Signed-off-by: Manuel Traut 
> Reviewed-by: Simon Glass 
> Reviewed-by: Simon Glass 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 3/3] cmd: pxe: use strdup to copy config

2022-12-12 Thread Tom Rini
On Fri, Oct 28, 2022 at 11:01:20AM +0200, Patrick Delaunay wrote:

> Replace malloc and strcpy by strdup in
> function parse_label_kernel.
> 
> Signed-off-by: Patrick Delaunay 
> Reviewed-by: Neil Armstrong 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 2/3] cmd: pxe: support INITRD and FDT selection with FIT

2022-12-12 Thread Tom Rini
On Fri, Oct 28, 2022 at 11:01:19AM +0200, Patrick Delaunay wrote:

> Since the commit d5ba6188dfbf ("cmd: pxe_utils: Check fdtcontroladdr
> in label_boot") the FDT or the FDTDIR label is required in extlinux.conf
> and the fallback done by bootm command when only the device tree present
> in this command parameters is no more performed when FIT is used for
> kernel.
> 
> When the label FDT or FDTDIR are absent or if the device tree file is
> absent, the PXE command in U-Boot uses the default U-Boot device tree
> selected by fdtcontroladdr = gd->fdt_blob, it is the "Scenario 3".
> 
> With this scenario the bootm FIP fallback is no more possible with
> the extlinux.conf when only "kernel" label is present and is a FIP:
> 
>   kernel #[# 
> As the U-Boot FDT is always provided in the third bootm argument,
> the device tree found in FIP is not used as fallback, it was done
> previously in boot_get_fdt().
> 
> This patch adds a new field kernel_label to save the full kernel label.
> The FDT bootm parameters use the kernel address (to avoid to load a
> second time the same FIP) and the config when this full label is reused
> for "fdt" or "initrd" label.
> 
> This FIP support in extlinux.conf is restored when the "FDT" label
> can be found and select the same FIP (identical file and configuration):
> 
>   kernel #[#   fdt #[# 
> The patch add also this possibility for initrd.
> 
>   initrd #[# 
> Signed-off-by: Patrick Delaunay 
> Reviewed-by: Neil Armstrong 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 1/3] cmd: pxe: reorder kernel treatment in label_boot

2022-12-12 Thread Tom Rini
On Fri, Oct 28, 2022 at 11:01:18AM +0200, Patrick Delaunay wrote:

> Reorder kernel treatment in label_boot at the beginning of the function.
> 
> This patch doesn't change the pxe command behavior, it is only a
> preliminary step for next patch, build kernel_addr before parsing
> the label initrd and fdt to build the next bootm arguments.
> 
> Signed-off-by: Patrick Delaunay 
> Reviewed-by: Neil Armstrong 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] net: Fix memory corruption in eth_halt() if the stop handler frees the priv member

2022-12-12 Thread Fabio Estevam
Hi Bernhard,

On Mon, Dec 12, 2022 at 6:12 PM Bernhard Rosenkränzer  wrote:
>
> Calling eth_halt() could result in memory corruption if the stop()
> handler frees or modifies the priv member.
>
> A stored value of dev_get_uclass_priv() is assumed to remain valid
> after the stop() handler has been called, which is not always the
> case (e.g. rndis over usb gadget).
>
> Re-check the priv pointer after calling the stop() handler.
>
> Signed-off-by: Bernhard Rosenkränzer 
> ---
>  net/eth-uclass.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/net/eth-uclass.c b/net/eth-uclass.c
> index f41da4b37b..410f3310c7 100644
> --- a/net/eth-uclass.c
> +++ b/net/eth-uclass.c
> @@ -343,6 +343,11 @@ void eth_halt(void)
> return;
>
> eth_get_ops(current)->stop(current);
> +
> +   priv = dev_get_uclass_priv(current);
> +   if (!priv || !priv->running)
> +   return;
> +

Niel submitted the same fix:
https://lists.denx.de/pipermail/u-boot/2022-December/502055.html


[PATCH] net: Fix memory corruption in eth_halt() if the stop handler frees the priv member

2022-12-12 Thread Bernhard Rosenkränzer
Calling eth_halt() could result in memory corruption if the stop()
handler frees or modifies the priv member.

A stored value of dev_get_uclass_priv() is assumed to remain valid
after the stop() handler has been called, which is not always the
case (e.g. rndis over usb gadget).

Re-check the priv pointer after calling the stop() handler.

Signed-off-by: Bernhard Rosenkränzer 
---
 net/eth-uclass.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/net/eth-uclass.c b/net/eth-uclass.c
index f41da4b37b..410f3310c7 100644
--- a/net/eth-uclass.c
+++ b/net/eth-uclass.c
@@ -343,6 +343,11 @@ void eth_halt(void)
return;
 
eth_get_ops(current)->stop(current);
+
+   priv = dev_get_uclass_priv(current);
+   if (!priv || !priv->running)
+   return;
+
priv->state = ETH_STATE_PASSIVE;
priv->running = false;
 }
-- 
2.38.1



Re: [PATCH v4 1/5] image: Add fallback for fit_config_verify

2022-12-12 Thread Tom Rini
On Mon, Dec 12, 2022 at 02:12:07PM -0500, Sean Anderson wrote:

> Add a fallback for this function so it can be used without regard to
> whether FIT_SIGNATURE is enabled or not.
> 
> Signed-off-by: Sean Anderson 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature


[PATCH v4 5/5] cmd: source: Support specifying config name

2022-12-12 Thread Sean Anderson
As discussed previously [1,2], the source command is not safe to use with
verified boot unless there is a key with required = "images" (which has its
own problems). This is because if such a key is absent, signatures are
verified but not required. It is assumed that configuration nodes will
provide the signature. Because the source command does not use
configurations to determine the image to source, effectively no
verification takes place.

To address this, allow specifying configuration nodes. We use the same
syntax as the bootm command (helpfully provided for us by fit_parse_conf).
By default, we first try the default config and then the default image. To
force using a config, # must be present in the command (e.g. `source
$loadaddr#my-conf`). For convenience, the config may be omitted, just like
the address may be (e.g. `source \#`). This also works for images
(`source :` behaves exactly like `source` currently does).

[1] 
https://lore.kernel.org/u-boot/7d711133-d513-5bcb-52f2-a9dbaa9ee...@prevas.dk/
[2] 
https://lore.kernel.org/u-boot/042dcb34-f85f-351e-1b0e-513f89005...@gmail.com/

Signed-off-by: Sean Anderson 
Reviewed-by: Simon Glass 
---

Changes in v4:
- Fix fit_conf_get_prop_node missing a phase

Changes in v3:
- Halve the quotes

 .../cmd_stm32prog/cmd_stm32prog.c |  2 +-
 boot/bootmeth_script.c|  2 +-
 cmd/source.c  | 74 +--
 doc/uImage.FIT/source_file_format.txt |  3 +
 drivers/usb/gadget/f_sdp.c|  2 +-
 include/image.h   | 19 +++--
 test/py/tests/test_source.py  | 11 ++-
 7 files changed, 83 insertions(+), 30 deletions(-)

diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c 
b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
index 3627b4c35c..cb13a14d82 100644
--- a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
+++ b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
@@ -154,7 +154,7 @@ static int do_stm32prog(struct cmd_tbl *cmdtp, int flag, 
int argc,
do_bootz(cmdtp, 0, 4, bootm_argv);
}
if (data->script)
-   image_source_script(data->script, NULL);
+   image_source_script(data->script, NULL, NULL);
 
if (reset) {
puts("Reset...\n");
diff --git a/boot/bootmeth_script.c b/boot/bootmeth_script.c
index d1c3f94003..6c84721d1c 100644
--- a/boot/bootmeth_script.c
+++ b/boot/bootmeth_script.c
@@ -101,7 +101,7 @@ static int script_boot(struct udevice *dev, struct bootflow 
*bflow)
log_debug("mmc_bootdev: %s\n", env_get("mmc_bootdev"));
 
addr = map_to_sysmem(bflow->buf);
-   ret = image_source_script(addr, NULL);
+   ret = image_source_script(addr, NULL, NULL);
if (ret)
return log_msg_ret("boot", ret);
 
diff --git a/cmd/source.c b/cmd/source.c
index 5973824601..94da5d8d6a 100644
--- a/cmd/source.c
+++ b/cmd/source.c
@@ -42,7 +42,7 @@ static const char *get_default_image(const void *fit)
 }
 #endif
 
-int image_source_script(ulong addr, const char *fit_uname)
+int image_source_script(ulong addr, const char *fit_uname, const char 
*confname)
 {
ulong   len;
 #if defined(CONFIG_LEGACY_IMAGE_FORMAT)
@@ -112,19 +112,47 @@ int image_source_script(ulong addr, const char *fit_uname)
return 1;
}
 
-   if (!fit_uname)
-   fit_uname = get_default_image(fit_hdr);
-
if (!fit_uname) {
-   puts("No FIT subimage unit name\n");
-   return 1;
-   }
+   /* If confname is empty, use the default */
+   if (confname && *confname)
+   noffset = fit_conf_get_node(fit_hdr, confname);
+   else
+   noffset = fit_conf_get_node(fit_hdr, NULL);
+   if (noffset < 0) {
+   if (!confname)
+   goto fallback;
+   printf("Could not find config %s\n", confname);
+   return 1;
+   }
 
-   /* get script component image node offset */
-   noffset = fit_image_get_node (fit_hdr, fit_uname);
-   if (noffset < 0) {
-   printf ("Can't find '%s' FIT subimage\n", fit_uname);
-   return 1;
+   if (verify && fit_config_verify(fit_hdr, noffset))
+   return 1;
+
+   noffset = fit_conf_get_prop_node(fit_hdr, noffset,
+FIT_SCRIPT_PROP,
+IH_PHASE_NONE);
+   if (noffset < 0) {
+   if (!confname)
+  

[PATCH v4 4/5] cmd: source: Clean up a few lines

2022-12-12 Thread Sean Anderson
This simplifies a few lines and corrects an error message.

Signed-off-by: Sean Anderson 
Reviewed-by: Simon Glass 
---

(no changes since v1)

 cmd/source.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/cmd/source.c b/cmd/source.c
index 698d9f86d9..5973824601 100644
--- a/cmd/source.c
+++ b/cmd/source.c
@@ -128,16 +128,14 @@ int image_source_script(ulong addr, const char *fit_uname)
}
 
if (!fit_image_check_type (fit_hdr, noffset, IH_TYPE_SCRIPT)) {
-   puts ("Not a image image\n");
+   puts("Not a script image\n");
return 1;
}
 
/* verify integrity */
-   if (verify) {
-   if (!fit_image_verify(fit_hdr, noffset)) {
-   puts ("Bad Data Hash\n");
-   return 1;
-   }
+   if (verify && !fit_image_verify(fit_hdr, noffset)) {
+   puts("Bad Data Hash\n");
+   return 1;
}
 
/* get script subimage data address and length */
-- 
2.35.1.1320.gc452695387.dirty



[PATCH v4 3/5] treewide: Use NULL for script image name

2022-12-12 Thread Sean Anderson
Two callers of image_source_script specify an image name. However, both
use the deprecated @ syntax, indicating that they have not been updated
in a while. If CONFIG_FIT_SIGNATURE is enabled, we will reject such
names outright. Back in commit 152576a598c ("stm32mp: stm32prog: handle
U-Boot script in flashlayout alternate"), we even renamed one of the
nodes. Instead of hard-coding a script image name, just use the default
image.

Signed-off-by: Sean Anderson 
Reviewed-by: Simon Glass 
Reviewed-by: Patrick Delaunay 
---
This has a non-zero chance of breaking something, especially for SDP.
It's not strictly necessary for the following patches, so I can drop it
if there are any issues.

(no changes since v1)

 arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c | 2 +-
 drivers/usb/gadget/f_sdp.c  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c 
b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
index 007f713130..3627b4c35c 100644
--- a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
+++ b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
@@ -154,7 +154,7 @@ static int do_stm32prog(struct cmd_tbl *cmdtp, int flag, 
int argc,
do_bootz(cmdtp, 0, 4, bootm_argv);
}
if (data->script)
-   image_source_script(data->script, "script@stm32prog");
+   image_source_script(data->script, NULL);
 
if (reset) {
puts("Reset...\n");
diff --git a/drivers/usb/gadget/f_sdp.c b/drivers/usb/gadget/f_sdp.c
index af4b167e17..1643d28947 100644
--- a/drivers/usb/gadget/f_sdp.c
+++ b/drivers/usb/gadget/f_sdp.c
@@ -868,7 +868,7 @@ static int sdp_handle_in_ep(struct spl_image_info 
*spl_image,
jump_to_image_no_args(_image);
 #else
/* In U-Boot, allow jumps to scripts */
-   image_source_script(sdp_func->jmp_address, "script@1");
+   image_source_script(sdp_func->jmp_address, NULL);
 #endif
}
 
-- 
2.35.1.1320.gc452695387.dirty



[PATCH v4 2/5] test: Add test for source command

2022-12-12 Thread Sean Anderson
This adds a basic test for FIT image handling by the source command.
It's a python test becase we need to run mkimage.

Signed-off-by: Sean Anderson 
Reviewed-by: Simon Glass 
---

(no changes since v3)

Changes in v3:
- Halve the quotes

Changes in v2:
- New

 test/py/tests/source.its | 43 
 test/py/tests/test_source.py | 28 +++
 2 files changed, 71 insertions(+)
 create mode 100644 test/py/tests/source.its
 create mode 100644 test/py/tests/test_source.py

diff --git a/test/py/tests/source.its b/test/py/tests/source.its
new file mode 100644
index 00..3c62f777f1
--- /dev/null
+++ b/test/py/tests/source.its
@@ -0,0 +1,43 @@
+/dts-v1/;
+
+/ {
+description = "FIT image to test the source command";
+#address-cells = <1>;
+
+images {
+default = "script-1";
+
+script-1 {
+data = "echo 1";
+type = "script";
+arch = "sandbox";
+compression = "none";
+};
+
+script-2 {
+data = "echo 2";
+type = "script";
+arch = "sandbox";
+compression = "none";
+};
+
+not-a-script {
+data = "echo 3";
+type = "kernel";
+arch = "sandbox";
+compression = "none";
+};
+};
+
+configurations {
+default = "conf-2";
+
+conf-1 {
+script = "script-1";
+};
+
+conf-2 {
+script = "script-2";
+};
+};
+};
diff --git a/test/py/tests/test_source.py b/test/py/tests/test_source.py
new file mode 100644
index 00..e5ffdfe3fc
--- /dev/null
+++ b/test/py/tests/test_source.py
@@ -0,0 +1,28 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright (C) 2022 Sean Anderson 
+
+import os
+import pytest
+import u_boot_utils as util
+
+@pytest.mark.boardspec('sandbox')
+@pytest.mark.buildconfigspec('cmd_echo')
+@pytest.mark.buildconfigspec('cmd_source')
+@pytest.mark.buildconfigspec('fit')
+def test_source(u_boot_console):
+# Compile our test script image
+cons = u_boot_console
+mkimage = os.path.join(cons.config.build_dir, 'tools/mkimage')
+its = os.path.join(cons.config.source_dir, 'test/py/tests/source.its')
+fit = os.path.join(cons.config.build_dir, 'source.itb')
+util.run_and_log(cons, (mkimage, '-f', its, fit))
+cons.run_command(f'host load hostfs - $loadaddr {fit}')
+
+assert '1' in cons.run_command('source')
+assert '1' in cons.run_command('source :script-1')
+assert '2' in cons.run_command('source :script-2')
+assert 'Fail' in cons.run_command('source :not-a-script || echo Fail')
+
+cons.run_command('fdt addr $loadaddr')
+cons.run_command('fdt rm /images default')
+assert 'Fail' in cons.run_command('source || echo Fail')
-- 
2.35.1.1320.gc452695387.dirty



[PATCH v4 1/5] image: Add fallback for fit_config_verify

2022-12-12 Thread Sean Anderson
Add a fallback for this function so it can be used without regard to
whether FIT_SIGNATURE is enabled or not.

Signed-off-by: Sean Anderson 
---

Changes in v4:
- New

 include/image.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/include/image.h b/include/image.h
index 6f21dafba8..2a53c30486 100644
--- a/include/image.h
+++ b/include/image.h
@@ -1258,7 +1258,14 @@ int fit_image_verify_with_data(const void *fit, int 
image_noffset,
   size_t size);
 
 int fit_image_verify(const void *fit, int noffset);
+#if CONFIG_IS_ENABLED(FIT_SIGNATURE)
 int fit_config_verify(const void *fit, int conf_noffset);
+#else
+static inline int fit_config_verify(const void *fit, int conf_noffset)
+{
+   return 0;
+}
+#endif
 int fit_all_image_verify(const void *fit);
 int fit_config_decrypt(const void *fit, int conf_noffset);
 int fit_image_check_os(const void *fit, int noffset, uint8_t os);
-- 
2.35.1.1320.gc452695387.dirty



[PATCH v4 0/5] cmd: source: Support specifying config name

2022-12-12 Thread Sean Anderson
This series adds support for using configs with the source command. See
the third patch for details.

Changes in v4:
- Add fallback for fit_config_verify
- Fix fit_conf_get_prop_node missing a phase

Changes in v3:
- Halve the quotes

Changes in v2:
- Add test for source command

Sean Anderson (5):
  image: Add fallback for fit_config_verify
  test: Add test for source command
  treewide: Use NULL for script image name
  cmd: source: Clean up a few lines
  cmd: source: Support specifying config name

 .../cmd_stm32prog/cmd_stm32prog.c |  2 +-
 boot/bootmeth_script.c|  2 +-
 cmd/source.c  | 84 +--
 doc/uImage.FIT/source_file_format.txt |  3 +
 drivers/usb/gadget/f_sdp.c|  2 +-
 include/image.h   | 26 --
 test/py/tests/source.its  | 43 ++
 test/py/tests/test_source.py  | 37 
 8 files changed, 164 insertions(+), 35 deletions(-)
 create mode 100644 test/py/tests/source.its
 create mode 100644 test/py/tests/test_source.py

-- 
2.35.1.1320.gc452695387.dirty



Re: [PATCH V2 1/1] Configs: enable gigadevice xilinx_zynqmp_mini_qspi_defconfig

2022-12-12 Thread Vlim
Hi, Michal,

Do you mean group a few files in to one patch?

Regards,

Victor



Get Outlook for Android

From: Michal Simek 
Sent: Monday, December 12, 2022 10:58:00 PM
To: Vlim 
Cc: u-boot@lists.denx.de ; vikhyat.go...@amd.com 
; ashok.reddy.s...@amd.com 
Subject: Re: [PATCH V2 1/1] Configs: enable gigadevice 
xilinx_zynqmp_mini_qspi_defconfig

此为外部邮件,谨防钓鱼邮件,请注意邮件是否涉及敏感信息

This is an external email, beware of phishing emails. Please pay close 
attention to whether the email contains sensitive information


Hi Victor,

po 12. 12. 2022 v 15:50 odesílatel Victor Lim  napsal:
>
> enabling gigadevice in this file

it is quite clear that you are changing it in this file not another
one. Remove it.

And send it as a series because I really don't want to pick it up one
by one when we have b4
and can download all of them together.

Thanks,
Michal



--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: 
https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.monstr.eu%2Fdata=05%7C01%7Cvlim%40gigadevice.com%7C6bb31077525c42d9ad9c08dadc514ae1%7Cf84ba339959c4ab19b671e43414f945e%7C0%7C0%7C638064538983434499%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7Csdata=%2BA3kGtoOST4zkZ0hCpiCiU5D9Zlm%2BzHpmVxpfs1Llj0%3Dreserved=0
 p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs


Re: [PATCH v3 2/2] board: mediatek: add mt8195 demo board

2022-12-12 Thread Tom Rini
On Mon, Dec 12, 2022 at 01:53:05PM -0500, Tom Rini wrote:
> On Mon, Dec 12, 2022 at 11:53:04AM -0500, Tom Rini wrote:
> > On Thu, Nov 10, 2022 at 03:34:53PM +0800, Macpaul Lin wrote:
> > 
> > > From: Fabien Parent 
> > > 
> > > Add mt8195-demo board support.
> > > This demo purpose board uses MediaTek's MT8195 SoC.
> > > 
> > > Signed-off-by: Fabien Parent 
> > > Signed-off-by: Amjad Ouled-Ameur 
> > > Signed-off-by: Macpaul Lin 
> > [snip]
> > > +#include 
> > > +
> > > +#define CONFIG_SYS_NS16550_SERIAL
> > > +#define CONFIG_SYS_NS16550_REG_SIZE  -4
> > > +#define CONFIG_SYS_NS16550_MEM32
> > > +#define CONFIG_SYS_NS16550_COM1  0x11002000
> > > +#define CONFIG_SYS_NS16550_CLK   2600
> > 
> > This is unused, I believe.  But when trying to build with current next I
> > get:
> > Error: Load Address must be set.
> > Error: Bad parameters for image type
> > 
> > Please rebase on top of current next and repost, thanks!
> 
> Sorry for the noise, this failed due to another patch that needs to be
> reworked instead.

Welp, I should have finished my re-testing.  The patch that broke
phycore-rk3288 and I assumed broke this platform too, did not break this
platform, there's still some other problem here.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 2/2] musb-new: omap2430: fix musb probing in gadget mode

2022-12-12 Thread Tom Rini
On Sat, Nov 26, 2022 at 11:30:10PM +0100, Andreas Kemnade wrote:

> Host mode structures were accessed but not initialized
> and gadget dm did not compile at all.
> 
> Signed-off-by: Andreas Kemnade 
> ---
>  drivers/usb/musb-new/omap2430.c | 42 -
>  1 file changed, 25 insertions(+), 17 deletions(-)

This breaks omap3_beagle and omap3_evm.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] serial: ns16550: Enable clocks during probe

2022-12-12 Thread Tom Rini
On Sun, Nov 27, 2022 at 11:48:34PM -0600, Samuel Holland wrote:

> If the UART bus or baud clock has a gate, it must be enabled before the
> UART can be used.
> 
> Signed-off-by: Samuel Holland 
> Reviewed-by: Stefan Roese 

This breaks building on phycore-rk3288

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v3 2/2] board: mediatek: add mt8195 demo board

2022-12-12 Thread Tom Rini
On Mon, Dec 12, 2022 at 11:53:04AM -0500, Tom Rini wrote:
> On Thu, Nov 10, 2022 at 03:34:53PM +0800, Macpaul Lin wrote:
> 
> > From: Fabien Parent 
> > 
> > Add mt8195-demo board support.
> > This demo purpose board uses MediaTek's MT8195 SoC.
> > 
> > Signed-off-by: Fabien Parent 
> > Signed-off-by: Amjad Ouled-Ameur 
> > Signed-off-by: Macpaul Lin 
> [snip]
> > +#include 
> > +
> > +#define CONFIG_SYS_NS16550_SERIAL
> > +#define CONFIG_SYS_NS16550_REG_SIZE-4
> > +#define CONFIG_SYS_NS16550_MEM32
> > +#define CONFIG_SYS_NS16550_COM10x11002000
> > +#define CONFIG_SYS_NS16550_CLK 2600
> 
> This is unused, I believe.  But when trying to build with current next I
> get:
> Error: Load Address must be set.
> Error: Bad parameters for image type
> 
> Please rebase on top of current next and repost, thanks!

Sorry for the noise, this failed due to another patch that needs to be
reworked instead.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 4/8] sunxi: Convert H616 DRAM options to single setting

2022-12-12 Thread Andre Przywara
On Sun, 11 Dec 2022 17:32:09 +0100
Jernej Skrabec  wrote:

Hi,

> Vendor DRAM settings use TPR10 parameter to enable various features.
> There are many mores features that just those that are currently
> mentioned. Since new will be added later and most are not known, let's
> reuse value from vendor DRAM driver as-is. This will also help adding
> support for new boards.

Looks good. I checked that the actual code in
mctl_phy_bit_delay_compensation() just gets indented (no real changes), and
is now guarded by the new checks.
The values in the _defconfig still result in the same decisions, though
many are blocked anyway by no one actually calling that bit_delay function
at all. (I wonder what happens when we enable it?)
One small thing below.

> Signed-off-by: Jernej Skrabec 
> ---
>  .../include/asm/arch-sunxi/dram_sun50i_h616.h |  10 +
>  arch/arm/mach-sunxi/Kconfig   |  38 +---
>  arch/arm/mach-sunxi/dram_sun50i_h616.c| 197 +-
>  configs/orangepi_zero2_defconfig  |   5 +-
>  4 files changed, 117 insertions(+), 133 deletions(-)
> 
> diff --git a/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h 
> b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> index c9e1f84bfcdd..b5140c79b70e 100644
> --- a/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> +++ b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> @@ -137,6 +137,15 @@ check_member(sunxi_mctl_ctl_reg, unk_0x4240, 0x4240);
>  #define MSTR_ACTIVE_RANKS(x) (((x == 2) ? 3 : 1) << 24)
>  #define MSTR_BURST_LENGTH(x) (((x) >> 1) << 16)
>  
> +/* TODO: figure out what unknown features do */
> +#define TPR10_UNKNOWN_FEAT0  BIT(16)
> +#define TPR10_UNKNOWN_FEAT1  BIT(17)
> +#define TPR10_UNKNOWN_FEAT2  BIT(18)

Could you just put the bit number in the macro? Like TPR10_BIT16? That
both avoids inventing meaningless names, and helps readers to correlate
code more easily. Or skip the symbol altogether for those and use just
"BIT(16)" in the code.

Cheers,
Andre

> +#define TPR10_WRITE_LEVELING BIT(20)
> +#define TPR10_READ_CALIBRATION   BIT(21)
> +#define TPR10_READ_TRAINING  BIT(22)
> +#define TPR10_WRITE_TRAINING BIT(23)
> +
>  struct dram_para {
>   u32 clk;
>   enum sunxi_dram_type type;
> @@ -147,6 +156,7 @@ struct dram_para {
>   u32 dx_odt;
>   u32 dx_dri;
>   u32 ca_dri;
> + u32 tpr10;
>  };
>  
>  
> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> index cad53f19912c..abcbd0fb9061 100644
> --- a/arch/arm/mach-sunxi/Kconfig
> +++ b/arch/arm/mach-sunxi/Kconfig
> @@ -52,38 +52,6 @@ config DRAM_SUN50I_H616
> like H616.
>  
>  if DRAM_SUN50I_H616
> -config DRAM_SUN50I_H616_WRITE_LEVELING
> - bool "H616 DRAM write leveling"
> - ---help---
> -   Select this when DRAM on your H616 board needs write leveling.
> -
> -config DRAM_SUN50I_H616_READ_CALIBRATION
> - bool "H616 DRAM read calibration"
> - ---help---
> -   Select this when DRAM on your H616 board needs read calibration.
> -
> -config DRAM_SUN50I_H616_READ_TRAINING
> - bool "H616 DRAM read training"
> - ---help---
> -   Select this when DRAM on your H616 board needs read training.
> -
> -config DRAM_SUN50I_H616_WRITE_TRAINING
> - bool "H616 DRAM write training"
> - ---help---
> -   Select this when DRAM on your H616 board needs write training.
> -
> -config DRAM_SUN50I_H616_BIT_DELAY_COMPENSATION
> - bool "H616 DRAM bit delay compensation"
> - ---help---
> -   Select this when DRAM on your H616 board needs bit delay
> -   compensation.
> -
> -config DRAM_SUN50I_H616_UNKNOWN_FEATURE
> - bool "H616 DRAM unknown feature"
> - ---help---
> -   Select this when DRAM on your H616 board needs this unknown
> -   feature.
> -
>  config DRAM_SUN50I_H616_DX_ODT
>   hex "H616 DRAM DX ODT parameter"
>   help
> @@ -98,6 +66,12 @@ config DRAM_SUN50I_H616_CA_DRI
>   hex "H616 DRAM CA DRI parameter"
>   help
> CA DRI value from vendor DRAM settings.
> +
> +config DRAM_SUN50I_H616_TPR10
> + hex "H616 DRAM TPR10 parameter"
> + help
> +   TPR10 value from vendor DRAM settings. It tells which features
> +   should be configured, like write leveling, read calibration, etc.
>  endif
>  
>  config SUN6I_PRCM
> diff --git a/arch/arm/mach-sunxi/dram_sun50i_h616.c 
> b/arch/arm/mach-sunxi/dram_sun50i_h616.c
> index 06a07dfbf9cc..14a01a3c4e54 100644
> --- a/arch/arm/mach-sunxi/dram_sun50i_h616.c
> +++ b/arch/arm/mach-sunxi/dram_sun50i_h616.c
> @@ -577,109 +577,112 @@ static bool mctl_phy_bit_delay_compensation(struct 
> dram_para *para)
>   u32 *ptr;
>   int i;
>  
> - clrbits_le32(SUNXI_DRAM_PHY0_BASE + 0x60, 1);
> - setbits_le32(SUNXI_DRAM_PHY0_BASE + 8, 8);
> - clrbits_le32(SUNXI_DRAM_PHY0_BASE + 0x190, 0x10);
> + if (para->tpr10 & TPR10_UNKNOWN_FEAT2) {
> + clrbits_le32(SUNXI_DRAM_PHY0_BASE + 0x60, 1);
> + setbits_le32(SUNXI_DRAM_PHY0_BASE + 8, 8);

Re: [PATCH v3 2/2] board: mediatek: add mt8195 demo board

2022-12-12 Thread Tom Rini
On Thu, Nov 10, 2022 at 03:34:53PM +0800, Macpaul Lin wrote:

> From: Fabien Parent 
> 
> Add mt8195-demo board support.
> This demo purpose board uses MediaTek's MT8195 SoC.
> 
> Signed-off-by: Fabien Parent 
> Signed-off-by: Amjad Ouled-Ameur 
> Signed-off-by: Macpaul Lin 
[snip]
> +#include 
> +
> +#define CONFIG_SYS_NS16550_SERIAL
> +#define CONFIG_SYS_NS16550_REG_SIZE  -4
> +#define CONFIG_SYS_NS16550_MEM32
> +#define CONFIG_SYS_NS16550_COM1  0x11002000
> +#define CONFIG_SYS_NS16550_CLK   2600

This is unused, I believe.  But when trying to build with current next I
get:
Error: Load Address must be set.
Error: Bad parameters for image type

Please rebase on top of current next and repost, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v3 4/4] cmd: source: Support specifying config name

2022-12-12 Thread Tom Rini
On Thu, Nov 03, 2022 at 05:35:33PM -0400, Sean Anderson wrote:

> As discussed previously [1,2], the source command is not safe to use with
> verified boot unless there is a key with required = "images" (which has its
> own problems). This is because if such a key is absent, signatures are
> verified but not required. It is assumed that configuration nodes will
> provide the signature. Because the source command does not use
> configurations to determine the image to source, effectively no
> verification takes place.
> 
> To address this, allow specifying configuration nodes. We use the same
> syntax as the bootm command (helpfully provided for us by fit_parse_conf).
> By default, we first try the default config and then the default image. To
> force using a config, # must be present in the command (e.g. `source
> $loadaddr#my-conf`). For convenience, the config may be omitted, just like
> the address may be (e.g. `source \#`). This also works for images
> (`source \:` behaves exactly like `source` currently does).
> 
> [1] 
> https://lore.kernel.org/u-boot/7d711133-d513-5bcb-52f2-a9dbaa9ee...@prevas.dk/
> [2] 
> https://lore.kernel.org/u-boot/042dcb34-f85f-351e-1b0e-513f89005...@gmail.com/
> 
> Signed-off-by: Sean Anderson 
> Reviewed-by: Simon Glass 

Currently, there's two problems.  One, fit_conf_get_prop_node() should
be called (I believe) with IH_PHASE_NONE, which I can do when applying.
However, two, fit_config_verify() depends on
CONFIG_IS_ENABLED(FIT_SIGNATURE) and I'm less immediately sure how to
rework that in to this patch. Can you please rebase on top of current
next? Thanks.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 0/8] sunxi: Update H616 DRAM driver

2022-12-12 Thread Jernej Škrabec
Hi Andre,

Dne ponedeljek, 12. december 2022 ob 02:04:51 CET je Andre Przywara 
napisal(a):
> On Sun, 11 Dec 2022 17:32:05 +0100
> Jernej Skrabec  wrote:
> 
> Hi Jernej,
> 
> many thanks for putting this together!
> I will have a more elaborate look at each patch later.
> 
> > Current H616 DRAM driver is completely customized to Orange Pi Zero2
> > board, which is currently the only H616 board supported by U-Boot.
> 
> Not anymore, I merged the X96 Mate support lately, after the DT got
> merged into the Linux tree.

Right. First part of sentence is still true, although I later remembered that 
some values are based on T95 values, those that are not used by Orange Pi 
Zero2.

> 
> Those are the values for the box I came up with:
> CONFIG_DRAM_SUN50I_H616_DX_ODT=0x03030303
> CONFIG_DRAM_SUN50I_H616_DX_DRI=0x0e0e0e0e
> CONFIG_DRAM_SUN50I_H616_CA_DRI=0x1c12
> CONFIG_DRAM_SUN50I_H616_TPR0=0xcc05
> CONFIG_DRAM_SUN50I_H616_TPR10=0x2f0007
> CONFIG_DRAM_SUN50I_H616_TPR11=0x
> CONFIG_DRAM_SUN50I_H616_TPR12=0xfedf7557
> 
> based on this boot0 found in some firmware update image:
> 00045400  be 02 00 ea 65 47 4f 4e  2e 42 54 30 cc ba f3 80 
> |eGON.BT0| 00045410  00 c0 00 00 30 00 00 00  00 00 00 00 00 00 02
> 00  |0...| 00045420  00 00 02 00 00 00 00 00  00 00 00 00 34 2e
> 30 00  |4.0.| 00045430  00 00 00 00 03 00 00 00  88 02 00 00 03
> 00 00 00  || 00045440  03 03 03 03 0e 0e 0e 0e  12 1c 00 00
> 01 00 00 00  || 00045450  fb 30 00 00 00 00 00 00  40 08 00
> 00 04 00 00 00  |.0..@...| 00045460  08 00 00 00 00 00 00 00  00 00
> 00 00 00 00 00 00  || 00045470  00 00 00 00 00 00 00 00  00
> 00 00 00 00 00 00 00  || 00045480  00 00 00 00 00 00 00 00 
> 00 00 00 00 00 00 00 00  || 00045490  05 0c 00 c0 00 00 00
> 00  00 00 00 00 00 00 00 00  || 000454a0  80 80 80 33 07 00
> 2f 00  dd dd ff ff 57 75 df fe  |...3../.Wu..| 000454b0  40 00 00 00 00
> 00 00 00  00 00 00 00 08 00 02 01  |@...|
> 
> I would be grateful if you could verify this.

Looks correct. I'll use them in my v2 patches.

> 
> I built it, and it reported the 4GB correctly, also managed to boot into
> Linux just fine. No extensive testing, nor didn't I compare register
> dumps or disassembly (yet).
> 
> Cheers,
> Andre
> 
> P.S. Any plans on upstreaming support for your T95  H616 TV
> box? That would probably help the case here.

Not really, X96 Mate is basically the same as T95, except DRAM configuration. 
As I said, I verified that these patches provide same register values as 
before. This includes those which were modeled after T95 DRAM values.

Best regards,
Jernej

> 
> > Needless to say, this is not ideal for adding new boards. With changes
> > in this series, all DDR3 boards are supported and all that is needed is
> > just vendor DRAM values extracted from Android image. New DRAM types
> > should also be easier to support, since a lot of constants used before
> > are not really DRAM type dependent.
> > 
> > Changes were verified by decompiling driver and generated values were
> > compared to previous, hard coded ones. This was done without dram_para
> > structures, so compiler was able to heavily optimize code and produce
> > constants.
> > 
> > Please take a look.
> > 
> > Best regards,
> > Jernej
> > 
> > Jernej Skrabec (8):
> >   sunxi: Fix write to H616 DRAM CR register
> >   sunxi: cosmetic: Fix H616 DRAM driver code style
> >   sunxi: parameterize H616 DRAM ODT values
> >   sunxi: Convert H616 DRAM options to single setting
> >   sunxi: Always configure ODT on H616 DRAM
> >   sunxi: Make bit delay function in H616 DRAM code void
> >   sunxi: Parameterize bit delay code in H616 DRAM driver
> >   sunxi: Parameterize H616 DRAM code some more
> >  
> >  .../include/asm/arch-sunxi/dram_sun50i_h616.h |  18 +
> >  arch/arm/mach-sunxi/Kconfig   |  67 +--
> >  arch/arm/mach-sunxi/dram_sun50i_h616.c| 445 +++---
> >  configs/orangepi_zero2_defconfig  |   8 +-
> >  4 files changed, 348 insertions(+), 190 deletions(-)






Re: [PATCH v1] arch/arm: sm: introduce efusedump command

2022-12-12 Thread Tom Rini
On Fri, Dec 09, 2022 at 03:52:04PM +0300, Alexey Romanov wrote:

> Using this command user can print efuse memory:
> 
> $ sm efusedump 0 10
>   : ff 00 31 00 00 ff 66 00 00 00  ..1...f...
> 
> Signed-off-by: Alexey Romanov 
> ---
>  arch/arm/mach-meson/sm.c | 36 +++-
>  1 file changed, 35 insertions(+), 1 deletion(-)

This needs to be moved done under cmd/ somewhere, perhaps cmd/meson/

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH V2 1/1] Configs: enable gigadevice xilinx_zynqmp_mini_qspi_defconfig

2022-12-12 Thread Michal Simek
Hi,

first of all no top posting.

po 12. 12. 2022 v 16:07 odesílatel Vlim  napsal:
>
> Hi, Michal,
>
> Do you mean group a few files in to one patch?

I am fine with one patch per SOC but up2you.
But definitely send it as series with --thread with cover letter.

Thanks,
Michal


Re: [PATCH] mtd: spi-nor-ids: add Macronix flash entry

2022-12-12 Thread Tom Rini
On Sun, Dec 11, 2022 at 11:19:02PM +0800, Jit Loon Lim wrote:

> From: Tien Fong Chee 
> 
> Add Macronix mx25u51245g flash entry, so this can be used on
> SoCFPGA devices.
> 
> Signed-off-by: Tien Fong Chee 
> Signed-off-by: Jit Loon Lim 
> ---
>  drivers/mtd/spi/spi-nor-ids.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
> index 4fe8b0d92c..f5cf3d0156 100644
> --- a/drivers/mtd/spi/spi-nor-ids.c
> +++ b/drivers/mtd/spi/spi-nor-ids.c
> @@ -182,7 +182,7 @@ const struct flash_info spi_nor_ids[] = {
>   { INFO("mx25l12805d", 0xc22018, 0, 64 * 1024, 256, SECT_4K) },
>   { INFO("mx25u12835f", 0xc22538, 0, 64 * 1024, 256, SECT_4K) },
>   { INFO("mx25u51245g", 0xc2253a, 0, 64 * 1024, 1024, SECT_4K |
> -SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
> + SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
>   { INFO("mx25l12855e", 0xc22618, 0, 64 * 1024, 256, 0) },
>   { INFO("mx25l25635e", 0xc22019, 0, 64 * 1024, 512, SPI_NOR_DUAL_READ | 
> SPI_NOR_QUAD_READ) },
>   { INFO("mx25u25635f", 0xc22539, 0, 64 * 1024, 512, SECT_4K | 
> SPI_NOR_4B_OPCODES) },

As confirmed by "git diff -w" this is entirely a whitespace only change.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 1/4] riscv: spl: Introduce SPL_OPENSBI_OS_BOOT

2022-12-12 Thread Tom Rini
On Mon, Dec 12, 2022 at 03:49:10PM +0800, Rick Chen wrote:
> > On 12/7/22 01:23, Rick Chen wrote:
> > > In RISC-V, it only provide normal mode booting currently.
> > > To speed up the booting process, here provide SPL_OPENSBI_OS_BOOT
> > > to achieve this feature which will be call Fast-Boot mode. By
> >
> > Can you name this something different. We already have something called
> > fastboot in-tree (the Android-derived protocol) and there's a Microsoft
> > technology called fastboot (some kind of hibernation). "OS Boot" isn't
> > very specific either, since we (almost always) boot an OS. Maybe "Eagle
> > mode" by analogy to Falcon mode, which lets SPL directly boot an OS.
> 
> I think fast boot is a behavior which shall be interpreted widely but
> not proprietary.
> Or maybe I can  rename it as RISC-V Fast Boot to distinguish them.
> 
> >
> > (Is this substantially different from falcon mode anyway?)
> 
> Please see the explanations to Tom.
> 
> >
> > > enabling SPL_OPENSBI_OS_BOOT, it will generate linux.itb instead
> > > of default u-boot.itb after compiling. It initializes memory with
> > > the U-Boot SPL at the first stage, just like what a regular booting
> > > process (i.e. Normal Boot) does in the beginning. Instead of jumping
> > > to the U-Boot proper from OpenSBI before booting Linux Kernel, the
> > > Fast Boot process jumps directly to Linux Kernel to gain shorter
> > > booting time.
> > >
> > > Signed-off-by: Rick Chen 
> > > ---
> > >   common/spl/Kconfig   | 14 ++
> > >   common/spl/spl_fit.c |  3 ++-
> > >   common/spl/spl_opensbi.c | 25 -
> > >   3 files changed, 28 insertions(+), 14 deletions(-)
> > >
> > > diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> > > index 05181bdba3..8805aba1b7 100644
> > > --- a/common/spl/Kconfig
> > > +++ b/common/spl/Kconfig
> > > @@ -1509,6 +1509,20 @@ config SPL_OPENSBI_SCRATCH_OPTIONS
> > > Options passed to fw_dynamic, for example 
> > > SBI_SCRATCH_NO_BOOT_PRINTS or
> > > SBI_SCRATCH_DEBUG_PRINTS.
> > >
> > > +config SPL_OPENSBI_OS_BOOT
> >
> > Please use the same name for the config as for the description.
> >
> > > + bool "openSBI Fast Boot"
> > > + depends on SPL_OPENSBI
> > > + help
> > > +   Enable this openSBI can jump to Linux Kernel directly.
> >
> > Can you put some of the explanation from the commit message here?
> 
> OK, I will move some messages here from commit messages.
> 
> >
> > > +
> > > +config SPL_OPENSBI_FIT_NAME
> > > + string "SPL openSBI fit image name"
> > > + depends on SPL_OPENSBI
> > > + default "linux.itb" if SPL_OPENSBI_OS_BOOT
> > > + default "u-boot.itb"
> > > + help
> > > +   This will help to generate different fit name accordingly.
> >
> > Why not SPL_FS_LOAD_PAYLOAD_NAME?
> >
> > It looks like the code changes below do not use these configs. Can you
> > move them to the next patch so it is clearer that they are for binman?
> 
> I have saw this config, but it does't support SPL_RAM but only for filesystem
> That is why I don't leverage it.
> 
> I can prepare a patch as below if no other concerns:
> 
> config SPL_FS_LOAD_PAYLOAD_NAME
> string "File to load for U-Boot from the filesystem"
> depends on SPL_FS_EXT4 || SPL_FS_FAT || SPL_FS_SQUASHFS || SPL_RAM
> default "tispl.bin" if SYS_K3_SPL_ATF
> default "u-boot.itb" if SPL_LOAD_FIT
> default "linux.itb" if SPL_OPENSBI_OS_BOOT
> default "u-boot.img"
> help
>   Filename to read to load U-Boot when reading from filesystem.

But in the case you have it's for the output name, and not at all about
what's being loaded from a filesystem yes? This shouldn't be a "SPL_.."
option, but should be under arch/riscv/Kconfig somewhere, since it's
changing the general riscv binman.dtsi file. And on a related note,
please make sure that 'make htmldocs' is happy with your documentation
changes as I think I see some spacing problems in 4/4.

-- 
Tom


signature.asc
Description: PGP signature


Re: Please pull u-boot-marvell/master

2022-12-12 Thread Tom Rini
On Mon, Dec 12, 2022 at 09:57:41AM +0100, Stefan Roese wrote:

> Hi Tom,
> 
> please pull this late Marvell related fix:
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PULL] Pull request for u-boot master / v2023.01-rc4 = u-boot-stm32-20221212

2022-12-12 Thread Tom Rini
On Mon, Dec 12, 2022 at 01:10:52PM +0100, Patrice CHOTARD wrote:

> Hi Tom
> 
> Please pull these 2 patches for v2023.01-rc4
> 
> CI status: 
> https://source.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/14403
> 
> The following changes since commit 7a7b0856ca01f0dadc940f6f1bc6df44129ad9d0:
> 
>   Merge tag 'u-boot-nand-20221211' of 
> https://source.denx.de/u-boot/custodians/u-boot-nand-flash (2022-12-11 
> 09:40:25 -0500)
> 
> are available in the Git repository at:
> 
>   https://source.denx.de/u-boot/custodians/u-boot-stm.git 
> tags/u-boot-stm32-20221212
> 
> for you to fetch changes up to 30257f4699e0e58818f6e6f86021a994f485ee58:
> 
>   dm: pmic: ignore disabled node in pmic_bind_children (2022-12-12 11:25:28 
> +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


[PATCH] usb: gadget: ether: split start/stop from init/halt

2022-12-12 Thread Niel Fourie
Split out _usb_eth_start() from _usb_eth_init() and
usb_eth_stop() from _usb_eth_halt(). Now _usb_eth_init() only
initialises and registers the gadget device, which _usb_eth_halt()
reverses, and together are used for probing and removing the
device. The _usb_eth_start() and _usb_eth_stop() functions connect
and disconnect the gadget as expected by the start()/stop()
callbacks.

Previously the gadget device was probed on every start() and
removed on every stop(), which is inconsistent with other DM_ETH
drivers. For non-DM gadget drivers the old behaviour has been
retained.

Signed-off-by: Niel Fourie 
Cc: Marek Vasut 
Cc: Lukasz Majewski 
Cc: Ramon Fried 
---
 drivers/usb/gadget/ether.c | 58 +-
 1 file changed, 45 insertions(+), 13 deletions(-)

diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c
index 43aec7ffa70..a75b4eeb5bb 100644
--- a/drivers/usb/gadget/ether.c
+++ b/drivers/usb/gadget/ether.c
@@ -2305,15 +2305,11 @@ fail:
 
 /*-*/
 static void _usb_eth_halt(struct ether_priv *priv);
+static void _usb_eth_stop(struct ether_priv *priv);
 
 static int _usb_eth_init(struct ether_priv *priv)
 {
-   struct eth_dev *dev = >ethdev;
-   struct usb_gadget *gadget;
-   unsigned long ts;
int ret;
-   unsigned long timeout = USB_CONNECT_TIMEOUT;
-
ret = usb_gadget_initialize(0);
if (ret)
return ret;
@@ -2353,14 +2349,26 @@ static int _usb_eth_init(struct ether_priv *priv)
priv->eth_driver.resume = eth_resume;
if (usb_gadget_register_driver(>eth_driver) < 0)
goto fail;
+   return 0;
+fail:
+   _usb_eth_halt(priv);
+   return -1;
+}
 
-   dev->network_started = 0;
+static int _usb_eth_start(struct ether_priv *priv)
+{
+   unsigned long ts;
+   unsigned long timeout = USB_CONNECT_TIMEOUT;
+   struct eth_dev *dev = >ethdev;
+
+   if (!dev->gadget)
+   return -1;
 
+   dev->network_started = 0;
packet_received = 0;
packet_sent = 0;
 
-   gadget = dev->gadget;
-   usb_gadget_connect(gadget);
+   usb_gadget_connect(dev->gadget);
 
if (env_get("cdc_connect_timeout"))
timeout = dectoul(env_get("cdc_connect_timeout"), NULL) * 
CONFIG_SYS_HZ;
@@ -2378,6 +2386,7 @@ static int _usb_eth_init(struct ether_priv *priv)
rx_submit(dev, dev->rx_req, 0);
return 0;
 fail:
+   _usb_eth_stop(priv);
_usb_eth_halt(priv);
return -1;
 }
@@ -2457,11 +2466,10 @@ static int _usb_eth_recv(struct ether_priv *priv)
return 0;
 }
 
-static void _usb_eth_halt(struct ether_priv *priv)
+static void _usb_eth_stop(struct ether_priv *priv)
 {
struct eth_dev *dev = >ethdev;
 
-   /* If the gadget not registered, simple return */
if (!dev->gadget)
return;
 
@@ -2485,6 +2493,14 @@ static void _usb_eth_halt(struct ether_priv *priv)
usb_gadget_handle_interrupts(0);
dev->network_started = 0;
}
+}
+
+static void _usb_eth_halt(struct ether_priv *priv)
+{
+   struct eth_dev *dev = >ethdev;
+
+   if (!dev->gadget)
+   return;
 
usb_gadget_unregister_driver(>eth_driver);
usb_gadget_release(0);
@@ -2493,9 +2509,13 @@ static void _usb_eth_halt(struct ether_priv *priv)
 #ifndef CONFIG_DM_ETH
 static int usb_eth_init(struct eth_device *netdev, struct bd_info *bd)
 {
+   int ret;
struct ether_priv *priv = (struct ether_priv *)netdev->priv;
 
-   return _usb_eth_init(priv);
+   ret = _usb_eth_init(priv);
+   if (!ret)
+   ret = _usb_eth_start(priv);
+   return ret;
 }
 
 static int usb_eth_send(struct eth_device *netdev, void *packet, int length)
@@ -2536,6 +2556,7 @@ void usb_eth_halt(struct eth_device *netdev)
 {
struct ether_priv *priv = (struct ether_priv *)netdev->priv;
 
+   _usb_eth_stop(priv);
_usb_eth_halt(priv);
 }
 
@@ -2559,7 +2580,7 @@ static int usb_eth_start(struct udevice *dev)
 {
struct ether_priv *priv = dev_get_priv(dev);
 
-   return _usb_eth_init(priv);
+   return _usb_eth_start(priv);
 }
 
 static int usb_eth_send(struct udevice *dev, void *packet, int length)
@@ -2609,7 +2630,7 @@ static void usb_eth_stop(struct udevice *dev)
 {
struct ether_priv *priv = dev_get_priv(dev);
 
-   _usb_eth_halt(priv);
+   _usb_eth_stop(priv);
 }
 
 static int usb_eth_probe(struct udevice *dev)
@@ -2623,6 +2644,16 @@ static int usb_eth_probe(struct udevice *dev)
get_ether_addr(CONFIG_USBNET_DEV_ADDR, pdata->enetaddr);
eth_env_set_enetaddr("usbnet_devaddr", pdata->enetaddr);
 
+   return _usb_eth_init(priv);
+
+   return 0;
+}
+
+static int usb_eth_remove(struct udevice *dev)
+{
+   struct ether_priv *priv = dev_get_priv(dev);
+
+   _usb_eth_halt(priv);
return 0;
 }
 
@@ 

[PATCH v2] net: eth-uclass: revalidate priv after stop() in eth_halt()

2022-12-12 Thread Niel Fourie
In eth_halt(), reread and revalidate priv after calling stop(),
as it may have been freed, leaving a dangling pointer.

In the ethernet gadget implementation, the gadget device gets
probed during start() and removed during stop(), which includes
freeing `uclass_priv_` to which `priv` is pointing. Writing to
`priv` after stop() may corrupt the `fd` member of `struct
malloc_chunk`, which represents the freed block, and could cause
hard-to-debug crashes on subsequent calls to malloc()/free().

Signed-off-by: Niel Fourie 
Cc: Ramon Fried 
Cc: Marek Vasut 
Cc: Lukasz Majewski 
---
Changes for v2:
- Revalidate priv instead of changing state before stop()
- Added explanational comment

This patch my be dropped if the patch which addresses the root cause
("usb: gadget: ether: split start/stop from init/halt") is accepted.

 net/eth-uclass.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/net/eth-uclass.c b/net/eth-uclass.c
index f41da4b37b3..7d5783b5cab 100644
--- a/net/eth-uclass.c
+++ b/net/eth-uclass.c
@@ -341,8 +341,11 @@ void eth_halt(void)
priv = dev_get_uclass_priv(current);
if (!priv || !priv->running)
return;
-
eth_get_ops(current)->stop(current);
+   /* Ethernet gadget frees priv during stop, workaround until fixed... */
+   priv = dev_get_uclass_priv(current);
+   if (!priv || !priv->running)
+   return;
priv->state = ETH_STATE_PASSIVE;
priv->running = false;
 }
-- 
2.38.1



AW: [PATCH] distro/pxeboot: Handle prompt variable

2022-12-12 Thread Traut Manuel LCPF-CH
Can this be picked for next?

-Ursprüngliche Nachricht-
Von: Simon Glass  
Gesendet: Sonntag, 27. November 2022 15:36
An: Traut Manuel LCPF-CH 
Cc: u-boot@lists.denx.de; vagr...@debian.org
Betreff: Re: EXTERNAL - [PATCH] distro/pxeboot: Handle prompt variable

On Fri, 18 Nov 2022 at 05:36, Manuel Traut  wrote:
>
> Regarding the documentation found here:
> https://github.com/u-boot/u-boot/blob/master/common/menu.c#L347
>
> If both timeout and prompt is set to 0 the default entry shall be 
> booted immediately. However the current behaviour is that the prompt 
> is shown (tested with distroboot) until the user selects an entry (no 
> timeout).
>
> This change implements a behaviour as documented. It was tested with 
> distroboot.
>
> Signed-off-by: Manuel Traut 
> ---
>  boot/pxe_utils.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)

Reviewed-by: Simon Glass 


[PATCH V2 1/1] Configs: enable gigadevice xilinx_zynqmp_mini_qspi_defconfig

2022-12-12 Thread Victor Lim
enabling gigadevice in this file

Signed-off-by: Victor Lim 
---
 configs/xilinx_zynqmp_mini_qspi_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/xilinx_zynqmp_mini_qspi_defconfig 
b/configs/xilinx_zynqmp_mini_qspi_defconfig
index c6401c2a54..2171d09fc3 100644
--- a/configs/xilinx_zynqmp_mini_qspi_defconfig
+++ b/configs/xilinx_zynqmp_mini_qspi_defconfig
@@ -69,6 +69,7 @@ CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_SPI_FLASH_WINBOND=y
+CONFIG_SPI_FLASH_GIGADEVICE=y
 # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
 # CONFIG_POWER is not set
 CONFIG_ARM_DCC=y
-- 
2.25.1



[PATCH V2 1/1] Configs: enable gigadevice

2022-12-12 Thread Victor Lim
enabling gigadevice in this file

Signed-off-by: Victor Lim 
---
 configs/zynq_cse_qspi_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/zynq_cse_qspi_defconfig b/configs/zynq_cse_qspi_defconfig
index 60f0d7cac4..d58db07e71 100644
--- a/configs/zynq_cse_qspi_defconfig
+++ b/configs/zynq_cse_qspi_defconfig
@@ -71,6 +71,7 @@ CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_SPI_FLASH_WINBOND=y
+CONFIG_SPI_FLASH_GIGADEVICE=y
 # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
 CONFIG_ARM_DCC=y
 CONFIG_ZYNQ_QSPI=y
-- 
2.25.1



[PATCH 3/3] ARM: dts: stm32: add support for USB2514B onboard hub on stm32mp157c-ev1

2022-12-12 Thread Fabrice Gasnier
Add support for USB2514B onboard hub on stm32mp157c EV1 board. The HUB
is supplied by a 3v3 PMIC regulator.

[backport from linux ad9591b01d24]
Signed-off-by: Fabrice Gasnier 
---

 arch/arm/dts/stm32mp157c-ev1.dts | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/dts/stm32mp157c-ev1.dts b/arch/arm/dts/stm32mp157c-ev1.dts
index d142dd30e16b..07bcd7c50672 100644
--- a/arch/arm/dts/stm32mp157c-ev1.dts
+++ b/arch/arm/dts/stm32mp157c-ev1.dts
@@ -362,6 +362,14 @@
 _ehci {
phys = <_port0>;
status = "okay";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   /* onboard HUB */
+   hub@1 {
+   compatible = "usb424,2514";
+   reg = <1>;
+   vdd-supply = <>;
+   };
 };
 
 _hs {
-- 
2.25.1



[PATCH 0/3] Add support for USB onboard HUB, used on stm32 boards

2022-12-12 Thread Fabrice Gasnier
This series adds a driver to support USB onboard HUB, inspired by Linux
onboard hub driver.

Purpose is to manage the power supply regulator on STM32 boards, for
low power use case in Linux. U-boot driver allows to benefit of the
device tree part to supply the HUB when need, instead using an
always-on regulator.

It aligns the relevant DT part from emerging Linux v6.2. It also adds the
relevant default configuration on stm32mp15.


Fabrice Gasnier (3):
  usb: onboard-hub: add driver to manage onboard hub supplies
  configs: stm32: enable USB onboard HUB driver
  ARM: dts: stm32: add support for USB2514B onboard hub on
stm32mp157c-ev1

 arch/arm/dts/stm32mp157c-ev1.dts|  8 
 common/Makefile |  1 +
 common/usb_onboard_hub.c| 62 +
 configs/stm32mp15_basic_defconfig   |  1 +
 configs/stm32mp15_defconfig |  1 +
 configs/stm32mp15_trusted_defconfig |  1 +
 drivers/usb/Kconfig | 10 +
 drivers/usb/host/usb-uclass.c   | 16 +---
 8 files changed, 94 insertions(+), 6 deletions(-)
 create mode 100644 common/usb_onboard_hub.c

-- 
2.25.1



[PATCH 2/3] configs: stm32: enable USB onboard HUB driver

2022-12-12 Thread Fabrice Gasnier
Activate the USB onboard HUB driver, that is used to enable the HUB supply
on STM32MP15 EVAL, DK1 and DK2 boards.
This avoids marking the 3v3 corresponding regulator as always-on.

Signed-off-by: Fabrice Gasnier 
---

 configs/stm32mp15_basic_defconfig   | 1 +
 configs/stm32mp15_defconfig | 1 +
 configs/stm32mp15_trusted_defconfig | 1 +
 3 files changed, 3 insertions(+)

diff --git a/configs/stm32mp15_basic_defconfig 
b/configs/stm32mp15_basic_defconfig
index 86ebbef0a6c8..4d2ac589931a 100644
--- a/configs/stm32mp15_basic_defconfig
+++ b/configs/stm32mp15_basic_defconfig
@@ -164,6 +164,7 @@ CONFIG_USB=y
 CONFIG_DM_USB_GADGET=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_EHCI_GENERIC=y
+CONFIG_USB_ONBOARD_HUB=y
 CONFIG_USB_GADGET=y
 CONFIG_USB_GADGET_MANUFACTURER="STMicroelectronics"
 CONFIG_USB_GADGET_VENDOR_NUM=0x0483
diff --git a/configs/stm32mp15_defconfig b/configs/stm32mp15_defconfig
index caa79e68834f..ccf65dd12223 100644
--- a/configs/stm32mp15_defconfig
+++ b/configs/stm32mp15_defconfig
@@ -140,6 +140,7 @@ CONFIG_USB=y
 CONFIG_DM_USB_GADGET=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_EHCI_GENERIC=y
+CONFIG_USB_ONBOARD_HUB=y
 CONFIG_USB_GADGET=y
 CONFIG_USB_GADGET_MANUFACTURER="STMicroelectronics"
 CONFIG_USB_GADGET_VENDOR_NUM=0x0483
diff --git a/configs/stm32mp15_trusted_defconfig 
b/configs/stm32mp15_trusted_defconfig
index 3309c2e79246..a553038a42c5 100644
--- a/configs/stm32mp15_trusted_defconfig
+++ b/configs/stm32mp15_trusted_defconfig
@@ -140,6 +140,7 @@ CONFIG_USB=y
 CONFIG_DM_USB_GADGET=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_EHCI_GENERIC=y
+CONFIG_USB_ONBOARD_HUB=y
 CONFIG_USB_GADGET=y
 CONFIG_USB_GADGET_MANUFACTURER="STMicroelectronics"
 CONFIG_USB_GADGET_VENDOR_NUM=0x0483
-- 
2.25.1



[PATCH 1/3] usb: onboard-hub: add driver to manage onboard hub supplies

2022-12-12 Thread Fabrice Gasnier
The main issue the driver addresses is that a USB hub needs to be
powered before it can be discovered. This is often solved by using
"regulator-always-on".

This driver is inspired by the Linux v6.1 driver. It only enables (or
disables) the hub vdd (3v3) supply, so it can be enumerated.
Scanning of the device tree is done in a similar manner to the sandbox,
by the usb-uclass. DT part looks like:

_ehci {
...
#address-cells = <1>;
#size-cells = <0>;
hub@1 {
compatible = "usb424,2514";
reg = <1>;
vdd-supply = <>;
};
};

When the bus gets probed, the driver is automatically probed/removed from
the bus tree, as an example on stm32:
STM32MP> usb start
starting USB...
STM32MP> dm tree
 Class Index  Probed  DriverName
---
 usb   0  [ + ]   ehci_generic  |   |-- usb@5800d000
 usb_hub   0  [ + ]   usb_onboard_hub   |   |   `-- hub@1
 usb_hub   1  [ + ]   usb_hub   |   |   `-- usb_hub

STM32MP> usb tree
USB device tree:
  1  Hub (480 Mb/s, 0mA)
  |  u-boot EHCI Host Controller
  |
  +-2  Hub (480 Mb/s, 2mA)

Signed-off-by: Fabrice Gasnier 
---

 common/Makefile   |  1 +
 common/usb_onboard_hub.c  | 62 +++
 drivers/usb/Kconfig   | 10 ++
 drivers/usb/host/usb-uclass.c | 16 +
 4 files changed, 83 insertions(+), 6 deletions(-)
 create mode 100644 common/usb_onboard_hub.c

diff --git a/common/Makefile b/common/Makefile
index 20addfb244c2..7789aab484fd 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_PHYLIB) += miiphyutil.o
 obj-$(CONFIG_USB_HOST) += usb.o usb_hub.o
 obj-$(CONFIG_USB_GADGET) += usb.o usb_hub.o
 obj-$(CONFIG_USB_STORAGE) += usb_storage.o
+obj-$(CONFIG_USB_ONBOARD_HUB) += usb_onboard_hub.o
 
 # others
 obj-$(CONFIG_CONSOLE_MUX) += iomux.o
diff --git a/common/usb_onboard_hub.c b/common/usb_onboard_hub.c
new file mode 100644
index ..89e18a2ddad6
--- /dev/null
+++ b/common/usb_onboard_hub.c
@@ -0,0 +1,62 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Driver for onboard USB hubs
+ *
+ * Copyright (C) 2022, STMicroelectronics - All Rights Reserved
+ *
+ * Mostly inspired by Linux kernel v6.1 onboard_usb_hub driver
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+struct onboard_hub {
+   struct udevice *vdd;
+};
+
+static int usb_onboard_hub_probe(struct udevice *dev)
+{
+   struct onboard_hub *hub = dev_get_priv(dev);
+   int ret;
+
+   ret = device_get_supply_regulator(dev, "vdd-supply", >vdd);
+   if (ret) {
+   dev_err(dev, "can't get vdd-supply: %d\n", ret);
+   return ret;
+   }
+
+   ret = regulator_set_enable_if_allowed(hub->vdd, true);
+   if (ret)
+   dev_err(dev, "can't enable vdd-supply: %d\n", ret);
+
+   return ret;
+}
+
+static int usb_onboard_hub_remove(struct udevice *dev)
+{
+   struct onboard_hub *hub = dev_get_priv(dev);
+   int ret;
+
+   ret = regulator_set_enable_if_allowed(hub->vdd, false);
+   if (ret)
+   dev_err(dev, "can't disable vdd-supply: %d\n", ret);
+
+   return ret;
+}
+
+static const struct udevice_id usb_onboard_hub_ids[] = {
+   /* Use generic usbVID,PID dt-bindings (usb-device.yaml) */
+   { .compatible = "usb424,2514" }, /* USB2514B USB 2.0 */
+   { }
+};
+
+U_BOOT_DRIVER(usb_onboard_hub) = {
+   .name   = "usb_onboard_hub",
+   .id = UCLASS_USB_HUB,
+   .probe = usb_onboard_hub_probe,
+   .remove = usb_onboard_hub_remove,
+   .of_match = usb_onboard_hub_ids,
+   .priv_auto = sizeof(struct onboard_hub),
+};
diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index 3afb45d5ccb2..d10ee6853d40 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -106,6 +106,16 @@ config USB_KEYBOARD
  Say Y here if you want to use a USB keyboard for U-Boot command line
  input.
 
+config USB_ONBOARD_HUB
+   bool "Onboard USB hub support"
+   depends on DM_USB
+   ---help---
+ Say Y here if you want to support discrete onboard USB hubs that
+ don't require an additional control bus for initialization, but
+ need some non-trivial form of initialization, such as enabling a
+ power regulator. An example for such a hub is the Microchip
+ USB2514B.
+
 if USB_KEYBOARD
 
 config USB_KEYBOARD_FN_KEYS
diff --git a/drivers/usb/host/usb-uclass.c b/drivers/usb/host/usb-uclass.c
index 060f3441df0c..f5dc93ffee39 100644
--- a/drivers/usb/host/usb-uclass.c
+++ b/drivers/usb/host/usb-uclass.c
@@ -271,19 +271,23 @@ int usb_init(void)
/* init low_level USB */
printf("Bus %s: ", bus->name);
 
-#ifdef CONFIG_SANDBOX
/*
 * For Sandbox, we need scan the device tree each time when we
 * start 

[PATCH] ARM: dts: stm32: update vbus-supply of usbphyc_port0 on stm32mp157c-ev1

2022-12-12 Thread Fabrice Gasnier
phy-stm32-usbphyc bindings uses a connector node with vbus-supply
property.

[backport from linux 43e55d778a6b]
Signed-off-by: Fabrice Gasnier 
---

 arch/arm/dts/stm32mp157c-ev1.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/dts/stm32mp157c-ev1.dts b/arch/arm/dts/stm32mp157c-ev1.dts
index 07bcd7c50672..2d5db41ed67b 100644
--- a/arch/arm/dts/stm32mp157c-ev1.dts
+++ b/arch/arm/dts/stm32mp157c-ev1.dts
@@ -393,6 +393,10 @@
st,tune-squelch-level = <3>;
st,tune-hs-rx-offset = <2>;
st,no-lsfs-sc;
+   connector {
+   compatible = "usb-a-connector";
+   vbus-supply = <_sw>;
+   };
 };
 
 _port1 {
-- 
2.25.1



Re: [PATCH 1/4] riscv: spl: Introduce SPL_OPENSBI_OS_BOOT

2022-12-12 Thread Tom Rini
On Mon, Dec 12, 2022 at 02:45:10PM +0800, Rick Chen wrote:
> Hi Tom
> 
> > On Fri, Dec 09, 2022 at 08:48:37AM -0500, Sean Anderson wrote:
> > > On 12/7/22 01:23, Rick Chen wrote:
> > > > In RISC-V, it only provide normal mode booting currently.
> > > > To speed up the booting process, here provide SPL_OPENSBI_OS_BOOT
> > > > to achieve this feature which will be call Fast-Boot mode. By
> > >
> > > Can you name this something different. We already have something called
> > > fastboot in-tree (the Android-derived protocol) and there's a Microsoft
> > > technology called fastboot (some kind of hibernation). "OS Boot" isn't
> > > very specific either, since we (almost always) boot an OS. Maybe "Eagle
> > > mode" by analogy to Falcon mode, which lets SPL directly boot an OS.
> > >
> > > (Is this substantially different from falcon mode anyway?)
> >
> > I was kind of wondering if this is different, really, from Falcon Mode.
> > Falcon Mode didn't initially have to factor in other-firmware as that's
> > not a hard requirement on arm32 like it is on arm64 or risc-v.  But my
> > first read of this was that it seems like the RISC-V specific side of
> > doing Falcon Mode and dealing with the prior stage needs correctly.
> >
> 
> Yes. It is a little bit different from the Falcon mode (SPL_OS_BOOT=y).
> When I try to enable SPL_OS_BOOT, it will encounter that SYS_SPL_ARGS_ADDR and
>  jump_to_image_linux() shall be defined but they are un-necessary for RISC-V.
> Because the flow of OpenSBI and SPL_OS_BOOT are totally different code
> flow in board_init_r() of common/spl/spl.c.
> That is why I added a new symbol called SPL_OPENSBI_OS_BOOT for this
> RISC-V fast boot implementation.

Those sound like fairly minor challenges for the same fundamental
concept. We have SYS_SPL_ARGS_ADDR for "where is the device tree to
pass along". We might need to do a little code re-factoring here. But
maybe also a little bit of explaining why we wouldn't be booting to the
OS directly but instead passing back to openSBI to do this? That's not
normally how RISC-V boots the OS, right? Or am I miss-understanding
something here?

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH V2 1/1] Configs: enable gigadevice xilinx_zynqmp_mini_qspi_defconfig

2022-12-12 Thread Michal Simek
Hi Victor,

po 12. 12. 2022 v 15:50 odesílatel Victor Lim  napsal:
>
> enabling gigadevice in this file

it is quite clear that you are changing it in this file not another
one. Remove it.

And send it as a series because I really don't want to pick it up one
by one when we have b4
and can download all of them together.

Thanks,
Michal



-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs


Re: [PATCH v3 12/19] phy: at91: Add support for the USB 2.0 PHY's of SAMA7

2022-12-12 Thread Claudiu.Beznea
On 12.12.2022 15:39, Sergiu Moga wrote:
> In order to have USB functionality, drivers for SAMA7's
> USB 2.0 PHY's have been added. There is one driver
> for UTMI clock's SFR and RESET required functionalities and
> one for its three possible subclocks of the phy's themselves.
> In order for this layout to properly work in conjunction with
> CCF and DT, the former driver will also act as a clock provider
> for the three phy's with the help of a custom hook into the
> driver's of_xlate method.
> 
> Signed-off-by: Sergiu Moga 
> Tested-by: Mihai Sain 
> ---
> 
> v1 -> v3:
> - No change
> 
> 
>  drivers/phy/Kconfig  |  10 ++
>  drivers/phy/Makefile |   1 +
>  drivers/phy/phy-sama7-usb.c  |  92 ++
>  drivers/phy/phy-sama7-utmi-clk.c | 202 +++
>  4 files changed, 305 insertions(+)
>  create mode 100644 drivers/phy/phy-sama7-usb.c
>  create mode 100644 drivers/phy/phy-sama7-utmi-clk.c
> 
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index cf4d5908d7..9fbb956783 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -281,6 +281,16 @@ config PHY_XILINX_ZYNQMP
> Enable this to support ZynqMP High Speed Gigabit Transceiver
> that is part of ZynqMP SoC.
>  
> +config PHY_MICROCHIP_SAMA7_USB
> +   tristate "Microchip SAMA7 USB 2.0 PHY"
> +   depends on PHY && ARCH_AT91
> +   help
> +  Enable this to support SAMA7 USB 2.0 PHY.
> +
> +  The USB 2.0 PHY integrates high-speed, full-speed and low-speed
> +  termination and signal switching. With a single resistor, it
> +  requires minimal external components.
> +
>  source "drivers/phy/rockchip/Kconfig"
>  source "drivers/phy/cadence/Kconfig"
>  source "drivers/phy/ti/Kconfig"
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index a3b9f3c5b1..9d50affd47 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -38,6 +38,7 @@ obj-$(CONFIG_PHY_MTK_TPHY) += phy-mtk-tphy.o
>  obj-$(CONFIG_PHY_NPCM_USB) += phy-npcm-usb.o
>  obj-$(CONFIG_PHY_IMX8MQ_USB) += phy-imx8mq-usb.o
>  obj-$(CONFIG_PHY_XILINX_ZYNQMP) += phy-zynqmp.o
> +obj-$(CONFIG_PHY_MICROCHIP_SAMA7_USB)  += phy-sama7-utmi-clk.o 
> phy-sama7-usb.o
>  obj-y += cadence/
>  obj-y += ti/
>  obj-y += qcom/
> diff --git a/drivers/phy/phy-sama7-usb.c b/drivers/phy/phy-sama7-usb.c
> new file mode 100644
> index 00..b6fe40ecc1
> --- /dev/null
> +++ b/drivers/phy/phy-sama7-usb.c
> @@ -0,0 +1,92 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Support for Atmel/Microchip USB PHY's.
> + *
> + * Copyright (C) 2022 Microchip Technology Inc. and its subsidiaries
> + *
> + * Author: Sergiu Moga 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +struct sama7_usb_phy {
> + struct clk *uclk;
> + struct regmap *sfr;
> + int port;
> +};
> +
> +int sama7_usb_phy_init(struct phy *phy)
> +{
> + struct sama7_usb_phy *sama7_phy = dev_get_priv(phy->dev);
> + int port = sama7_phy->port;
> +
> + regmap_update_bits(sama7_phy->sfr, SAMA7_SFR_UTMI0R(port),
> +SAMA7_SFR_UTMI_RX_TX_PREEM_AMP_TUNE_1X,
> +SAMA7_SFR_UTMI_RX_TX_PREEM_AMP_TUNE_1X);
> +
> + regmap_update_bits(sama7_phy->sfr, SAMA7_SFR_UTMI0R(port),
> +SAMA7_SFR_UTMI_RX_VBUS,
> +SAMA7_SFR_UTMI_RX_VBUS);
> +
> + return 0;
> +}
> +
> +int sama7_phy_power_on(struct phy *phy)
> +{
> + struct sama7_usb_phy *sama7_phy = dev_get_priv(phy->dev);
> +
> + clk_prepare_enable(sama7_phy->uclk);
> +
> + return 0;
> +}
> +
> +int sama7_phy_power_off(struct phy *phy)
> +{
> + struct sama7_usb_phy *sama7_phy = dev_get_priv(phy->dev);
> +
> + clk_disable_unprepare(sama7_phy->uclk);
> +
> + return 0;
> +}
> +
> +int sama7_usb_phy_probe(struct udevice *dev)
> +{
> + struct sama7_usb_phy *sama7_phy = dev_get_priv(dev);
> +
> + sama7_phy->uclk = devm_clk_get(dev, "utmi_clk");
> + if (IS_ERR(sama7_phy->uclk))
> + return PTR_ERR(sama7_phy->uclk);
> +
> + sama7_phy->sfr = syscon_regmap_lookup_by_phandle(dev, "sfr-phandle");
> + if (IS_ERR(sama7_phy->sfr)) {
> + sama7_phy->sfr = NULL;

Is this needed?

> + return PTR_ERR(sama7_phy->sfr);
> + }
> +
> + return dev_read_u32(dev, "reg", _phy->port);
> +}
> +
> +static const struct phy_ops sama7_usb_phy_ops = {
> + .init = sama7_usb_phy_init,
> + .power_on = sama7_phy_power_on,
> + .power_off = sama7_phy_power_off,
> +};
> +
> +static const struct udevice_id sama7_usb_phy_of_match[] = {
> + { .compatible = "microchip,sama7g5-usb-phy", },
> + { },
> +};
> +
> +U_BOOT_DRIVER(sama7_usb_phy_driver) = {
> + .name = "sama7-usb-phy",
> + .id = UCLASS_PHY,
> + .of_match = sama7_usb_phy_of_match,
> + .ops = _usb_phy_ops,
> + .probe = sama7_usb_phy_probe,
> + .priv_auto = sizeof(struct sama7_usb_phy),
> +};
> 

[PATCH] arm64: zynqmp: Remove unused snps,refclk_fladj property

2022-12-12 Thread Michal Simek
The commit c55ac51a550c ("usb: dwc3: Program GFLADJ") hopefully fixed
issues around fladj logic. This DT property was used in Xilinx stack only
that's why remove because it is not needed anymore.

Signed-off-by: Michal Simek 
---

 arch/arm/dts/zynqmp.dtsi | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/dts/zynqmp.dtsi b/arch/arm/dts/zynqmp.dtsi
index 34504a8cbb92..0a06c73390b2 100644
--- a/arch/arm/dts/zynqmp.dtsi
+++ b/arch/arm/dts/zynqmp.dtsi
@@ -870,7 +870,6 @@
interrupts = <0 65 4>, <0 69 4>, <0 75 4>;
iommus = < 0x860>;
snps,quirk-frame-length-adjustment = <0x20>;
-   snps,refclk_fladj;
clock-names = "ref";
snps,enable_guctl1_resume_quirk;
snps,enable_guctl1_ipd_quirk;
@@ -902,7 +901,6 @@
interrupts = <0 70 4>, <0 74 4>, <0 76 4>;
iommus = < 0x861>;
snps,quirk-frame-length-adjustment = <0x20>;
-   snps,refclk_fladj;
clock-names = "ref";
snps,enable_guctl1_resume_quirk;
snps,enable_guctl1_ipd_quirk;
-- 
2.36.1



Re: [PATCH 1/1] net: missing break after net_ip6_handler()

2022-12-12 Thread Heinrich Schuchardt

On 12/7/22 06:52, Vyacheslav Mitrofanov V wrote:

On Wed, 2022-12-07 at 09:42 -0500, Tom Rini wrote:

On Wed, Dec 07, 2022 at 03:29:37PM +0100, Heinrich Schuchardt wrote:


Don't fall through to handling an IPv6 header as IPv4.

Fixes: ffdbf3bad5f3 ("net: ipv6: Incorporate IPv6 support into u-
boot net subsystem")
Addresses-Coverity-ID: 430975 ("Missing break in switch")
Signed-off-by: Heinrich Schuchardt <
heinrich.schucha...@canonical.com>
---
Do we have a unit trest of IPv6?
I guess we should at least do a IPv6 ping.


There are a few tests, yes, but more would be good.


Hello!

I have tested IPv6 (ping6 and tftpboot) with my own python scripts before 
sending to pathwork. I'll do some test conversion to use them with u-boot or 
add new tests for that soon!
Thanks!


Hello Vycheslav,

would you agree with that break being added? I didn't see a review response.

Best regards

Heinrich


[PATCH 2/2] arm64: zynqmp: Enable TI phy reset via GPIO

2022-12-12 Thread Michal Simek
From: Harini Katakam 

Add DT property to support reset of TI PHY connected to GEM.
This is present in RevA DT but needs to be extended RevB/1.0/1.1
versions which are built on top.

Fixes: 2b1db7b18c97 ("arm64: zynqmp: Wire GEM reset gpio")
Signed-off-by: Harini Katakam 
Signed-off-by: Michal Simek 
---

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

diff --git a/arch/arm/dts/zynqmp-zcu102-revB.dts 
b/arch/arm/dts/zynqmp-zcu102-revB.dts
index b2f0b1133175..de3b5ab9d93b 100644
--- a/arch/arm/dts/zynqmp-zcu102-revB.dts
+++ b/arch/arm/dts/zynqmp-zcu102-revB.dts
@@ -25,7 +25,7 @@
ti,tx-internal-delay = <0xa>;
ti,fifo-depth = <0x1>;
ti,dp83867-rxctrl-strap-quirk;
-   /* reset-gpios = <_u97 6 GPIO_ACTIVE_LOW>; */
+   reset-gpios = <_u97 6 GPIO_ACTIVE_LOW>;
};
/* Cleanup from RevA */
/delete-node/ ethernet-phy@21;
-- 
2.36.1



[PATCH 1/2] arm64: zynqmp: Describe TI phy as ethernet phy ID on ZCU102 RevB & up

2022-12-12 Thread Michal Simek
From: Harini Katakam 

TI phy requires a reset before PHY address detection to make sure
correct strapping via MIO is detected. Facilitate the same using
ethernet-phy-id compatible string. GPIO reset entry will be added in
a separate commit.
This support is present in RevA but needs to be extended to RevB/1.0/1.1
versions which are built on top.

Fixes: 13622c7a9dfa ("arm64: zynqmp: Describe TI phy as ethernet-phy-id")
Signed-off-by: Harini Katakam 
Signed-off-by: Michal Simek 
---

 arch/arm/dts/zynqmp-zcu102-revB.dts | 22 +-
 1 file changed, 13 insertions(+), 9 deletions(-)

diff --git a/arch/arm/dts/zynqmp-zcu102-revB.dts 
b/arch/arm/dts/zynqmp-zcu102-revB.dts
index 2422558b7484..b2f0b1133175 100644
--- a/arch/arm/dts/zynqmp-zcu102-revB.dts
+++ b/arch/arm/dts/zynqmp-zcu102-revB.dts
@@ -16,16 +16,20 @@
 
  {
phy-handle = <>;
-   phyc: ethernet-phy@c {
-   reg = <0xc>;
-   ti,rx-internal-delay = <0x8>;
-   ti,tx-internal-delay = <0xa>;
-   ti,fifo-depth = <0x1>;
-   ti,dp83867-rxctrl-strap-quirk;
-   /* reset-gpios = <_u97 6 GPIO_ACTIVE_LOW>; */
+   mdio: mdio {
+   phyc: ethernet-phy@c {
+   #phy-cells = <0x1>;
+   compatible = "ethernet-phy-id2000.a231";
+   reg = <0xc>;
+   ti,rx-internal-delay = <0x8>;
+   ti,tx-internal-delay = <0xa>;
+   ti,fifo-depth = <0x1>;
+   ti,dp83867-rxctrl-strap-quirk;
+   /* reset-gpios = <_u97 6 GPIO_ACTIVE_LOW>; */
+   };
+   /* Cleanup from RevA */
+   /delete-node/ ethernet-phy@21;
};
-   /* Cleanup from RevA */
-   /delete-node/ ethernet-phy@21;
 };
 
 /* Fix collision with u61 */
-- 
2.36.1



[PATCH] arm64: zynqmp: Remove unused USB DT properties

2022-12-12 Thread Michal Simek
xlnx,usb-polarity, xlnx,usb-reset-mode and snps,mask_phy_reset are not
documented in dt binding and also there is no code associated with them
that's why remove them.

Signed-off-by: Michal Simek 
---

 arch/arm/dts/zynqmp-dlc21-revA.dts  | 4 
 arch/arm/dts/zynqmp-g-a2197-00-revA.dts | 2 --
 arch/arm/dts/zynqmp-m-a2197-01-revA.dts | 4 
 arch/arm/dts/zynqmp-m-a2197-02-revA.dts | 4 
 arch/arm/dts/zynqmp-m-a2197-03-revA.dts | 4 
 arch/arm/dts/zynqmp-p-a2197-00-revA.dts | 4 
 6 files changed, 22 deletions(-)

diff --git a/arch/arm/dts/zynqmp-dlc21-revA.dts 
b/arch/arm/dts/zynqmp-dlc21-revA.dts
index 0461219ca3e7..bf0d89a5fcbe 100644
--- a/arch/arm/dts/zynqmp-dlc21-revA.dts
+++ b/arch/arm/dts/zynqmp-dlc21-revA.dts
@@ -154,8 +154,6 @@
 
  {
status = "okay";
-   xlnx,usb-polarity = <0>;
-   xlnx,usb-reset-mode = <0>;
 };
 
 _0 {
@@ -170,8 +168,6 @@
 
  {
status = "disabled"; /* Any unknown issue with USB-C */
-   xlnx,usb-polarity = <0>;
-   xlnx,usb-reset-mode = <0>;
 };
 
 _1 {
diff --git a/arch/arm/dts/zynqmp-g-a2197-00-revA.dts 
b/arch/arm/dts/zynqmp-g-a2197-00-revA.dts
index e00428351cbf..02d2427809d5 100644
--- a/arch/arm/dts/zynqmp-g-a2197-00-revA.dts
+++ b/arch/arm/dts/zynqmp-g-a2197-00-revA.dts
@@ -303,8 +303,6 @@
 
  { /* USB0 MIO52-63 */
status = "okay";
-   xlnx,usb-polarity = <0>;
-   xlnx,usb-reset-mode = <0>;
 };
 
 _0 {
diff --git a/arch/arm/dts/zynqmp-m-a2197-01-revA.dts 
b/arch/arm/dts/zynqmp-m-a2197-01-revA.dts
index 1fa023ffb13c..2d7fe592c8f9 100644
--- a/arch/arm/dts/zynqmp-m-a2197-01-revA.dts
+++ b/arch/arm/dts/zynqmp-m-a2197-01-revA.dts
@@ -461,8 +461,6 @@
 
  {
status = "okay";
-   xlnx,usb-polarity = <0>;
-   xlnx,usb-reset-mode = <0>;
 };
 
 _0 {
@@ -474,8 +472,6 @@
 
  {
status = "disabled"; /* not at mem board */
-   xlnx,usb-polarity = <0>;
-   xlnx,usb-reset-mode = <0>;
 };
 
 _1 {
diff --git a/arch/arm/dts/zynqmp-m-a2197-02-revA.dts 
b/arch/arm/dts/zynqmp-m-a2197-02-revA.dts
index 2271a6a49065..e46748d32c03 100644
--- a/arch/arm/dts/zynqmp-m-a2197-02-revA.dts
+++ b/arch/arm/dts/zynqmp-m-a2197-02-revA.dts
@@ -463,8 +463,6 @@
 
  {
status = "okay";
-   xlnx,usb-polarity = <0>;
-   xlnx,usb-reset-mode = <0>;
 };
 
 _0 {
@@ -476,8 +474,6 @@
 
  {
status = "disabled"; /* not at mem board */
-   xlnx,usb-polarity = <0>;
-   xlnx,usb-reset-mode = <0>;
 };
 
 _1 {
diff --git a/arch/arm/dts/zynqmp-m-a2197-03-revA.dts 
b/arch/arm/dts/zynqmp-m-a2197-03-revA.dts
index a89046a818fd..f564817e2c84 100644
--- a/arch/arm/dts/zynqmp-m-a2197-03-revA.dts
+++ b/arch/arm/dts/zynqmp-m-a2197-03-revA.dts
@@ -457,8 +457,6 @@
 
  {
status = "okay";
-   xlnx,usb-polarity = <0>;
-   xlnx,usb-reset-mode = <0>;
 };
 
 _0 {
@@ -470,8 +468,6 @@
 
  {
status = "disabled"; /* not at mem board */
-   xlnx,usb-polarity = <0>;
-   xlnx,usb-reset-mode = <0>;
 };
 
 _1 {
diff --git a/arch/arm/dts/zynqmp-p-a2197-00-revA.dts 
b/arch/arm/dts/zynqmp-p-a2197-00-revA.dts
index b3fe42faeee8..d63deb83e3c6 100644
--- a/arch/arm/dts/zynqmp-p-a2197-00-revA.dts
+++ b/arch/arm/dts/zynqmp-p-a2197-00-revA.dts
@@ -543,8 +543,6 @@
 
  {
status = "okay";
-   xlnx,usb-polarity = <0>;
-   xlnx,usb-reset-mode = <0>;
phy-names = "usb3-phy";
phys = < 1 PHY_TYPE_USB3 0 1>;
 };
@@ -559,8 +557,6 @@
 
  {
status = "okay";
-   xlnx,usb-polarity = <0>;
-   xlnx,usb-reset-mode = <0>;
 };
 
 _1 {
-- 
2.36.1



Re: [PATCH v5 1/1] u-boot-initial-env: rework make target

2022-12-12 Thread Tom Rini
On Mon, Dec 12, 2022 at 02:39:09PM +0100, Max Krummenacher wrote:
> Hi Tom
> 
> On Thu, Dec 8, 2022 at 9:24 PM Tom Rini  wrote:
> >
> > On Mon, Nov 28, 2022 at 09:41:22AM +0100, Max Krummenacher wrote:
> >
> > > From: Max Krummenacher 
> > >
> > > With LTO enabled the U-Boot initial environment is no longer stored
> > > in an easy accessible section in env/common.o. I.e. the section name
> > > changes from build to build, its content maybe compressed and it is
> > > annotated with additional data.
> > >
> > > Drop trying to read the initial env with elf tools from the compiler
> > > specific object file in favour of adding and using a host tool with
> > > the only functionality of printing the initial env to stdout.
> > >
> > > See also:
> > > https://lore.kernel.org/all/927b122e-1f62-e790-f5ca-30bae4332...@foss.st.com/
> > >
> > > Signed-off-by: Max Krummenacher 
> > > Acked-by: Pali Rohár 
> > > Reviewed-by: Simon Glass 
> >
> > Applied to u-boot/next, thanks!
> 
> The commit not only fixes the use case on arm64 with LTO enabled, it also
> fixes sandbox for x86-64. For me on Fedora with a `gcc (GCC) 11.3.1 20220421`
> both `make sandbox_defconfig; make u-boot-initial-env` and
> `make sandbox_defconfig; ; make u-boot-initial-env` fail with
> ```
>   GENENV  u-boot-initial-env
> objcopy: env/common.o: can't dump section
> '.rodata.default_environment' - it does not exist: file format not
> recognized
> sed: can't read u-boot-initial-env: No such file or directory
> ```
> 
> Wouldn't that merit applying the commit to master, i.e. include it in 
> v2023.01?

You can just disable LTO, and it's been an issue for a while now. It's
also easy enough to cherry-pick if there's cases out there that can't
wait.  Thanks again for addressing the problem!

-- 
Tom


signature.asc
Description: PGP signature


Re: [u-boot][PATCH 00/14] rawnand: omap_gpmc: driver model support

2022-12-12 Thread Tom Rini
On Mon, Dec 12, 2022 at 10:27:41AM +0100, Dario Binacchi wrote:
> Hi Roger,
> 
> On Mon, Dec 12, 2022 at 10:12 AM Roger Quadros  wrote:
> >
> > Hi Dario,
> >
> > On 11/12/2022 15:56, Dario Binacchi wrote:
> > > Hi Roger,
> > >
> > > On Fri, Nov 25, 2022 at 1:38 PM Roger Quadros  wrote:
> > >>
> > >> Hi Michael,
> > >>
> > >> On 08/11/2022 11:26, Michael Nazzareno Trimarchi wrote:
> > >>> Hi Roger
> > >>>
> > >>> On Fri, Nov 4, 2022 at 2:27 PM Roger Quadros  wrote:
> > 
> >  Hi,
> > 
> >  On 11/10/2022 14:49, Roger Quadros wrote:
> > > Hi,
> > >
> > > This series adds driver model support for rawnand: omap_gpmc
> > > and omap_elm drivers.
> > >
> > > This will enable the driver to be used on K2/K3 platforms as well.
> > 
> >  Any comments on patches 5 and later? Thanks
> > 
> > >>>
> > >>> We will try to close this week.
> > >>
> > >> Could you please give your comments on the last few patches. Thanks!
> > >>
> > >> cheers,
> > >> -roger
> > >>
> > >>>
> > >>> Michael
> > >>>
> > 
> >  cheers,
> >  -roger
> > 
> > >
> > > cheers,
> > > -roger
> > >
> > > Roger Quadros (14):
> > >   mtd: rawnand: omap_gpmc: Deprecate asm/arch/mem.h
> > >   mtd: rawnand: omap_gpmc: Enable build for K2/K3 platforms
> > >   mtd: rawnand: omap_gpmc: Fix build warning on 64-bit platforms
> > >   mtd: rawnand: omap_gpmc: Optimize NAND reads
> > >   mtd: rawnand: omap_gpmc: Fix BCH6/16 HW based correction
> > >   mtd: rawnand: nand_base: Allow base driver to be used in SPL without
> > > nand_bbt
> > >   mtd: rawnand: nand_spl_loaders: Fix cast type build warning
> > >   mtd: rawnand: omap_gpmc: Reduce .bss usage
> > >   dt-bindings: mtd: Add ti,gpmc-nand DT binding documentation
> > >   mtd: rawnand: omap_gpmc: support u-boot driver model
> > >   mtd: rawnand: omap_gpmc: Add SPL NAND support
> > >   mtd: rawnand: omap_gpmc: Enable SYS_NAND_PAGE_COUNT for OMAP_GPMC
> > >   dt-bindings: mtd: Add ti,elm DT binding documentation
> > >   mtd: rawnand: omap_elm: u-boot driver model support
> > >
> > >  doc/device-tree-bindings/mtd/ti,elm.yaml  |  72 +++
> > >  .../mtd/ti,gpmc-nand.yaml | 129 +
> > >  drivers/mtd/nand/raw/Kconfig  |  11 +-
> > >  drivers/mtd/nand/raw/Makefile |   2 +-
> > >  drivers/mtd/nand/raw/nand_base.c  |  18 +-
> > >  drivers/mtd/nand/raw/nand_spl_loaders.c   |   2 +-
> > >  drivers/mtd/nand/raw/omap_elm.c   |  33 +-
> > >  .../mtd => drivers/mtd/nand/raw}/omap_elm.h   |   6 +
> > >  drivers/mtd/nand/raw/omap_gpmc.c  | 500 
> > > +-
> > >  9 files changed, 637 insertions(+), 136 deletions(-)
> > >  create mode 100644 doc/device-tree-bindings/mtd/ti,elm.yaml
> > >  create mode 100644 doc/device-tree-bindings/mtd/ti,gpmc-nand.yaml
> > >  rename {include/linux/mtd => drivers/mtd/nand/raw}/omap_elm.h (97%)
> > >
> > >>>
> > >>>
> > >>>
> > >
> > > I tried to merge your whole series but after the second fix and the
> > > third time the CI/CD pipeline failed
> >
> > Do you have the link to the failure?
> 
> These are the CI/CD pipelines links:
> https://source.denx.de/u-boot/custodians/u-boot-nand-flash/-/jobs/540827
> https://source.denx.de/u-boot/custodians/u-boot-nand-flash/-/jobs/540876
> but I think you don't have permission to access them.

Note that under CI settings you can make your pipeline visible to all.
It's just not the default for some reason and I'm not sure we can change
it globally.

-- 
Tom


signature.asc
Description: PGP signature


[PATCH v3 19/19] usb: ohci-at91: Add `ohci_t` field in `ohci_at91_priv`

2022-12-12 Thread Sergiu Moga
From: Cristian Birsan 

The `ohci_register` function expects that the OHCI driver's
priv is a struct whose first field is of type `ohci_t`.
The original conversion to DM did not have it and this
inconsistency revealed itself whenever U-Boot required
multiple memory allocations resulting in a memory overwrite
of where this field would supposedly be.

Thus, add this missing field and automatically increase
the implicit size of the driver's priv to avoid whatever
future memory allocations may take place from overwriting
it.

Fixes: de1cf0a9c6 ("drivers: usb: ohci-at91: Enable OHCI functionality and 
register into DM")
Signed-off-by: Cristian Birsan 
Signed-off-by: Sergiu Moga 
Tested-by: Mihai Sain 
---


v1 -> v3:
- No change



 drivers/usb/host/ohci-at91.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index 4b1aff4127..0791769026 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -90,6 +90,7 @@ struct at91_usbh_data {
 };
 
 struct ohci_at91_priv {
+   ohci_t ohci;
struct clk *iclk;
struct clk *fclk;
struct clk *hclk;
-- 
2.34.1



[PATCH v3 18/19] configs: at91: sama7: Enable USB and RESET functionality

2022-12-12 Thread Sergiu Moga
Enable USB and RESET functionality. In order for USB to
work properly on SAMA7, the driver needs to be able
to have access to PHY's, which, in turn, need to have
access to the RSTC driver's assert/deassert functionalities.

Signed-off-by: Sergiu Moga 
Tested-by: Mihai Sain 
---



v1 -> v3:
- No change




 configs/sama7g5ek_mmc1_defconfig | 10 ++
 configs/sama7g5ek_mmc_defconfig  | 10 ++
 2 files changed, 20 insertions(+)

diff --git a/configs/sama7g5ek_mmc1_defconfig b/configs/sama7g5ek_mmc1_defconfig
index f004e44803..6c92781e60 100644
--- a/configs/sama7g5ek_mmc1_defconfig
+++ b/configs/sama7g5ek_mmc1_defconfig
@@ -38,6 +38,7 @@ CONFIG_CMD_GPIO=y
 CONFIG_CMD_I2C=y
 # CONFIG_CMD_LOADS is not set
 CONFIG_CMD_MMC=y
+CONFIG_CMD_USB=y
 CONFIG_CMD_DHCP=y
 CONFIG_CMD_MII=y
 CONFIG_CMD_PING=y
@@ -68,8 +69,12 @@ CONFIG_MMC_SDHCI_ATMEL=y
 CONFIG_PHY_MICREL=y
 CONFIG_PHY_MICREL_KSZ90X1=y
 CONFIG_MACB=y
+CONFIG_PHY=y
+CONFIG_PHY_MICROCHIP_SAMA7_USB=y
 CONFIG_PINCTRL=y
 CONFIG_PINCTRL_AT91PIO4=y
+CONFIG_DM_RESET=y
+CONFIG_RESET_AT91=y
 CONFIG_DM_SERIAL=y
 CONFIG_DEBUG_UART_ANNOUNCE=y
 CONFIG_ATMEL_USART=y
@@ -77,5 +82,10 @@ CONFIG_SYSRESET=y
 CONFIG_SYSRESET_AT91=y
 CONFIG_TIMER=y
 CONFIG_MCHP_PIT64B_TIMER=y
+CONFIG_USB=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_OHCI_HCD=y
+CONFIG_USB_ATMEL=y
+CONFIG_USB_STORAGE=y
 CONFIG_OF_LIBFDT_OVERLAY=y
 # CONFIG_EFI_LOADER_HII is not set
diff --git a/configs/sama7g5ek_mmc_defconfig b/configs/sama7g5ek_mmc_defconfig
index 5b42fc63f3..a4e57c7ba5 100644
--- a/configs/sama7g5ek_mmc_defconfig
+++ b/configs/sama7g5ek_mmc_defconfig
@@ -38,6 +38,7 @@ CONFIG_CMD_GPIO=y
 CONFIG_CMD_I2C=y
 # CONFIG_CMD_LOADS is not set
 CONFIG_CMD_MMC=y
+CONFIG_CMD_USB=y
 CONFIG_CMD_DHCP=y
 CONFIG_CMD_MII=y
 CONFIG_CMD_PING=y
@@ -68,8 +69,12 @@ CONFIG_MMC_SDHCI_ATMEL=y
 CONFIG_PHY_MICREL=y
 CONFIG_PHY_MICREL_KSZ90X1=y
 CONFIG_MACB=y
+CONFIG_PHY=y
+CONFIG_PHY_MICROCHIP_SAMA7_USB=y
 CONFIG_PINCTRL=y
 CONFIG_PINCTRL_AT91PIO4=y
+CONFIG_DM_RESET=y
+CONFIG_RESET_AT91=y
 CONFIG_DM_SERIAL=y
 CONFIG_DEBUG_UART_ANNOUNCE=y
 CONFIG_ATMEL_USART=y
@@ -77,5 +82,10 @@ CONFIG_SYSRESET=y
 CONFIG_SYSRESET_AT91=y
 CONFIG_TIMER=y
 CONFIG_MCHP_PIT64B_TIMER=y
+CONFIG_USB=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_OHCI_HCD=y
+CONFIG_USB_ATMEL=y
+CONFIG_USB_STORAGE=y
 CONFIG_OF_LIBFDT_OVERLAY=y
 # CONFIG_EFI_LOADER_HII is not set
-- 
2.34.1



[PATCH v3 16/19] configs: at91: sam9x60ek: Add required configs for the USB command

2022-12-12 Thread Sergiu Moga
Add the configs required to use the USB-related functionalities within
the bootloader.

Signed-off-by: Sergiu Moga 
---


v1 -> v2:
- No change


v2 -> v3:
- Also add USB Mass Storage on SAM9X60 Curiosity
- Add CONFIG_RESET_AT91 to enable RSTC



 configs/sam9x60_curiosity_mmc_defconfig | 8 
 configs/sam9x60ek_mmc_defconfig | 9 +
 configs/sam9x60ek_nandflash_defconfig   | 9 +
 configs/sam9x60ek_qspiflash_defconfig   | 9 +
 4 files changed, 35 insertions(+)

diff --git a/configs/sam9x60_curiosity_mmc_defconfig 
b/configs/sam9x60_curiosity_mmc_defconfig
index 732b5adf26..a09e01c197 100644
--- a/configs/sam9x60_curiosity_mmc_defconfig
+++ b/configs/sam9x60_curiosity_mmc_defconfig
@@ -37,6 +37,7 @@ CONFIG_CMD_DM=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
+CONFIG_CMD_USB=y
 # CONFIG_CMD_SETEXPR is not set
 CONFIG_CMD_DHCP=y
 CONFIG_BOOTP_BOOTFILESIZE=y
@@ -54,6 +55,7 @@ CONFIG_CLK_CCF=y
 CONFIG_CLK_AT91=y
 CONFIG_AT91_GENERIC_CLK=y
 CONFIG_AT91_SAM9X60_PLL=y
+CONFIG_AT91_SAM9X60_USB=y
 CONFIG_CPU=y
 CONFIG_AT91_GPIO=y
 CONFIG_DM_I2C=y
@@ -66,11 +68,17 @@ CONFIG_PHY_MICREL=y
 CONFIG_MACB=y
 CONFIG_PINCTRL=y
 CONFIG_PINCTRL_AT91=y
+CONFIG_DM_RESET=y
+CONFIG_RESET_AT91=y
 CONFIG_DM_SERIAL=y
 CONFIG_DEBUG_UART_ANNOUNCE=y
 CONFIG_ATMEL_USART=y
 CONFIG_TIMER=y
 CONFIG_MCHP_PIT64B_TIMER=y
+CONFIG_USB=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_ATMEL=y
+CONFIG_USB_STORAGE=y
 CONFIG_W1=y
 CONFIG_W1_GPIO=y
 CONFIG_W1_EEPROM=y
diff --git a/configs/sam9x60ek_mmc_defconfig b/configs/sam9x60ek_mmc_defconfig
index 268a485456..f703f5f39b 100644
--- a/configs/sam9x60ek_mmc_defconfig
+++ b/configs/sam9x60ek_mmc_defconfig
@@ -40,6 +40,7 @@ CONFIG_CMD_MMC=y
 CONFIG_CMD_NAND=y
 CONFIG_CMD_NAND_TRIMFFS=y
 CONFIG_CMD_SF_TEST=y
+CONFIG_CMD_USB=y
 # CONFIG_CMD_SETEXPR is not set
 CONFIG_CMD_DHCP=y
 CONFIG_BOOTP_BOOTFILESIZE=y
@@ -59,6 +60,7 @@ CONFIG_CLK_CCF=y
 CONFIG_CLK_AT91=y
 CONFIG_AT91_GENERIC_CLK=y
 CONFIG_AT91_SAM9X60_PLL=y
+CONFIG_AT91_SAM9X60_USB=y
 CONFIG_CPU=y
 CONFIG_AT91_GPIO=y
 CONFIG_DM_I2C=y
@@ -85,6 +87,8 @@ CONFIG_PHY_MICREL=y
 CONFIG_MACB=y
 CONFIG_PINCTRL=y
 CONFIG_PINCTRL_AT91=y
+CONFIG_DM_RESET=y
+CONFIG_RESET_AT91=y
 CONFIG_DM_SERIAL=y
 CONFIG_DEBUG_UART_ANNOUNCE=y
 CONFIG_ATMEL_USART=y
@@ -95,6 +99,11 @@ CONFIG_SYSRESET=y
 CONFIG_SYSRESET_AT91=y
 CONFIG_TIMER=y
 CONFIG_ATMEL_PIT_TIMER=y
+CONFIG_USB=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_OHCI_HCD=y
+CONFIG_USB_ATMEL=y
+CONFIG_USB_STORAGE=y
 CONFIG_W1=y
 CONFIG_W1_GPIO=y
 CONFIG_W1_EEPROM=y
diff --git a/configs/sam9x60ek_nandflash_defconfig 
b/configs/sam9x60ek_nandflash_defconfig
index a9cbb6e953..ff653090f7 100644
--- a/configs/sam9x60ek_nandflash_defconfig
+++ b/configs/sam9x60ek_nandflash_defconfig
@@ -41,6 +41,7 @@ CONFIG_CMD_MMC=y
 CONFIG_CMD_NAND=y
 CONFIG_CMD_NAND_TRIMFFS=y
 CONFIG_CMD_SF_TEST=y
+CONFIG_CMD_USB=y
 # CONFIG_CMD_SETEXPR is not set
 CONFIG_CMD_DHCP=y
 CONFIG_BOOTP_BOOTFILESIZE=y
@@ -61,6 +62,7 @@ CONFIG_CLK_CCF=y
 CONFIG_CLK_AT91=y
 CONFIG_AT91_GENERIC_CLK=y
 CONFIG_AT91_SAM9X60_PLL=y
+CONFIG_AT91_SAM9X60_USB=y
 CONFIG_CPU=y
 CONFIG_AT91_GPIO=y
 CONFIG_DM_I2C=y
@@ -87,6 +89,8 @@ CONFIG_PHY_MICREL=y
 CONFIG_MACB=y
 CONFIG_PINCTRL=y
 CONFIG_PINCTRL_AT91=y
+CONFIG_DM_RESET=y
+CONFIG_RESET_AT91=y
 CONFIG_DM_SERIAL=y
 CONFIG_DEBUG_UART_ANNOUNCE=y
 CONFIG_ATMEL_USART=y
@@ -97,6 +101,11 @@ CONFIG_SYSRESET=y
 CONFIG_SYSRESET_AT91=y
 CONFIG_TIMER=y
 CONFIG_ATMEL_PIT_TIMER=y
+CONFIG_USB=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_OHCI_HCD=y
+CONFIG_USB_ATMEL=y
+CONFIG_USB_STORAGE=y
 CONFIG_W1=y
 CONFIG_W1_GPIO=y
 CONFIG_W1_EEPROM=y
diff --git a/configs/sam9x60ek_qspiflash_defconfig 
b/configs/sam9x60ek_qspiflash_defconfig
index 72f08f1375..3e8277e39a 100644
--- a/configs/sam9x60ek_qspiflash_defconfig
+++ b/configs/sam9x60ek_qspiflash_defconfig
@@ -41,6 +41,7 @@ CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_NAND=y
 CONFIG_CMD_NAND_TRIMFFS=y
+CONFIG_CMD_USB=y
 # CONFIG_CMD_SETEXPR is not set
 CONFIG_CMD_DHCP=y
 CONFIG_BOOTP_BOOTFILESIZE=y
@@ -61,6 +62,7 @@ CONFIG_CLK_CCF=y
 CONFIG_CLK_AT91=y
 CONFIG_AT91_GENERIC_CLK=y
 CONFIG_AT91_SAM9X60_PLL=y
+CONFIG_AT91_SAM9X60_USB=y
 CONFIG_CPU=y
 CONFIG_AT91_GPIO=y
 CONFIG_DM_I2C=y
@@ -86,6 +88,8 @@ CONFIG_PHY_MICREL=y
 CONFIG_MACB=y
 CONFIG_PINCTRL=y
 CONFIG_PINCTRL_AT91=y
+CONFIG_DM_RESET=y
+CONFIG_RESET_AT91=y
 CONFIG_DM_SERIAL=y
 CONFIG_DEBUG_UART_ANNOUNCE=y
 CONFIG_ATMEL_USART=y
@@ -96,6 +100,11 @@ CONFIG_SYSRESET=y
 CONFIG_SYSRESET_AT91=y
 CONFIG_TIMER=y
 CONFIG_ATMEL_PIT_TIMER=y
+CONFIG_USB=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_OHCI_HCD=y
+CONFIG_USB_ATMEL=y
+CONFIG_USB_STORAGE=y
 CONFIG_W1=y
 CONFIG_W1_GPIO=y
 CONFIG_W1_EEPROM=y
-- 
2.34.1



[PATCH v3 14/19] ARM: dts: at91: sama5d2_icp: Add pinctrl nodes for USB related DT nodes

2022-12-12 Thread Sergiu Moga
Add the pinctrl subnodes required by the USB related DT nodes.

Signed-off-by: Sergiu Moga 
---


v1 -> v3:
- No change



 arch/arm/dts/at91-sama5d2_icp.dts | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/arch/arm/dts/at91-sama5d2_icp.dts 
b/arch/arm/dts/at91-sama5d2_icp.dts
index 2dffae9c5c..4f796c6c94 100644
--- a/arch/arm/dts/at91-sama5d2_icp.dts
+++ b/arch/arm/dts/at91-sama5d2_icp.dts
@@ -154,7 +154,29 @@
 ;
bias-disable;
};
+
+   pinctrl_usb_default: usb_default {
+   pinmux = ;
+   bias-disable;
+   };
+
+   pinctrl_usba_vbus: usba_vbus {
+   pinmux = ;
+   bias-disable;
+   };
};
};
};
 };
+
+ {
+   num-ports = <3>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_usb_default>;
+   status = "okay";
+};
+
+ {
+   phy_type = "hsic";
+   status = "okay";
+};
-- 
2.34.1



[PATCH v3 17/19] configs: at91: sama5d2: Enable OHCI/EHCI related configs

2022-12-12 Thread Sergiu Moga
Enable the OHCI and EHCI related configs required in order to be
able to use the USB command properly.

Signed-off-by: Sergiu Moga 
---



v1 -> v2:
- No change


v2 -> v3:
- Also add CONFIG_RESET_AT91 to enable RSTC



 configs/sama5d27_giantboard_defconfig  | 4 
 configs/sama5d27_som1_ek_mmc1_defconfig| 4 
 configs/sama5d27_som1_ek_mmc_defconfig | 4 
 configs/sama5d27_som1_ek_qspiflash_defconfig   | 4 
 configs/sama5d27_wlsom1_ek_mmc_defconfig   | 5 +
 configs/sama5d27_wlsom1_ek_qspiflash_defconfig | 4 
 configs/sama5d2_icp_mmc_defconfig  | 8 
 configs/sama5d2_icp_qspiflash_defconfig| 4 
 configs/sama5d2_ptc_ek_mmc_defconfig   | 4 
 configs/sama5d2_ptc_ek_nandflash_defconfig | 4 
 configs/sama5d2_xplained_emmc_defconfig| 4 
 configs/sama5d2_xplained_mmc_defconfig | 4 
 configs/sama5d2_xplained_qspiflash_defconfig   | 4 
 configs/sama5d2_xplained_spiflash_defconfig| 4 
 14 files changed, 61 insertions(+)

diff --git a/configs/sama5d27_giantboard_defconfig 
b/configs/sama5d27_giantboard_defconfig
index d08a42d911..d33b886116 100644
--- a/configs/sama5d27_giantboard_defconfig
+++ b/configs/sama5d27_giantboard_defconfig
@@ -81,6 +81,8 @@ CONFIG_DM_SPI_FLASH=y
 CONFIG_PINCTRL=y
 CONFIG_SPL_PINCTRL=y
 CONFIG_PINCTRL_AT91PIO4=y
+CONFIG_DM_RESET=y
+CONFIG_RESET_AT91=y
 CONFIG_DM_SERIAL=y
 CONFIG_DEBUG_UART_ANNOUNCE=y
 CONFIG_ATMEL_USART=y
@@ -95,6 +97,8 @@ CONFIG_ATMEL_PIT_TIMER=y
 CONFIG_SPL_ATMEL_PIT_TIMER=y
 CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_OHCI_HCD=y
+CONFIG_USB_ATMEL=y
 CONFIG_USB_STORAGE=y
 CONFIG_USB_GADGET=y
 CONFIG_USB_GADGET_ATMEL_USBA=y
diff --git a/configs/sama5d27_som1_ek_mmc1_defconfig 
b/configs/sama5d27_som1_ek_mmc1_defconfig
index 93ae714b62..a1f17e0f16 100644
--- a/configs/sama5d27_som1_ek_mmc1_defconfig
+++ b/configs/sama5d27_som1_ek_mmc1_defconfig
@@ -93,6 +93,8 @@ CONFIG_MACB=y
 CONFIG_PINCTRL=y
 CONFIG_SPL_PINCTRL=y
 CONFIG_PINCTRL_AT91PIO4=y
+CONFIG_DM_RESET=y
+CONFIG_RESET_AT91=y
 CONFIG_DM_SERIAL=y
 CONFIG_DEBUG_UART_ANNOUNCE=y
 CONFIG_ATMEL_USART=y
@@ -108,6 +110,8 @@ CONFIG_ATMEL_PIT_TIMER=y
 CONFIG_SPL_ATMEL_PIT_TIMER=y
 CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_OHCI_HCD=y
+CONFIG_USB_ATMEL=y
 CONFIG_USB_STORAGE=y
 CONFIG_USB_GADGET=y
 CONFIG_USB_GADGET_ATMEL_USBA=y
diff --git a/configs/sama5d27_som1_ek_mmc_defconfig 
b/configs/sama5d27_som1_ek_mmc_defconfig
index 5096366de7..67deb04af2 100644
--- a/configs/sama5d27_som1_ek_mmc_defconfig
+++ b/configs/sama5d27_som1_ek_mmc_defconfig
@@ -93,6 +93,8 @@ CONFIG_MACB=y
 CONFIG_PINCTRL=y
 CONFIG_SPL_PINCTRL=y
 CONFIG_PINCTRL_AT91PIO4=y
+CONFIG_DM_RESET=y
+CONFIG_RESET_AT91=y
 CONFIG_DM_SERIAL=y
 CONFIG_DEBUG_UART_ANNOUNCE=y
 CONFIG_ATMEL_USART=y
@@ -108,6 +110,8 @@ CONFIG_ATMEL_PIT_TIMER=y
 CONFIG_SPL_ATMEL_PIT_TIMER=y
 CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_OHCI_HCD=y
+CONFIG_USB_ATMEL=y
 CONFIG_USB_STORAGE=y
 CONFIG_USB_GADGET=y
 CONFIG_USB_GADGET_ATMEL_USBA=y
diff --git a/configs/sama5d27_som1_ek_qspiflash_defconfig 
b/configs/sama5d27_som1_ek_qspiflash_defconfig
index d7c7f42c93..265c1df32c 100644
--- a/configs/sama5d27_som1_ek_qspiflash_defconfig
+++ b/configs/sama5d27_som1_ek_qspiflash_defconfig
@@ -92,6 +92,8 @@ CONFIG_MACB=y
 CONFIG_PINCTRL=y
 CONFIG_SPL_PINCTRL=y
 CONFIG_PINCTRL_AT91PIO4=y
+CONFIG_DM_RESET=y
+CONFIG_RESET_AT91=y
 CONFIG_DM_SERIAL=y
 CONFIG_DEBUG_UART_ANNOUNCE=y
 CONFIG_ATMEL_USART=y
@@ -107,6 +109,8 @@ CONFIG_ATMEL_PIT_TIMER=y
 CONFIG_SPL_ATMEL_PIT_TIMER=y
 CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_OHCI_HCD=y
+CONFIG_USB_ATMEL=y
 CONFIG_USB_STORAGE=y
 CONFIG_USB_GADGET=y
 CONFIG_USB_GADGET_ATMEL_USBA=y
diff --git a/configs/sama5d27_wlsom1_ek_mmc_defconfig 
b/configs/sama5d27_wlsom1_ek_mmc_defconfig
index 7634a6c68f..3aa2dfda8f 100644
--- a/configs/sama5d27_wlsom1_ek_mmc_defconfig
+++ b/configs/sama5d27_wlsom1_ek_mmc_defconfig
@@ -56,6 +56,7 @@ CONFIG_CMD_GPIO=y
 CONFIG_CMD_I2C=y
 # CONFIG_CMD_LOADS is not set
 CONFIG_CMD_MMC=y
+CONFIG_CMD_USB=y
 CONFIG_CMD_DHCP=y
 CONFIG_BOOTP_BOOTFILESIZE=y
 CONFIG_CMD_MII=y
@@ -98,6 +99,8 @@ CONFIG_MACB=y
 CONFIG_PINCTRL=y
 CONFIG_SPL_PINCTRL=y
 CONFIG_PINCTRL_AT91PIO4=y
+CONFIG_DM_RESET=y
+CONFIG_RESET_AT91=y
 CONFIG_DM_SERIAL=y
 CONFIG_DEBUG_UART_ANNOUNCE=y
 CONFIG_ATMEL_USART=y
@@ -113,6 +116,8 @@ CONFIG_ATMEL_PIT_TIMER=y
 CONFIG_SPL_ATMEL_PIT_TIMER=y
 CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_OHCI_HCD=y
+CONFIG_USB_ATMEL=y
 CONFIG_USB_STORAGE=y
 CONFIG_USB_GADGET=y
 CONFIG_USB_GADGET_ATMEL_USBA=y
diff --git a/configs/sama5d27_wlsom1_ek_qspiflash_defconfig 
b/configs/sama5d27_wlsom1_ek_qspiflash_defconfig
index bb018d4c69..9a5b98df92 100644
--- a/configs/sama5d27_wlsom1_ek_qspiflash_defconfig
+++ b/configs/sama5d27_wlsom1_ek_qspiflash_defconfig
@@ -102,6 +102,8 @@ CONFIG_MACB=y
 CONFIG_PINCTRL=y
 CONFIG_SPL_PINCTRL=y
 CONFIG_PINCTRL_AT91PIO4=y
+CONFIG_DM_RESET=y
+CONFIG_RESET_AT91=y
 

[PATCH v3 15/19] ARM: dts: at91: sama5d27_wlsom1_ek: Add pinctrl nodes for USB DT nodes

2022-12-12 Thread Sergiu Moga
Add the pinctrl nodes required by the USB related DT nodes.

Signed-off-by: Sergiu Moga 
---




v1 -> v3:
- No change



 arch/arm/dts/at91-sama5d27_wlsom1_ek.dts | 25 
 1 file changed, 25 insertions(+)

diff --git a/arch/arm/dts/at91-sama5d27_wlsom1_ek.dts 
b/arch/arm/dts/at91-sama5d27_wlsom1_ek.dts
index eec183d5de..6d4b35ea96 100644
--- a/arch/arm/dts/at91-sama5d27_wlsom1_ek.dts
+++ b/arch/arm/dts/at91-sama5d27_wlsom1_ek.dts
@@ -143,7 +143,32 @@
pinmux = ;
bias-pull-up;
};
+
+   pinctrl_usb_default: usb_default {
+   pinmux = ;
+   bias-disable;
+   };
+
+   pinctrl_usba_vbus: usba_vbus {
+   pinmux = ;
+   bias-disable;
+   };
};
};
};
 };
+
+ {
+   num-ports = <3>;
+   atmel,vbus-gpio = <0
+   PIN_PA10 GPIO_ACTIVE_HIGH
+  0
+ >;
+   pinctrl-names = "default";
+   pinctrl-0 = <_usb_default>;
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
-- 
2.34.1



[PATCH v3 13/19] usb: ohci-at91: Add USB PHY functionality

2022-12-12 Thread Sergiu Moga
Add the ability to enable/disable whatever USB PHY's are
passed to the AT91 OHCI driver through DT.

Signed-off-by: Sergiu Moga 
Tested-by: Mihai Sain 
---



v1 -> v3:
- No change



 drivers/usb/host/ohci-at91.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index 8a10a29564..4b1aff4127 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -74,6 +74,10 @@ int usb_cpu_init_fail(void)
 #include 
 #include "ohci.h"
 
+#if CONFIG_IS_ENABLED(PHY_MICROCHIP_SAMA7_USB)
+#include 
+#endif
+
 #define AT91_MAX_USBH_PORTS3
 
 #define at91_for_each_port(index)  \
@@ -90,6 +94,10 @@ struct ohci_at91_priv {
struct clk *fclk;
struct clk *hclk;
bool clocked;
+
+#if CONFIG_IS_ENABLED(PHY_MICROCHIP_SAMA7_USB)
+   struct phy phy[AT91_MAX_USBH_PORTS];
+#endif
 };
 
 static void at91_start_clock(struct ohci_at91_priv *ohci_at91)
@@ -97,6 +105,13 @@ static void at91_start_clock(struct ohci_at91_priv 
*ohci_at91)
if (ohci_at91->clocked)
return;
 
+#if CONFIG_IS_ENABLED(PHY_MICROCHIP_SAMA7_USB)
+   int i;
+
+   at91_for_each_port(i)
+   generic_phy_power_on(_at91->phy[i]);
+#endif
+
clk_set_rate(ohci_at91->fclk, 4800);
clk_prepare_enable(ohci_at91->hclk);
clk_prepare_enable(ohci_at91->iclk);
@@ -109,6 +124,13 @@ static void at91_stop_clock(struct ohci_at91_priv 
*ohci_at91)
if (!ohci_at91->clocked)
return;
 
+#if CONFIG_IS_ENABLED(PHY_MICROCHIP_SAMA7_USB)
+   int i;
+
+   at91_for_each_port(i)
+   generic_phy_power_off(_at91->phy[i]);
+#endif
+
clk_disable_unprepare(ohci_at91->fclk);
clk_disable_unprepare(ohci_at91->iclk);
clk_disable_unprepare(ohci_at91->hclk);
@@ -214,6 +236,14 @@ static int ohci_atmel_probe(struct udevice *dev)
goto fail;
}
 
+#if CONFIG_IS_ENABLED(PHY_MICROCHIP_SAMA7_USB)
+   at91_for_each_port(i) {
+   generic_phy_get_by_index(dev, i, _at91->phy[i]);
+   generic_phy_init(_at91->phy[i]);
+   generic_phy_configure(_at91->phy[i], NULL);
+   }
+#endif
+
at91_start_hc(dev);
 
return ohci_register(dev, regs);
@@ -228,6 +258,7 @@ fail:
 
 static const struct udevice_id ohci_usb_ids[] = {
{ .compatible = "atmel,at91rm9200-ohci", },
+   { .compatible = "microchip,sama7g5-ohci", },
{ }
 };
 
-- 
2.34.1



[PATCH v3 12/19] phy: at91: Add support for the USB 2.0 PHY's of SAMA7

2022-12-12 Thread Sergiu Moga
In order to have USB functionality, drivers for SAMA7's
USB 2.0 PHY's have been added. There is one driver
for UTMI clock's SFR and RESET required functionalities and
one for its three possible subclocks of the phy's themselves.
In order for this layout to properly work in conjunction with
CCF and DT, the former driver will also act as a clock provider
for the three phy's with the help of a custom hook into the
driver's of_xlate method.

Signed-off-by: Sergiu Moga 
Tested-by: Mihai Sain 
---

v1 -> v3:
- No change


 drivers/phy/Kconfig  |  10 ++
 drivers/phy/Makefile |   1 +
 drivers/phy/phy-sama7-usb.c  |  92 ++
 drivers/phy/phy-sama7-utmi-clk.c | 202 +++
 4 files changed, 305 insertions(+)
 create mode 100644 drivers/phy/phy-sama7-usb.c
 create mode 100644 drivers/phy/phy-sama7-utmi-clk.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index cf4d5908d7..9fbb956783 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -281,6 +281,16 @@ config PHY_XILINX_ZYNQMP
  Enable this to support ZynqMP High Speed Gigabit Transceiver
  that is part of ZynqMP SoC.
 
+config PHY_MICROCHIP_SAMA7_USB
+   tristate "Microchip SAMA7 USB 2.0 PHY"
+   depends on PHY && ARCH_AT91
+   help
+Enable this to support SAMA7 USB 2.0 PHY.
+
+The USB 2.0 PHY integrates high-speed, full-speed and low-speed
+termination and signal switching. With a single resistor, it
+requires minimal external components.
+
 source "drivers/phy/rockchip/Kconfig"
 source "drivers/phy/cadence/Kconfig"
 source "drivers/phy/ti/Kconfig"
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index a3b9f3c5b1..9d50affd47 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -38,6 +38,7 @@ obj-$(CONFIG_PHY_MTK_TPHY) += phy-mtk-tphy.o
 obj-$(CONFIG_PHY_NPCM_USB) += phy-npcm-usb.o
 obj-$(CONFIG_PHY_IMX8MQ_USB) += phy-imx8mq-usb.o
 obj-$(CONFIG_PHY_XILINX_ZYNQMP) += phy-zynqmp.o
+obj-$(CONFIG_PHY_MICROCHIP_SAMA7_USB)  += phy-sama7-utmi-clk.o phy-sama7-usb.o
 obj-y += cadence/
 obj-y += ti/
 obj-y += qcom/
diff --git a/drivers/phy/phy-sama7-usb.c b/drivers/phy/phy-sama7-usb.c
new file mode 100644
index 00..b6fe40ecc1
--- /dev/null
+++ b/drivers/phy/phy-sama7-usb.c
@@ -0,0 +1,92 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Support for Atmel/Microchip USB PHY's.
+ *
+ * Copyright (C) 2022 Microchip Technology Inc. and its subsidiaries
+ *
+ * Author: Sergiu Moga 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct sama7_usb_phy {
+   struct clk *uclk;
+   struct regmap *sfr;
+   int port;
+};
+
+int sama7_usb_phy_init(struct phy *phy)
+{
+   struct sama7_usb_phy *sama7_phy = dev_get_priv(phy->dev);
+   int port = sama7_phy->port;
+
+   regmap_update_bits(sama7_phy->sfr, SAMA7_SFR_UTMI0R(port),
+  SAMA7_SFR_UTMI_RX_TX_PREEM_AMP_TUNE_1X,
+  SAMA7_SFR_UTMI_RX_TX_PREEM_AMP_TUNE_1X);
+
+   regmap_update_bits(sama7_phy->sfr, SAMA7_SFR_UTMI0R(port),
+  SAMA7_SFR_UTMI_RX_VBUS,
+  SAMA7_SFR_UTMI_RX_VBUS);
+
+   return 0;
+}
+
+int sama7_phy_power_on(struct phy *phy)
+{
+   struct sama7_usb_phy *sama7_phy = dev_get_priv(phy->dev);
+
+   clk_prepare_enable(sama7_phy->uclk);
+
+   return 0;
+}
+
+int sama7_phy_power_off(struct phy *phy)
+{
+   struct sama7_usb_phy *sama7_phy = dev_get_priv(phy->dev);
+
+   clk_disable_unprepare(sama7_phy->uclk);
+
+   return 0;
+}
+
+int sama7_usb_phy_probe(struct udevice *dev)
+{
+   struct sama7_usb_phy *sama7_phy = dev_get_priv(dev);
+
+   sama7_phy->uclk = devm_clk_get(dev, "utmi_clk");
+   if (IS_ERR(sama7_phy->uclk))
+   return PTR_ERR(sama7_phy->uclk);
+
+   sama7_phy->sfr = syscon_regmap_lookup_by_phandle(dev, "sfr-phandle");
+   if (IS_ERR(sama7_phy->sfr)) {
+   sama7_phy->sfr = NULL;
+   return PTR_ERR(sama7_phy->sfr);
+   }
+
+   return dev_read_u32(dev, "reg", _phy->port);
+}
+
+static const struct phy_ops sama7_usb_phy_ops = {
+   .init = sama7_usb_phy_init,
+   .power_on = sama7_phy_power_on,
+   .power_off = sama7_phy_power_off,
+};
+
+static const struct udevice_id sama7_usb_phy_of_match[] = {
+   { .compatible = "microchip,sama7g5-usb-phy", },
+   { },
+};
+
+U_BOOT_DRIVER(sama7_usb_phy_driver) = {
+   .name = "sama7-usb-phy",
+   .id = UCLASS_PHY,
+   .of_match = sama7_usb_phy_of_match,
+   .ops = _usb_phy_ops,
+   .probe = sama7_usb_phy_probe,
+   .priv_auto = sizeof(struct sama7_usb_phy),
+};
diff --git a/drivers/phy/phy-sama7-utmi-clk.c b/drivers/phy/phy-sama7-utmi-clk.c
new file mode 100644
index 00..ab9fddccf6
--- /dev/null
+++ b/drivers/phy/phy-sama7-utmi-clk.c
@@ -0,0 +1,202 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Support for Atmel/Microchip USB PHY's.

[PATCH v3 11/19] reset: at91: Add reset driver for basic assert/deassert operations

2022-12-12 Thread Sergiu Moga
Add support for at91 reset controller's basic assert/deassert
operations. Since this driver conflicts with the
SYSRESET driver because they both bind to the same RSTC node,
implement a custom bind hook that would manually bind the
sysreset driver, if enabled, to the same RSTC DT node.
Furthermore, delete the no longer needed compatibles from the
SYSRESET driver and rename it to make sure than any possible
conflicts are avoided.

Signed-off-by: Sergiu Moga 
Tested-by: Mihai Sain 
Reviewed-by: Claudiu Beznea 
---


v1 -> v3:
- No change


 drivers/reset/Kconfig|   8 ++
 drivers/reset/Makefile   |   1 +
 drivers/reset/reset-at91.c   | 141 +++
 drivers/sysreset/sysreset_at91.c |  10 +--
 4 files changed, 151 insertions(+), 9 deletions(-)
 create mode 100644 drivers/reset/reset-at91.c

diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 4cb0ba0850..e4039d7474 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -211,4 +211,12 @@ config RESET_DRA7
help
  Support for TI DRA7-RESET subsystem. Basic Assert/Deassert
  is supported.
+
+config RESET_AT91
+   bool "Enable support for Microchip/Atmel Reset Controller driver"
+   depends on DM_RESET && ARCH_AT91
+   help
+ This enables the Reset Controller driver support for Microchip/Atmel
+ SoCs. Mainly used to expose assert/deassert methods to other drivers
+ that require it.
 endmenu
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 0620b62809..6c8b45ecba 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -31,3 +31,4 @@ obj-$(CONFIG_RESET_RASPBERRYPI) += reset-raspberrypi.o
 obj-$(CONFIG_RESET_SCMI) += reset-scmi.o
 obj-$(CONFIG_RESET_ZYNQMP) += reset-zynqmp.o
 obj-$(CONFIG_RESET_DRA7) += reset-dra7.o
+obj-$(CONFIG_RESET_AT91) += reset-at91.o
diff --git a/drivers/reset/reset-at91.c b/drivers/reset/reset-at91.c
new file mode 100644
index 00..165c87acdc
--- /dev/null
+++ b/drivers/reset/reset-at91.c
@@ -0,0 +1,141 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Support for Atmel/Microchip Reset Controller.
+ *
+ * Copyright (C) 2022 Microchip Technology Inc. and its subsidiaries
+ *
+ * Author: Sergiu Moga 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct at91_reset {
+   void __iomem *dev_base;
+   struct at91_reset_data *data;
+};
+
+struct at91_reset_data {
+   u32 n_device_reset;
+   u8 device_reset_min_id;
+   u8 device_reset_max_id;
+};
+
+static const struct at91_reset_data sama7g5_data = {
+   .n_device_reset = 3,
+   .device_reset_min_id = SAMA7G5_RESET_USB_PHY1,
+   .device_reset_max_id = SAMA7G5_RESET_USB_PHY3,
+};
+
+static int at91_rst_update(struct at91_reset *reset, unsigned long id,
+  bool assert)
+{
+   u32 val;
+
+   if (!reset->dev_base)
+   return 0;
+
+   val = readl(reset->dev_base);
+   if (assert)
+   val |= BIT(id);
+   else
+   val &= ~BIT(id);
+   writel(val, reset->dev_base);
+
+   return 0;
+}
+
+static int at91_reset_of_xlate(struct reset_ctl *reset_ctl,
+  struct ofnode_phandle_args *args)
+{
+   struct at91_reset *reset = dev_get_priv(reset_ctl->dev);
+
+   if (!reset->data->n_device_reset ||
+   args->args[0] < reset->data->device_reset_min_id ||
+   args->args[0] > reset->data->device_reset_max_id)
+   return -EINVAL;
+
+   reset_ctl->id = args->args[0];
+
+   return 0;
+}
+
+static int at91_rst_assert(struct reset_ctl *reset_ctl)
+{
+   struct at91_reset *reset = dev_get_priv(reset_ctl->dev);
+
+   return at91_rst_update(reset, reset_ctl->id, true);
+}
+
+static int at91_rst_deassert(struct reset_ctl *reset_ctl)
+{
+   struct at91_reset *reset = dev_get_priv(reset_ctl->dev);
+
+   return at91_rst_update(reset, reset_ctl->id, false);
+}
+
+struct reset_ops at91_reset_ops = {
+   .of_xlate = at91_reset_of_xlate,
+   .rst_assert = at91_rst_assert,
+   .rst_deassert = at91_rst_deassert,
+};
+
+static int at91_reset_probe(struct udevice *dev)
+{
+   struct at91_reset *reset = dev_get_priv(dev);
+   struct clk sclk;
+   int ret;
+
+   reset->data = (struct at91_reset_data *)dev_get_driver_data(dev);
+   reset->dev_base = dev_remap_addr_index(dev, 1);
+   if (reset->data && reset->data->n_device_reset && !reset->dev_base)
+   return -EINVAL;
+
+   ret = clk_get_by_index(dev, 0, );
+   if (ret)
+   return ret;
+
+   return clk_prepare_enable();
+}
+
+static int at91_reset_bind(struct udevice *dev)
+{
+   struct udevice *at91_sysreset;
+
+   if (CONFIG_IS_ENABLED(SYSRESET_AT91))
+   return device_bind_driver_to_node(dev, "at91_sysreset",
+ "at91_sysreset",
+  

[PATCH v3 10/19] ARM: at91: add sama7 SFR definitions

2022-12-12 Thread Sergiu Moga
From: Cristian Birsan 

Special Function Registers(SFR) definitions for SAMA7 product family.

Signed-off-by: Cristian Birsan 
Signed-off-by: Sergiu Moga 
---



v1 -> v3:
- No change



 arch/arm/mach-at91/include/mach/sama7-sfr.h | 59 +
 1 file changed, 59 insertions(+)
 create mode 100644 arch/arm/mach-at91/include/mach/sama7-sfr.h

diff --git a/arch/arm/mach-at91/include/mach/sama7-sfr.h 
b/arch/arm/mach-at91/include/mach/sama7-sfr.h
new file mode 100644
index 00..a987ff5465
--- /dev/null
+++ b/arch/arm/mach-at91/include/mach/sama7-sfr.h
@@ -0,0 +1,59 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Microchip SFR (Special Function Registers) registers for SAMA7 family.
+ *
+ * Copyright (C) 2022 Microchip Technology Inc. and its subsidiaries
+ *
+ * Author: Cristian Birsan 
+ */
+
+#ifndef _LINUX_MFD_SYSCON_AT91_SAMA7_SFR_H
+#define _LINUX_MFD_SYSCON_AT91_SAMA7_SFR_H
+
+#define SAMA7_SFR_OHCIICR  0x00/* OHCI INT Configuration Register */
+#define SAMA7_SFR_OHCIISR  0x04/* OHCI INT Status Register */
+/* 0x08 ~ 0xe3: Reserved */
+#define SAMA7_SFR_WPMR 0xe4/* Write Protection Mode Register */
+#define SAMA7_SFR_WPSR 0xe4/* Write Protection Status Register */
+/* 0xec ~ 0x200b: Reserved */
+#define SAMA7_SFR_DEBUG0x200c  /* Debug Register */
+
+/* 0x2010 ~ 0x2027: Reserved */
+#define SAMA7_SFR_EHCIOHCI 0x2020  /* EHCI OHCI Clock Configuration Reg */
+
+#define SAMA7_SFR_HSS_AXI_QOS  0x2028  /* HSS AXI QOS Register */
+#define SAMA7_SFR_UDDRC0x202c  /* UDDRC Register */
+#define SAMA7_SFR_CAN_SRAM_SEL 0x2030  /* CAN SRAM Select. Register */
+/* 0x2034 ~ 0x203f: Reserved */
+
+#define SAMA7_SFR_UTMI00x2040
+#define SAMA7_SFR_UTMI0R(x)(SAMA7_SFR_UTMI0 + 4 * (x))
+
+#define SAMA7_SFR_UTMI0R0  0x2040  /* UTMI0 Configuration Register */
+#define SAMA7_SFR_UTMI0R1  0x2044  /* UTMI1 Configuration Register */
+#define SAMA7_SFR_UTMI0R2  0x2048  /* UTMI2 Configuration Register */
+
+/* Field definitions */
+#define SAMA7_SFR_OHCIICR_ARIE BIT(0)
+#define SAMA7_SFR_OHCIICR_APPSTART BIT(1)
+#define SAMA7_SFR_OHCIICR_USB_SUSP(x)  BIT(8 + (x))
+#define SAMA7_SFR_OHCIICR_USB_SUSPEND  GENMASK(10, 8)
+
+#define SAMA7_SFR_OHCIISR_RIS(x)   BIT(x)
+
+#define SAMA7_SFR_WPMR_WPENBIT(0)
+#define SAMA7_SFR_WPMR_KEY 0x53465200 /* SFR in ASCII*/
+#define SAMA7_SFR_WPMR_WPKEY_MASK  GENMASK(31, 8)
+
+#define SAMA7_SFR_WPSR_WPSRC_MASK  GENMASK(23, 8)
+#define SAMA7_SFR_WPSR_WPVS_MASK   BIT(0)
+
+#define SAMA7_SFR_CAN_SRAM_UPPER(x)BIT(x)
+
+#define SAMA7_SFR_UTMI_RX_VBUS BIT(25) /* VBUS Valid bit */
+#define SAMA7_SFR_UTMI_RX_TX_PREEM_AMP_TUNE_1X BIT(23) /* TXPREEMPAMPTUNE 1x */
+#define SAMA7_SFR_UTMI_COMMONONBIT(3)  /* PLL Common 
ON bit */
+
+#define SAMA7_SFR_EHCIOHCI_PHYCLK  BIT(1)  /* Alternate PHY Clk */
+
+#endif /* _LINUX_MFD_SYSCON_AT91_SAMA7_SFR_H */
-- 
2.34.1



[PATCH v3 09/19] ARM: dts: at91: sama7: Add USB related DT nodes

2022-12-12 Thread Sergiu Moga
Add the USB related DT nodes for the sama7g5ek board.

Signed-off-by: Sergiu Moga 
---


v1 -> v3:
- No change



 arch/arm/dts/at91-sama7g5ek.dts | 34 +++
 arch/arm/dts/sama7g5.dtsi   | 73 +
 2 files changed, 107 insertions(+)

diff --git a/arch/arm/dts/at91-sama7g5ek.dts b/arch/arm/dts/at91-sama7g5ek.dts
index 9b247fcaf6..31adc4d3e7 100644
--- a/arch/arm/dts/at91-sama7g5ek.dts
+++ b/arch/arm/dts/at91-sama7g5ek.dts
@@ -761,6 +761,11 @@
pinmux = ;
bias-disable;
};
+
+   pinctrl_usb_default: usb_default {
+   pinmux = ;
+   bias-disable;
+   };
 };
 
  {
@@ -837,6 +842,35 @@
status = "okay";
 };
 
+ {
+   num-ports = <3>;
+   atmel,vbus-gpio = <0
+  0
+   PIN_PC6 GPIO_ACTIVE_HIGH
+ >;
+   pinctrl-names = "default";
+   pinctrl-0 = <_usb_default>;
+   phys = <_phy2>;
+   phy-names = "usb";
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+_phy0 {
+   status = "okay";
+};
+
+_phy1 {
+   status = "okay";
+};
+
+_phy2 {
+   status = "okay";
+};
+
  {
vin-supply = <_3v3>;
status = "okay";
diff --git a/arch/arm/dts/sama7g5.dtsi b/arch/arm/dts/sama7g5.dtsi
index 6388a60e53..a6521aaa82 100644
--- a/arch/arm/dts/sama7g5.dtsi
+++ b/arch/arm/dts/sama7g5.dtsi
@@ -16,6 +16,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 / {
model = "Microchip SAMA7G5 family SoC";
@@ -103,6 +105,54 @@
};
};
 
+   utmi_clk: utmi-clk {
+   compatible = "microchip,sama7g5-utmi-clk";
+   sfr-phandle = <>;
+   #clock-cells = <1>;
+   clocks = < PMC_TYPE_CORE 27>;
+   clock-names = "utmi_clk";
+   resets = <_controller SAMA7G5_RESET_USB_PHY1>,
+<_controller SAMA7G5_RESET_USB_PHY2>,
+<_controller SAMA7G5_RESET_USB_PHY3>;
+   reset-names = "usb0_reset", "usb1_reset", "usb2_reset";
+   };
+
+   utmi {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   usb_phy0: phy@0 {
+   compatible = "microchip,sama7g5-usb-phy";
+   sfr-phandle = <>;
+   reg = <0>;
+   clocks = <_clk UTMI1>;
+   clock-names = "utmi_clk";
+   status = "disabled";
+   #phy-cells = <0>;
+   };
+
+   usb_phy1: phy@1 {
+   compatible = "microchip,sama7g5-usb-phy";
+   sfr-phandle = <>;
+   reg = <1>;
+   clocks = <_clk UTMI2>;
+   clock-names = "utmi_clk";
+   status = "disabled";
+   #phy-cells = <0>;
+   };
+
+   usb_phy2: phy@2 {
+   compatible = "microchip,sama7g5-usb-phy";
+   sfr-phandle = <>;
+   reg = <2>;
+   clocks = <_clk UTMI3>;
+   clock-names = "utmi_clk";
+   status = "disabled";
+   #phy-cells = <0>;
+   };
+   };
+
vddout25: fixed-regulator-vddout25 {
compatible = "regulator-fixed";
 
@@ -127,6 +177,24 @@
#size-cells = <1>;
ranges;
 
+   usb2: ohci@40 {
+   compatible = "microchip,sama7g5-ohci", "usb-ohci";
+   reg = <0x0040 0x10>;
+   interrupts = ;
+   clocks = < PMC_TYPE_PERIPHERAL 106>, <_clk 
UTMI1>, <_clk>;
+   clock-names = "ohci_clk", "hclk", "uhpck";
+   status = "disabled";
+   };
+
+   usb3: ehci@50 {
+   compatible = "atmel,at91sam9g45-ehci", "usb-ehci";
+   reg = <0x0050 0x10>;
+   interrupts = ;
+   clocks = <_clk>, < PMC_TYPE_PERIPHERAL 106>;
+   clock-names = "usb_clk", "ehci_clk";
+   status = "disabled";
+   };
+
nfc_sram: sram@60 {
compatible = "mmio-sram";
no-memory-wc;
@@ -559,6 +627,11 @@
status = "disabled";
};
 
+   sfr: sfr@e1624000 {
+   compatible = "microchip,sama7g5-sfr", "syscon";
+   reg = <0xe1624000 0x4000>;
+   };
+
eic: interrupt-controller@e1628000 {
compatible = "microchip,sama7g5-eic";
reg = <0xe1628000 0xec>;
-- 
2.34.1



[PATCH v3 08/19] dt-bindings: clk: at91: Define additional UTMI related clocks

2022-12-12 Thread Sergiu Moga
Add definitions for an additional main UTMI clock as well as its
respective subclocks.

Signed-off-by: Sergiu Moga 
---

v1 -> v3:
- No change


 include/dt-bindings/clk/at91.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/dt-bindings/clk/at91.h b/include/dt-bindings/clk/at91.h
index e30756b280..386f01cf31 100644
--- a/include/dt-bindings/clk/at91.h
+++ b/include/dt-bindings/clk/at91.h
@@ -18,5 +18,10 @@
 #define PMC_TYPE_PERIPHERAL3
 #define PMC_TYPE_GCK   4
 #define PMC_TYPE_SLOW  5
+#define UTMI   6
+
+#define UTMI1  0
+#define UTMI2  1
+#define UTMI3  2
 
 #endif
-- 
2.34.1



[PATCH v3 07/19] dt-bindings: reset: add sama7g5 definitions

2022-12-12 Thread Sergiu Moga
Upstream linux commit 5994f58977e0.

Add reset bindings for SAMA7G5. At the moment only USB PHYs are
included.

Signed-off-by: Sergiu Moga 
---


v1 -> v3:
- No change



 include/dt-bindings/reset/sama7g5-reset.h | 10 ++
 1 file changed, 10 insertions(+)
 create mode 100644 include/dt-bindings/reset/sama7g5-reset.h

diff --git a/include/dt-bindings/reset/sama7g5-reset.h 
b/include/dt-bindings/reset/sama7g5-reset.h
new file mode 100644
index 00..2116f41d04
--- /dev/null
+++ b/include/dt-bindings/reset/sama7g5-reset.h
@@ -0,0 +1,10 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+
+#ifndef __DT_BINDINGS_RESET_SAMA7G5_H
+#define __DT_BINDINGS_RESET_SAMA7G5_H
+
+#define SAMA7G5_RESET_USB_PHY1 4
+#define SAMA7G5_RESET_USB_PHY2 5
+#define SAMA7G5_RESET_USB_PHY3 6
+
+#endif /* __DT_BINDINGS_RESET_SAMA7G5_H */
-- 
2.34.1



[PATCH v3 06/19] usb: ohci-at91: Enable OHCI functionality and register into DM

2022-12-12 Thread Sergiu Moga
Register the OHCI driver into DM by properly initializing the required
clocks and pins required by the DT node of OHCI. In order for the VBUS
to stay enabled, a `child_pre_probe` method has been added to overcome
the DM core disabling it in `usb_scan_device`: when the generic
`device_probe` method is called, the pinctrl is processed once again,
undoing whatever changes have been made in our driver's probe method.

Signed-off-by: Sergiu Moga 
---



v1 -> v2:
- Move ` #include ` below `#if !(CONFIG_IS_ENABLED(DM_USB))` to
avoid implicit declarations warnings/errors


v2 -> v3:
- No change



 drivers/usb/host/ohci-at91.c | 183 +++
 1 file changed, 183 insertions(+)

diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index 9b955c1bd6..8a10a29564 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -5,6 +5,9 @@
  */
 
 #include 
+
+#if !(CONFIG_IS_ENABLED(DM_USB))
+
 #include 
 
 int usb_cpu_init(void)
@@ -62,3 +65,183 @@ int usb_cpu_init_fail(void)
 {
return usb_cpu_stop();
 }
+
+#elif CONFIG_IS_ENABLED(DM_GPIO)
+
+#include 
+#include 
+#include 
+#include 
+#include "ohci.h"
+
+#define AT91_MAX_USBH_PORTS3
+
+#define at91_for_each_port(index)  \
+   for ((index) = 0; (index) < AT91_MAX_USBH_PORTS; (index)++)
+
+struct at91_usbh_data {
+   enum usb_init_type init_type;
+   struct gpio_desc vbus_pin[AT91_MAX_USBH_PORTS];
+   u8 ports;   /* number of ports on root hub 
*/
+};
+
+struct ohci_at91_priv {
+   struct clk *iclk;
+   struct clk *fclk;
+   struct clk *hclk;
+   bool clocked;
+};
+
+static void at91_start_clock(struct ohci_at91_priv *ohci_at91)
+{
+   if (ohci_at91->clocked)
+   return;
+
+   clk_set_rate(ohci_at91->fclk, 4800);
+   clk_prepare_enable(ohci_at91->hclk);
+   clk_prepare_enable(ohci_at91->iclk);
+   clk_prepare_enable(ohci_at91->fclk);
+   ohci_at91->clocked = true;
+}
+
+static void at91_stop_clock(struct ohci_at91_priv *ohci_at91)
+{
+   if (!ohci_at91->clocked)
+   return;
+
+   clk_disable_unprepare(ohci_at91->fclk);
+   clk_disable_unprepare(ohci_at91->iclk);
+   clk_disable_unprepare(ohci_at91->hclk);
+   ohci_at91->clocked = false;
+}
+
+static void ohci_at91_set_power(struct at91_usbh_data *pdata, int port,
+   bool enable)
+{
+   if (!dm_gpio_is_valid(>vbus_pin[port]))
+   return;
+
+   if (enable)
+   dm_gpio_set_dir_flags(>vbus_pin[port],
+ GPIOD_IS_OUT | GPIOD_IS_OUT_ACTIVE);
+   else
+   dm_gpio_set_dir_flags(>vbus_pin[port], 0);
+}
+
+static void at91_start_hc(struct udevice *dev)
+{
+   struct ohci_at91_priv *ohci_at91 = dev_get_priv(dev);
+
+   at91_start_clock(ohci_at91);
+}
+
+static void at91_stop_hc(struct udevice *dev)
+{
+   struct ohci_at91_priv *ohci_at91 = dev_get_priv(dev);
+
+   at91_stop_clock(ohci_at91);
+}
+
+static int ohci_atmel_deregister(struct udevice *dev)
+{
+   struct at91_usbh_data *pdata = dev_get_plat(dev);
+   int i;
+
+   at91_stop_hc(dev);
+
+   at91_for_each_port(i) {
+   if (i >= pdata->ports)
+   break;
+
+   ohci_at91_set_power(pdata, i, false);
+   }
+
+   return ohci_deregister(dev);
+}
+
+static int ohci_atmel_child_pre_probe(struct udevice *dev)
+{
+   struct udevice *ohci_controller = dev_get_parent(dev);
+   struct at91_usbh_data *pdata = dev_get_plat(ohci_controller);
+   int i;
+
+   at91_for_each_port(i) {
+   if (i >= pdata->ports)
+   break;
+
+   ohci_at91_set_power(pdata, i, true);
+   }
+
+   return 0;
+}
+
+static int ohci_atmel_probe(struct udevice *dev)
+{
+   struct at91_usbh_data *pdata = dev_get_plat(dev);
+   struct ohci_at91_priv *ohci_at91 = dev_get_priv(dev);
+   int   i;
+   int   ret;
+   u32   ports;
+   struct ohci_regs  *regs = (struct ohci_regs *)dev_read_addr(dev);
+
+   if (!dev_read_u32(dev, "num-ports", ))
+   pdata->ports = ports;
+
+   at91_for_each_port(i) {
+   if (i >= pdata->ports)
+   break;
+
+   gpio_request_by_name(dev, "atmel,vbus-gpio", i,
+>vbus_pin[i], GPIOD_IS_OUT |
+GPIOD_IS_OUT_ACTIVE);
+   }
+
+   ohci_at91->iclk = devm_clk_get(dev, "ohci_clk");
+   if (IS_ERR(ohci_at91->iclk)) {
+   ret = PTR_ERR(ohci_at91->iclk);
+   goto fail;
+   }
+
+   ohci_at91->fclk = devm_clk_get(dev, "uhpck");
+   if (IS_ERR(ohci_at91->fclk)) {
+   ret = PTR_ERR(ohci_at91->fclk);
+   goto fail;
+   }
+
+   ohci_at91->hclk = 

[PATCH v3 05/19] clk: at91: sam9x60: Add initial setup of UPLL and USBCK rates

2022-12-12 Thread Sergiu Moga
In order for some of the functionalities, such as the USB clocks,
to work properly we need some clocks to be properly initialised
at the very beginning of booting.

Signed-off-by: Sergiu Moga 
---

v1 -> v2:
- Adapted according to the additional 04/19 PATCH, now making use of
`at91_clk_setup`



v2 -> v3:
- No change


 drivers/clk/at91/sam9x60.c | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/drivers/clk/at91/sam9x60.c b/drivers/clk/at91/sam9x60.c
index 14c2ffcac1..e2f72446d5 100644
--- a/drivers/clk/at91/sam9x60.c
+++ b/drivers/clk/at91/sam9x60.c
@@ -378,6 +378,31 @@ static const struct {
{ .n = "dbgu_gclk",   .id = 47, },
 };
 
+/**
+ * Clock setup description
+ * @cid:   clock id corresponding to clock subsystem
+ * @pid:   parent clock id corresponding to clock subsystem
+ * @rate:  clock rate
+ * @prate: parent rate
+ */
+static const struct pmc_clk_setup sam9x60_clk_setup[] = {
+   {
+   .cid = AT91_TO_CLK_ID(PMC_TYPE_CORE, ID_PLL_U_FRAC),
+   .rate = 96000,
+   },
+
+   {
+   .cid = AT91_TO_CLK_ID(PMC_TYPE_CORE, ID_PLL_U_DIV),
+   .rate = 48000,
+   },
+
+   {
+   .cid = AT91_TO_CLK_ID(PMC_TYPE_CORE, ID_USBCK),
+   .pid = AT91_TO_CLK_ID(PMC_TYPE_CORE, ID_PLL_U_DIV),
+   .rate = 4800,
+   },
+};
+
 #define prepare_mux_table(_allocs, _index, _dst, _src, _num, _label)   \
do {\
int _i; \
@@ -668,6 +693,11 @@ static int sam9x60_clk_probe(struct udevice *dev)
clk_dm(AT91_TO_CLK_ID(PMC_TYPE_GCK, sam9x60_gck[i].id), c);
}
 
+   /* Setup clocks. */
+   ret = at91_clk_setup(sam9x60_clk_setup, ARRAY_SIZE(sam9x60_clk_setup));
+   if (ret)
+   goto fail;
+
return 0;
 
 fail:
-- 
2.34.1



[PATCH v3 04/19] clk: at91: pmc: export clock setup to pmc

2022-12-12 Thread Sergiu Moga
From: Claudiu Beznea 

Clock setup was intended for setting clocks at boot time on SAMA7G5,
e.g. for root clocks like PLLs, that were used to feed IPs needed alive
in u-boot (e.g. Ethernet clock feed by a PLL). Export this functionality
to all at91 clocks as it may be necessary on other SoCs.

Signed-off-by: Claudiu Beznea 
Signed-off-by: Sergiu Moga 
---



v1 -> v2:
- Additional patch, this was not here in v1


v2 -> v3:
- Nothing



 drivers/clk/at91/pmc.c | 42 +
 drivers/clk/at91/pmc.h | 16 +
 drivers/clk/at91/sama7g5.c | 48 +-
 3 files changed, 64 insertions(+), 42 deletions(-)

diff --git a/drivers/clk/at91/pmc.c b/drivers/clk/at91/pmc.c
index 270892517a..87d2069d89 100644
--- a/drivers/clk/at91/pmc.c
+++ b/drivers/clk/at91/pmc.c
@@ -120,3 +120,45 @@ int at91_clk_mux_index_to_val(const u32 *table, u32 
num_parents, u32 index)
 
return table[index];
 }
+
+int at91_clk_setup(const struct pmc_clk_setup *setup, int size)
+{
+   struct clk *c, *parent;
+   int i, ret;
+
+   if (!size)
+   return 0;
+
+   if (!setup)
+   return -EINVAL;
+
+   for (i = 0; i < size; i++) {
+   ret = clk_get_by_id(setup[i].cid, );
+   if (ret)
+   return ret;
+
+   if (setup[i].pid) {
+   ret = clk_get_by_id(setup[i].pid, );
+   if (ret)
+   return ret;
+
+   ret = clk_set_parent(c, parent);
+   if (ret)
+   return ret;
+
+   if (setup[i].prate) {
+   ret = clk_set_rate(parent, setup[i].prate);
+   if (ret < 0)
+   return ret;
+   }
+   }
+
+   if (setup[i].rate) {
+   ret = clk_set_rate(c, setup[i].rate);
+   if (ret < 0)
+   return ret;
+   }
+   }
+
+   return 0;
+}
diff --git a/drivers/clk/at91/pmc.h b/drivers/clk/at91/pmc.h
index 17793b8802..ff464522aa 100644
--- a/drivers/clk/at91/pmc.h
+++ b/drivers/clk/at91/pmc.h
@@ -77,6 +77,20 @@ struct clk_usbck_layout {
u32 usbdiv_mask;
 };
 
+/**
+ * Clock setup description
+ * @cid:   clock id corresponding to clock subsystem
+ * @pid:   parent clock id corresponding to clock subsystem
+ * @rate:  clock rate
+ * @prate: parent rate
+ */
+struct pmc_clk_setup {
+   unsigned int cid;
+   unsigned int pid;
+   unsigned long rate;
+   unsigned long prate;
+};
+
 extern const struct clk_programmable_layout at91rm9200_programmable_layout;
 extern const struct clk_programmable_layout at91sam9g45_programmable_layout;
 extern const struct clk_programmable_layout at91sam9x5_programmable_layout;
@@ -160,4 +174,6 @@ void pmc_write(void __iomem *base, unsigned int off, 
unsigned int val);
 void pmc_update_bits(void __iomem *base, unsigned int off, unsigned int mask,
unsigned int bits);
 
+int at91_clk_setup(const struct pmc_clk_setup *setup, int size);
+
 #endif
diff --git a/drivers/clk/at91/sama7g5.c b/drivers/clk/at91/sama7g5.c
index d1ec3c82b5..8bd9c14156 100644
--- a/drivers/clk/at91/sama7g5.c
+++ b/drivers/clk/at91/sama7g5.c
@@ -1070,19 +1070,8 @@ static const struct {
},
 };
 
-/**
- * Clock setup description
- * @cid:   clock id corresponding to clock subsystem
- * @pid:   parent clock id corresponding to clock subsystem
- * @rate:  clock rate
- * @prate: parent rate
- */
-static const struct pmc_clk_setup {
-   unsigned int cid;
-   unsigned int pid;
-   unsigned long rate;
-   unsigned long prate;
-} sama7g5_clk_setup[] = {
+/* Clock setup description */
+static const struct pmc_clk_setup sama7g5_clk_setup[] = {
{
.cid = AT91_TO_CLK_ID(PMC_TYPE_CORE, ID_PLL_ETH_FRAC),
.rate = 62500,
@@ -1119,7 +1108,7 @@ static int sama7g5_clk_probe(struct udevice *dev)
unsigned int *muxallocs[SAMA7G5_MAX_MUX_ALLOCS];
const char *p[10];
unsigned int cm[10], m[10], *tmpclkmux, *tmpmux;
-   struct clk clk, *c, *parent;
+   struct clk clk, *c;
bool main_osc_bypass;
int ret, muxallocindex = 0, clkmuxallocindex = 0, i, j;
 
@@ -1353,34 +1342,9 @@ static int sama7g5_clk_probe(struct udevice *dev)
}
 
/* Setup clocks. */
-   for (i = 0; i < ARRAY_SIZE(sama7g5_clk_setup); i++) {
-   ret = clk_get_by_id(sama7g5_clk_setup[i].cid, );
-   if (ret)
-   goto fail;
-
-   if (sama7g5_clk_setup[i].pid) {
-   ret = clk_get_by_id(sama7g5_clk_setup[i].pid, );
-   if (ret)
-   goto fail;
-
-   ret = 

  1   2   >