Re: [PATCH] doc: update help message

[Heinrich Schuchardt]

On 1/14/21 12:04 PM, Patrick Delaunay wrote:

Update the help message used for 'make help':

   Documentation targets:
 Linux kernel internal documentation in different formats from ReST:
=>
 U-Boot documentation in different formats from ReST:

Signed-off-by: Patrick Delaunay 


Reviewed-by: Heinrich Schuchardt 


---

  doc/Makefile | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/Makefile b/doc/Makefile
index 0e0da5666f..a686d4728e 100644
--- a/doc/Makefile
+++ b/doc/Makefile
@@ -106,7 +106,7 @@ cleandocs:
$(Q)$(MAKE) BUILDDIR=$(abspath $(BUILDDIR)) $(build)=doc/media clean

  dochelp:
-   @echo  ' Linux kernel internal documentation in different formats from 
ReST:'
+   @echo  ' U-Boot documentation in different formats from ReST:'
@echo  '  htmldocs- HTML'
@echo  '  latexdocs   - LaTeX'
@echo  '  pdfdocs - PDF'

RE: Invitation: Regular U-Boot video call (Tuesday 19th)

[Peng Fan]

Hi Simon,

> Subject: Re: Invitation: Regular U-Boot video call (Tuesday 19th)
> 
> Hi Peng,
> 
> On Thu, 14 Jan 2021 at 18:33, Peng Fan  wrote:
> >
> > Hi Simon,
> >
> > > Subject: Invitation: Regular U-Boot video call (Tuesday 19th)
> > >
> > > Hi,
> > >
> > > (This has been discussed for a while now so I thought I would just
> > > try it)
> > >
> > > As an experiment I'd like to set up a regular 30-minute U-Boot call
> > > for people to discuss features, bugs, patches, etc.
> > >
> > > The meeting notes and details are here[1].
> >
> > The url is blocked by China. Do you have a direct google meet link, not 
> > using
> bit.ly?
> > I am in UTC + 8 timezone, not sure I am able to join, but please invite me.
> 
> Yes the link is here:
> 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.g
> oogle.com%2Fdocument%2Fd%2F1YBOMsbM19uSFyoJWnt7-PsOLBaevzQUg
> V-hiR88a5-o%2Fedit&data=04%7C01%7Cpeng.fan%40nxp.com%7Cee2d
> 255017d84f89a04308d8b95f0c8a%7C686ea1d3bc2b4c6fa92cd99c5c301635
> %7C0%7C0%7C637463165315330931%7CUnknown%7CTWFpbGZsb3d8eyJW
> IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C
> 1000&sdata=R7G%2B4iXtS%2F5qndSYHJ7L%2FzwmWfMJ5%2B%2FAWB
> RW1x2dB0s%3D&reserved=0
> 
> I don't know why it would be blocked in China. Can you access that one?

I could access this one and including the meet link using NXP VPN.

Thanks,
Peng.

> 
> Regards,
> Simon

[NXP-IMX] please pull nxp-imx-2021-1-16

[Peng Fan]

Hi Stefano,

Please pull nxp-imx-2021-1-16
---
nandbcb update/fix
sync i.MX8M dts from Linux kernel
add i.MX8MN LPDDR4 evk board
eth support for i.MX8MP evk
ddr fix for i.MX8M
---

CI:
My github ci not work.
I run buildman local and not see failure.

Thanks,
Peng.


The following changes since commit 21e1cae7902e6a9b1d7cf47cf4764e6fe7d3452a:

  Merge tag 'efi-2021-01-rc5-2' of 
https://gitlab.denx.de/u-boot/custodians/u-boot-efi (2020-12-29 10:23:58 -0500)

are available in the Git repository at:

  https://github.com/MrVan/u-boot.git tags/nxp-imx-2021-1-16

for you to fetch changes up to e02b2ca34b58131cb64b19887af007adb389f7bd:

  imx: timer: Modify GPT timer driver for mx7 (2021-01-15 18:22:44 +0800)


Han Xu (1):
  nandbcb: nand support for i.MX8MP

Peng Fan (12):
  imx: imx8mp_evk: enable eth support
  imx: imx8mn_ddr4_evk: Use CONFIG_TARGET_IMX8MN_DDR4_EVK for DDR4 EVK board
  imx: imx8mn_evk: correct stack/malloc adress
  arm: dts: imx8mn: sync dts from Linux Kernel
  imx: imx8mn: add i.MX8MN LPDDR4 EVK support
  imx8m: clock: add type of set_clk_eqos
  arm: dts: imx8mp: sync dts from Linux Kernel
  arm: dts: imx8mm: sync dts from Linux Kernel
  arm: dts: imx8mq: sync dts from Linux Kernel
  imx8m: lowlevel_init: tune alignment
  imx: imx8mn/p: drop CONFIG_SYS_[I,D]CACHE_OFF
  imx8m: add QSPI boot dev

Ye Li (9):
  imx: ddr: imx8m: Move selfref_en after DDR scrub
  nandbcb: Fix uninitialized variable
  imx: nandbcb: Fix resource leak
  imx: nandbcb: Fix resource leak in read_fcb
  imx: nandbcb: Fix potential overflow in fill_dbbt_data
  imx: nandbcb: Fix potential overflow in nandbcb_set_boot_config
  imx: Fix market segment fuse offset on iMX8MP
  imx6: Remove AHCI device before boot OS
  imx: timer: Modify GPT timer driver for mx7

 arch/arm/dts/Makefile   |1 +
 arch/arm/dts/imx8mm-evk.dts |  534 
++
 arch/arm/dts/imx8mm-evk.dtsi|  489 
++
 arch/arm/dts/imx8mm.dtsi|   53 -
 arch/arm/dts/imx8mn-ddr4-evk.dts|  321 
++---
 arch/arm/dts/imx8mn-evk-u-boot.dtsi |6 +
 arch/arm/dts/imx8mn-evk.dts |  128 ++
 arch/arm/dts/imx8mn-evk.dtsi|  360 

 arch/arm/dts/imx8mn-pinfunc.h   | 1266 
+-
 arch/arm/dts/imx8mn.dtsi|  411 
+++-
 arch/arm/dts/imx8mp-evk-u-boot.dtsi |4 +
 arch/arm/dts/imx8mp-evk.dts |  117 +-
 arch/arm/dts/imx8mp-pinfunc.h   |  360 
+---
 arch/arm/dts/imx8mp.dtsi|  234 +--
 arch/arm/dts/imx8mq-evk.dts |  186 ---
 arch/arm/dts/imx8mq-pinfunc.h   |  623 

 arch/arm/dts/imx8mq.dtsi|  302 ++--
 arch/arm/include/asm/arch-imx8m/clock.h |1 +
 arch/arm/include/asm/arch-imx8m/imx-regs.h  |2 +
 arch/arm/mach-imx/cmd_nandbcb.c |   34 +--
 arch/arm/mach-imx/cpu.c |   30 ++-
 arch/arm/mach-imx/imx8m/Kconfig |6 +
 arch/arm/mach-imx/imx8m/imximage-8mn-lpddr4.cfg |   17 ++
 arch/arm/mach-imx/imx8m/lowlevel_init.S |2 +-
 arch/arm/mach-imx/spl.c |2 +
 arch/arm/mach-imx/timer.c   |   16 +-
 board/freescale/imx8mn_evk/Kconfig  |2 +-
 board/freescale/imx8mn_evk/Makefile |1 +
 board/freescale/imx8mn_evk/lpddr4_timing.c  | 1585 
+++
 board/freescale/imx8mp_evk/imx8mp_evk.c |   65 +-
 configs/imx8mn_ddr4_evk_defconfig   |2 +-
 configs/imx8mn_evk_defconfig|   80 +++
 configs/imx8mp_evk_defconfig|9 +-
 doc/board/freescale/imx8mn_evk.rst  |   20 +-
 drivers/ddr/imx/imx8m/ddr_init.c|5 +-
 drivers/power/power_i2c.c   |8 +-
 include/configs/imx8mn_evk.h|9 +-
 include/configs/imx8mp_evk.h|   18 +-
 include/dt-bindings/clock/imx8mn-clock.h|   30 ++-
 include/dt-bindings/clock/imx8mp-clock.h|   95 +++-
 include/dt-bindings/clock/imx8mq-clock.h|   31 ++-
 41 files changed, 5743 insertions(+), 1722 deleti

Re: [PATCH v3 1/8] spl: fit: Drop 'length' argument to board_spl_fit_post_load()

[Tom Rini]

On Wed, Dec 23, 2020 at 08:44:05AM -0600, Alexandru Gagniuc wrote:

> The size is derived from the FIT image itself. Any alignment
> requirements are machine-specific and known by the board code. Thus
> the total length can be derived from the FIT image and knowledge of
> the platform. The 'length' argument is redundant. Remove it.
> 
> Signed-off-by: Alexandru Gagniuc 
> Reviewed-by: Peng Fan 
> Reviewed-by: Simon Glass 
> ---
>  arch/arm/mach-imx/spl.c | 5 +++--
>  common/spl/spl_fit.c| 4 ++--
>  include/spl.h   | 4 ++--
>  3 files changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm/mach-imx/spl.c b/arch/arm/mach-imx/spl.c
> index aa2686bb92..11255798d3 100644
> --- a/arch/arm/mach-imx/spl.c
> +++ b/arch/arm/mach-imx/spl.c
> @@ -18,6 +18,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  DECLARE_GLOBAL_DATA_PTR;
>  
> @@ -318,9 +319,9 @@ ulong board_spl_fit_size_align(ulong size)
>   return size;
>  }
>  
> -void board_spl_fit_post_load(ulong load_addr, size_t length)
> +void board_spl_fit_post_load(const void *fit)
>  {
> - u32 offset = length - CONFIG_CSF_SIZE;
> + u32 offset = ALIGN(fdt_totalsize(fit), 0x1000);
>  
>   if (imx_hab_authenticate_image(load_addr,
>  offset + IVT_SIZE + CSF_PAD_SIZE,

OK, this is a problem right here.  First, the code no longer compiles as
we don't pass in "load_addr", which is what
imx_hab_authenticate_image() takes to know where in DDR the image is to
validate.  While I could probably work out that value from what we use
now for offset, I would rather someone that can test the code do so.
Thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] Makefile: Do not call useless command 'true'

[Pali Rohár]

Hello! Could you please review this patch?

On Wednesday 04 November 2020 15:33:44 Pali Rohár wrote:
> Macro 'cmd_objcopy_uboot' currently does not work with passed empty command
> expanded from 'cmd_static_rela' and therefore dummy command 'true' is set
> in 'cmd_static_rela' to workaround this issue.
> 
> Eliminate it now by fixing 'cmd_objcopy_uboot' macro to work also with
> empty 'cmd_static_rela' macro and remove useless invocation of command
> 'true'.
> 
> Signed-off-by: Pali Rohár 
> ---
>  Makefile | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/Makefile b/Makefile
> index b90fe8b865..aeb2c17a9b 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -885,7 +885,7 @@ cmd_static_rela = \
>   tools/relocate-rela $(3) $(4) $$start $$end
>  else
>  quiet_cmd_static_rela =
> -cmd_static_rela = true
> +cmd_static_rela =
>  endif
>  
>  # Always append INPUTS so that arch config.mk's can add custom ones
> @@ -1312,7 +1312,11 @@ endif
>  shell_cmd = { $(call echo-cmd,$(1)) $(cmd_$(1)); }
>  
>  quiet_cmd_objcopy_uboot = OBJCOPY $@
> +ifdef cmd_static_rela
>  cmd_objcopy_uboot = $(cmd_objcopy) && $(call 
> shell_cmd,static_rela,$<,$@,$(CONFIG_SYS_TEXT_BASE)) || { rm -f $@; false; }
> +else
> +cmd_objcopy_uboot = $(cmd_objcopy)
> +endif
>  
>  u-boot-nodtb.bin: u-boot FORCE
>   $(call if_changed,objcopy_uboot)
> -- 
> 2.20.1
> 

Re: [PATCH 02/13] usb: musb: Fix compilation of gadget code

[Pali Rohár]

On Sunday 29 November 2020 18:52:13 Pavel Machek wrote:
> On Sun 2020-11-29 17:46:07, Pali Rohár wrote:
> > musb udc code depends on usb gadget code provided by CONFIG_USB_DEVICE and
> > defined in drivers/usb/gadget/Makefile. But this Makefile is not included
> > into U-Boot build when CONFIG_USB_GADGET is not set. As CONFIG_USB_DEVICE
> > cannot be enabled together with CONFIG_USB_GADGET it means that dependency
> > for musb udc code is not compiled during build. Fix it by including
> > drivers/usb/gadget dependency also when CONFIG_USB_DEVICE is set.
> > 
> _device_event_irq'
> > arm-linux-gnueabi-ld.bfd: 
> > drivers/usb/musb/built-in.o:u-boot/drivers/usb/musb/musb_udc.c: more 
> > undefined references to `usbd_device_event_irq' follow
> > arm-linux-gnueabi-ld.bfd: drivers/usb/musb/built-in.o: in function 
> > `udc_setup_ep':
> > u-boot/drivers/usb/musb/musb_udc.c: undefined reference to `usbd_alloc_urb'
> > arm-linux-gnueabi-ld.bfd: drivers/usb/musb/built-in.o: in function 
> > `udc_startup_events':
> > u-boot/drivers/usb/musb/musb_udc.c: undefined reference to 
> > `usbd_device_event_irq'
> > arm-linux-gnueabi-ld.bfd: u-boot/drivers/usb/musb/musb_udc.c: undefined 
> > reference to `usbd_device_event_irq'
> > arm-linux-gnueabi-ld.bfd: u-boot/drivers/usb/musb/musb_udc.c: undefined 
> > reference to `usbd_device_event_irq'
> > make: *** [Makefile:1762: u-boot] Error 1
> > 
> > Signed-off-by: Pali Rohár 
> 
> Reviewed-by: Pavel Machek 

PING!

I would like to remind this patch series as above compile error is still
present in U-Boot v2021.01 version.

Re: [GIT PULL] TI changes for v2021.04 next

[Pali Rohár]

On Monday 11 January 2021 07:34:11 Tom Rini wrote:
> On Mon, Jan 11, 2021 at 01:31:54PM +0100, Pali Rohár wrote:
> > On Monday 11 January 2021 07:28:08 Tom Rini wrote:
> > > On Mon, Jan 11, 2021 at 01:05:38PM +0100, Pali Rohár wrote:
> > > > On Thursday 07 January 2021 09:11:18 Tom Rini wrote:
> > > > > > Pali Rohár (3):
> > > > > >   Nokia RX-51: Convert to CONFIG_DM_MMC
> > > > > 
> > > > > This is also bringing up a conflict, and I think part of the real
> > > > > problem is that we shouldn't be having a single U_BOOT_DRVINFOS
> > > > > (formerly U_BOOT_DEVICES) but one per peripheral.  It may work but 
> > > > > it's
> > > > > not intentional (adding Simon in case he wants to correct me here).
> > > > 
> > > > Hello Tom! What is the one peripheral? One mmc device? Or more mmc
> > > > devices with the same mmc driver? Or all mmc devices (even with
> > > > different drivers)?
> > > 
> > > The patches (as far as it looks when merging) put all of i2c and mmc in
> > > to a single U_BOOT_DRVINFOS/U_BOOT_DEVICES rather than separate i2c and
> > > mmc U_BOOT_DRVINFOS/U_BOOT_DEVICES.
> > 
> > Ok, so you want to put all mmc devices into the one U_BOOT_DRVINFOS and
> > all i2c devices into second U_BOOT_DRVINFOS?
> 
> Yes, that's how it's usually done.

Ok! Fixed in V2.

[PATCH v2] Nokia RX-51: Convert to CONFIG_DM_MMC

[Pali Rohár]

Move twl4030_power_mmc_init() from board_mmc_power_init() to misc_init_r()
and disable CONFIG_SYS_MALLOC_F. Otherwise U-Boot cannot initialize MMC.
Also disable CONFIG_CMD_SLEEP CONFIG_DM_DEVICE_REMOVE CONFIG_MMC_VERBOSE to
free some space.

Signed-off-by: Pali Rohár 

---
Changes in v2:
* Disable also CONFIG_MMC_VERBOSE
* Put mmc definition into separate U_BOOT_DRVINFOS
---
 board/nokia/rx51/rx51.c  | 33 ++---
 configs/nokia_rx51_defconfig |  5 +
 2 files changed, 23 insertions(+), 15 deletions(-)

diff --git a/board/nokia/rx51/rx51.c b/board/nokia/rx51/rx51.c
index ceb4317901..84739ae129 100644
--- a/board/nokia/rx51/rx51.c
+++ b/board/nokia/rx51/rx51.c
@@ -415,6 +415,8 @@ int misc_init_r(void)
 
/* initialize twl4030 power managment */
twl4030_power_init();
+   twl4030_power_mmc_init(0);
+   twl4030_power_mmc_init(1);
 
/* set VSIM to 1.8V */
twl4030_pmrecv_vsel_cfg(TWL4030_PM_RECEIVER_VSIM_DEDICATED,
@@ -686,22 +688,23 @@ int rx51_kp_getc(struct stdio_dev *sdev)
return keybuf[keybuf_head++];
 }
 
-/*
- * Routine: board_mmc_init
- * Description: Initialize mmc devices.
- */
-int board_mmc_init(struct bd_info *bis)
-{
-   omap_mmc_init(0, 0, 0, -1, -1);
-   omap_mmc_init(1, 0, 0, -1, -1);
-   return 0;
-}
+static const struct mmc_config rx51_mmc_cfg = {
+   .host_caps = MMC_MODE_4BIT | MMC_MODE_HS_52MHz | MMC_MODE_HS,
+   .f_min = 40,
+   .f_max = 5200,
+   .b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT,
+   .voltages = MMC_VDD_32_33 | MMC_VDD_33_34 | MMC_VDD_165_195,
+};
 
-void board_mmc_power_init(void)
-{
-   twl4030_power_mmc_init(0);
-   twl4030_power_mmc_init(1);
-}
+static const struct omap_hsmmc_plat rx51_mmc[] = {
+   { rx51_mmc_cfg, (struct hsmmc *)OMAP_HSMMC1_BASE },
+   { rx51_mmc_cfg, (struct hsmmc *)OMAP_HSMMC2_BASE },
+};
+
+U_BOOT_DRVINFOS(rx51_mmc) = {
+   { "omap_hsmmc", &rx51_mmc[0] },
+   { "omap_hsmmc", &rx51_mmc[1] },
+};
 
 static const struct omap_i2c_plat rx51_i2c[] = {
{ I2C_BASE1, 10, OMAP_I2C_REV_V1 },
diff --git a/configs/nokia_rx51_defconfig b/configs/nokia_rx51_defconfig
index 30a02e2bc3..3b782715c7 100644
--- a/configs/nokia_rx51_defconfig
+++ b/configs/nokia_rx51_defconfig
@@ -4,6 +4,7 @@ CONFIG_ARCH_OMAP2PLUS=y
 CONFIG_SYS_TEXT_BASE=0x80008000
 CONFIG_NR_DRAM_BANKS=2
 CONFIG_TARGET_NOKIA_RX51=y
+# CONFIG_SYS_MALLOC_F is not set
 # CONFIG_TI_SYSC is not set
 # CONFIG_FIT is not set
 CONFIG_BOOTDELAY=30
@@ -36,6 +37,7 @@ CONFIG_CMD_MMC=y
 CONFIG_CMD_MTD=y
 CONFIG_CMD_ONENAND=y
 # CONFIG_CMD_SETEXPR is not set
+# CONFIG_CMD_SLEEP is not set
 CONFIG_CMD_EXT2=y
 CONFIG_CMD_EXT4=y
 CONFIG_CMD_FAT=y
@@ -45,9 +47,12 @@ CONFIG_ENV_OVERWRITE=y
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 # CONFIG_NET is not set
 CONFIG_DM=y
+# CONFIG_DM_DEVICE_REMOVE is not set
 CONFIG_DM_I2C=y
 CONFIG_TWL4030_LED=y
+CONFIG_DM_MMC=y
 # CONFIG_MMC_HW_PARTITIONING is not set
+# CONFIG_MMC_VERBOSE is not set
 CONFIG_MMC_OMAP_HS=y
 CONFIG_MTD=y
 CONFIG_CONS_INDEX=3
-- 
2.20.1

[PATCH] spi: zynqmp_gqspi: support dual and quad mode

[Brandon Maier]

The dm_spi_ops.xfer() API does not support dual and quad SPI modes. It
also doesn't allow the zynqmp_gqspi driver to calculate the correct
number of dummy cycles for some NOR ops (as doing so also requires the
buswidth).

Port the zynqmp_gqspi driver to spi_controller_mem_ops, which gives us
the buswidth values to correctly support all SNOR_PROTO_X_X_X commands
and to properly calculate dummy cycles.

Signed-off-by: Brandon Maier 
CC: ja...@amarulasolutions.com
CC: michal.si...@xilinx.com
---
 drivers/spi/zynqmp_gqspi.c | 164 -
 1 file changed, 70 insertions(+), 94 deletions(-)

diff --git a/drivers/spi/zynqmp_gqspi.c b/drivers/spi/zynqmp_gqspi.c
index efcbd0557f..e1fd551f68 100644
--- a/drivers/spi/zynqmp_gqspi.c
+++ b/drivers/spi/zynqmp_gqspi.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -171,8 +172,7 @@ struct zynqmp_qspi_priv {
unsigned int len;
int bytes_to_transfer;
int bytes_to_receive;
-   unsigned int is_inst;
-   unsigned int cs_change:1;
+   const struct spi_mem_op *op;
 };
 
 static int zynqmp_qspi_of_to_plat(struct udevice *bus)
@@ -221,6 +221,21 @@ static u32 zynqmp_qspi_bus_select(struct zynqmp_qspi_priv 
*priv)
return gqspi_fifo_reg;
 }
 
+static u32 zynqmp_qspi_genfifo_mode(u8 buswidth)
+{
+   switch (buswidth) {
+   case 1:
+   return GQSPI_SPI_MODE_SPI;
+   case 2:
+   return GQSPI_SPI_MODE_DUAL_SPI;
+   case 4:
+   return GQSPI_SPI_MODE_QSPI;
+   default:
+   debug("Unsupported bus width %u\n", buswidth);
+   return GQSPI_SPI_MODE_SPI;
+   }
+}
+
 static void zynqmp_qspi_fill_gen_fifo(struct zynqmp_qspi_priv *priv,
  u32 gqspi_fifo_reg)
 {
@@ -445,21 +460,42 @@ static int zynqmp_qspi_fill_tx_fifo(struct 
zynqmp_qspi_priv *priv, u32 size)
 
 static void zynqmp_qspi_genfifo_cmd(struct zynqmp_qspi_priv *priv)
 {
+   const struct spi_mem_op *op = priv->op;
u32 gen_fifo_cmd;
-   u32 bytecount = 0;
+   u8 i, dummy_cycles, addr;
+
+   /* Send opcode */
+   gen_fifo_cmd = zynqmp_qspi_bus_select(priv);
+   gen_fifo_cmd |= zynqmp_qspi_genfifo_mode(op->cmd.buswidth);
+   gen_fifo_cmd |= GQSPI_GFIFO_TX;
+   gen_fifo_cmd |= op->cmd.opcode;
+   zynqmp_qspi_fill_gen_fifo(priv, gen_fifo_cmd);
+
+   /* Send address */
+   for (i = 0; i < op->addr.nbytes; i++) {
+   addr = op->addr.val >> (8 * (op->addr.nbytes - i - 1));
 
-   while (priv->len) {
gen_fifo_cmd = zynqmp_qspi_bus_select(priv);
-   gen_fifo_cmd |= GQSPI_GFIFO_TX | GQSPI_SPI_MODE_SPI;
-   gen_fifo_cmd |= *(u8 *)priv->tx_buf;
-   bytecount++;
-   priv->len--;
-   priv->tx_buf = (u8 *)priv->tx_buf + 1;
+   gen_fifo_cmd |= zynqmp_qspi_genfifo_mode(op->addr.buswidth);
+   gen_fifo_cmd |= GQSPI_GFIFO_TX;
+   gen_fifo_cmd |= addr;
 
debug("GFIFO_CMD_Cmd = 0x%x\n", gen_fifo_cmd);
 
zynqmp_qspi_fill_gen_fifo(priv, gen_fifo_cmd);
}
+
+   /* Send dummy */
+   if (op->dummy.nbytes) {
+   dummy_cycles = op->dummy.nbytes * 8 / op->dummy.buswidth;
+
+   gen_fifo_cmd = zynqmp_qspi_bus_select(priv);
+   gen_fifo_cmd |= zynqmp_qspi_genfifo_mode(op->dummy.buswidth);
+   gen_fifo_cmd &= ~(GQSPI_GFIFO_TX | GQSPI_GFIFO_RX);
+   gen_fifo_cmd |= GQSPI_GFIFO_DATA_XFR_MASK;
+   gen_fifo_cmd |= dummy_cycles;
+   zynqmp_qspi_fill_gen_fifo(priv, gen_fifo_cmd);
+   }
 }
 
 static u32 zynqmp_qspi_calc_exp(struct zynqmp_qspi_priv *priv,
@@ -496,11 +532,10 @@ static int zynqmp_qspi_genfifo_fill_tx(struct 
zynqmp_qspi_priv *priv)
int ret = 0;
 
gen_fifo_cmd = zynqmp_qspi_bus_select(priv);
+   gen_fifo_cmd |= zynqmp_qspi_genfifo_mode(priv->op->data.buswidth);
gen_fifo_cmd |= GQSPI_GFIFO_TX |
GQSPI_GFIFO_DATA_XFR_MASK;
 
-   gen_fifo_cmd |= GQSPI_SPI_MODE_SPI;
-
while (priv->len) {
len = zynqmp_qspi_calc_exp(priv, &gen_fifo_cmd);
zynqmp_qspi_fill_gen_fifo(priv, gen_fifo_cmd);
@@ -574,11 +609,10 @@ static int zynqmp_qspi_genfifo_fill_rx(struct 
zynqmp_qspi_priv *priv)
u32 actuallen = priv->len;
 
gen_fifo_cmd = zynqmp_qspi_bus_select(priv);
+   gen_fifo_cmd |= zynqmp_qspi_genfifo_mode(priv->op->data.buswidth);
gen_fifo_cmd |= GQSPI_GFIFO_RX |
GQSPI_GFIFO_DATA_XFR_MASK;
 
-   gen_fifo_cmd |= GQSPI_SPI_MODE_SPI;
-
/*
 * Check if receive buffer is aligned to 4 byte and length
 * is multiples of four byte as we are using dma to receive.
@@ -595,62 +629,6 @@ static int zynqmp_qspi_genfifo_fill_rx(struct 
zynqmp_qspi_priv *priv)
return zynqmp_q

[PATCH] mtd: spi-nor-ids: add support for Micron mt25ql02g

[Brandon Maier]

From: Taylor Burton 

Micron's mt25ql02g is not currently supported in
U-Boot, but is in Linux. Linux already has this flash
present in its table. A snippet below:

{ "mt25ql02g",   INFO(0x20ba22, 0, 64 * 1024, 4096...},

Signed-off-by: Taylor Burton 
Signed-off-by: Brandon Maier 
CC: Jagan Teki 
CC: Vignesh R 
---
 drivers/mtd/spi/spi-nor-ids.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 5bd5dd3003..b1f7a1cf81 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -187,6 +187,7 @@ const struct flash_info spi_nor_ids[] = {
{ INFO("n25q00a", 0x20bb21, 0, 64 * 1024, 2048, SECT_4K | USE_FSR | 
SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
{ INFO("mt25ql01g",   0x21ba20, 0, 64 * 1024, 2048, SECT_4K | USE_FSR | 
SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
{ INFO("mt25qu02g",   0x20bb22, 0, 64 * 1024, 4096, SECT_4K | USE_FSR | 
SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
+   { INFO("mt25ql02g",   0x20ba22, 0, 64 * 1024, 4096, SECT_4K | USE_FSR | 
SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
{ INFO("mt35xu512aba", 0x2c5b1a, 0,  128 * 1024,  512, USE_FSR | 
SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES) },
{ INFO("mt35xu02g",  0x2c5b1c, 0, 128 * 1024,  2048, USE_FSR | 
SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES) },
 #endif
-- 
2.29.1

Re: [meta-freescale] MTD UBI undefined reference failed to build OE gatesgarth branch

[Andrey Zhizhikin]

Hello Jupiter,

On Fri, Jan 15, 2021 at 8:32 PM JH  wrote:
>
> Hello,
>
> The mtd build was fine, what could be missing not to link mtd?
>
> $ ls 2020.04-r0/build/mx6ull_14x14_evk_nand_config/drivers/mtd

>From all the build logs you have, it look to me that you're trying to
build the U-Boot delivered by NXP as a part of their BSP release.

In this case, I suggest you'd rather contact NXP support in order to
address this failure, since it is a vendor BSP you're trying to
upgrade.

In addition, I do not think that all mailing lists you've cross-posted
your question to would be able to help you here:
- linux-mtd list is not really appropriate to solve U-Boot build issues;
- u-boot list is for upstream U-Boot patches and discussions, which is
way past over 2020.04 version (not even considering that you're
building U-Boot from NXP fork);
- oe-core is not a proper list to post questions specific to one SOC vendor;
- meta-freescale 'gatesgarth' branch does not have any U-Boot build
configuration for mx6ull_14x14_evk_nand_config, the only available
build config provided is for sd card;

Having all those points above, I'd suggest you contact NXP support at
first to see if they can solve those build errors for you.

If you would find a solution, you can send a PR to meta-freescale to
address it - this would be much appreciated.

>
> built-in.o  mtdcore.su  mtdpart.o   mtd_uboot.o   mtd-uclass.o   nand spi
> mtdcore.o   mtd.o   mtdpart.su  mtd_uboot.su  mtd-uclass.su  onenand  ubi
>
>
>
> On 1/15/21, Jupiter  wrote:
> > Hello,
> >
> > I was able to build MTD, UBI and u-boot on OE version Zeus branch, but
> > failed in gatesgarth branch. Here are errors, what could I be missing?
> >
> > u-boot-imx/2020.04-r0/git/cmd/ubi.c:478: undefined reference to
> > `mtd_probe_devices'
> > u-boot-imx/2020.04-r0/git/cmd/ubi.c:484: undefined reference to
> > `put_mtd_device'
> > u-boot-imx/2020.04-r0/git/drivers/mtd/ubi/build.c:1161: undefined
> > reference to `put_mtd_device'
> > u-boot-imx/2020.04-r0/git/drivers/mtd/ubi/build.c:1229: undefined
> > reference to `get_mtd_device_nm'
> > u-boot-imx/2020.04-r0/git/drivers/mtd/ubi/io.c:1407: undefined
> > reference to `mtd_read'
> > u-boot-imx/2020.04-r0/git/drivers/mtd/ubi/io.c:279: undefined
> > reference to `mtd_write'
> >
> > u-boot-imx/2020.04-r0/git/drivers/video/cfb_console.c:2025: undefined
> > reference to `video_hw_init'
> > u-boot-imx/2020.04-r0/git/drivers/gpio/74x164_gpio.c:51: undefined
> > reference to `dm_spi_claim_bus'
> > u-boot-imx/2020.04-r0/git/drivers/gpio/74x164_gpio.c:55: undefined
> > reference to `dm_spi_xfer'
> > u-boot-imx/2020.04-r0/git/drivers/gpio/74x164_gpio.c:58: undefined
> > reference to `dm_spi_release_bus'
> > u-boot-imx/2020.04-r0/git/Makefile:1701: recipe for target 'u-boot' failed
> > make[1]: *** [u-boot] Error 1
> > WARNING: exit code 1 from a shell command.
> >
> > There are a couple of warning messages I am not sure if they are
> > important or just nonsense, like CONFIG_DEFAULT_DEVICE_TREE has
> > already been defined but it complained:
> >
> > Device Tree Source is not correctly specified.
> > Please define 'CONFIG_DEFAULT_DEVICE_TREE'
> > or build with 'DEVICE_TREE=' argument
> >
> > u-boot-imx/2020.04-r0/git/drivers/gpio/74x164_gpio.c:51:8: warning:
> > implicit declaration of function 'dm_spi_claim_bus'; did you mean
> > 'spi_claim_bus'? [-Wimplicit-function-declaration]
> >51 |  ret = dm_spi_claim_bus(dev);
> >   |^~~~
> >   |spi_claim_bus
> > @
> > u-boot-imx/2020.04-r0/git/drivers/gpio/74x164_gpio.c:55:8: warning:
> > implicit declaration of function 'dm_spi_xfer'; did you mean
> > 'spi_xfer'? [-Wimplicit-function-declaration]
> >55 |  ret = dm_spi_xfer(dev, priv->nregs * 8, priv->buffer, NULL,
> >   |^~~
> >   |spi_xfer
> > u-boot-imx/2020.04-r0/git/drivers/gpio/74x164_gpio.c:58:2: warning:
> > implicit declaration of function 'dm_spi_release_bus'; did you mean
> > 'spi_release_bus'? [-Wimplicit-function-declaration]
> >58 |  dm_spi_release_bus(dev);
> >   |  ^~
> >   |  spi_release_bus
> >
> > Appreciate your advice.
> >
> > Thank you very much.
> >
> > Kind regards,
> >
> > - jupiter
> >
>
>
> --
> "A man can fail many times, but he isn't a failure until he begins to
> blame somebody else."
> -- John Burroughs
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#24489): 
> https://lists.yoctoproject.org/g/meta-freescale/message/24489
> Mute This Topic: https://lists.yoctoproject.org/mt/79697340/3617192
> Group Owner: meta-freescale+ow...@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/meta-freescale/unsub 
> [andre...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>


-- 
Regards,
Andrey.

Re: [meta-freescale] MTD UBI undefined reference failed to build OE gatesgarth branch

[Jupiter]

Thanks for your response.

I am sorry, I thought that is what meta-freescale for, right? NXP
might involve the coding, but is it integrated and released by Yocto /
OE https://git.yoctoproject.org/cgit/cgit.cgi/meta-freescale/, right?
I cloned meta-freescale from Yocto project:
git://git.yoctoproject.org/meta-freescale, I am sorry, I really lost.

Re: [PATCH 2/2] efi_loader: make the UEFI boot manager configurable

[Heinrich Schuchardt]

On 1/15/21 7:43 PM, Tom Rini wrote:

On Fri, Jan 15, 2021 at 07:02:50PM +0100, Heinrich Schuchardt wrote:


Some boards are very tight on the binary size. Booting via UEFI is possible
without using the boot manager.


While I don't think we need to re-word this part, for the record my
concern is global, not specific platforms.  To re-iterate something we
talked about on IRC, I think it's important to be able to select and
have a default UEFI implementation that covers as many common use cases
as possible, while also being as small as possible.



Provide a configuration option to make the boot manager available.

Signed-off-by: Heinrich Schuchardt 

[snip]

+config CMD_BOOTEFI_BOOTMGR
+   bool "UEFI Boot Manager"
+   default y
+   help
+ Select this option if you want to select the UEFI binary to be booted
+ via UEFI variables Boot, BootOrder, and BootNext. This enables the
+ 'bootefi bootmgr' command.


I'm not sure this should be default y.  My concern is that the default
set of options is growing so that every possible case has support in the
binary but the hardware and practical use means we don't need all of
that.  This should perhaps be "default y if DISTRO_DEFAULTS" at least.


If you want to default something to no, I think that
EFI_UNICODE_CAPITALIZATION is a better candidate.

On wandboard_defconfig:

683976 - 680228 = 3748 bytes saved.

Best regards

Heinrich

Re: [PATCH] dm: fix build errors generated by last merges

[Tom Rini]

On Fri, Jan 15, 2021 at 09:10:26AM +0100, Dario Binacchi wrote:

> Something was wrong in the merge process into the mainline.
> Some added patches access driver structure fields and functions that
> have been modified by previous patches.
> The patch renames:
>  - dev_get_platdata to dev_get_plat
>  - dev_get_uclass_platdata to dev_get_uclass_plat
>  - ofdata_to_platdata to of_to_plat
>  - plat_data_alloc_size to plat_auto
>  - priv_auto_alloc_size to priv_auto
>  - video_uc_platdata to video_uc_plat
> 
> Signed-off-by: Dario Binacchi 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] efi_loader: Enable run-time variable support for tee based variables

[Andreas Schwab]

On Jan 15 2021, Ilias Apalodimas wrote:

> Anyway removing -fpic should work as well, but I'd rather do this [1],
> instead of relying on linker flags.

It's not the linker that breaks this, but the compiler, by forcing GOT
addressing.  And it can easily break again any time.

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [PATCH] efi_loader: Avoid emitting efi_var_buf to .GOT

[Atish Patra]

On Fri, Jan 15, 2021 at 8:00 AM Ilias Apalodimas
 wrote:
>
> Atish reports than on RISC-V, accessing the EFI variables causes
> a kernel panic. An objdump of the file verifies that, since the
> global pointer for efi_var_buf ends up in .GOT section which is
> not mapped in virtual address space for Linux.
>
> 
>
> 0084 :
>   84:   715daddisp,sp,-80
>
> * objdump -dr
> 0086 <.LCFI2>:
>   86:   e0a2sd  s0,64(sp)
>   88:   fc26sd  s1,56(sp)
>   8a:   e486sd  ra,72(sp)
>   8c:   f84asd  s2,48(sp)
>   8e:   f44esd  s3,40(sp)
>   90:   f052sd  s4,32(sp)
>   92:   ec56sd  s5,24(sp)
>   94:   0497auipc   s1,0x0
> 94: R_RISCV_GOT_HI20efi_var_buf
>   98:   0004b483ld  s1,0(s1) # 94 <.LCFI2+0xe>
> 98: R_RISCV_PCREL_LO12_I.L0
> 98: R_RISCV_RELAX   *ABS*
>
> * objdump -t
> 0084 g F .text.efi_runtime  00b8 efi_var_mem_find
>
> With the patch applied:
>
> * objdump -dr
> 0086 <.LCFI2>:
>   86:   e0a2sd  s0,64(sp)
>   88:   fc26sd  s1,56(sp)
>   8a:   e486sd  ra,72(sp)
>   8c:   f84asd  s2,48(sp)
>   8e:   f44esd  s3,40(sp)
>   90:   f052sd  s4,32(sp)
>   92:   ec56sd  s5,24(sp)
>   94:   0497auipc   s1,0x0
> 94: R_RISCV_PCREL_HI20  .LANCHOR0
> 94: R_RISCV_RELAX   *ABS*
>   98:   00048493mv  s1,s1
> 98: R_RISCV_PCREL_LO12_I.L0
> 98: R_RISCV_RELAX   *ABS*
>
> * objdump -t
> 0008 l O .data.efi_runtime  0008 efi_var_buf
>
> On arm64 this works, because there's no .GOT entries for this
> and everything is converted to relative references.
>

Just curious to know: Is it because of linker script magic or compiler
optimization ?
I might have missed something but I did not find anything relevant in
the arm64 linker scripts.

> * objdump -dr (identical pre-post patch, only the new function shows up)
> 00b4 :
>   b4:   aa0003eemov x14, x0
>   b8:   900aadrpx10, 0 
> b8: R_AARCH64_ADR_PREL_PG_HI21  .data.efi_runtime
>   bc:   91000140add x0, x10, #0x0
> bc: R_AARCH64_ADD_ABS_LO12_NC   .data.efi_runtime
>   c0:   aa0103edmov x13, x1
>   c4:   79400021ldrhw1, [x1]
>   c8:   aa0203ebmov x11, x2
>   cc:   f9400400ldr x0, [x0, #8]
>   d0:   b940100cldr w12, [x0, #16]
>   d4:   8b0c000cadd x12, x0, x12
>
> So let's switch efi_var_buf to static and create a helper function for
> anyone that needs to update it.
>
> Fixes: e01aed47d6a0 ("efi_loader: Enable run-time variable support for tee 
> based variables")
> Reported-by: Atish Patra 
> Signed-off-by: Ilias Apalodimas 
> ---
> Atish can you give it a spin and let me know if this fixes the issue for you?
> The objdump seems to be correct now, but I am not familiar with RISC-V.
> No regressions on Arm with TEE or memory backed variables.
>  include/efi_variable.h| 12 
>  lib/efi_loader/efi_var_mem.c  | 12 +++-
>  lib/efi_loader/efi_variable_tee.c |  2 +-
>  3 files changed, 24 insertions(+), 2 deletions(-)
>
> diff --git a/include/efi_variable.h b/include/efi_variable.h
> index 4704a3c16e65..b2317eb7bf1c 100644
> --- a/include/efi_variable.h
> +++ b/include/efi_variable.h
> @@ -306,4 +306,16 @@ efi_status_t __efi_runtime EFIAPI
>  efi_get_next_variable_name_runtime(efi_uintn_t *variable_name_size,
>u16 *variable_name, efi_guid_t *guid);
>
> +/**
> + * efi_var_buf_update() - Update the value of efi_var_buf in efi_var_mem.c
> + *
> + * @var_buf:   Source buffer
> + *
> + * efi_var_buf is special since we use it on Runtime Services. We need
> + * to keep it static in efi_var_mem.c and avoid having it pulled into
> + * .GOT. Since it has to be static this function must be used to update
> + * it
> + */
> +void efi_var_buf_update(struct efi_var_file *var_buf);
> +
>  #endif
> diff --git a/lib/efi_loader/efi_var_mem.c b/lib/efi_loader/efi_var_mem.c
> index d155f25f60e6..fcf0043b5d3b 100644
> --- a/lib/efi_loader/efi_var_mem.c
> +++ b/lib/efi_loader/efi_var_mem.c
> @@ -10,7 +10,12 @@
>  #include 
>  #include 
>
> -struct efi_var_file __efi_runtime_data *efi_var_buf;
> +/*
> + * keep efi_var_buf as static , moving it out might move it to .got
> + * which is not mapped in virtual address for Linux. Whenever
> + * we try to invoke get_variable service, it will panic.
> + */
> +static struct efi_var_file __efi_runtime_data *efi_var_buf;
>  static struct efi_var_entry __efi_runtime_data *efi_current_var;
>
>  /**
> @@ -339,3 +344,8 @@ efi_get_next_variable_name_mem(efi_uintn_t 
> *variable_name_size,
>
>

Re: MTD UBI undefined reference failed to build OE gatesgarth branch

[Jupiter]

Hello,

The mtd build was fine, what could be missing not to link mtd?

$ ls 2020.04-r0/build/mx6ull_14x14_evk_nand_config/drivers/mtd

built-in.o  mtdcore.su  mtdpart.o   mtd_uboot.o   mtd-uclass.o   nand spi
mtdcore.o   mtd.o   mtdpart.su  mtd_uboot.su  mtd-uclass.su  onenand  ubi



On 1/15/21, Jupiter  wrote:
> Hello,
>
> I was able to build MTD, UBI and u-boot on OE version Zeus branch, but
> failed in gatesgarth branch. Here are errors, what could I be missing?
>
> u-boot-imx/2020.04-r0/git/cmd/ubi.c:478: undefined reference to
> `mtd_probe_devices'
> u-boot-imx/2020.04-r0/git/cmd/ubi.c:484: undefined reference to
> `put_mtd_device'
> u-boot-imx/2020.04-r0/git/drivers/mtd/ubi/build.c:1161: undefined
> reference to `put_mtd_device'
> u-boot-imx/2020.04-r0/git/drivers/mtd/ubi/build.c:1229: undefined
> reference to `get_mtd_device_nm'
> u-boot-imx/2020.04-r0/git/drivers/mtd/ubi/io.c:1407: undefined
> reference to `mtd_read'
> u-boot-imx/2020.04-r0/git/drivers/mtd/ubi/io.c:279: undefined
> reference to `mtd_write'
>
> u-boot-imx/2020.04-r0/git/drivers/video/cfb_console.c:2025: undefined
> reference to `video_hw_init'
> u-boot-imx/2020.04-r0/git/drivers/gpio/74x164_gpio.c:51: undefined
> reference to `dm_spi_claim_bus'
> u-boot-imx/2020.04-r0/git/drivers/gpio/74x164_gpio.c:55: undefined
> reference to `dm_spi_xfer'
> u-boot-imx/2020.04-r0/git/drivers/gpio/74x164_gpio.c:58: undefined
> reference to `dm_spi_release_bus'
> u-boot-imx/2020.04-r0/git/Makefile:1701: recipe for target 'u-boot' failed
> make[1]: *** [u-boot] Error 1
> WARNING: exit code 1 from a shell command.
>
> There are a couple of warning messages I am not sure if they are
> important or just nonsense, like CONFIG_DEFAULT_DEVICE_TREE has
> already been defined but it complained:
>
> Device Tree Source is not correctly specified.
> Please define 'CONFIG_DEFAULT_DEVICE_TREE'
> or build with 'DEVICE_TREE=' argument
>
> u-boot-imx/2020.04-r0/git/drivers/gpio/74x164_gpio.c:51:8: warning:
> implicit declaration of function 'dm_spi_claim_bus'; did you mean
> 'spi_claim_bus'? [-Wimplicit-function-declaration]
>51 |  ret = dm_spi_claim_bus(dev);
>   |^~~~
>   |spi_claim_bus
> @
> u-boot-imx/2020.04-r0/git/drivers/gpio/74x164_gpio.c:55:8: warning:
> implicit declaration of function 'dm_spi_xfer'; did you mean
> 'spi_xfer'? [-Wimplicit-function-declaration]
>55 |  ret = dm_spi_xfer(dev, priv->nregs * 8, priv->buffer, NULL,
>   |^~~
>   |spi_xfer
> u-boot-imx/2020.04-r0/git/drivers/gpio/74x164_gpio.c:58:2: warning:
> implicit declaration of function 'dm_spi_release_bus'; did you mean
> 'spi_release_bus'? [-Wimplicit-function-declaration]
>58 |  dm_spi_release_bus(dev);
>   |  ^~
>   |  spi_release_bus
>
> Appreciate your advice.
>
> Thank you very much.
>
> Kind regards,
>
> - jupiter
>


--
"A man can fail many times, but he isn't a failure until he begins to
blame somebody else."
-- John Burroughs

Re: [PATCH] efi_loader: Avoid emitting efi_var_buf to .GOT

[Atish Patra]

On Fri, Jan 15, 2021 at 11:11 AM Ilias Apalodimas
 wrote:
>
> Hi Heinrich,
>
> [...]
> > > Atish can you give it a spin and let me know if this fixes the issue for 
> > > you?
> > > The objdump seems to be correct now, but I am not familiar with RISC-V.
> > > No regressions on Arm with TEE or memory backed variables.
> > >  include/efi_variable.h| 12 
> > >  lib/efi_loader/efi_var_mem.c  | 12 +++-
> > >  lib/efi_loader/efi_variable_tee.c |  2 +-
> > >  3 files changed, 24 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/include/efi_variable.h b/include/efi_variable.h
> > > index 4704a3c16e65..b2317eb7bf1c 100644
> > > --- a/include/efi_variable.h
> > > +++ b/include/efi_variable.h
> > > @@ -306,4 +306,16 @@ efi_status_t __efi_runtime EFIAPI
> > >  efi_get_next_variable_name_runtime(efi_uintn_t *variable_name_size,
> > >u16 *variable_name, efi_guid_t *guid);
> > >
> > > +/**
> > > + * efi_var_buf_update() - Update the value of efi_var_buf in 
> > > efi_var_mem.c
> >
> > Dear Ilias,
> >
> > thank you for addressing this problem. The code looks fine to me. Just
> > some ideas concerning comment lines:
>
> Well, I broke it to begin with so ...
>
> >
> > The value of efi_var_buf is the address it is pointing to. So i would
> > prefer:
> >
> > efi_var_buf_update() - udpate memory buffer for variables
> >
> > > + *
> > > + * @var_buf:   Source buffer
> >
> > %s/Source/source/
> >
>
> Ok
>
> > > + *
> > > + * efi_var_buf is special since we use it on Runtime Services. We need
> > > + * to keep it static in efi_var_mem.c and avoid having it pulled into
> > > + * .GOT. Since it has to be static this function must be used to update
> >
> > You already place a comment about .GOT where the declaration is. Here
> > describing how the function is used would be of interest. E.g.
> >
> > "This function copies to the memory buffer for UEFI variables. Call this
> > function in ExitBootServices() if memory backed variables are only used
> > at runtime to fill the buffer."
> >
>
> I'll replace it. Guess I was too concerned pointing out "Don't touch 
> efi_var_buf"
>
> > > + * it
> > > + */
> > > +void efi_var_buf_update(struct efi_var_file *var_buf);
> > > +
> > >  #endif
> > > diff --git a/lib/efi_loader/efi_var_mem.c b/lib/efi_loader/efi_var_mem.c
> > > index d155f25f60e6..fcf0043b5d3b 100644
> > > --- a/lib/efi_loader/efi_var_mem.c
> > > +++ b/lib/efi_loader/efi_var_mem.c
> > > @@ -10,7 +10,12 @@
> > >  #include 
> > >  #include 
> > >
> > > -struct efi_var_file __efi_runtime_data *efi_var_buf;
> > > +/*
> > > + * keep efi_var_buf as static , moving it out might move it to .got
> > > + * which is not mapped in virtual address for Linux. Whenever
> > > + * we try to invoke get_variable service, it will panic.
> >
> > Not everybody will know the abbreviation .got. How about:
> >
> > "The variables efi_var_file and efi_var_entry must be static to avoid
> > that they are referenced via the global offset table (section .got). The
> > GOT is neither mapped as EfiRuntimeServicesData nor do we support its
> > relocation during SetVirtualAddressMap()."
> >
>
> Sure
>
> > Otherwise
>
> I'll wait for Atish to verify it fixes RISC-V, because it makes no difference
> whatsoever in arm and send a v2.
>

Thanks for the quick fix. With this patch, I don't see the panic anymore.
Tested-by: Atish Patra 

> Thanks
> /Ilias
> >
> > Reviewed-by: Heinrich Schuchardt 
>
> [...]



-- 
Regards,
Atish

Re: [PATCH] efi_loader: Avoid emitting efi_var_buf to .GOT

[Ilias Apalodimas]

Hi Heinrich, 

[...]
> > Atish can you give it a spin and let me know if this fixes the issue for 
> > you?
> > The objdump seems to be correct now, but I am not familiar with RISC-V.
> > No regressions on Arm with TEE or memory backed variables.
> >  include/efi_variable.h| 12 
> >  lib/efi_loader/efi_var_mem.c  | 12 +++-
> >  lib/efi_loader/efi_variable_tee.c |  2 +-
> >  3 files changed, 24 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/efi_variable.h b/include/efi_variable.h
> > index 4704a3c16e65..b2317eb7bf1c 100644
> > --- a/include/efi_variable.h
> > +++ b/include/efi_variable.h
> > @@ -306,4 +306,16 @@ efi_status_t __efi_runtime EFIAPI
> >  efi_get_next_variable_name_runtime(efi_uintn_t *variable_name_size,
> >u16 *variable_name, efi_guid_t *guid);
> >
> > +/**
> > + * efi_var_buf_update() - Update the value of efi_var_buf in efi_var_mem.c
> 
> Dear Ilias,
> 
> thank you for addressing this problem. The code looks fine to me. Just
> some ideas concerning comment lines:

Well, I broke it to begin with so ...

> 
> The value of efi_var_buf is the address it is pointing to. So i would
> prefer:
> 
> efi_var_buf_update() - udpate memory buffer for variables
> 
> > + *
> > + * @var_buf:   Source buffer
> 
> %s/Source/source/
> 

Ok

> > + *
> > + * efi_var_buf is special since we use it on Runtime Services. We need
> > + * to keep it static in efi_var_mem.c and avoid having it pulled into
> > + * .GOT. Since it has to be static this function must be used to update
> 
> You already place a comment about .GOT where the declaration is. Here
> describing how the function is used would be of interest. E.g.
> 
> "This function copies to the memory buffer for UEFI variables. Call this
> function in ExitBootServices() if memory backed variables are only used
> at runtime to fill the buffer."
> 

I'll replace it. Guess I was too concerned pointing out "Don't touch 
efi_var_buf"

> > + * it
> > + */
> > +void efi_var_buf_update(struct efi_var_file *var_buf);
> > +
> >  #endif
> > diff --git a/lib/efi_loader/efi_var_mem.c b/lib/efi_loader/efi_var_mem.c
> > index d155f25f60e6..fcf0043b5d3b 100644
> > --- a/lib/efi_loader/efi_var_mem.c
> > +++ b/lib/efi_loader/efi_var_mem.c
> > @@ -10,7 +10,12 @@
> >  #include 
> >  #include 
> >
> > -struct efi_var_file __efi_runtime_data *efi_var_buf;
> > +/*
> > + * keep efi_var_buf as static , moving it out might move it to .got
> > + * which is not mapped in virtual address for Linux. Whenever
> > + * we try to invoke get_variable service, it will panic.
> 
> Not everybody will know the abbreviation .got. How about:
> 
> "The variables efi_var_file and efi_var_entry must be static to avoid
> that they are referenced via the global offset table (section .got). The
> GOT is neither mapped as EfiRuntimeServicesData nor do we support its
> relocation during SetVirtualAddressMap()."
> 

Sure

> Otherwise

I'll wait for Atish to verify it fixes RISC-V, because it makes no difference
whatsoever in arm and send a v2. 

Thanks
/Ilias
> 
> Reviewed-by: Heinrich Schuchardt 

[...]

Re: [PATCH v8] Add support for stack-protector

[Heinrich Schuchardt]

On 14.01.21 21:35, Joel Peshkin wrote:
> Add support for stack protector for UBOOT, SPL, and TPL
> as well as new pytest for stackprotector
>
> Signed-off-by: Joel Peshkin 
> ---
> Cc: Simon Glass 
> Cc: Heinrich Schuchardt 

Reviewed-by: Heinrich Schuchardt 

>
> Changes for v8:
>- Fix commit message
>- Force canary to UL type
> Changes for v7:
>- Fix commit message
>- add __builtin_extract_return_addr() calls
> Changes for v6:
>- Fix commit message
> Changes for v5:
>- Rebase
> Changes for v4:
>- Exclude EFI from stackprotector
>- Cleanups of extra includes and declaration
> Changes for v3:
>- Move test command to cmd/
>- Update Kconfig names and depends
>- clean up default canary initialization
> Changes for v2:
>- Add test command and corresponding config
>- Fixed incorrect description in Kconfig
>- Add unit test

Re: [PATCH] efi_loader: Avoid emitting efi_var_buf to .GOT

[Heinrich Schuchardt]

On 15.01.21 17:00, Ilias Apalodimas wrote:
> Atish reports than on RISC-V, accessing the EFI variables causes
> a kernel panic. An objdump of the file verifies that, since the
> global pointer for efi_var_buf ends up in .GOT section which is
> not mapped in virtual address space for Linux.
>
> 
>
> 0084 :
>   84:   715daddisp,sp,-80
>
> * objdump -dr
> 0086 <.LCFI2>:
>   86:   e0a2sd  s0,64(sp)
>   88:   fc26sd  s1,56(sp)
>   8a:   e486sd  ra,72(sp)
>   8c:   f84asd  s2,48(sp)
>   8e:   f44esd  s3,40(sp)
>   90:   f052sd  s4,32(sp)
>   92:   ec56sd  s5,24(sp)
>   94:   0497auipc   s1,0x0
> 94: R_RISCV_GOT_HI20efi_var_buf
>   98:   0004b483ld  s1,0(s1) # 94 <.LCFI2+0xe>
> 98: R_RISCV_PCREL_LO12_I.L0
> 98: R_RISCV_RELAX   *ABS*
>
> * objdump -t
> 0084 g F .text.efi_runtime  00b8 efi_var_mem_find
>
> With the patch applied:
>
> * objdump -dr
> 0086 <.LCFI2>:
>   86:   e0a2sd  s0,64(sp)
>   88:   fc26sd  s1,56(sp)
>   8a:   e486sd  ra,72(sp)
>   8c:   f84asd  s2,48(sp)
>   8e:   f44esd  s3,40(sp)
>   90:   f052sd  s4,32(sp)
>   92:   ec56sd  s5,24(sp)
>   94:   0497auipc   s1,0x0
> 94: R_RISCV_PCREL_HI20  .LANCHOR0
> 94: R_RISCV_RELAX   *ABS*
>   98:   00048493mv  s1,s1
> 98: R_RISCV_PCREL_LO12_I.L0
> 98: R_RISCV_RELAX   *ABS*
>
> * objdump -t
> 0008 l O .data.efi_runtime  0008 efi_var_buf
>
> On arm64 this works, because there's no .GOT entries for this
> and everything is converted to relative references.
>
> * objdump -dr (identical pre-post patch, only the new function shows up)
> 00b4 :
>   b4:   aa0003eemov x14, x0
>   b8:   900aadrpx10, 0 
> b8: R_AARCH64_ADR_PREL_PG_HI21  .data.efi_runtime
>   bc:   91000140add x0, x10, #0x0
> bc: R_AARCH64_ADD_ABS_LO12_NC   .data.efi_runtime
>   c0:   aa0103edmov x13, x1
>   c4:   79400021ldrhw1, [x1]
>   c8:   aa0203ebmov x11, x2
>   cc:   f9400400ldr x0, [x0, #8]
>   d0:   b940100cldr w12, [x0, #16]
>   d4:   8b0c000cadd x12, x0, x12
>
> So let's switch efi_var_buf to static and create a helper function for
> anyone that needs to update it.
>
> Fixes: e01aed47d6a0 ("efi_loader: Enable run-time variable support for tee 
> based variables")
> Reported-by: Atish Patra 
> Signed-off-by: Ilias Apalodimas 
> ---
> Atish can you give it a spin and let me know if this fixes the issue for you?
> The objdump seems to be correct now, but I am not familiar with RISC-V.
> No regressions on Arm with TEE or memory backed variables.
>  include/efi_variable.h| 12 
>  lib/efi_loader/efi_var_mem.c  | 12 +++-
>  lib/efi_loader/efi_variable_tee.c |  2 +-
>  3 files changed, 24 insertions(+), 2 deletions(-)
>
> diff --git a/include/efi_variable.h b/include/efi_variable.h
> index 4704a3c16e65..b2317eb7bf1c 100644
> --- a/include/efi_variable.h
> +++ b/include/efi_variable.h
> @@ -306,4 +306,16 @@ efi_status_t __efi_runtime EFIAPI
>  efi_get_next_variable_name_runtime(efi_uintn_t *variable_name_size,
>  u16 *variable_name, efi_guid_t *guid);
>
> +/**
> + * efi_var_buf_update() - Update the value of efi_var_buf in efi_var_mem.c

Dear Ilias,

thank you for addressing this problem. The code looks fine to me. Just
some ideas concerning comment lines:

The value of efi_var_buf is the address it is pointing to. So i would
prefer:

efi_var_buf_update() - udpate memory buffer for variables

> + *
> + * @var_buf: Source buffer

%s/Source/source/

> + *
> + * efi_var_buf is special since we use it on Runtime Services. We need
> + * to keep it static in efi_var_mem.c and avoid having it pulled into
> + * .GOT. Since it has to be static this function must be used to update

You already place a comment about .GOT where the declaration is. Here
describing how the function is used would be of interest. E.g.

"This function copies to the memory buffer for UEFI variables. Call this
function in ExitBootServices() if memory backed variables are only used
at runtime to fill the buffer."

> + * it
> + */
> +void efi_var_buf_update(struct efi_var_file *var_buf);
> +
>  #endif
> diff --git a/lib/efi_loader/efi_var_mem.c b/lib/efi_loader/efi_var_mem.c
> index d155f25f60e6..fcf0043b5d3b 100644
> --- a/lib/efi_loader/efi_var_mem.c
> +++ b/lib/efi_loader/efi_var_mem.c
> @@ -10,7 +10,12 @@
>  #include 
>  #include 
>
> -struct efi_var_file __efi_runtime_data *efi_var_buf;
> +/*
> + * keep efi_var_buf as static , moving it out migh

Re: [PATCH 2/2] efi_loader: make the UEFI boot manager configurable

[Tom Rini]

On Fri, Jan 15, 2021 at 07:02:50PM +0100, Heinrich Schuchardt wrote:

> Some boards are very tight on the binary size. Booting via UEFI is possible
> without using the boot manager.

While I don't think we need to re-word this part, for the record my
concern is global, not specific platforms.  To re-iterate something we
talked about on IRC, I think it's important to be able to select and
have a default UEFI implementation that covers as many common use cases
as possible, while also being as small as possible.

> 
> Provide a configuration option to make the boot manager available.
> 
> Signed-off-by: Heinrich Schuchardt 
[snip]
> +config CMD_BOOTEFI_BOOTMGR
> + bool "UEFI Boot Manager"
> + default y
> + help
> +   Select this option if you want to select the UEFI binary to be booted
> +   via UEFI variables Boot, BootOrder, and BootNext. This enables the
> +   'bootefi bootmgr' command.

I'm not sure this should be default y.  My concern is that the default
set of options is growing so that every possible case has support in the
binary but the hardware and practical use means we don't need all of
that.  This should perhaps be "default y if DISTRO_DEFAULTS" at least.

-- 
Tom


signature.asc
Description: PGP signature

Re: Devicetree state of U-Boot vs kernel

[Tom Rini]

On Wed, Jan 13, 2021 at 02:30:03PM +0100, Neil Armstrong wrote:
> Hi,
> 
> On 08/01/2021 01:39, Bill Mills wrote:
> > All,
> > 
> > On the Devicetree evolution call Wednesday I promised to finish my 
> > comparison of u-boot DT vs kernel DT.
> > The script is not perfect but the results are still interesting.
> > 
> > For each dts and dtsi file in the tip of the u-boot tree, it tries to 
> > correlate it to the kernel tip.
> > It compares git SHA1 signatures or falls back to filenames.
> > The results were surprising to me but perhaps they should not have been.
> > 
> > I have checked in the script[1] and the full results here [2]
> > 
> > The full file lists (with some diff stats) are in the root dir.
> > Example [3]
> > 
> > I also looked at the line count of the u-boot override files.
> > Even though we don't expect these to correlate, we do expect reasonable 
> > usage to result in small files.  Big files are an indication of possible 
> > abuse of the system.  (I don't think the idea was to have wholesale new 
> > versions of the DTS as an override.)
> > 
> > I plan to redo the script in python.  It will be much easier to be more 
> > precise and to look deeper.  (For example figure out how old the u-boot 
> > version is in number of change sets and number of days.  Or if no content 
> > sync now were they ever synced?)
> > 
> > Here is the scripts output: (from summary.txt)
> > 
> > Devicetree sync status for u-boot v2021.01-rc5-7-gb8c725e736
> > Compared to kernel v5.11-rc2-156-g71c061d24438
> 
> Do not compare with a such kernel, usually DT is sync'ed from stable kernels, 
> or -rc1, so 5.11 stuff will eventually go for next u-boot release, not the 
> actual one.
> 
> We (amlogic/meson) will sync part of DT with 5.10 for next release, the 
> previous is sync'ed to 5.9/5.8.
> 
> It's almost impossible to sync to each release.

It's also something left up to the custodians, but it's also expected to
sync things when our -rc1 window is open with the latest best-choice
upstream Linux kernel.  There is of course, work to be done still and
tooling to better / more easily identify the gaps is good.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] env: Fix warning when forcing environment without ENV_ACCESS_IGNORE_FORCE

[Tom Rini]

On Mon, Jan 11, 2021 at 11:27:20AM +0100, Martin Fuzzey wrote:

> Since commit 0f036bf4b87e ("env: Warn on force access if 
> ENV_ACCESS_IGNORE_FORCE set")
> a warning message is displayed when setenv -f is used WITHOUT
> CONFIG_ENV_ACCESS_IGNORE_FORCE, but the variable is set anyway, resulting
> in lots of log pollution.
> 
> env_flags_validate() returns 0 if the access is accepted, or non zero
> if it is refused.
> 
> So the original code
>   #ifndef CONFIG_ENV_ACCESS_IGNORE_FORCE
>   if (flag & H_FORCE)
>   return 0;
>   #endif
> 
> was correct, it returns 0 (accepts the modification) if forced UNLESS
> IGNORE_FORCE is set (in which case access checks in the following code
> are applied). The broken patch just added a printf to the force accepted
> case.
> 
> To obtain the intent of the patch we need this:
>   if (flag & H_FORCE) {
>   #ifdef CONFIG_ENV_ACCESS_IGNORE_FORCE
>   printf("## Error: Can't force access to \"%s\"\n", name);
>   #else
>   return 0;
>   #endif
>   }
> 
> Fixes: 0f036bf4b87e ("env: Warn on force access if ENV_ACCESS_IGNORE_FORCE 
> set")
> 
> Signed-off-by: Martin Fuzzey 
> ---
>  env/flags.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/env/flags.c b/env/flags.c
> index df4aed2..e3e833c 100644
> --- a/env/flags.c
> +++ b/env/flags.c
> @@ -563,12 +563,13 @@ int env_flags_validate(const struct env_entry *item, 
> const char *newval,
>   return 1;
>  #endif
>  
> -#ifndef CONFIG_ENV_ACCESS_IGNORE_FORCE
>   if (flag & H_FORCE) {
> +#ifdef CONFIG_ENV_ACCESS_IGNORE_FORCE
>   printf("## Error: Can't force access to \"%s\"\n", name);
> +#else
>   return 0;
> - }
>  #endif
> + }
>   switch (op) {
>   case env_op_delete:
>   if (item->flags & ENV_FLAGS_VARACCESS_PREVENT_DELETE) {

Marek, does this look right to you?  Heinrich, I think this means
there''s a follow-up commit that I made to one of the tests that can
probably be reverted as well?  Thanks for digging in to this Martin!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 0/4] phy: add support for Amlogic Meson AXG MIPI-DSI PHY function

[Tom Rini]

On Mon, Jan 11, 2021 at 09:47:29AM +0100, Neil Armstrong wrote:

> Hi Simon, Tom,
> 
> Could you review patches 1 & 2 of this serie ?

Patches 1 and 2 look fine to me, FWIW.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 1/1] image: usage of value ~0UL for intrd_high

[Tom Rini]

On Sun, Jan 10, 2021 at 05:20:50PM +0100, Heinrich Schuchardt wrote:
> On 1/10/21 2:43 PM, Tom Rini wrote:
> > On Sun, Jan 10, 2021 at 01:05:14PM +0100, Heinrich Schuchardt wrote:
> > > On 1/9/21 10:23 PM, Tom Rini wrote:
> > > > On Sat, Jan 09, 2021 at 08:59:01PM +0100, Heinrich Schuchardt wrote:
> > > > > Am 9. Januar 2021 20:40:04 MEZ schrieb Tom Rini :
> > > > > > On Sat, Jan 09, 2021 at 08:33:40PM +0100, Heinrich Schuchardt wrote:
> > > > > > > On 1/9/21 7:58 PM, Tom Rini wrote:
> > > > > > > > On Sat, Jan 09, 2021 at 08:47:07PM +0200, Andy Shevchenko wrote:
> > > > > > > > > On Sat, Jan 9, 2021 at 8:06 PM Heinrich Schuchardt
> > > > > >  wrote:
> > > > > > > > > > 
> > > > > > > > > > The comment for initrd_high in the coding and in README were
> > > > > > contradicting
> > > > > > > > > > and neither fully described what the coding does.
> > > > > > > > > > 
> > > > > > > > > > Clarify the usage of the special value ~0UL for the 
> > > > > > > > > > environment
> > > > > > variable
> > > > > > > > > > initrd_high.
> > > > > > > > > 
> > > > > > > > > All those F:s are hard to read in the comments and 
> > > > > > > > > documentation
> > > > > > and
> > > > > > > > > typo prone. I would prefer to rephrase like "all 1:s value in 
> > > > > > > > > 32-
> > > > > > or
> > > > > > > > > 64-bit format" or alike.
> > > > > > > > 
> > > > > > > > If we're going to improve this we should also note it's 
> > > > > > > > discouraged
> > > > > > > > unless you know for certain there will be no overlap and it's
> > > > > > strongly
> > > > > > > > discouraged in default environments.
> > > > > > > 
> > > > > > > What exactly is discouraged?
> > > > > > > 
> > > > > > > * setting initrd_high to a value != ~0? Here I would agree.
> > > > > > > * setting intird_high to ~0? Why should we copy initrd to a
> > > > > > > different place? Is it for some outdated Linux release?
> > > > > > 
> > > > > > We should always default to allowing the initrd to be relocated 
> > > > > > because
> > > > > > we can see (in many cases) overlap that will lead to failure to boot
> > > > > > but
> > > > > > this forces us to ignore that.  Having good default load values 
> > > > > > means
> > > > > > we
> > > > > > don't have a problem here.
> > > > > 
> > > > > We have an initrd that is already in memory. What could it overlap
> > > > > with that is not already overwritten?
> > > > 
> > > > Having the kernel and initrd too close in memory has the kernel BSS
> > > > overwrite the initrd.  This has happened time and time again before
> > > > I went around making some platforms have reasonable (ie kernel early,
> > > > ramdisk in lowmem but beyond where a kernel+bss can be, etc) defaults
> > > > and pushing others to do the same.
> > > > 
> > > > > Can you provide the text you want to see here?
> > > > 
> > > > Off-hand, it should look more like the big comment block in
> > > > include/configs/ti_armv7_common.h and reference the Linux booting on
> > > > arm/arm64 documents while noting that other architectures have the same
> > > > fundamental issues and their exact limits may or may not be as well
> > > > documented.
> > > > 
> > > 
> > > There is nothing in the include/configs/ti_armv7_common.h comments
> > > requiring to relocate initrd.
> > 
> > /*
> >   * We setup defaults based on constraints from the Linux kernel, which 
> > should
> >   * also be safe elsewhere.  We have the default load at 32MB into DDR (for
> >   * the kernel), FDT above 128MB (the maximum location for the end of the
> >   * kernel), and the ramdisk 512KB above that (allowing for hopefully never
> >   * seen large trees).  We say all of this must be within the first 256MB
> >   * as that will normally be within the kernel lowmem and thus visible via
> >   * bootm_size and we only run on platforms with 256MB or more of memory.
> >   *
> >   * As a temporary storage for DTBO blobs (which should be applied into DTB
> >   * blob), we use the location 15.5 MB above the ramdisk. If someone wants 
> > to
> >   * use ramdisk bigger than 15.5 MB, then DTBO can be loaded and applied to 
> > DTB
> >   * blob before loading the ramdisk, as DTBO location is only used as a 
> > temporary
> >   * storage, and can be re-used after 'fdt apply' command is done.
> >   */
> 
> I cannot see how this relates to initrd relocation.

You cannot safely disable initrd relocation without ensuring it won't be
locked in an unsafe location first.  It's also _generally_ going to be
noise in the boot sequence and not an advisable default.  It should be
documented as part of how to tune a system for optimal boot times.  But
given how often defaults are copy/pasted to the next platform without
fully understanding why those values were picked is why what we use as
default in one platform needs to be very carefully done.

-- 
Tom


signature.asc
Description: PGP signature

Re: [RFC PATCH] common: board_f: add print_archinfo to display arch information

[Tom Rini]

On Fri, Jan 15, 2021 at 01:46:54PM +0900, Jaehoon Chung wrote:

> Current U-boot doesn't display a message about which architecture is
> used. So Developer is difficult to know it by intuition.
> This patch is displaying to CPU information with CONFIG_SYS_CPU.
> 
> CPU: armv8
> DARM:  3.9 GiB
> 
> Signed-off-by: Jaehoon Chung 

We have a large number of "CPU: " prints today, under
CONFIG_DISPLAY_CPUINFO which is what I think you're looking for.

-- 
Tom


signature.asc
Description: PGP signature

[PATCH 2/2] efi_loader: make the UEFI boot manager configurable

[Heinrich Schuchardt]

Some boards are very tight on the binary size. Booting via UEFI is possible
without using the boot manager.

Provide a configuration option to make the boot manager available.

Signed-off-by: Heinrich Schuchardt 
---
 cmd/bootefi.c|  13 ++--
 cmd/efidebug.c   |   8 ++-
 lib/efi_loader/Kconfig   |   8 +++
 lib/efi_loader/Makefile  |   3 +-
 lib/efi_loader/efi_bootmgr.c | 135 ---
 5 files changed, 25 insertions(+), 142 deletions(-)

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index fe70eec625..c8eb5c32b0 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -631,10 +631,12 @@ static int do_bootefi(struct cmd_tbl *cmdtp, int flag, 
int argc,
else if (ret != EFI_SUCCESS)
return CMD_RET_FAILURE;

-   if (!strcmp(argv[1], "bootmgr"))
-   return do_efibootmgr();
+   if (IS_ENABLED(CONFIG_CMD_BOOTEFI_BOOTMGR)) {
+   if (!strcmp(argv[1], "bootmgr"))
+   return do_efibootmgr();
+   }
 #ifdef CONFIG_CMD_BOOTEFI_SELFTEST
-   else if (!strcmp(argv[1], "selftest"))
+   if (!strcmp(argv[1], "selftest"))
return do_efi_selftest();
 #endif

@@ -657,11 +659,14 @@ static char bootefi_help_text[] =
"Use environment variable efi_selftest to select a single test.\n"
"Use 'setenv efi_selftest list' to enumerate all tests.\n"
 #endif
+#ifdef CONFIG_CMD_BOOTEFI_BOOTMGR
"bootefi bootmgr [fdt address]\n"
"  - load and boot EFI payload based on BootOrder/Boot variables.\n"
"\n"
"If specified, the device tree located at  gets\n"
-   "exposed as EFI configuration table.\n";
+   "exposed as EFI configuration table.\n"
+#endif
+   ;
 #endif

 U_BOOT_CMD(
diff --git a/cmd/efidebug.c b/cmd/efidebug.c
index 6de81cab00..9a2d4ddd5e 100644
--- a/cmd/efidebug.c
+++ b/cmd/efidebug.c
@@ -1367,8 +1367,8 @@ static int do_efi_boot_opt(struct cmd_tbl *cmdtp, int 
flag,
  *
  * efidebug test bootmgr
  */
-static int do_efi_test_bootmgr(struct cmd_tbl *cmdtp, int flag,
-  int argc, char * const argv[])
+static __maybe_unused int do_efi_test_bootmgr(struct cmd_tbl *cmdtp, int flag,
+ int argc, char * const argv[])
 {
efi_handle_t image;
efi_uintn_t exit_data_size = 0;
@@ -1392,8 +1392,10 @@ static int do_efi_test_bootmgr(struct cmd_tbl *cmdtp, 
int flag,
 }

 static struct cmd_tbl cmd_efidebug_test_sub[] = {
+#ifdef CONFIG_CMD_BOOTEFI_BOOTMGR
U_BOOT_CMD_MKENT(bootmgr, CONFIG_SYS_MAXARGS, 1, do_efi_test_bootmgr,
 "", ""),
+#endif
 };

 /**
@@ -1581,8 +1583,10 @@ static char efidebug_help_text[] =
"  - show UEFI memory map\n"
"efidebug tables\n"
"  - show UEFI configuration tables\n"
+#ifdef CONFIG_CMD_BOOTEFI_BOOTMGR
"efidebug test bootmgr\n"
"  - run simple bootmgr for test\n"
+#endif
"efidebug query [-nv][-bs][-rt][-at]\n"
"  - show size of UEFI variables store\n";
 #endif
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index fdf245dea3..106f789b4d 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -27,6 +27,14 @@ config EFI_LOADER

 if EFI_LOADER

+config CMD_BOOTEFI_BOOTMGR
+   bool "UEFI Boot Manager"
+   default y
+   help
+ Select this option if you want to select the UEFI binary to be booted
+ via UEFI variables Boot, BootOrder, and BootNext. This enables the
+ 'bootefi bootmgr' command.
+
 config EFI_SETUP_EARLY
bool
default n
diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
index 412fa88245..a6355d240a 100644
--- a/lib/efi_loader/Makefile
+++ b/lib/efi_loader/Makefile
@@ -21,7 +21,7 @@ targets += helloworld.o
 endif

 obj-$(CONFIG_CMD_BOOTEFI_HELLO) += helloworld_efi.o
-obj-y += efi_bootmgr.o
+obj-$(CONFIG_CMD_BOOTEFI_BOOTMGR) += efi_bootmgr.o
 obj-y += efi_boottime.o
 obj-$(CONFIG_EFI_HAVE_CAPSULE_SUPPORT) += efi_capsule.o
 obj-$(CONFIG_EFI_CAPSULE_FIRMWARE) += efi_firmware.o
@@ -35,6 +35,7 @@ endif
 obj-y += efi_file.o
 obj-$(CONFIG_EFI_LOADER_HII) += efi_hii.o
 obj-y += efi_image_loader.o
+obj-y += efi_load_options.o
 obj-y += efi_memory.o
 obj-y += efi_root_node.o
 obj-y += efi_runtime.o
diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
index d3be2f94c6..25f5cebfdb 100644
--- a/lib/efi_loader/efi_bootmgr.c
+++ b/lib/efi_loader/efi_bootmgr.c
@@ -30,141 +30,6 @@ static const struct efi_runtime_services *rs;
  * should do normal or recovery boot.
  */

-/**
- * efi_set_load_options() - set the load options of a loaded image
- *
- * @handle:the image handle
- * @load_options_size: size of load options
- * @load_options:  pointer to load options
- * Return: status code
- */
-efi_status_t efi_set_load_options(efi_handle_t handle,
- efi_uintn_t l

[PATCH 1/2] efi_loader: move load options to new module

[Heinrich Schuchardt]

Move all load options related functions to a new module. So that they can
be compiled independently.

Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_loader/efi_load_options.c | 151 ++
 1 file changed, 151 insertions(+)
 create mode 100644 lib/efi_loader/efi_load_options.c

diff --git a/lib/efi_loader/efi_load_options.c 
b/lib/efi_loader/efi_load_options.c
new file mode 100644
index 00..9f0e25b6e9
--- /dev/null
+++ b/lib/efi_loader/efi_load_options.c
@@ -0,0 +1,151 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ *  EFI boot manager
+ *
+ *  Copyright (c) 2017 Rob Clark
+ */
+
+#define LOG_CATEGORY LOGC_EFI
+
+#include 
+#include 
+#include 
+#include 
+#include 
+//#include 
+#include 
+
+/**
+ * efi_set_load_options() - set the load options of a loaded image
+ *
+ * @handle:the image handle
+ * @load_options_size: size of load options
+ * @load_options:  pointer to load options
+ * Return: status code
+ */
+efi_status_t efi_set_load_options(efi_handle_t handle,
+ efi_uintn_t load_options_size,
+ void *load_options)
+{
+   struct efi_loaded_image *loaded_image_info;
+   efi_status_t ret;
+
+   ret = EFI_CALL(systab.boottime->open_protocol(
+   handle,
+   &efi_guid_loaded_image,
+   (void **)&loaded_image_info,
+   efi_root, NULL,
+   EFI_OPEN_PROTOCOL_BY_HANDLE_PROTOCOL));
+   if (ret != EFI_SUCCESS)
+   return EFI_INVALID_PARAMETER;
+
+   loaded_image_info->load_options = load_options;
+   loaded_image_info->load_options_size = load_options_size;
+
+   return EFI_CALL(systab.boottime->close_protocol(handle,
+   &efi_guid_loaded_image,
+   efi_root, NULL));
+}
+
+/**
+ * efi_deserialize_load_option() - parse serialized data
+ *
+ * Parse serialized data describing a load option and transform it to the
+ * efi_load_option structure.
+ *
+ * @lo:pointer to target
+ * @data:  serialized data
+ * @size:  size of the load option, on return size of the optional data
+ * Return: status code
+ */
+efi_status_t efi_deserialize_load_option(struct efi_load_option *lo, u8 *data,
+efi_uintn_t *size)
+{
+   efi_uintn_t len;
+
+   len = sizeof(u32);
+   if (*size < len + 2 * sizeof(u16))
+   return EFI_INVALID_PARAMETER;
+   lo->attributes = get_unaligned_le32(data);
+   data += len;
+   *size -= len;
+
+   len = sizeof(u16);
+   lo->file_path_length = get_unaligned_le16(data);
+   data += len;
+   *size -= len;
+
+   lo->label = (u16 *)data;
+   len = u16_strnlen(lo->label, *size / sizeof(u16) - 1);
+   if (lo->label[len])
+   return EFI_INVALID_PARAMETER;
+   len = (len + 1) * sizeof(u16);
+   if (*size < len)
+   return EFI_INVALID_PARAMETER;
+   data += len;
+   *size -= len;
+
+   len = lo->file_path_length;
+   if (*size < len)
+   return EFI_INVALID_PARAMETER;
+   lo->file_path = (struct efi_device_path *)data;
+   if (efi_dp_check_length(lo->file_path, len) < 0)
+   return EFI_INVALID_PARAMETER;
+   data += len;
+   *size -= len;
+
+   lo->optional_data = data;
+
+   return EFI_SUCCESS;
+}
+
+/**
+ * efi_serialize_load_option() - serialize load option
+ *
+ * Serialize efi_load_option structure into byte stream for Boot.
+ *
+ * @data:  buffer for serialized data
+ * @lo:load option
+ * Return: size of allocated buffer
+ */
+unsigned long efi_serialize_load_option(struct efi_load_option *lo, u8 **data)
+{
+   unsigned long label_len;
+   unsigned long size;
+   u8 *p;
+
+   label_len = (u16_strlen(lo->label) + 1) * sizeof(u16);
+
+   /* total size */
+   size = sizeof(lo->attributes);
+   size += sizeof(lo->file_path_length);
+   size += label_len;
+   size += lo->file_path_length;
+   if (lo->optional_data)
+   size += (utf8_utf16_strlen((const char *)lo->optional_data)
+  + 1) * sizeof(u16);
+   p = malloc(size);
+   if (!p)
+   return 0;
+
+   /* copy data */
+   *data = p;
+   memcpy(p, &lo->attributes, sizeof(lo->attributes));
+   p += sizeof(lo->attributes);
+
+   memcpy(p, &lo->file_path_length, sizeof(lo->file_path_length));
+   p += sizeof(lo->file_path_length);
+
+   memcpy(p, lo->label, label_len);
+   p += label_len;
+
+   memcpy(p, lo->file_path, lo->file_path_length);
+   p += lo->file_path_length;
+
+   if (lo->optional_data) {
+   utf8_u

[PATCH 0/2] efi_loader: make the UEFI boot manager configurable

[Heinrich Schuchardt]

Some boards are very tight on the binary size. Booting via UEFI is possible
without using the boot manager.

Provide a configuration option to make the boot manager available.

Heinrich Schuchardt (2):
  efi_loader: move load options to new module
  efi_loader: make the UEFI boot manager configurable

 cmd/bootefi.c |  13 ++-
 cmd/efidebug.c|   8 +-
 lib/efi_loader/Kconfig|   8 ++
 lib/efi_loader/Makefile   |   3 +-
 lib/efi_loader/efi_bootmgr.c  | 135 --
 lib/efi_loader/efi_load_options.c | 151 ++
 6 files changed, 176 insertions(+), 142 deletions(-)
 create mode 100644 lib/efi_loader/efi_load_options.c

--
2.29.2

Re: [PATCH] efi_loader: Enable run-time variable support for tee based variables

[Ilias Apalodimas]

Hi Andreas,

On Fri, Jan 15, 2021 at 05:34:04PM +0100, Andreas Schwab wrote:
> On Jan 14 2021, Atish Patra wrote:
> 
> > I am a bit confused how this will work. This means it will reside in GOT
> > which is not mapped in virtual address for Linux. Whenever we try to
> > invoke get_variable service, it will panic.
> > Did we miss a trick in RISC-V ?
> 
> I think the problem really is that RISC-V use -fpic for compiling.  If I
> change that to -fpie, there is no longer a GOT reference.

The -fpic explains why the GOT is there to begin with, as you say. Keep in mind 
it's
present in Arm as well. What I am trying to explain in the mail is that 
regardless 
of the -fpic, Arm gets rid of all GOT indirections. The section is actually
empty and they all turn into relative references. That's why that works fine
on Arm.

The reason for that (I think, if I am wrong somebody shout please), is that you 
only 
need a GOT in shared libraries for symbol pre-emption. So if both the library
and the executable define a global 'bar', the lib is supposed to switch the
references to the executable exposed symbol.
So on Arm the linker observes that's not the case, and uses relative
references, while it gets rid of  the GOT section entries (again shout if I am 
wrong :)).

Anyway removing -fpic should work as well, but I'd rather do this [1],
instead of relying on linker flags.

[1] https://lists.denx.de/pipermail/u-boot/2021-January/437478.html

Cheers
/Ilias
> 
> Andreas.
> 
> -- 
> Andreas Schwab, SUSE Labs, sch...@suse.de
> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
> "And now for something completely different."

RE: [PATCH 4/5] arm: dts: ls1028a: Add Ethernet switch node and dependencies

[Claudiu Manoil]

>-Original Message-
>From: Michael Walle 
>Sent: Thursday, January 14, 2021 5:40 PM
>To: Claudiu Manoil 
>Cc: Joe Hershberger ; Simon Glass
>; Bin Meng ; u-
>b...@lists.denx.de; Vladimir Oltean ; Alexandru
>Marginean 
>Subject: Re: [PATCH 4/5] arm: dts: ls1028a: Add Ethernet switch node and
>dependencies
>
>Hi Claudiu,
>
>Am 2021-01-14 16:20, schrieb Claudiu Manoil:
>>> -Original Message-
>>> From: Michael Walle 
>>> Sent: Wednesday, January 13, 2021 10:11 PM
>> [...]
 --- a/arch/arm/dts/fsl-ls1028a.dtsi
 +++ b/arch/arm/dts/fsl-ls1028a.dtsi
 @@ -14,6 +14,17 @@
#address-cells = <2>;
#size-cells = <2>;

 +  aliases {
 +  eth0 = &enetc0;
 +  eth1 = &enetc1;
 +  eth2 = &enetc2;
 +  eth3 = &enetc6;
 +  eth4 = &felix0;
 +  eth5 = &felix1;
 +  eth6 = &felix2;
 +  eth7 = &felix3;
 +  };
>>>
>>> Don't include the aliases in the common dtsi. There are serveral
>>> reasons for that:
>>>  (1) it is really board dependent. not every board has all these
>>>  ports.
>>>  (2) it will mess up the device numbering for boards which use
>>>  this dtsi. And with this it will also mess up the ethNaddr
>>>  environment variable logic.
>>>
>>> Please move them into the corresponding boards.
>>>
>> I think the point of this patch was to enable the felix switch for the
>> LS1028A RDB only for now,
>> for simplicity, to make the patch set smaller. Follow-up patches would
>> enable it for the remaining
>> boards.
>> But I understand that keeping the aliases in the fsl-ls1028a.dtsi can
>> mess up other boards
>> that include it, including the Kontron boards.  Would you agree to
>> update only the ls1028 RDB
>> board DT for now?
>
>Sure, once accepted, I'll post a follow-up for our board.
>
>> Alternatively you could test these patches on your boards and maybe
>> provide the DT updates for
>> the Kontron boards as part of this patch set.
>
>I'm going to test this anyways and add a Tested-by to this set, once it
>tested successfully.
>
>At the moment the only board variant which this would apply to is not
>upstream yet. Patches are pending. But sure, if it will be in upstream
>you could pick it up for this set.
>
 +
sysclk: sysclk {
compatible = "fixed-clock";
#clock-cells = <0>;
 @@ -151,9 +162,51 @@
reg = <0x000300 0 0 0 0>;
status = "disabled";
};
 +  ethsw: pci@0,5 {
 +  #address-cells=<0>;
 +  #size-cells=<1>;
 +  reg = <0x000500 0 0 0 0>;
>
>This should also have
>  status = "disabled"
>
 +
 +  ethsw_ports: ports {
 +  #address-cells = <1>;
 +  #size-cells = <0>;
 +
 +  felix0: port@0 {
 +  reg = <0>;
 +  status = "disabled";
 +  label = "swp0";
 +  };
 +  felix1: port@1 {
 +  reg = <1>;
 +  status = "disabled";
 +  label = "swp1";
 +  };
 +  felix2: port@2 {
 +  reg = <2>;
 +  status = "disabled";
 +  label = "swp2";
 +  };
 +  felix3: port@3 {
 +  reg = <3>;
 +  status = "disabled";
 +  label = "swp3";
 +  };
 +  port@4 {
 +  reg = <4>;
 +  phy-mode = "internal";
 +  status = "okay";
 +  ethernet = <&enetc2>;
 +  };
>>>
>>> status = "disabled".
>>>
>>> Why would you enable just this port if all the switch ports
>>> are disabled.
>>>
>>
>> The number of active front panel ports may vary from board to board.
>> These ports are supposed to be enabled in each board DT, depending
>> on setup. But a DSA switch always needs a CPU port regardless of how
>> many front side ports are active in each particular setup, and port@4
>> is
>> the CPU port.
>
>Sure, but my point was that the default should be disabled - as it
>should be for any peripheral in the dtsi - and it should be enabled per
>board.
>What if I'd rather use the other internal port? The linux dtsi also has all
>ports disabled by default. Speaking of the linux device tree. The u-boot
>one and the linux one are out

RE: [PATCH 1/5] net: Introduce DSA class for Ethernet switches

[Claudiu Manoil]

>-Original Message-
>From: Simon Glass 
>Sent: Thursday, January 14, 2021 5:42 PM
>To: Claudiu Manoil 
>Cc: Joe Hershberger ; Bin Meng
>; Michael Walle ; U-Boot Mailing
>List ; Vladimir Oltean ;
>Alexandru Marginean 
>Subject: Re: [PATCH 1/5] net: Introduce DSA class for Ethernet switches
>
[...]
>
>Reviewed-by: Simon Glass 
>
>I don't think it is necessary to have the 'if (!pdev)' checks around
>the place. We need a way in U-Boot to have checks like that to catch
>programming errors  but to be able to turn them off in production code
>to reduce size.
>
>I suppose a Kconfig would do it, with:
>
>if (CONFIG_IS_ENABLED(SAFETY) && !pdev)
>return log_,msg_ref("safety", -ENODEV)
>
>Also note that -ENODEV is used by drive rmodel so it generally isn't
>safe to return it as a logic error. I think in this case because it
>never happens, it should be OK.
>

Thanks for the review, Simon.
I thought about using assert(pdev) checks, but during development the
simple "if (!pdev)..." proved more friendly.  I like your idea about enabling
the checks at compile time and disabling them in production.
For now, since this SAFETY flag is not implemented, my understanding is
that you’re ok with leaving the pdev checks in the code as they are right now
and sometime in the future these will be converted to the "SAFETY" construct
you mention.

Re: [PATCH 1/6] net: macb: use dummy descriptor for RBQP

[Eugen.Hristev]

On 15.01.2021 14:26, Padmarao Begari wrote:
> Hi Eugen,
> 
> On Fri, Jan 15, 2021 at 1:34 PM  > wrote:
> 
> On 15.01.2021 06:02, Padmarao Begari wrote:
>  > Hi Eugen,
>  >
>  > On Thu, Jan 14, 2021 at 4:50 PM  
>  >  >> wrote:
>  >
>  >     On 17.12.2020 07:22, Padmarao Begari - I30397 wrote:
>  >      > Hi Eugen,
>  >      >
>  >      > This series of patches break my side of work(patches) so
> you need to
>  >      > create patches after my patches are going into master branch
>  >     because my
>  >      > patches are already reviewed and tested.
>  >
>  >     Hi,
>  >
>  >     Could you please detail the breakage ?
>  >
>  >
>  > The breakage is the fdt relocation disabled in the board environment
>  > variables so I have removed it and enabled fdt relocation in
> PATCH v9.
> 
> Maybe you misunderstand my question. I was asking about the sama7g5
> macb
> series, which you claimed that breaks your current patch set.
> This is a link to the series :
> https://patchwork.ozlabs.org/project/uboot/list/?series=218367
> 
> Since you claimed that this series breaks your series, I am asking what
> exactly is the breakage. How does the fdt relocation in your board
> environment has anything to do with macb and these patches which are
> not
> applied ?
> 
> 
> My mistake, misunderstood your question,
> Yes the fdt relocation has nothing to do with the macb.
> We both are adding a member into struct mac_config, a dummy descriptor 
> for RBQP and my changes are both 32-bit and 64-bit DMA.

Okay, so, could you please tell me why you told us that our sama7g5 
series breaks your solarfire SoC series ?
It would be good for both of us if you could test our sama7g5 series on 
top of your patches, on your platform, such that we know that we do not 
affect anything on your board.

Thanks again,
Eugen

> 
> Regards
> Padmarao
> 
> Thanks,
> Eugen
> 
>  >
>  > Regards
>  > Padmarao
>  >
>  >     I saw a pull request with your patches that was NAK-ed, if
> your two
>  >     macb
>  >     patches are tested and reviewed I could apply them to the
> atmel tree as
>  >     well and send them, if your PR is delayed. But we are
> interested to
>  >     have
>  >     our sama7g5 series pushed as well, so we need to know if it's
> ok on
>  >     your
>  >     side, and what is wrong with the sama7g5 series.
>  >
>  >     Thanks!
>  >     Eugen
>  >      >
>  >      > Regards
>  >      > Padmarao
>  >      >
>  >   
>   
>  >      > *From:* Eugen Hristev - M18282
> mailto:eugen.hris...@microchip.com>
>  >      >>
>  >      > *Sent:* Wednesday, December 16, 2020 12:24 PM
>  >      > *To:* anup.pa...@wdc.com 
> >
>  >     mailto:anup.pa...@wdc.com>
> >>;
>  > bin.m...@windriver.com 
> >
>  >      > mailto:bin.m...@windriver.com>
> >>;
>  >     Padmarao Begari - I30397
>  >      >  
>  >      >>
>  >      > *Cc:* Claudiu Beznea - M18063
> mailto:claudiu.bez...@microchip.com>
>  >      >>;
>  >      > joe.hershber...@ni.com 
> >
>  >     mailto:joe.hershber...@ni.com>
> >>;
>  > u-boot@lists.denx.de 
> >
>  >      > mailto:u-boot@lists.denx.de>
> >>
>  >      > *Subject:* Re: [PATCH 1/6] net: macb: use dummy descriptor
> for RBQP
>  >      > On 03.12.2020 11:25, Claudiu Beznea wrote:
>  >      >> In case of multiple queues on RX side the queue scheduler
>  >      >> will try to use all the available configured queues (with
>  >      >> descriptors having TX_USED bit cleared). If at least one RBQP
>  >      >> points to a descriptor with a valid used bit
> configuration then
>  >      >> the r

Re: [PATCH 1/2] timer: mtk_timer: initialize the timer before use

[Matthias Brugger]

On Tue, Jan 12, 2021 at 01:44:02PM +0800, Weijie Gao wrote:
> The timer being used by this driver may have already been used by first
> stage bootloader (e.g. ATF/preloader), and it's settings may differ from
> what this driver is going to use.
> 
> This may cause issues, such as inaccurate timer frequency due to
> incorrect clock divider.
> 
> This patch adds the initialization code to avoid them.
> 
> Signed-off-by: Weijie Gao 
> ---
>  drivers/timer/mtk_timer.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/timer/mtk_timer.c b/drivers/timer/mtk_timer.c
> index 448a76a7e1..f6b97f868c 100644
> --- a/drivers/timer/mtk_timer.c
> +++ b/drivers/timer/mtk_timer.c
> @@ -61,6 +61,16 @@ static int mtk_timer_probe(struct udevice *dev)
>   if (!uc_priv->clock_rate)
>   return -EINVAL;
>  
> + /*
> +  * Initialize the timer:
> +  * 1. set clock source to system clock with clock divider setting to 1
> +  * 2. set timer mode to free running
> +  * 3. reset timer counter to 0 then enable the timer
> +  */
> + writel(GPT4_CLK_SYS | GPT4_CLK_DIV1, priv->base + MTK_GPT4_CLK);
> + writel(GPT4_FREERUN | GPT4_CLEAR | GPT4_ENABLE,

GPT4_FREERUN is defined as GENMASK(5,4) while in the Linux kernel it has
the value of 3. Can you explain where this difference comes from?

Regards,
Matthias

> +priv->base + MTK_GPT4_CTRL);
> +
>   return 0;
>  }
>  
> -- 
> 2.17.1

Re: [PATCH] efi_loader: Enable run-time variable support for tee based variables

[Andreas Schwab]

On Jan 14 2021, Atish Patra wrote:

> I am a bit confused how this will work. This means it will reside in GOT
> which is not mapped in virtual address for Linux. Whenever we try to
> invoke get_variable service, it will panic.
> Did we miss a trick in RISC-V ?

I think the problem really is that RISC-V use -fpic for compiling.  If I
change that to -fpie, there is no longer a GOT reference.

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [GIT PULL] SoCFPGA changes for v2021.04-rc1

[Tom Rini]

On Fri, Jan 15, 2021 at 11:15:18AM +, Tan, Ley Foon wrote:

> Hi Tom
> 
> Please pull the SoCFPGA changes for v2021.04.
> 
> Regards
> Ley Foon
> 
> The following changes since commit ab1a425524a79eeca61e7b67fdf382c7a499346f:
> 
>   Merge tag 'u-boot-stm32-20210113' of 
> https://gitlab.denx.de/u-boot/custodians/u-boot-stm (2021-01-13 15:00:53 
> -0500)
> 
> are available in the Git repository at:
> 
>   https://github.com/lftan/u-boot.git 2021.04-rc
> 
> for you to fetch changes up to 40551cf99c237f93d9e0e07b6dd8f31b3868a0f0:
> 
>   tools: socfpgaimage: update padding flow (2021-01-15 17:48:39 +0800)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

[PATCH] efi_loader: Avoid emitting efi_var_buf to .GOT

[Ilias Apalodimas]

Atish reports than on RISC-V, accessing the EFI variables causes
a kernel panic. An objdump of the file verifies that, since the
global pointer for efi_var_buf ends up in .GOT section which is
not mapped in virtual address space for Linux.



0084 :
  84:   715daddisp,sp,-80

* objdump -dr
0086 <.LCFI2>:
  86:   e0a2sd  s0,64(sp)
  88:   fc26sd  s1,56(sp)
  8a:   e486sd  ra,72(sp)
  8c:   f84asd  s2,48(sp)
  8e:   f44esd  s3,40(sp)
  90:   f052sd  s4,32(sp)
  92:   ec56sd  s5,24(sp)
  94:   0497auipc   s1,0x0
94: R_RISCV_GOT_HI20efi_var_buf
  98:   0004b483ld  s1,0(s1) # 94 <.LCFI2+0xe>
98: R_RISCV_PCREL_LO12_I.L0
98: R_RISCV_RELAX   *ABS*

* objdump -t
0084 g F .text.efi_runtime  00b8 efi_var_mem_find

With the patch applied:

* objdump -dr
0086 <.LCFI2>:
  86:   e0a2sd  s0,64(sp)
  88:   fc26sd  s1,56(sp)
  8a:   e486sd  ra,72(sp)
  8c:   f84asd  s2,48(sp)
  8e:   f44esd  s3,40(sp)
  90:   f052sd  s4,32(sp)
  92:   ec56sd  s5,24(sp)
  94:   0497auipc   s1,0x0
94: R_RISCV_PCREL_HI20  .LANCHOR0
94: R_RISCV_RELAX   *ABS*
  98:   00048493mv  s1,s1
98: R_RISCV_PCREL_LO12_I.L0
98: R_RISCV_RELAX   *ABS*

* objdump -t
0008 l O .data.efi_runtime  0008 efi_var_buf

On arm64 this works, because there's no .GOT entries for this
and everything is converted to relative references.

* objdump -dr (identical pre-post patch, only the new function shows up)
00b4 :
  b4:   aa0003eemov x14, x0
  b8:   900aadrpx10, 0 
b8: R_AARCH64_ADR_PREL_PG_HI21  .data.efi_runtime
  bc:   91000140add x0, x10, #0x0
bc: R_AARCH64_ADD_ABS_LO12_NC   .data.efi_runtime
  c0:   aa0103edmov x13, x1
  c4:   79400021ldrhw1, [x1]
  c8:   aa0203ebmov x11, x2
  cc:   f9400400ldr x0, [x0, #8]
  d0:   b940100cldr w12, [x0, #16]
  d4:   8b0c000cadd x12, x0, x12

So let's switch efi_var_buf to static and create a helper function for
anyone that needs to update it.

Fixes: e01aed47d6a0 ("efi_loader: Enable run-time variable support for tee 
based variables")
Reported-by: Atish Patra 
Signed-off-by: Ilias Apalodimas 
---
Atish can you give it a spin and let me know if this fixes the issue for you?
The objdump seems to be correct now, but I am not familiar with RISC-V.
No regressions on Arm with TEE or memory backed variables. 
 include/efi_variable.h| 12 
 lib/efi_loader/efi_var_mem.c  | 12 +++-
 lib/efi_loader/efi_variable_tee.c |  2 +-
 3 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/include/efi_variable.h b/include/efi_variable.h
index 4704a3c16e65..b2317eb7bf1c 100644
--- a/include/efi_variable.h
+++ b/include/efi_variable.h
@@ -306,4 +306,16 @@ efi_status_t __efi_runtime EFIAPI
 efi_get_next_variable_name_runtime(efi_uintn_t *variable_name_size,
   u16 *variable_name, efi_guid_t *guid);
 
+/**
+ * efi_var_buf_update() - Update the value of efi_var_buf in efi_var_mem.c
+ *
+ * @var_buf:   Source buffer
+ *
+ * efi_var_buf is special since we use it on Runtime Services. We need
+ * to keep it static in efi_var_mem.c and avoid having it pulled into
+ * .GOT. Since it has to be static this function must be used to update
+ * it
+ */
+void efi_var_buf_update(struct efi_var_file *var_buf);
+
 #endif
diff --git a/lib/efi_loader/efi_var_mem.c b/lib/efi_loader/efi_var_mem.c
index d155f25f60e6..fcf0043b5d3b 100644
--- a/lib/efi_loader/efi_var_mem.c
+++ b/lib/efi_loader/efi_var_mem.c
@@ -10,7 +10,12 @@
 #include 
 #include 
 
-struct efi_var_file __efi_runtime_data *efi_var_buf;
+/*
+ * keep efi_var_buf as static , moving it out might move it to .got
+ * which is not mapped in virtual address for Linux. Whenever
+ * we try to invoke get_variable service, it will panic.
+ */
+static struct efi_var_file __efi_runtime_data *efi_var_buf;
 static struct efi_var_entry __efi_runtime_data *efi_current_var;
 
 /**
@@ -339,3 +344,8 @@ efi_get_next_variable_name_mem(efi_uintn_t 
*variable_name_size,
 
return EFI_SUCCESS;
 }
+
+void efi_var_buf_update(struct efi_var_file *var_buf)
+{
+   memcpy(efi_var_buf, var_buf, EFI_VAR_BUF_SIZE);
+}
diff --git a/lib/efi_loader/efi_variable_tee.c 
b/lib/efi_loader/efi_variable_tee.c
index be6f3dfad469..c69330443801 100644
--- a/lib/efi_loader/efi_variable_tee.c
+++ b/lib/efi_loader/efi_variable_tee.c
@@ -692,7 +692,7 @@ void efi_variables_boot_exit_notify(void)
if (ret != EFI_SUCCESS)
log_err("Can't 

Re: [PATCH] serial: a3720: Implement pending method for output direction

[Pali Rohár]

On Friday 15 January 2021 15:50:46 Stefan Roese wrote:
> On 14.01.21 15:46, Pali Rohár wrote:
> > To check if some output characters are waiting either in Transmitter
> > Holding Register or Transmitter Shift Register we need to look at
> > TX_EMPTY bit of UART Status Register.
> > 
> > Signed-off-by: Pali Rohár 
> 
> Reviewed-by: Stefan Roese 
> 
> BTW: How did you detect this issue?

During debugging both TF-A and linux kernel as they were eating
characters sent via A3720 UART. Details are in kernel and TF-A patches:

https://lore.kernel.org/linux-serial/20201223191931.18343-1-p...@kernel.org/
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/7734

I have not spotted this issue in U-Boot (only in TF-A and kernel), but I
decided to look also at the U-Boot A3720 UART implementation... And find
out that it is incomplete too, ignoring 'bool input' function argument.

> Thanks,
> Stefan
> 
> > ---
> >   drivers/serial/serial_mvebu_a3700.c | 10 --
> >   1 file changed, 8 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/serial/serial_mvebu_a3700.c 
> > b/drivers/serial/serial_mvebu_a3700.c
> > index fb43f88eaf..909901c9f0 100644
> > --- a/drivers/serial/serial_mvebu_a3700.c
> > +++ b/drivers/serial/serial_mvebu_a3700.c
> > @@ -23,6 +23,7 @@ struct mvebu_platdata {
> >   #define UART_POSSR_REG0x14
> >   #define UART_STATUS_RX_RDY0x10
> > +#define UART_STATUS_TX_EMPTY   0x40
> >   #define UART_STATUS_TXFIFO_FULL   0x800
> >   #define UART_CTRL_RXFIFO_RESET0x4000
> > @@ -59,8 +60,13 @@ static int mvebu_serial_pending(struct udevice *dev, 
> > bool input)
> > struct mvebu_platdata *plat = dev_get_platdata(dev);
> > void __iomem *base = plat->base;
> > -   if (readl(base + UART_STATUS_REG) & UART_STATUS_RX_RDY)
> > -   return 1;
> > +   if (input) {
> > +   if (readl(base + UART_STATUS_REG) & UART_STATUS_RX_RDY)
> > +   return 1;
> > +   } else {
> > +   if (!(readl(base + UART_STATUS_REG) & UART_STATUS_TX_EMPTY))
> > +   return 1;
> > +   }
> > return 0;
> >   }
> > 
> 
> 
> Viele Grüße,
> Stefan
> 
> -- 
> DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de

Re: Invitation: Regular U-Boot video call (Tuesday 19th)

[Bin Meng]

Hi Simon,

On Fri, Jan 15, 2021 at 10:13 PM Simon Glass  wrote:
>
> Hi Bin,
>
> On Thu, 14 Jan 2021 at 19:12, Bin Meng  wrote:
> >
> > Hi Peng,
> >
> > On Fri, Jan 15, 2021 at 9:33 AM Peng Fan  wrote:
> > >
> > > Hi Simon,
> > >
> > > > Subject: Invitation: Regular U-Boot video call (Tuesday 19th)
> > > >
> > > > Hi,
> > > >
> > > > (This has been discussed for a while now so I thought I would just try 
> > > > it)
> > > >
> > > > As an experiment I'd like to set up a regular 30-minute U-Boot call for 
> > > > people
> > > > to discuss features, bugs, patches, etc.
> > > >
> > > > The meeting notes and details are here[1].
> > >
> > > The url is blocked by China. Do you have a direct google meet link, not 
> > > using bit.ly?
> > > I am in UTC + 8 timezone, not sure I am able to join, but please invite 
> > > me.
> > >
> >
> > Yep, but the google meet is also blocked :) That's why I suggest we
> > use Zoom or something else for better experience.
>
> Oh that's nuts.
>
> What is the situation with monitoring of calls with Zoom?

Zoom is directly accessible in China.

> Are VPNs available in China?

Yep, we have to figure that out, isn't it :)

Regards,
Bin

Re: [PATCH] serial: a3720: Implement pending method for output direction

[Stefan Roese]

On 14.01.21 15:46, Pali Rohár wrote:

To check if some output characters are waiting either in Transmitter
Holding Register or Transmitter Shift Register we need to look at
TX_EMPTY bit of UART Status Register.

Signed-off-by: Pali Rohár 


Reviewed-by: Stefan Roese 

BTW: How did you detect this issue?

Thanks,
Stefan


---
  drivers/serial/serial_mvebu_a3700.c | 10 --
  1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/serial/serial_mvebu_a3700.c 
b/drivers/serial/serial_mvebu_a3700.c
index fb43f88eaf..909901c9f0 100644
--- a/drivers/serial/serial_mvebu_a3700.c
+++ b/drivers/serial/serial_mvebu_a3700.c
@@ -23,6 +23,7 @@ struct mvebu_platdata {
  #define UART_POSSR_REG0x14
  
  #define UART_STATUS_RX_RDY	0x10

+#define UART_STATUS_TX_EMPTY   0x40
  #define UART_STATUS_TXFIFO_FULL   0x800
  
  #define UART_CTRL_RXFIFO_RESET	0x4000

@@ -59,8 +60,13 @@ static int mvebu_serial_pending(struct udevice *dev, bool 
input)
struct mvebu_platdata *plat = dev_get_platdata(dev);
void __iomem *base = plat->base;
  
-	if (readl(base + UART_STATUS_REG) & UART_STATUS_RX_RDY)

-   return 1;
+   if (input) {
+   if (readl(base + UART_STATUS_REG) & UART_STATUS_RX_RDY)
+   return 1;
+   } else {
+   if (!(readl(base + UART_STATUS_REG) & UART_STATUS_TX_EMPTY))
+   return 1;
+   }
  
  	return 0;

  }




Viele Grüße,
Stefan

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

Re: [PATCH u-boot-marvell] arm: mvebu: turris_mox: enable wdt command in defconfig

[Stefan Roese]

On 13.01.21 18:22, Marek Behún wrote:
Enable wdt command in defconfig for Turris MOX. This is useful when 
doing debugging.


Signed-off-by: Marek Behún 


Reviewed-by: Stefan Roese 

Thanks,
Stefan

Re: [PATCH 2/2] board: atmel: Add SAMA5D27 giant board

[Greg Gallagher]

On Fri, Jan 15, 2021 at 2:55 AM  wrote:

> On 11.01.2021 09:10, Greg Gallagher wrote:
> > Giant board is a tiny SBC based on the Adafruit Feather form factor,
> > created by groboards it contains a SAMA5D2 processor (SAMA5D27),
> > 128 MB of RAM and a microSD card for storage.
> >
> > Signed-off-by: Greg Gallagher 
>
> Hi Greg,
>
>
> > ---
> >
> >   arch/arm/dts/Makefile |   3 +
> >   arch/arm/dts/at91-sama5d27_giantboard.dts | 128 
> >   arch/arm/mach-at91/Kconfig|   9 +
> >   board/atmel/sama5d27_giantboard/Kconfig   |  15 ++
> >   board/atmel/sama5d27_giantboard/MAINTAINERS   |   6 +
> >   board/atmel/sama5d27_giantboard/Makefile  |   5 +
> >   .../sama5d27_giantboard/sama5d27_giantboard.c | 182 ++
> >   configs/sama5d27_giantboard_defconfig |  93 +
> >   include/configs/sama5d27_giantboard.h | 136 +
> >   9 files changed, 577 insertions(+)
> >   create mode 100644 arch/arm/dts/at91-sama5d27_giantboard.dts
> >   create mode 100644 board/atmel/sama5d27_giantboard/Kconfig
> >   create mode 100644 board/atmel/sama5d27_giantboard/MAINTAINERS
> >   create mode 100644 board/atmel/sama5d27_giantboard/Makefile
> >   create mode 100644
> board/atmel/sama5d27_giantboard/sama5d27_giantboard.c
> >   create mode 100644 configs/sama5d27_giantboard_defconfig
> >   create mode 100644 include/configs/sama5d27_giantboard.h
> >
> > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > index fd47e408f8..23b45290a4 100644
> > --- a/arch/arm/dts/Makefile
> > +++ b/arch/arm/dts/Makefile
> > @@ -898,6 +898,9 @@ dtb-$(CONFIG_TARGET_SAMA5D2_XPLAINED) += \
> >   dtb-$(CONFIG_TARGET_SAMA5D27_SOM1_EK) += \
> >  at91-sama5d27_som1_ek.dtb
> >
> > +dtb-$(CONFIG_TARGET_SAMA5D27_GIANTBOARD) += \
> > +   at91-sama5d27_giantboard.dtb
> > +
> >   dtb-$(CONFIG_TARGET_SAMA5D27_WLSOM1_EK) += \
> >  at91-sama5d27_wlsom1_ek.dtb
> >
> > diff --git a/arch/arm/dts/at91-sama5d27_giantboard.dts
> b/arch/arm/dts/at91-sama5d27_giantboard.dts
> > new file mode 100644
> > index 00..e81ca60ca0
> > --- /dev/null
> > +++ b/arch/arm/dts/at91-sama5d27_giantboard.dts
> > @@ -0,0 +1,128 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * at91-sama5d27_giantboard.dts - Device Tree file for Giant Board
> > + *
> > + * Copyright (C) 2020 Greg Gallagher 
> > + *
> > + * Derived from at91-sama5d27_som1_ek.dts
> > + *
> > + * Copyright (C) 2017 Microchip Corporation
> > + *   Wenyou Yang 
> > + */
> > +/dts-v1/;
> > +#include "sama5d2.dtsi"
> > +#include "sama5d2-pinfunc.h"
> > +
> > +/ {
> > +   model = "Giant Board";
> > +   compatible = "atmel,sama5d27-giantboard", "atmel,sama5d2",
> "atmel,sama5";
> > +
> > +   memory {
> > +   reg = <0x2000 0x800>;
> > +   };
> > +
> > +   chosen {
> > +   u-boot,dm-pre-reloc;
> > +   stdout-path = &uart1;
> > +   };
> > +
> > +   ahb {
> > +   sdmmc1: sdio-host@b000 {
> > +   bus-width = <4>;
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <&pinctrl_sdmmc1_cmd_dat_default
> &pinctrl_sdmmc1_ck_cd_default>;
> > +   status = "okay";
> > +   u-boot,dm-pre-reloc;
> > +   };
> > +
> > +   apb {
> > +
> Please remove empty line here
>
Ack


> > +   uart1: serial@f802 {
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <&pinctrl_uart1_default>;
> > +   status = "okay";
> > +   u-boot,dm-pre-reloc;
> > +   };
> > +
> > +   i2c0: i2c@f8028000 {
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <&pinctrl_i2c0_default>;
> > +   status = "okay";
> > +   };
> > +
> > +   i2c1: i2c@fc028000 {
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <&pinctrl_i2c1_default>;
> > +   status = "okay";
> > +
> > +   pmic@5b {
> > +   compatible =
> "active-semi,act8945a";
> > +   reg = <0x5b>;
> > +   active-semi,vsel-low;
> > +   status = "okay";
> > +   };
> > +   };
> > +
> > +   pit: timer@f8048030 {
> > +   status = "okay";
> > +   u-boot,dm-pre-reloc;
> > +   };
> > +
> > +   sfr: sfr@f803 {
> > +   st

Re: Invitation: Regular U-Boot video call (Tuesday 19th)

[Simon Glass]

Hi Bin,

On Thu, 14 Jan 2021 at 19:12, Bin Meng  wrote:
>
> Hi Peng,
>
> On Fri, Jan 15, 2021 at 9:33 AM Peng Fan  wrote:
> >
> > Hi Simon,
> >
> > > Subject: Invitation: Regular U-Boot video call (Tuesday 19th)
> > >
> > > Hi,
> > >
> > > (This has been discussed for a while now so I thought I would just try it)
> > >
> > > As an experiment I'd like to set up a regular 30-minute U-Boot call for 
> > > people
> > > to discuss features, bugs, patches, etc.
> > >
> > > The meeting notes and details are here[1].
> >
> > The url is blocked by China. Do you have a direct google meet link, not 
> > using bit.ly?
> > I am in UTC + 8 timezone, not sure I am able to join, but please invite me.
> >
>
> Yep, but the google meet is also blocked :) That's why I suggest we
> use Zoom or something else for better experience.

Oh that's nuts.

What is the situation with monitoring of calls with Zoom? Are VPNs
available in China?

Regards,
Simon

Re: Invitation: Regular U-Boot video call (Tuesday 19th)

[Simon Glass]

Hi Peng,

On Thu, 14 Jan 2021 at 18:33, Peng Fan  wrote:
>
> Hi Simon,
>
> > Subject: Invitation: Regular U-Boot video call (Tuesday 19th)
> >
> > Hi,
> >
> > (This has been discussed for a while now so I thought I would just try it)
> >
> > As an experiment I'd like to set up a regular 30-minute U-Boot call for 
> > people
> > to discuss features, bugs, patches, etc.
> >
> > The meeting notes and details are here[1].
>
> The url is blocked by China. Do you have a direct google meet link, not using 
> bit.ly?
> I am in UTC + 8 timezone, not sure I am able to join, but please invite me.

Yes the link is here:

https://docs.google.com/document/d/1YBOMsbM19uSFyoJWnt7-PsOLBaevzQUgV-hiR88a5-o/edit

I don't know why it would be blocked in China. Can you access that one?

Regards,
Simon

[PATCH 15/15] gpio: Add a way to read 3-way strapping pins

[Simon Glass]

Using the internal vs. external pull resistors it is possible to get
27 different combinations from 3 strapping pins. Add an implementation
of this.

This involves updating the sandbox GPIO driver to model external and
(weaker) internal pull resistors. The get_value() method now takes account
of what is driving a pin:

   sandbox: GPIOD_EXT_DRIVEN - in which case GPIO_EXT_HIGH provides the
  value
   outside source - in which case GPIO_EXT_PULL_UP/DOWN indicates the
  external state and we work the final state using those flags and
  the internal GPIOD_PULL_UP/DOWN flags

Of course the outside source does not really exist in sandbox. We are just
modelling it for test purpose.

Signed-off-by: Simon Glass 
---

 arch/sandbox/include/asm/gpio.h |  5 +-
 drivers/gpio/gpio-uclass.c  | 78 ++
 drivers/gpio/sandbox.c  | 13 +++--
 include/asm-generic/gpio.h  | 37 +
 test/dm/gpio.c  | 98 +
 5 files changed, 226 insertions(+), 5 deletions(-)

diff --git a/arch/sandbox/include/asm/gpio.h b/arch/sandbox/include/asm/gpio.h
index edf78cb4131..097abfb299c 100644
--- a/arch/sandbox/include/asm/gpio.h
+++ b/arch/sandbox/include/asm/gpio.h
@@ -26,8 +26,11 @@
 /* Our own private GPIO flags, which musn't conflict with GPIOD_... */
 #define GPIOD_EXT_HIGH BIT(20) /* external source is high (else low) */
 #define GPIOD_EXT_DRIVEN   BIT(21) /* external source is driven */
+#define GPIOD_EXT_PULL_UP  BIT(22) /* GPIO has external pull-up */
+#define GPIOD_EXT_PULL_DOWNBIT(23) /* GPIO has external pull-down */
 
-#define GPIOD_SANDBOX_MASK GENMASK(21, 20)
+#define GPIOD_EXT_PULL (BIT(21) | BIT(22))
+#define GPIOD_SANDBOX_MASK GENMASK(23, 20)
 
 /**
  * Return the simulated value of a GPIO (used only in sandbox test code)
diff --git a/drivers/gpio/gpio-uclass.c b/drivers/gpio/gpio-uclass.c
index 77b40263bbd..984c07d1dfa 100644
--- a/drivers/gpio/gpio-uclass.c
+++ b/drivers/gpio/gpio-uclass.c
@@ -3,6 +3,8 @@
  * Copyright (c) 2013 Google, Inc
  */
 
+#define LOG_CATEGORY   UCLASS_GPIO
+
 #include 
 #include 
 #include 
@@ -20,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -708,6 +711,21 @@ int dm_gpio_set_dir_flags(struct gpio_desc *desc, ulong 
flags)
return dm_gpio_clrset_flags(desc, 0, flags);
 }
 
+int dm_gpios_clrset_flags(struct gpio_desc *desc, int count, ulong clr,
+ ulong set)
+{
+   int ret;
+   int i;
+
+   for (i = 0; i < count; i++) {
+   ret = dm_gpio_clrset_flags(&desc[i], clr, set);
+   if (ret)
+   return log_ret(ret);
+   }
+
+   return 0;
+}
+
 int dm_gpio_get_flags(struct gpio_desc *desc, ulong *flagsp)
 {
struct udevice *dev = desc->dev;
@@ -974,6 +992,66 @@ int dm_gpio_get_values_as_int(const struct gpio_desc 
*desc_list, int count)
return vector;
 }
 
+int dm_gpio_get_values_as_int_base3(struct gpio_desc *desc_list,
+   int count)
+{
+   static const char tristate[] = "01z";
+   enum {
+   PULLUP,
+   PULLDOWN,
+
+   NUM_OPTIONS,
+   };
+   int vals[NUM_OPTIONS];
+   uint mask;
+   uint vector = 0;
+   int ret, i;
+
+   for (i = 0; i < NUM_OPTIONS; i++) {
+   uint flags = GPIOD_IS_IN;
+
+   flags |= (i == PULLDOWN) ? GPIOD_PULL_DOWN : GPIOD_PULL_UP;
+   ret = dm_gpios_clrset_flags(desc_list, count, GPIOD_MASK_PULL,
+   flags);
+   if (ret)
+   return log_msg_ret("pu", ret);
+
+   /* Give the lines time to settle */
+   udelay(10);
+
+   ret = dm_gpio_get_values_as_int(desc_list, count);
+   if (ret < 0)
+   return log_msg_ret("get1", ret);
+   vals[i] = ret;
+   }
+
+   log_debug("values: %x %x, count = %d\n", vals[0], vals[1], count);
+   for (i = count - 1, mask = 1 << i; i >= 0; i--, mask >>= 1) {
+   uint pd = vals[PULLDOWN] & mask ? 1 : 0;
+   uint pu = vals[PULLUP] & mask ? 1 : 0;
+   uint digit;
+
+   /*
+* Get value with internal pulldown active. If this is 1 then
+* there is a stronger external pullup, which we call 1. If not
+* then call it 0.
+*/
+   digit = pd;
+
+   /*
+* If the values differ then the pin is floating so we call
+* this a 2.
+*/
+   if (pu != pd)
+   digit |= 2;
+   log_debug("%c ", tristate[digit]);
+   vector = 3 * vector + digit;
+   }
+   log_debug("vector=%d\n", vector);
+
+   return vector;
+}
+
 /**
  * gpio_request_tail: common

[PATCH 14/15] gpio: sandbox: Track whether a GPIO is driven

[Simon Glass]

Add a new flag to keep track of whether sandbox is driving the pin, or
whether it is expecting an input signal. If it is driving, then the value
of the pin is the value being driven (0 or 1). If not driving, then we
consider the value 0, since we don't currently handle things like pull-ups
yet.

Signed-off-by: Simon Glass 
---

 arch/sandbox/include/asm/gpio.h |  3 ++-
 drivers/gpio/sandbox.c  | 21 +++--
 2 files changed, 17 insertions(+), 7 deletions(-)

diff --git a/arch/sandbox/include/asm/gpio.h b/arch/sandbox/include/asm/gpio.h
index 3f267797644..edf78cb4131 100644
--- a/arch/sandbox/include/asm/gpio.h
+++ b/arch/sandbox/include/asm/gpio.h
@@ -25,8 +25,9 @@
 
 /* Our own private GPIO flags, which musn't conflict with GPIOD_... */
 #define GPIOD_EXT_HIGH BIT(20) /* external source is high (else low) */
+#define GPIOD_EXT_DRIVEN   BIT(21) /* external source is driven */
 
-#define GPIOD_SANDBOX_MASK BIT(20)
+#define GPIOD_SANDBOX_MASK GENMASK(21, 20)
 
 /**
  * Return the simulated value of a GPIO (used only in sandbox test code)
diff --git a/drivers/gpio/sandbox.c b/drivers/gpio/sandbox.c
index 11d4757abbb..b32f7ac529b 100644
--- a/drivers/gpio/sandbox.c
+++ b/drivers/gpio/sandbox.c
@@ -76,16 +76,22 @@ static int set_gpio_flag(struct udevice *dev, unsigned int 
offset, ulong flag,
 int sandbox_gpio_get_value(struct udevice *dev, unsigned offset)
 {
struct gpio_state *state = get_gpio_state(dev, offset);
+   bool val;
 
if (get_gpio_flag(dev, offset, GPIOD_IS_OUT))
debug("sandbox_gpio: get_value on output gpio %u\n", offset);
 
-   return state->flags & GPIOD_EXT_HIGH ? true : false;
+   if (state->flags & GPIOD_EXT_DRIVEN)
+   val = state->flags & GPIOD_EXT_HIGH;
+   else
+   val = false;
+
+   return val;
 }
 
 int sandbox_gpio_set_value(struct udevice *dev, unsigned offset, int value)
 {
-   set_gpio_flag(dev, offset, GPIOD_EXT_HIGH, value);
+   set_gpio_flag(dev, offset, GPIOD_EXT_DRIVEN | GPIOD_EXT_HIGH, value);
 
return 0;
 }
@@ -142,8 +148,8 @@ static int sb_gpio_direction_output(struct udevice *dev, 
unsigned offset,
ret = sandbox_gpio_set_direction(dev, offset, 1);
if (ret)
return ret;
-   ret = set_gpio_flag(dev, offset, GPIOD_IS_OUT_ACTIVE | GPIOD_EXT_HIGH,
-   value);
+   ret = set_gpio_flag(dev, offset, GPIOD_IS_OUT_ACTIVE |
+   GPIOD_EXT_DRIVEN | GPIOD_EXT_HIGH, value);
if (ret)
return ret;
 
@@ -171,8 +177,8 @@ static int sb_gpio_set_value(struct udevice *dev, unsigned 
offset, int value)
return -1;
}
 
-   ret = set_gpio_flag(dev, offset, GPIOD_IS_OUT_ACTIVE | GPIOD_EXT_HIGH,
-   value);
+   ret = set_gpio_flag(dev, offset, GPIOD_IS_OUT_ACTIVE |
+   GPIOD_EXT_DRIVEN | GPIOD_EXT_HIGH, value);
if (ret)
return ret;
 
@@ -217,10 +223,13 @@ static int sb_gpio_update_flags(struct udevice *dev, uint 
offset, ulong flags)
struct gpio_state *state = get_gpio_state(dev, offset);
 
if (flags & GPIOD_IS_OUT) {
+   flags |= GPIOD_EXT_DRIVEN;
if (flags & GPIOD_IS_OUT_ACTIVE)
flags |= GPIOD_EXT_HIGH;
else
flags &= ~GPIOD_EXT_HIGH;
+   } else {
+   flags |= state->flags & GPIOD_SANDBOX_MASK;
}
state->flags = flags;
 
-- 
2.30.0.284.gd98b1dd5eaa7-goog

[PATCH 13/15] gpio: x86: Drop the deprecated methods in intel_gpio

[Simon Glass]

We don't need to implement direction_input() and direction_output()
anymore. Drop them and use update_flags() instead.

Signed-off-by: Simon Glass 
---

 arch/x86/include/asm/intel_pinctrl_defs.h |  5 ++
 drivers/gpio/intel_gpio.c | 72 ---
 2 files changed, 43 insertions(+), 34 deletions(-)

diff --git a/arch/x86/include/asm/intel_pinctrl_defs.h 
b/arch/x86/include/asm/intel_pinctrl_defs.h
index 1ea141f082f..5d83d24bae2 100644
--- a/arch/x86/include/asm/intel_pinctrl_defs.h
+++ b/arch/x86/include/asm/intel_pinctrl_defs.h
@@ -11,6 +11,11 @@
 
 /* This file is included by device trees, so avoid BIT() macros */
 
+#define GPIO_DW_SIZE(x)(sizeof(u32) * (x))
+#define PAD_CFG_OFFSET(x, dw_num)  ((x) + GPIO_DW_SIZE(dw_num))
+#define PAD_CFG0_OFFSET(x) PAD_CFG_OFFSET(x, 0)
+#define PAD_CFG1_OFFSET(x) PAD_CFG_OFFSET(x, 1)
+
 #define PAD_CFG0_TX_STATE_BIT  0
 #define PAD_CFG0_TX_STATE  (1 << PAD_CFG0_TX_STATE_BIT)
 #define PAD_CFG0_RX_STATE_BIT  1
diff --git a/drivers/gpio/intel_gpio.c b/drivers/gpio/intel_gpio.c
index eda95485c93..d596bed2465 100644
--- a/drivers/gpio/intel_gpio.c
+++ b/drivers/gpio/intel_gpio.c
@@ -3,6 +3,8 @@
  * Copyright 2019 Google LLC
  */
 
+#define LOG_CATEGORY   UCLASS_GPIO
+
 #include 
 #include 
 #include 
@@ -23,38 +25,6 @@
 #include 
 #include 
 
-static int intel_gpio_direction_input(struct udevice *dev, uint offset)
-{
-   struct udevice *pinctrl = dev_get_parent(dev);
-   uint config_offset;
-
-   config_offset = intel_pinctrl_get_config_reg_offset(pinctrl, offset);
-
-   pcr_clrsetbits32(pinctrl, config_offset,
-PAD_CFG0_MODE_MASK | PAD_CFG0_TX_STATE |
- PAD_CFG0_RX_DISABLE,
-PAD_CFG0_MODE_GPIO | PAD_CFG0_TX_DISABLE);
-
-   return 0;
-}
-
-static int intel_gpio_direction_output(struct udevice *dev, uint offset,
-  int value)
-{
-   struct udevice *pinctrl = dev_get_parent(dev);
-   uint config_offset;
-
-   config_offset = intel_pinctrl_get_config_reg_offset(pinctrl, offset);
-
-   pcr_clrsetbits32(pinctrl, config_offset,
-PAD_CFG0_MODE_MASK | PAD_CFG0_RX_STATE |
- PAD_CFG0_TX_DISABLE | PAD_CFG0_TX_STATE,
-PAD_CFG0_MODE_GPIO | PAD_CFG0_RX_DISABLE |
- (value ? PAD_CFG0_TX_STATE : 0));
-
-   return 0;
-}
-
 static int intel_gpio_get_value(struct udevice *dev, uint offset)
 {
struct udevice *pinctrl = dev_get_parent(dev);
@@ -130,6 +100,41 @@ static int intel_gpio_xlate(struct udevice *orig_dev, 
struct gpio_desc *desc,
return 0;
 }
 
+static int intel_gpio_update_flags(struct udevice *dev, unsigned int offset,
+  ulong flags)
+{
+   struct udevice *pinctrl = dev_get_parent(dev);
+   u32 bic0 = 0, bic1 = 0;
+   u32 or0, or1;
+   uint config_offset;
+
+   config_offset = intel_pinctrl_get_config_reg_offset(pinctrl, offset);
+
+   if (flags & GPIOD_IS_OUT) {
+   bic0 |= PAD_CFG0_MODE_MASK | PAD_CFG0_RX_STATE |
+   PAD_CFG0_TX_DISABLE;
+   or0 |= PAD_CFG0_MODE_GPIO | PAD_CFG0_RX_DISABLE;
+   } else if (flags & GPIOD_IS_IN) {
+   bic0 |= PAD_CFG0_MODE_MASK | PAD_CFG0_TX_STATE |
+   PAD_CFG0_RX_DISABLE;
+   or0 |= PAD_CFG0_MODE_GPIO | PAD_CFG0_TX_DISABLE;
+   }
+   if (flags & GPIOD_PULL_UP) {
+   bic1 |= PAD_CFG1_PULL_MASK;
+   or1 |= PAD_CFG1_PULL_UP_20K;
+   } else if (flags & GPIOD_PULL_DOWN) {
+   bic1 |= PAD_CFG1_PULL_MASK;
+   or1 |= PAD_CFG1_PULL_DN_20K;
+   }
+
+   pcr_clrsetbits32(pinctrl, PAD_CFG0_OFFSET(config_offset), bic0, or0);
+   pcr_clrsetbits32(pinctrl, PAD_CFG1_OFFSET(config_offset), bic1, or1);
+   log_debug("%s: flags=%lx, offset=%x, config_offset=%x, %x/%x %x/%x\n",
+ dev->name, flags, offset, config_offset, bic0, or0, bic1, 
or1);
+
+   return 0;
+}
+
 #if CONFIG_IS_ENABLED(ACPIGEN)
 static int intel_gpio_get_acpi(const struct gpio_desc *desc,
   struct acpi_gpio *gpio)
@@ -177,12 +182,11 @@ static int intel_gpio_of_to_plat(struct udevice *dev)
 }
 
 static const struct dm_gpio_ops gpio_intel_ops = {
-   .direction_input= intel_gpio_direction_input,
-   .direction_output   = intel_gpio_direction_output,
.get_value  = intel_gpio_get_value,
.set_value  = intel_gpio_set_value,
.get_function   = intel_gpio_get_function,
.xlate  = intel_gpio_xlate,
+   .update_flags   = intel_gpio_update_flags,
 #if CONFIG_IS_ENABLED(ACPIGEN)
.get_acpi   = intel_gpio_get_acpi,
 #endif
-- 
2.30.0.284

[PATCH 11/15] gpio: Replace direction_input() and direction_output()

[Simon Glass]

The new update_flags() method is more flexible since it allows the
driver to see the full flags all at once. Use that in preference to these
two functions. Add comments to that effect.

Signed-off-by: Simon Glass 
---

 drivers/gpio/gpio-uclass.c | 15 ++-
 include/asm-generic/gpio.h | 26 +-
 2 files changed, 31 insertions(+), 10 deletions(-)

diff --git a/drivers/gpio/gpio-uclass.c b/drivers/gpio/gpio-uclass.c
index 05627ecdc30..68ed65d0899 100644
--- a/drivers/gpio/gpio-uclass.c
+++ b/drivers/gpio/gpio-uclass.c
@@ -512,13 +512,10 @@ int gpio_direction_input(unsigned gpio)
int ret;
 
ret = gpio_to_device(gpio, &desc);
-   if (ret)
-   return ret;
-   ret = check_reserved(&desc, "dir_input");
if (ret)
return ret;
 
-   return gpio_get_ops(desc.dev)->direction_input(desc.dev, desc.offset);
+   return dm_gpio_clrset_flags(&desc, GPIOD_MASK_DIR, GPIOD_IS_IN);
 }
 
 /**
@@ -533,17 +530,17 @@ int gpio_direction_input(unsigned gpio)
 int gpio_direction_output(unsigned gpio, int value)
 {
struct gpio_desc desc;
+   ulong flags;
int ret;
 
ret = gpio_to_device(gpio, &desc);
-   if (ret)
-   return ret;
-   ret = check_reserved(&desc, "dir_output");
if (ret)
return ret;
 
-   return gpio_get_ops(desc.dev)->direction_output(desc.dev,
-   desc.offset, value);
+   flags = GPIOD_IS_OUT;
+   if (value)
+   flags |= GPIOD_IS_OUT_ACTIVE;
+   return dm_gpio_clrset_flags(&desc, GPIOD_MASK_DIR, flags);
 }
 
 static int _gpio_get_value(const struct gpio_desc *desc)
diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
index 4a657b1bd2b..4628d937259 100644
--- a/include/asm-generic/gpio.h
+++ b/include/asm-generic/gpio.h
@@ -266,10 +266,32 @@ int gpio_xlate_offs_flags(struct udevice *dev, struct 
gpio_desc *desc,
 struct dm_gpio_ops {
int (*request)(struct udevice *dev, unsigned offset, const char *label);
int (*rfree)(struct udevice *dev, unsigned int offset);
+
+   /**
+* direction_input() - deprecated
+*
+* Equivalent to update_flags(...GPIOD_IS_IN)
+*/
int (*direction_input)(struct udevice *dev, unsigned offset);
+
+   /**
+* direction_output() - deprecated
+*
+* Equivalent to update_flags(...GPIOD_IS_OUT) with GPIOD_IS_OUT_ACTIVE
+* also set if @value
+*/
int (*direction_output)(struct udevice *dev, unsigned offset,
int value);
+
int (*get_value)(struct udevice *dev, unsigned offset);
+
+   /**
+* set_value() - Sets the GPIO value of an output
+*
+* If the driver provides an @update_flags() method then that is used
+* in preference to this, with GPIOD_IS_OUT_ACTIVE set according to
+* @value.
+*/
int (*set_value)(struct udevice *dev, unsigned offset, int value);
/**
 * get_function() Get the GPIO function
@@ -328,7 +350,9 @@ struct dm_gpio_ops {
 * uclass, so the driver always sees the value that should be set at the
 * pin (1=high, 0=low).
 *
-* This method is optional.
+* This method is required and should be implemented by new drivers. At
+* some point, it will supersede direction_input() and
+* direction_output(), which wil be removed.
 *
 * @dev:GPIO device
 * @offset: GPIO offset within that device
-- 
2.30.0.284.gd98b1dd5eaa7-goog

[PATCH 12/15] gpio: Use an 'ops' variable everywhere

[Simon Glass]

Update this driver to use the common method of putting the driver
operations in an 'ops' variable install of calling gpio_get_ops()
repeatedly. Make it const since operations do not change.

Signed-off-by: Simon Glass 
---

 drivers/gpio/gpio-uclass.c | 25 ++---
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/drivers/gpio/gpio-uclass.c b/drivers/gpio/gpio-uclass.c
index 68ed65d0899..77b40263bbd 100644
--- a/drivers/gpio/gpio-uclass.c
+++ b/drivers/gpio/gpio-uclass.c
@@ -219,7 +219,7 @@ int gpio_xlate_offs_flags(struct udevice *dev, struct 
gpio_desc *desc,
 static int gpio_find_and_xlate(struct gpio_desc *desc,
   struct ofnode_phandle_args *args)
 {
-   struct dm_gpio_ops *ops = gpio_get_ops(desc->dev);
+   const struct dm_gpio_ops *ops = gpio_get_ops(desc->dev);
 
if (ops->xlate)
return ops->xlate(desc->dev, desc, args);
@@ -352,6 +352,7 @@ int gpio_hog_lookup_name(const char *name, struct gpio_desc 
**desc)
 
 int dm_gpio_request(struct gpio_desc *desc, const char *label)
 {
+   const struct dm_gpio_ops *ops = gpio_get_ops(desc->dev);
struct udevice *dev = desc->dev;
struct gpio_dev_priv *uc_priv;
char *str;
@@ -363,8 +364,8 @@ int dm_gpio_request(struct gpio_desc *desc, const char 
*label)
str = strdup(label);
if (!str)
return -ENOMEM;
-   if (gpio_get_ops(dev)->request) {
-   ret = gpio_get_ops(dev)->request(dev, desc->offset, label);
+   if (ops->request) {
+   ret = ops->request(dev, desc->offset, label);
if (ret) {
free(str);
return ret;
@@ -441,14 +442,15 @@ int gpio_requestf(unsigned gpio, const char *fmt, ...)
 
 int _dm_gpio_free(struct udevice *dev, uint offset)
 {
+   const struct dm_gpio_ops *ops = gpio_get_ops(dev);
struct gpio_dev_priv *uc_priv;
int ret;
 
uc_priv = dev_get_uclass_priv(dev);
if (!uc_priv->name[offset])
return -ENXIO;
-   if (gpio_get_ops(dev)->rfree) {
-   ret = gpio_get_ops(dev)->rfree(dev, offset);
+   if (ops->rfree) {
+   ret = ops->rfree(dev, offset);
if (ret)
return ret;
}
@@ -545,9 +547,10 @@ int gpio_direction_output(unsigned gpio, int value)
 
 static int _gpio_get_value(const struct gpio_desc *desc)
 {
+   const struct dm_gpio_ops *ops = gpio_get_ops(desc->dev);
int value;
 
-   value = gpio_get_ops(desc->dev)->get_value(desc->dev, desc->offset);
+   value = ops->get_value(desc->dev, desc->offset);
 
return desc->flags & GPIOD_ACTIVE_LOW ? !value : value;
 }
@@ -643,7 +646,7 @@ static int check_dir_flags(ulong flags)
 static int _dm_gpio_update_flags(struct gpio_desc *desc, ulong flags)
 {
struct udevice *dev = desc->dev;
-   struct dm_gpio_ops *ops = gpio_get_ops(dev);
+   const struct dm_gpio_ops *ops = gpio_get_ops(dev);
struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev);
int ret = 0;
 
@@ -709,7 +712,7 @@ int dm_gpio_get_flags(struct gpio_desc *desc, ulong *flagsp)
 {
struct udevice *dev = desc->dev;
int ret, value;
-   struct dm_gpio_ops *ops = gpio_get_ops(dev);
+   const struct dm_gpio_ops *ops = gpio_get_ops(dev);
ulong flags;
 
ret = check_reserved(desc, "get_flags");
@@ -807,7 +810,7 @@ static int get_function(struct udevice *dev, int offset, 
bool skip_unused,
const char **namep)
 {
struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev);
-   struct dm_gpio_ops *ops = gpio_get_ops(dev);
+   const struct dm_gpio_ops *ops = gpio_get_ops(dev);
 
BUILD_BUG_ON(GPIOF_COUNT != ARRAY_SIZE(gpio_function));
if (!device_active(dev))
@@ -844,7 +847,7 @@ int gpio_get_raw_function(struct udevice *dev, int offset, 
const char **namep)
 
 int gpio_get_status(struct udevice *dev, int offset, char *buf, int buffsize)
 {
-   struct dm_gpio_ops *ops = gpio_get_ops(dev);
+   const struct dm_gpio_ops *ops = gpio_get_ops(dev);
struct gpio_dev_priv *priv;
char *str = buf;
int func;
@@ -884,7 +887,7 @@ int gpio_get_status(struct udevice *dev, int offset, char 
*buf, int buffsize)
 #if CONFIG_IS_ENABLED(ACPIGEN)
 int gpio_get_acpi(const struct gpio_desc *desc, struct acpi_gpio *gpio)
 {
-   struct dm_gpio_ops *ops;
+   const struct dm_gpio_ops *ops;
 
memset(gpio, '\0', sizeof(*gpio));
if (!dm_gpio_is_valid(desc)) {
-- 
2.30.0.284.gd98b1dd5eaa7-goog

[PATCH 10/15] dm: gpio: Add a way to update flags

[Simon Glass]

It is convenient to be able to adjust some of the flags for a GPIO while
leaving others alone. Add a function for this.

Update dm_gpio_set_dir_flags() to make use of this.

Also update dm_gpio_set_value() to use this also, since this allows the
open-drain / open-source features to be implemented directly in the
driver, rather than using the uclass workaround.

Update the sandbox tests accordingly. This involves a lot of changes to
dm_test_gpio_opendrain_opensource() since we no-longer have the direciion
being reported differently depending on the open drain/open source flags.

Signed-off-by: Simon Glass 
---

 drivers/gpio/gpio-uclass.c |  65 ++-
 include/asm-generic/gpio.h |  25 
 test/dm/gpio.c | 125 -
 3 files changed, 184 insertions(+), 31 deletions(-)

diff --git a/drivers/gpio/gpio-uclass.c b/drivers/gpio/gpio-uclass.c
index aa0e3852122..05627ecdc30 100644
--- a/drivers/gpio/gpio-uclass.c
+++ b/drivers/gpio/gpio-uclass.c
@@ -568,6 +568,7 @@ int dm_gpio_get_value(const struct gpio_desc *desc)
 
 int dm_gpio_set_value(const struct gpio_desc *desc, int value)
 {
+   const struct dm_gpio_ops *ops;
int ret;
 
ret = check_reserved(desc, "set_value");
@@ -577,21 +578,33 @@ int dm_gpio_set_value(const struct gpio_desc *desc, int 
value)
if (desc->flags & GPIOD_ACTIVE_LOW)
value = !value;
 
+   /* GPIOD_ are directly managed by driver in update_flags */
+   ops = gpio_get_ops(desc->dev);
+   if (ops->update_flags) {
+   ulong flags = desc->flags;
+
+   if (value)
+   flags |= GPIOD_IS_OUT_ACTIVE;
+   else
+   flags &= ~GPIOD_IS_OUT_ACTIVE;
+   return ops->update_flags(desc->dev, desc->offset, flags);
+   }
+
/*
 * Emulate open drain by not actively driving the line high or
 * Emulate open source by not actively driving the line low
 */
if ((desc->flags & GPIOD_OPEN_DRAIN && value) ||
(desc->flags & GPIOD_OPEN_SOURCE && !value))
-   return gpio_get_ops(desc->dev)->direction_input(desc->dev,
-   desc->offset);
+   return ops->direction_input(desc->dev, desc->offset);
else if (desc->flags & GPIOD_OPEN_DRAIN ||
 desc->flags & GPIOD_OPEN_SOURCE)
-   return gpio_get_ops(desc->dev)->direction_output(desc->dev,
-   desc->offset,
-   value);
+   return ops->direction_output(desc->dev, desc->offset, value);
+
+   ret = ops->set_value(desc->dev, desc->offset, value);
+   if (ret)
+   return ret;
 
-   gpio_get_ops(desc->dev)->set_value(desc->dev, desc->offset, value);
return 0;
 }
 
@@ -619,6 +632,17 @@ static int check_dir_flags(ulong flags)
return 0;
 }
 
+/**
+ * _dm_gpio_update_flags() - Send flags to the driver
+ *
+ * This uses the best available method to send the given flags to the driver.
+ * Note that if flags & GPIOD_ACTIVE_LOW, the driver sees the opposite value
+ * of GPIOD_IS_OUT_ACTIVE.
+ *
+ * @desc:  GPIO description
+ * @flags: flags value to set
+ * @return 0 if OK, -ve on error
+ */
 static int _dm_gpio_update_flags(struct gpio_desc *desc, ulong flags)
 {
struct udevice *dev = desc->dev;
@@ -637,6 +661,11 @@ static int _dm_gpio_update_flags(struct gpio_desc *desc, 
ulong flags)
return ret;
}
 
+   /* If active low, invert the output state */
+   if ((flags & (GPIOD_IS_OUT | GPIOD_ACTIVE_LOW)) ==
+   (GPIOD_IS_OUT | GPIOD_ACTIVE_LOW))
+   flags ^= GPIOD_IS_OUT_ACTIVE;
+
/* GPIOD_ are directly managed by driver in update_flags */
if (ops->update_flags) {
ret = ops->update_flags(dev, desc->offset, flags);
@@ -649,26 +678,34 @@ static int _dm_gpio_update_flags(struct gpio_desc *desc, 
ulong flags)
}
}
 
-   /* save the flags also in descriptor */
-   if (!ret)
-   desc->flags = flags;
-
return ret;
 }
 
-int dm_gpio_set_dir_flags(struct gpio_desc *desc, ulong flags)
+int dm_gpio_clrset_flags(struct gpio_desc *desc, ulong clr, ulong set)
 {
+   ulong flags;
int ret;
 
ret = check_reserved(desc, "set_dir_flags");
if (ret)
return ret;
 
-   /* combine the requested flags (for IN/OUT) and the descriptor flags */
-   flags |= desc->flags;
+   flags = (desc->flags & ~clr) | set;
+
ret = _dm_gpio_update_flags(desc, flags);
+   if (ret)
+   return ret;
 
-   return ret;
+   /* save the flags also in descriptor */
+   desc->flags = flags;
+
+   return 0;
+}
+
+int dm_gpio_set_dir_flags(struct gpio_desc *desc, ul

[PATCH 09/15] gpio: sandbox: Make sandbox_gpio_set_flags() set all flags

[Simon Glass]

Allow this function to see all flags, including the internal sandbox ones.
This allows the tests to fully control the behaviour of the driver.

To make this work, move the setting of GPIOD_EXT_HIGH -to where the flags
are updated via driver model, rather than the sandbox 'back door'.

Signed-off-by: Simon Glass 
---

 drivers/gpio/sandbox.c | 21 ++---
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/drivers/gpio/sandbox.c b/drivers/gpio/sandbox.c
index ebc160cb849..11d4757abbb 100644
--- a/drivers/gpio/sandbox.c
+++ b/drivers/gpio/sandbox.c
@@ -114,9 +114,7 @@ int sandbox_gpio_set_flags(struct udevice *dev, uint 
offset, ulong flags)
 {
struct gpio_state *state = get_gpio_state(dev, offset);
 
-   if (flags & GPIOD_IS_OUT_ACTIVE)
-   flags |= GPIOD_EXT_HIGH;
-   state->flags = (state->flags & GPIOD_SANDBOX_MASK) | flags;
+   state->flags = flags;
 
return 0;
 }
@@ -213,17 +211,26 @@ static int sb_gpio_xlate(struct udevice *dev, struct 
gpio_desc *desc,
return 0;
 }
 
-static int sb_gpio_update_flags(struct udevice *dev, uint offset, ulong newf)
+static int sb_gpio_update_flags(struct udevice *dev, uint offset, ulong flags)
 {
-   debug("%s: offset:%u, flags = %lx\n", __func__, offset, newf);
+   debug("%s: offset:%u, flags = %lx\n", __func__, offset, flags);
+   struct gpio_state *state = get_gpio_state(dev, offset);
+
+   if (flags & GPIOD_IS_OUT) {
+   if (flags & GPIOD_IS_OUT_ACTIVE)
+   flags |= GPIOD_EXT_HIGH;
+   else
+   flags &= ~GPIOD_EXT_HIGH;
+   }
+   state->flags = flags;
 
-   return sandbox_gpio_set_flags(dev, offset, newf);
+   return 0;
 }
 
 static int sb_gpio_get_flags(struct udevice *dev, uint offset, ulong *flagsp)
 {
debug("%s: offset:%u\n", __func__, offset);
-   *flagsp = *get_gpio_flags(dev, offset);
+   *flagsp = *get_gpio_flags(dev, offset) & ~GPIOD_SANDBOX_MASK;
 
return 0;
 }
-- 
2.30.0.284.gd98b1dd5eaa7-goog

[PATCH 08/15] gpio: sandbox: Fully separate pin value from output value

[Simon Glass]

At present we have the concept of a pin's external value. This is what
is used when getting the value of a pin. But we still set the
GPIOD_IS_OUT_ACTIVE flag when changing the value. This is not actually
correct, since if the pin changes from output to input, the external
value need not change. Adjust the logic for this difference.

Signed-off-by: Simon Glass 
---

 drivers/gpio/sandbox.c | 24 
 1 file changed, 20 insertions(+), 4 deletions(-)

diff --git a/drivers/gpio/sandbox.c b/drivers/gpio/sandbox.c
index 52e73e2300a..ebc160cb849 100644
--- a/drivers/gpio/sandbox.c
+++ b/drivers/gpio/sandbox.c
@@ -85,7 +85,7 @@ int sandbox_gpio_get_value(struct udevice *dev, unsigned 
offset)
 
 int sandbox_gpio_set_value(struct udevice *dev, unsigned offset, int value)
 {
-   set_gpio_flag(dev, offset, GPIOD_IS_OUT_ACTIVE | GPIOD_EXT_HIGH, value);
+   set_gpio_flag(dev, offset, GPIOD_EXT_HIGH, value);
 
return 0;
 }
@@ -137,10 +137,19 @@ static int sb_gpio_direction_input(struct udevice *dev, 
unsigned offset)
 static int sb_gpio_direction_output(struct udevice *dev, unsigned offset,
int value)
 {
+   int ret;
+
debug("%s: offset:%u, value = %d\n", __func__, offset, value);
 
-   return sandbox_gpio_set_direction(dev, offset, 1) |
-   sandbox_gpio_set_value(dev, offset, value);
+   ret = sandbox_gpio_set_direction(dev, offset, 1);
+   if (ret)
+   return ret;
+   ret = set_gpio_flag(dev, offset, GPIOD_IS_OUT_ACTIVE | GPIOD_EXT_HIGH,
+   value);
+   if (ret)
+   return ret;
+
+   return 0;
 }
 
 /* read GPIO IN value of port 'offset' */
@@ -154,6 +163,8 @@ static int sb_gpio_get_value(struct udevice *dev, unsigned 
offset)
 /* write GPIO OUT value to port 'offset' */
 static int sb_gpio_set_value(struct udevice *dev, unsigned offset, int value)
 {
+   int ret;
+
debug("%s: offset:%u, value = %d\n", __func__, offset, value);
 
if (!sandbox_gpio_get_direction(dev, offset)) {
@@ -162,7 +173,12 @@ static int sb_gpio_set_value(struct udevice *dev, unsigned 
offset, int value)
return -1;
}
 
-   return sandbox_gpio_set_value(dev, offset, value);
+   ret = set_gpio_flag(dev, offset, GPIOD_IS_OUT_ACTIVE | GPIOD_EXT_HIGH,
+   value);
+   if (ret)
+   return ret;
+
+   return 0;
 }
 
 static int sb_gpio_get_function(struct udevice *dev, unsigned offset)
-- 
2.30.0.284.gd98b1dd5eaa7-goog

[PATCH 07/15] gpio: sandbox: Use a separate flag for the value

[Simon Glass]

At present with the sandbox GPIO driver it is not possible to change the
value of GPIOD_IS_OUT_ACTIVE unless the GPIO is an output. This makes it
hard to test changing the flags since we need to be aware of the internal
workings of the driver.

The feature is designed to aid testing.

Split this feature out into a separate sandbox-specific flag, so that the
flags can change unimpeded. This will make it easier to allow updating the
flags in a future patch.

Signed-off-by: Simon Glass 
---

 arch/sandbox/include/asm/gpio.h |  5 
 drivers/gpio/sandbox.c  | 43 +++--
 2 files changed, 25 insertions(+), 23 deletions(-)

diff --git a/arch/sandbox/include/asm/gpio.h b/arch/sandbox/include/asm/gpio.h
index 20d78296551..3f267797644 100644
--- a/arch/sandbox/include/asm/gpio.h
+++ b/arch/sandbox/include/asm/gpio.h
@@ -23,6 +23,11 @@
  */
 #include 
 
+/* Our own private GPIO flags, which musn't conflict with GPIOD_... */
+#define GPIOD_EXT_HIGH BIT(20) /* external source is high (else low) */
+
+#define GPIOD_SANDBOX_MASK BIT(20)
+
 /**
  * Return the simulated value of a GPIO (used only in sandbox test code)
  *
diff --git a/drivers/gpio/sandbox.c b/drivers/gpio/sandbox.c
index 9ce5d823505..52e73e2300a 100644
--- a/drivers/gpio/sandbox.c
+++ b/drivers/gpio/sandbox.c
@@ -59,12 +59,12 @@ static int get_gpio_flag(struct udevice *dev, unsigned int 
offset, ulong flag)
 static int set_gpio_flag(struct udevice *dev, unsigned int offset, ulong flag,
 int value)
 {
-   ulong *gpio = get_gpio_flags(dev, offset);
+   struct gpio_state *state = get_gpio_state(dev, offset);
 
if (value)
-   *gpio |= flag;
+   state->flags |= flag;
else
-   *gpio &= ~flag;
+   state->flags &= ~flag;
 
return 0;
 }
@@ -75,14 +75,19 @@ static int set_gpio_flag(struct udevice *dev, unsigned int 
offset, ulong flag,
 
 int sandbox_gpio_get_value(struct udevice *dev, unsigned offset)
 {
+   struct gpio_state *state = get_gpio_state(dev, offset);
+
if (get_gpio_flag(dev, offset, GPIOD_IS_OUT))
debug("sandbox_gpio: get_value on output gpio %u\n", offset);
-   return get_gpio_flag(dev, offset, GPIOD_IS_OUT_ACTIVE);
+
+   return state->flags & GPIOD_EXT_HIGH ? true : false;
 }
 
 int sandbox_gpio_set_value(struct udevice *dev, unsigned offset, int value)
 {
-   return set_gpio_flag(dev, offset, GPIOD_IS_OUT_ACTIVE, value);
+   set_gpio_flag(dev, offset, GPIOD_IS_OUT_ACTIVE | GPIOD_EXT_HIGH, value);
+
+   return 0;
 }
 
 int sandbox_gpio_get_direction(struct udevice *dev, unsigned offset)
@@ -93,19 +98,25 @@ int sandbox_gpio_get_direction(struct udevice *dev, 
unsigned offset)
 int sandbox_gpio_set_direction(struct udevice *dev, unsigned offset, int 
output)
 {
set_gpio_flag(dev, offset, GPIOD_IS_OUT, output);
-   set_gpio_flag(dev, offset, GPIOD_IS_IN, !(output));
+   set_gpio_flag(dev, offset, GPIOD_IS_IN, !output);
 
return 0;
 }
 
 ulong sandbox_gpio_get_flags(struct udevice *dev, uint offset)
 {
-   return *get_gpio_flags(dev, offset);
+   ulong flags = *get_gpio_flags(dev, offset);
+
+   return flags & ~GPIOD_SANDBOX_MASK;
 }
 
 int sandbox_gpio_set_flags(struct udevice *dev, uint offset, ulong flags)
 {
-   *get_gpio_flags(dev, offset) = flags;
+   struct gpio_state *state = get_gpio_state(dev, offset);
+
+   if (flags & GPIOD_IS_OUT_ACTIVE)
+   flags |= GPIOD_EXT_HIGH;
+   state->flags = (state->flags & GPIOD_SANDBOX_MASK) | flags;
 
return 0;
 }
@@ -188,23 +199,9 @@ static int sb_gpio_xlate(struct udevice *dev, struct 
gpio_desc *desc,
 
 static int sb_gpio_update_flags(struct udevice *dev, uint offset, ulong newf)
 {
-   ulong *flags;
-
debug("%s: offset:%u, flags = %lx\n", __func__, offset, newf);
 
-   flags = get_gpio_flags(dev, offset);
-
-   /*
-* For testing purposes keep the output value when switching to input.
-* This allows us to manipulate the input value via the gpio command.
-*/
-   if (newf & GPIOD_IS_IN)
-   *flags = (newf & ~GPIOD_IS_OUT_ACTIVE) |
-   (*flags & GPIOD_IS_OUT_ACTIVE);
-   else
-   *flags = newf;
-
-   return 0;
+   return sandbox_gpio_set_flags(dev, offset, newf);
 }
 
 static int sb_gpio_get_flags(struct udevice *dev, uint offset, ulong *flagsp)
-- 
2.30.0.284.gd98b1dd5eaa7-goog

[PATCH 05/15] gpio: Drop dm_gpio_set_dir()

[Simon Glass]

This function is not used. Drop it.

Signed-off-by: Simon Glass 
---

 drivers/gpio/gpio-uclass.c | 11 ---
 include/asm-generic/gpio.h | 11 ---
 2 files changed, 22 deletions(-)

diff --git a/drivers/gpio/gpio-uclass.c b/drivers/gpio/gpio-uclass.c
index 864a9003245..aa0e3852122 100644
--- a/drivers/gpio/gpio-uclass.c
+++ b/drivers/gpio/gpio-uclass.c
@@ -671,17 +671,6 @@ int dm_gpio_set_dir_flags(struct gpio_desc *desc, ulong 
flags)
return ret;
 }
 
-int dm_gpio_set_dir(struct gpio_desc *desc)
-{
-   int ret;
-
-   ret = check_reserved(desc, "set_dir");
-   if (ret)
-   return ret;
-
-   return _dm_gpio_update_flags(desc, desc->flags);
-}
-
 int dm_gpio_get_flags(struct gpio_desc *desc, ulong *flagsp)
 {
struct udevice *dev = desc->dev;
diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
index 5ecb73c138d..30ff5feb160 100644
--- a/include/asm-generic/gpio.h
+++ b/include/asm-generic/gpio.h
@@ -659,17 +659,6 @@ int dm_gpio_get_value(const struct gpio_desc *desc);
 
 int dm_gpio_set_value(const struct gpio_desc *desc, int value);
 
-/**
- * dm_gpio_set_dir() - Set the direction for a GPIO
- *
- * This sets up the direction according to the GPIO flags: desc->flags.
- *
- * @desc:  GPIO description containing device, offset and flags,
- * previously returned by gpio_request_by_name()
- * @return 0 if OK, -ve on error
- */
-int dm_gpio_set_dir(struct gpio_desc *desc);
-
 /**
  * dm_gpio_set_dir_flags() - Set direction using description and added flags
  *
-- 
2.30.0.284.gd98b1dd5eaa7-goog

[PATCH 06/15] gpio: sandbox: Rename GPIO dir_flags to flags

[Simon Glass]

Adjust the terminology in this driver to reflect that fact that all flags
are handled, not just direction flags.

Create a new access function to get the full GPIO state, not just the
direction flags. Drop the static invalid_dir_flags since we can rely on a
segfault if something is wrong.

Signed-off-by: Simon Glass 
---

 arch/sandbox/include/asm/gpio.h |  8 ++--
 drivers/gpio/sandbox.c  | 65 ++---
 test/dm/gpio.c  | 18 -
 3 files changed, 49 insertions(+), 42 deletions(-)

diff --git a/arch/sandbox/include/asm/gpio.h b/arch/sandbox/include/asm/gpio.h
index df4ba4fb5f3..20d78296551 100644
--- a/arch/sandbox/include/asm/gpio.h
+++ b/arch/sandbox/include/asm/gpio.h
@@ -69,17 +69,17 @@ int sandbox_gpio_set_direction(struct udevice *dev, 
unsigned int offset,
  * @param offset   GPIO offset within bank
  * @return dir_flags: bitfield accesses by GPIOD_ defines
  */
-ulong sandbox_gpio_get_dir_flags(struct udevice *dev, unsigned int offset);
+ulong sandbox_gpio_get_flags(struct udevice *dev, unsigned int offset);
 
 /**
  * Set the simulated flags of a GPIO (used only in sandbox test code)
  *
  * @param dev  device to use
  * @param offset   GPIO offset within bank
- * @param flagsdir_flags: bitfield accesses by GPIOD_ defines
+ * @param flagsbitfield accesses by GPIOD_ defines
  * @return -1 on error, 0 if ok
  */
-int sandbox_gpio_set_dir_flags(struct udevice *dev, unsigned int offset,
-  ulong flags);
+int sandbox_gpio_set_flags(struct udevice *dev, unsigned int offset,
+  ulong flags);
 
 #endif
diff --git a/drivers/gpio/sandbox.c b/drivers/gpio/sandbox.c
index fd14d4e8b5f..9ce5d823505 100644
--- a/drivers/gpio/sandbox.c
+++ b/drivers/gpio/sandbox.c
@@ -22,34 +22,44 @@
 
 struct gpio_state {
const char *label;  /* label given by requester */
-   ulong dir_flags;/* dir_flags (GPIOD_...) */
+   ulong flags;/* flags (GPIOD_...) */
 };
 
-/* Access routines for GPIO dir flags */
-static ulong *get_gpio_dir_flags(struct udevice *dev, unsigned int offset)
+/* Access routines for GPIO info */
+static struct gpio_state *get_gpio_state(struct udevice *dev, uint offset)
 {
struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev);
struct gpio_state *state = dev_get_priv(dev);
 
if (offset >= uc_priv->gpio_count) {
-   static ulong invalid_dir_flags;
printf("sandbox_gpio: error: invalid gpio %u\n", offset);
-   return &invalid_dir_flags;
+   return NULL;
}
 
-   return &state[offset].dir_flags;
+   return &state[offset];
+}
+
+/* Access routines for GPIO dir flags */
+static ulong *get_gpio_flags(struct udevice *dev, unsigned int offset)
+{
+   struct gpio_state *state = get_gpio_state(dev, offset);
+
+   if (!state)
+   return NULL;
+
+   return &state->flags;
 
 }
 
 static int get_gpio_flag(struct udevice *dev, unsigned int offset, ulong flag)
 {
-   return (*get_gpio_dir_flags(dev, offset) & flag) != 0;
+   return (*get_gpio_flags(dev, offset) & flag) != 0;
 }
 
 static int set_gpio_flag(struct udevice *dev, unsigned int offset, ulong flag,
 int value)
 {
-   ulong *gpio = get_gpio_dir_flags(dev, offset);
+   ulong *gpio = get_gpio_flags(dev, offset);
 
if (value)
*gpio |= flag;
@@ -88,15 +98,14 @@ int sandbox_gpio_set_direction(struct udevice *dev, 
unsigned offset, int output)
return 0;
 }
 
-ulong sandbox_gpio_get_dir_flags(struct udevice *dev, unsigned int offset)
+ulong sandbox_gpio_get_flags(struct udevice *dev, uint offset)
 {
-   return *get_gpio_dir_flags(dev, offset);
+   return *get_gpio_flags(dev, offset);
 }
 
-int sandbox_gpio_set_dir_flags(struct udevice *dev, unsigned int offset,
-  ulong flags)
+int sandbox_gpio_set_flags(struct udevice *dev, uint offset, ulong flags)
 {
-   *get_gpio_dir_flags(dev, offset) = flags;
+   *get_gpio_flags(dev, offset) = flags;
 
return 0;
 }
@@ -177,33 +186,31 @@ static int sb_gpio_xlate(struct udevice *dev, struct 
gpio_desc *desc,
return 0;
 }
 
-static int sb_gpio_update_flags(struct udevice *dev, unsigned int offset,
-   ulong flags)
+static int sb_gpio_update_flags(struct udevice *dev, uint offset, ulong newf)
 {
-   ulong *dir_flags;
+   ulong *flags;
 
-   debug("%s: offset:%u, dir_flags = %lx\n", __func__, offset, flags);
+   debug("%s: offset:%u, flags = %lx\n", __func__, offset, newf);
 
-   dir_flags = get_gpio_dir_flags(dev, offset);
+   flags = get_gpio_flags(dev, offset);
 
/*
 * For testing purposes keep the output value when switching to input.
 * This allows us to manipulate the input value via the gpio command.
 */
-   if 

[PATCH 04/15] gpio: Rename dm_gpio_get_dir_flags() to dm_gpio_get_flags()

[Simon Glass]

This function can be used to get any flags, not just direction flags.
Rename it to avoid confusion.

Signed-off-by: Simon Glass 
---

 drivers/gpio/gpio-uclass.c |  2 +-
 include/asm-generic/gpio.h |  4 ++--
 test/dm/gpio.c | 12 ++--
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/gpio/gpio-uclass.c b/drivers/gpio/gpio-uclass.c
index 83d3cf0a6b3..864a9003245 100644
--- a/drivers/gpio/gpio-uclass.c
+++ b/drivers/gpio/gpio-uclass.c
@@ -682,7 +682,7 @@ int dm_gpio_set_dir(struct gpio_desc *desc)
return _dm_gpio_update_flags(desc, desc->flags);
 }
 
-int dm_gpio_get_dir_flags(struct gpio_desc *desc, ulong *flagsp)
+int dm_gpio_get_flags(struct gpio_desc *desc, ulong *flagsp)
 {
struct udevice *dev = desc->dev;
int ret, value;
diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
index 48e042dc44b..5ecb73c138d 100644
--- a/include/asm-generic/gpio.h
+++ b/include/asm-generic/gpio.h
@@ -685,7 +685,7 @@ int dm_gpio_set_dir(struct gpio_desc *desc);
 int dm_gpio_set_dir_flags(struct gpio_desc *desc, ulong flags);
 
 /**
- * dm_gpio_get_dir_flags() - Get direction flags
+ * dm_gpio_get_flags() - Get direction flags
  *
  * read the current direction flags
  *
@@ -694,7 +694,7 @@ int dm_gpio_set_dir_flags(struct gpio_desc *desc, ulong 
flags);
  * @flags: place to put the used flags
  * @return 0 if OK, -ve on error, in which case desc->flags is not updated
  */
-int dm_gpio_get_dir_flags(struct gpio_desc *desc, ulong *flags);
+int dm_gpio_get_flags(struct gpio_desc *desc, ulong *flags);
 
 /**
  * gpio_get_number() - Get the global GPIO number of a GPIO
diff --git a/test/dm/gpio.c b/test/dm/gpio.c
index a08c3590d71..6b9ec88ca2b 100644
--- a/test/dm/gpio.c
+++ b/test/dm/gpio.c
@@ -397,22 +397,22 @@ static int dm_test_gpio_get_dir_flags(struct 
unit_test_state *uts)
ut_asserteq(6, gpio_request_list_by_name(dev, "test3-gpios", desc_list,
 ARRAY_SIZE(desc_list), 0));
 
-   ut_assertok(dm_gpio_get_dir_flags(&desc_list[0], &flags));
+   ut_assertok(dm_gpio_get_flags(&desc_list[0], &flags));
ut_asserteq(GPIOD_IS_OUT | GPIOD_OPEN_DRAIN, flags);
 
-   ut_assertok(dm_gpio_get_dir_flags(&desc_list[1], &flags));
+   ut_assertok(dm_gpio_get_flags(&desc_list[1], &flags));
ut_asserteq(GPIOD_IS_OUT | GPIOD_OPEN_SOURCE, flags);
 
-   ut_assertok(dm_gpio_get_dir_flags(&desc_list[2], &flags));
+   ut_assertok(dm_gpio_get_flags(&desc_list[2], &flags));
ut_asserteq(GPIOD_IS_OUT, flags);
 
-   ut_assertok(dm_gpio_get_dir_flags(&desc_list[3], &flags));
+   ut_assertok(dm_gpio_get_flags(&desc_list[3], &flags));
ut_asserteq(GPIOD_IS_IN | GPIOD_PULL_UP, flags);
 
-   ut_assertok(dm_gpio_get_dir_flags(&desc_list[4], &flags));
+   ut_assertok(dm_gpio_get_flags(&desc_list[4], &flags));
ut_asserteq(GPIOD_IS_IN | GPIOD_PULL_DOWN, flags);
 
-   ut_assertok(dm_gpio_get_dir_flags(&desc_list[5], &flags));
+   ut_assertok(dm_gpio_get_flags(&desc_list[5], &flags));
ut_asserteq(GPIOD_IS_IN, flags);
 
ut_assertok(gpio_free_list(dev, desc_list, 6));
-- 
2.30.0.284.gd98b1dd5eaa7-goog

[PATCH 03/15] dm: gpio: Rename get_dir_flags() method to get_flags()

[Simon Glass]

It is more useful to be able to read all the flags, not just the direction
ones. In fact this is what the STM32 driver does. Update the method name
to reflect this.

Tweak the docs a little and use 'flagsp' as the return argument, as is
common in driver model, to indicate it returns a value.

Signed-off-by: Simon Glass 
---

 drivers/gpio/gpio-uclass.c  | 30 +++---
 drivers/gpio/sandbox.c  |  8 
 drivers/gpio/stm32_gpio.c   |  8 
 drivers/pinctrl/pinctrl-stmfx.c |  8 
 include/asm-generic/gpio.h  | 13 +++--
 5 files changed, 34 insertions(+), 33 deletions(-)

diff --git a/drivers/gpio/gpio-uclass.c b/drivers/gpio/gpio-uclass.c
index 0862a28bf86..83d3cf0a6b3 100644
--- a/drivers/gpio/gpio-uclass.c
+++ b/drivers/gpio/gpio-uclass.c
@@ -682,39 +682,39 @@ int dm_gpio_set_dir(struct gpio_desc *desc)
return _dm_gpio_update_flags(desc, desc->flags);
 }
 
-int dm_gpio_get_dir_flags(struct gpio_desc *desc, ulong *flags)
+int dm_gpio_get_dir_flags(struct gpio_desc *desc, ulong *flagsp)
 {
struct udevice *dev = desc->dev;
int ret, value;
struct dm_gpio_ops *ops = gpio_get_ops(dev);
-   ulong dir_flags;
+   ulong flags;
 
-   ret = check_reserved(desc, "get_dir_flags");
+   ret = check_reserved(desc, "get_flags");
if (ret)
return ret;
 
/* GPIOD_ are directly provided by driver except GPIOD_ACTIVE_LOW */
-   if (ops->get_dir_flags) {
-   ret = ops->get_dir_flags(dev, desc->offset, &dir_flags);
+   if (ops->get_flags) {
+   ret = ops->get_flags(dev, desc->offset, &flags);
if (ret)
return ret;
 
/* GPIOD_ACTIVE_LOW is saved in desc->flags */
-   value = dir_flags & GPIOD_IS_OUT_ACTIVE ? 1 : 0;
+   value = flags & GPIOD_IS_OUT_ACTIVE ? 1 : 0;
if (desc->flags & GPIOD_ACTIVE_LOW)
value = !value;
-   dir_flags &= ~(GPIOD_ACTIVE_LOW | GPIOD_IS_OUT_ACTIVE);
-   dir_flags |= (desc->flags & GPIOD_ACTIVE_LOW);
+   flags &= ~(GPIOD_ACTIVE_LOW | GPIOD_IS_OUT_ACTIVE);
+   flags |= (desc->flags & GPIOD_ACTIVE_LOW);
if (value)
-   dir_flags |= GPIOD_IS_OUT_ACTIVE;
+   flags |= GPIOD_IS_OUT_ACTIVE;
} else {
-   dir_flags = desc->flags;
+   flags = desc->flags;
/* only GPIOD_IS_OUT_ACTIVE is provided by uclass */
-   dir_flags &= ~GPIOD_IS_OUT_ACTIVE;
+   flags &= ~GPIOD_IS_OUT_ACTIVE;
if ((desc->flags & GPIOD_IS_OUT) && _gpio_get_value(desc))
-   dir_flags |= GPIOD_IS_OUT_ACTIVE;
+   flags |= GPIOD_IS_OUT_ACTIVE;
}
-   *flags = dir_flags;
+   *flagsp = flags;
 
return 0;
 }
@@ -1309,8 +1309,8 @@ static int gpio_post_bind(struct udevice *dev)
ops->xlate += gd->reloc_off;
if (ops->update_flags)
ops->update_flags += gd->reloc_off;
-   if (ops->get_dir_flags)
-   ops->get_dir_flags += gd->reloc_off;
+   if (ops->get_flags)
+   ops->get_flags += gd->reloc_off;
 
reloc_done++;
}
diff --git a/drivers/gpio/sandbox.c b/drivers/gpio/sandbox.c
index 029908dc9f9..fd14d4e8b5f 100644
--- a/drivers/gpio/sandbox.c
+++ b/drivers/gpio/sandbox.c
@@ -199,11 +199,11 @@ static int sb_gpio_update_flags(struct udevice *dev, 
unsigned int offset,
return 0;
 }
 
-static int sb_gpio_get_dir_flags(struct udevice *dev, unsigned int offset,
-ulong *flags)
+static int sb_gpio_get_flags(struct udevice *dev, unsigned int offset,
+ulong *flagsp)
 {
debug("%s: offset:%u\n", __func__, offset);
-   *flags = *get_gpio_dir_flags(dev, offset);
+   *flagsp = *get_gpio_dir_flags(dev, offset);
 
return 0;
 }
@@ -273,7 +273,7 @@ static const struct dm_gpio_ops gpio_sandbox_ops = {
.get_function   = sb_gpio_get_function,
.xlate  = sb_gpio_xlate,
.update_flags   = sb_gpio_update_flags,
-   .get_dir_flags  = sb_gpio_get_dir_flags,
+   .get_flags  = sb_gpio_get_flags,
 #if CONFIG_IS_ENABLED(ACPIGEN)
.get_acpi   = sb_gpio_get_acpi,
 #endif
diff --git a/drivers/gpio/stm32_gpio.c b/drivers/gpio/stm32_gpio.c
index daae6ddb93f..06a1f28cb77 100644
--- a/drivers/gpio/stm32_gpio.c
+++ b/drivers/gpio/stm32_gpio.c
@@ -221,8 +221,8 @@ static int stm32_gpio_update_flags(struct udevice *dev, 
unsigned int offset,
return 0;
 }
 
-static int stm32_gpio_get_dir_flags(struct udevice *dev, unsigned int offset,
-   ulong *flags)
+static int stm32_gpio_get_flags(struct

[PATCH 02/15] dm: gpio: Rename set_dir_flags() method to update_flags()

[Simon Glass]

The current method is a misnomer since it is also used (e.g. by stm32) to
update pull settings and open source/open drain.

Rename it and expand the documentation to cover a few more details.

Signed-off-by: Simon Glass 
---

 drivers/gpio/gpio-uclass.c  | 16 
 drivers/gpio/sandbox.c  |  6 +++---
 drivers/gpio/stm32_gpio.c   |  6 +++---
 drivers/pinctrl/pinctrl-stmfx.c |  6 +++---
 include/asm-generic/gpio.h  | 30 --
 test/dm/gpio.c  |  8 
 6 files changed, 45 insertions(+), 27 deletions(-)

diff --git a/drivers/gpio/gpio-uclass.c b/drivers/gpio/gpio-uclass.c
index e84b68db772..0862a28bf86 100644
--- a/drivers/gpio/gpio-uclass.c
+++ b/drivers/gpio/gpio-uclass.c
@@ -619,7 +619,7 @@ static int check_dir_flags(ulong flags)
return 0;
 }
 
-static int _dm_gpio_set_dir_flags(struct gpio_desc *desc, ulong flags)
+static int _dm_gpio_update_flags(struct gpio_desc *desc, ulong flags)
 {
struct udevice *dev = desc->dev;
struct dm_gpio_ops *ops = gpio_get_ops(dev);
@@ -637,9 +637,9 @@ static int _dm_gpio_set_dir_flags(struct gpio_desc *desc, 
ulong flags)
return ret;
}
 
-   /* GPIOD_ are directly managed by driver in set_dir_flags*/
-   if (ops->set_dir_flags) {
-   ret = ops->set_dir_flags(dev, desc->offset, flags);
+   /* GPIOD_ are directly managed by driver in update_flags */
+   if (ops->update_flags) {
+   ret = ops->update_flags(dev, desc->offset, flags);
} else {
if (flags & GPIOD_IS_OUT) {
ret = ops->direction_output(dev, desc->offset,
@@ -666,7 +666,7 @@ int dm_gpio_set_dir_flags(struct gpio_desc *desc, ulong 
flags)
 
/* combine the requested flags (for IN/OUT) and the descriptor flags */
flags |= desc->flags;
-   ret = _dm_gpio_set_dir_flags(desc, flags);
+   ret = _dm_gpio_update_flags(desc, flags);
 
return ret;
 }
@@ -679,7 +679,7 @@ int dm_gpio_set_dir(struct gpio_desc *desc)
if (ret)
return ret;
 
-   return _dm_gpio_set_dir_flags(desc, desc->flags);
+   return _dm_gpio_update_flags(desc, desc->flags);
 }
 
 int dm_gpio_get_dir_flags(struct gpio_desc *desc, ulong *flags)
@@ -1307,8 +1307,8 @@ static int gpio_post_bind(struct udevice *dev)
ops->get_function += gd->reloc_off;
if (ops->xlate)
ops->xlate += gd->reloc_off;
-   if (ops->set_dir_flags)
-   ops->set_dir_flags += gd->reloc_off;
+   if (ops->update_flags)
+   ops->update_flags += gd->reloc_off;
if (ops->get_dir_flags)
ops->get_dir_flags += gd->reloc_off;
 
diff --git a/drivers/gpio/sandbox.c b/drivers/gpio/sandbox.c
index dc8d506e8d4..029908dc9f9 100644
--- a/drivers/gpio/sandbox.c
+++ b/drivers/gpio/sandbox.c
@@ -177,8 +177,8 @@ static int sb_gpio_xlate(struct udevice *dev, struct 
gpio_desc *desc,
return 0;
 }
 
-static int sb_gpio_set_dir_flags(struct udevice *dev, unsigned int offset,
-ulong flags)
+static int sb_gpio_update_flags(struct udevice *dev, unsigned int offset,
+   ulong flags)
 {
ulong *dir_flags;
 
@@ -272,7 +272,7 @@ static const struct dm_gpio_ops gpio_sandbox_ops = {
.set_value  = sb_gpio_set_value,
.get_function   = sb_gpio_get_function,
.xlate  = sb_gpio_xlate,
-   .set_dir_flags  = sb_gpio_set_dir_flags,
+   .update_flags   = sb_gpio_update_flags,
.get_dir_flags  = sb_gpio_get_dir_flags,
 #if CONFIG_IS_ENABLED(ACPIGEN)
.get_acpi   = sb_gpio_get_acpi,
diff --git a/drivers/gpio/stm32_gpio.c b/drivers/gpio/stm32_gpio.c
index 79d55e812db..daae6ddb93f 100644
--- a/drivers/gpio/stm32_gpio.c
+++ b/drivers/gpio/stm32_gpio.c
@@ -189,8 +189,8 @@ static int stm32_gpio_get_function(struct udevice *dev, 
unsigned int offset)
return GPIOF_FUNC;
 }
 
-static int stm32_gpio_set_dir_flags(struct udevice *dev, unsigned int offset,
-   ulong flags)
+static int stm32_gpio_update_flags(struct udevice *dev, unsigned int offset,
+  ulong flags)
 {
struct stm32_gpio_priv *priv = dev_get_priv(dev);
struct stm32_gpio_regs *regs = priv->regs;
@@ -268,7 +268,7 @@ static const struct dm_gpio_ops gpio_stm32_ops = {
.get_value  = stm32_gpio_get_value,
.set_value  = stm32_gpio_set_value,
.get_function   = stm32_gpio_get_function,
-   .set_dir_flags  = stm32_gpio_set_dir_flags,
+   .update_flags   = stm32_gpio_update_flags,
.get_dir_flags  = stm32_gpio_get_dir_flags,
 };
 
diff --git a/drivers/pinctrl/pinctrl-stmfx.c b/drivers/pinct

[PATCH 01/15] gpio: Disable functions not used with of-platdata

[Simon Glass]

These functions use devicetree and cannot wprl with of-platdata, which has
no runtime devicetree.

If they are used, the current linker error is confusing, since it talks
about missing functions in the bowels of driver model.

Avoid compiling these functions at all with of-platdata, so that a
straightforward link error points to the problem.

Signed-off-by: Simon Glass 
---

 drivers/gpio/gpio-uclass.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpio/gpio-uclass.c b/drivers/gpio/gpio-uclass.c
index bad6b71e0c3..e84b68db772 100644
--- a/drivers/gpio/gpio-uclass.c
+++ b/drivers/gpio/gpio-uclass.c
@@ -1023,6 +1023,7 @@ err:
return ret;
 }
 
+#if !CONFIG_IS_ENABLED(OF_PLATDATA)
 static int _gpio_request_by_name_nodev(ofnode node, const char *list_name,
   int index, struct gpio_desc *desc,
   int flags, bool add_index)
@@ -1109,6 +1110,7 @@ int gpio_get_list_count(struct udevice *dev, const char 
*list_name)
 
return ret;
 }
+#endif /* OF_PLATDATA */
 
 int dm_gpio_free(struct udevice *dev, struct gpio_desc *desc)
 {
-- 
2.30.0.284.gd98b1dd5eaa7-goog

[PATCH 00/15] gpio: Update and simplify the uclass API

[Simon Glass]

At present the GPIO uclass mirrors what was in U-Boot before driver model.
It works well in most cases but is becoming cumbersome with things like
pull-up/down and drive strength. In those cases it is easier for the
driver to deal with all the flags at one, rather than piece by piece.

In fact the current API does not officially have a method for adjusting
anything other than the direction flags. While set_dir_flags() and
get_dir_flags() do in fact support changing other flags, this is not
documented.

Secondly, set_dir_flags actually ORs the current flags with the new ones
so it is not possible to clear flags. It seems better to use a clr/set
interface (bit clear followed by OR) to provide more flexibility.

Finally, direction_input() and direction_output() are really just the same
thing as set_dir_flags(), with a different name. We currently use the
latter if available, failing back to the former. But it makes sense to
deprecate the old methods.

This series makes the above changes. Existing drivers are mostly left
alone, since they should continue to operate as is. The sandbox driver is
updated to add the required new tests and the x86 driver is switched over
to the new API.

The STM32 driver should be checked to make sure the open source/open drain
features still work as intended.


Simon Glass (15):
  gpio: Disable functions not used with of-platdata
  dm: gpio: Rename set_dir_flags() method to update_flags()
  dm: gpio: Rename get_dir_flags() method to get_flags()
  gpio: Rename dm_gpio_get_dir_flags() to dm_gpio_get_flags()
  gpio: Drop dm_gpio_set_dir()
  gpio: sandbox: Rename GPIO dir_flags to flags
  gpio: sandbox: Use a separate flag for the value
  gpio: sandbox: Fully separate pin value from output value
  gpio: sandbox: Make sandbox_gpio_set_flags() set all flags
  dm: gpio: Add a way to update flags
  gpio: Replace direction_input() and direction_output()
  gpio: Use an 'ops' variable everywhere
  gpio: x86: Drop the deprecated methods in intel_gpio
  gpio: sandbox: Track whether a GPIO is driven
  gpio: Add a way to read 3-way strapping pins

 arch/sandbox/include/asm/gpio.h   |  17 +-
 arch/x86/include/asm/intel_pinctrl_defs.h |   5 +
 drivers/gpio/gpio-uclass.c| 228 ++-
 drivers/gpio/intel_gpio.c |  72 +++---
 drivers/gpio/sandbox.c| 137 
 drivers/gpio/stm32_gpio.c |  14 +-
 drivers/pinctrl/pinctrl-stmfx.c   |  14 +-
 include/asm-generic/gpio.h| 130 +--
 test/dm/gpio.c| 261 +++---
 9 files changed, 663 insertions(+), 215 deletions(-)

-- 
2.30.0.284.gd98b1dd5eaa7-goog

Re: Pull request for UEFI sub-system for efi-2021-04-rc1

[Heinrich Schuchardt]

On 14.01.21 20:24, Tom Rini wrote:
> On Wed, Jan 13, 2021 at 07:43:56PM +0100, Heinrich Schuchardt wrote:
>
>> Dear Tom,
>>
>> The following changes since commit ee6726be4f0dccb612f0193c62ca149164c8a5af:
>>
>>   Merge tag 'ti-v2021.04-rc1' of
>> https://gitlab.denx.de/u-boot/custodians/u-boot-ti (2021-01-12 09:32:48
>> -0500)
>>
>> are available in the Git repository at:
>>
>>   https://gitlab.denx.de/u-boot/custodians/u-boot-efi.git
>> tags/efi-2021-04-rc1
>>
>> for you to fetch changes up to 8e70f1cb3f2c18d574b087d4fc1d79e68ce98fa9:
>>
>>   efi_selftest: dtbdump support EFI_DT_FIXUP_PROTOCOL (2021-01-13
>> 02:38:01 +0100)
>>
>> Gitlab showed no problems:
>> https://gitlab.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/5854
>>
>
> Applied to u-boot/master, thanks!
>
> But!  This got me to look a little harder at things and even if we have
> a platform where we disable ext4/fat write support, there's no change in
> the EFI side of the code.  Is this something we can do anything about?
> If so, is it worthwhile or likely to really only change a few boards and
> I'm just grasping at straws, so to speak, on the question of "Can we do
> anything to reduce EFI code size" ?

I assume you already have disabled:
CONFIG_EFI_DEVICE_PATH_TO_TEXT
CONFIG_EFI_LOADER_HII
CONFIG_EFI_UNICODE_COLLATION_PROTOCOL2

Could you, please, give me an example config to work on?

Best regards

Heinrich

[PATCH] ARM: dts: stm32: Fix cosmetic typo: use 'kHz' as kilohertz abbreviation

[Fabrice GIRARDOT]

The kilohertz unit abbreviation should read 'kHz'.
Note to STM32 team: modified files were generated, it may be worth
to fix STM32CubeMX tool.

Signed-off-by: Fabrice GIRARDOT 
---
 arch/arm/dts/stm32mp15-ddr3-1x4Gb-1066-binG.dtsi | 2 +-
 arch/arm/dts/stm32mp15-ddr3-2x4Gb-1066-binG.dtsi | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/stm32mp15-ddr3-1x4Gb-1066-binG.dtsi 
b/arch/arm/dts/stm32mp15-ddr3-1x4Gb-1066-binG.dtsi
index b4787c4..978331b 100644
--- a/arch/arm/dts/stm32mp15-ddr3-1x4Gb-1066-binG.dtsi
+++ b/arch/arm/dts/stm32mp15-ddr3-1x4Gb-1066-binG.dtsi
@@ -15,7 +15,7 @@
  * Save Date: 2020.02.20, save Time: 18:45:20
  */
 #define DDR_MEM_COMPATIBLE ddr3-1066-888-bin-g-1x4gb-533mhz
-#define DDR_MEM_NAME   "DDR3-DDR3L 16bits 533000Khz"
+#define DDR_MEM_NAME   "DDR3-DDR3L 16bits 533000kHz"
 #define DDR_MEM_SPEED  533000
 #define DDR_MEM_SIZE   0x2000
 
diff --git a/arch/arm/dts/stm32mp15-ddr3-2x4Gb-1066-binG.dtsi 
b/arch/arm/dts/stm32mp15-ddr3-2x4Gb-1066-binG.dtsi
index dc2875c..426be21 100644
--- a/arch/arm/dts/stm32mp15-ddr3-2x4Gb-1066-binG.dtsi
+++ b/arch/arm/dts/stm32mp15-ddr3-2x4Gb-1066-binG.dtsi
@@ -15,7 +15,7 @@
  * Save Date: 2020.02.20, save Time: 18:49:33
  */
 #define DDR_MEM_COMPATIBLE ddr3-1066-888-bin-g-2x4gb-533mhz
-#define DDR_MEM_NAME   "DDR3-DDR3L 32bits 533000Khz"
+#define DDR_MEM_NAME   "DDR3-DDR3L 32bits 533000kHz"
 #define DDR_MEM_SPEED  533000
 #define DDR_MEM_SIZE   0x4000
 
-- 
2.7.4

Re: [PATCH 1/6] net: macb: use dummy descriptor for RBQP

[Padmarao Begari]

Hi Eugen,

On Fri, Jan 15, 2021 at 1:34 PM  wrote:

> On 15.01.2021 06:02, Padmarao Begari wrote:
> > Hi Eugen,
> >
> > On Thu, Jan 14, 2021 at 4:50 PM  > > wrote:
> >
> > On 17.12.2020 07:22, Padmarao Begari - I30397 wrote:
> >  > Hi Eugen,
> >  >
> >  > This series of patches break my side of work(patches) so you need
> to
> >  > create patches after my patches are going into master branch
> > because my
> >  > patches are already reviewed and tested.
> >
> > Hi,
> >
> > Could you please detail the breakage ?
> >
> >
> > The breakage is the fdt relocation disabled in the board environment
> > variables so I have removed it and enabled fdt relocation in PATCH v9.
>
> Maybe you misunderstand my question. I was asking about the sama7g5 macb
> series, which you claimed that breaks your current patch set.
> This is a link to the series :
> https://patchwork.ozlabs.org/project/uboot/list/?series=218367
>
> Since you claimed that this series breaks your series, I am asking what
> exactly is the breakage. How does the fdt relocation in your board
> environment has anything to do with macb and these patches which are not
> applied ?
>
>
My mistake, misunderstood your question,
Yes the fdt relocation has nothing to do with the macb.
We both are adding a member into struct mac_config, a dummy descriptor
for RBQP and my changes are both 32-bit and 64-bit DMA.

Regards
Padmarao


> Thanks,
> Eugen
>
> >
> > Regards
> > Padmarao
> >
> > I saw a pull request with your patches that was NAK-ed, if your two
> > macb
> > patches are tested and reviewed I could apply them to the atmel tree
> as
> > well and send them, if your PR is delayed. But we are interested to
> > have
> > our sama7g5 series pushed as well, so we need to know if it's ok on
> > your
> > side, and what is wrong with the sama7g5 series.
> >
> > Thanks!
> > Eugen
> >  >
> >  > Regards
> >  > Padmarao
> >  >
> >
>  
> >  > *From:* Eugen Hristev - M18282  > >
> >  > *Sent:* Wednesday, December 16, 2020 12:24 PM
> >  > *To:* anup.pa...@wdc.com 
> > mailto:anup.pa...@wdc.com>>;
> > bin.m...@windriver.com 
> >  > mailto:bin.m...@windriver.com>>;
> > Padmarao Begari - I30397
> >  >  > >
> >  > *Cc:* Claudiu Beznea - M18063  > >;
> >  > joe.hershber...@ni.com 
> > mailto:joe.hershber...@ni.com>>;
> > u-boot@lists.denx.de 
> >  > mailto:u-boot@lists.denx.de>>
> >  > *Subject:* Re: [PATCH 1/6] net: macb: use dummy descriptor for
> RBQP
> >  > On 03.12.2020 11:25, Claudiu Beznea wrote:
> >  >> In case of multiple queues on RX side the queue scheduler
> >  >> will try to use all the available configured queues (with
> >  >> descriptors having TX_USED bit cleared). If at least one RBQP
> >  >> points to a descriptor with a valid used bit configuration then
> >  >> the reception may block as this may point to any memory. To avoid
> >  >> this scenario all the queues (except queue zero) were disabled by
> >  >> setting DMA descriptors with used bit set on proper RBQP. The
> driver
> >  >> anyway uses only queue 0 for TX/RX.
> >  >>
> >  >> Signed-off-by: Claudiu Beznea  > >
> >  >> ---
> >  >
> >  > Hi Anup, Bin, Padmarao,
> >  >
> >  > I noticed on the mailing list that you have been actively working
> and
> >  > testing the Macb driver on various platforms, we have this series
> >  > outstanding and I want to make sure that it does not break
> > anything on
> >  > your side, so it would be appreciated if you could have a look or
> > test
> >  > it before it goes into master branch.
> >  >
> >  > Thanks !
> >  > Eugen
> >  >
> >  >
> >  >>   drivers/net/macb.c | 4 +++-
> >  >>   drivers/net/macb.h | 2 ++
> >  >>   2 files changed, 5 insertions(+), 1 deletion(-)
> >  >>
> >  >> diff --git a/drivers/net/macb.c b/drivers/net/macb.c
> >  >> index b80a259ff757..836eb85ec96a 100644
> >  >> --- a/drivers/net/macb.c
> >  >> +++ b/drivers/net/macb.c
> >  >> @@ -732,8 +732,10 @@ static int gmac_init_multi_queues(struct
> > macb_device *macb)
> >  >>flush_dcache_range(macb->dummy_desc_dma,
> > macb->dummy_desc_dma +
> >  >>ALIGN(MACB_TX_DUMMY_DMA_DESC_SIZE,
> > PKTALIGN));
> >  >>
> >  >> - for (i = 1; i < num_queues; i++)
> >  >> + for (i = 1; i < num_queues; i++) {
> >  >>gem_writel_queue_TBQP(macb, macb->dummy_desc_dm

[PATCH v2 2/2] pci: Add Rockchip dwc based PCIe controller driver

[Shawn Lin]

Add Rockchip dwc based PCIe controller driver for rk356x platform.
Driver support Gen3 by operating as a Root complex.

Signed-off-by: Shawn Lin 

---

Changes in v2:
- reorder the header file
- add more comment
- use clrsetbits_le32 and setbits_le32
- fix other various suggestions from Simon

 drivers/pci/Kconfig|   9 +
 drivers/pci/Makefile   |   1 +
 drivers/pci/pcie_dw_rockchip.c | 877 +
 drivers/phy/rockchip/Kconfig   |   3 +
 4 files changed, 890 insertions(+)
 create mode 100644 drivers/pci/pcie_dw_rockchip.c

diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 65498bce1d..b1de38f766 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -281,6 +281,15 @@ config PCIE_ROCKCHIP
  Say Y here if you want to enable PCIe controller support on
  Rockchip SoCs.
 
+config PCIE_DW_ROCKCHIP
+   bool "Rockchip DesignWare based PCIe controller"
+   depends on ARCH_ROCKCHIP
+   select DM_PCI
+   select PHY_ROCKCHIP_SNPS_PCIE3
+   help
+ Say Y here if you want to enable DW PCIe controller support on
+ Rockchip SoCs.
+
 config PCI_BRCMSTB
bool "Broadcom STB PCIe controller"
depends on DM_PCI
diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
index 8b4d49a590..5ed94bc95c 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -48,5 +48,6 @@ obj-$(CONFIG_PCIE_INTEL_FPGA) += pcie_intel_fpga.o
 obj-$(CONFIG_PCI_KEYSTONE) += pcie_dw_ti.o
 obj-$(CONFIG_PCIE_MEDIATEK) += pcie_mediatek.o
 obj-$(CONFIG_PCIE_ROCKCHIP) += pcie_rockchip.o
+obj-$(CONFIG_PCIE_DW_ROCKCHIP) += pcie_dw_rockchip.o
 obj-$(CONFIG_PCI_BRCMSTB) += pcie_brcmstb.o
 obj-$(CONFIG_PCI_OCTEONTX) += pci_octeontx.o
diff --git a/drivers/pci/pcie_dw_rockchip.c b/drivers/pci/pcie_dw_rockchip.c
new file mode 100644
index 00..15270627b0
--- /dev/null
+++ b/drivers/pci/pcie_dw_rockchip.c
@@ -0,0 +1,877 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Rockchip DesignWare based PCIe host controller driver
+ *
+ * Copyright (c) 2021 Rockchip, Inc.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/**
+ * struct rk_pcie - RK DW PCIe controller state
+ *
+ * @vpcie3v3: The 3.3v power supply for slot
+ * @dbi_base: The base address of dwc core regs
+ * @apb_base: The base address of vendor regs
+ * @cfg_base: The base address of config header space
+ * @cfg_size: The size of the configuration space which is needed
+ *as it gets written into the PCIE_ATU_LIMIT register
+ * @first_busno: This driver supports multiple PCIe controllers.
+ *   first_busno stores the bus number of the PCIe root-port
+ *   number which may vary depending on the PCIe setup
+ *   (PEX switches etc).
+ * @rst_gpio: The #PERST signal for slot
+ * @io:The IO space for EP's BAR
+ * @mem: The memory space for EP's BAR
+ */
+struct rk_pcie {
+   struct udevice  *dev;
+   struct udevice  *vpcie3v3;
+   void*dbi_base;
+   void*apb_base;
+   void*cfg_base;
+   fdt_size_t  cfg_size;
+   struct phy  phy;
+   struct clk_bulk clks;
+   int first_busno;
+   struct reset_ctl_bulk   rsts;
+   struct gpio_descrst_gpio;
+   struct pci_region   io;
+   struct pci_region   mem;
+};
+
+/* Parameters for the waiting for iATU enabled routine */
+#define PCIE_CLIENT_GENERAL_DEBUG  0x104
+#define PCIE_CLIENT_HOT_RESET_CTRL 0x180
+#define PCIE_LTSSM_ENABLE_ENHANCE  BIT(4)
+#define PCIE_CLIENT_LTSSM_STATUS   0x300
+#define SMLH_LINKUPBIT(16)
+#define RDLH_LINKUPBIT(17)
+#define PCIE_CLIENT_DBG_FIFO_MODE_CON  0x310
+#define PCIE_CLIENT_DBG_FIFO_PTN_HIT_D0 0x320
+#define PCIE_CLIENT_DBG_FIFO_PTN_HIT_D1 0x324
+#define PCIE_CLIENT_DBG_FIFO_TRN_HIT_D0 0x328
+#define PCIE_CLIENT_DBG_FIFO_TRN_HIT_D1 0x32c
+#define PCIE_CLIENT_DBG_FIFO_STATUS0x350
+#define PCIE_CLIENT_DBG_TRANSITION_DATA0x
+#define PCIE_CLIENT_DBF_EN 0x0003
+
+/* PCI DBICS registers */
+#define PCIE_LINK_STATUS_REG   0x80
+#define PCIE_LINK_STATUS_SPEED_OFF 16
+#define PCIE_LINK_STATUS_SPEED_MASK(0xf << PCIE_LINK_STATUS_SPEED_OFF)
+#define PCIE_LINK_STATUS_WIDTH_OFF 20
+#define PCIE_LINK_STATUS_WIDTH_MASK(0xf << PCIE_LINK_STATUS_WIDTH_OFF)
+
+#define PCIE_LINK_CAPABILITY   0x7c
+#define PCIE_LINK_CTL_20xa0
+#define TARGET_LINK_SPEED_MASK 0xf
+#define LINK_SPEED_GEN_1   0x1
+#define LINK_SPEED_GEN_2   0x2
+#define LINK_SPEED_GEN_3   0x3
+
+#define PCIE_MISC_CONTROL_1_OFF0x8bc
+#define PCIE_DBI_RO_WR_EN  BIT(0)
+
+#define PCIE_LINK_WIDTH_SPEED_CONTROL  0x80c
+#define POR

[PATCH v2 0/2] Add Rockchip dwc-based PCIe controller and PHY support

[Shawn Lin]

This patchset add Rockchip dwc-based PCIe controller and PHY
found on RK356X platforms. It could support Gen3 as a root complex.


Changes in v2:
- reoder header file
- add comment
- reorder the header file
- add more comment
- use clrsetbits_le32 and setbits_le32
- fix other various suggestions from Simon

Shawn Lin (2):
  phy: rockchip: Add Rockchip Synopsys PCIe 3.0 PHY
  pci: Add Rockchip dwc based PCIe controller driver

 drivers/pci/Kconfig   |   9 +
 drivers/pci/Makefile  |   1 +
 drivers/pci/pcie_dw_rockchip.c| 877 ++
 drivers/phy/rockchip/Kconfig  |   9 +
 drivers/phy/rockchip/Makefile |   1 +
 .../phy/rockchip/phy-rockchip-snps-pcie3.c| 157 
 6 files changed, 1054 insertions(+)
 create mode 100644 drivers/pci/pcie_dw_rockchip.c
 create mode 100644 drivers/phy/rockchip/phy-rockchip-snps-pcie3.c

-- 
2.17.1

[PATCH v2 1/2] phy: rockchip: Add Rockchip Synopsys PCIe 3.0 PHY

[Shawn Lin]

Add the Rockchip Synopsys based PCIe 3.0 PHY driver as
part of Generic PHY framework.

Signed-off-by: Shawn Lin 
Reviewed-by: Simon Glass 
---

Changes in v2:
- reoder header file
- add comment

 drivers/phy/rockchip/Kconfig  |   6 +
 drivers/phy/rockchip/Makefile |   1 +
 .../phy/rockchip/phy-rockchip-snps-pcie3.c| 157 ++
 3 files changed, 164 insertions(+)
 create mode 100644 drivers/phy/rockchip/phy-rockchip-snps-pcie3.c

diff --git a/drivers/phy/rockchip/Kconfig b/drivers/phy/rockchip/Kconfig
index 2318e71f35..b794cdaf6a 100644
--- a/drivers/phy/rockchip/Kconfig
+++ b/drivers/phy/rockchip/Kconfig
@@ -18,6 +18,12 @@ config PHY_ROCKCHIP_PCIE
help
  Enable this to support the Rockchip PCIe PHY.
 
+config PHY_ROCKCHIP_SNPS_PCIE3
+   bool "Rockchip Snps PCIe3 PHY Driver"
+   depends on PHY && ARCH_ROCKCHIP
+   help
+ Support for Rockchip PCIe3 PHY with Synopsys IP block.
+
 config PHY_ROCKCHIP_TYPEC
bool "Rockchip TYPEC PHY Driver"
depends on ARCH_ROCKCHIP
diff --git a/drivers/phy/rockchip/Makefile b/drivers/phy/rockchip/Makefile
index 44049154f9..f6ad3bf59a 100644
--- a/drivers/phy/rockchip/Makefile
+++ b/drivers/phy/rockchip/Makefile
@@ -5,4 +5,5 @@
 
 obj-$(CONFIG_PHY_ROCKCHIP_INNO_USB2)   += phy-rockchip-inno-usb2.o
 obj-$(CONFIG_PHY_ROCKCHIP_PCIE)+= phy-rockchip-pcie.o
+obj-$(CONFIG_PHY_ROCKCHIP_SNPS_PCIE3)  += phy-rockchip-snps-pcie3.o
 obj-$(CONFIG_PHY_ROCKCHIP_TYPEC)   += phy-rockchip-typec.o
diff --git a/drivers/phy/rockchip/phy-rockchip-snps-pcie3.c 
b/drivers/phy/rockchip/phy-rockchip-snps-pcie3.c
new file mode 100644
index 00..5ae41fbeee
--- /dev/null
+++ b/drivers/phy/rockchip/phy-rockchip-snps-pcie3.c
@@ -0,0 +1,157 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Rockchip PCIE3.0 phy driver
+ *
+ * Copyright (C) 2021 Rockchip Electronics Co., Ltd.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define GRF_PCIE30PHY_CON1 0x4
+#define GRF_PCIE30PHY_CON6 0x18
+#define GRF_PCIE30PHY_CON9 0x24
+
+/**
+ * struct rockchip_p3phy_priv - RK DW PCIe PHY state
+ *
+ * @mmio: The base address of PHY internal registers
+ * @phy_grf: The regmap for controlling pipe signal
+ * @p30phy: The reset signal for PHY
+ * @ref_clk_m: The reference clock of M for PHY
+ * @ref_clk_n: The reference clock of N for PHY
+ * @pclk: The clock for accessing PHY blocks
+ */
+struct rockchip_p3phy_priv {
+   void __iomem *mmio;
+   struct regmap *phy_grf;
+   struct reset_ctl p30phy;
+   struct clk ref_clk_m;
+   struct clk ref_clk_n;
+   struct clk pclk;
+};
+
+static int rochchip_p3phy_init(struct phy *phy)
+{
+   struct rockchip_p3phy_priv *priv = dev_get_priv(phy->dev);
+   int ret;
+
+   ret = clk_enable(&priv->ref_clk_m);
+   if (ret < 0 && ret != -ENOSYS)
+   return ret;
+
+   ret = clk_enable(&priv->ref_clk_n);
+   if (ret < 0 && ret != -ENOSYS)
+   goto err_ref;
+
+   ret = clk_enable(&priv->pclk);
+   if (ret < 0 && ret != -ENOSYS)
+   goto err_pclk;
+
+   reset_assert(&priv->p30phy);
+   udelay(1);
+
+   /* Deassert PCIe PMA output clamp mode */
+   regmap_write(priv->phy_grf, GRF_PCIE30PHY_CON9,
+(0x1 << 15) | (0x1 << 31));
+
+   reset_deassert(&priv->p30phy);
+   udelay(1);
+
+   return 0;
+err_pclk:
+   clk_disable(&priv->ref_clk_n);
+err_ref:
+   clk_disable(&priv->ref_clk_m);
+
+   return ret;
+}
+
+static int rochchip_p3phy_exit(struct phy *phy)
+{
+   struct rockchip_p3phy_priv *priv = dev_get_priv(phy->dev);
+
+   clk_disable(&priv->ref_clk_m);
+   clk_disable(&priv->ref_clk_n);
+   clk_disable(&priv->pclk);
+   reset_assert(&priv->p30phy);
+
+   return 0;
+}
+
+static int rockchip_p3phy_probe(struct udevice *dev)
+{
+   struct rockchip_p3phy_priv *priv = dev_get_priv(dev);
+   struct udevice *syscon;
+   int ret;
+
+   priv->mmio = (void __iomem *)dev_read_addr(dev);
+   if ((fdt_addr_t)priv->mmio == FDT_ADDR_T_NONE)
+   return -EINVAL;
+
+   ret = uclass_get_device_by_phandle(UCLASS_SYSCON, dev,
+  "rockchip,phy-grf",  &syscon);
+   if (ret) {
+   pr_err("unable to find syscon device for rockchip,phy-grf\n");
+   return ret;
+   }
+
+   priv->phy_grf = syscon_get_regmap(syscon);
+   if (IS_ERR(priv->phy_grf)) {
+   dev_err(dev, "failed to find rockchip,phy_grf regmap\n");
+   return PTR_ERR(priv->phy_grf);
+   }
+
+   ret = reset_get_by_name(dev, "phy", &priv->p30phy);
+   if (ret) {
+   dev_err(dev, "no phy reset control specified\n");
+   return ret;
+   }
+
+   ret = clk_get_by_name(dev, "refclk_m", &priv->ref_clk_m);
+   if (ret) {
+

Re: [PATCH 2/2] pci: Add Rockchip dwc based PCIe controller driver【请注意，邮件由s...@google.com代发】

[Shawn Lin]

Hi Simon

Thanks you for  reviewing it.

在 2021/1/14 23:42, Simon Glass 写道:

Hi Shawn,

On Thu, 14 Jan 2021 at 01:15, Shawn Lin  wrote:




8<--


+
+static int rockchip_pcie_init_port(struct udevice *dev)
+{
+   int ret;
+   u32 val;
+   struct rk_pcie *priv = dev_get_priv(dev);
+
+   /* Set power and maybe external ref clk input */
+   if (priv->vpcie3v3) {
+   ret = regulator_set_value(priv->vpcie3v3, 330);


Is there an autoset option for this so this info can go in the device
tree instead?


I think we should control this by driver as other PCIe drivers did, as
we can't guarantee all kernel dtbs doing the right thing and 3v3 power
is very important for both of devices and PHY block.




+   if (ret) {
+   dev_err(priv->dev, "failed to enable vpcie3v3 
(ret=%d)\n",
+   ret);
+   return ret;






Regards,
Simon

Re: [PATCH 2/2] arm64: dts: meson: fix meson-khadas-vim3-u-boot.dtsi

[Art Nikpal]

> It's not necessary since already included in:

Yes u right !  Sorry !


On Fri, Jan 15, 2021 at 4:15 PM Neil Armstrong 
wrote:

> Hi,
>
>
> On 15/01/2021 06:15, Artem Lapkin wrote:
> > Add missed include meson-g12-common-u-boot.dtsi
> >
> > PROBLEM: missed hdmi video setup for VIM3 and VIM3L boards
> >
> > Signed-off-by: Artem Lapkin 
> > ---
> >  arch/arm/dts/meson-khadas-vim3-u-boot.dtsi | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/arch/arm/dts/meson-khadas-vim3-u-boot.dtsi
> b/arch/arm/dts/meson-khadas-vim3-u-boot.dtsi
> > index 81fd5be378..5d6444cbac 100644
> > --- a/arch/arm/dts/meson-khadas-vim3-u-boot.dtsi
> > +++ b/arch/arm/dts/meson-khadas-vim3-u-boot.dtsi
> > @@ -10,6 +10,8 @@
> >   };
> >  };
> >
> > +#include "meson-g12-common-u-boot.dtsi"
> > +
>
> It's not necessary since already included in:
> arch/arm/dts/meson-g12b-a311d-khadas-vim3-u-boot.dtsi:#include
> "meson-g12-common-u-boot.dtsi"
> and
> arch/arm/dts/meson-sm1-u-boot.dtsi:#include "meson-g12-common-u-boot.dtsi"
>
> What u-boot version are you using ?
> Please check u-boot-master and my u-boot-amlogic and u-boot-amlogic-next
> branches on https://gitlab.denx.de/u-boot/custodians/u-boot-amlogic
> before posting !
>
> Thanks,
> Neil
>

[PATCH] video: meson: add HDMI fail-save FullHD option

[Artem Lapkin]

add VIDEO_MESON_HDMI_FAIL_SAVE_FULL_HD configuration option

ABOUT:

Force setup FullHD display mode, if proper timing cant readed.
from display! Its happens for some 4K display, which send
unsupported high timings, but same time can works as FullHD!
Also its will be useful for suspended or disconnected displays.

NOTE: this option disabled by default

Signed-off-by: Artem Lapkin 
---
 drivers/video/meson/Kconfig | 10 ++
 drivers/video/meson/meson_vpu.c | 19 +--
 2 files changed, 27 insertions(+), 2 deletions(-)

diff --git a/drivers/video/meson/Kconfig b/drivers/video/meson/Kconfig
index 0c9ddeb8..55d67700 100644
--- a/drivers/video/meson/Kconfig
+++ b/drivers/video/meson/Kconfig
@@ -10,3 +10,13 @@ config VIDEO_MESON
select DISPLAY
help
  Enable Amlogic Meson Video Processing Unit video support.
+
+config VIDEO_MESON_HDMI_FAIL_SAVE_FULL_HD
+   bool "Enable HDMI fail-save FullHD mode"
+   depends on VIDEO_MESON
+   default n
+   help
+ Force setup FullHD display mode, if proper timing cant readed.
+ from display! Its happens for some 4K display, which send
+ unsupported high timings, but same time can works as FullHD!
+ Also its will be useful for suspended or disconnected displays
diff --git a/drivers/video/meson/meson_vpu.c b/drivers/video/meson/meson_vpu.c
index 4868839f..af677a45 100644
--- a/drivers/video/meson/meson_vpu.c
+++ b/drivers/video/meson/meson_vpu.c
@@ -52,8 +52,23 @@ static int meson_vpu_setup_mode(struct udevice *dev, struct 
udevice *disp)
if (disp) {
ret = display_read_timing(disp, &timing);
if (ret) {
-   debug("%s: Failed to read timings\n", __func__);
-   goto cvbs;
+   if 
(IS_ENABLED(CONFIG_VIDEO_MESON_HDMI_FAIL_SAVE_FULL_HD)) {
+   printf("DISPLAY: setup failsave FullHD mode\n");
+   timing.pixelclock.typ = 14850;
+   timing.hactive.typ = 1920;
+   timing.hfront_porch.typ = 88;
+   timing.hback_porch.typ = 148;
+   timing.hsync_len.typ = 44;
+   timing.vactive.typ = 1080;
+   timing.vfront_porch.typ = 4;
+   timing.vback_porch.typ = 36;
+   timing.vsync_len.typ = 5;
+   timing.flags = 10;
+   timing.hdmi_monitor = true;
+   } else {
+   debug("%s: Failed to read timings\n", __func__);
+   goto cvbs;
+   }
}
 
uc_priv->xsize = timing.hactive.typ;
-- 
2.25.1

Re: [PATCH 1/2] phy: rockchip: Add Rockchip Synopsys PCIe 3.0 PHY【请注意，邮件由s...@google.com代发】

[Shawn Lin]

在 2021/1/14 23:42, Simon Glass 写道:

Hi Shawn,

On Thu, 14 Jan 2021 at 01:15, Shawn Lin  wrote:


Add the Rockchip Synopsys based PCIe 3.0 PHY driver as
part of Generic PHY framework.

Signed-off-by: Shawn Lin 
---

  drivers/phy/rockchip/Kconfig  |   6 +
  drivers/phy/rockchip/Makefile |   1 +
  .../phy/rockchip/phy-rockchip-snps-pcie3.c| 146 ++
  3 files changed, 153 insertions(+)
  create mode 100644 drivers/phy/rockchip/phy-rockchip-snps-pcie3.c



Reviewed-by: Simon Glass 



Thanks for reviewing it, and will fix them in V2.


nits below


diff --git a/drivers/phy/rockchip/Kconfig b/drivers/phy/rockchip/Kconfig
index 2318e71f35..b794cdaf6a 100644
--- a/drivers/phy/rockchip/Kconfig
+++ b/drivers/phy/rockchip/Kconfig
@@ -18,6 +18,12 @@ config PHY_ROCKCHIP_PCIE
 help
   Enable this to support the Rockchip PCIe PHY.

+config PHY_ROCKCHIP_SNPS_PCIE3
+   bool "Rockchip Snps PCIe3 PHY Driver"
+   depends on PHY && ARCH_ROCKCHIP
+   help
+ Support for Rockchip PCIe3 PHY with Synopsys IP block.


Can you mention the features here?


+
  config PHY_ROCKCHIP_TYPEC
 bool "Rockchip TYPEC PHY Driver"
 depends on ARCH_ROCKCHIP
diff --git a/drivers/phy/rockchip/Makefile b/drivers/phy/rockchip/Makefile
index 44049154f9..f6ad3bf59a 100644
--- a/drivers/phy/rockchip/Makefile
+++ b/drivers/phy/rockchip/Makefile
@@ -5,4 +5,5 @@

  obj-$(CONFIG_PHY_ROCKCHIP_INNO_USB2)   += phy-rockchip-inno-usb2.o
  obj-$(CONFIG_PHY_ROCKCHIP_PCIE)+= phy-rockchip-pcie.o
+obj-$(CONFIG_PHY_ROCKCHIP_SNPS_PCIE3)  += phy-rockchip-snps-pcie3.o
  obj-$(CONFIG_PHY_ROCKCHIP_TYPEC)   += phy-rockchip-typec.o
diff --git a/drivers/phy/rockchip/phy-rockchip-snps-pcie3.c 
b/drivers/phy/rockchip/phy-rockchip-snps-pcie3.c
new file mode 100644
index 00..3132f811b9
--- /dev/null
+++ b/drivers/phy/rockchip/phy-rockchip-snps-pcie3.c
@@ -0,0 +1,146 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Rockchip PCIE3.0 phy driver
+ *
+ * Copyright (C) 2021 Rockchip Electronics Co., Ltd.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 


Check header order

https://www.denx.de/wiki/U-Boot/CodingStyle


+
+#define GRF_PCIE30PHY_CON1 0x4
+#define GRF_PCIE30PHY_CON6 0x18
+#define GRF_PCIE30PHY_CON9 0x24
+
+struct rockchip_p3phy_priv {
+   void __iomem *mmio;
+   int mode;


please add comments for members


+   struct regmap *phy_grf;
+   struct reset_ctl p30phy;
+   struct clk ref_clk_m;
+   struct clk ref_clk_n;
+   struct clk pclk;
+};
+
+static int rochchip_p3phy_init(struct phy *phy)
+{
+   struct rockchip_p3phy_priv *priv = dev_get_priv(phy->dev);
+   int ret;
+
+   ret = clk_enable(&priv->ref_clk_m);
+   if (ret < 0 && ret != -ENOSYS)
+   return ret;
+
+   ret = clk_enable(&priv->ref_clk_n);
+   if (ret < 0 && ret != -ENOSYS)
+   goto err_ref;
+
+   ret = clk_enable(&priv->pclk);
+   if (ret < 0 && ret != -ENOSYS)
+   goto err_pclk;
+
+   reset_assert(&priv->p30phy);
+   udelay(1);
+
+   /* Deassert PCIe PMA output clamp mode */
+   regmap_write(priv->phy_grf, GRF_PCIE30PHY_CON9,
+(0x1 << 15) | (0x1 << 31));
+
+   reset_deassert(&priv->p30phy);
+   udelay(1);
+
+   return 0;
+err_pclk:
+   clk_disable(&priv->ref_clk_n);
+err_ref:
+   clk_disable(&priv->ref_clk_m);


blank line before final return (please fix throughout)


+   return ret;
+}
+

[...]

Regards,
Simon

[PATCH 2/2] arm64: dts: meson: fix meson-khadas-vim3-u-boot.dtsi

[Artem Lapkin]

Add missed include meson-g12-common-u-boot.dtsi

PROBLEM: missed hdmi video setup for VIM3 and VIM3L boards

Signed-off-by: Artem Lapkin 
---
 arch/arm/dts/meson-khadas-vim3-u-boot.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/dts/meson-khadas-vim3-u-boot.dtsi 
b/arch/arm/dts/meson-khadas-vim3-u-boot.dtsi
index 81fd5be378..5d6444cbac 100644
--- a/arch/arm/dts/meson-khadas-vim3-u-boot.dtsi
+++ b/arch/arm/dts/meson-khadas-vim3-u-boot.dtsi
@@ -10,6 +10,8 @@
};
 };
 
+#include "meson-g12-common-u-boot.dtsi"
+
 &sd_emmc_c {
status = "okay";
pinctrl-0 = <&emmc_ctrl_pins>, <&emmc_data_4b_pins>, <&emmc_ds_pins>;
-- 
2.25.1

[PATCH 1/2] gpio: gpio-uclass: add OPEN_DRAIN flag parsing

[Artem Lapkin]

add GPIOD_OPEN_DRAIN flag which cant parsed properly

Problem: for example cant power video system for sm1 g12a socs
because OPEN_DRAIN flag cant parsed

DTS examples:

```
$ grep GPIO_OPEN_DRAIN\>  arch/arm/dts/meson-*.dt*
arch/arm/dts/meson-g12a-sei510.dts: gpio = <&gpio GPIOH_8 
GPIO_OPEN_DRAIN>;
arch/arm/dts/meson-g12a-u200.dts:   gpio = <&gpio GPIOH_8 
GPIO_OPEN_DRAIN>;
arch/arm/dts/meson-gx-libretech-pc.dtsi:gpio = <&gpio GPIOH_3 
GPIO_OPEN_DRAIN>;
arch/arm/dts/meson-khadas-vim3.dtsi:gpio = <&gpio GPIOH_8 
GPIO_OPEN_DRAIN>;
arch/arm/dts/meson-sm1-sei610.dts:  gpio = <&gpio GPIOH_8 
GPIO_OPEN_DRAIN>;
```

Signed-off-by: Artem Lapkin 
---
 drivers/gpio/gpio-uclass.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/gpio/gpio-uclass.c b/drivers/gpio/gpio-uclass.c
index bad6b71e0c..6225f32457 100644
--- a/drivers/gpio/gpio-uclass.c
+++ b/drivers/gpio/gpio-uclass.c
@@ -574,6 +574,15 @@ int dm_gpio_set_value(const struct gpio_desc *desc, int 
value)
if (ret)
return ret;
 
+   if (desc->flags & GPIOD_OPEN_DRAIN) {
+   if (value)
+   gpio_get_ops(desc->dev)->direction_input(desc->dev, 
desc->offset);
+   else
+   gpio_get_ops(desc->dev)->direction_output(desc->dev, 
desc->offset, 0);
+
+   return 0;
+   }
+
if (desc->flags & GPIOD_ACTIVE_LOW)
value = !value;
 
-- 
2.25.1

[PATCH 0/2] fix hdmi video setup for khadas vim3x boards

[Artem Lapkin]

next patches add missed parts

Artem Lapkin (2):
  gpio: gpio-uclass: add OPEN_DRAIN flag parsing
  arm64: dts: meson: fix meson-khadas-vim3-u-boot.dtsi

 arch/arm/dts/meson-khadas-vim3-u-boot.dtsi |  2 ++
 drivers/gpio/gpio-uclass.c | 10 ++
 2 files changed, 12 insertions(+)

-- 
2.25.1

Re: [PATCH] autoboot: fix illegal memory access when stop key and delay key are empty

[Heinrich Schuchardt]

On 15.01.21 04:11, yuezhang...@sony.com wrote:
> If both stop key and delay key are empty, the length of these
> keys is 0. The subtraction operation will cause the u_int type
> variable to overflow, will cause illegal memory access in key
> input loop.
>
> This commit fixes this bug by using int type instead of u_init.
> ---
>  common/autoboot.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/common/autoboot.c b/common/autoboot.c
> index e628baffb8..61fb09f910 100644
> --- a/common/autoboot.c
> +++ b/common/autoboot.c
> @@ -156,9 +156,9 @@ static int passwd_abort_key(uint64_t etime)
>   };
>
>   char presskey[MAX_DELAY_STOP_STR];
> - u_int presskey_len = 0;
> - u_int presskey_max = 0;
> - u_int i;
> + int presskey_len = 0;
> + int presskey_max = 0;

Both indices cannot be negative. So it is understandable that u_int was
chosen. You could avoid the subtraction instead of changing the type:

-for (i = 0; i < presskey_max - 1; i++)
+for (i = 0; i + 1 < presskey_max; i++)

Acked-by: Heinrich Schuchardt 

> + int i;
>
>  #  ifdef CONFIG_AUTOBOOT_DELAY_STR
>   if (delaykey[0].str == NULL)
>

Re: [PATCH 1/6] net: macb: use dummy descriptor for RBQP

[Eugen.Hristev]

On 15.01.2021 06:02, Padmarao Begari wrote:
> Hi Eugen,
> 
> On Thu, Jan 14, 2021 at 4:50 PM  > wrote:
> 
> On 17.12.2020 07:22, Padmarao Begari - I30397 wrote:
>  > Hi Eugen,
>  >
>  > This series of patches break my side of work(patches) so you need to
>  > create patches after my patches are going into master branch
> because my
>  > patches are already reviewed and tested.
> 
> Hi,
> 
> Could you please detail the breakage ?
> 
> 
> The breakage is the fdt relocation disabled in the board environment 
> variables so I have removed it and enabled fdt relocation in PATCH v9.

Maybe you misunderstand my question. I was asking about the sama7g5 macb 
series, which you claimed that breaks your current patch set.
This is a link to the series :
https://patchwork.ozlabs.org/project/uboot/list/?series=218367

Since you claimed that this series breaks your series, I am asking what 
exactly is the breakage. How does the fdt relocation in your board 
environment has anything to do with macb and these patches which are not 
applied ?

Thanks,
Eugen

> 
> Regards
> Padmarao
> 
> I saw a pull request with your patches that was NAK-ed, if your two
> macb
> patches are tested and reviewed I could apply them to the atmel tree as
> well and send them, if your PR is delayed. But we are interested to
> have
> our sama7g5 series pushed as well, so we need to know if it's ok on
> your
> side, and what is wrong with the sama7g5 series.
> 
> Thanks!
> Eugen
>  >
>  > Regards
>  > Padmarao
>  >
> 
>  > *From:* Eugen Hristev - M18282  >
>  > *Sent:* Wednesday, December 16, 2020 12:24 PM
>  > *To:* anup.pa...@wdc.com 
> mailto:anup.pa...@wdc.com>>;
> bin.m...@windriver.com 
>  > mailto:bin.m...@windriver.com>>;
> Padmarao Begari - I30397
>  >  >
>  > *Cc:* Claudiu Beznea - M18063  >;
>  > joe.hershber...@ni.com 
> mailto:joe.hershber...@ni.com>>;
> u-boot@lists.denx.de 
>  > mailto:u-boot@lists.denx.de>>
>  > *Subject:* Re: [PATCH 1/6] net: macb: use dummy descriptor for RBQP
>  > On 03.12.2020 11:25, Claudiu Beznea wrote:
>  >> In case of multiple queues on RX side the queue scheduler
>  >> will try to use all the available configured queues (with
>  >> descriptors having TX_USED bit cleared). If at least one RBQP
>  >> points to a descriptor with a valid used bit configuration then
>  >> the reception may block as this may point to any memory. To avoid
>  >> this scenario all the queues (except queue zero) were disabled by
>  >> setting DMA descriptors with used bit set on proper RBQP. The driver
>  >> anyway uses only queue 0 for TX/RX.
>  >>
>  >> Signed-off-by: Claudiu Beznea  >
>  >> ---
>  >
>  > Hi Anup, Bin, Padmarao,
>  >
>  > I noticed on the mailing list that you have been actively working and
>  > testing the Macb driver on various platforms, we have this series
>  > outstanding and I want to make sure that it does not break
> anything on
>  > your side, so it would be appreciated if you could have a look or
> test
>  > it before it goes into master branch.
>  >
>  > Thanks !
>  > Eugen
>  >
>  >
>  >>   drivers/net/macb.c | 4 +++-
>  >>   drivers/net/macb.h | 2 ++
>  >>   2 files changed, 5 insertions(+), 1 deletion(-)
>  >>
>  >> diff --git a/drivers/net/macb.c b/drivers/net/macb.c
>  >> index b80a259ff757..836eb85ec96a 100644
>  >> --- a/drivers/net/macb.c
>  >> +++ b/drivers/net/macb.c
>  >> @@ -732,8 +732,10 @@ static int gmac_init_multi_queues(struct
> macb_device *macb)
>  >>    flush_dcache_range(macb->dummy_desc_dma,
> macb->dummy_desc_dma +
>  >>    ALIGN(MACB_TX_DUMMY_DMA_DESC_SIZE,
> PKTALIGN));
>  >>
>  >> - for (i = 1; i < num_queues; i++)
>  >> + for (i = 1; i < num_queues; i++) {
>  >>    gem_writel_queue_TBQP(macb, macb->dummy_desc_dma,
> i - 1);
>  >> + gem_writel_queue_RBQP(macb, macb->dummy_desc_dma,
> i - 1);
>  >> + }
>  >>
>  >>    return 0;
>  >>   }
>  >> diff --git a/drivers/net/macb.h b/drivers/net/macb.h
>  >> index 9b16383eba46..28c7fe306883 100644
>  >> --- a/drivers/net/macb.h
>  >> +++ b/drivers/net/macb.h
>  >> @@ -768,5 +768,7 @@
>  >>   #define GEM_RX_CSUM_CHECKED_MASK    2
>  >>   #define gem_writel_queue_TBQP(port, value, queue_num)   \
> 

Re: [PATCH 1/3] efi_loader: print boot device and file path in helloworld

[Heinrich Schuchardt]

On 15.01.21 05:29, AKASHI Takahiro wrote:
> On Fri, Jan 15, 2021 at 04:12:18AM +0100, Heinrich Schuchardt wrote:
>> Am 15. Januar 2021 02:56:03 MEZ schrieb AKASHI Takahiro 
>> :
>>> Heinrich,
>>>
>>> On Tue, Jan 12, 2021 at 08:58:40PM +0100, Heinrich Schuchardt wrote:
 Let helloworld.efi print the device path of the boot device and the
>>> file
 path as provided by the loaded image protocol.

 Signed-off-by: Heinrich Schuchardt 
 ---
  lib/efi_loader/helloworld.c | 167
>>> +---



>>>
>>> If this kind of information is quite useful for users, why not add
>>> that (printing) feature as an option of bootefi (or efidebug)?
>>> I'm afraid that most users who are irritated as you said won't be able
>>> to imagine such information be printed by helloworld app.
>>>
>>
>> The file path is written in
>>
>> https://github.com/trini/u-boot/blob/master/cmd/bootefi.c#L471
>>
>> Device paths are not really user friendly.
>
> So why do you want to print such info at helloworld?
>
> I guess that, according to your cover letter, you have in your mind
> some cases where an user may get in trouble relating to the boot device.
> Right?
>
>> So I would not like to write it there.
>
> What I meant to suggest is to add an option, -v or -h, to bootefi,
> which prints verbose (and helpful) information for users to identify a cause.
> I can easily imagine users may blindly try to add -[v|h] when
> they see an error message even if they don't know there is such an option:)

To me helloworld.efi is a tool for a developer to see if an EFI binary
is correctly invoked.

The normal U-Boot code we want to keep as slim as possible.

According to the spec UEFI boots from the ESP and typically there is
only one. So printing the file path in cmd/bootefi should be enough.

Best regards

Heinrich

Re: [PATCH 2/2] board: atmel: Add SAMA5D27 giant board

[Eugen.Hristev]

On 11.01.2021 09:10, Greg Gallagher wrote:
> Giant board is a tiny SBC based on the Adafruit Feather form factor,
> created by groboards it contains a SAMA5D2 processor (SAMA5D27),
> 128 MB of RAM and a microSD card for storage.
> 
> Signed-off-by: Greg Gallagher 

Hi Greg,


> ---
> 
>   arch/arm/dts/Makefile |   3 +
>   arch/arm/dts/at91-sama5d27_giantboard.dts | 128 
>   arch/arm/mach-at91/Kconfig|   9 +
>   board/atmel/sama5d27_giantboard/Kconfig   |  15 ++
>   board/atmel/sama5d27_giantboard/MAINTAINERS   |   6 +
>   board/atmel/sama5d27_giantboard/Makefile  |   5 +
>   .../sama5d27_giantboard/sama5d27_giantboard.c | 182 ++
>   configs/sama5d27_giantboard_defconfig |  93 +
>   include/configs/sama5d27_giantboard.h | 136 +
>   9 files changed, 577 insertions(+)
>   create mode 100644 arch/arm/dts/at91-sama5d27_giantboard.dts
>   create mode 100644 board/atmel/sama5d27_giantboard/Kconfig
>   create mode 100644 board/atmel/sama5d27_giantboard/MAINTAINERS
>   create mode 100644 board/atmel/sama5d27_giantboard/Makefile
>   create mode 100644 board/atmel/sama5d27_giantboard/sama5d27_giantboard.c
>   create mode 100644 configs/sama5d27_giantboard_defconfig
>   create mode 100644 include/configs/sama5d27_giantboard.h
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index fd47e408f8..23b45290a4 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -898,6 +898,9 @@ dtb-$(CONFIG_TARGET_SAMA5D2_XPLAINED) += \
>   dtb-$(CONFIG_TARGET_SAMA5D27_SOM1_EK) += \
>  at91-sama5d27_som1_ek.dtb
> 
> +dtb-$(CONFIG_TARGET_SAMA5D27_GIANTBOARD) += \
> +   at91-sama5d27_giantboard.dtb
> +
>   dtb-$(CONFIG_TARGET_SAMA5D27_WLSOM1_EK) += \
>  at91-sama5d27_wlsom1_ek.dtb
> 
> diff --git a/arch/arm/dts/at91-sama5d27_giantboard.dts 
> b/arch/arm/dts/at91-sama5d27_giantboard.dts
> new file mode 100644
> index 00..e81ca60ca0
> --- /dev/null
> +++ b/arch/arm/dts/at91-sama5d27_giantboard.dts
> @@ -0,0 +1,128 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * at91-sama5d27_giantboard.dts - Device Tree file for Giant Board
> + *
> + * Copyright (C) 2020 Greg Gallagher 
> + *
> + * Derived from at91-sama5d27_som1_ek.dts
> + *
> + * Copyright (C) 2017 Microchip Corporation
> + *   Wenyou Yang 
> + */
> +/dts-v1/;
> +#include "sama5d2.dtsi"
> +#include "sama5d2-pinfunc.h"
> +
> +/ {
> +   model = "Giant Board";
> +   compatible = "atmel,sama5d27-giantboard", "atmel,sama5d2", 
> "atmel,sama5";
> +
> +   memory {
> +   reg = <0x2000 0x800>;
> +   };
> +
> +   chosen {
> +   u-boot,dm-pre-reloc;
> +   stdout-path = &uart1;
> +   };
> +
> +   ahb {
> +   sdmmc1: sdio-host@b000 {
> +   bus-width = <4>;
> +   pinctrl-names = "default";
> +   pinctrl-0 = <&pinctrl_sdmmc1_cmd_dat_default 
> &pinctrl_sdmmc1_ck_cd_default>;
> +   status = "okay";
> +   u-boot,dm-pre-reloc;
> +   };
> +
> +   apb {
> +
Please remove empty line here
> +   uart1: serial@f802 {
> +   pinctrl-names = "default";
> +   pinctrl-0 = <&pinctrl_uart1_default>;
> +   status = "okay";
> +   u-boot,dm-pre-reloc;
> +   };
> +
> +   i2c0: i2c@f8028000 {
> +   pinctrl-names = "default";
> +   pinctrl-0 = <&pinctrl_i2c0_default>;
> +   status = "okay";
> +   };
> +
> +   i2c1: i2c@fc028000 {
> +   pinctrl-names = "default";
> +   pinctrl-0 = <&pinctrl_i2c1_default>;
> +   status = "okay";
> +
> +   pmic@5b {
> +   compatible = "active-semi,act8945a";
> +   reg = <0x5b>;
> +   active-semi,vsel-low;
> +   status = "okay";
> +   };
> +   };
> +
> +   pit: timer@f8048030 {
> +   status = "okay";
> +   u-boot,dm-pre-reloc;
> +   };
> +
> +   sfr: sfr@f803 {
> +   status = "okay";
> +   u-boot,dm-pre-reloc;
> +   };
> +
> +   pioA: gpio@fc038000 {
> +   pinctrl {
> +
Please remove empty line here
> +   pinctrl_sdmmc1_cm

Re: [PATCH 1/2] pinctrl: stmfx: Fix MAX_PIN_NAME_LEN

[Patrice CHOTARD]

Hi 

This series is abandoned and will be replaced by a new one.

Patrice


On 1/11/21 3:03 PM, Patrice Chotard wrote:
> MAX_PIN_NAME_LEN is set to 7 whereas stmfx pin name prefix "stmfx_gpio"
> is 10 char long. So "pinmux status" output looks like:
> 
> STM32MP> pinmux status -a
> --
> stmfx@42:
> stmfx_ : input
> stmfx_ : input
> stmfx_ : input
> stmfx_ : input
> stmfx_ : input
> .
> 
> Set MAX_PIN_NAME_LEN to 13 to get a correct pinmux command output.
> 
> Fixes: e27e96aa804e("pinctrl: stmfx: update pin name")
> 
> Signed-off-by: Patrice Chotard 
> 
> ---
> 
>  drivers/pinctrl/pinctrl-stmfx.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/pinctrl/pinctrl-stmfx.c b/drivers/pinctrl/pinctrl-stmfx.c
> index a62be44d2d..d23ad862f2 100644
> --- a/drivers/pinctrl/pinctrl-stmfx.c
> +++ b/drivers/pinctrl/pinctrl-stmfx.c
> @@ -346,7 +346,7 @@ static int stmfx_pinctrl_get_pins_count(struct udevice 
> *dev)
>   * STMFX pins[15:0] are called "stmfx_gpio[15:0]"
>   * and STMFX pins[23:16] are called "stmfx_agpio[7:0]"
>   */
> -#define MAX_PIN_NAME_LEN 7
> +#define MAX_PIN_NAME_LEN 13
>  static char pin_name[MAX_PIN_NAME_LEN];
>  static const char *stmfx_pinctrl_get_pin_name(struct udevice *dev,
> unsigned int selector)
> 

[GIT PULL] SoCFPGA changes for v2021.04-rc1

[Tan, Ley Foon]

Hi Tom

Please pull the SoCFPGA changes for v2021.04.

Regards
Ley Foon

The following changes since commit ab1a425524a79eeca61e7b67fdf382c7a499346f:

  Merge tag 'u-boot-stm32-20210113' of 
https://gitlab.denx.de/u-boot/custodians/u-boot-stm (2021-01-13 15:00:53 -0500)

are available in the Git repository at:

  https://github.com/lftan/u-boot.git 2021.04-rc

for you to fetch changes up to 40551cf99c237f93d9e0e07b6dd8f31b3868a0f0:

  tools: socfpgaimage: update padding flow (2021-01-15 17:48:39 +0800)


- Add ATF flow for SoC64 devices
- Update socfpgaimage to support print header and update padding flow


Chee Hong Ang (14):
  arm: socfpga: Add function for checking description from FIT image
  arm: socfpga: soc64: Load FIT image with ATF support
  arm: socfpga: soc64: Override 'lowlevel_init' to support ATF
  arm: socfpga: Disable "spin-table" method for booting Linux
  arm: socfpga: soc64: Add SMC helper function for Intel SOCFPGA (64bits)
  arm: socfpga: soc64: Define SMC function identifiers for PSCI SiP services
  mmc: dwmmc: socfpga: Add ATF support for MMC driver
  net: designware: socfpga: Add ATF support for MAC driver
  arm: socfpga: soc64: Add ATF support for Reset Manager driver
  arm: socfpga: soc64: Add ATF support for FPGA reconfig driver
  arm: socfpga: mailbox: Add 'SYSTEM_RESET' PSCI support to 
mbox_reset_cold()
  arm: socfpga: soc64: SSBL shall not setup stack on OCRAM
  arm: socfpga: soc64: Skip handoff data access in SSBL
  configs: socfpga: Add defconfig for Agilex and Stratix 10 with ATF support

Ley Foon Tan (3):
  tools: socfpgaimage: Print image header information
  configs: socfpga: Add CONFIG_SPL_PAD_TO
  tools: socfpgaimage: update padding flow

Siew Chin Lim (4):
  arm: socfpga: Add secure register access helper functions for SoC 64bits
  mmc: dwmmc: Change designware MMC 'clksel' callback function to return 
status
  arm: socfpga: dts: soc64: Add binman node of FIT image with ATF support
  arm: socfpga: soc64: Enable FIT image generation using binman

 Makefile   |   5 +-
 arch/arm/dts/socfpga_agilex-u-boot.dtsi|   4 +-
 arch/arm/dts/socfpga_soc64_fit-u-boot.dtsi | 120 +
 arch/arm/dts/socfpga_stratix10-u-boot.dtsi |   8 +
 arch/arm/dts/socfpga_stratix10_socdk-u-boot.dtsi   |   4 +-
 arch/arm/mach-socfpga/Kconfig  |   4 +-
 arch/arm/mach-socfpga/Makefile |   5 +
 arch/arm/mach-socfpga/board.c  |  12 +-
 .../mach-socfpga/include/mach/secure_reg_helper.h  |  19 +
 arch/arm/mach-socfpga/include/mach/smc_api.h   |  13 +
 arch/arm/mach-socfpga/lowlevel_init_soc64.S|  76 +++
 arch/arm/mach-socfpga/mailbox_s10.c|   5 +
 arch/arm/mach-socfpga/reset_manager_s10.c  |  13 +
 arch/arm/mach-socfpga/secure_reg_helper.c  |  89 
 arch/arm/mach-socfpga/smc_api.c|  56 ++
 arch/arm/mach-socfpga/wrap_pll_config_s10.c|   3 +-
 configs/socfpga_agilex_atf_defconfig   |  72 +++
 configs/socfpga_stratix10_atf_defconfig|  74 +++
 drivers/fpga/intel_sdm_mb.c| 139 +
 drivers/mmc/ca_dw_mmc.c|   4 +-
 drivers/mmc/dw_mmc.c   |   9 +-
 drivers/mmc/exynos_dw_mmc.c|   4 +-
 drivers/mmc/nexell_dw_mmc.c|   4 +-
 drivers/mmc/socfpga_dw_mmc.c   |  18 +-
 drivers/net/dwmac_socfpga.c|  37 +-
 include/configs/socfpga_common.h   |   2 +
 include/configs/socfpga_soc64_common.h |  24 +-
 include/dwmmc.h|   2 +-
 include/linux/intel-smc.h  | 573 +
 tools/socfpgaimage.c   |  86 +++-
 30 files changed, 1447 insertions(+), 37 deletions(-)
 create mode 100644 arch/arm/dts/socfpga_soc64_fit-u-boot.dtsi
 create mode 100644 arch/arm/dts/socfpga_stratix10-u-boot.dtsi
 create mode 100644 arch/arm/mach-socfpga/include/mach/secure_reg_helper.h
 create mode 100644 arch/arm/mach-socfpga/include/mach/smc_api.h
 create mode 100644 arch/arm/mach-socfpga/lowlevel_init_soc64.S
 create mode 100644 arch/arm/mach-socfpga/secure_reg_helper.c
 create mode 100644 arch/arm/mach-socfpga/smc_api.c
 create mode 100644 configs/socfpga_agilex_atf_defconfig
 create mode 100644 configs/socfpga_stratix10_atf_defconfig
 create mode 100644 include/linux/intel-smc.h

Re: [PATCH] usb: xhci: Fix compare to use physical addresses in xhci_bulk_tx()

[Nicolas Saenz Julienne]

+Matthias, just so you're aware.

On Fri, 2021-01-15 at 11:33 +0100, Stefan Roese wrote:
> On 15.01.21 11:27, Nicolas Saenz Julienne wrote:
> > On Fri, 2021-01-15 at 08:52 +0100, Stefan Roese wrote:
> > > Testing with v2021.01 on MIPS Octeon has shown, that the latest patch
> > > for the "short packet event trb handling" did introduce a bug on
> > > platforms with virtual address != physical address. This patch fixes
> > > this issue by using the correct address types in the compare (both
> > > physical in this case).
> > > 
> > > Signed-off-by: Stefan Roese 
> > > Cc: Aaron Williams 
> > > Cc: Chandrakala Chavva 
> > > Cc: Ran Wang 
> > > Cc: Nicolas Saenz Julienne 
> > > Cc: Marek Vasut 
> > > Cc: Bin Meng 
> > > ---
> > >   drivers/usb/host/xhci-ring.c | 4 ++--
> > >   1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
> > > index d708fc928b..d6c47d579b 100644
> > > --- a/drivers/usb/host/xhci-ring.c
> > > +++ b/drivers/usb/host/xhci-ring.c
> > > @@ -723,8 +723,8 @@ again:
> > >   return -ETIMEDOUT;
> > >   }
> > >   
> > > 
> > > 
> > > - if ((uintptr_t)(le64_to_cpu(event->trans_event.buffer))
> > > - != (uintptr_t)last_transfer_trb_addr) {
> > > + if ((uintptr_t)(le64_to_cpu(event->trans_event.buffer)) !=
> > > + (uintptr_t)virt_to_phys(last_transfer_trb_addr)) {
> > >   available_length -=
> > >   
> > > (int)EVENT_TRB_LEN(le32_to_cpu(event->trans_event.transfer_len));
> > >   xhci_acknowledge_event(ctrl);
> > 
> > FWIW I also addressed this in my Rpi400/CM4 enablement series:
> > https://lists.denx.de/pipermail/u-boot/2021-January/437150.html
> 
> Yes, thanks. I've seen your patch and also looked into it while
> debugging this issue on my MIPS platform this morning.
> 
> Actually I would prefer my fix, as it uses virt_to_phys() and not the
> other way around. Currently only virt_to_phys() is used in the USB code
> and not phys_to_virt(), which does not seem to work correctly on my
> platform BTW (as I discovered this morning).

Fair enough, I'll rebase my series on top of this once it's picked :).

Regards,
Nicolas



signature.asc
Description: This is a digitally signed message part

Re: [PATCH] usb: xhci: Fix compare to use physical addresses in xhci_bulk_tx()

[Nicolas Saenz Julienne]

+Matthias, just so you're aware.

On Fri, 2021-01-15 at 11:33 +0100, Stefan Roese wrote:
> On 15.01.21 11:27, Nicolas Saenz Julienne wrote:
> > On Fri, 2021-01-15 at 08:52 +0100, Stefan Roese wrote:
> > > Testing with v2021.01 on MIPS Octeon has shown, that the latest patch
> > > for the "short packet event trb handling" did introduce a bug on
> > > platforms with virtual address != physical address. This patch fixes
> > > this issue by using the correct address types in the compare (both
> > > physical in this case).
> > > 
> > > Signed-off-by: Stefan Roese 
> > > Cc: Aaron Williams 
> > > Cc: Chandrakala Chavva 
> > > Cc: Ran Wang 
> > > Cc: Nicolas Saenz Julienne 
> > > Cc: Marek Vasut 
> > > Cc: Bin Meng 
> > > ---
> > >   drivers/usb/host/xhci-ring.c | 4 ++--
> > >   1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
> > > index d708fc928b..d6c47d579b 100644
> > > --- a/drivers/usb/host/xhci-ring.c
> > > +++ b/drivers/usb/host/xhci-ring.c
> > > @@ -723,8 +723,8 @@ again:
> > >   return -ETIMEDOUT;
> > >   }
> > >   
> > > 
> > > 
> > > - if ((uintptr_t)(le64_to_cpu(event->trans_event.buffer))
> > > - != (uintptr_t)last_transfer_trb_addr) {
> > > + if ((uintptr_t)(le64_to_cpu(event->trans_event.buffer)) !=
> > > + (uintptr_t)virt_to_phys(last_transfer_trb_addr)) {
> > >   available_length -=
> > >   
> > > (int)EVENT_TRB_LEN(le32_to_cpu(event->trans_event.transfer_len));
> > >   xhci_acknowledge_event(ctrl);
> > 
> > FWIW I also addressed this in my Rpi400/CM4 enablement series:
> > https://lists.denx.de/pipermail/u-boot/2021-January/437150.html
> 
> Yes, thanks. I've seen your patch and also looked into it while
> debugging this issue on my MIPS platform this morning.
> 
> Actually I would prefer my fix, as it uses virt_to_phys() and not the
> other way around. Currently only virt_to_phys() is used in the USB code
> and not phys_to_virt(), which does not seem to work correctly on my
> platform BTW (as I discovered this morning).

Fair enough, I'll rebase my series on top of this once it's picked :).

Regards,
Nicolas



signature.asc
Description: This is a digitally signed message part

Re: [PATCH] usb: xhci: Fix compare to use physical addresses in xhci_bulk_tx()

[Stefan Roese]

On 15.01.21 11:27, Nicolas Saenz Julienne wrote:

On Fri, 2021-01-15 at 08:52 +0100, Stefan Roese wrote:

Testing with v2021.01 on MIPS Octeon has shown, that the latest patch
for the "short packet event trb handling" did introduce a bug on
platforms with virtual address != physical address. This patch fixes
this issue by using the correct address types in the compare (both
physical in this case).

Signed-off-by: Stefan Roese 
Cc: Aaron Williams 
Cc: Chandrakala Chavva 
Cc: Ran Wang 
Cc: Nicolas Saenz Julienne 
Cc: Marek Vasut 
Cc: Bin Meng 
---
  drivers/usb/host/xhci-ring.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index d708fc928b..d6c47d579b 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -723,8 +723,8 @@ again:
    return -ETIMEDOUT;
    }
  


-   if ((uintptr_t)(le64_to_cpu(event->trans_event.buffer))
-   != (uintptr_t)last_transfer_trb_addr) {
+   if ((uintptr_t)(le64_to_cpu(event->trans_event.buffer)) !=
+   (uintptr_t)virt_to_phys(last_transfer_trb_addr)) {
    available_length -=
    
(int)EVENT_TRB_LEN(le32_to_cpu(event->trans_event.transfer_len));
    xhci_acknowledge_event(ctrl);


FWIW I also addressed this in my Rpi400/CM4 enablement series:
https://lists.denx.de/pipermail/u-boot/2021-January/437150.html


Yes, thanks. I've seen your patch and also looked into it while
debugging this issue on my MIPS platform this morning.

Actually I would prefer my fix, as it uses virt_to_phys() and not the
other way around. Currently only virt_to_phys() is used in the USB code
and not phys_to_virt(), which does not seem to work correctly on my
platform BTW (as I discovered this morning).


That said,

Reviewed-by: Nicolas Saenz Julienne 


Thanks,
Stefan

Re: [PATCH] usb: xhci: Fix compare to use physical addresses in xhci_bulk_tx()

[Nicolas Saenz Julienne]

On Fri, 2021-01-15 at 08:52 +0100, Stefan Roese wrote:
> Testing with v2021.01 on MIPS Octeon has shown, that the latest patch
> for the "short packet event trb handling" did introduce a bug on
> platforms with virtual address != physical address. This patch fixes
> this issue by using the correct address types in the compare (both
> physical in this case).
> 
> Signed-off-by: Stefan Roese 
> Cc: Aaron Williams 
> Cc: Chandrakala Chavva 
> Cc: Ran Wang 
> Cc: Nicolas Saenz Julienne 
> Cc: Marek Vasut 
> Cc: Bin Meng 
> ---
>  drivers/usb/host/xhci-ring.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
> index d708fc928b..d6c47d579b 100644
> --- a/drivers/usb/host/xhci-ring.c
> +++ b/drivers/usb/host/xhci-ring.c
> @@ -723,8 +723,8 @@ again:
>   return -ETIMEDOUT;
>   }
>  
> 
> - if ((uintptr_t)(le64_to_cpu(event->trans_event.buffer))
> - != (uintptr_t)last_transfer_trb_addr) {
> + if ((uintptr_t)(le64_to_cpu(event->trans_event.buffer)) !=
> + (uintptr_t)virt_to_phys(last_transfer_trb_addr)) {
>   available_length -=
>   
> (int)EVENT_TRB_LEN(le32_to_cpu(event->trans_event.transfer_len));
>   xhci_acknowledge_event(ctrl);

FWIW I also addressed this in my Rpi400/CM4 enablement series:
https://lists.denx.de/pipermail/u-boot/2021-January/437150.html

That said,

Reviewed-by: Nicolas Saenz Julienne 

Regards,
Nicolas




signature.asc
Description: This is a digitally signed message part

Re: [PATCH] usb: xhci: Fix compare to use physical addresses in xhci_bulk_tx()

[Stefan Roese]

Hi Bin,

On 15.01.21 09:16, Bin Meng wrote:

Hi Stefan,

On Fri, Jan 15, 2021 at 3:53 PM Stefan Roese  wrote:


Testing with v2021.01 on MIPS Octeon has shown, that the latest patch
for the "short packet event trb handling" did introduce a bug on
platforms with virtual address != physical address. This patch fixes
this issue by using the correct address types in the compare (both
physical in this case).

Signed-off-by: Stefan Roese 
Cc: Aaron Williams 
Cc: Chandrakala Chavva 
Cc: Ran Wang 
Cc: Nicolas Saenz Julienne 
Cc: Marek Vasut 
Cc: Bin Meng 
---
  drivers/usb/host/xhci-ring.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index d708fc928b..d6c47d579b 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -723,8 +723,8 @@ again:
 return -ETIMEDOUT;
 }

-   if ((uintptr_t)(le64_to_cpu(event->trans_event.buffer))
-   != (uintptr_t)last_transfer_trb_addr) {
+   if ((uintptr_t)(le64_to_cpu(event->trans_event.buffer)) !=
+   (uintptr_t)virt_to_phys(last_transfer_trb_addr)) {


Is last_transfer_trb_addr virtual address? I thought queue_trb()
returns physical address?


No, queue_trb() returns a virtual address accessible from the CPU.

Thanks,
Stefan

RE: [PATCH v7 1/4] arm: rmobile: Add RZ/G2[HMNE] SoC support

[Biju Das]

Hi,

> Subject: RE: [PATCH v7 1/4] arm: rmobile: Add RZ/G2[HMNE] SoC support
> 
> >
> > > diff --git a/arch/arm/mach-rmobile/cpu_info-rcar.c
> > > b/arch/arm/mach-rmobile/cpu_info-rcar.c
> > > index 5bde24ae0e..08345503a2 100644
> > > --- a/arch/arm/mach-rmobile/cpu_info-rcar.c
> > > +++ b/arch/arm/mach-rmobile/cpu_info-rcar.c
> > > @@ -6,6 +6,7 @@
> > >*/
> > >   #include 
> > >   #include 
> > > +#include 
> > >
> > >   #define PRR_MASK0x7fff
> > >   #define R8A7796_REV_1_0 0x5200
> > > @@ -21,9 +22,28 @@ static u32 rmobile_get_prr(void)
> > >   #endif
> > >   }
> > >
> > > +static bool is_rzg_family(void)
> > > +{
> > > + bool rzg_family_type = false;
> > > + struct udevice *soc;
> > > + char name[16];
> > > +
> > > + if (!(soc_get(&soc) || soc_get_family(soc, name, 16))) {
> >
> > This depends on some other patchset, right ?
> > I will wait for that to land and then apply this one.
> 
> Yes, Simon have reviewed this patches and not sure who needs to pick this
> up. So I have sent a gentle remainder for picking this patches [1] [1]
> http://u-boot.10912.n7.nabble.com/PATCH-v4-0-4-Add-Renesas-SoC-
> identification-driver-support-tt432936.html
> 
> >
> > Did you check that this is still OK on RCar Gen2 with its size-limited
> > SPL?
> 
> Unfortunately I do not have access currently to RCar Gen2 boards.
> 

Because of lock down, Still I don't have access to R-Car Gen2 boards.

As you said, R-Car Gen2 SPL has constraint on image size,
Can we make a decision, we won't enable SoC identification driver on R-Car Gen2 
SPL?

Regards,
Biju

RE: [PATCH v4 0/4] Add Renesas SoC identification driver support

[Biju Das]

Hi All,

Gentle ping. 

Can we merge this patch? If you are happy, otherwise please let meknow.

Thanks and regards,
Biju

> -Original Message-
> From: Adam Ford 
> Sent: 11 December 2020 20:25
> To: Biju Das 
> Cc: Simon Glass ; Marek Vasut
> ; Tom Rini ; Dave
> Gerlach ; Prabhakar Mahadev Lad  lad...@bp.renesas.com>; u-boot@lists.denx.de; Nobuhiro Iwamatsu
> ; Chris Paterson 
> Subject: Re: [PATCH v4 0/4] Add Renesas SoC identification driver support
> 
> On Mon, Nov 30, 2020 at 3:18 AM Biju Das 
> wrote:
> >
> > Hi All,
> >
> > Gentle Ping. Please let me know, are we happy with this patch series?
> >
> 
> I have a series pending this as well.
> 
> thank you,
> 
> adam
> > The patch series[1] is blocked by this.
> > [1]
> > https://jpn01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fu-boo
> > t.10912.n7.nabble.com%2FPATCH-v7-0-4-Add-CPU-identification-support-fo
> > r-RZ-G2-SoC-s-tt433694.html%23a433807&data=04%7C01%7Cbiju.das.jz%4
> > 0bp.renesas.com%7Cd041fb395d834b5281f208d89e12e15f%7C53d82571da1947e49
> > cb4625a166a4a2a%7C0%7C1%7C637433151226342691%7CUnknown%7CTWFpbGZsb3d8e
> > yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C30
> > 00&sdata=kXysig8DF8cNkoHn7kRC2Zphcgj3RyOCcWYstRavbSA%3D&reserv
> > ed=0
> >
> > Cheers,
> > Biju
> >
> > > -Original Message-
> > > From: Biju Das 
> > > Sent: 16 November 2020 13:04
> > > To: Simon Glass ; Marek Vasut
> > > 
> > > Cc: Biju Das ; Dave Gerlach  > > gerl...@ti.com>; Prabhakar Mahadev Lad  > > lad...@bp.renesas.com>; u-boot@lists.denx.de; Nobuhiro Iwamatsu
> > > ; Chris Paterson 
> > > Subject: [PATCH v4 0/4] Add Renesas SoC identification driver
> > > support
> > >
> > > This patch series aims to support Renesas SoC identification driver.
> > >
> > > Added a helper function of_match_node to find the matching of_match
> > > structure. This helper function can be used to replace the following
> > > code in u-boot [1] and [2]
> > >
> > > [1]
> > > https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fel
> > > ixir.b
> > > ootlin.com%2Fu-
> > > boot%2Flatest%2Fsource%2Fdrivers%2Fserial%2Fserial_uniphier.c%23L129
> > > &d
> > > ata=04%7C01%7Cbiju.das.jz%40bp.renesas.com%7Ccc01f2630adf48bdb3c408d
> > > 88a306
> > > 996%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C0%7C637411287820999264%
> > > 7CUnkn
> > > own%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haW
> > > wiLCJX
> > > VCI6Mn0%3D%7C1000&sdata=YmZ52jZrOQqXhvbflvy5XWnXsfb7FIRgxpY1XhBI
> > > 6YE%3D
> > > &reserved=0
> > > [2]
> > > https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fel
> > > ixir.b
> > > ootlin.com%2Fu-
> > > boot%2Flatest%2Fsource%2Fdrivers%2Fusb%2Fphy%2Frockchip_usb2_phy.c%2
> > > 3L77&a
> > > mp;data=04%7C01%7Cbiju.das.jz%40bp.renesas.com%7Ccc01f2630adf48bdb3c
> > > 408d88
> > > a306996%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C0%7C637411287820999
> > > 264%7C
> > > Unknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik
> > > 1haWwi
> > > LCJXVCI6Mn0%3D%7C1000&sdata=N2wF3aZNCkN7TQlA%2FbhV3ggDjZdYVjjS%2
> > > F0tOFf
> > > j%2BkOE%3D&reserved=0
> > >
> > > Also added soc_id attribute support in UCLASS_SOC which is required
> > > for Renesas SoC identification driver similar to mainline linux.
> > >
> > > v3->v4
> > >   * Added Simon's Rb tag
> > >   * Updated patch description for SoC identification using soc_id
> > >   * Updated probe function of Renesas SoC identification driver.
> > >
> > > Biju Das (4):
> > >   dm: core: Add of_match_node helper function
> > >   soc: Fix comments from SOC to SoC
> > >   dm: soc: Add SoC id for attribute matching
> > >   dm: soc: SoC identification driver for Renesas SoC's
> > >
> > >  drivers/core/device.c |  21 
> > >  drivers/soc/Kconfig   |   7 ++
> > >  drivers/soc/Makefile  |   1 +
> > >  drivers/soc/soc-uclass.c  |  19 ++-  drivers/soc/soc_renesas.c |
> > > 244 ++
> > >  drivers/soc/soc_sandbox.c |   8 ++
> > >  include/dm/device.h   |  13 ++
> > >  include/soc.h |  39 +-
> > >  test/dm/core.c|  31 +
> > >  test/dm/soc.c |   8 ++
> > >  10 files changed, 384 insertions(+), 7 deletions(-)  create mode
> > > 100644 drivers/soc/soc_renesas.c
> > >
> > > --
> > > 2.17.1
> >

[PATCH] mmc: fsl_esdhc_imx.c: fix compiler warning

[Heiko Schocher]

prevent unsued variable compiler warning if
DM_REGULATOR is not set.

Signed-off-by: Heiko Schocher 
---

 drivers/mmc/fsl_esdhc_imx.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mmc/fsl_esdhc_imx.c b/drivers/mmc/fsl_esdhc_imx.c
index f47a095c50f..8ac859797f0 100644
--- a/drivers/mmc/fsl_esdhc_imx.c
+++ b/drivers/mmc/fsl_esdhc_imx.c
@@ -790,7 +790,9 @@ static int esdhc_set_voltage(struct mmc *mmc)
 {
struct fsl_esdhc_priv *priv = dev_get_priv(mmc->dev);
struct fsl_esdhc *regs = priv->esdhc_regs;
+#if CONFIG_IS_ENABLED(DM_REGULATOR)
int ret;
+#endif
 
priv->signal_voltage = mmc->signal_voltage;
switch (mmc->signal_voltage) {
-- 
2.25.4

Re: [PATCH 2/2] mmc: exynos_dw_mmc: remove unused function

[Minkyu Kang]

Hi,

On Wed, 13 Jan 2021 at 10:31, Peng Fan  wrote:

> > Subject: [PATCH 2/2] mmc: exynos_dw_mmc: remove unused function
> >
> > Remove unused function in exynos_dw_mmc.c.
> >
> > Signed-off-by: Jaehoon Chung 
>
> Reviewed-by: Peng Fan 
>
> > ---
> >  drivers/mmc/exynos_dw_mmc.c | 56 -
> >  1 file changed, 56 deletions(-)
> >
> > diff --git a/drivers/mmc/exynos_dw_mmc.c
> > b/drivers/mmc/exynos_dw_mmc.c index 3aa9fb3c89..edb5a52c96 100644
> > --- a/drivers/mmc/exynos_dw_mmc.c
> > +++ b/drivers/mmc/exynos_dw_mmc.c
> > @@ -133,8 +133,6 @@ static int exynos_dwmci_core_init(struct dwmci_host
> > *host)
> >   return 0;
> >  }
> >
> > -static struct dwmci_host dwmci_host[DWMMC_MAX_CH_NUM];
> > -
> >  static int do_dwmci_init(struct dwmci_host *host)  {
> >   int flag, err;
> > @@ -206,60 +204,6 @@ static int exynos_dwmci_get_config(const void *blob,
> > int node,
> >   return 0;
> >  }
> >
> > -static int exynos_dwmci_process_node(const void *blob,
> > - int node_list[], int count)
> > -{
> > - struct dwmci_exynos_priv_data *priv;
> > - struct dwmci_host *host;
> > - int i, node, err;
> > -
> > - for (i = 0; i < count; i++) {
> > - node = node_list[i];
> > - if (node <= 0)
> > - continue;
> > - host = &dwmci_host[i];
> > -
> > - priv = malloc(sizeof(struct dwmci_exynos_priv_data));
> > - if (!priv) {
> > - pr_err("dwmci_exynos_priv_data malloc fail!\n");
> > - return -ENOMEM;
> > - }
> > -
> > - err = exynos_dwmci_get_config(blob, node, host, priv);
> > - if (err) {
> > - printf("%s: failed to decode dev %d\n", __func__,
> i);
> > - free(priv);
> > - return err;
> > - }
> > - host->priv = priv;
> > -
> > - do_dwmci_init(host);
> > - }
> > - return 0;
> > -}
> > -
> > -int exynos_dwmmc_init(const void *blob) -{
> > - int node_list[DWMMC_MAX_CH_NUM];
> > - int boot_dev_node;
> > - int err = 0, count;
> > -
> > - count = fdtdec_find_aliases_for_id(blob, "mmc",
> > - COMPAT_SAMSUNG_EXYNOS_DWMMC, node_list,
> > - DWMMC_MAX_CH_NUM);
> > -
> > - /* For DWMMC always set boot device as mmc 0 */
> > - if (count >= 3 && get_boot_mode() == BOOT_MODE_SD) {
> > - boot_dev_node = node_list[2];
> > - node_list[2] = node_list[0];
> > - node_list[0] = boot_dev_node;
> > - }
> > -
> > - err = exynos_dwmci_process_node(blob, node_list, count);
> > -
> > - return err;
> > -}
> > -
> >  #ifdef CONFIG_DM_MMC
> >  static int exynos_dwmmc_probe(struct udevice *dev)  {
> > --
> > 2.17.1
>
>
applied to u-boot-samsung.

-- 
Thanks,
Minkyu Kang.

Re: [PATCH 1/2] samsung: arndale: remove board_mmc_init function

[Minkyu Kang]

Hi,

On Wed, 13 Jan 2021 at 13:14, Krzysztof Kozlowski  wrote:

> On Tue, Jan 12, 2021 at 03:30:53PM +0900, Jaehoon Chung wrote:
> > Remove board_mmc_init function.
> > It will be probed with driver-model.
> >
> > Signed-off-by: Jaehoon Chung 
> > ---
> >  arch/arm/mach-exynos/include/mach/dwmmc.h |  2 --
> >  board/samsung/arndale/arndale.c   | 13 -
> >  2 files changed, 15 deletions(-)
> >
>
> Acked-by: Krzysztof Kozlowski 
>
> Best regards,
> Krzysztof
>

applied to u-boot-samsung.

-- 
Thanks,
Minkyu Kang.

Re: [PATCH] video: meson: add HDMI fail-save FullHD option

[Neil Armstrong]

Hi,

On 15/01/2021 09:11, Artem Lapkin wrote:
> add VIDEO_MESON_HDMI_FAIL_SAVE_FULL_HD configuration option
> 
> ABOUT:
> 
> Force setup FullHD display mode, if proper timing cant readed.
> from display! Its happens for some 4K display, which send
> unsupported high timings, but same time can works as FullHD!
> Also its will be useful for suspended or disconnected displays.

Thanks ! It was in my TODO list

> 
> NOTE: this option disabled by default
> 
> Signed-off-by: Artem Lapkin 
> ---
>  drivers/video/meson/Kconfig | 10 ++
>  drivers/video/meson/meson_vpu.c | 19 +--
>  2 files changed, 27 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/video/meson/Kconfig b/drivers/video/meson/Kconfig
> index 0c9ddeb8..55d67700 100644
> --- a/drivers/video/meson/Kconfig
> +++ b/drivers/video/meson/Kconfig
> @@ -10,3 +10,13 @@ config VIDEO_MESON
>   select DISPLAY
>   help
> Enable Amlogic Meson Video Processing Unit video support.
> +
> +config VIDEO_MESON_HDMI_FAIL_SAVE_FULL_HD
> + bool "Enable HDMI fail-save FullHD mode"
> + depends on VIDEO_MESON
> + default n
> + help
> +   Force setup FullHD display mode, if proper timing cant readed.
> +   from display! Its happens for some 4K display, which send
> +   unsupported high timings, but same time can works as FullHD!
> +   Also its will be useful for suspended or disconnected displays

I don't think it's necessary to have an option for that.

> diff --git a/drivers/video/meson/meson_vpu.c b/drivers/video/meson/meson_vpu.c
> index 4868839f..af677a45 100644
> --- a/drivers/video/meson/meson_vpu.c
> +++ b/drivers/video/meson/meson_vpu.c
> @@ -52,8 +52,23 @@ static int meson_vpu_setup_mode(struct udevice *dev, 
> struct udevice *disp)
>   if (disp) {
>   ret = display_read_timing(disp, &timing);
>   if (ret) {
> - debug("%s: Failed to read timings\n", __func__);
> - goto cvbs;
> + if 
> (IS_ENABLED(CONFIG_VIDEO_MESON_HDMI_FAIL_SAVE_FULL_HD)) {
> + printf("DISPLAY: setup failsave FullHD mode\n");
> + timing.pixelclock.typ = 14850;
> + timing.hactive.typ = 1920;
> + timing.hfront_porch.typ = 88;
> + timing.hback_porch.typ = 148;
> + timing.hsync_len.typ = 44;
> + timing.vactive.typ = 1080;
> + timing.vfront_porch.typ = 4;
> + timing.vback_porch.typ = 36;
> + timing.vsync_len.typ = 5;
> + timing.flags = 10;
> + timing.hdmi_monitor = true;
> + } else {
> + debug("%s: Failed to read timings\n", __func__);
> + goto cvbs;


So, 1080p is not a good idea for DVI screens, only for HDMI displays.
And I don't think it's the right place, since when I will add support for DSI 
output,
it won't work.

So it should go in the meson_dw_hdmi, but you'll need to add a read_timing() 
callback instead
of the read_edid, that would do the same as display_read_timing() but return a 
fallback mode if
edid_get_timing_validate() fails.

You could get the info about HDMI or DVI in timing->hdmi_monitor, then you 
should return 1024x768 for DVI and
1080p for HDMI displays, but you'll need to fix the edid_get_timing_validate to 
check for HDMI stuff before
validating the timings.

Neil

> + }
>   }
>  
>   uc_priv->xsize = timing.hactive.typ;
> 

Re: [PATCH] usb: xhci: Fix compare to use physical addresses in xhci_bulk_tx()

[Bin Meng]

Hi Stefan,

On Fri, Jan 15, 2021 at 3:53 PM Stefan Roese  wrote:
>
> Testing with v2021.01 on MIPS Octeon has shown, that the latest patch
> for the "short packet event trb handling" did introduce a bug on
> platforms with virtual address != physical address. This patch fixes
> this issue by using the correct address types in the compare (both
> physical in this case).
>
> Signed-off-by: Stefan Roese 
> Cc: Aaron Williams 
> Cc: Chandrakala Chavva 
> Cc: Ran Wang 
> Cc: Nicolas Saenz Julienne 
> Cc: Marek Vasut 
> Cc: Bin Meng 
> ---
>  drivers/usb/host/xhci-ring.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
> index d708fc928b..d6c47d579b 100644
> --- a/drivers/usb/host/xhci-ring.c
> +++ b/drivers/usb/host/xhci-ring.c
> @@ -723,8 +723,8 @@ again:
> return -ETIMEDOUT;
> }
>
> -   if ((uintptr_t)(le64_to_cpu(event->trans_event.buffer))
> -   != (uintptr_t)last_transfer_trb_addr) {
> +   if ((uintptr_t)(le64_to_cpu(event->trans_event.buffer)) !=
> +   (uintptr_t)virt_to_phys(last_transfer_trb_addr)) {

Is last_transfer_trb_addr virtual address? I thought queue_trb()
returns physical address?

> available_length -=
> 
> (int)EVENT_TRB_LEN(le32_to_cpu(event->trans_event.transfer_len));
> xhci_acknowledge_event(ctrl);
> --

Regards,
Bin

Re: [PATCH 2/2] arm64: dts: meson: fix meson-khadas-vim3-u-boot.dtsi

[Neil Armstrong]

Hi,


On 15/01/2021 06:15, Artem Lapkin wrote:
> Add missed include meson-g12-common-u-boot.dtsi
> 
> PROBLEM: missed hdmi video setup for VIM3 and VIM3L boards
> 
> Signed-off-by: Artem Lapkin 
> ---
>  arch/arm/dts/meson-khadas-vim3-u-boot.dtsi | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm/dts/meson-khadas-vim3-u-boot.dtsi 
> b/arch/arm/dts/meson-khadas-vim3-u-boot.dtsi
> index 81fd5be378..5d6444cbac 100644
> --- a/arch/arm/dts/meson-khadas-vim3-u-boot.dtsi
> +++ b/arch/arm/dts/meson-khadas-vim3-u-boot.dtsi
> @@ -10,6 +10,8 @@
>   };
>  };
>  
> +#include "meson-g12-common-u-boot.dtsi"
> + 

It's not necessary since already included in:
arch/arm/dts/meson-g12b-a311d-khadas-vim3-u-boot.dtsi:#include 
"meson-g12-common-u-boot.dtsi"
and
arch/arm/dts/meson-sm1-u-boot.dtsi:#include "meson-g12-common-u-boot.dtsi"

What u-boot version are you using ?
Please check u-boot-master and my u-boot-amlogic and u-boot-amlogic-next 
branches on https://gitlab.denx.de/u-boot/custodians/u-boot-amlogic before 
posting !

Thanks,
Neil

Re: [PATCH 1/2] gpio: gpio-uclass: add OPEN_DRAIN flag parsing

[Neil Armstrong]

Hi,

This has already been pushed on u-boot master:
https://patchwork.ozlabs.org/project/uboot/patch/20200505084318.15307-2-narmstr...@baylibre.com/

Commit: 47bd533e9dd0f967ff7b62f3edfd6c97131e1501
Author: Neil Armstrong 
Date:   Tue May 5 10:43:17 2020 +0200

gpio: emulate open drain & open source in dm_gpio_set_value()

Handle the GPIOD_OPEN_DRAIN & GPIOD_OPEN_SOURCE flags to emulate open drain
and open source by setting the GPIO line as input depending on the
requested value.

The behaviour is taken from the Linux gpiolib.

Signed-off-by: Neil Armstrong 
Reviewed-by: Simon Glass 

Neil

On 15/01/2021 06:15, Artem Lapkin wrote:
> add GPIOD_OPEN_DRAIN flag which cant parsed properly
> 
> Problem: for example cant power video system for sm1 g12a socs
> because OPEN_DRAIN flag cant parsed
> 
> DTS examples:
> 
> ```
> $ grep GPIO_OPEN_DRAIN\>  arch/arm/dts/meson-*.dt*
> arch/arm/dts/meson-g12a-sei510.dts:   gpio = <&gpio GPIOH_8 
> GPIO_OPEN_DRAIN>;
> arch/arm/dts/meson-g12a-u200.dts: gpio = <&gpio GPIOH_8 
> GPIO_OPEN_DRAIN>;
> arch/arm/dts/meson-gx-libretech-pc.dtsi:  gpio = <&gpio GPIOH_3 
> GPIO_OPEN_DRAIN>;
> arch/arm/dts/meson-khadas-vim3.dtsi:  gpio = <&gpio GPIOH_8 
> GPIO_OPEN_DRAIN>;
> arch/arm/dts/meson-sm1-sei610.dts:gpio = <&gpio GPIOH_8 
> GPIO_OPEN_DRAIN>;
> ```
> 
> Signed-off-by: Artem Lapkin 
> ---
>  drivers/gpio/gpio-uclass.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/gpio/gpio-uclass.c b/drivers/gpio/gpio-uclass.c
> index bad6b71e0c..6225f32457 100644
> --- a/drivers/gpio/gpio-uclass.c
> +++ b/drivers/gpio/gpio-uclass.c
> @@ -574,6 +574,15 @@ int dm_gpio_set_value(const struct gpio_desc *desc, int 
> value)
>   if (ret)
>   return ret;
>  
> + if (desc->flags & GPIOD_OPEN_DRAIN) {
> + if (value)
> + gpio_get_ops(desc->dev)->direction_input(desc->dev, 
> desc->offset);
> + else
> + gpio_get_ops(desc->dev)->direction_output(desc->dev, 
> desc->offset, 0);
> +
> + return 0;
> + }
> +
>   if (desc->flags & GPIOD_ACTIVE_LOW)
>   value = !value;
>  
> 

[PATCH] dm: fix build errors generated by last merges

[Dario Binacchi]

Something was wrong in the merge process into the mainline.
Some added patches access driver structure fields and functions that
have been modified by previous patches.
The patch renames:
 - dev_get_platdata to dev_get_plat
 - dev_get_uclass_platdata to dev_get_uclass_plat
 - ofdata_to_platdata to of_to_plat
 - plat_data_alloc_size to plat_auto
 - priv_auto_alloc_size to priv_auto
 - video_uc_platdata to video_uc_plat

Signed-off-by: Dario Binacchi 
---

 drivers/clk/ti/clk-am3-dpll.c   |  2 +-
 drivers/clk/ti/clk-ctrl.c   |  2 +-
 drivers/clk/ti/clk-divider.c|  2 +-
 drivers/clk/ti/clk-gate.c   |  2 +-
 drivers/clk/ti/clk-mux.c|  2 +-
 drivers/pwm/pwm-ti-ehrpwm.c |  2 +-
 drivers/spi/ca_sflash.c |  2 +-
 drivers/video/seps525.c |  6 +++---
 drivers/video/tdo-tl070wsh30.c  | 12 ++--
 drivers/video/ti/tilcdc-panel.c |  2 +-
 drivers/video/ti/tilcdc.c   |  8 
 11 files changed, 21 insertions(+), 21 deletions(-)

diff --git a/drivers/clk/ti/clk-am3-dpll.c b/drivers/clk/ti/clk-am3-dpll.c
index 7916a24538..90b4cc69ef 100644
--- a/drivers/clk/ti/clk-am3-dpll.c
+++ b/drivers/clk/ti/clk-am3-dpll.c
@@ -260,7 +260,7 @@ U_BOOT_DRIVER(clk_ti_am3_dpll) = {
.name = "ti_am3_dpll_clock",
.id = UCLASS_CLK,
.of_match = clk_ti_am3_dpll_of_match,
-   .ofdata_to_platdata = clk_ti_am3_dpll_of_to_plat,
+   .of_to_plat = clk_ti_am3_dpll_of_to_plat,
.probe = clk_ti_am3_dpll_probe,
.remove = clk_ti_am3_dpll_remove,
.priv_auto = sizeof(struct clk_ti_am3_dpll_priv),
diff --git a/drivers/clk/ti/clk-ctrl.c b/drivers/clk/ti/clk-ctrl.c
index 940e8d6caf..3c6195b208 100644
--- a/drivers/clk/ti/clk-ctrl.c
+++ b/drivers/clk/ti/clk-ctrl.c
@@ -148,7 +148,7 @@ U_BOOT_DRIVER(clk_ti_ctrl) = {
.name = "ti_ctrl_clk",
.id = UCLASS_CLK,
.of_match = clk_ti_ctrl_ids,
-   .ofdata_to_platdata = clk_ti_ctrl_of_to_plat,
+   .of_to_plat = clk_ti_ctrl_of_to_plat,
.ops = &clk_ti_ctrl_ops,
.priv_auto = sizeof(struct clk_ti_ctrl_priv),
 };
diff --git a/drivers/clk/ti/clk-divider.c b/drivers/clk/ti/clk-divider.c
index a862637785..270f2fbdf0 100644
--- a/drivers/clk/ti/clk-divider.c
+++ b/drivers/clk/ti/clk-divider.c
@@ -373,7 +373,7 @@ U_BOOT_DRIVER(clk_ti_divider) = {
.name = "ti_divider_clock",
.id = UCLASS_CLK,
.of_match = clk_ti_divider_of_match,
-   .ofdata_to_platdata = clk_ti_divider_of_to_plat,
+   .of_to_plat = clk_ti_divider_of_to_plat,
.probe = clk_ti_divider_probe,
.remove = clk_ti_divider_remove,
.priv_auto = sizeof(struct clk_ti_divider_priv),
diff --git a/drivers/clk/ti/clk-gate.c b/drivers/clk/ti/clk-gate.c
index 236eaed6df..0ca453c8de 100644
--- a/drivers/clk/ti/clk-gate.c
+++ b/drivers/clk/ti/clk-gate.c
@@ -87,7 +87,7 @@ U_BOOT_DRIVER(clk_ti_gate) = {
.name = "ti_gate_clock",
.id = UCLASS_CLK,
.of_match = clk_ti_gate_of_match,
-   .ofdata_to_platdata = clk_ti_gate_of_to_plat,
+   .of_to_plat = clk_ti_gate_of_to_plat,
.priv_auto = sizeof(struct clk_ti_gate_priv),
.ops = &clk_ti_gate_ops,
 };
diff --git a/drivers/clk/ti/clk-mux.c b/drivers/clk/ti/clk-mux.c
index 419502c389..bb5e49e114 100644
--- a/drivers/clk/ti/clk-mux.c
+++ b/drivers/clk/ti/clk-mux.c
@@ -245,7 +245,7 @@ U_BOOT_DRIVER(clk_ti_mux) = {
.name = "ti_mux_clock",
.id = UCLASS_CLK,
.of_match = clk_ti_mux_of_match,
-   .ofdata_to_platdata = clk_ti_mux_of_to_plat,
+   .of_to_plat = clk_ti_mux_of_to_plat,
.probe = clk_ti_mux_probe,
.remove = clk_ti_mux_remove,
.priv_auto = sizeof(struct clk_ti_mux_priv),
diff --git a/drivers/pwm/pwm-ti-ehrpwm.c b/drivers/pwm/pwm-ti-ehrpwm.c
index ac3d731d22..f09914519b 100644
--- a/drivers/pwm/pwm-ti-ehrpwm.c
+++ b/drivers/pwm/pwm-ti-ehrpwm.c
@@ -461,7 +461,7 @@ U_BOOT_DRIVER(ti_ehrpwm) = {
.id = UCLASS_PWM,
.of_match = ti_ehrpwm_ids,
.ops = &ti_ehrpwm_ops,
-   .ofdata_to_platdata = ti_ehrpwm_of_to_plat,
+   .of_to_plat = ti_ehrpwm_of_to_plat,
.probe = ti_ehrpwm_probe,
.remove = ti_ehrpwm_remove,
.priv_auto = sizeof(struct ti_ehrpwm_priv),
diff --git a/drivers/spi/ca_sflash.c b/drivers/spi/ca_sflash.c
index 00af6bffa6..84569845b7 100644
--- a/drivers/spi/ca_sflash.c
+++ b/drivers/spi/ca_sflash.c
@@ -571,6 +571,6 @@ U_BOOT_DRIVER(ca_sflash) = {
.id = UCLASS_SPI,
.of_match = ca_sflash_ids,
.ops = &ca_sflash_ops,
-   .priv_auto_alloc_size = sizeof(struct ca_sflash_priv),
+   .priv_auto = sizeof(struct ca_sflash_priv),
.probe = ca_sflash_probe,
 };
diff --git a/drivers/video/seps525.c b/drivers/video/seps525.c
index 369e5e6afc..74c8721e1e 100644
--- a/drivers/video/seps525.c
+++ b/drivers/video/seps525.c
@@ -299,7 +299,7 @@ static int seps525_probe(struct udevice *dev)
 
 static int seps525_bind(struct udevice *dev)
 {
-   struct video_uc_plat