Re: [U-Boot] [PATCH v2 1/2] spi: zynqmp_qspi: Add support for ZynqMP qspi driver

[Jagan Teki]

On Wed, May 2, 2018 at 2:49 PM, Siva Durga Prasad Paladugu
 wrote:
> Hi,
>
>> -Original Message-
>> From: Jagan Teki [mailto:ja...@amarulasolutions.com]
>> Sent: Wednesday, April 25, 2018 10:47 AM
>> To: Siva Durga Prasad Paladugu 
>> Cc: U-Boot-Denx 
>> Subject: Re: [U-Boot] [PATCH v2 1/2] spi: zynqmp_qspi: Add support for
>> ZynqMP qspi driver

[snip]

>> >>
>> >> > +
>> >> > +   plat->regs = (struct zynqmp_qspi_regs *)(devfdt_get_addr(bus) +
>> >> > +
>> >> > ZYNQMP_GQSPI_REG_OFFSET);
>> >> > +   plat->dma_regs = (struct zynqmp_qspi_dma_regs *)
>> >> > + (devfdt_get_addr(bus) +
>> >> > + ZYNQMP_GQSPI_DMA_REG_OFFSET);
>> >> > +
>> >> > +   ret = clk_get_by_index(bus, 0, );
>> >> > +   if (ret < 0) {
>> >> > +   dev_err(dev, "failed to get clock\n");
>> >> > +   return ret;
>> >> > +   }
>> >> > +
>> >> > +   clock = clk_get_rate();
>> >> > +   if (IS_ERR_VALUE(clock)) {
>> >> > +   dev_err(dev, "failed to get rate\n");
>> >> > +   return clock;
>> >> > +   }
>> >> > +   debug("%s: CLK %ld\n", __func__, clock);
>> >> > +
>> >> > +   ret = clk_enable();
>> >> > +   if (ret && ret != -ENOSYS) {
>> >> > +   dev_err(dev, "failed to enable clock\n");
>> >> > +   return ret;
>> >> > +   }
>> >> > +
>> >> > +   value = dev_read_u32_default(bus, "spi-rx-bus-width", 1);
>> >> > +   switch (value) {
>> >> > +   case 1:
>> >> > +   break;
>> >> > +   case 2:
>> >> > +   mode |= SPI_RX_DUAL;
>> >> > +   break;
>> >> > +   case 4:
>> >> > +   mode |= SPI_RX_QUAD;
>> >> > +   break;
>> >> > +   default:
>> >> > +   printf("Invalid spi-rx-bus-width %d\n", value);
>> >> > +   break;
>> >> > +   }
>> >> > +
>> >> > +   value = dev_read_u32_default(bus, "spi-tx-bus-width", 1);
>> >> > +   switch (value) {
>> >> > +   case 1:
>> >> > +   break;
>> >> > +   case 2:
>> >> > +   mode |= SPI_TX_DUAL;
>> >> > +   break;
>> >> > +   case 4:
>> >> > +   mode |= SPI_TX_QUAD;
>> >> > +   break;
>> >> > +   default:
>> >> > +   printf("Invalid spi-tx-bus-width %d\n", value);
>> >> > +   break;
>> >> > +   }
>> >> > +
>> >> > +   plat->tx_rx_mode = mode;
>> >> > +
>> >> > +   plat->frequency = clock;
>> >> > +   plat->speed_hz = plat->frequency;
>> >>
>> >> why we need this? all these are generic stuff which is available at
>> >> spi- uclass.c
>> >
>> > Somehow I am not able to get these from spi-uclass.c , the routine which
>> reads all these info from dt in spi-uclass.c is never getting invoked in my
>> flow.
>> > I checked other driver as well,. Do you have an idea on why is it so?
>>
>> All these attributes are from platdata which were initialized by spi-uclass.c
>> so if you need any of these we can get the dm_spi_slave_platdata from
>> your driver using dev_get_parent_platdata() function.
>
> Looks like you didn’t get my point, in my flow the routine 
> spi_slave_ofdata_to_platdata() in spi-uclass.c is
> not getting invoked at all that’s why I am not getting this data from 
> spi-uclass.c. do you have an idea on
> what could be the issue that spi_slave_ofdata_to_platdata() is not getting 
> invoked.
> I will anyway debug it but, if you already encountered this and aware of any 
> reason for this , please let me know, that really helps me.

Fix the rest and keep this as it is we will discuss on next version.

Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot,V2] imx: mx7: psci: add system reset support

[Peng Fan]

> -Original Message-
> From: Trent Piepho [mailto:tpie...@impinj.com]
> Sent: 2018年5月8日 6:07
> To: christian.gmei...@gmail.com; Peng Fan ; Anson
> Huang ; u-boot@lists.denx.de;
> albert.u.b...@aribaud.net; sba...@denx.de
> Cc: Fabio Estevam 
> Subject: Re: [U-Boot,V2] imx: mx7: psci: add system reset support
> 
> On Thu, 2018-01-04 at 17:03 +0800, Anson Huang wrote:
> > Add i.MX7 PSCI system reset support, linux kernel now can use "reboot"
> > command to reset system.
> 
> 
> > +__secure void imx_system_reset(void)
> > +{
> > +   writew(1 << 2, WDOG1_BASE_ADDR);
> > +}
> 
> This does not work properly on our board.

You could try write 0x14 to WDOG1_BASE_ADDR to see whether it works.
Here using (1 << 2) triggers both SRS and WDOG_B which seems wrong.

-Peng.

> 
> Due to an erratum in iMX7d it is necessary to wire the external WDOG_B
> signal to the pmic to cycle power in order to reset the board.  The
> Linux IMX watchdog driver works when it does a reboot via the watchdog,
> but this code does not.
> 
> When the Linux drivers is configured for an external wdog signal, using
> a DT property, it sets WCR_SRS to prevent the internal system reset in
> response to watchdog triggering.  When that is not done, as in this
> patch, the internal reset appears to reset the wdog module or iomux or
> something, which causes the imx7d to stop asserting the external wdog
> signal.
> 
> In my tests, this takes only about 2.4 µs.  Such a short wdog_b pulse
> does not appear to be sufficient to trigger the pmic to cycle power.
> 
> When SRS is set, then the WDOG_B signal will remain asserted until the
> POR_B input signal to the imx7d is asserted.  I.e., until pmic responds
> to the watchdog signal.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v5 4/7] bootcount: Rewrite autoboot to use wrapper functions from bootcount.h

[Alex Kiernan]

On Wed, May 2, 2018 at 3:11 PM Lukasz Majewski  wrote:

> The code has been refactored to use common wrappers from bootcount.h
> header.

> Signed-off-by: Lukasz Majewski 
> Reviewed-by: Stefan Roese 
> Reviewed-by: Tom Rini 

Reviewed-by:  Alex Kiernan 


> ---

> Changes in v5:
> - None

> Changes in v4:
> - Use global data pointer (gd_t *) instead of bootcount specific enum

> Changes in v3:
> - New patch

> Changes in v2: None

>   common/autoboot.c | 23 +--
>   1 file changed, 5 insertions(+), 18 deletions(-)

> diff --git a/common/autoboot.c b/common/autoboot.c
> index 2eef7a04cc..a0f7822c9e 100644
> --- a/common/autoboot.c
> +++ b/common/autoboot.c
> @@ -14,6 +14,7 @@
>   #include 
>   #include 
>   #include 
> +#include 

>   DECLARE_GLOBAL_DATA_PTR;

> @@ -291,18 +292,8 @@ const char *bootdelay_process(void)
>   {
>  char *s;
>  int bootdelay;
> -#ifdef CONFIG_BOOTCOUNT_LIMIT
> -   unsigned long bootcount = 0;
> -   unsigned long bootlimit = 0;
> -#endif /* CONFIG_BOOTCOUNT_LIMIT */
> -
> -#ifdef CONFIG_BOOTCOUNT_LIMIT
> -   bootcount = bootcount_load();
> -   bootcount++;
> -   bootcount_store(bootcount);
> -   env_set_ulong("bootcount", bootcount);
> -   bootlimit = env_get_ulong("bootlimit", 10, 0);
> -#endif /* CONFIG_BOOTCOUNT_LIMIT */
> +
> +   bootcount_inc();

>  s = env_get("bootdelay");
>  bootdelay = s ? (int)simple_strtol(s, NULL, 10) :
CONFIG_BOOTDELAY;
> @@ -324,13 +315,9 @@ const char *bootdelay_process(void)
>  s = env_get("failbootcmd");
>  } else
>   #endif /* CONFIG_POST */
> -#ifdef CONFIG_BOOTCOUNT_LIMIT
> -   if (bootlimit && (bootcount > bootlimit)) {
> -   printf("Warning: Bootlimit (%u) exceeded. Using
altbootcmd.\n",
> -  (unsigned)bootlimit);
> +   if (bootcount_error())
>  s = env_get("altbootcmd");
> -   } else
> -#endif /* CONFIG_BOOTCOUNT_LIMIT */
> +   else
>  s = env_get("bootcmd");

>  process_fdt_options(gd->fdt_blob);
> --
> 2.11.0



-- 
Alex Kiernan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] spi: kirkwood: add orion-spi compatible string

[Jagan Teki]

On Tue, May 8, 2018 at 4:24 AM, Chris Packham  wrote:
> This matches the compatible string used by the Linux kernel. This will
> allow u-boot to use the same device tree files.
>
> Signed-off-by: Chris Packham 
> ---
> This applies on top of Jagan's series
> http://patchwork.ozlabs.org/project/uboot/list/?series=33927
>
>  drivers/spi/kirkwood_spi.c | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/drivers/spi/kirkwood_spi.c b/drivers/spi/kirkwood_spi.c
> index 036fc36b8329..6a5ab8a1cba4 100644
> --- a/drivers/spi/kirkwood_spi.c
> +++ b/drivers/spi/kirkwood_spi.c
> @@ -226,6 +226,10 @@ static int mvebu_spi_ofdata_to_platdata(struct udevice 
> *bus)
> return 0;
>  }
>
> +static const struct mvebu_spi_dev orion_spi_dev_data = {
> +   .is_errata_50mhz_ac = false,
> +};
> +
>  static const struct mvebu_spi_dev armada_xp_spi_dev_data = {
> .is_errata_50mhz_ac = false,
>  };
> @@ -239,6 +243,10 @@ static const struct mvebu_spi_dev 
> armada_380_spi_dev_data = {
>  };
>
>  static const struct udevice_id mvebu_spi_ids[] = {
> +   {
> +   .compatible = "marvell,orion-spi",
> +   .data = (ulong)_spi_dev_data

Reviewed-by: Jagan Teki 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v5 3/7] bootcount: Add function wrappers to handle bootcount increment and error checking

[Alex Kiernan]

On Wed, May 2, 2018 at 3:11 PM Lukasz Majewski  wrote:

> Those two functions can be used to provide easy bootcount management.

> Signed-off-by: Lukasz Majewski 

> Reviewed-by: Tom Rini 
> Reviewed-by: Stefan Roese 
> ---

> Changes in v5:
> - Provide parenthesis for #if defined(FOO) && ...

> Changes in v4:
> - Remove enum bootcount_context and replace it with checking gd_t->flags
>(The GD_FLG_SPL_INIT is only set in SPL, it is cleared in u-boot proper,
> so can be used as indication if we are in u-boot or SPL).
> - Do not call bootcount_store() twice when it is not needed.
> - Call env_set_ulong("bootcount", bootcount); only in NON SPL context -
>Boards with TINY_PRINTF (in newest mainline) will build break as this
function
>requires simple_itoa() from vsprintf.c (now not always build in SPL).

> Changes in v3:
> - Unify those functions to also work with common/autoboot.c code
> - Add enum bootcount_context to distinguish between u-boot proper and SPL

> Changes in v2:
> - None

>   include/bootcount.h | 47 +++
>   1 file changed, 47 insertions(+)

> diff --git a/include/bootcount.h b/include/bootcount.h
> index e3b3f7028e..a886c98f44 100644
> --- a/include/bootcount.h
> +++ b/include/bootcount.h
> @@ -11,6 +11,8 @@
>   #include 
>   #include 

> +#if defined(CONFIG_SPL_BOOTCOUNT_LIMIT) ||
defined(CONFIG_BOOTCOUNT_LIMIT)
> +
>   #if !defined(CONFIG_SYS_BOOTCOUNT_LE) &&
!defined(CONFIG_SYS_BOOTCOUNT_BE)
>   # if __BYTE_ORDER == __LITTLE_ENDIAN
>   #  define CONFIG_SYS_BOOTCOUNT_LE
> @@ -40,4 +42,49 @@ static inline u32 raw_bootcount_load(volatile u32
*addr)
>  return in_be32(addr);
>   }
>   #endif
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +static inline int bootcount_error(void)
> +{
> +   unsigned long bootcount = bootcount_load();
> +   unsigned long bootlimit = env_get_ulong("bootlimit", 10, 0);
> +
> +   if (bootlimit && bootcount > bootlimit) {
> +   printf("Warning: Bootlimit (%lu) exceeded.", bootlimit);
> +   if (!(gd->flags & GD_FLG_SPL_INIT))
> +   printf(" Using altbootcmd.");
> +   printf("\n");
> +
> +   return 1;
> +   }
> +
> +   return 0;
> +}
> +
> +static inline void bootcount_inc(void)
> +{
> +   unsigned long bootcount = bootcount_load();
> +
> +   if (gd->flags & GD_FLG_SPL_INIT) {
> +   bootcount_store(++bootcount);
> +   return;
> +   }
> +
> +#ifndef CONFIG_SPL_BUILD
> +   /* Only increment bootcount when no bootcount support in SPL */
> +#ifndef CONFIG_SPL_BOOTCOUNT_LIMIT
> +   bootcount_store(++bootcount);
> +#endif
> +   env_set_ulong("bootcount", bootcount);
> +#endif /* !CONFIG_SPL_BUILD */
> +}
> +

I'm kinda confused by this code... isn't this equivalent.?

   static inline void bootcount_inc(void)
   {
  unsigned long bootcount = bootcount_load();

  bootcount_store(++bootcount);
   #ifndef CONFIG_SPL_BUILD
  env_set_ulong("bootcount", bootcount);
   #endif /* !CONFIG_SPL_BUILD */
   }

Also I suspect bootcount_store() will fail at link time on boards where the
bootcount is stored in ext4?

> +#if defined(CONFIG_SPL_BUILD) && !defined(CONFIG_SPL_BOOTCOUNT_LIMIT)
> +void bootcount_store(ulong a) {};
> +ulong bootcount_load(void) { return 0; }
> +#endif /* CONFIG_SPL_BUILD && !CONFIG_SPL_BOOTCOUNT_LIMIT */
> +#else
> +static inline int bootcount_error(void) { return 0; }
> +static inline void bootcount_inc(void) {}
> +#endif /* CONFIG_SPL_BOOTCOUNT_LIMIT || CONFIG_BOOTCOUNT_LIMIT */
>   #endif /* _BOOTCOUNT_H__ */
> --
> 2.11.0



-- 
Alex Kiernan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v5 2/7] bootcount: Add include guards into bootcount.h file

[Alex Kiernan]

On Wed, May 2, 2018 at 3:11 PM Lukasz Majewski  wrote:

> This patch adds missing include guards for bootcount.h file.

> Signed-off-by: Lukasz Majewski 
> Reviewed-by: Stefan Roese 
> Reviewed-by: Tom Rini 


Reviewed-by: Alex Kiernan 

> ---

> Changes in v5:
> - None

> Changes in v4:
> - None

> Changes in v3:
> - None

> Changes in v2:
> - New patch

>   include/bootcount.h | 3 +++
>   1 file changed, 3 insertions(+)

> diff --git a/include/bootcount.h b/include/bootcount.h
> index 06fb4d3578..e3b3f7028e 100644
> --- a/include/bootcount.h
> +++ b/include/bootcount.h
> @@ -4,6 +4,8 @@
>*
>* SPDX-License-Identifier:GPL-2.0+
>*/
> +#ifndef _BOOTCOUNT_H__
> +#define _BOOTCOUNT_H__

>   #include 
>   #include 
> @@ -38,3 +40,4 @@ static inline u32 raw_bootcount_load(volatile u32 *addr)
>  return in_be32(addr);
>   }
>   #endif
> +#endif /* _BOOTCOUNT_H__ */
> --
> 2.11.0



-- 
Alex Kiernan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v5 1/7] bootcount: spl: Enable bootcount support in SPL

[Alex Kiernan]

On Wed, May 2, 2018 at 3:11 PM Lukasz Majewski  wrote:

> New, SPL related config option - CONFIG_SPL_BOOTCOUNT_LIMIT has been
> added to allow drivers/bootcount code re-usage in SPL.

> This code is necessary to use and setup bootcount in SPL in the case of
> falcon boot mode.

> Signed-off-by: Lukasz Majewski 
> Reviewed-by: Stefan Roese 
> Reviewed-by: Tom Rini 


Reviewed-by: Alex Kiernan 


> ---

> Changes in v5:
> - None

> Changes in v4:
> - None

> Changes in v3:
> - None

> Changes in v2:
> - None

>   common/spl/Kconfig | 9 +
>   drivers/Makefile   | 1 +
>   2 files changed, 10 insertions(+)

> diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> index 259f96607e..431710a93b 100644
> --- a/common/spl/Kconfig
> +++ b/common/spl/Kconfig
> @@ -54,6 +54,15 @@ config SPL_BOOTROM_SUPPORT
>BOOT_DEVICE_BOOTROM (or fall-through to the next boot device in
the
>boot device list, if not implemented for a given board)

> +config SPL_BOOTCOUNT_LIMIT
> +   bool "Support bootcount in SPL"
> +   depends on SPL_ENV_SUPPORT
> +   help
> + On some boards, which use 'falcon' mode, it is necessary to
check
> + and increment the number of boot attempts. Such boards do not
> + use proper U-Boot for normal boot flow and hence needs those
> + adjustments to be done in the SPL.
> +
>   config SPL_RAW_IMAGE_SUPPORT
>  bool "Support SPL loading and booting of RAW images"
>  default n if (ARCH_MX6 && (SPL_MMC_SUPPORT || SPL_SATA_SUPPORT))
> diff --git a/drivers/Makefile b/drivers/Makefile
> index 6846d181aa..061331eadd 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -20,6 +20,7 @@ obj-$(CONFIG_$(SPL_TPL_)TIMER) += timer/
>   ifndef CONFIG_TPL_BUILD
>   ifdef CONFIG_SPL_BUILD

> +obj-$(CONFIG_SPL_BOOTCOUNT_LIMIT) += bootcount/
>   obj-$(CONFIG_SPL_CPU_SUPPORT) += cpu/
>   obj-$(CONFIG_SPL_CRYPTO_SUPPORT) += crypto/
>   obj-$(CONFIG_SPL_GPIO_SUPPORT) += gpio/
> --
> 2.11.0



-- 
Alex Kiernan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] Convert CONFIG_SUPPORT_EMMC_RPMB to Kconfig

[Alex Kiernan]

Convert CONFIG_SUPPORT_EMMC_RPMB to Kconfig. Split the command handling
from the underlying support and expose this through CMD_MMC_RPMB.

Signed-off-by: Alex Kiernan 
---

 README | 4 
 cmd/Kconfig| 7 +++
 cmd/mmc.c  | 6 +++---
 configs/gwventana_emmc_defconfig   | 1 +
 configs/gwventana_gw5904_defconfig | 1 +
 configs/gwventana_nand_defconfig   | 1 +
 configs/vining_2000_defconfig  | 1 +
 drivers/mmc/Kconfig| 7 +++
 include/configs/gw_ventana.h   | 1 -
 include/configs/vining_2000.h  | 1 -
 scripts/config_whitelist.txt   | 1 -
 11 files changed, 21 insertions(+), 10 deletions(-)

diff --git a/README b/README
index a62aee1..48ed3e0 100644
--- a/README
+++ b/README
@@ -1172,10 +1172,6 @@ The following options need to be configured:
CONFIG_SUPPORT_EMMC_BOOT
Enable some additional features of the eMMC boot partitions.
 
-   CONFIG_SUPPORT_EMMC_RPMB
-   Enable the commands for reading, writing and programming the
-   key for the Replay Protection Memory Block partition in eMMC.
-
 - USB Device Firmware Update (DFU) class support:
CONFIG_DFU_OVER_USB
This enables the USB portion of the DFU USB class
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 4324031..fb18eee 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -808,6 +808,13 @@ config CMD_MMC
help
  MMC memory mapped support.
 
+config CMD_MMC_RPMB
+   bool "Enable support for RPMB in the mmc command"
+   depends on CMD_MMC
+   help
+ Enable the commands for reading, writing and programming the
+ key for the Replay Protection Memory Block partition in eMMC.
+
 config CMD_NAND
bool "nand"
default y if NAND_SUNXI
diff --git a/cmd/mmc.c b/cmd/mmc.c
index 5a0b0f6..1da2cec 100644
--- a/cmd/mmc.c
+++ b/cmd/mmc.c
@@ -126,7 +126,7 @@ static int do_mmcinfo(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
return CMD_RET_SUCCESS;
 }
 
-#ifdef CONFIG_SUPPORT_EMMC_RPMB
+#if CONFIG_IS_ENABLED(CMD_MMC_RPMB)
 static int confirm_key_prog(void)
 {
puts("Warning: Programming authentication key can be done only once !\n"
@@ -816,7 +816,7 @@ static cmd_tbl_t cmd_mmc[] = {
U_BOOT_CMD_MKENT(partconf, 5, 0, do_mmc_partconf, "", ""),
U_BOOT_CMD_MKENT(rst-function, 3, 0, do_mmc_rst_func, "", ""),
 #endif
-#ifdef CONFIG_SUPPORT_EMMC_RPMB
+#if CONFIG_IS_ENABLED(CMD_MMC_RPMB)
U_BOOT_CMD_MKENT(rpmb, CONFIG_SYS_MAXARGS, 1, do_mmcrpmb, "", ""),
 #endif
U_BOOT_CMD_MKENT(setdsr, 2, 0, do_mmc_setdsr, "", ""),
@@ -880,7 +880,7 @@ U_BOOT_CMD(
" - Change the RST_n_FUNCTION field of the specified device\n"
"   WARNING: This is a write-once field and 0 / 1 / 2 are the only 
valid values.\n"
 #endif
-#ifdef CONFIG_SUPPORT_EMMC_RPMB
+#if CONFIG_IS_ENABLED(CMD_MMC_RPMB)
"mmc rpmb read addr blk# cnt [address of auth-key] - block size is 256 
bytes\n"
"mmc rpmb write addr blk# cnt  - block size is 256 
bytes\n"
"mmc rpmb key  - program the RPMB authentication 
key.\n"
diff --git a/configs/gwventana_emmc_defconfig b/configs/gwventana_emmc_defconfig
index c77de88..d4de3b4 100644
--- a/configs/gwventana_emmc_defconfig
+++ b/configs/gwventana_emmc_defconfig
@@ -56,6 +56,7 @@ CONFIG_CMD_UBI=y
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_DM=y
 CONFIG_DWC_AHSATA=y
+CONFIG_SUPPORT_EMMC_RPMB=y
 CONFIG_FSL_ESDHC=y
 CONFIG_PHYLIB=y
 CONFIG_NETDEVICES=y
diff --git a/configs/gwventana_gw5904_defconfig 
b/configs/gwventana_gw5904_defconfig
index 007b49a..fdad5ee 100644
--- a/configs/gwventana_gw5904_defconfig
+++ b/configs/gwventana_gw5904_defconfig
@@ -56,6 +56,7 @@ CONFIG_CMD_UBI=y
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_DM=y
 CONFIG_DWC_AHSATA=y
+CONFIG_SUPPORT_EMMC_RPMB=y
 CONFIG_FSL_ESDHC=y
 CONFIG_PHYLIB=y
 CONFIG_MV88E61XX_SWITCH=y
diff --git a/configs/gwventana_nand_defconfig b/configs/gwventana_nand_defconfig
index 1de7081..e6ccfef 100644
--- a/configs/gwventana_nand_defconfig
+++ b/configs/gwventana_nand_defconfig
@@ -58,6 +58,7 @@ CONFIG_CMD_UBI=y
 CONFIG_ENV_IS_IN_NAND=y
 CONFIG_DM=y
 CONFIG_DWC_AHSATA=y
+CONFIG_SUPPORT_EMMC_RPMB=y
 CONFIG_FSL_ESDHC=y
 CONFIG_NAND=y
 CONFIG_NAND_MXS=y
diff --git a/configs/vining_2000_defconfig b/configs/vining_2000_defconfig
index 1d28b2f..8cc030b 100644
--- a/configs/vining_2000_defconfig
+++ b/configs/vining_2000_defconfig
@@ -30,6 +30,7 @@ CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_EFI_PARTITION=y
 CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
+CONFIG_SUPPORT_EMMC_RPMB=y
 CONFIG_FSL_ESDHC=y
 CONFIG_PHYLIB=y
 CONFIG_PCI=y
diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index 4fa8dd8..6273aca 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -71,6 +71,13 @@ config MMC_HW_PARTITIONING
  This adds a command and an API to do hardware partitioning on eMMC
  devices.
 

[U-Boot] [PATCH v3 2/3] serial: ns16550: Add reset ctrl to driver

[Ley Foon Tan]

Add code to reset all reset signals as in serial DT node. A reset property is 
an optional feature,
so do not fail if a reset property is not present.

If a reset property is discovered, then use it to deassert, thus bringing the
IP out of reset.

Signed-off-by: Ley Foon Tan 
Reviewed-by: Marek Vasut 
---
 drivers/serial/ns16550.c |8 
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index 53550bf..9c80090 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -177,6 +178,7 @@ void NS16550_init(NS16550_t com_port, int baud_divisor)
 #if defined(CONFIG_ARCH_OMAP2PLUS)
serial_out(0x7, _port->mdr1);   /* mode select reset TL16C750*/
 #endif
+
serial_out(UART_MCRVAL, _port->mcr);
serial_out(ns16550_getfcr(com_port), _port->fcr);
if (baud_divisor != -1)
@@ -370,6 +372,12 @@ static int ns16550_serial_setbrg(struct udevice *dev, int 
baudrate)
 int ns16550_serial_probe(struct udevice *dev)
 {
struct NS16550 *const com_port = dev_get_priv(dev);
+   struct reset_ctl_bulk reset_bulk;
+   int ret;
+
+   ret = reset_get_bulk(dev, _bulk);
+   if (!ret)
+   reset_deassert_bulk(_bulk);
 
com_port->plat = dev_get_platdata(dev);
NS16550_init(com_port, -1);
-- 
1.7.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3 3/3] net: designware: Add reset ctrl to driver

[Ley Foon Tan]

Add code to reset all reset signals as in Ethernet DT node. A reset property is 
an optional feature,
so only print out a warning and do not fail if a reset property is not present.

If a reset property is discovered, then use it to deassert, thus bringing the
IP out of reset.

Signed-off-by: Ley Foon Tan 
---
 drivers/net/designware.c |8 
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/drivers/net/designware.c b/drivers/net/designware.c
index cf12521..6797691 100644
--- a/drivers/net/designware.c
+++ b/drivers/net/designware.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -664,6 +665,7 @@ int designware_eth_probe(struct udevice *dev)
u32 iobase = pdata->iobase;
ulong ioaddr;
int ret;
+   struct reset_ctl_bulk reset_bulk;
 #ifdef CONFIG_CLK
int i, err, clock_nb;
 
@@ -710,6 +712,12 @@ int designware_eth_probe(struct udevice *dev)
}
 #endif
 
+   ret = reset_get_bulk(dev, _bulk);
+   if (ret)
+   dev_warn(dev, "Can't get reset: %d\n", ret);
+   else
+   reset_deassert_bulk(_bulk);
+
 #ifdef CONFIG_DM_PCI
/*
 * If we are on PCI bus, either directly attached to a PCI root port,
-- 
1.7.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3 1/3] mmc: dwmmc: socfpga: Add reset ctrl to driver

[Ley Foon Tan]

Add code to reset all reset signals as in mmc DT node. A reset property is an 
optional feature,
so only print out a warning and do not fail if a reset property is not present.

If a reset property is discovered, then use it to deassert, thus bringing the
IP out of reset.

Signed-off-by: Ley Foon Tan 
---
 drivers/mmc/socfpga_dw_mmc.c |   17 +
 1 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/drivers/mmc/socfpga_dw_mmc.c b/drivers/mmc/socfpga_dw_mmc.c
index fa0e449..eb7e64e 100644
--- a/drivers/mmc/socfpga_dw_mmc.c
+++ b/drivers/mmc/socfpga_dw_mmc.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -33,6 +34,20 @@ struct dwmci_socfpga_priv_data {
unsigned intsmplsel;
 };
 
+static void socfpga_dwmci_reset(struct udevice *dev)
+{
+   struct reset_ctl_bulk reset_bulk;
+   int ret;
+
+   ret = reset_get_bulk(dev, _bulk);
+   if (ret) {
+  dev_warn(dev, "Can't get reset: %d\n", ret);
+  return;
+   }
+
+   reset_deassert_bulk(_bulk);
+}
+
 static void socfpga_dwmci_clksel(struct dwmci_host *host)
 {
struct dwmci_socfpga_priv_data *priv = host->priv;
@@ -109,6 +124,8 @@ static int socfpga_dwmmc_probe(struct udevice *dev)
struct dwmci_socfpga_priv_data *priv = dev_get_priv(dev);
struct dwmci_host *host = >host;
 
+   socfpga_dwmci_reset(dev);
+
 #ifdef CONFIG_BLK
dwmci_setup_cfg(>cfg, host, host->bus_hz, 40);
host->mmc = >mmc;
-- 
1.7.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3 0/3] drivers: Add reset ctrl to drivers

[Ley Foon Tan]

Add reset ctrl to dwmmc socfpga, designware Ethernet and ns16550 serial drivers.

A reset property is an optional feature, so only print out a warning and
do not fail if a reset property is not present.

If a reset property is discovered, then use it to deassert, thus bringing the
IP out of reset.

This is preparation to upstream Intel Stratix 10 SoC support in [1].

v2 change:
- remove #ifdef CONFIG_DM_RESET switch
- add maintainer emails

History:
v1: https://patchwork.ozlabs.org/cover/905519/
v2: https://patchwork.ozlabs.org/cover/908667/

[1]: https://patchwork.ozlabs.org/cover/900499/

Ley Foon Tan (3):
  mmc: dwmmc: socfpga: Add reset ctrl to driver
  serial: ns16550: Add reset ctrl to driver
  net: designware: Add reset ctrl to driver

 drivers/mmc/socfpga_dw_mmc.c |   17 +
 drivers/net/designware.c |8 
 drivers/serial/ns16550.c |8 
 3 files changed, 33 insertions(+), 0 deletions(-)

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v7 06/35] musb: sunxi: Add OTG device clkgate and reset for H3/H5

[Marek Vasut]

On 05/07/2018 10:11 PM, Maxime Ripard wrote:
> On Mon, May 07, 2018 at 05:32:34PM +0200, Marek Vasut wrote:
>> On 05/07/2018 04:52 PM, Maxime Ripard wrote:
>>> On Mon, May 07, 2018 at 01:47:43PM +0200, Marek Vasut wrote:
 On 05/07/2018 09:33 AM, Jagan Teki wrote:
> Add OTG device clkgate and reset for H3/H5 through driver_data.
>
> Signed-off-by: Jagan Teki 

 Why don't you implement a clock driver for this SoC instead ?
>>>
>>> Aren't you asking a bit too much?
>>
>> I am not asking for anything, this is a question, not a request.
> 
> My bad then, this definitely sounded like a request to me.

So uh, how do I make this NOT sound like a request to you ?
Can you phrase it for me ?

>> I asked why not implement a clock driver and use it just like any other
>> civilized modern driver would instead of digging in the clock controller
>> registers from a USB framework driver (which is icky).
> 
> From an absolute point of view, I agree. But we are where we are.

Which is where exactly ?

>> I think that if we are doing some sort of conversion, we should do it
>> completely and properly instead of leaving in hacks like this. A clock
>> driver which allows enabling/disabling clock is probably like what, 2
>> hour work ? So maybe it's worth investing that time up front to save
>> maintenance burden in the future.
> 
> This is definitely not a 2 hours job. More like 2 weeks if you want to
> do it properly, and by which I mean creating the clock driver,
> converting all the users to it, and then making sure you don't have
> any regressions.
> 
> This is on our radar, but this won't happen overnight.

Fine

>>> Since the first post of these patches, you've asked to rework in a
>>> significant manner the driver already, including doing a new PHY
>>> driver to use the device model, and making other substantial changes
>>> to it.
>>
>> Well yes, because it was crap at the beginning and I don't want to see
>> the crap accumulating. It has become much better since, as you can see I
>> only had a few minor comments.
> 
> And that's totally your role, but at the same time, the point of this
> series is not to fix the whole world, but rather add support for one
> particular SoC that is using pretty much the same design than any of
> our other SoCs' USB phy before. And here we are, 35 patches and
> counting.

If I said "yes" to every single patch adding just a minor additional bit
of crap to the codebase, we'd be in the state in which we were in 2012,
sinking under the boatload of ifdeffery and ad-hoc solutions. So I think
some push is needed to avoid that situation.

>>> Jagan complied to all your requests so far, but this one is going to
>>> create yet another ton of patches on top of an (already) 35 patches
>>> series. And this request comes out of nowhere at the 7th version.
>>
>> I disagree, one clock driver patch and a tweak to the series, unless I
>> missed something obvious.
> 
> This won't be one clock driver patch. Seriously.

Fine

>>> Creating a new clock driver will take a lot of effort, and this really
>>> surprise me given that we've had strictly no feedback from you on this
>>> considering all the previous SoCs bringups we've done so far.
>>
>> What do you mean by "this" ? I think i did review the previous
>> iterations of this series ? If not, was I on CC ?
> 
> You did, and thanks a lot for that. The only thing I'm noting is that
> it's the first time you're being so picky about a series.

Er, no, I am always picky and hard.

> I appreciate
> that you have to draw the line somewhere, and when things you want in
> your subsystem aren't moving as fast as you'd like them to be you have
> to enforce new rules. But if you were unhappy about something, you
> never told us, which doesn't seem like a good path forward
> either. Even in your previous reviews of that particular series.

I think I pointed out pretty much all of it ? If I missed something,
it's because it was hidden and didn't surface until the patchset got
into some better shape.

>> I have to admit, I don't really care about the rest of the Allwinner SoC
>> code or what you do there, I only care about the USB part and this
>> poking of clock controller registers seems wrong in a DM/DT driver.
> 
> And I do agree on that. But we also have some history to carry.
> 
>> I also don't mind if the clock driver comes later, but I would like to
>> see it happen at some point (soon) to remove this register poking.
> 
> Awesome then :)

Is this going to happen at some point ?

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [GIT PULL] u-boot-uniphier/master

[Masahiro Yamada]

Hi Tom,

Now that MW is open, please pull UniPhier SoC updates.
Thanks.


The following changes since commit a43d46a73cb2c40481791cb292b8eb0b5a80d55e:

  arm: v7R: Add support for enabling caches (2018-05-07 15:53:29 -0400)

are available in the git repository at:

  git://git.denx.de/u-boot-uniphier.git master

for you to fetch changes up to 079b54f29e4bfacb4a84c859d8ea95e50fb50bb5:

  ARM: uniphier: enable CONFIG_PINCONF (2018-05-08 10:25:15 +0900)


Masahiro Yamada (7):
  pinctrl: uniphier: remove unneeded pin data of LD6b SoC
  pinctrl: uniphier: replace printf() with dev_err()
  pinctrl: uniphier: include  instead of 
  pinctrl: uniphier: support per-pin configuration via DT
  pinctrl: uniphier: support drive-strength configuration
  pinctrl: uniphier: add ethernet TX pin data for LD20
  ARM: uniphier: enable CONFIG_PINCONF

 configs/uniphier_v8_defconfig|   1 +
 drivers/pinctrl/uniphier/pinctrl-uniphier-core.c | 140
+++--
 drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c |  11 +
 drivers/pinctrl/uniphier/pinctrl-uniphier-ld6b.c |  13 --
 drivers/pinctrl/uniphier/pinctrl-uniphier.h  |  49 +---
 5 files changed, 190 insertions(+), 24 deletions(-)


-- 
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 0/7] ARM: uniphier: support drive-strength pin configuration

[Masahiro Yamada]

2018-05-05 19:53 GMT+09:00 Masahiro Yamada :
>
> I will merge this series after the release.
>
>
>
> Masahiro Yamada (7):
>   pinctrl: uniphier: remove unneeded pin data of LD6b
>   pinctrl: uniphier: replace printf() with dev_err()
>   pinctrl: uniphier: include  instead of
> 
>   pinctrl: uniphier: support per-pin configuration via DT
>   pinctrl: uniphier: support drive-strength configuration
>   pinctrl: uniphier: add ethernet TX pin data for LD20
>   ARM: uniphier: enable CONFIG_PINCONF
>

Series, applied to u-boot-uniphier.

-- 
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 2/2] sunxi: binman: Add U-Boot binary size check

[Måns Rullgård]

Maxime Ripard  writes:

> On Wed, May 02, 2018 at 03:24:50PM +0100, Måns Rullgård wrote:
>> Maxime Ripard  writes:
>> 
>> > 1;5201;0c
>> > On Wed, May 02, 2018 at 10:34:49AM +0100, Måns Rullgård wrote:
>> >> Siarhei Siamashka  writes:
>> >> 
>> >> > On Tue, 01 May 2018 18:25:06 +0100
>> >> > Måns Rullgård  wrote:
>> >> >
>> >> >> Maxime Ripard  writes:
>> >> >> 
>> >> >> > The U-Boot binary may trip over its actual allocated size in the 
>> >> >> > storage.
>> >> >> > In such a case, the environment will not be readable anymore (because
>> >> >> > corrupted when the new image was flashed), and any attempt at using 
>> >> >> > saveenv
>> >> >> > to reconstruct the environment will result in a corrupted U-Boot 
>> >> >> > binary.
>> >> >> >
>> >> >> > Reviewed-by: Andre Przywara 
>> >> >> > Signed-off-by: Maxime Ripard 
>> >> >> > ---
>> >> >> >  arch/arm/dts/sunxi-u-boot.dtsi | 12 
>> >> >> >  1 file changed, 12 insertions(+)
>> >> >> >
>> >> >> > diff --git a/arch/arm/dts/sunxi-u-boot.dtsi 
>> >> >> > b/arch/arm/dts/sunxi-u-boot.dtsi
>> >> >> > index 5adfd9bca2ec..72e95afd780e 100644
>> >> >> > --- a/arch/arm/dts/sunxi-u-boot.dtsi
>> >> >> > +++ b/arch/arm/dts/sunxi-u-boot.dtsi
>> >> >> > @@ -1,5 +1,14 @@
>> >> >> >  #include 
>> >> >> >
>> >> >> > +/*
>> >> >> > + * This is the maximum size the U-Boot binary can be, which is 
>> >> >> > basically
>> >> >> > + * the start of the environment, minus the start of the U-Boot 
>> >> >> > binary in
>> >> >> > + * the MMC. This makes the assumption that the MMC is using 
>> >> >> > 512-bytes
>> >> >> > + * blocks, but devices using something other than that remains to be
>> >> >> > + * seen.
>> >> >> > + */
>> >> >> > +#define UBOOT_MMC_MAX_SIZE  (CONFIG_ENV_OFFSET - 
>> >> >> > (CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR * 512))
>> >> >> > +
>> >> >> >  / {
>> >> >> >  binman {
>> >> >> >  filename = "u-boot-sunxi-with-spl.bin";
>> >> >> > @@ -8,6 +17,9 @@
>> >> >> >  filename = "spl/sunxi-spl.bin";
>> >> >> >  };
>> >> >> >  u-boot-img {
>> >> >> > +#ifdef CONFIG_MMC
>> >> >> > +size = ;
>> >> >> > +#endif
>> >> >> >  pos = ;
>> >> >> >  };
>> >> >> >  };
>> >> >> > --   
>> >> >> 
>> >> >> This is broken in (at least) two ways:
>> >> >> 
>> >> >> 1. It is simply nonsensical if u-boot and env are on different devices
>> >> >>or not on mmc even if mmc support is enabled.
>> >> >> 
>> >> >> 2. It causes u-boot-sunxi-with-spl.bin to be padded to the env offset.
>> >> >>At best, this is useless.  If the env doesn't immediately follow
>> >> >>u-boot, it really breaks things.
>> >> >> 
>> >> >> Please fix or revert, I don't really care which.
>> >> >
>> >> > The padding is not useless. It reserves space for future size expansions
>> >> > and makes it harder for the users to hurt themselves.
>> >> >
>> >> > For example, if the padded U-Boot size is 1024K while the actual size
>> >> > is only ~800K, then adventurous users might be tempted to fit some of
>> >> > their data into this gap. Yay, ~200K of storage space for free! Except
>> >> > that the next U-Boot release may grow up to 900K without any warning
>> >> > and if the users are not careful enough, then their data would be
>> >> > corrupted during upgrade.
>> >> 
>> >> Do U-Boot users really need that level of hand-holding?
>> >
>> > Yes, and that's never a good argument to make, because...
>> >
>> >> > Could you please tell us what is your problem and why reverting this
>> >> > patch would fix it?
>> >> 
>> >> See above.  Best case, it just wastes space in the created file.  If the
>> >> configuration is anything other than U-Boot immediately followed by env
>> >> on the same device, it _will_ break things horribly.  A few examples:
>> >> 
>> >> 1.  U-Boot and env are on different devices, e.g. U-Boot on mmc and env
>> >> in SPI NOR flash.  In this case, padding the file to the env offset
>> >> makes no sense.  Writing the image will corrupt anything stored
>> >> after U-Boot at a smaller (but still safe) offset.
>> >
>> > .. I could make pretty much the same one for all your cases, which
>> > would be completely useless, and wouldn't fix anything.
>> 
>> Huh?  I'm saying we shouldn't "helpfully" do things that actually break
>> perfectly valid setups.  U-Boot users are expected to know what they are
>> doing, and shouldn't need that kind of help.  In my opinion.
>
> My point is that this is a slippery slope. Anyway..

Yes, trying to be overly helpful is indeed a slippery slope.

>> > I guess this one could be solved using an ifdef guard with
>> > ENV_IS_IN_MMC.
>> 
>> Not if env is on a different mmc device.
>
> Ah, right...
>
>> >> 2.  U-Boot at a non-zero offset, followed by 

Re: [U-Boot] [PATCH 3/3] rockchip: fix incorrect detection of ram size

[Marty E. Plummer]

On Mon, May 07, 2018 at 11:16:28AM +0200, Dr. Philipp Tomsich wrote:
> 
> > On 7 May 2018, at 04:34, Marty E. Plummer  wrote:
> > 
> > On Mon, May 07, 2018 at 10:20:55AM +0800, Kever Yang wrote:
> >> Hi Marty,
> >> 
> >> 
> >> On 05/06/2018 10:25 PM, Marty E. Plummer wrote:
> >>> Taken from coreboot's src/soc/rockchip/rk3288/sdram.c
> >>> 
> >>> Without this change, my u-boot build for the asus c201 chromebook (4GiB)
> >>> is incorrectly detected as 0 Bytes of ram.
> >> 
> >> I know the root cause for this issue, and I have a local patch for it.
> >> The rk3288 is 32bit, and 4GB size is just out of range, so we need to 
> >> before
> >> the max size before return with '<<20'. Sorry for forgot to send it out.
> >> 
> >>> 
> >>> Signed-off-by: Marty E. Plummer 
> >>> ---
> >>> arch/arm/mach-rockchip/sdram_common.c | 62 ---
> >>> 1 file changed, 37 insertions(+), 25 deletions(-)
> >>> 
> >>> diff --git a/arch/arm/mach-rockchip/sdram_common.c 
> >>> b/arch/arm/mach-rockchip/sdram_common.c
> >>> index 76dbdc8715..a9c9f970a4 100644
> >>> --- a/arch/arm/mach-rockchip/sdram_common.c
> >>> +++ b/arch/arm/mach-rockchip/sdram_common.c
> >>> @@ -10,6 +10,8 @@
> >>> #include 
> >>> #include 
> >>> #include 
> >>> +#include 
> >>> +#include 
> >>> 
> >>> DECLARE_GLOBAL_DATA_PTR;
> >>> size_t rockchip_sdram_size(phys_addr_t reg)
> >>> @@ -19,34 +21,44 @@ size_t rockchip_sdram_size(phys_addr_t reg)
> >>>   size_t size_mb = 0;
> >>>   u32 ch;
> >>> 
> >>> - u32 sys_reg = readl(reg);
> >>> - u32 ch_num = 1 + ((sys_reg >> SYS_REG_NUM_CH_SHIFT)
> >>> -& SYS_REG_NUM_CH_MASK);
> >>> + if (!size_mb) {
> >> 
> >> I don't understand this and follow up changes, we don't really need it,
> >> isn't it?
> >> I think don't need the changes before here.
> > Yeah, that was just another level of indentation for the if (!size_mb)
> > guard, but I've reworked the patch to not do that as it was pointed out
> > that since size_mb is initialized to 0 prior.
> >>> + /*
> >>> +  * we use the 0x~0xfeff space
> >>> +  * since 0xff00~0x is soc register space
> >>> +  * so we reserve it
> >>> +  */
> >>> + size_mb = min(size_mb, 0xff00/SZ_1M);
> >> 
> >> This is what we really need, as Klaus point out, we need to use
> >> SDRAM_MAX_SIZE
> >> instead of hard code.
> > Yeah, I've got a rework on that which uses SDRAM_MAX_SIZE as instructed,
> > build and boot tested on my hardware.
> 
> In that case you just masked the problem but didn???t solve it: assuming 
> size_mb
> is size_t (I???ll assume this is 64bit, but did not check), then your 4GB is 
> 0x1__ )
> which overflows to 0x0 when converted to a u32.
> 
> In other words: we need to figure out where the truncation occurs (image what
> happens if a new 32bit processor with LPAE comes out???).
> 
A very valid point. With the following patch to sdram_common.c and
sdram_rk3288.c applied I get the debug output that follows it:
diff --git a/arch/arm/mach-rockchip/sdram_common.c 
b/arch/arm/mach-rockchip/sdram_common.c
index 232a7fa655..0fe69bf558 100644
--- a/arch/arm/mach-rockchip/sdram_common.c
+++ b/arch/arm/mach-rockchip/sdram_common.c
@@ -4,6 +4,7 @@
  * SPDX-License-Identifier: GPL-2.0+
  */
 
+#define DEBUG 1
 #include 
 #include 
 #include 
@@ -39,16 +40,19 @@ size_t rockchip_sdram_size(phys_addr_t reg)
SYS_REG_ROW_3_4_MASK;
 
chipsize_mb = (1 << (cs0_row + col + bk + bw - 20));
+   debug("%s: %d: chipsize_mb %x\n", __func__, __LINE__, 
chipsize_mb);
 
if (rank > 1)
chipsize_mb += chipsize_mb >> (cs0_row - cs1_row);
if (row_3_4)
chipsize_mb = chipsize_mb * 3 / 4;
size_mb += chipsize_mb;
+   debug("%s: %d: size_mb %x\n", __func__, __LINE__, size_mb);
debug("rank %d col %d bk %d cs0_row %d bw %d row_3_4 %d\n",
  rank, col, bk, cs0_row, bw, row_3_4);
}
 
+   debug("%s: %d: size_mb %x\n", __func__, __LINE__, size_mb);
size_mb = min(size_mb, SDRAM_MAX_SIZE/SZ_1M);
 
return (size_t)size_mb << 20;
diff --git a/drivers/ram/rockchip/sdram_rk3288.c 
b/drivers/ram/rockchip/sdram_rk3288.c
index d99bf12476..9738eb088f 100644
--- a/drivers/ram/rockchip/sdram_rk3288.c
+++ b/drivers/ram/rockchip/sdram_rk3288.c
@@ -7,6 +7,7 @@
  * Adapted from coreboot.
  */
 
+#define DEBUG 1
 #include 
 #include 
 #include 

---
U-Boot SPL 2018.05-rc3-02370-g309384e84b-dirty (May 07 2018 - 19:42:15 -0500)
Trying to boot from SPI


U-Boot 2018.05-rc3-02370-g309384e84b-dirty (May 07 2018 - 19:42:15 -0500)

Model: Google Speedy
DRAM:  rockchip_sdram_size ff73009c 3c50dc50
rockchip_sdram_size: 42: chipsize_mb 400
rockchip_sdram_size: 49: size_mb 800
rank 2 col 11 bk 3 cs0_row 14 bw 2 row_3_4 0
rockchip_sdram_size: 42: chipsize_mb 400

Re: [U-Boot] [U-Boot, v2, 4/4] syscon: add Linux-compatible syscon API

[Tom Rini]

On Thu, Apr 19, 2018 at 12:14:04PM +0900, Masahiro Yamada wrote:

> The syscon implementation in U-Boot is different from that in Linux.
> Thus, DT files imported from Linux do not work for U-Boot.
> 
> In U-Boot driver model, each node is bound to a dedicated driver
> that is the most compatible to it.  This design gets along with the
> concept of DT, and the syscon in Linux originally worked like that.
> 
> However, Linux commit bdb0066df96e ("mfd: syscon: Decouple syscon
> interface from platform devices") changed the behavior because it is
> useful to let a device bind to another driver, but still work as a
> syscon provider.
> 
> That change had happened before U-Boot initially supported the syscon
> driver by commit 6f98b7504f70 ("dm: Add support for generic system
> controllers (syscon)").  So, the U-Boot's syscon works differently
> from the beginning.  I'd say this is mis-implementation given that
> DT is not oriented to a particular project, but Linux is the canon
> of DT in practice.
> 
> The problem typically arises in the combination of "syscon" and
> "simple-mfd" compatibles.
> 
> In Linux, they are orthogonal, i.e., the order between "syscon" and
> "simple-mfd" does not matter at all.
> 
> Assume the following compatible.
> 
>compatible = "foo,bar-syscon", "syscon", "simple-mfd";
> 
> In U-Boot, this device node is bound to the syscon driver
> (driver/core/syscon-uclass.c) since the "syscon" is found to be the
> most compatible.  Then, syscon_get_regmap() succeeds.
> 
> However,
> 
>compatible = "foo,bar-syscon", "simple-mfd", "syscon";
> 
> does not work because this node is bound to the simple-bus driver
> (drivers/core/simple-bus.c) in favor of "simple-mfd" compatible.
> The compatible string "syscon" is just dismissed.
> 
> Moreover,
> 
>compatible = "foo,bar-syscon", "syscon";
> 
> works like the first case because the syscon driver populates the
> child devices.  This is wrong because populating children is the job
> of "simple-mfd" (or "simple-bus").
> 
> This commit ports syscon_node_to_regmap() from Linux.  This API
> does not require the given node to be bound to a driver in any way.
> 
> Reported-by: Kunihiko Hayashi 
> Signed-off-by: Masahiro Yamada 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCHv2 2/3] buildman: support newer gcc versions from kernel.org

[Tom Rini]

From: Daniel Schwierzeck 

Add support for gcc versions 7.3.0, 6.4.0 and 4.9.4.

Also use a regex for matching the tarball names. Some gcc versions
use '-ARCH-' instead of '_ARCH-'.

As part of this, we switch TravisCI to also using these toolchains for
all platforms.

Signed-off-by: Daniel Schwierzeck 
Signed-off-by: Tom Rini 
---
Changes in v2:
- Change to only 7.3.0 / 6.4.0 / 4.9.4 for gcc versions.  Update
  .travis.yml for x86_64 toolchain and fetch all toolchains.
- Fold in the old patch I had to expand and update SH builds as we
  cannot build without those changes.
---
 .travis.yml | 38 ++
 tools/buildman/toolchain.py |  6 +++---
 2 files changed, 29 insertions(+), 15 deletions(-)

diff --git a/.travis.yml b/.travis.yml
index 57f38e11698b..b07ce9b8ceb4 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -21,7 +21,6 @@ addons:
 - python-virtualenv
 - swig
 - libpython-dev
-- gcc-powerpc-linux-gnu
 - iasl
 - grub-efi-ia32-bin
 - rpm2cpio
@@ -29,6 +28,11 @@ addons:
 - device-tree-compiler
 - lzop
 
+before_install:
+ - sudo add-apt-repository ppa:ubuntu-toolchain-r/test -y
+ - sudo apt-get update -q
+ - sudo apt-get install libisl15 -y
+
 install:
  # Clone uboot-test-hooks
  - git clone --depth=1 git://github.com/swarren/uboot-test-hooks.git 
/tmp/uboot-test-hooks
@@ -36,10 +40,8 @@ install:
  - ln -s travis-ci /tmp/uboot-test-hooks/py/`hostname`
  # prepare buildman environment
  - echo -e "[toolchain]\nroot = /usr" > ~/.buildman
- - echo -e "aarch64 = /tmp/gcc-linaro-6.3.1-2017.02-x86_64_aarch64-linux-gnu" 
>> ~/.buildman
- - echo -e "arm = /tmp/gcc-linaro-6.3.1-2017.02-x86_64_arm-linux-gnueabihf" >> 
~/.buildman
  - echo -e "arc = /tmp/arc_gnu_2017.09_prebuilt_uclibc_le_archs_linux_install" 
>> ~/.buildman
- - echo -e "\n[toolchain-alias]\nsh = sh4\nopenrisc = or32" >> ~/.buildman
+ - echo -e "\n[toolchain-alias]\nsh = sh2" >> ~/.buildman
  - cat ~/.buildman
  - virtualenv /tmp/venv
  - . /tmp/venv/bin/activate
@@ -64,10 +66,10 @@ before_script:
   - if [[ "${TOOLCHAIN}" == *microblaze* ]]; then ./tools/buildman/buildman 
--fetch-arch microblaze ; fi
   - if [[ "${TOOLCHAIN}" == *mips* ]]; then ./tools/buildman/buildman 
--fetch-arch mips ; fi
   - if [[ "${TOOLCHAIN}" == *or32* ]]; then ./tools/buildman/buildman 
--fetch-arch or32 ; fi
-  - if [[ "${TOOLCHAIN}" == *sh4* ]]; then ./tools/buildman/buildman 
--fetch-arch sh4 ; fi
+  - if [[ "${TOOLCHAIN}" == *sh* ]]; then ./tools/buildman/buildman 
--fetch-arch sh2 ; fi
   - if [[ "${TOOLCHAIN}" == *x86_64* ]]; then
   ./tools/buildman/buildman --fetch-arch x86_64;
-  echo -e "\n[toolchain-prefix]\nx86 = 
${HOME}/.buildman-toolchains/gcc-4.9.0-nolibc/x86_64-linux/bin/x86_64-linux-" 
>> ~/.buildman;
+  echo -e "\n[toolchain-prefix]\nx86 = 
${HOME}/.buildman-toolchains/gcc-7.3.0-nolibc/x86_64-linux/bin/x86_64-linux-" 
>> ~/.buildman;
 fi
   - if [[ "${TOOLCHAIN}" == arc ]]; then
wget 
https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/download/arc-2017.09-release/arc_gnu_2017.09_prebuilt_uclibc_le_archs_linux_install.tar.gz
 &&
@@ -80,11 +82,10 @@ before_script:
 fi
   # If TOOLCHAIN is unset, we're on some flavour of ARM.
   - if [[ "${TOOLCHAIN}" == "" ]]; then
-   wget 
http://releases.linaro.org/components/toolchain/binaries/6.3-2017.02/aarch64-linux-gnu/gcc-linaro-6.3.1-2017.02-x86_64_aarch64-linux-gnu.tar.xz
 &&
-   wget 
http://releases.linaro.org/components/toolchain/binaries/6.3-2017.02/arm-linux-gnueabihf/gcc-linaro-6.3.1-2017.02-x86_64_arm-linux-gnueabihf.tar.xz
 &&
-   tar -C /tmp -xf 
gcc-linaro-6.3.1-2017.02-x86_64_aarch64-linux-gnu.tar.xz &&
-   tar -C /tmp -xf 
gcc-linaro-6.3.1-2017.02-x86_64_arm-linux-gnueabihf.tar.xz;
+   ./tools/buildman/buildman --fetch-arch arm &&
+   ./tools/buildman/buildman --fetch-arch aarch64;
 fi
+  - if [[ "${TOOLCHAIN}" == "powerpc" ]]; then ./tools/buildman/buildman 
--fetch-arch powerpc; fi
   - if [[ "${TOOLCHAIN}" == "riscv" ]]; then
 wget 
https://github.com/PkmX/riscv-prebuilt-toolchains/releases/download/20180111/riscv32-unknown-elf-toolchain.tar.gz
 &&
 tar -C /tmp -xf riscv32-unknown-elf-toolchain.tar.gz &&
@@ -227,26 +228,37 @@ matrix:
   TOOLCHAIN="mips"
 - env:
 - BUILDMAN="mpc83xx"
+  TOOLCHAIN="powerpc"
 - env:
 - BUILDMAN="mpc85xx -x freescale"
+  TOOLCHAIN="powerpc"
 - env:
 - BUILDMAN="mpc85xx -x t208xrdb -x t4qds -x t102* -x p1_p2_rdb_pc -x 
p1010rdb -x corenet_ds -x b4860qds -x sbc8548 -x bsc91*"
+  TOOLCHAIN="powerpc"
 - env:
 - BUILDMAN="t208xrdb"
+  TOOLCHAIN="powerpc"
 - env:
 - BUILDMAN="t4qds"
+  TOOLCHAIN="powerpc"
 - env:
 - BUILDMAN="t102*"
+  TOOLCHAIN="powerpc"
 - env:
 - 

Re: [U-Boot] [U-Boot, 6/6] psci: arm: remove armv7 function psci_save_target_pc

[Tom Rini]

On Mon, Apr 16, 2018 at 10:15:12AM +0200, Patrick Delaunay wrote:

> This function is no more used, and replaced by psci_save
> which save also context id as requested by PSCI requirements.
> 
> Even if the context id is not used by Linux, it should be saved
> and restored in r0 when the CPU_ON is performed.
> 
> Signed-off-by: Patrick Delaunay 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCHv2 1/3] at91: Minor tweaks to SPL logic for space savings on smartweb

[Tom Rini]

- spl_board_init is empty on smartweb so drop that function
- When CONFIG_AT91SAM9_WATCHDOG is set we do not disable the watchdog in
  SPL and instead let full U-Boot handle it.  Instead of an empty
  function just do not call a function.

Signed-off-by: Tom Rini 
---
With gcc-7.2 smartweb is 16bytes too large.  These changes bring us just
back under.
---
 arch/arm/Kconfig   | 2 +-
 arch/arm/mach-at91/spl.c   | 4 +---
 arch/arm/mach-at91/spl_at91.c  | 2 ++
 arch/arm/mach-at91/spl_atmel.c | 2 ++
 4 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2bbb86c462dd..a5420112f39c 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -393,7 +393,7 @@ choice
 
 config ARCH_AT91
bool "Atmel AT91"
-   select SPL_BOARD_INIT if SPL
+   select SPL_BOARD_INIT if SPL && !TARGET_SMARTWEB
 
 config TARGET_EDB93XX
bool "Support edb93xx"
diff --git a/arch/arm/mach-at91/spl.c b/arch/arm/mach-at91/spl.c
index 7cba3825e7f4..8bfb2a452b5e 100644
--- a/arch/arm/mach-at91/spl.c
+++ b/arch/arm/mach-at91/spl.c
@@ -11,9 +11,7 @@
 #include 
 #include 
 
-#if defined(CONFIG_AT91SAM9_WATCHDOG)
-void at91_disable_wdt(void) { }
-#else
+#if !defined(CONFIG_AT91SAM9_WATCHDOG)
 void at91_disable_wdt(void)
 {
struct at91_wdt *wdt = (struct at91_wdt *)ATMEL_BASE_WDT;
diff --git a/arch/arm/mach-at91/spl_at91.c b/arch/arm/mach-at91/spl_at91.c
index d701c3586d38..8c368042a6b2 100644
--- a/arch/arm/mach-at91/spl_at91.c
+++ b/arch/arm/mach-at91/spl_at91.c
@@ -76,7 +76,9 @@ void __weak spl_board_init(void)
 void board_init_f(ulong dummy)
 {
lowlevel_clock_init();
+#if !defined(CONFIG_AT91SAM9_WATCHDOG)
at91_disable_wdt();
+#endif
 
/*
 * At this stage the main oscillator is supposed to be enabled
diff --git a/arch/arm/mach-at91/spl_atmel.c b/arch/arm/mach-at91/spl_atmel.c
index 11db1e5f8cff..597ff8c03673 100644
--- a/arch/arm/mach-at91/spl_atmel.c
+++ b/arch/arm/mach-at91/spl_atmel.c
@@ -98,8 +98,10 @@ void board_init_f(ulong dummy)
configure_2nd_sram_as_l2_cache();
 #endif
 
+#if !defined(CONFIG_AT91SAM9_WATCHDOG)
/* disable watchdog */
at91_disable_wdt();
+#endif
 
/* PMC configuration */
at91_pmc_init();
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCHv2 3/3] .travis.yml: Further optimizations

[Tom Rini]

- Xilinx aarch64 is caught in the general xilinx arm job, exclude from
  the general aarch64 job.
- Give the generic aarch64 job a better name
- Re-sort the PowerPC jobs so that we can complete them a bit quicker.

Signed-off-by: Tom Rini 
---
 .travis.yml | 36 +---
 1 file changed, 9 insertions(+), 27 deletions(-)

diff --git a/.travis.yml b/.travis.yml
index b07ce9b8ceb4..2326c3443c5d 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -150,17 +150,11 @@ matrix:
 - BUILDMAN="arc"
   TOOLCHAIN="arc"
 - env:
-- BUILDMAN="arm11"
-- env:
-- BUILDMAN="arm7"
-- env:
-- BUILDMAN="arm920t"
+- BUILDMAN="arm11 arm7 arm920t arm946es"
 - env:
 - JOB="arm926ejs"
   BUILDMAN="arm926ejs -x mx,siemens,atmel"
 - env:
-- BUILDMAN="arm946es"
-- env:
 - BUILDMAN="atmel"
 - env:
 - BUILDMAN="aries"
@@ -168,7 +162,6 @@ matrix:
 - JOB="Boundary Devices"
   BUILDMAN="boundary"
 - env:
-- JOB="engicam"
   BUILDMAN="engicam"
 - env:
 - JOB="Freescale ARM32"
@@ -227,19 +220,17 @@ matrix:
 - BUILDMAN="mips"
   TOOLCHAIN="mips"
 - env:
-- BUILDMAN="mpc83xx"
+- JOB="Non-Freescale PowerPC"
+  BUILDMAN="powerpc -x freescale"
   TOOLCHAIN="powerpc"
 - env:
-- BUILDMAN="mpc85xx -x freescale"
+- BUILDMAN="mpc85xx -x t208xrdb -x t4qds -x t102* -x 
p1_p2_rdb_pc -x p1010rdb -x corenet_ds -x b4860qds -x bsc91*"
   TOOLCHAIN="powerpc"
 - env:
-- BUILDMAN="mpc85xx -x t208xrdb -x t4qds -x t102* -x p1_p2_rdb_pc -x 
p1010rdb -x corenet_ds -x b4860qds -x sbc8548 -x bsc91*"
+- BUILDMAN="t208xrdb corenet_ds"
   TOOLCHAIN="powerpc"
 - env:
-- BUILDMAN="t208xrdb"
-  TOOLCHAIN="powerpc"
-- env:
-- BUILDMAN="t4qds"
+- BUILDMAN="t4qds b4860qds mpc83xx mpc86xx"
   TOOLCHAIN="powerpc"
 - env:
 - BUILDMAN="t102*"
@@ -248,16 +239,7 @@ matrix:
 - BUILDMAN="p1_p2_rdb_pc"
   TOOLCHAIN="powerpc"
 - env:
-- BUILDMAN="p1010rdb"
-  TOOLCHAIN="powerpc"
-- env:
-- BUILDMAN="corenet_ds b4860qds sbc8548 bsc91*"
-  TOOLCHAIN="powerpc"
-- env:
-- BUILDMAN="mpc86xx"
-  TOOLCHAIN="powerpc"
-- env:
-- BUILDMAN="mpc8xx"
+- BUILDMAN="p1010rdb bsc91"
   TOOLCHAIN="powerpc"
 - env:
 - BUILDMAN="siemens"
@@ -276,8 +258,8 @@ matrix:
 - env:
 - BUILDMAN="uniphier"
 - env:
-- JOB="aarch64"
-  BUILDMAN="aarch64 -x 
tegra,freescale,mvebu,uniphier,sunxi,samsung,rockchip"
+- JOB="Catch-all AArch64"
+  BUILDMAN="aarch64 -x 
tegra,freescale,mvebu,uniphier,sunxi,samsung,rockchip,xilinx"
 - env:
 - BUILDMAN="rockchip"
 - env:
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, 3/6] tegra: psci: save context id in cpu_on command

[Tom Rini]

On Mon, Apr 16, 2018 at 10:15:09AM +0200, Patrick Delaunay wrote:

> Replace the psci_save_target_pc call by the new function
> psci_save(cpu, pc,context_id)
> 
> Signed-off-by: Patrick Delaunay 
> Reviewed-by: Stephen Warren 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v2, 3/4] regmap: change regmap_init_mem() to take ofnode instead udevice

[Tom Rini]

On Thu, Apr 19, 2018 at 12:14:03PM +0900, Masahiro Yamada wrote:

> Currently, regmap_init_mem() takes a udevice. This requires the node
> has already been associated with a device. It prevents syscon/regmap
> from behaving like those in Linux.
> 
> Change the first argumenet to take a device node.
> 
> Signed-off-by: Masahiro Yamada 
> Acked-by: Neil Armstrong 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v2, 7/7] arm: v7R: Add support for enabling caches

[Tom Rini]

On Thu, Apr 26, 2018 at 06:21:31PM +0530, Lokesh Vutla wrote:

> Cache maintenance procedure is same for v7A and v7R
> processors. So re-use cache-cp15.c file except for
> mmu parts.
> 
> Tested-by: Michal Simek 
> Signed-off-by: Lokesh Vutla 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] test: regmap: test Linux-compatible syscon_node_to_regmap()

[Tom Rini]

On Mon, Apr 23, 2018 at 01:26:53PM +0900, Masahiro Yamada wrote:

> Like Linux, syscon_node_to_regmap() allows a node to work as a syscon
> provider without binding it to a syscon driver.  Test this.
> 
> Requested-by: Simon Glass 
> Signed-off-by: Masahiro Yamada 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v2, 2/7] arm: v7: Kconfig: Rename CPU_V7 as CPU_V7A

[Tom Rini]

On Thu, Apr 26, 2018 at 06:21:26PM +0530, Lokesh Vutla wrote:

> Currently CPU_V7 kconfig symbol supports only ARMv7A architectures under
> armv7 folder. This led to a misconception of creating separate folders
> for armv7m and armv7r. There is no reason to create separate folder for
> other armv7 based architectures when it can co-exist with few Kconfig
> symbols.
> 
> As a first step towards a common folder, rename CPU_V7 as CPUV7A. Later
> separate Kconfig symbols can be added for CPU_V7R and CPU_V7M and
> can co exist in the same folder.
> 
> Reviewed-by: Tom Rini 
> Tested-by: Michal Simek 
> Suggested-by: Alexander Graf 
> Signed-off-by: Lokesh Vutla 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot,v2,6/7] arm: v7R: Add support for MPU

[Tom Rini]

On Thu, Apr 26, 2018 at 06:21:30PM +0530, Lokesh Vutla wrote:

> The Memory Protection Unit(MPU) allows to partition memory into regions
> and set individual protection attributes for each region. In absence
> of MPU a default map[1] will take effect. Add support for configuring
> MPU on Cortex-R, by reusing the existing support for Cortex-M processor.
> 
> [1] 
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0460d/I1002400.html
> 
> Tested-by: Michal Simek 
> Signed-off-by: Lokesh Vutla 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot,v2,1/4] regmap: clean up regmap allocation

[Tom Rini]

On Thu, Apr 19, 2018 at 12:14:01PM +0900, Masahiro Yamada wrote:

> Putting zero length array at the end of struct is a common technique
> to embed arbitrary length of members.  There is no good reason to let
> regmap_alloc_count() branch by "if (count <= 1)".
> 
> As far as I understood the code, regmap->base is an alias of
> regmap->ranges[0].start, but it is not helpful but make the code
> just ugly.
> 
> Rename regmap_alloc_count() to regmap_alloc() because the _count
> suffix seems pointless.
> 
> Signed-off-by: Masahiro Yamada 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot,v2,5/7] arm: v7R: Add initial support

[Tom Rini]

On Thu, Apr 26, 2018 at 06:21:29PM +0530, Lokesh Vutla wrote:

> From: Michal Simek 
> 
> The Cortex-R* processors are a mid-range CPUs for use in deeply-embedded,
> real-time systems. It implements the ARMv7-R architecture, and includes
> Thumb-2 technology for optimum code density and processing throughput.
> 
> Except for MPU(Memory Protection Unit) and few CP15 registers, most of the
> features are compatible with v7 architecture. So,reuse the same armv7
> folder and introduce a new config CPU_V7R in order to differentiate
> from v7 based platforms.
> 
> Tested-by: Michal Simek 
> Reviewed-by: Tom Rini 
> Signed-off-by: Michal Simek 
> Signed-off-by: Lokesh Vutla 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot,v2,3/7] arm: v7: Kconfig: Add entry for MMU

[Tom Rini]

On Thu, Apr 26, 2018 at 06:21:27PM +0530, Lokesh Vutla wrote:

> Add a Kconfig entry for MMU and imply for all platforms using
> cache-cp15.c containing MMU setup. Using imply instead of select so that
> MMU can be disabled by defconfigs when not needed.
> 
> Tested-by: Michal Simek 
> Reviewed-by: Tom Rini 
> Signed-off-by: Lokesh Vutla 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] test: ofnode: test ofnode_device_is_compatible()

[Tom Rini]

On Fri, Apr 27, 2018 at 01:02:02AM +0900, Masahiro Yamada wrote:

> Test ofnode_device_is_compatible(), and also ofnode_path().
> 
> Requested-by: Simon Glass 
> Signed-off-by: Masahiro Yamada 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v2, 2/4] dm: ofnode: add ofnode_device_is_compatible() helper

[Tom Rini]

On Thu, Apr 19, 2018 at 12:14:02PM +0900, Masahiro Yamada wrote:

> device_is_compatible() takes udevice, but there is no such a helper
> that takes ofnode.
> 
> Signed-off-by: Masahiro Yamada 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, 5/6] sunxi: psci: save context id in cpu_on command

[Tom Rini]

On Mon, Apr 16, 2018 at 10:15:11AM +0200, Patrick Delaunay wrote:

> Replace the psci_save_target_pc call by the new function
> psci_save(cpu, pc,context_id)
> 
> Signed-off-by: Patrick Delaunay 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v2, 1/7] arm: v7: Update VBAR only if available

[Tom Rini]

On Thu, Apr 26, 2018 at 06:21:25PM +0530, Lokesh Vutla wrote:

> Not all ARM V7 based cpus has VBAR for remapping
> vector base address. So, update VBAR only if it available.
> 
> Reviewed-by: Tom Rini 
> Signed-off-by: Lokesh Vutla 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] arm: armv7m: Clean up some thumb / compiler flag options

[Tom Rini]

- The correct way to build with thumb mode is to select SYS_THUMB_BUILD
- We should be setting -march=armv7-m in arch/arm/Makefile not the
  sub-config.mk file.

Signed-off-by: Tom Rini 
---
 arch/arm/Kconfig  | 1 +
 arch/arm/Makefile | 1 +
 arch/arm/cpu/armv7m/config.mk | 2 +-
 3 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2bbb86c462dd..efc9108a5a3a 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -221,6 +221,7 @@ config CPU_V7M
select THUMB2_KERNEL
select SYS_CACHE_SHIFT_5
select SYS_ARM_MPU
+   select SYS_THUMB_BUILD
 
 config CPU_V7R
bool
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 3b1dd85716de..913d23048f1f 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -16,6 +16,7 @@ arch-$(CONFIG_CPU_ARM1136)=-march=armv5
 arch-$(CONFIG_CPU_ARM1176) =-march=armv5t
 arch-$(CONFIG_CPU_V7A) =$(call cc-option, -march=armv7-a, \
 $(call cc-option, -march=armv7, -march=armv5))
+arch-$(CONFIG_CPU_V7M) =-march=armv7-m
 arch-$(CONFIG_CPU_V7R) =-march=armv7-r
 arch-$(CONFIG_ARM64)   =-march=armv8-a
 
diff --git a/arch/arm/cpu/armv7m/config.mk b/arch/arm/cpu/armv7m/config.mk
index 4e46df5a2844..f50964cfb92e 100644
--- a/arch/arm/cpu/armv7m/config.mk
+++ b/arch/arm/cpu/armv7m/config.mk
@@ -3,4 +3,4 @@
 # (C) Copyright 2015
 # Kamil Lulko, 
 
-PLATFORM_CPPFLAGS += -march=armv7-m -mthumb -mno-unaligned-access
+PLATFORM_CPPFLAGS += -mno-unaligned-access
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, 4/6] uniphier: psci: save context id in cpu_on command

[Tom Rini]

On Mon, Apr 16, 2018 at 10:15:10AM +0200, Patrick Delaunay wrote:

> Replace the psci_save_target_pc call by the new function
> psci_save(cpu, pc,context_id)
> 
> Signed-off-by: Patrick Delaunay 
> Acked-by: Masahiro Yamada 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, 2/6] imx7: psci: save context id in cpu_on command

[Tom Rini]

On Mon, Apr 16, 2018 at 10:15:08AM +0200, Patrick Delaunay wrote:

> Replace the psci_save_target_pc call by the new function
> psci_save(cpu, pc,context_id)
> 
> Signed-off-by: Patrick Delaunay 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v2, 4/7] arm: v7: Kconfig: Introduce SYS_ARM_CACHE_CP15

[Tom Rini]

On Thu, Apr 26, 2018 at 06:21:28PM +0530, Lokesh Vutla wrote:

> Certain ARM architectures like ARMv7-A, ARMv7-R has support for
> enabling caches using CP15 registers. To have a common support
> for all these architectures, introduce a Kconfig symbol
> SYS_ARM_CACHE_CP15 that selects cache-cp15.c
> 
> Tested-by: Michal Simek 
> Reviewed-by: Tom Rini 
> Signed-off-by: Lokesh Vutla 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v2, 2/3] arm: psci: add a weak function psci_arch_cpu_entry

[Tom Rini]

On Mon, Apr 16, 2018 at 10:13:23AM +0200, Patrick Delaunay wrote:

> The added function psci_arch_cpu_entry() is called
> during psci_cpu_entry() and can be used by arch to handle
> PSCI state transition from ON_PENDING to ON.
> 
> The default weak function is empty: not behavior change.
> 
> Signed-off-by: Patrick Delaunay 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, 1/6] ls102xa: psci: save context id in cpu_on command

[Tom Rini]

On Mon, Apr 16, 2018 at 10:15:07AM +0200, Patrick Delaunay wrote:

> Replace the psci_save_target_pc call by the new function
> psci_save(cpu, pc,context_id)
> 
> 
> Signed-off-by: Patrick Delaunay 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, 2/6] imx7: psci: save context id in cpu_on command

[Tom Rini]

On Mon, Apr 16, 2018 at 10:15:08AM +0200, Patrick Delaunay wrote:

> Replace the psci_save_target_pc call by the new function
> psci_save(cpu, pc,context_id)
> 
> Signed-off-by: Patrick Delaunay 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot,v2,3/3] arm: stm32mp1: add PSCI support

[Tom Rini]

On Mon, Apr 16, 2018 at 10:13:24AM +0200, Patrick Delaunay wrote:

> Add PSCI v1.0 support for Linux and manage PSCI state
> for each CPU (affinity 0 level) with all mandatory functions:
> - PSCI_VERSION
> - CPU_SUSPEND
> - CPU_OFF
> - CPU_ON
> - AFFINITY_INFO
> - SYSTEM_OFF
> - SYSTEM_RESET
> - PSCI_FEATURES
> and 1 optional to avoid Linux warning
> - MIGRATE_INFO_TYPE
> 
> Signed-off-by: Patrick Delaunay 
> Reviewed-by: CITOOLS 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v2, 1/3] arm: psci: save context id for cpu_on PSCI command

[Tom Rini]

On Mon, Apr 16, 2018 at 10:13:22AM +0200, Patrick Delaunay wrote:

> Save and use the 3rd parameter of PSCI CPU_ON request: context_id.
> 
> The context_id parameter is only meaningful to the caller.
> U-Boot PSCI preserves a copy of the value passed in this parameter.
> Following wakeup from a  powerdown state, U-BOOT PSCI places
> this value in R0 when it first enters the OS.
> 
> NB: this context id is not (yet?) used by Linux but it is mandatory
> to be PSCI compliant.
> 
> update armv7 psci functions:
> - psci_save_target_pc(): keep for backward compatibility with
>   current platform (only save PC and force context id to 0)
>   => should be removed when all platform migrate to the new API
> 
> - psci_save(): new API to use by ARMv7 platform with PSCI,
>   save pc (= entry_point_address) and context_id
> 
> Signed-off-by: Patrick Delaunay 
> Reviewed-by: Stephen Warren 
> Reviewed-by: Masahiro Yamada 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/1] board: arm: Add support for Broadcom BCM7445D0

[Tom Rini]

On Sun, May 06, 2018 at 07:09:22AM -0400, Thomas Fitzsimmons wrote:

> Add support for loading U-Boot on the Broadcom 7445D0 SoC.  This port
> assumes Broadcom's BOLT bootloader is acting as the second stage
> bootloader, and U-Boot is acting as the third stage bootloader, loaded
> as an ELF program by BOLT.
> 
> Signed-off-by: Thomas Fitzsimmons 
> Cc: Stefan Roese 
[snip]
> diff --git a/arch/arm/lib/crt0.S b/arch/arm/lib/crt0.S
> index fa81317..f1a6f35 100644
> --- a/arch/arm/lib/crt0.S
> +++ b/arch/arm/lib/crt0.S
> @@ -94,6 +94,7 @@ ENTRY(_main)
>   * 'here' but relocated.
>   */
>  
> +#if !defined(CONFIG_OF_PRIOR_STAGE)
>   ldr r0, [r9, #GD_START_ADDR_SP] /* sp = gd->start_addr_sp */
>   bic r0, r0, #7  /* 8-byte alignment for ABI compliance */
>   mov sp, r0
> @@ -108,6 +109,7 @@ ENTRY(_main)
>  #endif
>   ldr r0, [r9, #GD_RELOCADDR] /* r0 = gd->relocaddr */
>   b   relocate_code
> +#endif
>  here:
>  /*
>   * now relocate vectors

Can you explain this bit a good bit more?

> +config BCHP_BSPI_MAST_N_BOOT_CTRL
> + hex ""
> + default 0x003e3208

Doing hex "" seems wrong.  What are you doing here exactly?

> diff --git a/common/fdt_support.c b/common/fdt_support.c
> index 66a313e..f07dfe3 100644
> --- a/common/fdt_support.c
> +++ b/common/fdt_support.c
> @@ -242,11 +242,13 @@ int fdt_initrd(void *fdt, ulong initrd_start, ulong 
> initrd_end)
>   }
>   }
>  
> +#if !defined(CONFIG_BCMSTB_ACCOMMODATE_STBLINUX)
>   err = fdt_add_mem_rsv(fdt, initrd_start, initrd_end - initrd_start);
>   if (err < 0) {
>   printf("fdt_initrd: %s\n", fdt_strerror(err));
>   return err;
>   }
> +#endif

Why do we need this?

> +#ifdef DEBUG
> +static int debug_tx_rx;
> +#define D(fmt, args...) debug_cond(debug_tx_rx, fmt, ##args)
> +#else
> +#define D(fmt, args...)
> +#endif

We have dbg() etc, please use.  Thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/1] tools/file2include: create Linux style SPDX header

[Tom Rini]

On Mon, May 07, 2018 at 08:38:24PM +0200, Heinrich Schuchardt wrote:

> file2include is used to convert a binary file to a C include.
> With the patch the SPDX header is written to the first line as
> expected by scripts/checkpatch.pl.
> 
> Cf. https://www.kernel.org/doc/html/v4.16/process/license-rules.html
> 
> Signed-off-by: Heinrich Schuchardt 

Reviewed-by: Tom Rini 

And I'll drop this hunk from my follow-up patch, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] spi: kirkwood: Full dm conversion

[Chris Packham]

On Thu, May 3, 2018 at 11:21 PM Stefan Roese  wrote:

> Hi Chris,

> On 02.05.2018 23:56, Chris Packham wrote:
> > Hi All,
> > On Wed, May 2, 2018 at 10:53 PM Stefan Roese  wrote:
> >
> >> Hi Simon,
> >
> >> On 01.05.2018 12:54, Simon Guinot wrote:
> >>> On Mon, Apr 30, 2018 at 11:28:28AM +0530, Jagan Teki wrote:
>  On Fri, Apr 27, 2018 at 2:21 PM, Simon Guinot <
> > simon.gui...@sequanux.org> wrote:
> > On Thu, Apr 26, 2018 at 11:30:00AM +0530, Jagan Teki wrote:
> >> On Thu, Mar 15, 2018 at 5:03 PM, Jagan Teki <
> > ja...@amarulasolutions.com> wrote:
> >>> kirkwood now support dt along with platform data,
> >>> respective boards need to switch into dm for the same.
> >>
> >> Added all board mainatiner, using this driver on their relevant
> >> boards. So try to switch to DM_SPI(SPI_FLASH) before migration
> >> deadline expires.
> >
> > Hi Jagan,
> >
> > And what is the deadline exactly ?
> 
>  See DM_SPI/SPI_FLASH migration details from,
> > doc/driver-model/MIGRATION.txt
> >>>
> >>> Thanks for letting me know Jagan...
> >
> >> Just to be clear here. The older Marvell platforms Orion and Kirkwood
> >> completely lack DM (Driver-Model) and DT (Device-Tree) support in
> >> U-Boot. This needs to be added (similar to what I've done to the
> >> newer parts beginning with Armada XP / 38x) so that the SPI driver
> >> (and others) can be used as DM-enabled driver.
> >
> >> Please see arch/arm/mach-mvebu/ for more details here.
> >
> >> Any work on this is greatly appreciated as I fear that the support
> >> for these older SoC's might get dropped completely otherwise soon.
> >
> > I had a quick try on one of the kirkwood based boards I have. It was
pretty
> > easy to bring in the dts files from Linux and get some basic stuff
working.
> > I started with i2c since I can still boot without it, I haven't been
brave
> > enough to try spi yet.
> >
> > Hopefully I can spend a bit more time on it over the weekend.

> This sound just great. Thanks.

> > In terms of a long-term plan. I could upstream support for our board, we
> > still include it in the source we distribute as part of our GPL
compliance.
> > Since it's a older board that has been fairly stable we're not doing a
lot
> > of development on it. My motivation for retaining support for kirkwood
is
> > just in case we have some other EOL part that requires us to release a
new
> > bootloader. I could do a blind conversion of other in-tree kirkwood
boards
> > but my ability to test them would be quite limited.

> This "blind conversion" is definitely much better, than the removal.
> Others might be able to test some of the boards. I don't have any of
> those - so I can't help out here.


An update on this.

I've tested these 2 patches from Jagan on my out-of-tree Kirkwood board
with the addition of http://patchwork.ozlabs.org/patch/909973/ the chip
seems accessible. So for both

Tested-by: Chris Packham 

In terms of getting the conversion done. I'm about halfway through bringing
in the dts files from Linux. My plan is to send an initial series for
boards that don't enable CONFIG_CMD_SF that just imports the dts and
enables CONFIG_OF_CONTROL without actually enabling the DM for any
subsystem (that isn't already enabled).

Then for the boards with SF enabled I'll need to build test them with and
without Jagan's patches. So that could take a bit longer. Unfortunately in
order to maintain bisect-ability these will have have to go in before
Jagan's changes can be merged.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] spi: kirkwood: add orion-spi compatible string

[Chris Packham]

This matches the compatible string used by the Linux kernel. This will
allow u-boot to use the same device tree files.

Signed-off-by: Chris Packham 
---
This applies on top of Jagan's series
http://patchwork.ozlabs.org/project/uboot/list/?series=33927

 drivers/spi/kirkwood_spi.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/spi/kirkwood_spi.c b/drivers/spi/kirkwood_spi.c
index 036fc36b8329..6a5ab8a1cba4 100644
--- a/drivers/spi/kirkwood_spi.c
+++ b/drivers/spi/kirkwood_spi.c
@@ -226,6 +226,10 @@ static int mvebu_spi_ofdata_to_platdata(struct udevice 
*bus)
return 0;
 }
 
+static const struct mvebu_spi_dev orion_spi_dev_data = {
+   .is_errata_50mhz_ac = false,
+};
+
 static const struct mvebu_spi_dev armada_xp_spi_dev_data = {
.is_errata_50mhz_ac = false,
 };
@@ -239,6 +243,10 @@ static const struct mvebu_spi_dev armada_380_spi_dev_data 
= {
 };
 
 static const struct udevice_id mvebu_spi_ids[] = {
+   {
+   .compatible = "marvell,orion-spi",
+   .data = (ulong)_spi_dev_data
+   },
{
.compatible = "marvell,armada-375-spi",
.data = (ulong)_375_spi_dev_data
-- 
2.17.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot,V2] imx: mx7: psci: add system reset support

[Trent Piepho]

On Thu, 2018-01-04 at 17:03 +0800, Anson Huang wrote:
> Add i.MX7 PSCI system reset support, linux
> kernel now can use "reboot" command to reset
> system.


> +__secure void imx_system_reset(void)
> +{
> + writew(1 << 2, WDOG1_BASE_ADDR);
> +}

This does not work properly on our board.

Due to an erratum in iMX7d it is necessary to wire the external WDOG_B
signal to the pmic to cycle power in order to reset the board.  The
Linux IMX watchdog driver works when it does a reboot via the watchdog,
but this code does not.

When the Linux drivers is configured for an external wdog signal, using
a DT property, it sets WCR_SRS to prevent the internal system reset in
response to watchdog triggering.  When that is not done, as in this
patch, the internal reset appears to reset the wdog module or iomux or
something, which causes the imx7d to stop asserting the external wdog
signal.

In my tests, this takes only about 2.4 µs.  Such a short wdog_b pulse
does not appear to be sufficient to trigger the pmic to cycle power.

When SRS is set, then the WDOG_B signal will remain asserted until the
POR_B input signal to the imx7d is asserted.  I.e., until pmic responds
to the watchdog signal.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC PATCH v2 15/20] fastboot: Merge boot common across USB and UDP

[Jocelyn Bohr]

Optional nit: Consider renaming "fastbootcmd" to "fb_bootcmd" or similar.
IMO "fastbootcmd" is
ambiguous as there can be multiple env variable commands related to
fastboot.

On Thu, May 3, 2018 at 2:21 PM Joe Hershberger 
wrote:

> On Mon, Apr 30, 2018 at 3:32 AM, Alex Kiernan 
> wrote:
> > Merge USB and UDP boot code. The USB implementation stays the same, but
> > UDP no longer passes an fdt. We introduce a new environment variable
> > 'fastbootcmd' which if set overrides the hardcoded boot command, setting
> > this then allows the UDP implementation to remain the same. If after
> > running 'fastbootcmd' the board has not booted, control is returned
> > to U-Boot and the fastboot process ends.
> >
> > Signed-off-by: Alex Kiernan 
>
> Nit below...
>
> Acked-by: Joe Hershberger 
>

Reviewed-by: Jocelyn Bohr 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/3] efi_loader: allow unaligned memory access

[Tom Rini]

On Thu, Apr 05, 2018 at 09:39:20AM +0200, Alexander Graf wrote:
> On 04/04/2018 09:14 PM, Heinrich Schuchardt wrote:
> >On 04/04/2018 06:11 PM, Alexander Graf wrote:
> >>
> >>On 04.04.18 17:10, Heinrich Schuchardt wrote:
> >>>On 04/04/2018 02:32 PM, Alexander Graf wrote:
> 
> On 03.04.18 21:59, Heinrich Schuchardt wrote:
> >The UEFI spec mandates that unaligned memory access should be enabled if
> >supported by the CPU architecture.
> >
> >This patch adds an empty weak function unaligned_access() that can be
> >overridden by an architecture specific routine.
> >
> >Signed-off-by: Heinrich Schuchardt 
> >---
> >  cmd/bootefi.c   | 13 +
> >  include/asm-generic/unaligned.h |  3 +++
> >  2 files changed, 16 insertions(+)
> >
> >diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> >index ba258ac9f3..412e6519ba 100644
> >--- a/cmd/bootefi.c
> >+++ b/cmd/bootefi.c
> >@@ -18,6 +18,7 @@
> >  #include 
> >  #include 
> >  #include 
> >+#include 
> >  #include 
> >  DECLARE_GLOBAL_DATA_PTR;
> >@@ -89,6 +90,15 @@ out:
> > return ret;
> >  }
> >+/*
> >+ * Allow unaligned memory access.
> >+ *
> >+ * This routine is overridden by architectures providing this feature.
> >+ */
> >+void __weak allow_unaligned(void)
> >+{
> >+}
> >+
> I'd prefer to guard the body of the function with an #ifdef CONFIG_ARM
> so everyone knows why it's there. Then call straight into a function
> provided in the ARM core code:
> >>>The same visibility can be achieved with a comment.
> >>It's not as obvious. The default really should be to map memory as
> >>cached and allow for unaligned accesses.
> >>
> static void allow_unaligned(void)
> {
> /* On ARM we prohibit unaligned accesses by default, enable them here */
> #if defined(CONFIG_ARM) && !defined(CONFIG_ARM64) &&
> !defined(CONFIG_CPU_V7M)
>    mmu_enable_unaligned();
> #endif
> }
> >>>RISC-V also supports traps for unaligned access.
> >>Just because it supports them doesn't mean we should use them. AArch64
> >>also allows for unaligned access traps and I went through great length
> >>to refactor the mm code in U-Boot to ensure that we do not trap.
> >>
> >>>Using architecture specific flags outside arch/ is a mess.
> >>>We should not commit new sins but eliminate the existing deviations.
> >>>
> And then in arch/arm/lib/cache-cp15.c:
> 
> void mmu_enable_unaligned(void)
> {
>    set_cr(get_cr() & ~CR_A);
> }
> >>>For some ARM architecture versions the bit is reserved and not used for
> >>>unaligned access. No clue what this function would do in this case.
> >>Do you have pointers? Anything defined in the UEFI spec should have the bit.
> >UEFI spec 2.7:
> >2.3.5 AArch32 Platforms
> >In addition, the invoking OSs can assume that unaligned access support
> >is enabled if it is present in the processor.
> >
> >So the UEFI spec foresees processors supporting unaligned memory access
> >and others that do not support it.
> 
> I think the only corner case is Cortex-M, but that's not terribly high up on
> my priority list. And if that requires everything to be aligned, so be it.
> 
> >
> >>>That is why I used a weak function that does nothing if the CPU does not
> >>>support the flag.
> >>Any platform that uses cache-cp15 also supports the CR_A bit FWIW. So it
> >>really belongs there.>
> >>And again, I do not want to prettify a special hack for a broken
> >>architecture. People should see warts when they're there.
> >>
> >>The real fix IMHO is to enable aligned accesses always, like we do on
> >>any sane architecture.
> >>
> >Is this a typo: "enable aligned accesses"?
> >
> >Aligned access is always enabled. It is unaligned access that currently
> >is not enabled in U-Boot.
> 
> Yes, enable unaligned accesses of course :).
> 
> Albert, this is your call I think. Would you be heavily opposed to
> Heinrich's initial patch? It really is the best option IMHO:

Let me try actually saying something this time.  We had a large amount
of back and forth over "unaligned access" over the last several years.
Heinrich's is doing something we've expressly chosen not to do (and
there's pages and pages of discussion in the archives).  So the changes
here to enter an EFI application in the way it expects need to be done
for EFI as part of entering EFI.  I would almost suggest something like
a prepare_for_efi (and a matching unwind) function.

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [UNTESTED PATCH] ARM: orion5x: fix use of callee-saved registers in lowloevel_init

[Chris Packham]

On Mon, May 7, 2018 at 10:11 PM Mans Rullgard  wrote:

> The lowlevel_init function uses r4 and r6 without preserving their
> values as required by the AAPCS.  Use r0 and r2 instead as these
> are call-clobbered.

> Signed-off-by: Mans Rullgard 
> ---
>   arch/arm/mach-orion5x/lowlevel_init.S | 168 +-
>   1 file changed, 84 insertions(+), 84 deletions(-)

> diff --git a/arch/arm/mach-orion5x/lowlevel_init.S
b/arch/arm/mach-orion5x/lowlevel_init.S
> index 3f38f36ff294..a4e113601013 100644
> --- a/arch/arm/mach-orion5x/lowlevel_init.S
> +++ b/arch/arm/mach-orion5x/lowlevel_init.S
> @@ -72,67 +72,67 @@ lowlevel_init:

>   #ifdef CONFIG_SPL_BUILD

> -   /* Use 'r4 as the base for internal register accesses */
> -   ldr r4, =ORION5X_REGS_PHY_BASE
> +   /* Use 'r2 as the base for internal register accesses */
> +   ldr r2, =ORION5X_REGS_PHY_BASE

>  /* move internal registers from the default 0xD000
>   * to their intended location, defined by SoC */
>  ldr r3, =0xD000
>  add r3, r3, #0x2
> -   str r4, [r3, #0x80]
> +   str r2, [r3, #0x80]

>  /* Use R3 as the base for DRAM registers */
> -   add r3, r4, #0x01000
> +   add r3, r2, #0x01000

>  /*DDR SDRAM Initialization Control */
> -   ldr r6, =0x0001
> -   str r6, [r3, #0x480]
> +   ldr r0, =0x0001
> +   str r0, [r3, #0x480]

>  /* Use R3 as the base for PCI registers */
> -   add r3, r4, #0x31000
> +   add r3, r2, #0x31000

>  /* Disable arbiter */
> -   ldr r6, =0x0030
> -   str r6, [r3, #0xd00]
> +   ldr r0, =0x0030
> +   str r0, [r3, #0xd00]

>  /* Use R3 as the base for DRAM registers */
> -   add r3, r4, #0x01000
> +   add r3, r2, #0x01000

>  /* set all dram windows to 0 */
> -   mov r6, #0
> -   str r6, [r3, #0x504]
> -   str r6, [r3, #0x50C]
> -   str r6, [r3, #0x514]
> -   str r6, [r3, #0x51C]
> +   mov r0, #0
> +   str r0, [r3, #0x504]
> +   str r0, [r3, #0x50C]
> +   str r0, [r3, #0x514]
> +   str r0, [r3, #0x51C]

>  /* 1) Configure SDRAM  */
> -   ldr r6, =SDRAM_CONFIG
> -   str r6, [r3, #0x400]
> +   ldr r0, =SDRAM_CONFIG
> +   str r0, [r3, #0x400]

>  /* 2) Set SDRAM Control reg */
> -   ldr r6, =SDRAM_CONTROL
> -   str r6, [r3, #0x404]
> +   ldr r0, =SDRAM_CONTROL
> +   str r0, [r3, #0x404]

>  /* 3) Write SDRAM address control register */
> -   ldr r6, =SDRAM_ADDR_CTRL
> -   str r6, [r3, #0x410]
> +   ldr r0, =SDRAM_ADDR_CTRL
> +   str r0, [r3, #0x410]

>  /* 4) Write SDRAM bank 0 size register */
> -   ldr r6, =SDRAM_BANK0_SIZE
> -   str r6, [r3, #0x504]
> +   ldr r0, =SDRAM_BANK0_SIZE
> +   str r0, [r3, #0x504]
>  /* keep other banks disabled */

>  /* 5) Write SDRAM open pages control register */
> -   ldr r6, =SDRAM_OPEN_PAGE_EN
> -   str r6, [r3, #0x414]
> +   ldr r0, =SDRAM_OPEN_PAGE_EN
> +   str r0, [r3, #0x414]

>  /* 6) Write SDRAM timing Low register */
> -   ldr r6, =SDRAM_TIME_CTRL_LOW
> -   str r6, [r3, #0x408]
> +   ldr r0, =SDRAM_TIME_CTRL_LOW
> +   str r0, [r3, #0x408]

>  /* 7) Write SDRAM timing High register */
> -   ldr r6, =SDRAM_TIME_CTRL_HI
> -   str r6, [r3, #0x40C]
> +   ldr r0, =SDRAM_TIME_CTRL_HI
> +   str r0, [r3, #0x40C]

>  /* 8) Write SDRAM mode register */
>  /* The CPU must not attempt to change the SDRAM Mode register
setting */
> @@ -143,73 +143,73 @@ lowlevel_init:
>  /* and then sets SDRAM Mode register to its new value.
  */

>  /* 8.1 write 'nop' to SDRAM operation */
> -   ldr r6, =SDRAM_OP_NOP
> -   str r6, [r3, #0x418]
> +   ldr r0, =SDRAM_OP_NOP
> +   str r0, [r3, #0x418]

>  /* 8.2 poll SDRAM operation until back in 'normal' mode.  */
>   1:
> -   ldr r6, [r3, #0x418]
> -   cmp r6, #0
> +   ldr r0, [r3, #0x418]
> +   cmp r0, #0
>  bne 1b

>  /* 8.3 Now its safe to write new value to SDRAM Mode register
 */
> -   ldr r6, =SDRAM_MODE
> -   str r6, [r3, #0x41C]
> +   ldr r0, =SDRAM_MODE
> +   str r0, [r3, #0x41C]

>  /* 8.4 Set new mode */
> -   ldr r6, =SDRAM_OP_SETMODE
> -   str r6, [r3, #0x418]
> +   ldr r0, =SDRAM_OP_SETMODE
> +   str r0, [r3, #0x418]

>  /* 8.5 poll SDRAM operation until back in 'normal' mode.  */
>   2:
> -   ldr r6, [r3, #0x418]
> -   cmp r6, #0
> +   ldr r0, [r3, 

Re: [U-Boot] [RFC PATCH v2 14/20] fastboot: Avoid re-parsing cmd_string for boot/reboot

[Jocelyn Bohr]

On Thu, May 3, 2018 at 2:18 PM Joe Hershberger 
wrote:

> On Mon, Apr 30, 2018 at 3:32 AM, Alex Kiernan 
> wrote:
> > When picking up boot/reboot after we've sent our result packet, use
> > the previously parsed command rather than redoing the strcmp.
> >
> > Signed-off-by: Alex Kiernan 
>
> Acked-by: Joe Hershberger 
>

Reviewed-by: Jocelyn Bohr 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 1/3] mtd: nand: tegra: convert to driver model and live tree

[Marcel Ziswiler]

From: Marcel Ziswiler 

The Tegra NAND driver recently got broken by ongoing driver model resp.
live tree migration work:

NAND:  Could not decode nand-flash in device tree
Tegra NAND init failed
0 MiB

A patch for NAND uclass support was proposed about a year ago:
https://patchwork.ozlabs.org/patch/722282/

It was not merged and I do not see on-going work for this.

This commit just provides a driver model probe hook to retrieve further
configuration from the live device tree. As there is no NAND ulass as of
yet (ab)using UCLASS_MTD. Once UCLASS_NAND is supported, it would be
possible to migrate to it.

Signed-off-by: Marcel Ziswiler 
Reviewed-by: Simon Glass 

---

Changes in v2:
- Use UCLASS_MTD rather than MISC as suggested by Stefan.

 drivers/mtd/nand/tegra_nand.c | 98 ---
 1 file changed, 55 insertions(+), 43 deletions(-)

diff --git a/drivers/mtd/nand/tegra_nand.c b/drivers/mtd/nand/tegra_nand.c
index c03c9cb178..3802cc9e89 100644
--- a/drivers/mtd/nand/tegra_nand.c
+++ b/drivers/mtd/nand/tegra_nand.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "tegra_nand.h"
 
 DECLARE_GLOBAL_DATA_PTR;
@@ -29,6 +30,13 @@ DECLARE_GLOBAL_DATA_PTR;
 /* ECC bytes to be generated for tag data */
 #define TAG_ECC_BYTES  4
 
+static const struct udevice_id tegra_nand_dt_ids[] = {
+   {
+   .compatible = "nvidia,tegra20-nand",
+   },
+   { /* sentinel */ }
+};
+
 /* 64 byte oob block info for large page (== 2KB) device
  *
  * OOB flash layout for Tegra with Reed-Solomon 4 symbol correct ECC:
@@ -91,9 +99,11 @@ struct nand_drv {
struct fdt_nand config;
 };
 
-static struct nand_drv nand_ctrl;
-static struct mtd_info *our_mtd;
-static struct nand_chip nand_chip[CONFIG_SYS_MAX_NAND_DEVICE];
+struct tegra_nand_info {
+   struct udevice *dev;
+   struct nand_drv nand_ctrl;
+   struct nand_chip nand_chip;
+};
 
 /**
  * Wait for command completion
@@ -453,8 +463,8 @@ static void stop_command(struct nand_ctlr *reg)
  * @param *reg_val address of reg_val
  * @return 0 if ok, -1 on error
  */
-static int set_bus_width_page_size(struct fdt_nand *config,
-   u32 *reg_val)
+static int set_bus_width_page_size(struct mtd_info *our_mtd,
+  struct fdt_nand *config, u32 *reg_val)
 {
if (config->width == 8)
*reg_val = CFG_BUS_WIDTH_8BIT;
@@ -514,7 +524,7 @@ static int nand_rw_page(struct mtd_info *mtd, struct 
nand_chip *chip,
 
info = (struct nand_drv *)nand_get_controller_data(chip);
config = >config;
-   if (set_bus_width_page_size(config, _val))
+   if (set_bus_width_page_size(mtd, config, _val))
return -EINVAL;
 
/* Need to be 4-byte aligned */
@@ -722,7 +732,7 @@ static int nand_rw_oob(struct mtd_info *mtd, struct 
nand_chip *chip,
if (((int)chip->oob_poi) & 0x03)
return -EINVAL;
info = (struct nand_drv *)nand_get_controller_data(chip);
-   if (set_bus_width_page_size(>config, _val))
+   if (set_bus_width_page_size(mtd, >config, _val))
return -EINVAL;
 
stop_command(info->reg);
@@ -883,51 +893,39 @@ static void setup_timing(unsigned 
timing[FDT_NAND_TIMING_COUNT],
 /**
  * Decode NAND parameters from the device tree
  *
- * @param blob Device tree blob
- * @param node Node containing "nand-flash" compatible node
+ * @param dev  Driver model device
+ * @param config   Device tree NAND configuration
  * @return 0 if ok, -ve on error (FDT_ERR_...)
  */
-static int fdt_decode_nand(const void *blob, int node, struct fdt_nand *config)
+static int fdt_decode_nand(struct udevice *dev, struct fdt_nand *config)
 {
int err;
 
-   config->reg = (struct nand_ctlr *)fdtdec_get_addr(blob, node, "reg");
-   config->enabled = fdtdec_get_is_enabled(blob, node);
-   config->width = fdtdec_get_int(blob, node, "nvidia,nand-width", 8);
-   err = gpio_request_by_name_nodev(offset_to_ofnode(node),
-   "nvidia,wp-gpios", 0, >wp_gpio, GPIOD_IS_OUT);
+   config->reg = (struct nand_ctlr *)dev_read_addr(dev);
+   config->enabled = dev_read_enabled(dev);
+   config->width = dev_read_u32_default(dev, "nvidia,nand-width", 8);
+   err = gpio_request_by_name(dev, "nvidia,wp-gpios", 0, >wp_gpio,
+  GPIOD_IS_OUT);
if (err)
return err;
-   err = fdtdec_get_int_array(blob, node, "nvidia,timing",
-   config->timing, FDT_NAND_TIMING_COUNT);
+   err = dev_read_u32_array(dev, "nvidia,timing", config->timing,
+FDT_NAND_TIMING_COUNT);
if (err < 0)
return err;
 
-   /* Now look up the controller and decode that */
-   node = fdt_next_node(blob, node, NULL);
-   if (node < 0)
-   

[U-Boot] [PATCH v2 0/3] tegra nand mtd, ubi, driver model and live tree enablement

[Marcel Ziswiler]

This series addresses recent Tegra NAND driver breakage caused by
ongoing driver model resp. live tree migration work and enables it on
Harmony as well.

This series is available at 
http://git.toradex.com/cgit/u-boot-toradex.git/log/?h=for-next

Changes in v2:
- Use UCLASS_MTD rather than MISC as suggested by Stefan.
- Enable CONFIG_MTD as well to make sure UCLASS_MTD is available.
- New commit required due to using UCLASS_MTD.

Marcel Ziswiler (3):
  mtd: nand: tegra: convert to driver model and live tree
  configs: harmony: enable live tree, mtd and ubi
  configs: colibri_t20: enable mtd

 configs/colibri_t20_defconfig |  1 +
 configs/harmony_defconfig |  6 +++
 drivers/mtd/nand/tegra_nand.c | 98 ---
 include/configs/harmony.h |  4 ++
 4 files changed, 66 insertions(+), 43 deletions(-)

-- 
2.14.3

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 2/3] configs: harmony: enable live tree, mtd and ubi

[Marcel Ziswiler]

From: Marcel Ziswiler 

U-Boot on Harmony recently got broken by ongoing driver model resp. live
tree migration work:

U-Boot 2018.03-rc3 (Feb 21 2018 - 15:43:08 +0100)

TEGRA20
Model: NVIDIA Tegra20 Harmony evaluation board
Board: NVIDIA Harmony
DRAM:  1 GiB
Video device 'dc@5420' cannot allocate frame buffer memory -ensure
the device is set up before relocation
Error binding driver 'tegra_lcd': -28
Some drivers failed to bind
Error binding driver 'generic_simple_bus': -28
Some drivers failed to bind
initcall sequence 3ffa86d0 failed at call 00121dc0 (err=-28)

This commit fixes this by enabling live tree, MTD and UBI for Harmony as
well.

Signed-off-by: Marcel Ziswiler 

---

Changes in v2:
- Enable CONFIG_MTD as well to make sure UCLASS_MTD is available.

 configs/harmony_defconfig | 6 ++
 include/configs/harmony.h | 4 
 2 files changed, 10 insertions(+)

diff --git a/configs/harmony_defconfig b/configs/harmony_defconfig
index d716fc3546..9d4235b3a7 100644
--- a/configs/harmony_defconfig
+++ b/configs/harmony_defconfig
@@ -18,13 +18,19 @@ CONFIG_CMD_USB=y
 CONFIG_CMD_PMIC=y
 CONFIG_CMD_REGULATOR=y
 CONFIG_CMD_EXT4_WRITE=y
+CONFIG_MTDIDS_DEFAULT="nand0=tegra_nand"
+CONFIG_MTDPARTS_DEFAULT="mtdparts=tegra_nand:2m(u-boot)ro,1m(u-boot-env),1m(cfgblock)ro,-(ubi)"
+CONFIG_CMD_UBI=y
 # CONFIG_SPL_DOS_PARTITION is not set
 # CONFIG_SPL_EFI_PARTITION is not set
+CONFIG_OF_LIVE=y
 CONFIG_ENV_IS_IN_NAND=y
 CONFIG_SPL_DM=y
 CONFIG_PCI=y
 CONFIG_DM_PCI=y
 CONFIG_DM_PCI_COMPAT=y
+CONFIG_MTD=y
+CONFIG_MTD_UBI_FASTMAP=y
 CONFIG_DM_PMIC=y
 CONFIG_DM_REGULATOR=y
 CONFIG_DM_REGULATOR_FIXED=y
diff --git a/include/configs/harmony.h b/include/configs/harmony.h
index 9a0b1aff24..59fd6c4eb5 100644
--- a/include/configs/harmony.h
+++ b/include/configs/harmony.h
@@ -30,6 +30,10 @@
 #define CONFIG_TEGRA_NAND
 #define CONFIG_SYS_MAX_NAND_DEVICE 1
 
+/* Dynamic MTD partition support */
+#define CONFIG_MTD_PARTITIONS
+#define CONFIG_MTD_DEVICE  /* needed for mtdparts commands */
+
 /* Environment in NAND (which is 512M), aligned to start of last sector */
 #define CONFIG_ENV_OFFSET  (SZ_512M - SZ_128K) /* 128K sector size */
 
-- 
2.14.3

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 3/3] configs: colibri_t20: enable mtd

[Marcel Ziswiler]

From: Marcel Ziswiler 

Enable CONFIG_MTD as well to make sure UCLASS_MTD is available

Signed-off-by: Marcel Ziswiler 

---

Changes in v2:
- New commit required due to using UCLASS_MTD.

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

diff --git a/configs/colibri_t20_defconfig b/configs/colibri_t20_defconfig
index 90777e0201..e5d33ecfef 100644
--- a/configs/colibri_t20_defconfig
+++ b/configs/colibri_t20_defconfig
@@ -35,6 +35,7 @@ CONFIG_ENV_IS_IN_NAND=y
 CONFIG_SPL_DM=y
 CONFIG_DFU_MMC=y
 CONFIG_DFU_RAM=y
+CONFIG_MTD=y
 CONFIG_MTD_UBI_FASTMAP=y
 CONFIG_DM_PMIC=y
 CONFIG_DM_REGULATOR=y
-- 
2.14.3

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 0/3] drivers: Add reset ctrl to drivers

[Dinh Nguyen]

On Fri, May 4, 2018 at 5:49 AM, Ley Foon Tan  wrote:
> Add reset ctrl to dwmmc socfpga, designware Ethernet and ns16550 serial 
> drivers.
>
> A reset property is an optional feature, so only print out a warning and
> do not fail if a reset property is not present.
>
> If a reset property is discovered, then use it to deassert, thus bringing the
> IP out of reset.
>
> This is preparation to upstream Intel Stratix 10 SoC support in [1].
>
> v2 change:
> - remove 'return' in designware emac driver
> - keep reset control in socfpga_dw_mmc.c because it didn't call to common 
> dwmmc probe
>   function when in SPL.
> - add reviewed-by in ns16550 patch
>
> History:
> v1: https://patchwork.ozlabs.org/cover/905519/
>
> [1]: https://patchwork.ozlabs.org/cover/900499/
>
> Ley Foon Tan (3):
>   mmc: dwmmc: socfpga: Add reset ctrl to driver
>   serial: ns16550: Add reset ctrl to driver
>   net: designware: Add reset ctrl to driver
>
>  drivers/mmc/socfpga_dw_mmc.c |   19 +++
>  drivers/net/designware.c |   11 +++
>  drivers/serial/ns16550.c |   12 
>  3 files changed, 42 insertions(+), 0 deletions(-)

Please run get_maintainer.pl on V3. You're forgetting to include the
maintainers on these subsystems.

Dinh
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/5] ARM: arm926ejs: fix lowlevel_init call

[Chris Packham]

Hi Klaus,

On Mon, May 7, 2018 at 8:48 PM  wrote:



> > On 07.05.2018, at 10:25, Chris Packham  wrote:
> >
> > Hi Mans, Stefano,
> >
> > On Fri, Apr 27, 2018 at 9:00 PM Stefano Babic  wrote:
> >
> >> On 21/04/2018 17:11, Mans Rullgard wrote:
> >>> The code attempts to preserve the value of LR by storing it in R12/IP
> >>> across the lowevel_init() call.  However, this register is not saved
> >>> by the callee.  Use a register that guaranteed to be preserved
instead.
> >>>
> >>> Signed-off-by: Mans Rullgard 
> >>> ---
> >>> arch/arm/cpu/arm926ejs/start.S | 4 ++--
> >>> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/arch/arm/cpu/arm926ejs/start.S
> > b/arch/arm/cpu/arm926ejs/start.S
> >>> index 959d1ed86d8a..a6f0bdb70345 100644
> >>> --- a/arch/arm/cpu/arm926ejs/start.S
> >>> +++ b/arch/arm/cpu/arm926ejs/start.S
> >>> @@ -105,9 +105,9 @@ flush_dcache:
> >>>  /*
> >>>   * Go setup Memory and board specific bits prior to relocation.
> >>>   */
> >>> - mov ip, lr  /* perserve link reg across call */
> >>> + mov r4, lr  /* perserve link reg across call */
> >>>  bl  lowlevel_init   /* go setup pll,mux,memory */
> >>> - mov lr, ip  /* restore link */
> >>> + mov lr, r4  /* restore link */
> >>> #endif
> >>>  mov pc, lr  /* back to my caller */
> >>> #endif /* CONFIG_SKIP_LOWLEVEL_INIT */
> >>>
> >
> >> Applied to u-boot-imx, thanks !
> >
> > I think this might be causing me a problem on a Marvell Kirkwood board
I'm
> > working on getting into upstream. It may also be problematic for orion5x
> > boards. Both of these use r4 in lowlevel_init.
> >
> > Obviously I can fix the board that I'm working on. Is there some
> > expectation as to which registers can be clobbered?

> The "Procedure Call Standard for the ARM® Architecture” may help:

http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042f/IHI0042F_aapcs.pdf
> Page 15

> A subroutine must preserve the contents of the registers r4-r8, r10,
r11 and
> SP (and r9 in PCS variants that designate r9 as v6).

> So for thumb r1-r3 and r12 should be usable  without taking any care of
them.
> Maybe r13 depending if you already have a stack or not.

Thanks. I figured there was probably some document that described this. I
started looking at EABI docs but didn't find anything last night.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/5] ARM: arm926ejs: fix lowlevel_init call

[Chris Packham]

On Mon, May 7, 2018 at 10:11 PM Måns Rullgård  wrote:

> Chris Packham  writes:

> > Hi Mans, Stefano,
> >
> > On Fri, Apr 27, 2018 at 9:00 PM Stefano Babic  wrote:
> >
> >> On 21/04/2018 17:11, Mans Rullgard wrote:
> >> > The code attempts to preserve the value of LR by storing it in R12/IP
> >> > across the lowevel_init() call.  However, this register is not saved
> >> > by the callee.  Use a register that guaranteed to be preserved
instead.
> >> >
> >> > Signed-off-by: Mans Rullgard 
> >> > ---
> >> >  arch/arm/cpu/arm926ejs/start.S | 4 ++--
> >> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >> >
> >> > diff --git a/arch/arm/cpu/arm926ejs/start.S
> > b/arch/arm/cpu/arm926ejs/start.S
> >> > index 959d1ed86d8a..a6f0bdb70345 100644
> >> > --- a/arch/arm/cpu/arm926ejs/start.S
> >> > +++ b/arch/arm/cpu/arm926ejs/start.S
> >> > @@ -105,9 +105,9 @@ flush_dcache:
> >> >   /*
> >> >* Go setup Memory and board specific bits prior to relocation.
> >> >*/
> >> > - mov ip, lr  /* perserve link reg across call */
> >> > + mov r4, lr  /* perserve link reg across call */
> >> >   bl  lowlevel_init   /* go setup pll,mux,memory */
> >> > - mov lr, ip  /* restore link */
> >> > + mov lr, r4  /* restore link */
> >> >  #endif
> >> >   mov pc, lr  /* back to my caller */
> >> >  #endif /* CONFIG_SKIP_LOWLEVEL_INIT */
> >> >
> >
> >> Applied to u-boot-imx, thanks !
> >
> > I think this might be causing me a problem on a Marvell Kirkwood board
I'm
> > working on getting into upstream. It may also be problematic for orion5x
> > boards. Both of these use r4 in lowlevel_init.

> I've just sent an untested patch for orion5x.


Thanks for that.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] SPDX: Convert a few files that were missed before

[Tom Rini]

As part of the main conversion a few files were missed.  These files had
additional whitespace after the '*' and before the SPDX tag and my
previous regex was too strict.  This time I did a grep for all SPDX tags
and then filtered out anything that matched the correct styles.

Fixes: 83d290c56fab ("SPDX: Convert all of our single license tags to Linux 
Kernel style")
Reported-by: Heinrich Schuchardt 
Signed-off-by: Tom Rini 
---
 arch/arm/mach-rmobile/include/mach/ehci-rmobile.h   | 3 +--
 arch/arm/mach-socfpga/qts-filter.sh | 2 +-
 arch/arm/thumb1/include/asm/proc-armv/system.h  | 3 +--
 board/opalkelly/zynq/zynq-syzygy-hub/ps7_init_gpl.c | 3 +--
 board/xilinx/zynq/zynq-microzed/ps7_init_gpl.c  | 5 +
 board/xilinx/zynq/zynq-zc702/ps7_init_gpl.c | 5 +
 board/xilinx/zynq/zynq-zc706/ps7_init_gpl.c | 5 +
 board/xilinx/zynq/zynq-zed/ps7_init_gpl.c   | 5 +
 cmd/bootefi.c   | 3 +--
 doc/README.uefi | 4 ++--
 drivers/net/vsc9953.c   | 3 +--
 drivers/usb/host/ehci-rmobile.c | 3 +--
 drivers/video/bridge/Makefile   | 3 +--
 include/asm-generic/pe.h| 3 +--
 include/charset.h   | 3 +--
 include/efi_driver.h| 3 +--
 include/efi_loader.h| 3 +--
 include/efi_selftest.h  | 3 +--
 include/net.h   | 2 +-
 include/pe.h| 3 +--
 lib/charset.c   | 3 +--
 lib/efi_driver/Makefile | 4 +---
 lib/efi_driver/efi_block_device.c   | 3 +--
 lib/efi_driver/efi_uclass.c | 3 +--
 lib/efi_loader/Makefile | 3 +--
 lib/efi_loader/efi_bootmgr.c| 3 +--
 lib/efi_loader/efi_boottime.c   | 3 +--
 lib/efi_loader/efi_console.c| 3 +--
 lib/efi_loader/efi_device_path_to_text.c| 3 +--
 lib/efi_loader/efi_device_path_utilities.c  | 3 +--
 lib/efi_loader/efi_disk.c   | 3 +--
 lib/efi_loader/efi_file.c   | 3 +--
 lib/efi_loader/efi_gop.c| 3 +--
 lib/efi_loader/efi_image_loader.c   | 3 +--
 lib/efi_loader/efi_memory.c | 3 +--
 lib/efi_loader/efi_net.c| 3 +--
 lib/efi_loader/efi_runtime.c| 3 +--
 lib/efi_loader/efi_smbios.c | 3 +--
 lib/efi_loader/efi_variable.c   | 3 +--
 lib/efi_loader/efi_watchdog.c   | 3 +--
 lib/efi_selftest/Makefile   | 6 ++
 lib/efi_selftest/efi_selftest_disk_image.h  | 3 +--
 lib/lz4.c   | 3 +--
 net/arp.c   | 2 +-
 net/arp.h   | 2 +-
 net/cdp.c   | 2 +-
 net/cdp.h   | 2 +-
 net/net.c   | 2 +-
 net/ping.c  | 2 +-
 net/ping.h  | 2 +-
 test/fs/fs-test.sh  | 4 +---
 tools/file2include.c| 3 +--
 tools/ifdtool.c | 2 +-
 53 files changed, 55 insertions(+), 108 deletions(-)

diff --git a/arch/arm/mach-rmobile/include/mach/ehci-rmobile.h 
b/arch/arm/mach-rmobile/include/mach/ehci-rmobile.h
index 463654efd33e..ca8c5f370637 100644
--- a/arch/arm/mach-rmobile/include/mach/ehci-rmobile.h
+++ b/arch/arm/mach-rmobile/include/mach/ehci-rmobile.h
@@ -1,8 +1,7 @@
+/* SPDX-License-Identifier: GPL-2.0 */
 /*
  *  Copyright (C) 2013,2014 Renesas Electronics Corporation
  *  Copyright (C) 2014 Nobuhiro Iwamatsu 
- *
- *  SPDX-License-Identifier: GPL-2.0
  */
 
 #ifndef __EHCI_RMOBILE_H__
diff --git a/arch/arm/mach-socfpga/qts-filter.sh 
b/arch/arm/mach-socfpga/qts-filter.sh
index 02c28be2b772..3a442bc5d827 100755
--- a/arch/arm/mach-socfpga/qts-filter.sh
+++ b/arch/arm/mach-socfpga/qts-filter.sh
@@ -145,10 +145,10 @@ process_sdram_config() {
 
(
cat << EOF
+/* SPDX-License-Identifier: BSD-3-Clause */
 /*
  * Altera SoCFPGA SDRAM configuration
  *
- * SPDX-License-Identifier:BSD-3-Clause
  */
 
 #ifndef __SOCFPGA_SDRAM_CONFIG_H__
diff --git a/arch/arm/thumb1/include/asm/proc-armv/system.h 
b/arch/arm/thumb1/include/asm/proc-armv/system.h
index 7dfbf3d33db0..1324f7efb137 100644
--- a/arch/arm/thumb1/include/asm/proc-armv/system.h
+++ 

[U-Boot] [PATCH 1/1] tools/file2include: avoid incorrect comments

[Heinrich Schuchardt]

Avoid creating incorrect comments like /* ...*/... */ by printing
'.' instead of '*' inside comments.

Signed-off-by: Heinrich Schuchardt 
---
 tools/file2include.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/file2include.c b/tools/file2include.c
index e602f937f15..b98af30a728 100644
--- a/tools/file2include.c
+++ b/tools/file2include.c
@@ -84,7 +84,7 @@ int main(int argc, char *argv[])
printf("\\x%02x", buf[j]);
printf("\"}, /* ");
for (j = i; j < i + BLOCK_SIZE && j < count; ++j) {
-   if (buf[j] >= 0x20 && buf[j] <= 0x7e)
+   if (buf[j] != '*' && buf[j] >= 0x20 && buf[j] <= 0x7e)
printf("%c", buf[j]);
else
printf(".");
-- 
2.17.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 2/2] sunxi: binman: Add U-Boot binary size check

[Maxime Ripard]

On Wed, May 02, 2018 at 03:24:50PM +0100, Måns Rullgård wrote:
> Maxime Ripard  writes:
> 
> > 1;5201;0c
> > On Wed, May 02, 2018 at 10:34:49AM +0100, Måns Rullgård wrote:
> >> Siarhei Siamashka  writes:
> >> 
> >> > On Tue, 01 May 2018 18:25:06 +0100
> >> > Måns Rullgård  wrote:
> >> >
> >> >> Maxime Ripard  writes:
> >> >> 
> >> >> > The U-Boot binary may trip over its actual allocated size in the 
> >> >> > storage.
> >> >> > In such a case, the environment will not be readable anymore (because
> >> >> > corrupted when the new image was flashed), and any attempt at using 
> >> >> > saveenv
> >> >> > to reconstruct the environment will result in a corrupted U-Boot 
> >> >> > binary.
> >> >> >
> >> >> > Reviewed-by: Andre Przywara 
> >> >> > Signed-off-by: Maxime Ripard 
> >> >> > ---
> >> >> >  arch/arm/dts/sunxi-u-boot.dtsi | 12 
> >> >> >  1 file changed, 12 insertions(+)
> >> >> >
> >> >> > diff --git a/arch/arm/dts/sunxi-u-boot.dtsi 
> >> >> > b/arch/arm/dts/sunxi-u-boot.dtsi
> >> >> > index 5adfd9bca2ec..72e95afd780e 100644
> >> >> > --- a/arch/arm/dts/sunxi-u-boot.dtsi
> >> >> > +++ b/arch/arm/dts/sunxi-u-boot.dtsi
> >> >> > @@ -1,5 +1,14 @@
> >> >> >  #include 
> >> >> >
> >> >> > +/*
> >> >> > + * This is the maximum size the U-Boot binary can be, which is 
> >> >> > basically
> >> >> > + * the start of the environment, minus the start of the U-Boot 
> >> >> > binary in
> >> >> > + * the MMC. This makes the assumption that the MMC is using 512-bytes
> >> >> > + * blocks, but devices using something other than that remains to be
> >> >> > + * seen.
> >> >> > + */
> >> >> > +#define UBOOT_MMC_MAX_SIZE   (CONFIG_ENV_OFFSET - 
> >> >> > (CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR * 512))
> >> >> > +
> >> >> >  / {
> >> >> >   binman {
> >> >> >   filename = "u-boot-sunxi-with-spl.bin";
> >> >> > @@ -8,6 +17,9 @@
> >> >> >   filename = "spl/sunxi-spl.bin";
> >> >> >   };
> >> >> >   u-boot-img {
> >> >> > +#ifdef CONFIG_MMC
> >> >> > + size = ;
> >> >> > +#endif
> >> >> >   pos = ;
> >> >> >   };
> >> >> >   };
> >> >> > --   
> >> >> 
> >> >> This is broken in (at least) two ways:
> >> >> 
> >> >> 1. It is simply nonsensical if u-boot and env are on different devices
> >> >>or not on mmc even if mmc support is enabled.
> >> >> 
> >> >> 2. It causes u-boot-sunxi-with-spl.bin to be padded to the env offset.
> >> >>At best, this is useless.  If the env doesn't immediately follow
> >> >>u-boot, it really breaks things.
> >> >> 
> >> >> Please fix or revert, I don't really care which.
> >> >
> >> > The padding is not useless. It reserves space for future size expansions
> >> > and makes it harder for the users to hurt themselves.
> >> >
> >> > For example, if the padded U-Boot size is 1024K while the actual size
> >> > is only ~800K, then adventurous users might be tempted to fit some of
> >> > their data into this gap. Yay, ~200K of storage space for free! Except
> >> > that the next U-Boot release may grow up to 900K without any warning
> >> > and if the users are not careful enough, then their data would be
> >> > corrupted during upgrade.
> >> 
> >> Do U-Boot users really need that level of hand-holding?
> >
> > Yes, and that's never a good argument to make, because...
> >
> >> > Could you please tell us what is your problem and why reverting this
> >> > patch would fix it?
> >> 
> >> See above.  Best case, it just wastes space in the created file.  If the
> >> configuration is anything other than U-Boot immediately followed by env
> >> on the same device, it _will_ break things horribly.  A few examples:
> >> 
> >> 1.  U-Boot and env are on different devices, e.g. U-Boot on mmc and env
> >> in SPI NOR flash.  In this case, padding the file to the env offset
> >> makes no sense.  Writing the image will corrupt anything stored
> >> after U-Boot at a smaller (but still safe) offset.
> >
> > .. I could make pretty much the same one for all your cases, which
> > would be completely useless, and wouldn't fix anything.
> 
> Huh?  I'm saying we shouldn't "helpfully" do things that actually break
> perfectly valid setups.  U-Boot users are expected to know what they are
> doing, and shouldn't need that kind of help.  In my opinion.

My point is that this is a slippery slope. Anyway..

> > I guess this one could be solved using an ifdef guard with
> > ENV_IS_IN_MMC.
> 
> Not if env is on a different mmc device.

Ah, right...

> >> 2.  U-Boot at a non-zero offset, followed by env, but _not_ on mmc.  If
> >> CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR, probably at its default
> >> value, is smaller than the offset of U-Boot in its actual device,
> >> the padding will be too large.  Writing the 

[U-Boot] [PATCH v2 1/1] include: update log2 header from the Linux kernel

[Heinrich Schuchardt]

Without the patch gcc 8 produces:
warning: ignoring attribute ‘noreturn’ because it conflicts with
attribute ‘const’ [-Wattributes]
 int ilog2_NaN(void);

So let's update the include from Linux kernel v4.16.

This removes static checks of ilog2() arguments.

Signed-off-by: Heinrich Schuchardt 
---
v2
rebased
---
 include/linux/log2.h | 63 ++--
 1 file changed, 37 insertions(+), 26 deletions(-)

diff --git a/include/linux/log2.h b/include/linux/log2.h
index 4ded5ee68a9..d4e32ecfc64 100644
--- a/include/linux/log2.h
+++ b/include/linux/log2.h
@@ -3,6 +3,11 @@
  *
  * Copyright (C) 2006 Red Hat, Inc. All Rights Reserved.
  * Written by David Howells (dhowe...@redhat.com)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
  */
 
 #ifndef _LINUX_LOG2_H
@@ -11,12 +16,6 @@
 #include 
 #include 
 
-/*
- * deal with unrepresentable constant logarithms
- */
-extern __attribute__((const, noreturn))
-int ilog2_NaN(void);
-
 /*
  * non-constant log of base 2 calculators
  * - the arch may override these in asm/bitops.h if they can be implemented
@@ -39,19 +38,23 @@ int __ilog2_u64(u64 n)
 }
 #endif
 
-/*
- *  Determine whether some value is a power of two, where zero is
+/**
+ * is_power_of_2() - check if a value is a power of two
+ * @n: the value to check
+ *
+ * Determine whether some value is a power of two, where zero is
  * *not* considered a power of two.
+ * Return: true if @n is a power of 2, otherwise false.
  */
-
 static inline __attribute__((const))
 bool is_power_of_2(unsigned long n)
 {
return (n != 0 && ((n & (n - 1)) == 0));
 }
 
-/*
- * round up to nearest power of two
+/**
+ * __roundup_pow_of_two() - round up to nearest power of two
+ * @n: value to round up
  */
 static inline __attribute__((const))
 unsigned long __roundup_pow_of_two(unsigned long n)
@@ -59,8 +62,9 @@ unsigned long __roundup_pow_of_two(unsigned long n)
return 1UL << fls_long(n - 1);
 }
 
-/*
- * round down to nearest power of two
+/**
+ * __rounddown_pow_of_two() - round down to nearest power of two
+ * @n: value to round down
  */
 static inline __attribute__((const))
 unsigned long __rounddown_pow_of_two(unsigned long n)
@@ -69,19 +73,19 @@ unsigned long __rounddown_pow_of_two(unsigned long n)
 }
 
 /**
- * ilog2 - log of base 2 of 32-bit or a 64-bit unsigned value
- * @n - parameter
+ * ilog2 - log base 2 of 32-bit or a 64-bit unsigned value
+ * @n: parameter
  *
  * constant-capable log of base 2 calculation
  * - this can be used to initialise global variables from constant data, hence
- *   the massive ternary operator construction
+ * the massive ternary operator construction
  *
  * selects the appropriately-sized optimised version depending on sizeof(n)
  */
 #define ilog2(n)   \
 (  \
__builtin_constant_p(n) ? ( \
-   (n) < 1 ? ilog2_NaN() : \
+   (n) < 2 ? 0 :   \
(n) & (1ULL << 63) ? 63 :   \
(n) & (1ULL << 62) ? 62 :   \
(n) & (1ULL << 61) ? 61 :   \
@@ -144,10 +148,7 @@ unsigned long __rounddown_pow_of_two(unsigned long n)
(n) & (1ULL <<  4) ?  4 :   \
(n) & (1ULL <<  3) ?  3 :   \
(n) & (1ULL <<  2) ?  2 :   \
-   (n) & (1ULL <<  1) ?  1 :   \
-   (n) & (1ULL <<  0) ?  0 :   \
-   ilog2_NaN() \
-  ) :  \
+   1) :\
(sizeof(n) <= 4) ?  \
__ilog2_u32(n) :\
__ilog2_u64(n)  \
@@ -155,7 +156,7 @@ unsigned long __rounddown_pow_of_two(unsigned long n)
 
 /**
  * roundup_pow_of_two - round the given value up to nearest power of two
- * @n - parameter
+ * @n: parameter
  *
  * round the given value up to the nearest power of two
  * - the result is undefined when n == 0
@@ -172,7 +173,7 @@ unsigned long __rounddown_pow_of_two(unsigned long n)
 
 /**
  * rounddown_pow_of_two - round the given value down to nearest power of two
- * @n - parameter
+ * @n: parameter
  *
  * round the given value down to the nearest power of two
  * - the result is undefined when n == 0
@@ -185,6 +186,12 @@ unsigned long __rounddown_pow_of_two(unsigned long n)
__rounddown_pow_of_two(n)   \
  )
 
+static inline __attribute_const__
+int __order_base_2(unsigned long n)
+{
+   return n > 1 ? ilog2(n - 1) + 1 : 0;
+}
+
 /**
  * order_base_2 - calculate the (rounded up) base 2 order of the argument
  * @n: parameter
@@ -198,7 +205,11 @@ unsigned 

Re: [U-Boot] [PATCH v7 06/35] musb: sunxi: Add OTG device clkgate and reset for H3/H5

[Maxime Ripard]

On Mon, May 07, 2018 at 05:32:34PM +0200, Marek Vasut wrote:
> On 05/07/2018 04:52 PM, Maxime Ripard wrote:
> > On Mon, May 07, 2018 at 01:47:43PM +0200, Marek Vasut wrote:
> >> On 05/07/2018 09:33 AM, Jagan Teki wrote:
> >>> Add OTG device clkgate and reset for H3/H5 through driver_data.
> >>>
> >>> Signed-off-by: Jagan Teki 
> >>
> >> Why don't you implement a clock driver for this SoC instead ?
> > 
> > Aren't you asking a bit too much?
> 
> I am not asking for anything, this is a question, not a request.

My bad then, this definitely sounded like a request to me.

> I asked why not implement a clock driver and use it just like any other
> civilized modern driver would instead of digging in the clock controller
> registers from a USB framework driver (which is icky).

From an absolute point of view, I agree. But we are where we are.

> I think that if we are doing some sort of conversion, we should do it
> completely and properly instead of leaving in hacks like this. A clock
> driver which allows enabling/disabling clock is probably like what, 2
> hour work ? So maybe it's worth investing that time up front to save
> maintenance burden in the future.

This is definitely not a 2 hours job. More like 2 weeks if you want to
do it properly, and by which I mean creating the clock driver,
converting all the users to it, and then making sure you don't have
any regressions.

This is on our radar, but this won't happen overnight.

> > Since the first post of these patches, you've asked to rework in a
> > significant manner the driver already, including doing a new PHY
> > driver to use the device model, and making other substantial changes
> > to it.
> 
> Well yes, because it was crap at the beginning and I don't want to see
> the crap accumulating. It has become much better since, as you can see I
> only had a few minor comments.

And that's totally your role, but at the same time, the point of this
series is not to fix the whole world, but rather add support for one
particular SoC that is using pretty much the same design than any of
our other SoCs' USB phy before. And here we are, 35 patches and
counting.

> > Jagan complied to all your requests so far, but this one is going to
> > create yet another ton of patches on top of an (already) 35 patches
> > series. And this request comes out of nowhere at the 7th version.
> 
> I disagree, one clock driver patch and a tweak to the series, unless I
> missed something obvious.

This won't be one clock driver patch. Seriously.

> > Creating a new clock driver will take a lot of effort, and this really
> > surprise me given that we've had strictly no feedback from you on this
> > considering all the previous SoCs bringups we've done so far.
> 
> What do you mean by "this" ? I think i did review the previous
> iterations of this series ? If not, was I on CC ?

You did, and thanks a lot for that. The only thing I'm noting is that
it's the first time you're being so picky about a series. I appreciate
that you have to draw the line somewhere, and when things you want in
your subsystem aren't moving as fast as you'd like them to be you have
to enforce new rules. But if you were unhappy about something, you
never told us, which doesn't seem like a good path forward
either. Even in your previous reviews of that particular series.

> I have to admit, I don't really care about the rest of the Allwinner SoC
> code or what you do there, I only care about the USB part and this
> poking of clock controller registers seems wrong in a DM/DT driver.

And I do agree on that. But we also have some history to carry.

> I also don't mind if the clock driver comes later, but I would like to
> see it happen at some point (soon) to remove this register poking.

Awesome then :)

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] No support for "standalone" applications in FIT image?

[Brett Stahlman]

I've built a standalone application that uses exported u-boot functions. It
worked fine when I was loading the binary with "go", but when I attempted
to package the binary in a FIT image, to be loaded with bootm, I ran into
trouble...

Specifically, although the header seems to be parsed correctly, u-boot
eventually fails (in bootm_find_os) with the following message:

ERROR: can't get kernel image!

I'm packaging with the following mkimage parameters:

type = standalone
os = u-boot
arch = arm64

The problem appears to arise in fit_image_load, which doesn't consider
"standalone" a valid type for a FIT image. I was able to get my standalone
app to load properly by changing type from "standalone" to "firmware". But
why is this necessary? "Standalone" seems a more appropriate choice than
"firmware" for an application built using u-boot's standalone template. Is
there a reason I shouldn't be attempting to package a u-boot standalone app
in a FIT image?

Note: The reason I decided to switch from flat binary image to FIT image is
that I'm loading from flash memory (not a file system); thus, I wanted to
add a header that encoded the size of the binary so I'd know how much to
copy from flash to RAM. I've since discovered that the u-boot shell doesn't
provide any utilities for extracting size from a FIT header in flash, so if
I want to copy only the bytes in the image, I'd need to read the size from
a hard-coded offset in the FIT header, which seems a bit ugly...
Bottom line: Perhaps there's no reason to prefer bootm/FIT over go/binary
after all... But I'd still like to understand why packaging as type =
"standalone" doesn't work. I can't imagine mkimage would support the
standalone type if there were never a reason to use it...

Thanks,
Brett S.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/1] xyz-modem: va_start() must be matched by va_end()

[Heinrich Schuchardt]

Every va_start() call must be matched by a va_end() call.

scripts/checkpatch.pl required reformatting the complete function
zm_dprintf().

Signed-off-by: Heinrich Schuchardt 
---
 common/xyzModem.c | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/common/xyzModem.c b/common/xyzModem.c
index a126e32ed35..2b18a6e9f50 100644
--- a/common/xyzModem.c
+++ b/common/xyzModem.c
@@ -180,15 +180,16 @@ static char *zm_out = zm_debug_buf;
 static char *zm_out_start = zm_debug_buf;
 
 static int
-zm_dprintf (char *fmt, ...)
+zm_dprintf(char *fmt, ...)
 {
-  int len;
-  va_list args;
-
-  va_start (args, fmt);
-  len = diag_vsprintf (zm_out, fmt, args);
-  zm_out += len;
-  return len;
+   int len;
+   va_list args;
+
+   va_start(args, fmt);
+   len = diag_vsprintf(zm_out, fmt, args);
+   va_end(args);
+   zm_out += len;
+   return len;
 }
 
 static void
-- 
2.17.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 0/2] SPDX: Convert tags to Linux Kernel style

[Tom Rini]

On Mon, May 07, 2018 at 08:04:58PM +0200, Heinrich Schuchardt wrote:
> On 05/07/2018 04:07 PM, Tom Rini wrote:
> > As per the emails I had sent before on this subject, I've converted our
> > SPDX tags to Linux Kernel style.  What this means, to quote from the
> > kernel's Documentation/process/license-rules.rst file is:
> > 2. Style:
> > 
> >The SPDX license identifier is added in form of a comment.  The comment
> >style depends on the file type::
> > 
> >   C source: // SPDX-License-Identifier: 
> >   C header: /* SPDX-License-Identifier:  */
> >   ASM:  /* SPDX-License-Identifier:  */
> >   scripts:  # SPDX-License-Identifier: 
> >   .rst: .. SPDX-License-Identifier: 
> >   .dts{i}:  // SPDX-License-Identifier: 
> > 
> > Where, yes, the C source comments are not our usual style.  But I believe
> > that cross-project consistency is important and will further help us when
> > we fixup some of our from Linux but un-tagged-currently files.  I'm posting
> > these patches currently for posterity as I will be pushing them both
> > shortly (they have build tested the world successfully).  I'm also not
> > going to approve 1/2 to the ML as it's huge and I frankly expect Google to
> > tell me I can't send it.  The commit log is:
> > 
> > commit 83d290c56fab2d38cd1ab4c4cc7099559c1d5046
> > Author: Tom Rini 
> > Date:   Sun May 6 17:58:06 2018 -0400
> > 
> > SPDX: Convert all of our single license tags to Linux Kernel style
> > 
> > When U-Boot started using SPDX tags we were among the early adopters and
> > there weren't a lot of other examples to borrow from.  So we picked the
> > area of the file that usually had a full license text and replaced it
> > with an appropriate SPDX-License-Identifier: entry.  Since then, the
> > Linux Kernel has adopted SPDX tags and they place it as the very first
> > line in a file (except where shebangs are used, then it's second line)
> > and with slightly different comment styles than us.
> > 
> > In part due to community overlap, in part due to better tag visibility
> > and in part for other minor reasons, switch over to that style.
> > 
> > This commit changes all instances where we have a single declared
> > license in the tag as both the before and after are identical in tag
> > contents.  There's also a few places where I found we did not have a tag
> > and have introduced one.
> > 
> > Signed-off-by: Tom Rini 
> > 
> > And I think the above summarizes things well.  I am posting 2/2 for
> > posterity as it contains no functional changes but to repeat what the
> > commit log says, we go from "LICENSE-A LICENSE-B" to "LICENSE-A OR
> > LICENSE-B" which allows for useful expressions to be made.
> > 
> 
> Hello Tom,
> 
> thanks for picking up this tedious task.
> 
> Unfortunately you missed some files, e.g.
> 
> include/efi_driver.h:6: *  SPDX-License-Identifier: GPL-2.0+

A-yup, I didn't grep on ' *[[:blank:]]+SPDX-..' just a single space.
I'll do a fixup shortly and post that.  Consider it an after the fact
additional reason to use the format that checkpatch.pl will catch (And
that I run before every push).  Thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/1] tools/file2include: create Linux style SPDX header

[Fabio Estevam]

On Mon, May 7, 2018 at 3:38 PM, Heinrich Schuchardt  wrote:
> file2include is used to convert a binary file to a C include.
> With the patch the SPDX header is written to the first line as
> expected by scripts/checkpatch.pl.
>
> Cf. https://www.kernel.org/doc/html/v4.16/process/license-rules.html
>
> Signed-off-by: Heinrich Schuchardt 

Reviewed-by: Fabio Estevam 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/1] tools/file2include: create Linux style SPDX header

[Heinrich Schuchardt]

file2include is used to convert a binary file to a C include.
With the patch the SPDX header is written to the first line as
expected by scripts/checkpatch.pl.

Cf. https://www.kernel.org/doc/html/v4.16/process/license-rules.html

Signed-off-by: Heinrich Schuchardt 
---
 tools/file2include.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/tools/file2include.c b/tools/file2include.c
index 7ca45c8339a..e602f937f15 100644
--- a/tools/file2include.c
+++ b/tools/file2include.c
@@ -62,12 +62,11 @@ int main(int argc, char *argv[])
count = fread(buf, 1, count, file);
 
/* Generate output */
+   printf("/* SPDX-License-Identifier: GPL-2.0+ */\n");
printf("/*\n");
printf(" *  Non-zero %u byte strings of a disk image\n", BLOCK_SIZE);
printf(" *\n");
printf(" *  Generated with tools/file2include\n");
-   printf(" *\n");
-   printf(" *  SPDX-License-Identifier:GPL-2.0+\n");
printf(" */\n\n");
printf("#define EFI_ST_DISK_IMG { 0x%08zx, { \\\n", count);
 
-- 
2.17.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC] Migrate to Linux Kernel style SPDX Tags for v2018.05

[Fabio Estevam]

On Mon, May 7, 2018 at 3:19 PM, Marek Vasut  wrote:

> // SPDX foo
> /*
>  * bar
>  */
>
> Sort of stuff in the files.

Yes, it seems that the preferred style is to move everything to //
style in the initial comments:

// SPDX foo
//
// bar
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC] Migrate to Linux Kernel style SPDX Tags for v2018.05

[Marek Vasut]

On 05/07/2018 06:47 PM, Fabio Estevam wrote:
> On Mon, May 7, 2018 at 8:53 AM, Marek Vasut  wrote:
> 
>> And also the same inconsistent coding style then ?
> 
> Not sure what inconsistent coding style you are talking about.

// SPDX foo
/*
 * bar
 */

Sort of stuff in the files.

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 0/2] SPDX: Convert tags to Linux Kernel style

[Heinrich Schuchardt]

On 05/07/2018 04:07 PM, Tom Rini wrote:
> As per the emails I had sent before on this subject, I've converted our
> SPDX tags to Linux Kernel style.  What this means, to quote from the
> kernel's Documentation/process/license-rules.rst file is:
> 2. Style:
> 
>The SPDX license identifier is added in form of a comment.  The comment
>style depends on the file type::
> 
>   C source:   // SPDX-License-Identifier: 
>   C header:   /* SPDX-License-Identifier:  */
>   ASM:/* SPDX-License-Identifier:  */
>   scripts:# SPDX-License-Identifier: 
>   .rst:   .. SPDX-License-Identifier: 
>   .dts{i}:// SPDX-License-Identifier: 
> 
> Where, yes, the C source comments are not our usual style.  But I believe
> that cross-project consistency is important and will further help us when
> we fixup some of our from Linux but un-tagged-currently files.  I'm posting
> these patches currently for posterity as I will be pushing them both
> shortly (they have build tested the world successfully).  I'm also not
> going to approve 1/2 to the ML as it's huge and I frankly expect Google to
> tell me I can't send it.  The commit log is:
> 
> commit 83d290c56fab2d38cd1ab4c4cc7099559c1d5046
> Author: Tom Rini 
> Date:   Sun May 6 17:58:06 2018 -0400
> 
> SPDX: Convert all of our single license tags to Linux Kernel style
> 
> When U-Boot started using SPDX tags we were among the early adopters and
> there weren't a lot of other examples to borrow from.  So we picked the
> area of the file that usually had a full license text and replaced it
> with an appropriate SPDX-License-Identifier: entry.  Since then, the
> Linux Kernel has adopted SPDX tags and they place it as the very first
> line in a file (except where shebangs are used, then it's second line)
> and with slightly different comment styles than us.
> 
> In part due to community overlap, in part due to better tag visibility
> and in part for other minor reasons, switch over to that style.
> 
> This commit changes all instances where we have a single declared
> license in the tag as both the before and after are identical in tag
> contents.  There's also a few places where I found we did not have a tag
> and have introduced one.
> 
> Signed-off-by: Tom Rini 
> 
> And I think the above summarizes things well.  I am posting 2/2 for
> posterity as it contains no functional changes but to repeat what the
> commit log says, we go from "LICENSE-A LICENSE-B" to "LICENSE-A OR
> LICENSE-B" which allows for useful expressions to be made.
> 

Hello Tom,

thanks for picking up this tedious task.

Unfortunately you missed some files, e.g.

include/efi_driver.h:6: *  SPDX-License-Identifier: GPL-2.0+
include/efi_loader.h:6: *  SPDX-License-Identifier: GPL-2.0+
include/asm-generic/pe.h:9: *  SPDX-License-Identifier: GPL-2.0+
include/pe.h:8: *  SPDX-License-Identifier: GPL-2.0+
include/charset.h:6: *  SPDX-License-Identifier: GPL-2.0+
include/efi_selftest.h:6: *  SPDX-License-Identifier: GPL-2.0+
lib/efi_driver/efi_uclass.c:6: *  SPDX-License-Identifier: GPL-2.0+
lib/efi_driver/efi_block_device.c:6: *  SPDX-License-Identifier:
GPL-2.0+
lib/efi_selftest/efi_miniapp_file_image_return.h:6: *
SPDX-License-Identifier: GPL-2.0+
lib/efi_selftest/efi_selftest_disk_image.h:6: *
SPDX-License-Identifier:   GPL-2.0+
lib/efi_selftest/efi_miniapp_file_image_exit.h:6: *
SPDX-License-Identifier:   GPL-2.0+
lib/charset.c:6: *  SPDX-License-Identifier: GPL-2.0+
lib/efi_loader/efi_device_path_utilities.c:6: *
SPDX-License-Identifier: GPL-2.0+
lib/efi_loader/efi_image_loader.c:8: *  SPDX-License-Identifier:
GPL-2.0+
lib/efi_loader/efi_variable.c:6: *  SPDX-License-Identifier: GPL-2.0+
lib/efi_loader/efi_bootmgr.c:6: *  SPDX-License-Identifier: GPL-2.0+
lib/efi_loader/efi_net.c:6: *  SPDX-License-Identifier: GPL-2.0+
lib/efi_loader/efi_gop.c:6: *  SPDX-License-Identifier: GPL-2.0+
lib/efi_loader/efi_smbios.c:6: *  SPDX-License-Identifier: GPL-2.0+
lib/efi_loader/efi_console.c:6: *  SPDX-License-Identifier: GPL-2.0+
lib/efi_loader/efi_disk.c:6: *  SPDX-License-Identifier: GPL-2.0+
lib/efi_loader/efi_watchdog.c:6: *  SPDX-License-Identifier: GPL-2.0+
lib/efi_loader/efi_memory.c:6: *  SPDX-License-Identifier: GPL-2.0+
lib/efi_loader/efi_boottime.c:6: *  SPDX-License-Identifier: GPL-2.0+
lib/efi_loader/efi_file.c:6: *  SPDX-License-Identifier: GPL-2.0+
lib/efi_loader/efi_runtime.c:6: *  SPDX-License-Identifier: GPL-2.0+
lib/efi_loader/efi_device_path_to_text.c:6: *  SPDX-License-Identifier:
   GPL-2.0+
arch/arm/mach-rmobile/include/mach/ehci-rmobile.h:5: *
SPDX-License-Identifier: GPL-2.0
arch/arm/thumb1/include/asm/proc-armv/system.h:11: *
SPDX-License-Identifier:  GPL-2.0+
cmd/bootefi.c:6: *  SPDX-License-Identifier: GPL-2.0+
drivers/net/vsc9953.c:4: * 

Re: [U-Boot] [RFC] Migrate to Linux Kernel style SPDX Tags for v2018.05

[Fabio Estevam]

On Mon, May 7, 2018 at 8:53 AM, Marek Vasut  wrote:

> And also the same inconsistent coding style then ?

Not sure what inconsistent coding style you are talking about.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [ANN] U-Boot v2018.05 released

[Tom Rini]

Hey all,

It's release day, and here we are doing the release.  It's live on git
and FTP and ACD (along with the PGP sig file).

A few things I want to call out here.  First, a bunch more NXP PowerPC
boards have just been marked as Orphaned due to lack of valid maintainer
email.  So the one year until removal clock has started for them.  This
also marks the point where another batch of boards will hit the 1 year
mark with the _next_ release and I'm inclined to say that what that
means is that _this_ is the final release they will be in.

Second, logo!  We've never officially had a logo and I've made some
half-hearted attempts over the years to find someone to do one.  Thanks
to Alexander Graf and now Heinrich Schuchardt we have one in-progress
and at:
https://www.xypron.de/projects/u-boot/images/Circle-icons-submarine-orange-teal.svg

Please provide any serious feedback on this, preferably in the current
thread titled "Logo for U-Boot".  I'd like to grab the new logo and use
it for both conference things and for a default framebuffer logo
(tools/logo/) for v2018.07-rc1.

Finally, SPDX tags.  Now that the Linux Kernel is using them and has
all of documentation, tooling and user expectations around it, we have
switched over to that style formatting for tags.  All existing files
have been converted and for new files checkpatch has already been
warning about them if they're in the wrong format.  The only outstanding
thing now is to adapt the kernel document about where/how/why to U-Boot,
and since that is not a direct drop-in I didn't include it in this
release but will instead be posting a patch in the next day or two to
update our Licenses/README to reflect both style and include the longer
reasoning, explanation, etc.

Thanks all!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] SPDX: Convert all of our single license tags to Linux Kernel style

[Tom Rini]

On Mon, May 07, 2018 at 10:07:24AM -0400, Tom Rini wrote:

> When U-Boot started using SPDX tags we were among the early adopters and
> there weren't a lot of other examples to borrow from.  So we picked the
> area of the file that usually had a full license text and replaced it
> with an appropriate SPDX-License-Identifier: entry.  Since then, the
> Linux Kernel has adopted SPDX tags and they place it as the very first
> line in a file (except where shebangs are used, then it's second line)
> and with slightly different comment styles than us.
> 
> In part due to community overlap, in part due to better tag visibility
> and in part for other minor reasons, switch over to that style.
> 
> This commit changes all instances where we have a single declared
> license in the tag as both the before and after are identical in tag
> contents.  There's also a few places where I found we did not have a tag
> and have introduced one.
> 
> Signed-off-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] SPDX: Convert all of our multiple license tags to Linux Kernel style

[Tom Rini]

On Mon, May 07, 2018 at 10:07:25AM -0400, Tom Rini wrote:

> When U-Boot started using SPDX tags we were among the early adopters and
> there weren't a lot of other examples to borrow from.  So we picked the
> area of the file that usually had a full license text and replaced it
> with an appropriate SPDX-License-Identifier: entry.  Since then, the
> Linux Kernel has adopted SPDX tags and they place it as the very first
> line in a file (except where shebangs are used, then it's second line)
> and with slightly different comment styles than us.
> 
> In part due to community overlap, in part due to better tag visibility
> and in part for other minor reasons, switch over to that style.
> 
> This commit changes all instances where we have multiple licenses (in
> these cases, dual license) declared in the SPDX-License-Identifier tag.
> In this case we change from listing "LICENSE-A LICENSE-B" or "LICENSE-A
> or LICENSE-B" or "(LICENSE-A OR LICENSE-B)" to "LICENSE-A OR LICENSE-B"
> as per the Linux Kernel style document.  Note that parenthesis are
> allowed so when they were used before we continue to use them.
> 
> Signed-off-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] git-mailrc: Update some addresses and aliases

[Tom Rini]

On Mon, May 07, 2018 at 11:07:06AM -0400, Tom Rini wrote:

> - Based on 08ae21af9671 ("MAINTAINERS: Switch nxp.com domain") update or
>   drop some formerly Freescale addresses.
> - Update a few aliases to reflect current custodians
> 
> Signed-off-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v7 06/35] musb: sunxi: Add OTG device clkgate and reset for H3/H5

[Marek Vasut]

On 05/07/2018 04:52 PM, Maxime Ripard wrote:
> On Mon, May 07, 2018 at 01:47:43PM +0200, Marek Vasut wrote:
>> On 05/07/2018 09:33 AM, Jagan Teki wrote:
>>> Add OTG device clkgate and reset for H3/H5 through driver_data.
>>>
>>> Signed-off-by: Jagan Teki 
>>
>> Why don't you implement a clock driver for this SoC instead ?
> 
> Aren't you asking a bit too much?

I am not asking for anything, this is a question, not a request.

I asked why not implement a clock driver and use it just like any other
civilized modern driver would instead of digging in the clock controller
registers from a USB framework driver (which is icky).

I think that if we are doing some sort of conversion, we should do it
completely and properly instead of leaving in hacks like this. A clock
driver which allows enabling/disabling clock is probably like what, 2
hour work ? So maybe it's worth investing that time up front to save
maintenance burden in the future.

> Since the first post of these patches, you've asked to rework in a
> significant manner the driver already, including doing a new PHY
> driver to use the device model, and making other substantial changes
> to it.

Well yes, because it was crap at the beginning and I don't want to see
the crap accumulating. It has become much better since, as you can see I
only had a few minor comments.

> Jagan complied to all your requests so far, but this one is going to
> create yet another ton of patches on top of an (already) 35 patches
> series. And this request comes out of nowhere at the 7th version.

I disagree, one clock driver patch and a tweak to the series, unless I
missed something obvious.

> Creating a new clock driver will take a lot of effort, and this really
> surprise me given that we've had strictly no feedback from you on this
> considering all the previous SoCs bringups we've done so far.

What do you mean by "this" ? I think i did review the previous
iterations of this series ? If not, was I on CC ?

I have to admit, I don't really care about the rest of the Allwinner SoC
code or what you do there, I only care about the USB part and this
poking of clock controller registers seems wrong in a DM/DT driver.

I also don't mind if the clock driver comes later, but I would like to
see it happen at some point (soon) to remove this register poking.

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] git-mailrc: Update some addresses and aliases

[Tom Rini]

- Based on 08ae21af9671 ("MAINTAINERS: Switch nxp.com domain") update or
  drop some formerly Freescale addresses.
- Update a few aliases to reflect current custodians

Signed-off-by: Tom Rini 
---
 doc/git-mailrc | 39 ---
 1 file changed, 12 insertions(+), 27 deletions(-)

diff --git a/doc/git-mailrc b/doc/git-mailrc
index e55a1cb1d9e6..af8e3358a983 100644
--- a/doc/git-mailrc
+++ b/doc/git-mailrc
@@ -16,25 +16,21 @@ alias abrodkin   Alexey Brodkin 

 alias afleming   Andy Fleming 
 alias ag Anatolij Gustschin 
 alias agraf  Alexander Graf 
-alias alisonwang Alison Wang 
+alias alisonwang Alison Wang 
 alias angelo_ts  Angelo Dureghello 
 alias bmeng  Bin Meng 
 alias danielschwierzeck Daniel Schwierzeck 
 alias dinh  Dinh Nguyen 
-alias galak  Kumar Gala 
 alias hs Heiko Schocher 
-alias ijcIan Campbell 
 alias iwamatsu   Nobuhiro Iwamatsu 
 alias jaehoonJaehoon Chung 
 alias jagan  Jagan Teki 
-alias jasonjin   Jason Jin 
 alias jhersh Joe Hershberger 
-alias jwrdegoede Hans de Goede 
-alias kimphill   Kim Phillips 
 alias luka   Luka Perkov 
 alias lukma  Lukasz Majewski 
 alias macpaulMacpaul Lin 
 alias marex  Marek Vasut 
+alias mariosix   Mario Six 
 alias masahiro   Masahiro Yamada 
 alias mateuszMateusz Kulikowski 
 alias maximeMaxime Ripard 
@@ -42,25 +38,22 @@ alias monstr Michal Simek 
 alias prafulla   Prafulla Wadaskar 
 alias prom   Minkyu Kang 
 alias ptomsich   Philipp Tomsich 
-alias rbohmerRemy Bohmer 
-alias reinhardm  Reinhard Meyer 
 alias sbabic Stefano Babic 
-alias scottwood  Scott Wood 
+alias scottwood  Scott Wood 
 alias sjgSimon Glass 
 alias smcnuttScott McNutt 
-alias sonic  Sonic Zhang 
 alias stroeseStefan Roese 
 alias trini  Tom Rini 
-alias vapier Mike Frysinger 
 alias wd Wolfgang Denk 
+alias yorksunYork Sun 
 
 # Architecture aliases
-alias arch   arc, arm, bfin, m68k, microblaze, mips, nds32, nios2, 
powerpc, sandbox, superh, sparc, x86
+alias arch   arc, arm, m68k, microblaze, mips, nds32, nios2, powerpc, 
sandbox, superh, x86
 alias arches arch
 
 alias arcuboot, abrodkin
 
-alias armuboot, aaribaud
+alias armuboot, aaribaud, trini
 alias at91   uboot, abiessmann
 alias davinciti
 alias imxuboot, sbabic
@@ -81,9 +74,6 @@ alias uniphier   uboot, masahiro
 alias zynq   uboot, monstr
 alias rockchip   uboot, sjg, Kever Yang , 
ptomsich
 
-alias bfin   uboot, vapier, sonic
-alias blackfin   bfin
-
 alias m68k   uboot, alisonwang, angelo_ts
 alias coldfire   m68k
 
@@ -97,22 +87,17 @@ alias nds32  uboot, macpaul
 alias nios   uboot, Thomas Chou , smcnutt
 alias nios2  nios
 
-alias powerpcuboot, afleming, kimphill, galak, stroese, wd
+alias powerpcuboot, afleming, stroese, wd, yorksun, mariosix
 alias ppcpowerpc
-alias mpc5xxxuboot, wd
-alias mpc8xx uboot, wd
-alias mpc82xxuboot, wd
-alias mpc83xxuboot, kimphill
-alias mpc85xxuboot, afleming, galak
-alias mpc86xxuboot, afleming, galak
-alias ppc4xx uboot, stroese
+alias mpc8xx uboot, wd, Christophe Leroy 
+alias mpc83xxuboot, yorksun, mariosix
+alias mpc85xxuboot, afleming, yorksun
+alias mpc86xxuboot, afleming, yorksun
 
 alias sandboxsjg
 alias sb sandbox
 
-alias sparc  uboot, Francois Retief 
-
-alias superh uboot, iwamatsu
+alias superh uboot, iwamatsu, marex
 alias sh 

Re: [U-Boot] [PATCH v7 06/35] musb: sunxi: Add OTG device clkgate and reset for H3/H5

[Maxime Ripard]

On Mon, May 07, 2018 at 01:47:43PM +0200, Marek Vasut wrote:
> On 05/07/2018 09:33 AM, Jagan Teki wrote:
> > Add OTG device clkgate and reset for H3/H5 through driver_data.
> > 
> > Signed-off-by: Jagan Teki 
> 
> Why don't you implement a clock driver for this SoC instead ?

Aren't you asking a bit too much?

Since the first post of these patches, you've asked to rework in a
significant manner the driver already, including doing a new PHY
driver to use the device model, and making other substantial changes
to it.

Jagan complied to all your requests so far, but this one is going to
create yet another ton of patches on top of an (already) 35 patches
series. And this request comes out of nowhere at the 7th version.

Creating a new clock driver will take a lot of effort, and this really
surprise me given that we've had strictly no feedback from you on this
considering all the previous SoCs bringups we've done so far.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC] Migrate to Linux Kernel style SPDX Tags for v2018.05

[Tom Rini]

On Mon, May 07, 2018 at 01:53:56PM +0200, Marek Vasut wrote:
> On 05/07/2018 03:57 AM, Fabio Estevam wrote:
> > On Sun, May 6, 2018 at 10:45 PM, Tom Rini  wrote:
> > 
> >> The only place they'll now be allowed, just like with the Linux Kernel,
> >> is for the first line SDPX tag in some file formats.  Bringing us in
> >> line with how the kernel goes is overall a good thing I believe.
> > 
> > Correct: it is less confusing to have U-Boot and kernel using the same
> > SPDX style.
> 
> And also the same inconsistent coding style then ?

A very small part of me wants to go and nuke all of the inconsistent
comment styles we have today scattered around into //-style comments
because _that_ enforces consistency.

"The first line is a //-style comment in C files now and the rest
aren't!" I don't think is a great argument.  And I don't think it's a
greater argument than "The SPDX tag is always the first line (rarely the
second)".

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC] Migrate to Linux Kernel style SPDX Tags for v2018.05

[Marek Vasut]

On 05/07/2018 03:57 AM, Fabio Estevam wrote:
> On Sun, May 6, 2018 at 10:45 PM, Tom Rini  wrote:
> 
>> The only place they'll now be allowed, just like with the Linux Kernel,
>> is for the first line SDPX tag in some file formats.  Bringing us in
>> line with how the kernel goes is overall a good thing I believe.
> 
> Correct: it is less confusing to have U-Boot and kernel using the same
> SPDX style.
> 
And also the same inconsistent coding style then ?

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v7 19/35] device-tree-bindings: phy: Sync sun4i-usb-phy bindings

[Marek Vasut]

On 05/07/2018 09:33 AM, Jagan Teki wrote:
> Sync sun4i-usb-phy bindings from Linux, since the
> drivers/phy/allwinner/phy-sun4i-usb.c follw similar.

follow

which commit in Linux does this come from ? This should be in the commit
message for future reference.

> Signed-off-by: Jagan Teki 
> ---
>  doc/device-tree-bindings/phy/sun4i-usb-phy.txt | 65 
> ++
>  1 file changed, 65 insertions(+)
>  create mode 100644 doc/device-tree-bindings/phy/sun4i-usb-phy.txt
> 
> diff --git a/doc/device-tree-bindings/phy/sun4i-usb-phy.txt 
> b/doc/device-tree-bindings/phy/sun4i-usb-phy.txt
> new file mode 100644
> index 00..c1ce5a0a65
> --- /dev/null
> +++ b/doc/device-tree-bindings/phy/sun4i-usb-phy.txt
> @@ -0,0 +1,65 @@
> +Allwinner sun4i USB PHY
> +---
> +
> +Required properties:
> +- compatible : should be one of
> +  * allwinner,sun4i-a10-usb-phy
> +  * allwinner,sun5i-a13-usb-phy
> +  * allwinner,sun6i-a31-usb-phy
> +  * allwinner,sun7i-a20-usb-phy
> +  * allwinner,sun8i-a23-usb-phy
> +  * allwinner,sun8i-a33-usb-phy
> +  * allwinner,sun8i-a83t-usb-phy
> +  * allwinner,sun8i-h3-usb-phy
> +  * allwinner,sun8i-v3s-usb-phy
> +  * allwinner,sun50i-a64-usb-phy
> +- reg : a list of offset + length pairs
> +- reg-names :
> +  * "phy_ctrl"
> +  * "pmu0" for H3, V3s and A64
> +  * "pmu1"
> +  * "pmu2" for sun4i, sun6i, sun7i, sun8i-a83t or sun8i-h3
> +  * "pmu3" for sun8i-h3
> +- #phy-cells : from the generic phy bindings, must be 1
> +- clocks : phandle + clock specifier for the phy clocks
> +- clock-names :
> +  * "usb_phy" for sun4i, sun5i or sun7i
> +  * "usb0_phy", "usb1_phy" and "usb2_phy" for sun6i
> +  * "usb0_phy", "usb1_phy" for sun8i
> +  * "usb0_phy", "usb1_phy", "usb2_phy" and "usb2_hsic_12M" for sun8i-a83t
> +  * "usb0_phy", "usb1_phy", "usb2_phy" and "usb3_phy" for sun8i-h3
> +- resets : a list of phandle + reset specifier pairs
> +- reset-names :
> +  * "usb0_reset"
> +  * "usb1_reset"
> +  * "usb2_reset" for sun4i, sun6i, sun7i, sun8i-a83t or sun8i-h3
> +  * "usb3_reset" for sun8i-h3
> +
> +Optional properties:
> +- usb0_id_det-gpios : gpio phandle for reading the otg id pin value
> +- usb0_vbus_det-gpios : gpio phandle for detecting the presence of usb0 vbus
> +- usb0_vbus_power-supply: power-supply phandle for usb0 vbus presence detect
> +- usb0_vbus-supply : regulator phandle for controller usb0 vbus
> +- usb1_vbus-supply : regulator phandle for controller usb1 vbus
> +- usb2_vbus-supply : regulator phandle for controller usb2 vbus
> +- usb3_vbus-supply : regulator phandle for controller usb3 vbus
> +
> +Example:
> + usbphy: phy@01c13400 {
> + #phy-cells = <1>;
> + compatible = "allwinner,sun4i-a10-usb-phy";
> + /* phy base regs, phy1 pmu reg, phy2 pmu reg */
> + reg = <0x01c13400 0x10 0x01c14800 0x4 0x01c1c800 0x4>;
> + reg-names = "phy_ctrl", "pmu1", "pmu2";
> + clocks = <_clk 8>;
> + clock-names = "usb_phy";
> + resets = <_clk 0>, <_clk 1>, <_clk 2>;
> + reset-names = "usb0_reset", "usb1_reset", "usb2_reset";
> + pinctrl-names = "default";
> + pinctrl-0 = <_id_detect_pin>, <_vbus_detect_pin>;
> + usb0_id_det-gpios = < 7 19 GPIO_ACTIVE_HIGH>; /* PH19 */
> + usb0_vbus_det-gpios = < 7 22 GPIO_ACTIVE_HIGH>; /* PH22 */
> + usb0_vbus-supply = <_usb0_vbus>;
> + usb1_vbus-supply = <_usb1_vbus>;
> + usb2_vbus-supply = <_usb2_vbus>;
> + };
> 


-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v7 06/35] musb: sunxi: Add OTG device clkgate and reset for H3/H5

[Marek Vasut]

On 05/07/2018 09:33 AM, Jagan Teki wrote:
> Add OTG device clkgate and reset for H3/H5 through driver_data.
> 
> Signed-off-by: Jagan Teki 

Why don't you implement a clock driver for this SoC instead ?

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] SPDX: Convert all of our multiple license tags to Linux Kernel style

[Fabio Estevam]

On Mon, May 7, 2018 at 11:18 AM, Tom Rini  wrote:

>> I don't see a single occurrence of 'GPL-2.0+ OR X11' in the kernel tree.
>>
>> It seems that people use 'GPL-2.0+ OR MIT' instead.
>
> They do, and on IRC someone was commenting on this as well.  This is
> however what the current tag uses and for a strict conversion patch I
> don't feel I should change things.  Thanks!

Ok, it makes sense. This could be adapted later if needed.

Thanks for doing this.

Reviewed-by: Fabio Estevam 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] SPDX: Convert all of our multiple license tags to Linux Kernel style

[Tom Rini]

On Mon, May 07, 2018 at 11:16:50AM -0300, Fabio Estevam wrote:
> Hi Tom,
> 
> On Mon, May 7, 2018 at 11:07 AM, Tom Rini  wrote:
> 
> > diff --git a/arch/arm/dts/bk4r1.dts b/arch/arm/dts/bk4r1.dts
> > index 197e5abd704f..866b80e0b0b3 100644
> > --- a/arch/arm/dts/bk4r1.dts
> > +++ b/arch/arm/dts/bk4r1.dts
> > @@ -1,7 +1,6 @@
> > +// SPDX-License-Identifier: GPL-2.0+ OR X11
> 
> I don't see a single occurrence of 'GPL-2.0+ OR X11' in the kernel tree.
> 
> It seems that people use 'GPL-2.0+ OR MIT' instead.

They do, and on IRC someone was commenting on this as well.  This is
however what the current tag uses and for a strict conversion patch I
don't feel I should change things.  Thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] SPDX: Convert all of our multiple license tags to Linux Kernel style

[Fabio Estevam]

Hi Tom,

On Mon, May 7, 2018 at 11:07 AM, Tom Rini  wrote:

> diff --git a/arch/arm/dts/bk4r1.dts b/arch/arm/dts/bk4r1.dts
> index 197e5abd704f..866b80e0b0b3 100644
> --- a/arch/arm/dts/bk4r1.dts
> +++ b/arch/arm/dts/bk4r1.dts
> @@ -1,7 +1,6 @@
> +// SPDX-License-Identifier: GPL-2.0+ OR X11

I don't see a single occurrence of 'GPL-2.0+ OR X11' in the kernel tree.

It seems that people use 'GPL-2.0+ OR MIT' instead.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 08/11] sandbox: Enable support for MC34708 PMIC in DTS

[Lukasz Majewski]

Hi Fabio,

> Hi Lukasz,
> 
> On Sun, May 6, 2018 at 5:26 PM, Lukasz Majewski  wrote:
> 
> > diff --git a/arch/sandbox/dts/sandbox.dts
> > b/arch/sandbox/dts/sandbox.dts index 1fb8225fbb..b187b6fac1 100644
> > --- a/arch/sandbox/dts/sandbox.dts
> > +++ b/arch/sandbox/dts/sandbox.dts
> > @@ -115,6 +115,10 @@
> > sandbox_pmic: sandbox_pmic {
> > reg = <0x40>;
> > };
> > +
> > +   mc34708_pmic: mc34708_pmic {
> > +   reg = <0x41>;
> > +   };  
> 
> I know you are following the current style of this file, but this
> looks incorrect.
> 
> According to Devicetree Specification v0.2 document:
> 
> "The name of a node should be somewhat generic, reflecting the
> function of the device and not its precise programming model."
> 
> Also, the reg property needs to have a corresponding unit address.
> 
> It would better to rewrite this as:
> 
> mc34708: pmic@41 {
>  reg = <0x41>
> };

Yes, you are right. I've blindly followed the current (wrong) code.

I'm now waiting for comments from Simon and will fix this in v3.

Thanks for review.


Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de


pgp82QpefYUeU.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 2/2] SPDX: Convert all of our multiple license tags to Linux Kernel style

[Tom Rini]

When U-Boot started using SPDX tags we were among the early adopters and
there weren't a lot of other examples to borrow from.  So we picked the
area of the file that usually had a full license text and replaced it
with an appropriate SPDX-License-Identifier: entry.  Since then, the
Linux Kernel has adopted SPDX tags and they place it as the very first
line in a file (except where shebangs are used, then it's second line)
and with slightly different comment styles than us.

In part due to community overlap, in part due to better tag visibility
and in part for other minor reasons, switch over to that style.

This commit changes all instances where we have multiple licenses (in
these cases, dual license) declared in the SPDX-License-Identifier tag.
In this case we change from listing "LICENSE-A LICENSE-B" or "LICENSE-A
or LICENSE-B" or "(LICENSE-A OR LICENSE-B)" to "LICENSE-A OR LICENSE-B"
as per the Linux Kernel style document.  Note that parenthesis are
allowed so when they were used before we continue to use them.

Signed-off-by: Tom Rini 
---
 arch/arm/dts/bk4r1.dts| 3 +--
 arch/arm/dts/fsl-ls1012a-frdm.dts | 3 +--
 arch/arm/dts/fsl-ls1012a-frdm.dtsi| 3 +--
 arch/arm/dts/fsl-ls1012a-qds.dts  | 3 +--
 arch/arm/dts/fsl-ls1012a-qds.dtsi | 3 +--
 arch/arm/dts/fsl-ls1012a-rdb.dts  | 3 +--
 arch/arm/dts/fsl-ls1012a-rdb.dtsi | 3 +--
 arch/arm/dts/fsl-ls1012a.dtsi | 3 +--
 arch/arm/dts/fsl-ls1043a-qds-duart.dts| 3 +--
 arch/arm/dts/fsl-ls1043a-qds-lpuart.dts   | 3 +--
 arch/arm/dts/fsl-ls1043a-qds.dtsi | 3 +--
 arch/arm/dts/fsl-ls1043a-rdb.dts  | 3 +--
 arch/arm/dts/fsl-ls1043a.dtsi | 3 +--
 arch/arm/dts/fsl-ls1046a-qds-duart.dts| 3 +--
 arch/arm/dts/fsl-ls1046a-qds-lpuart.dts   | 3 +--
 arch/arm/dts/fsl-ls1046a-qds.dtsi | 3 +--
 arch/arm/dts/fsl-ls1046a-rdb.dts  | 3 +--
 arch/arm/dts/fsl-ls1046a.dtsi | 3 +--
 arch/arm/dts/fsl-ls1088a-qds.dts  | 3 +--
 arch/arm/dts/fsl-ls1088a-rdb.dts  | 3 +--
 arch/arm/dts/fsl-ls1088a.dtsi | 3 +--
 arch/arm/dts/fsl-ls2080a-qds.dts  | 3 +--
 arch/arm/dts/fsl-ls2080a-rdb.dts  | 3 +--
 arch/arm/dts/fsl-ls2080a.dtsi | 3 +--
 arch/arm/dts/fsl-ls2081a-rdb.dts  | 3 +--
 arch/arm/dts/fsl-ls2088a-rdb-qspi.dts | 3 +--
 arch/arm/dts/imx53-cx9020.dts | 3 +--
 arch/arm/dts/imx7-colibri.dts | 3 +--
 arch/arm/dts/meson-gxl-mali.dtsi  | 3 +--
 arch/arm/dts/meson-gxl-s905x-khadas-vim.dts   | 3 +--
 arch/arm/dts/meson-gxl-s905x-libretech-cc.dts | 3 +--
 arch/arm/dts/meson-gxl-s905x-p212.dtsi| 3 +--
 arch/arm/dts/pcm052.dts   | 3 +--
 arch/arm/dts/rk3188-radxarock.dts | 3 +--
 arch/arm/dts/rk3188.dtsi  | 3 +--
 arch/arm/dts/rk3229-evb.dts   | 3 +--
 arch/arm/dts/rk3288-evb.dts   | 3 +--
 arch/arm/dts/rk3288-evb.dtsi  | 3 +--
 arch/arm/dts/rk3288-fennec.dts| 3 +--
 arch/arm/dts/rk3288-firefly.dts   | 3 +--
 arch/arm/dts/rk3288-firefly.dtsi  | 3 +--
 arch/arm/dts/rk3288-miqi.dts  | 3 +--
 arch/arm/dts/rk3288-miqi.dtsi | 3 +--
 arch/arm/dts/rk3288-popmetal.dts  | 3 +--
 arch/arm/dts/rk3288-tinker.dts| 3 +--
 arch/arm/dts/rk3368-geekbox-u-boot.dtsi   | 3 +--
 arch/arm/dts/rk3368-lion-u-boot.dtsi  | 3 +--
 arch/arm/dts/rk3368-lion.dts  | 3 +--
 arch/arm/dts/rk3368-px5-evb-u-boot.dtsi   | 3 +--
 arch/arm/dts/rk3368-sheep-u-boot.dtsi | 3 +--
 arch/arm/dts/rk3399-puma-ddr1333.dts  | 3 +--
 arch/arm/dts/rk3399-puma-ddr1600.dts  | 3 +--
 arch/arm/dts/rk3399-puma-ddr1866.dts  | 3 +--
 arch/arm/dts/rk3399-puma.dtsi | 3 +--
 arch/arm/dts/rk3xxx.dtsi  | 3 +--
 arch/arm/dts/socfpga_arria10_socdk_sdmmc_handoff.dtsi | 3 +--
 arch/arm/dts/stm32mp15-ddr.dtsi   | 3 +--
 arch/arm/dts/stm32mp15-ddr3-2x4Gb-1066-binG.dtsi  | 3 +--
 arch/arm/dts/stm32mp157-u-boot.dtsi   | 3 +--
 arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi  | 3 +--
 arch/arm/dts/sun4i-a10-inet-3f.dts| 3 +--
 arch/arm/dts/sun4i-a10-inet-3w.dts| 3 +--
 

[U-Boot] [PATCH 0/2] SPDX: Convert tags to Linux Kernel style

[Tom Rini]

As per the emails I had sent before on this subject, I've converted our
SPDX tags to Linux Kernel style.  What this means, to quote from the
kernel's Documentation/process/license-rules.rst file is:
2. Style:

   The SPDX license identifier is added in form of a comment.  The comment
   style depends on the file type::

  C source: // SPDX-License-Identifier: 
  C header: /* SPDX-License-Identifier:  */
  ASM:  /* SPDX-License-Identifier:  */
  scripts:  # SPDX-License-Identifier: 
  .rst: .. SPDX-License-Identifier: 
  .dts{i}:  // SPDX-License-Identifier: 

Where, yes, the C source comments are not our usual style.  But I believe
that cross-project consistency is important and will further help us when
we fixup some of our from Linux but un-tagged-currently files.  I'm posting
these patches currently for posterity as I will be pushing them both
shortly (they have build tested the world successfully).  I'm also not
going to approve 1/2 to the ML as it's huge and I frankly expect Google to
tell me I can't send it.  The commit log is:

commit 83d290c56fab2d38cd1ab4c4cc7099559c1d5046
Author: Tom Rini 
Date:   Sun May 6 17:58:06 2018 -0400

SPDX: Convert all of our single license tags to Linux Kernel style

When U-Boot started using SPDX tags we were among the early adopters and
there weren't a lot of other examples to borrow from.  So we picked the
area of the file that usually had a full license text and replaced it
with an appropriate SPDX-License-Identifier: entry.  Since then, the
Linux Kernel has adopted SPDX tags and they place it as the very first
line in a file (except where shebangs are used, then it's second line)
and with slightly different comment styles than us.

In part due to community overlap, in part due to better tag visibility
and in part for other minor reasons, switch over to that style.

This commit changes all instances where we have a single declared
license in the tag as both the before and after are identical in tag
contents.  There's also a few places where I found we did not have a tag
and have introduced one.

Signed-off-by: Tom Rini 

And I think the above summarizes things well.  I am posting 2/2 for
posterity as it contains no functional changes but to repeat what the
commit log says, we go from "LICENSE-A LICENSE-B" to "LICENSE-A OR
LICENSE-B" which allows for useful expressions to be made.

-- 
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC] Migrate to Linux Kernel style SPDX Tags for v2018.05

[Tom Rini]

On Mon, May 07, 2018 at 01:56:54PM +0900, Masahiro Yamada wrote:
> 2018-05-07 9:35 GMT+09:00 Marek Vasut :
> > On 04/26/2018 01:26 PM, Tom Rini wrote:
> >> Hey all,
> >>
> >> This was already brought up by  Heinrich Schuchardt, but didn't get much
> >> traction.  So, I'm bringing it up again now.  The little feedback from
> >> that thread was we should move to Linux Kernel style tags.  I'm going to
> >> propose that we do just that, for v2018.05.  I'll play with coccinelle
> >> to get it done.  Comments?  Thanks!
> >
> > We rejected C++ style comments for a long long time , both in U-Boot and
> > in Linux. Why do we accept them now ? I find them horrid and they only
> > bring inconsistency into the coding style.
> >
> 
> Linus changed his mind.
> 
> https://lkml.org/lkml/2017/11/25/133

Thanks for the link!  He, unsurprisingly, makes some good points.  And
having converted all of our tags, we do indeed have a number of places
with unique comment style left.

We also had a small number of cases of incorrect tags which I think if
the tag stood out more might have been caught during review.

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3 2/6] spi: omap3_spi: Full dm conversion

[Jagan Teki]

omap3_spi now support dt along with platform data,
respective boards need to switch into dm for the same.

Tested-by: Adam Ford  #omap3_logic
Signed-off-by: Jagan Teki 
---
 drivers/spi/Kconfig  |  14 +-
 drivers/spi/omap3_spi.c  | 337 +++
 include/dm/platform_data/spi_omap3.h |  16 ++
 3 files changed, 125 insertions(+), 242 deletions(-)
 create mode 100644 include/dm/platform_data/spi_omap3.h

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index d93f7d0049..72423beebf 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -111,6 +111,13 @@ config MVEBU_A3700_SPI
  used to access the SPI NOR flash on platforms embedding this
  Marvell IP core.
 
+config OMAP3_SPI
+   bool "McSPI driver for OMAP"
+   help
+ SPI master controller for OMAP24XX and later Multichannel SPI
+ (McSPI). This driver be used to access SPI chips on platforms
+ embedding this OMAP3 McSPI IP core.
+
 config PIC32_SPI
bool "Microchip PIC32 SPI driver"
depends on MACH_PIC32
@@ -305,11 +312,4 @@ config MXS_SPI
  Enable the MXS SPI controller driver. This driver can be used
  on the i.MX23 and i.MX28 SoCs.
 
-config OMAP3_SPI
-   bool "McSPI driver for OMAP"
-   help
- SPI master controller for OMAP24XX and later Multichannel SPI
- (McSPI). This driver be used to access SPI chips on platforms
- embedding this OMAP3 McSPI IP core.
-
 endmenu # menu "SPI Support"
diff --git a/drivers/spi/omap3_spi.c b/drivers/spi/omap3_spi.c
index 1ac691a68e..4108dcabbf 100644
--- a/drivers/spi/omap3_spi.c
+++ b/drivers/spi/omap3_spi.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -109,9 +110,6 @@ struct mcspi {
 };
 
 struct omap3_spi_priv {
-#ifndef CONFIG_DM_SPI
-   struct spi_slave slave;
-#endif
struct mcspi *regs;
unsigned int cs;
unsigned int freq;
@@ -312,12 +310,16 @@ static int omap3_spi_txrx(struct omap3_spi_priv *priv, 
unsigned int len,
return 0;
 }
 
-static int _spi_xfer(struct omap3_spi_priv *priv, unsigned int bitlen,
-const void *dout, void *din, unsigned long flags)
+static int omap3_spi_xfer(struct udevice *dev, unsigned int bitlen,
+ const void *dout, void *din, unsigned long flags)
 {
-   unsigned intlen;
+   struct udevice *bus = dev->parent;
+   struct omap3_spi_priv *priv = dev_get_priv(bus);
+   struct dm_spi_slave_platdata *slave_plat = dev_get_parent_platdata(dev);
+   unsigned int len;
int ret = -1;
 
+   priv->cs = slave_plat->cs;
if (priv->wordlen < 4 || priv->wordlen > 32) {
printf("omap3_spi: invalid wordlen %d\n", priv->wordlen);
return -1;
@@ -353,78 +355,6 @@ static int _spi_xfer(struct omap3_spi_priv *priv, unsigned 
int bitlen,
return ret;
 }
 
-static void _omap3_spi_set_speed(struct omap3_spi_priv *priv)
-{
-   uint32_t confr, div = 0;
-
-   confr = readl(>regs->channel[priv->cs].chconf);
-
-   /* Calculate clock divisor. Valid range: 0x0 - 0xC ( /1 - /4096 ) */
-   if (priv->freq) {
-   while (div <= 0xC && (OMAP3_MCSPI_MAX_FREQ / (1 << div))
-   > priv->freq)
-   div++;
-   } else {
-div = 0xC;
-   }
-
-   /* set clock divisor */
-   confr &= ~OMAP3_MCSPI_CHCONF_CLKD_MASK;
-   confr |= div << 2;
-
-   omap3_spi_write_chconf(priv, confr);
-}
-
-static void _omap3_spi_set_mode(struct omap3_spi_priv *priv)
-{
-   uint32_t confr;
-
-   confr = readl(>regs->channel[priv->cs].chconf);
-
-   /* standard 4-wire master mode:  SCK, MOSI/out, MISO/in, nCS
-* REVISIT: this controller could support SPI_3WIRE mode.
-*/
-   if (priv->pin_dir == MCSPI_PINDIR_D0_IN_D1_OUT) {
-   confr &= ~(OMAP3_MCSPI_CHCONF_IS|OMAP3_MCSPI_CHCONF_DPE1);
-   confr |= OMAP3_MCSPI_CHCONF_DPE0;
-   } else {
-   confr &= ~OMAP3_MCSPI_CHCONF_DPE0;
-   confr |= OMAP3_MCSPI_CHCONF_IS|OMAP3_MCSPI_CHCONF_DPE1;
-   }
-
-   /* set SPI mode 0..3 */
-   confr &= ~(OMAP3_MCSPI_CHCONF_POL | OMAP3_MCSPI_CHCONF_PHA);
-   if (priv->mode & SPI_CPHA)
-   confr |= OMAP3_MCSPI_CHCONF_PHA;
-   if (priv->mode & SPI_CPOL)
-   confr |= OMAP3_MCSPI_CHCONF_POL;
-
-   /* set chipselect polarity; manage with FORCE */
-   if (!(priv->mode & SPI_CS_HIGH))
-   confr |= OMAP3_MCSPI_CHCONF_EPOL; /* active-low; normal */
-   else
-   confr &= ~OMAP3_MCSPI_CHCONF_EPOL;
-
-   /* Transmit & receive mode */
-   confr &= ~OMAP3_MCSPI_CHCONF_TRM_MASK;
-
-   omap3_spi_write_chconf(priv, confr);
-}
-
-static void _omap3_spi_set_wordlen(struct omap3_spi_priv 

[U-Boot] [PATCH] driver/mtd/spi: Default page size Spansion flash "S25FS512S" is 256b

[Ashish Kumar]

Signed-off-by: Ashish Kumar 
---
 drivers/mtd/spi/spi_flash.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 3d24a08..ce420cb 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -1046,14 +1046,15 @@ int spi_flash_scan(struct spi_flash *flash)
flash->shift = (flash->dual_flash & SF_DUAL_PARALLEL_FLASH) ? 1 : 0;
flash->page_size = info->page_size;
/*
-* The Spansion S25FL032P and S25FL064P have 256b pages, yet use the
-* 0x4d00 Extended JEDEC code. The rest of the Spansion flashes with
-* the 0x4d00 Extended JEDEC code have 512b pages. All of the others
-* have 256b pages.
+* The Spansion S25FS512S, S25FL032P and S25FL064P have 256b pages,
+* yet use the 0x4d00 Extended JEDEC code. The rest of the Spansion
+* flashes with the 0x4d00 Extended JEDEC code have 512b pages.
+* All of the others have 256b pages.
 */
if (JEDEC_EXT(info) == 0x4d00) {
if ((JEDEC_ID(info) != 0x0215) &&
-   (JEDEC_ID(info) != 0x0216))
+   (JEDEC_ID(info) != 0x0216) &&
+   (JEDEC_ID(info) != 0x0220))
flash->page_size = 512;
}
flash->page_size <<= flash->shift;
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/5] ARM: arm926ejs: fix lowlevel_init call

[Måns Rullgård]

Chris Packham  writes:

> Hi Mans, Stefano,
>
> On Fri, Apr 27, 2018 at 9:00 PM Stefano Babic  wrote:
>
>> On 21/04/2018 17:11, Mans Rullgard wrote:
>> > The code attempts to preserve the value of LR by storing it in R12/IP
>> > across the lowevel_init() call.  However, this register is not saved
>> > by the callee.  Use a register that guaranteed to be preserved instead.
>> >
>> > Signed-off-by: Mans Rullgard 
>> > ---
>> >  arch/arm/cpu/arm926ejs/start.S | 4 ++--
>> >  1 file changed, 2 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/arch/arm/cpu/arm926ejs/start.S
> b/arch/arm/cpu/arm926ejs/start.S
>> > index 959d1ed86d8a..a6f0bdb70345 100644
>> > --- a/arch/arm/cpu/arm926ejs/start.S
>> > +++ b/arch/arm/cpu/arm926ejs/start.S
>> > @@ -105,9 +105,9 @@ flush_dcache:
>> >   /*
>> >* Go setup Memory and board specific bits prior to relocation.
>> >*/
>> > - mov ip, lr  /* perserve link reg across call */
>> > + mov r4, lr  /* perserve link reg across call */
>> >   bl  lowlevel_init   /* go setup pll,mux,memory */
>> > - mov lr, ip  /* restore link */
>> > + mov lr, r4  /* restore link */
>> >  #endif
>> >   mov pc, lr  /* back to my caller */
>> >  #endif /* CONFIG_SKIP_LOWLEVEL_INIT */
>> >
>
>> Applied to u-boot-imx, thanks !
>
> I think this might be causing me a problem on a Marvell Kirkwood board I'm
> working on getting into upstream. It may also be problematic for orion5x
> boards. Both of these use r4 in lowlevel_init.

I've just sent an untested patch for orion5x.

-- 
Måns Rullgård
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [UNTESTED PATCH] ARM: orion5x: fix use of callee-saved registers in lowloevel_init

[Mans Rullgard]

The lowlevel_init function uses r4 and r6 without preserving their
values as required by the AAPCS.  Use r0 and r2 instead as these
are call-clobbered.

Signed-off-by: Mans Rullgard 
---
 arch/arm/mach-orion5x/lowlevel_init.S | 168 +-
 1 file changed, 84 insertions(+), 84 deletions(-)

diff --git a/arch/arm/mach-orion5x/lowlevel_init.S 
b/arch/arm/mach-orion5x/lowlevel_init.S
index 3f38f36ff294..a4e113601013 100644
--- a/arch/arm/mach-orion5x/lowlevel_init.S
+++ b/arch/arm/mach-orion5x/lowlevel_init.S
@@ -72,67 +72,67 @@ lowlevel_init:
 
 #ifdef CONFIG_SPL_BUILD
 
-   /* Use 'r4 as the base for internal register accesses */
-   ldr r4, =ORION5X_REGS_PHY_BASE
+   /* Use 'r2 as the base for internal register accesses */
+   ldr r2, =ORION5X_REGS_PHY_BASE
 
/* move internal registers from the default 0xD000
 * to their intended location, defined by SoC */
ldr r3, =0xD000
add r3, r3, #0x2
-   str r4, [r3, #0x80]
+   str r2, [r3, #0x80]
 
/* Use R3 as the base for DRAM registers */
-   add r3, r4, #0x01000
+   add r3, r2, #0x01000
 
/*DDR SDRAM Initialization Control */
-   ldr r6, =0x0001
-   str r6, [r3, #0x480]
+   ldr r0, =0x0001
+   str r0, [r3, #0x480]
 
/* Use R3 as the base for PCI registers */
-   add r3, r4, #0x31000
+   add r3, r2, #0x31000
 
/* Disable arbiter */
-   ldr r6, =0x0030
-   str r6, [r3, #0xd00]
+   ldr r0, =0x0030
+   str r0, [r3, #0xd00]
 
/* Use R3 as the base for DRAM registers */
-   add r3, r4, #0x01000
+   add r3, r2, #0x01000
 
/* set all dram windows to 0 */
-   mov r6, #0
-   str r6, [r3, #0x504]
-   str r6, [r3, #0x50C]
-   str r6, [r3, #0x514]
-   str r6, [r3, #0x51C]
+   mov r0, #0
+   str r0, [r3, #0x504]
+   str r0, [r3, #0x50C]
+   str r0, [r3, #0x514]
+   str r0, [r3, #0x51C]
 
/* 1) Configure SDRAM  */
-   ldr r6, =SDRAM_CONFIG
-   str r6, [r3, #0x400]
+   ldr r0, =SDRAM_CONFIG
+   str r0, [r3, #0x400]
 
/* 2) Set SDRAM Control reg */
-   ldr r6, =SDRAM_CONTROL
-   str r6, [r3, #0x404]
+   ldr r0, =SDRAM_CONTROL
+   str r0, [r3, #0x404]
 
/* 3) Write SDRAM address control register */
-   ldr r6, =SDRAM_ADDR_CTRL
-   str r6, [r3, #0x410]
+   ldr r0, =SDRAM_ADDR_CTRL
+   str r0, [r3, #0x410]
 
/* 4) Write SDRAM bank 0 size register */
-   ldr r6, =SDRAM_BANK0_SIZE
-   str r6, [r3, #0x504]
+   ldr r0, =SDRAM_BANK0_SIZE
+   str r0, [r3, #0x504]
/* keep other banks disabled */
 
/* 5) Write SDRAM open pages control register */
-   ldr r6, =SDRAM_OPEN_PAGE_EN
-   str r6, [r3, #0x414]
+   ldr r0, =SDRAM_OPEN_PAGE_EN
+   str r0, [r3, #0x414]
 
/* 6) Write SDRAM timing Low register */
-   ldr r6, =SDRAM_TIME_CTRL_LOW
-   str r6, [r3, #0x408]
+   ldr r0, =SDRAM_TIME_CTRL_LOW
+   str r0, [r3, #0x408]
 
/* 7) Write SDRAM timing High register */
-   ldr r6, =SDRAM_TIME_CTRL_HI
-   str r6, [r3, #0x40C]
+   ldr r0, =SDRAM_TIME_CTRL_HI
+   str r0, [r3, #0x40C]
 
/* 8) Write SDRAM mode register */
/* The CPU must not attempt to change the SDRAM Mode register setting */
@@ -143,73 +143,73 @@ lowlevel_init:
/* and then sets SDRAM Mode register to its new value.*/
 
/* 8.1 write 'nop' to SDRAM operation */
-   ldr r6, =SDRAM_OP_NOP
-   str r6, [r3, #0x418]
+   ldr r0, =SDRAM_OP_NOP
+   str r0, [r3, #0x418]
 
/* 8.2 poll SDRAM operation until back in 'normal' mode.  */
 1:
-   ldr r6, [r3, #0x418]
-   cmp r6, #0
+   ldr r0, [r3, #0x418]
+   cmp r0, #0
bne 1b
 
/* 8.3 Now its safe to write new value to SDRAM Mode register */
-   ldr r6, =SDRAM_MODE
-   str r6, [r3, #0x41C]
+   ldr r0, =SDRAM_MODE
+   str r0, [r3, #0x41C]
 
/* 8.4 Set new mode */
-   ldr r6, =SDRAM_OP_SETMODE
-   str r6, [r3, #0x418]
+   ldr r0, =SDRAM_OP_SETMODE
+   str r0, [r3, #0x418]
 
/* 8.5 poll SDRAM operation until back in 'normal' mode.  */
 2:
-   ldr r6, [r3, #0x418]
-   cmp r6, #0
+   ldr r0, [r3, #0x418]
+   cmp r0, #0
bne 2b
 
/* DDR SDRAM Address/Control Pads Calibration */
-   ldr r6, [r3, #0x4C0]
+   ldr r0, [r3, #0x4C0]
 
/* Set Bit [31] to make the register writable   */
-   orr r6, r6, #SDRAM_PAD_CTRL_WR_EN
-   str   

[U-Boot] [PATCH] spi: cadence_qspi: Fix warning cast from pointer to integer of different size

[Ley Foon Tan]

Cast to ulong data type.

Compilation warning as below:

  CC  spl/drivers/spi/cadence_qspi_apb.o
  LD  spl/lib/built-in.o
drivers/spi/cadence_qspi_apb.c: In function 
‘cadence_qspi_apb_indirect_write_setup’:
drivers/spi/cadence_qspi_apb.c:696:18: warning: cast from pointer to integer of 
different size [-Wpointer-to-int-cast]
  cmdlen, (unsigned int)cmdbuf);

Signed-off-by: Ley Foon Tan 
---
 drivers/spi/cadence_qspi_apb.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
index aa3a9ff..5bef0ae 100644
--- a/drivers/spi/cadence_qspi_apb.c
+++ b/drivers/spi/cadence_qspi_apb.c
@@ -692,8 +692,8 @@ int cadence_qspi_apb_indirect_write_setup(struct 
cadence_spi_platdata *plat,
unsigned int addr_bytes = cmdlen > 4 ? 4 : 3;
 
if (cmdlen < 4 || cmdbuf == NULL) {
-   printf("QSPI: iInvalid input argument, len %d cmdbuf 0x%08x\n",
-  cmdlen, (unsigned int)cmdbuf);
+   printf("QSPI: Invalid input argument, len %d cmdbuf 0x%08lx\n",
+  cmdlen, (unsigned long)cmdbuf);
return -EINVAL;
}
/* Setup the indirect trigger address */
-- 
1.7.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] spi: cadence_qspi: Fix compilation warning

[Ley Foon Tan]

Cast data_bytes to integer.

Compilation warning as below:

In file included from include/linux/bug.h:7:0,
 from include/common.h:26,
 from drivers/spi/cadence_qspi.c:8:
drivers/spi/cadence_qspi.c: In function ‘cadence_spi_xfer’:
drivers/spi/cadence_qspi.c:211:8: warning: format ‘%d’ expects argument of type 
‘int’, but argument 3 has type ‘size_t {aka long unsigned int}’ [-Wformat=]
  debug("%s: len=%d [bytes]\n", __func__, data_bytes);
^
include/linux/printk.h:37:21: note: in definition of macro ‘pr_fmt’
 #define pr_fmt(fmt) fmt
 ^~~
include/log.h:142:2: note: in expansion of macro ‘debug_cond’
  debug_cond(_DEBUG, fmt, ##args)
  ^~
drivers/spi/cadence_qspi.c:211:2: note: in expansion of macro ‘debug’
  debug("%s: len=%d [bytes]\n", __func__, data_bytes);

Signed-off-by: Ley Foon Tan 
---
 drivers/spi/cadence_qspi.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
index f80d073..dc4b5a4 100644
--- a/drivers/spi/cadence_qspi.c
+++ b/drivers/spi/cadence_qspi.c
@@ -208,7 +208,7 @@ static int cadence_spi_xfer(struct udevice *dev, unsigned 
int bitlen,
} else {
data_bytes = bitlen / 8;
}
-   debug("%s: len=%d [bytes]\n", __func__, data_bytes);
+   debug("%s: len=%d [bytes]\n", __func__, (int)data_bytes);
 
/* Set Chip select */
cadence_qspi_apb_chipselect(base, spi_chip_select(dev),
-- 
1.7.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] spi: cadence_qspi: Change to use devfdt_get_addr_index()

[Ley Foon Tan]

Change to use devfdt_get_addr_index() function to get fdt address.

Original code has compilation warning below:

drivers/spi/cadence_qspi.c: In function ‘cadence_spi_ofdata_to_platdata’:
drivers/spi/cadence_qspi.c:297:18: warning: cast to pointer from integer of 
different size [-Wint-to-pointer-cast]
  plat->regbase = (void *)data[0];
  ^
drivers/spi/cadence_qspi.c:298:18: warning: cast to pointer from integer of 
different size [-Wint-to-pointer-cast]
  plat->ahbbase = (void *)data[2];
  ^
Signed-off-by: Ley Foon Tan 
---
 drivers/spi/cadence_qspi.c |   13 ++---
 1 files changed, 2 insertions(+), 11 deletions(-)

diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
index 7b312f8..f80d073 100644
--- a/drivers/spi/cadence_qspi.c
+++ b/drivers/spi/cadence_qspi.c
@@ -284,18 +284,9 @@ static int cadence_spi_ofdata_to_platdata(struct udevice 
*bus)
const void *blob = gd->fdt_blob;
int node = dev_of_offset(bus);
int subnode;
-   u32 data[4];
-   int ret;
 
-   /* 2 base addresses are needed, lets get them from the DT */
-   ret = fdtdec_get_int_array(blob, node, "reg", data, ARRAY_SIZE(data));
-   if (ret) {
-   printf("Error: Can't get base addresses (ret=%d)!\n", ret);
-   return -ENODEV;
-   }
-
-   plat->regbase = (void *)data[0];
-   plat->ahbbase = (void *)data[2];
+   plat->regbase = (void *)devfdt_get_addr_index(bus, 0);
+   plat->ahbbase = (void *)devfdt_get_addr_index(bus, 1);
plat->is_decoded_cs = fdtdec_get_bool(blob, node, "cdns,is-decoded-cs");
plat->fifo_depth = fdtdec_get_uint(blob, node, "cdns,fifo-depth", 128);
plat->fifo_width = fdtdec_get_uint(blob, node, "cdns,fifo-width", 4);
-- 
1.7.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3 1/6] spi: kconfig: Move MPC8XXX_SPI to if DM_SPI

[Jagan Teki]

Move MPC8XXX_SPI to DM_SPI defined since driver is now
fully converted to dm.

Signed-off-by: Jagan Teki 
---
 drivers/spi/Kconfig | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index ec92b84ed2..d93f7d0049 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -99,6 +99,11 @@ config ICH_SPI
  access the SPI NOR flash on platforms embedding this Intel
  ICH IP core.
 
+config MPC8XXX_SPI
+   bool "MPC8XXX SPI Driver"
+   help
+ Enable support for SPI on the MPC8XXX PowerPC SoCs.
+
 config MVEBU_A3700_SPI
bool "Marvell Armada 3700 SPI driver"
help
@@ -288,11 +293,6 @@ config MPC8XX_SPI
help
  Enable support for SPI on MPC8XX
 
-config MPC8XXX_SPI
-   bool "MPC8XXX SPI Driver"
-   help
- Enable support for SPI on the MPC8XXX PowerPC SoCs.
-
 config MXC_SPI
bool "MXC SPI Driver"
help
-- 
2.14.3

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot