Re: Please pull u-boot-i2c/next

[Patrice CHOTARD]

Hi Heiko, Tom

Is this PR can be merged into v2021.10 ?
The patch "mtd: nand: raw: convert nand_dt_init() to ofnode_xx() interface" is 
fixing 
an issue for all platforms for which OF_LIVE flag is enabled.

For all these platforms, all nand DT property can't be read (nand-bus-width, 
nand-on-flash-bbt, 
nand-ecc-mode.nand-ecc-strength andnand-ecc-step-size properties are concerned)

It has been detected on STM32MP1 platforms.

Thanks
Patrice





On 9/28/21 8:32 AM, Heiko Schocher wrote:
> Hello Tom,
> 
> please pull from u-boot-i2c next
> 
> The following changes since commit 1d1f98c8eed7bb4792300e655c2cb70136928f74:
> 
>   Merge tag 'dm-pull-next-27sep21' of 
> https://source.denx.de/u-boot/custodians/u-boot-dm into next
> (2021-09-27 11:09:23 -0400)
> 
> are available in the Git repository at:
> 
>   https://source.denx.de/u-boot/custodians/u-boot-i2c.git 20210928-for-next
> 
> for you to fetch changes up to a70c3f9fb84524243eabefd28e0aa539f22e6226:
> 
>   mtd: nand: raw: convert nand_dt_init() to ofnode_xx() interface (2021-09-28 
> 06:34:45 +0200)
> 
> ----
> i2c changes for 20210928-for-next
> 
> - i2c: rcar_i2c: Enable configuring SCL rise and fall times
> - i2c: mvtwsi: Add support for DM clocks and resets
> - mtd: nand: raw: convert nand_dt_init() to ofnode_xx() interface
> 
> 
> Adam Ford (1):
>   i2c: rcar_i2c: Enable configuring SCL rise and fall times
> 
> Patrice Chotard (1):
>   mtd: nand: raw: convert nand_dt_init() to ofnode_xx() interface
> 
> Samuel Holland (1):
>   i2c: mvtwsi: Add support for DM clocks and resets
> 
>  drivers/i2c/mvtwsi.c   | 13 +
>  drivers/i2c/rcar_i2c.c |  8 +++-
>  drivers/mtd/nand/raw/denali.c  |  2 +-
>  drivers/mtd/nand/raw/mxs_nand.c|  2 +-
>  drivers/mtd/nand/raw/nand_base.c   | 27 +++
>  drivers/mtd/nand/raw/stm32_fmc2_nand.c |  2 +-
>  drivers/mtd/nand/raw/sunxi_nand.c  |  2 +-
>  include/linux/mtd/rawnand.h|  6 +++---
>  8 files changed, 38 insertions(+), 24 deletions(-)
> 
> 
> azure build:
> 
> https://dev.azure.com/hs0298/hs/_build/results?buildId=74&view=results
> 
> Thanks!
> 
> bye,
> Heiko
> 

Re: Please pull u-boot-i2c/next

[Heiko Schocher]

Hello Patrice,

On 28.09.21 09:05, Patrice CHOTARD wrote:
> Hi Heiko, Tom
> 
> Is this PR can be merged into v2021.10 ?
> The patch "mtd: nand: raw: convert nand_dt_init() to ofnode_xx() interface" 
> is fixing 
> an issue for all platforms for which OF_LIVE flag is enabled.
> 
> For all these platforms, all nand DT property can't be read (nand-bus-width, 
> nand-on-flash-bbt, 
> nand-ecc-mode.nand-ecc-strength andnand-ecc-step-size properties are 
> concerned)
> 
> It has been detected on STM32MP1 platforms.

>From my side yes, but as it is in next I think it cannot go directly
into master ...  may tom pickup this patch directly?

bye,
Heiko
> 
> Thanks
> Patrice
> 
> 
> 
> 
> 
> On 9/28/21 8:32 AM, Heiko Schocher wrote:
>> Hello Tom,
>>
>> please pull from u-boot-i2c next
>>
>> The following changes since commit 1d1f98c8eed7bb4792300e655c2cb70136928f74:
>>
>>   Merge tag 'dm-pull-next-27sep21' of 
>> https://source.denx.de/u-boot/custodians/u-boot-dm into next
>> (2021-09-27 11:09:23 -0400)
>>
>> are available in the Git repository at:
>>
>>   https://source.denx.de/u-boot/custodians/u-boot-i2c.git 20210928-for-next
>>
>> for you to fetch changes up to a70c3f9fb84524243eabefd28e0aa539f22e6226:
>>
>>   mtd: nand: raw: convert nand_dt_init() to ofnode_xx() interface 
>> (2021-09-28 06:34:45 +0200)
>>
>> 
>> i2c changes for 20210928-for-next
>>
>> - i2c: rcar_i2c: Enable configuring SCL rise and fall times
>> - i2c: mvtwsi: Add support for DM clocks and resets
>> - mtd: nand: raw: convert nand_dt_init() to ofnode_xx() interface
>>
>> 
>> Adam Ford (1):
>>   i2c: rcar_i2c: Enable configuring SCL rise and fall times
>>
>> Patrice Chotard (1):
>>   mtd: nand: raw: convert nand_dt_init() to ofnode_xx() interface
>>
>> Samuel Holland (1):
>>   i2c: mvtwsi: Add support for DM clocks and resets
>>
>>  drivers/i2c/mvtwsi.c   | 13 +
>>  drivers/i2c/rcar_i2c.c |  8 +++-
>>  drivers/mtd/nand/raw/denali.c  |  2 +-
>>  drivers/mtd/nand/raw/mxs_nand.c|  2 +-
>>  drivers/mtd/nand/raw/nand_base.c   | 27 +++
>>  drivers/mtd/nand/raw/stm32_fmc2_nand.c |  2 +-
>>  drivers/mtd/nand/raw/sunxi_nand.c  |  2 +-
>>  include/linux/mtd/rawnand.h|  6 +++---
>>  8 files changed, 38 insertions(+), 24 deletions(-)
>>
>>
>> azure build:
>>
>> https://dev.azure.com/hs0298/hs/_build/results?buildId=74&view=results
>>
>> Thanks!
>>
>> bye,
>> Heiko
>>

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

Re: [PATCH 0/5] Apple M1 Support

[Mark Kettenis]

> From: Simon Glass 
> Date: Mon, 27 Sep 2021 21:46:56 -0600
> 
> Hi Mark,
> 
> On Sun, 26 Sept 2021 at 09:53, Simon Glass  wrote:
> >
> > Hi Mark,
> >
> > On Sat, 25 Sept 2021 at 10:46, Mark Kettenis  
> > wrote:
> > >
> > > > From: Simon Glass 
> > > > Date: Sat, 25 Sep 2021 08:42:30 -0600
> > > >
> > > > Hi Mark,
> > > >
> > > > On Sat, 25 Sept 2021 at 07:52, Mark Kettenis  
> > > > wrote:
> > > > >
> > > > > > From: Simon Glass 
> > > > > > Date: Sat, 25 Sep 2021 07:27:41 -0600
> > > > > >
> > > > > > Hi Mark,
> > > > > >
> > > > > > On Sat, 25 Sept 2021 at 02:11, Mark Kettenis 
> > > > > >  wrote:
> > > > > > >
> > > > > > > > From: Simon Glass 
> > > > > > > > Date: Fri, 24 Sep 2021 19:20:32 -0600
> > > > > > > >
> > > > > > > > Hi Mark,
> > > > > > > >
> > > > > > > > On Sat, 18 Sept 2021 at 07:54, Mark Kettenis 
> > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > > This series adds basic support for Apple's M1 SoC to U-Boot.
> > > > > > > > > This builds a basic U-Boot that can be used as a payload
> > > > > > > > > for the m1n1 boot loader being developed by the Asahi Linux
> > > > > > > > > project.
> > > > > > > > >
> > > > > > > > > The goal here is to privide an UEFI interface on these 
> > > > > > > > > machines that
> > > > > > > >
> > > > > > > > provide
> > > > > > > >
> > > > > > > > > allows booting various open source OSes.  This initial series 
> > > > > > > > > provides
> > > > > > > > > support for the serial port, framebuffer and the USB 3.1 
> > > > > > > > > Type-C ports.
> > > > > > > > > It can boot a support OS (e.g. OpenBSD/arm64) from a USB disk.
> > > > > > > > >
> > > > > > > > > Mark Kettenis (5):
> > > > > > > > >   arm: apple: Add initial support for Apple's M1 SoC
> > > > > > > > >   serial: s5p: Add Apple M1 support
> > > > > > > > >   misc: Add Apple DART driver
> > > > > > > > >   arm: dts: apple: Add preliminary device trees
> > > > > > > > >   doc: board: apple: Add Apple M1 documentation
> > > > > > > > >
> > > > > > > > >  arch/arm/Kconfig  |  22 +
> > > > > > > > >  arch/arm/Makefile |   1 +
> > > > > > > > >  arch/arm/dts/t8103-j274.dts   | 135 +
> > > > > > > > >  arch/arm/dts/t8103-j293.dts   |  97 
> > > > > > > > >  arch/arm/dts/t8103.dtsi   | 506 
> > > > > > > > > ++
> > > > > > > > >  arch/arm/include/asm/arch-m1/clk.h|  11 +
> > > > > > > > >  arch/arm/include/asm/arch-m1/uart.h   |  41 ++
> > > > > > > > >  arch/arm/mach-apple/Kconfig   |  18 +
> > > > > > > > >  arch/arm/mach-apple/Makefile  |   4 +
> > > > > > > > >  arch/arm/mach-apple/board.c   | 163 ++
> > > > > > > > >  arch/arm/mach-apple/lowlevel_init.S   |  16 +
> > > > > > > > >  configs/apple_m1_defconfig|  14 +
> > > > > > > > >  doc/board/apple/index.rst |   9 +
> > > > > > > > >  doc/board/apple/m1.rst|  54 ++
> > > > > > > > >  doc/board/index.rst   |   1 +
> > > > > > > > >  drivers/misc/Kconfig  |   7 +
> > > > > > > > >  drivers/misc/Makefile |   1 +
> > > > > > > > >  drivers/misc/apple_dart.c | 171 ++
> > > > > > > > >  drivers/serial/Kconfig|   2 +-
> > > > > > > > >  drivers/serial/serial_s5p.c   |  22 +
> > > > > > > > >  include/configs/apple.h   |  38 ++
> > > > > > > > >  .../interrupt-controller/apple-aic.h  |  15 +
> > > > > > > > >  include/dt-bindings/pinctrl/apple.h   |  13 +
> > > > > > > > >  include/dt-bindings/spmi/spmi.h   |  10 +
> > > > > > > > >  24 files changed, 1370 insertions(+), 1 deletion(-)
> > > > > > > > >  create mode 100644 arch/arm/dts/t8103-j274.dts
> > > > > > > > >  create mode 100644 arch/arm/dts/t8103-j293.dts
> > > > > > > > >  create mode 100644 arch/arm/dts/t8103.dtsi
> > > > > > > > >  create mode 100644 arch/arm/include/asm/arch-m1/clk.h
> > > > > > > > >  create mode 100644 arch/arm/include/asm/arch-m1/uart.h
> > > > > > > > >  create mode 100644 arch/arm/mach-apple/Kconfig
> > > > > > > > >  create mode 100644 arch/arm/mach-apple/Makefile
> > > > > > > > >  create mode 100644 arch/arm/mach-apple/board.c
> > > > > > > > >  create mode 100644 arch/arm/mach-apple/lowlevel_init.S
> > > > > > > > >  create mode 100644 configs/apple_m1_defconfig
> > > > > > > > >  create mode 100644 doc/board/apple/index.rst
> > > > > > > > >  create mode 100644 doc/board/apple/m1.rst
> > > > > > > > >  create mode 100644 drivers/misc/apple_dart.c
> > > > > > > > >  create mode 100644 include/configs/apple.h
> > > > > > > > >  create mode 100644 
> > > > > > > > > include/dt-bindings/interrupt-controller/apple-aic.h
> > > > > > > > >  create mode 100644 include/dt-bindings/pinctrl/apple.h
> > > > > > > > >

Re: [PATCH v2] cmd: ubi: add a command to swap volumes

[Heiko Schocher]

Hello Ayoub,

On 09.09.21 13:52, Ayoub Zaki wrote:
> This commit adds the command ubi swap to swap an ubi volumes.
> The format of the command is: ubi swap  .
> To enable this command, the option CMD_UBI_SWAPVOL must be selected.
> ---
>  cmd/Kconfig |  8 
>  cmd/ubi.c   | 54 +
>  2 files changed, 62 insertions(+)

Could you please add a Signed-off-by line?

And please add in further patches a change log [1], may you want
to use patman u-boot:/tools/patman/README

Thanks!

bye,
Heiko
[1] https://www.denx.de/wiki/view/U-Boot/Patches#Sending_updated_patch_versions
-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

[PATCH] nvme: invalidate correct memory range after read

[Stefan Agner]

The current code invalidates the range after the read buffer since the
buffer pointer gets incremented in the read loop. Use a temporary
pointer to make sure we have a pristine pointer to invalidate the
correct memory range after read.

Fixes: 704e040a51d2 ("nvme: Apply cache operations on the DMA buffers")
Signed-off-by: Stefan Agner 
---

 drivers/nvme/nvme.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c
index f6465ea7f4..354513ad30 100644
--- a/drivers/nvme/nvme.c
+++ b/drivers/nvme/nvme.c
@@ -743,6 +743,7 @@ static ulong nvme_blk_rw(struct udevice *udev, lbaint_t 
blknr,
u64 prp2;
u64 total_len = blkcnt << desc->log2blksz;
u64 temp_len = total_len;
+   void *temp_buffer = buffer;
 
u64 slba = blknr;
u16 lbas = 1 << (dev->max_transfer_shift - ns->lba_shift);
@@ -770,19 +771,19 @@ static ulong nvme_blk_rw(struct udevice *udev, lbaint_t 
blknr,
}
 
if (nvme_setup_prps(dev, &prp2,
-   lbas << ns->lba_shift, (ulong)buffer))
+   lbas << ns->lba_shift, (ulong)temp_buffer))
return -EIO;
c.rw.slba = cpu_to_le64(slba);
slba += lbas;
c.rw.length = cpu_to_le16(lbas - 1);
-   c.rw.prp1 = cpu_to_le64((ulong)buffer);
+   c.rw.prp1 = cpu_to_le64((ulong)temp_buffer);
c.rw.prp2 = cpu_to_le64(prp2);
status = nvme_submit_sync_cmd(dev->queues[NVME_IO_Q],
&c, NULL, IO_TIMEOUT);
if (status)
break;
temp_len -= (u32)lbas << ns->lba_shift;
-   buffer += lbas << ns->lba_shift;
+   temp_buffer += lbas << ns->lba_shift;
}
 
if (read)
-- 
2.33.0

[PATCH] sandbox: Remove OF_HOSTFILE

[Ilias Apalodimas]

OF_HOSTFILE is used on sandbox configs only.  Although it's pretty
unique not a source of any confusions,  we are better of having simple
config options for the DTB.
So let's replace that with the existing OF_BOARD.  This will make U-Boot
have only three different config options for the DTB origin.
- OF_SEPARATE, build separately from U-Boot
- OF_BOARD, board specific way of providing the DTB
- OF_EMBED embedded in the u-boot binary, but discouraged from being used
  in production

Signed-off-by: Ilias Apalodimas 
---
 Makefile  |  6 +++---
 arch/sandbox/cpu/cpu.c| 21 -
 arch/sandbox/include/asm/u-boot-sandbox.h |  8 
 configs/sandbox64_defconfig   |  2 +-
 configs/sandbox_defconfig |  2 +-
 configs/sandbox_flattree_defconfig|  2 +-
 configs/sandbox_noinst_defconfig  |  2 +-
 configs/sandbox_spl_defconfig |  2 +-
 configs/tools-only_defconfig  |  2 +-
 doc/develop/devicetree/control.rst|  7 +++
 dts/Kconfig   |  9 -
 lib/fdtdec.c  |  5 -
 scripts/Makefile.spl  |  4 ++--
 13 files changed, 26 insertions(+), 46 deletions(-)

diff --git a/Makefile b/Makefile
index 3014788e14e8..cf3d98d00a62 100644
--- a/Makefile
+++ b/Makefile
@@ -957,7 +957,7 @@ INPUTS-$(CONFIG_BINMAN_STANDALONE_FDT) += u-boot.dtb
 ifeq ($(CONFIG_SPL_FRAMEWORK),y)
 INPUTS-$(CONFIG_OF_SEPARATE) += u-boot-dtb.img
 endif
-INPUTS-$(CONFIG_OF_HOSTFILE) += u-boot.dtb
+INPUTS-$(CONFIG_SANDBOX) += u-boot.dtb
 ifneq ($(CONFIG_SPL_TARGET),)
 INPUTS-$(CONFIG_SPL) += $(CONFIG_SPL_TARGET:"%"=%)
 endif
@@ -1423,7 +1423,7 @@ u-boot-lzma.img: u-boot.bin.lzma FORCE
 
 u-boot-dtb.img u-boot.img u-boot.kwb u-boot.pbl u-boot-ivt.img: \
$(if $(CONFIG_SPL_LOAD_FIT),u-boot-nodtb.bin \
-   $(if 
$(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_OF_HOSTFILE)$(CONFIG_BINMAN_STANDALONE_FDT),dts/dt.dtb)
 \
+   $(if 
$(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_SANDBOX)$(CONFIG_BINMAN_STANDALONE_FDT),dts/dt.dtb)
 \
,$(UBOOT_BIN)) FORCE
$(call if_changed,mkimage)
$(BOARD_SIZE_CHECK)
@@ -1437,7 +1437,7 @@ MKIMAGEFLAGS_u-boot.itb += -B 0x8
 
 ifdef U_BOOT_ITS
 u-boot.itb: u-boot-nodtb.bin \
-   $(if 
$(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_OF_HOSTFILE),dts/dt.dtb) \
+   $(if 
$(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_SANDBOX),dts/dt.dtb) \
$(U_BOOT_ITS) FORCE
$(call if_changed,mkfitimage)
$(BOARD_SIZE_CHECK)
diff --git a/arch/sandbox/cpu/cpu.c b/arch/sandbox/cpu/cpu.c
index 48636ab63919..bc67a5a5a10b 100644
--- a/arch/sandbox/cpu/cpu.c
+++ b/arch/sandbox/cpu/cpu.c
@@ -291,44 +291,47 @@ void invalidate_dcache_range(unsigned long start, 
unsigned long stop)
 {
 }
 
-int sandbox_read_fdt_from_file(void)
+void *board_fdt_blob_setup(void)
 {
struct sandbox_state *state = state_get_current();
const char *fname = state->fdt_fname;
-   void *blob;
+   void *blob = NULL;
loff_t size;
int err;
int fd;
 
+   printf("SETUP BLOB\n");
blob = map_sysmem(CONFIG_SYS_FDT_LOAD_ADDR, 0);
if (!state->fdt_fname) {
err = fdt_create_empty_tree(blob, 256);
if (!err)
goto done;
printf("Unable to create empty FDT: %s\n", fdt_strerror(err));
-   return -EINVAL;
+   goto fail;
}
 
err = os_get_filesize(fname, &size);
if (err < 0) {
printf("Failed to file FDT file '%s'\n", fname);
-   return err;
+   goto fail;
}
fd = os_open(fname, OS_O_RDONLY);
if (fd < 0) {
printf("Failed to open FDT file '%s'\n", fname);
-   return -EACCES;
+   goto fail;
}
+
if (os_read(fd, blob, size) != size) {
os_close(fd);
-   return -EIO;
+   printf("Failed to read file '%s'\n", fname);
+   goto fail;
}
os_close(fd);
 
 done:
-   gd->fdt_blob = blob;
-
-   return 0;
+   return blob;
+fail:
+   return NULL;
 }
 
 ulong timer_get_boot_us(void)
diff --git a/arch/sandbox/include/asm/u-boot-sandbox.h 
b/arch/sandbox/include/asm/u-boot-sandbox.h
index 73b1897191d5..56dc13c3eb11 100644
--- a/arch/sandbox/include/asm/u-boot-sandbox.h
+++ b/arch/sandbox/include/asm/u-boot-sandbox.h
@@ -76,14 +76,6 @@ int pci_unmap_physmem(const void *addr, unsigned long len,
  */
 void sandbox_set_enable_pci_map(int enable);
 
-/**
- * sandbox_read_fdt_from_file() - Read a device tree from a file
- *
- * Read a device tree file from a host file and set it up for use as the
- * control FDT.
- */
-int sandbox_read_fdt_from_file(void);
-
 /**
  * sandbox_reset() - reset 

[PATCH] sandbox: Remove OF_HOSTFILE

[Ilias Apalodimas]

OF_HOSTFILE is used on sandbox configs only.  Although it's pretty
unique not a source of any confusions,  we are better of having simple
config options for the DTB.
So let's replace that with the existing OF_BOARD.  This will make U-Boot
have only three different config options for the DTB origin.
- OF_SEPARATE, build separately from U-Boot
- OF_BOARD, board specific way of providing the DTB
- OF_EMBED embedded in the u-boot binary, but discouraged from being used
  in production

Signed-off-by: Ilias Apalodimas 
---
 Makefile  |  6 +++---
 arch/sandbox/cpu/cpu.c| 21 -
 arch/sandbox/include/asm/u-boot-sandbox.h |  8 
 configs/sandbox64_defconfig   |  2 +-
 configs/sandbox_defconfig |  2 +-
 configs/sandbox_flattree_defconfig|  2 +-
 configs/sandbox_noinst_defconfig  |  2 +-
 configs/sandbox_spl_defconfig |  2 +-
 configs/tools-only_defconfig  |  2 +-
 doc/develop/devicetree/control.rst|  7 +++
 dts/Kconfig   |  9 -
 lib/fdtdec.c  |  5 -
 scripts/Makefile.spl  |  4 ++--
 13 files changed, 26 insertions(+), 46 deletions(-)

diff --git a/Makefile b/Makefile
index 3014788e14e8..cf3d98d00a62 100644
--- a/Makefile
+++ b/Makefile
@@ -957,7 +957,7 @@ INPUTS-$(CONFIG_BINMAN_STANDALONE_FDT) += u-boot.dtb
 ifeq ($(CONFIG_SPL_FRAMEWORK),y)
 INPUTS-$(CONFIG_OF_SEPARATE) += u-boot-dtb.img
 endif
-INPUTS-$(CONFIG_OF_HOSTFILE) += u-boot.dtb
+INPUTS-$(CONFIG_SANDBOX) += u-boot.dtb
 ifneq ($(CONFIG_SPL_TARGET),)
 INPUTS-$(CONFIG_SPL) += $(CONFIG_SPL_TARGET:"%"=%)
 endif
@@ -1423,7 +1423,7 @@ u-boot-lzma.img: u-boot.bin.lzma FORCE
 
 u-boot-dtb.img u-boot.img u-boot.kwb u-boot.pbl u-boot-ivt.img: \
$(if $(CONFIG_SPL_LOAD_FIT),u-boot-nodtb.bin \
-   $(if 
$(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_OF_HOSTFILE)$(CONFIG_BINMAN_STANDALONE_FDT),dts/dt.dtb)
 \
+   $(if 
$(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_SANDBOX)$(CONFIG_BINMAN_STANDALONE_FDT),dts/dt.dtb)
 \
,$(UBOOT_BIN)) FORCE
$(call if_changed,mkimage)
$(BOARD_SIZE_CHECK)
@@ -1437,7 +1437,7 @@ MKIMAGEFLAGS_u-boot.itb += -B 0x8
 
 ifdef U_BOOT_ITS
 u-boot.itb: u-boot-nodtb.bin \
-   $(if 
$(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_OF_HOSTFILE),dts/dt.dtb) \
+   $(if 
$(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_SANDBOX),dts/dt.dtb) \
$(U_BOOT_ITS) FORCE
$(call if_changed,mkfitimage)
$(BOARD_SIZE_CHECK)
diff --git a/arch/sandbox/cpu/cpu.c b/arch/sandbox/cpu/cpu.c
index 48636ab63919..bc67a5a5a10b 100644
--- a/arch/sandbox/cpu/cpu.c
+++ b/arch/sandbox/cpu/cpu.c
@@ -291,44 +291,47 @@ void invalidate_dcache_range(unsigned long start, 
unsigned long stop)
 {
 }
 
-int sandbox_read_fdt_from_file(void)
+void *board_fdt_blob_setup(void)
 {
struct sandbox_state *state = state_get_current();
const char *fname = state->fdt_fname;
-   void *blob;
+   void *blob = NULL;
loff_t size;
int err;
int fd;
 
+   printf("SETUP BLOB\n");
blob = map_sysmem(CONFIG_SYS_FDT_LOAD_ADDR, 0);
if (!state->fdt_fname) {
err = fdt_create_empty_tree(blob, 256);
if (!err)
goto done;
printf("Unable to create empty FDT: %s\n", fdt_strerror(err));
-   return -EINVAL;
+   goto fail;
}
 
err = os_get_filesize(fname, &size);
if (err < 0) {
printf("Failed to file FDT file '%s'\n", fname);
-   return err;
+   goto fail;
}
fd = os_open(fname, OS_O_RDONLY);
if (fd < 0) {
printf("Failed to open FDT file '%s'\n", fname);
-   return -EACCES;
+   goto fail;
}
+
if (os_read(fd, blob, size) != size) {
os_close(fd);
-   return -EIO;
+   printf("Failed to read file '%s'\n", fname);
+   goto fail;
}
os_close(fd);
 
 done:
-   gd->fdt_blob = blob;
-
-   return 0;
+   return blob;
+fail:
+   return NULL;
 }
 
 ulong timer_get_boot_us(void)
diff --git a/arch/sandbox/include/asm/u-boot-sandbox.h 
b/arch/sandbox/include/asm/u-boot-sandbox.h
index 73b1897191d5..56dc13c3eb11 100644
--- a/arch/sandbox/include/asm/u-boot-sandbox.h
+++ b/arch/sandbox/include/asm/u-boot-sandbox.h
@@ -76,14 +76,6 @@ int pci_unmap_physmem(const void *addr, unsigned long len,
  */
 void sandbox_set_enable_pci_map(int enable);
 
-/**
- * sandbox_read_fdt_from_file() - Read a device tree from a file
- *
- * Read a device tree file from a host file and set it up for use as the
- * control FDT.
- */
-int sandbox_read_fdt_from_file(void);
-
 /**
  * sandbox_reset() - reset 

[PATCH] board: ti: Add support for the AM437x GP EVM mini board

[Amjad Ouled-Ameur]

From: Andreas Dannenberg 

This is not really a new board but rather a minimal bootloader solution
for the AM437x GP EVM. In terms of interfaces, it only supports booting
from MMC0 or UART0 and only activates a minimal set of drivers that are
that are necessary to run the device such as DDR, I2C, and PMIC.

The goal is to provide a bare minimum starting point to boot Linux for
basing custom board-ports on. The limited complexity of this solution
should make it easier to achieve a successful boot to U-Boot prompt vs.
trying to pair down the full-featured multi-platform AM437x U-Boot
available through am43xx_evm_defconfig.

Signed-off-by: Andreas Dannenberg 
[Amjad: fix compile and checkpatch warnings]
Signed-off-by: Amjad Ouled-Ameur 

---
Tests:
- This has been tested on AM43xx platform, the board boots successfully
to u-boot prompt and runs basic commands seamlessly, please find the logs
here: [0]
However, regarding the kernel boot test, sometimes it does boot correctly,
sometimes it does not, but this patch does not actually guaranteey that
since its purpose is to mainly allow the user to achieve a successful boot
to U-boot prompt.

[0]: https://pastebin.com/zmCsjQRT

 MAINTAINERS  |   4 +
 arch/arm/dts/Makefile|   5 +-
 arch/arm/dts/am437x-gp-evm-mini.dts  | 171 ++
 arch/arm/mach-omap2/am33xx/Kconfig   |  22 ++
 board/ti/am43xx/Kconfig  |  13 +-
 board/ti/am43xx/Makefile |   6 +-
 board/ti/am43xx/board_hs_mini.h  |  27 ++
 board/ti/am43xx/board_mini.c | 452 +++
 board/ti/am43xx/board_mini.h |  28 ++
 board/ti/am43xx/mux_mini.c   |  53 
 configs/am43xx_evm_mini_defconfig|  39 +++
 configs/am43xx_hs_evm_mini_defconfig |  47 +++
 include/configs/am43xx_evm_mini.h| 120 +++
 13 files changed, 983 insertions(+), 4 deletions(-)
 create mode 100644 arch/arm/dts/am437x-gp-evm-mini.dts
 create mode 100644 board/ti/am43xx/board_hs_mini.h
 create mode 100644 board/ti/am43xx/board_mini.c
 create mode 100644 board/ti/am43xx/board_mini.h
 create mode 100644 board/ti/am43xx/mux_mini.c
 create mode 100644 configs/am43xx_evm_mini_defconfig
 create mode 100644 configs/am43xx_hs_evm_mini_defconfig
 create mode 100644 include/configs/am43xx_evm_mini.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 5370b550648e..0159be0e4673 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -492,6 +492,7 @@ F:  arch/arm/mach-keystone/
 F: arch/arm/mach-omap2/
 F: arch/arm/include/asm/arch-omap*/
 F: arch/arm/include/asm/ti-common/
+F: arch/arm/dts/am437x*
 F: board/ti/
 F: drivers/dma/ti*
 F: drivers/firmware/ti_sci.*
@@ -518,6 +519,7 @@ F:  drivers/timer/omap-timer.c
 F: drivers/watchdog/omap_wdt.c
 F: include/linux/pruss_driver.h
 F: include/linux/soc/ti/
+F: include/configs/am43xx_evm_mini.h
 
 ARM U8500
 M: Stephan Gerhold 
@@ -1134,6 +1136,8 @@ F:arch/arm/mach-k3/config_secure.mk
 F: configs/am335x_hs_evm_defconfig
 F: configs/am335x_hs_evm_uart_defconfig
 F: configs/am43xx_hs_evm_defconfig
+F: configs/am43xx_evm_mini_defconfig
+F: configs/am43xx_hs_evm_mini_defconfig
 F: configs/am57xx_hs_evm_defconfig
 F: configs/am57xx_hs_evm_usb_defconfig
 F: configs/dra7xx_hs_evm_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index fc16a57e60b0..3b8c539a6272 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -375,7 +375,10 @@ dtb-$(CONFIG_AM33XX) += \
am335x-guardian.dtb \
am335x-wega-rdk.dtb \
am335x-regor-rdk.dtb
-dtb-$(CONFIG_AM43XX) += am437x-gp-evm.dtb am437x-sk-evm.dtb\
+dtb-$(CONFIG_AM43XX) += \
+   am437x-gp-evm.dtb \
+   am437x-gp-evm-mini.dtb \
+   am437x-sk-evm.dtb \
am43x-epos-evm.dtb \
am437x-idk-evm.dtb \
am4372-generic.dtb \
diff --git a/arch/arm/dts/am437x-gp-evm-mini.dts 
b/arch/arm/dts/am437x-gp-evm-mini.dts
new file mode 100644
index ..07c93c47b638
--- /dev/null
+++ b/arch/arm/dts/am437x-gp-evm-mini.dts
@@ -0,0 +1,171 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+/* AM437x GP EVM MINI */
+
+/dts-v1/;
+
+#include "am4372.dtsi"
+#include 
+#include 
+
+/ {
+   model = "TI AM437x GP EVM MINI";
+   compatible = 
"ti,am437x-gp-evm-mini","ti,am437x-gp-evm","ti,am4372","ti,am43";
+
+   chosen {
+   stdout-path = &uart0;
+   tick-timer = &timer2;
+   };
+
+   ocp {
+   u-boot,dm-spl;
+   };
+
+   vmmcsd_fixed: fixedregulator-sd {
+   compatible = "regulator-fixed";
+   regulator-name = "vmmcsd_fixed";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   enable-active-high;
+   };
+
+   vtt_fixed: fixedregulator-vtt {
+   compatible = "regulator-fixed";
+ 

RE: [EXT] S25HS512 not functional with u-boot 2021.10.rc3

[Kuldeep Singh]

Hi Harkirat,

> -Original Message-
> From: U-Boot  On Behalf Of Harkirat Virk
> Sent: Wednesday, September 15, 2021 12:21 AM
> To: u-boot@lists.denx.de
> Subject: [EXT] S25HS512 not functional with u-boot 2021.10.rc3
> 
> Caution: EXT Email
> 
> I have a custom board using imx6ul and Spansion S25HS512T Flash. On the
> current version of u-boot (2021.10.rc3) and I am guessing even previous ones
> the Spansion flash is not functioning
> 
> => sf probe
> drivers/core/uclass.c:325-uclass_find_device_by_seq() 0
> drivers/core/uclass.c:333-uclass_find_device_by_seq()- 0 'spi@21e'
> drivers/core/uclass.c:336-uclass_find_device_by_seq()- found
> drivers/spi/spi-uclass.c:282-spi_find_chip_select() fsl_qspi spi@21e:
> spi_find_chip_select: plat=9ef2bf60, cs=0
> drivers/core/uclass.c:325-uclass_find_device_by_seq() 0
> drivers/core/uclass.c:333-uclass_find_device_by_seq()- 0 'spi@21e'
> drivers/core/uclass.c:336-uclass_find_device_by_seq()- found
> drivers/spi/spi-uclass.c:282-spi_find_chip_select() fsl_qspi spi@21e:
> spi_find_chip_select: plat=9ef2bf60, cs=0
> drivers/core/uclass.c:325-uclass_find_device_by_seq() 0
> drivers/core/uclass.c:333-uclass_find_device_by_seq()- 0
> 'iomuxc@20e'
> drivers/core/uclass.c:336-uclass_find_device_by_seq()- found
> drivers/pinctrl/pinctrl-uclass.c:300-pinctrl_select_state_simple()
> jedec_spi_nor s25hs512t@0: set_state_simple op missing
> drivers/spi/fsl_qspi.c:464-fsl_qspi_prepare_lut() fsl_qspi spi@21e:
> CMD[9f] lutval[0:1c00049f1:0 2:0 3:0]

Did you try enabling debug logs in spi-nor framework(spi-nor-core.c) and see 
what jedec id's were return after issuing the command?
And does it match with the one's present in spi-nor-ids.c?

> drivers/spi/spi-uclass.c:438-  spi_get_bus_and_cs() spi_get_bus_and_cs:
> Error path, created=0, device 's25hs512t@0'
> Failed to initialize SPI flash at 0:0 (error -524)
> 
> Result is the same with different modes and frequencies, bus and CS are
> correct
> 
> My DTSI is
> 
> &qspi {
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_qspi>;
> status = "okay";
> 
> flash0: s25hs512t@0 {
> #address-cells = <1>;
> #size-cells = <1>;
> compatible = "spansion,s25hs512t", "jedec,spi-nor";

Please use compatible as "jedec,spi-nor" as it is sufficient to detect the 
flash automatically.

> spi-max-frequency = <4000>;
> spi-rx-bus-width = <4>;
> spi-tx-bus-width = <4>;

Since flash cannot be probed, I would recommend using  bus-width as 
<1,1>.
Using <4,4> bus-width will require SPI_FLASH_SFDP to be enabled in defconfig.

Regards
Kuldeep

> reg = <0>;
> spi-mode = <0>;
> m25p,fast-read;
> status = "okay";
> /* some partition information*/
> };
> };
> 
> Defconfig has
> 
> CONFIG_SPI=y
> CONFIG_DM_SPI=y
> CONFIG_FSL_QSPI=y
> CONFIG_MTD=y
> CONFIG_DM_MTD=y
> CONFIG_DM_SPI_FLASH=y
> CONFIG_SF_DEFAULT_MODE=0
> CONFIG_SF_DEFAULT_SPEED=4000
> CONFIG_SPI_FLASH_SPANSION=y
> 
>  DM Tree
> 
> => dm tree
>  Class Index  Probed  DriverName
> ---
>  root  0  [ + ]   root_driver   root_driver
>  thermal   0  [   ]   imx_thermal   |-- imx_thermal
>  simple_bus0  [ + ]   simple_bus|-- soc
>  simple_bus1  [ + ]   simple_bus|   |-- aips-bus@200
>  simple_bus2  [ + ]   simple_bus|   |   |-- spba-bus@200
>  serial0  [ + ]   serial_mxc|   |   |   `-- serial@202
>  gpio  0  [   ]   gpio_mxc  |   |   |-- gpio@209c000
>  gpio  1  [   ]   gpio_mxc  |   |   |-- gpio@20a
>  gpio  2  [   ]   gpio_mxc  |   |   |-- gpio@20a4000
>  gpio  3  [   ]   gpio_mxc  |   |   |-- gpio@20a8000
>  gpio  4  [   ]   gpio_mxc  |   |   |-- gpio@20ac000
>  simple_bus3  [   ]   simple_bus|   |   |-- anatop@20c8000
>  simple_bus4  [   ]   simple_bus|   |   |-- snvs@20cc000
>  pinctrl   0  [ + ]   fsl_imx6q_iomuxc  |   |   `-- iomuxc@20e
>  pinconfig 0  [   ]   pinconfig |   |   |-- i2c1grp
>  pinconfig 1  [   ]   pinconfig |   |   |-- i2c2grp
>  pinconfig 2  [ + ]   pinconfig |   |   |-- qspigrp
>  pinconfig 3  [   ]   pinconfig |   |   |-- ledsgrp
>  pinconfig 4  [ + ]   pinconfig |   |   |-- uart1grp
>  pinconfig 5  [ + ]   pinconfig |   |   |-- usdhc2grp
>  pinconfig 6  [   ]   pinconfig |   |   `-- wdoggrp
>  simple_bus5  [ + ]   simple_bus|   `-- aips-bus@210
>  usb   0  [   ]   ehci_mx6  |   |-- us

[PATCH] board: ti: Add support for the AM335x GP EVM mini board

[Amjad Ouled-Ameur]

From: Andreas Dannenberg 

This is not really a new board but rather a minimal bootloader solution
for the AM335x GP EVM. In terms of interfaces, it only supports booting
from MMC0 or UART0 and only activates a minimal set of drivers that are
that are necessary to run the device such as DDR, I2C, and PMIC.

The goal is to provide a bare minimum starting point to boot Linux for
basing custom board-ports on. The limited complexity of this solution
should make it easier to achieve a successful boot to U-Boot prompt vs.
trying to pair down the full-featured multi-platform AM335x U-Boot
available through am335x_evm_defconfig.

Signed-off-by: Andreas Dannenberg 
[Amjad: fix checkpatch and compile warnings]
Signed-off-by: Amjad Ouled-Ameur 

---
Tests:
- This has been tested on Am335x platform, the board boots successfully
to u-boot prompt and runs basic commands seamlessly, please find the logs
here: [0]
However, regarding the kernel boot test, this patch does not actually
guaranteey that since its purpose is to mainly allow the user to achieve a
successful boot to U-boot prompt.

[0]: https://pastebin.com/ixQ2yB9n

 MAINTAINERS  |   1 +
 arch/arm/dts/Makefile|   1 +
 arch/arm/dts/am335x-bone-common.dtsi |   1 +
 arch/arm/dts/am335x-evm-mini.dts | 166 ++
 arch/arm/mach-omap2/am33xx/Kconfig   |  30 
 board/ti/am335x/Kconfig  |  13 +-
 board/ti/am335x/Makefile |   6 +-
 board/ti/am335x/board_hs_mini.h  |  19 ++
 board/ti/am335x/board_mini.c | 249 +++
 board/ti/am335x/board_mini.h |  44 +
 board/ti/am335x/mux_mini.c   | 109 
 configs/am335x_evm_mini_defconfig|  42 +
 configs/am335x_hs_evm_mini_defconfig |  46 +
 include/configs/am335x_evm_mini.h|  96 +++
 14 files changed, 820 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm/dts/am335x-evm-mini.dts
 create mode 100644 board/ti/am335x/board_hs_mini.h
 create mode 100644 board/ti/am335x/board_mini.c
 create mode 100644 board/ti/am335x/board_mini.h
 create mode 100644 board/ti/am335x/mux_mini.c
 create mode 100644 configs/am335x_evm_mini_defconfig
 create mode 100644 configs/am335x_hs_evm_mini_defconfig
 create mode 100644 include/configs/am335x_evm_mini.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 5370b550648e..09b942acd109 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -492,6 +492,7 @@ F:  arch/arm/mach-keystone/
 F: arch/arm/mach-omap2/
 F: arch/arm/include/asm/arch-omap*/
 F: arch/arm/include/asm/ti-common/
+F: arch/arm/dts/am335x*
 F: board/ti/
 F: drivers/dma/ti*
 F: drivers/firmware/ti_sci.*
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index fc16a57e60b0..faf8f438bf29 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -360,6 +360,7 @@ dtb-$(CONFIG_AM33XX) += \
am335x-brsmarc1.dtb \
am335x-draco.dtb \
am335x-evm.dtb \
+   am335x-evm-mini.dtb \
am335x-evmsk.dtb \
am335x-bonegreen.dtb \
am335x-icev2.dtb \
diff --git a/arch/arm/dts/am335x-bone-common.dtsi 
b/arch/arm/dts/am335x-bone-common.dtsi
index 35ec1a8df870..a87558686709 100644
--- a/arch/arm/dts/am335x-bone-common.dtsi
+++ b/arch/arm/dts/am335x-bone-common.dtsi
@@ -211,6 +211,7 @@
 
tps: tps@24 {
reg = <0x24>;
+   #interrupt-cells = <1>;
};
 
baseboard_eeprom: baseboard_eeprom@50 {
diff --git a/arch/arm/dts/am335x-evm-mini.dts b/arch/arm/dts/am335x-evm-mini.dts
new file mode 100644
index ..f45da0fd3f6f
--- /dev/null
+++ b/arch/arm/dts/am335x-evm-mini.dts
@@ -0,0 +1,166 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com/
+ */
+/dts-v1/;
+
+#include "am33xx.dtsi"
+#include 
+
+/ {
+   model = "TI AM335x EVM MINI";
+   compatible = "ti,am335x-evm-mini", "ti,am335x-evm", "ti,am33xx";
+
+   chosen {
+   stdout-path = &uart0;
+   tick-timer = &timer2;
+   };
+
+   cpus {
+   cpu@0 {
+   cpu0-supply = <&vdd1_reg>;
+   };
+   };
+
+   memory {
+   device_type = "memory";
+   reg = <0x8000 0x1000>; /* 256 MB */
+   };
+
+   vbat: fixedregulator@0 {
+   compatible = "regulator-fixed";
+   regulator-name = "vbat";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   regulator-boot-on;
+   };
+};
+
+&am33xx_pinmux {
+   i2c0_pins: pinmux_i2c0_pins {
+   pinctrl-single,pins = <
+   0x188 (PIN_INPUT_PULLUP | MUX_MODE0)/* 
i2c0_sda.i2c0_sda */
+   0x18c (PIN_INPUT_PULLUP | MUX_MODE0)/* 
i2c0_scl.i2c0_scl */
+   >;
+   };
+
+   uart0_pins: pinmux_uart0_pins {
+   pinctrl-single

RE: [PATCH] introduce CONFIG_DEVICE_TREE_INCLUDES

[Roman Kopytin]

Hi, all
I prepared 3 patches for fdt_add_pubkey adding.
But in our company infrastructure I can't use git send-email. Our IT can't help 
me to resolve issue.

-Original Message-
From: Rasmus Villemoes  
Sent: Tuesday, September 28, 2021 11:57 AM
To: u-boot@lists.denx.de
Cc: Alex Kiernan ; Simon Glass ; 
Roman Kopytin ; Masahiro Yamada 
; Rasmus Villemoes 
Subject: [PATCH] introduce CONFIG_DEVICE_TREE_INCLUDES

The build system already automatically looks for and includes an in-tree 
*-u-boot.dtsi when building the control .dtb. However, there are some things 
that are awkward to maintain in such an in-tree file, most notably the metadata 
associated to public keys used for verified boot.

The only "official" API to get that metadata into the .dtb is via mkimage, as a 
side effect of building an actual signed image. But there are multiple problems 
with that. First of all, the final U-Boot (be it U-Boot proper or an SPL) image 
is built based on a binary image, the .dtb, and possibly some other binary 
artifacts. So modifying the .dtb after the build requires the meta-buildsystem 
(Yocto, buildroot, whatnot) to know about and repeat some of the steps that are 
already known to and handled by U-Boot's build system, resulting in needless 
duplication of code. It's also somewhat annoying and inconsistent to have a 
.dtb file in the build folder which is not generated by the command listed in 
the corresponding .cmd file (that of course applies to any generated file).

So the contents of the /signature node really needs to be baked into the .dtb 
file when it is first created, which means providing the relevant data in the 
form of a .dtsi file. One could in theory put that data into the *-u-boot.dtsi 
file, but it's more convenient to be able to provide it externally: For 
example, when developing for a customer, it's common to use a set of dummy keys 
for development, while the consultants do not (and should not) have access to 
the actual keys used in production. For such a setup, it's easier if the keys 
used are chosen via the meta-buildsystem and the path(s) patched in during the 
configure step. And of course, nothing prevents anybody from having 
DEVICE_TREE_INCLUDES point at files maintained in git, or for that matter from 
including the public key metadata in the *-u-boot.dtsi directly and ignore this 
feature.

There are other uses for this, e.g. in combination with ENV_IMPORT_FDT it can 
be used for providing the contents of the /config/environment node, so I don't 
want to tie this exclusively to use for verified boot.

Signed-off-by: Rasmus Villemoes 
---

Getting the public key metadata into .dtsi form can be done with a little 
scripting (roughly 'mkimage -K' of a dummy image followed by 'dtc -I dtb -O 
dts'). I have a script that does that, along with options to set 'required' and 
'required-mode' properties, include u-boot,dm-spl properties in case one wants 
to check U-Boot proper from SPL with the verified boot mechanism, etc. I'm 
happy to share that script if this gets accepted, but it's moot if this is 
rejected.

I have previously tried to get an fdt_add_pubkey tool accepted [1,2] to 
disentangle the kernel and u-boot builds (or u-boot and SPL builds for that 
matter!), but as I've since realized, that isn't quite enough
- the above points re modifying the .dtb after it is created but before that is 
used to create further build artifacts still stand. However, such a tool could 
still be useful for creating the .dtsi info without the private keys being 
present, and my key2dtsi.sh script could easily be modified to use a tool like 
that should it ever appear.

[1] 
https://lore.kernel.org/u-boot/20200211094818.14219-3-rasmus.villem...@prevas.dk/
[2] 
https://lore.kernel.org/u-boot/2184f1e6dd6247e48133c76205fee...@kaspersky.com/

 dts/Kconfig  | 9 +
 scripts/Makefile.lib | 2 ++
 2 files changed, 11 insertions(+)

diff --git a/dts/Kconfig b/dts/Kconfig
index dabe0080c1..593dddbaf0 100644
--- a/dts/Kconfig
+++ b/dts/Kconfig
@@ -139,6 +139,15 @@ config DEFAULT_DEVICE_TREE
  It can be overridden from the command line:
  $ make DEVICE_TREE=
 
+config DEVICE_TREE_INCLUDES
+   string "Extra .dtsi files to include when building DT control"
+   depends on OF_CONTROL
+   help
+ U-Boot's control .dtb is usually built from an in-tree .dts
+ file, plus (if available) an in-tree U-Boot-specific .dtsi
+ file. This option specifies a space-separated list of extra
+ .dtsi files that will also be used.
+
 config OF_LIST
string "List of device tree files to include for DT control"
depends on SPL_LOAD_FIT || MULTI_DTB_FIT diff --git 
a/scripts/Makefile.lib b/scripts/Makefile.lib index 78bbebe7e9..a2accba940 
100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -320,6 +320,8 @@ quiet_cmd_dtc = DTC $@
 # Bring in any U-Boot-specific include at the end of the file  cmd_dtc = mkdir 
-p $(dir ${dtc-t

Re: GSuit limit for recipients

[Oleksandr Suvorov]

Hello Tom,

Thank you! It seems the only reasonable solution. I'm just slightly worried
about commits being made non-atomic :(

On Tue, Sep 28, 2021 at 12:06 AM Tom Rini  wrote:
>
> On Mon, Sep 27, 2021 at 05:58:08PM +0300, Oleksandr Suvorov wrote:
>
> > Dear community,
> >
> > This weekend I tried to post (using patman) a patch set that should
> > have been sent to 120 recipients (a lot of files were changed).
> >
> > I've got an error from the Gmail SMTP server:
> > 4.5.3 Your message has too many recipients. For more information regarding
> > 4.5.3 Google's sending limits, please visit:
> > 4.5.3  https://support.google.com/mail/?p=TooManyRecipientsError
> > e1sm1539543ljp.114 - gsmtp
> >
> > The doc says there is a limit for recipients - 100 per message. All my
> > emails are hosted by Gmail/G-suit. I think I'm not the first who faced
> > such an issue.
> > Could you share your tricks or best practices on how to post patch
> > sets with more than 100 recipients without changing an e-mail
> > provider?
> >
> > Thanks in advance for your help!
>
> Honestly, that probably means the patch needs to be split up more.  Per
> SoC / SoC family perhaps.
>
> --
> Tom



-- 
Best regards,

Oleksandr Suvorov
Software Engineer
T: +380 63 8489656
E: oleksandr.suvo...@foundries.io
W: www.foundries.io

Re: [PATCH v2] cmd: ubi: add a command to swap volumes

[Wolfgang Denk]

Dear Ayoub,

In message <20210909115257.14147-1-ayoub.z...@embexus.com> you wrote:
> This commit adds the command ubi swap to swap an ubi volumes.
> The format of the command is: ubi swap  .
> To enable this command, the option CMD_UBI_SWAPVOL must be selected.

May I ask what this command is good for, i. e. what is the intended
use case?

I have the feeling that you might want to do something which
requires an atomic operation, but you should be aware that the
implementation is NOT atomic - even worse: in case of problems there
is not even a way to fall back to the old state.

So if you think to use this for example for reliable software
updates, then you have a big problem here.

Or am I missing something?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Niklaus Wirth has lamented that, whereas Europeans pronounce his name
correctly  (Ni-klows  Virt),  Americans  invariably  mangle  it  into
(Nick-les  Worth).  Which  is to say that Europeans call him by name,
but Americans call him by value.

[PATCH] introduce CONFIG_DEVICE_TREE_INCLUDES

[Rasmus Villemoes]

The build system already automatically looks for and includes an
in-tree *-u-boot.dtsi when building the control .dtb. However, there
are some things that are awkward to maintain in such an in-tree file,
most notably the metadata associated to public keys used for verified
boot.

The only "official" API to get that metadata into the .dtb is via
mkimage, as a side effect of building an actual signed image. But
there are multiple problems with that. First of all, the final U-Boot
(be it U-Boot proper or an SPL) image is built based on a binary
image, the .dtb, and possibly some other binary artifacts. So
modifying the .dtb after the build requires the meta-buildsystem
(Yocto, buildroot, whatnot) to know about and repeat some of the steps
that are already known to and handled by U-Boot's build system,
resulting in needless duplication of code. It's also somewhat annoying
and inconsistent to have a .dtb file in the build folder which is not
generated by the command listed in the corresponding .cmd file (that
of course applies to any generated file).

So the contents of the /signature node really needs to be baked into
the .dtb file when it is first created, which means providing the
relevant data in the form of a .dtsi file. One could in theory put
that data into the *-u-boot.dtsi file, but it's more convenient to be
able to provide it externally: For example, when developing for a
customer, it's common to use a set of dummy keys for development,
while the consultants do not (and should not) have access to the
actual keys used in production. For such a setup, it's easier if the
keys used are chosen via the meta-buildsystem and the path(s) patched
in during the configure step. And of course, nothing prevents anybody
from having DEVICE_TREE_INCLUDES point at files maintained in git, or
for that matter from including the public key metadata in the
*-u-boot.dtsi directly and ignore this feature.

There are other uses for this, e.g. in combination with ENV_IMPORT_FDT
it can be used for providing the contents of the /config/environment
node, so I don't want to tie this exclusively to use for verified
boot.

Signed-off-by: Rasmus Villemoes 
---

Getting the public key metadata into .dtsi form can be done with a
little scripting (roughly 'mkimage -K' of a dummy image followed by
'dtc -I dtb -O dts'). I have a script that does that, along with
options to set 'required' and 'required-mode' properties, include
u-boot,dm-spl properties in case one wants to check U-Boot proper from
SPL with the verified boot mechanism, etc. I'm happy to share that
script if this gets accepted, but it's moot if this is rejected.

I have previously tried to get an fdt_add_pubkey tool accepted [1,2]
to disentangle the kernel and u-boot builds (or u-boot and SPL builds
for that matter!), but as I've since realized, that isn't quite enough
- the above points re modifying the .dtb after it is created but
before that is used to create further build artifacts still
stand. However, such a tool could still be useful for creating the
.dtsi info without the private keys being present, and my key2dtsi.sh
script could easily be modified to use a tool like that should it ever
appear.

[1] 
https://lore.kernel.org/u-boot/20200211094818.14219-3-rasmus.villem...@prevas.dk/
[2] 
https://lore.kernel.org/u-boot/2184f1e6dd6247e48133c76205fee...@kaspersky.com/

 dts/Kconfig  | 9 +
 scripts/Makefile.lib | 2 ++
 2 files changed, 11 insertions(+)

diff --git a/dts/Kconfig b/dts/Kconfig
index dabe0080c1..593dddbaf0 100644
--- a/dts/Kconfig
+++ b/dts/Kconfig
@@ -139,6 +139,15 @@ config DEFAULT_DEVICE_TREE
  It can be overridden from the command line:
  $ make DEVICE_TREE=
 
+config DEVICE_TREE_INCLUDES
+   string "Extra .dtsi files to include when building DT control"
+   depends on OF_CONTROL
+   help
+ U-Boot's control .dtb is usually built from an in-tree .dts
+ file, plus (if available) an in-tree U-Boot-specific .dtsi
+ file. This option specifies a space-separated list of extra
+ .dtsi files that will also be used.
+
 config OF_LIST
string "List of device tree files to include for DT control"
depends on SPL_LOAD_FIT || MULTI_DTB_FIT
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 78bbebe7e9..a2accba940 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -320,6 +320,8 @@ quiet_cmd_dtc = DTC $@
 # Bring in any U-Boot-specific include at the end of the file
 cmd_dtc = mkdir -p $(dir ${dtc-tmp}) ; \
(cat $<; $(if $(u_boot_dtsi),echo '$(pound)include "$(u_boot_dtsi)"')) 
> $(pre-tmp); \
+   $(foreach f,$(subst $(quote),,$(CONFIG_DEVICE_TREE_INCLUDES)), \
+ echo '$(pound)include "$(f)"' >> $(pre-tmp);) \
$(CPP) $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) $(pre-tmp) 
; \
$(DTC) -O dtb -o $@ -b 0 \
-i $(dir $<) $(DTC_FLAGS) \
-- 
2.31.1

Re: [PATCH] imx: imx7d-sdb: fix ethernet, sync .dts with linux

[Rasmus Villemoes]

On 16/09/2021 18.52, Fabio Estevam wrote:
> Hi Rasmus,
> 
> On Thu, Sep 16, 2021 at 11:53 AM Rasmus Villemoes
>  wrote:
>>
>> Commit 0d52bab46 (mx7dsabre: Enable DM_ETH) changed these flags from 0
>> (aka GPIO_ACTIVE_HIGH) to GPIO_ACTIVE_LOW. It claimed to "Also sync
>> device tree with v5.5-rc1", but in the linux tree, these gpios have
>> always been GPIO_ACTIVE_HIGH ever since this node was introduced
>> around v4.13 (linux commit 184f39b5).
>>
>> I'm guessing that the reason for the GPIO_ACTIVE_LOW was to work
>> around the behaviour of the soft-spi driver back then, which
>> effectively defaulted to spi-mode 3 and not 0. That was arguably a bug
>> in the soft-spi driver, which then got fixed in 0e146993bb3 (spi: add
>> support for all spi modes with soft spi), but that commit then broke
>> ethernet on this board.
>>
>> Fix it by setting the gpios as active high, which as a bonus actually
>> brings us in sync with the .dts in the linux source tree.
>>
>> Without this, one gets
>>
>> Net:   Could not get PHY for FEC0: addr 0
>> No ethernet found.
>>
>> With this, ethernet (at least ping and tftp) works as expected from
>> the U-Boot shell.
>>
>> Cc: Fabio Estevam 
>> Cc: Joris Offouga 
>> Cc: "Christian Bräuner Sørensen" 
>> Signed-off-by: Rasmus Villemoes 
> 
> Thanks for the fix:
> 
> Reviewed-by: Fabio Estevam 
> 

Any chance this can make it in before v2021.10 is released?

Rasmus

[PATCH] imx: mx7: spl: fix CONFIG_SPL_MAX_SIZE definition

[Matthias Schiffer]

The CONFIG_SPL_MAX_SIZE definition did not account for all areas that
are used by the boot ROM according to the manual, causing boot failures
due to truncated SPL images when actually hitting this limit.

Signed-off-by: Matthias Schiffer 
---
 include/configs/imx7_spl.h | 20 ++--
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/include/configs/imx7_spl.h b/include/configs/imx7_spl.h
index 01d1cd83b23..128f612392f 100644
--- a/include/configs/imx7_spl.h
+++ b/include/configs/imx7_spl.h
@@ -18,15 +18,23 @@
  *  - Set the stack at the end of the free area section, at 0x00946BB8.
  *  - The BOOT ROM loads what they consider the firmware image
  *which consists of a 4K header in front of us that contains the IVT, DCD
- *and some padding thus 'our' max size is really 0x00946BB8 - 0x00911000.
- *64KB is more then enough for the SPL.
+ *and some padding. However, the manual also states that the ROM uses the
+ *OCRAM_EPCD and OCRAM_PXP areas for itself. While the SPL is free to use
+ *this range for stack and malloc, the SPL itself must fit below 0x92,
+ *or the image will be truncated in at least some boot modes like USB SDP.
+ *Thus our max size is really 0x0092 - 0x00912000. If necessary,
+ *CONFIG_SPL_TEXT_BASE could be moved to 0x00911000 to gain 4KB of space
+ *for the SPL, but 56KB should be more than enough for the SPL.
  */
-#define CONFIG_SPL_MAX_SIZE0x1
+#define CONFIG_SPL_MAX_SIZE0xE000
 #define CONFIG_SPL_STACK   0x00946BB8
 /*
- * Pad SPL to 68KB (4KB header + 64KB max size). This allows to write the
- * SPL/U-Boot combination generated with u-boot-with-spl.imx directly to a
- * boot media (given that boot media specific offset is configured properly).
+ * Pad SPL to 68KB (4KB header + 56KB max size + 8KB extra padding)
+ * The extra padding could be removed, but this value was used historically
+ * based on an incorrect CONFIG_SPL_MAX_SIZE definition.
+ * This allows to write the SPL/U-Boot combination generated with
+ * u-boot-with-spl.imx directly to a boot media (given that boot media specific
+ * offset is configured properly).
  */
 #define CONFIG_SPL_PAD_TO  0x11000
 
-- 
2.17.1

Re: [PATCH v2 3/3] efi_loader: add DeployedMode and AuditMode variable measurement

[Masahisa Kojima]

On Mon, 27 Sept 2021 at 22:53, Ilias Apalodimas
 wrote:
>
> On Tue, 21 Sept 2021 at 10:17, Masahisa Kojima
>  wrote:
> >
> > This commit adds the DeployedMode and AuditMode variable
> > measurement required in TCG PC Client PFP Spec.
> >
> > Signed-off-by: Masahisa Kojima 
> > ---
> >
> > (no changes since v1)
> >
> >  lib/efi_loader/efi_tcg2.c | 47 +++
> >  1 file changed, 47 insertions(+)
> >
> > diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
> > index ea2c1ead03..68542c7cd3 100644
> > --- a/lib/efi_loader/efi_tcg2.c
> > +++ b/lib/efi_loader/efi_tcg2.c
> > @@ -12,6 +12,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -1828,6 +1829,50 @@ out:
> > return ret;
> >  }
> >
> > +/**
> > + * tcg2_measure_deployed_audit_mode() - measure deployedmode and auditmode
> > + *
> > + * @dev:   TPM device
> > + *
> > + * Return: status code
> > + */
> > +static efi_status_t tcg2_measure_deployed_audit_mode(struct udevice *dev)
> > +{
> > +   u8 deployed_mode;
> > +   u8 audit_mode;
> > +   efi_uintn_t size;
> > +   efi_status_t ret;
> > +   u32 pcr_index;
> > +
> > +   size = sizeof(deployed_mode);
> > +   ret = efi_get_variable_int(L"DeployedMode", 
> > &efi_global_variable_guid,
> > +  NULL, &size, &deployed_mode, NULL);
> > +   if (ret != EFI_SUCCESS)
> > +   return ret;
> > +
> > +   pcr_index = (deployed_mode ? 1 : 7);
> > +
> > +   ret = tcg2_measure_variable(dev, pcr_index,
> > +   EV_EFI_VARIABLE_DRIVER_CONFIG,
> > +   L"DeployedMode",
> > +   &efi_global_variable_guid,
> > +   size, &deployed_mode);
> > +
>
> tcg2_measure_variable() can't fail here?  Do we care if it does?

I will add appropriate error handling.

>
> > +   size = sizeof(audit_mode);
> > +   ret = efi_get_variable_int(L"AuditMode", &efi_global_variable_guid,
> > +  NULL, &size, &audit_mode, NULL);
> > +   if (ret != EFI_SUCCESS)
> > +   return ret;
> > +
> > +   ret = tcg2_measure_variable(dev, pcr_index,
> > +   EV_EFI_VARIABLE_DRIVER_CONFIG,
> > +   L"AuditMode",
> > +   &efi_global_variable_guid,
> > +   size, &audit_mode);
> > +
>
> Does it make sense to read both of the variables first and measure
> them only if both are present?

Yes, it is better. If one of the variable is not present, skip both DeployedMode
and AuditMode measurement.

> IOW is there any connection between AuditMode and DeployedMode measurements?

In UEFI spec:
 DeployedMode = 1 -> AuditMode is always 0
 DeployedMode = 0 -> AuditMode can be 0 or 1

Thanks,
Masahisa Kojima

>
>
> Regards
> /Ilias
> > +   return ret;
> > +}
> > +
> >  /**
> >   * tcg2_measure_secure_boot_variable() - measure secure boot variables
> >   *
> > @@ -1891,6 +1936,8 @@ static efi_status_t 
> > tcg2_measure_secure_boot_variable(struct udevice *dev)
> > free(data);
> > }
> >
> > +   ret = tcg2_measure_deployed_audit_mode(dev);
> > +
> >  error:
> > return ret;
> >  }
> > --
> > 2.17.1
> >

Re: [PATCH 0/5] Apple M1 Support

[Simon Glass]

Hi Mark,

On Tue, 28 Sept 2021 at 01:36, Mark Kettenis  wrote:
>
> > From: Simon Glass 
> > Date: Mon, 27 Sep 2021 21:46:56 -0600
> >
> > Hi Mark,
> >
> > On Sun, 26 Sept 2021 at 09:53, Simon Glass  wrote:
> > >
> > > Hi Mark,
> > >
> > > On Sat, 25 Sept 2021 at 10:46, Mark Kettenis  
> > > wrote:
> > > >
> > > > > From: Simon Glass 
> > > > > Date: Sat, 25 Sep 2021 08:42:30 -0600
> > > > >
> > > > > Hi Mark,
> > > > >
> > > > > On Sat, 25 Sept 2021 at 07:52, Mark Kettenis 
> > > > >  wrote:
> > > > > >
> > > > > > > From: Simon Glass 
> > > > > > > Date: Sat, 25 Sep 2021 07:27:41 -0600
> > > > > > >
> > > > > > > Hi Mark,
> > > > > > >
> > > > > > > On Sat, 25 Sept 2021 at 02:11, Mark Kettenis 
> > > > > > >  wrote:
> > > > > > > >
> > > > > > > > > From: Simon Glass 
> > > > > > > > > Date: Fri, 24 Sep 2021 19:20:32 -0600
> > > > > > > > >
> > > > > > > > > Hi Mark,
> > > > > > > > >
> > > > > > > > > On Sat, 18 Sept 2021 at 07:54, Mark Kettenis 
> > > > > > > > >  wrote:
> > > > > > > > > >
> > > > > > > > > > This series adds basic support for Apple's M1 SoC to U-Boot.
> > > > > > > > > > This builds a basic U-Boot that can be used as a payload
> > > > > > > > > > for the m1n1 boot loader being developed by the Asahi Linux
> > > > > > > > > > project.
> > > > > > > > > >
> > > > > > > > > > The goal here is to privide an UEFI interface on these 
> > > > > > > > > > machines that
> > > > > > > > >
> > > > > > > > > provide
> > > > > > > > >
> > > > > > > > > > allows booting various open source OSes.  This initial 
> > > > > > > > > > series provides
> > > > > > > > > > support for the serial port, framebuffer and the USB 3.1 
> > > > > > > > > > Type-C ports.
> > > > > > > > > > It can boot a support OS (e.g. OpenBSD/arm64) from a USB 
> > > > > > > > > > disk.
> > > > > > > > > >
> > > > > > > > > > Mark Kettenis (5):
> > > > > > > > > >   arm: apple: Add initial support for Apple's M1 SoC
> > > > > > > > > >   serial: s5p: Add Apple M1 support
> > > > > > > > > >   misc: Add Apple DART driver
> > > > > > > > > >   arm: dts: apple: Add preliminary device trees
> > > > > > > > > >   doc: board: apple: Add Apple M1 documentation
> > > > > > > > > >
> > > > > > > > > >  arch/arm/Kconfig  |  22 +
> > > > > > > > > >  arch/arm/Makefile |   1 +
> > > > > > > > > >  arch/arm/dts/t8103-j274.dts   | 135 +
> > > > > > > > > >  arch/arm/dts/t8103-j293.dts   |  97 
> > > > > > > > > >  arch/arm/dts/t8103.dtsi   | 506 
> > > > > > > > > > ++
> > > > > > > > > >  arch/arm/include/asm/arch-m1/clk.h|  11 +
> > > > > > > > > >  arch/arm/include/asm/arch-m1/uart.h   |  41 ++
> > > > > > > > > >  arch/arm/mach-apple/Kconfig   |  18 +
> > > > > > > > > >  arch/arm/mach-apple/Makefile  |   4 +
> > > > > > > > > >  arch/arm/mach-apple/board.c   | 163 ++
> > > > > > > > > >  arch/arm/mach-apple/lowlevel_init.S   |  16 +
> > > > > > > > > >  configs/apple_m1_defconfig|  14 +
> > > > > > > > > >  doc/board/apple/index.rst |   9 +
> > > > > > > > > >  doc/board/apple/m1.rst|  54 ++
> > > > > > > > > >  doc/board/index.rst   |   1 +
> > > > > > > > > >  drivers/misc/Kconfig  |   7 +
> > > > > > > > > >  drivers/misc/Makefile |   1 +
> > > > > > > > > >  drivers/misc/apple_dart.c | 171 ++
> > > > > > > > > >  drivers/serial/Kconfig|   2 +-
> > > > > > > > > >  drivers/serial/serial_s5p.c   |  22 +
> > > > > > > > > >  include/configs/apple.h   |  38 ++
> > > > > > > > > >  .../interrupt-controller/apple-aic.h  |  15 +
> > > > > > > > > >  include/dt-bindings/pinctrl/apple.h   |  13 +
> > > > > > > > > >  include/dt-bindings/spmi/spmi.h   |  10 +
> > > > > > > > > >  24 files changed, 1370 insertions(+), 1 deletion(-)
> > > > > > > > > >  create mode 100644 arch/arm/dts/t8103-j274.dts
> > > > > > > > > >  create mode 100644 arch/arm/dts/t8103-j293.dts
> > > > > > > > > >  create mode 100644 arch/arm/dts/t8103.dtsi
> > > > > > > > > >  create mode 100644 arch/arm/include/asm/arch-m1/clk.h
> > > > > > > > > >  create mode 100644 arch/arm/include/asm/arch-m1/uart.h
> > > > > > > > > >  create mode 100644 arch/arm/mach-apple/Kconfig
> > > > > > > > > >  create mode 100644 arch/arm/mach-apple/Makefile
> > > > > > > > > >  create mode 100644 arch/arm/mach-apple/board.c
> > > > > > > > > >  create mode 100644 arch/arm/mach-apple/lowlevel_init.S
> > > > > > > > > >  create mode 100644 configs/apple_m1_defconfig
> > > > > > > > > >  create mode 100644 doc/board/apple/index.rst
> > > > > > > > > >  create mode 100644 doc/board/apple/m1.rst
> > > > > > > > > >  create mode 100644 drivers/m

Re: [PATCH] board: ti: Add support for the AM335x GP EVM mini board

[Tom Rini]

... trimming the CC list.

On Tue, Sep 28, 2021 at 11:41:36AM +0200, Amjad Ouled-Ameur wrote:

> From: Andreas Dannenberg 
> 
> This is not really a new board but rather a minimal bootloader solution
> for the AM335x GP EVM. In terms of interfaces, it only supports booting
> from MMC0 or UART0 and only activates a minimal set of drivers that are
> that are necessary to run the device such as DDR, I2C, and PMIC.
> 
> The goal is to provide a bare minimum starting point to boot Linux for
> basing custom board-ports on. The limited complexity of this solution
> should make it easier to achieve a successful boot to U-Boot prompt vs.
> trying to pair down the full-featured multi-platform AM335x U-Boot
> available through am335x_evm_defconfig.
> 
> Signed-off-by: Andreas Dannenberg 
> [Amjad: fix checkpatch and compile warnings]
> Signed-off-by: Amjad Ouled-Ameur 

There's a few problems here, and I say this as someone who is doing the
"mini" version for J721e/etc.  First:

> diff --git a/arch/arm/dts/am335x-evm-mini.dts 
> b/arch/arm/dts/am335x-evm-mini.dts
> new file mode 100644
> index ..f45da0fd3f6f
> --- /dev/null
> +++ b/arch/arm/dts/am335x-evm-mini.dts

No new dts files.  You use the same dts for kernel and u-boot, and have
to write one once.  And it all Just Works when you want to
enable more features on your platform.

> diff --git a/arch/arm/mach-omap2/am33xx/Kconfig 
> b/arch/arm/mach-omap2/am33xx/Kconfig
> index 4268419b166b..296559a00c15 100644
> --- a/arch/arm/mach-omap2/am33xx/Kconfig
> +++ b/arch/arm/mach-omap2/am33xx/Kconfig
> @@ -63,6 +63,36 @@ config TARGET_AM335X_EVM
> to write software and develop hardware around
> an AM335x processor subsystem.
>  
> +config TARGET_AM335X_EVM_MINI
> + bool "Support am335x_evm_mini"
> + select BOARD_LATE_INIT
> + select DM
> + select DM_GPIO
> + select DM_SERIAL
> + imply CMD_DM
> + imply SPL_DM
> + imply SPL_DM_SEQ_ALIAS
> + imply SPL_ENV_SUPPORT
> + imply SPL_FS_EXT4
> + imply SPL_FS_FAT
> + imply SPL_GPIO_SUPPORT
> + imply SPL_I2C_SUPPORT
> + imply SPL_LIBCOMMON_SUPPORT
> + imply SPL_LIBDISK_SUPPORT
> + imply SPL_LIBGENERIC_SUPPORT
> + imply SPL_MMC_SUPPORT
> + imply SPL_OF_LIBFDT
> + imply SPL_POWER_SUPPORT
> + imply SPL_SEPARATE_BSS
> + imply SPL_SERIAL_SUPPORT
> + imply SPL_SYS_MALLOC_SIMPLE
> + imply SPL_YMODEM_SUPPORT
> + help
> +   This option specifies support for the AM335x
> +   GP and HS EVM development platforms using a minimal
> +   system configuration, only supporting a small subset
> +   of boot media and other features.

There should be, maybe, a few selects, for things you simply cannot
avoid, and no imply's.  The point is something that's clear about what
is enabled and why it's enabled.  And you've got a bunch of extra stuff
enabled there.

> diff --git a/board/ti/am335x/board_hs_mini.h b/board/ti/am335x/board_hs_mini.h
> new file mode 100644
> index ..e03ba141f286
> --- /dev/null
> +++ b/board/ti/am335x/board_hs_mini.h
> @@ -0,0 +1,19 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * TI AM437x boards information header
> + * Derived from AM335x board.
> + *
> + * Copyright (C) 2020, Texas Instruments, Incorporated - http://www.ti.com/
> + */
> +
> +#ifndef _BOARD_HS_H_
> +#define _BOARD_HS_H_
> +
> +#ifdef CONFIG_TI_SECURE_DEVICE
> +void board_fit_image_post_process(void **p_image, size_t *p_size)
> +{
> + secure_boot_verify_image(p_image, p_size);
> +}
> +#endif
> +
> +#endif

I'd like some of the TI folks to chime in on if we really need to have a
"mini" HS variant too.

> diff --git a/board/ti/am335x/board_mini.c b/board/ti/am335x/board_mini.c
> new file mode 100644
> index ..94f0a2910be3
> --- /dev/null
> +++ b/board/ti/am335x/board_mini.c
> @@ -0,0 +1,249 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Mini board functions for TI AM335X based boards
> + *
> + * Copyright (C) 2020, Texas Instruments, Incorporated - http://www.ti.com/
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "board_mini.h"
> +#include "board_hs_mini.h"

Check if we really need all of those includes still.

[snip]
> +const struct dpll_params *get_dpll_mpu_params(void)
> +{
> + int ind = get_sys_clk_index();
> + int freq = am335x_get_efuse_mpu_max_freq(cdev);
> +
> + switch (freq) {
> + case MPUPLL_M_1000:
> + return &dpll_mpu_opp[ind][5];
> + case MPUPLL_M_800:
> + return &dpll_mpu_opp[ind][4];
> + case MPUPLL_M_720:
> + return &dpll_mpu_opp[ind][3];
> + case MPUPLL_M_600:
> + return &dpll_mpu_opp[ind][2];
> + case MPUPL

Re: Please pull u-boot-i2c/next

[Tom Rini]

On Tue, Sep 28, 2021 at 09:26:43AM +0200, Heiko Schocher wrote:
> Hello Patrice,
> 
> On 28.09.21 09:05, Patrice CHOTARD wrote:
> > Hi Heiko, Tom
> > 
> > Is this PR can be merged into v2021.10 ?
> > The patch "mtd: nand: raw: convert nand_dt_init() to ofnode_xx() interface" 
> > is fixing 
> > an issue for all platforms for which OF_LIVE flag is enabled.
> > 
> > For all these platforms, all nand DT property can't be read 
> > (nand-bus-width, nand-on-flash-bbt, 
> > nand-ecc-mode.nand-ecc-strength andnand-ecc-step-size properties are 
> > concerned)
> > 
> > It has been detected on STM32MP1 platforms.
> 
> From my side yes, but as it is in next I think it cannot go directly
> into master ...  may tom pickup this patch directly?

I can put:
https://patchwork.ozlabs.org/project/uboot/patch/20210913142553.24333-1-patrice.chot...@foss.st.com/
in to my regression fixes bundle, which I'll apply shortly.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] fastboot: fix partition name truncation in environment lookup

[Matthias Schiffer]

On Fri, 2021-07-30 at 10:04 -0400, Sean Anderson wrote:
> On 7/30/21 8:23 AM, Matthias Schiffer wrote:
> > strlcat() need to be passed the full buffer length. The incorrect call
> > caused truncation of partition names for fastboot_raw_partition_... and
> > fastboot_partition_alias_... env lookup to much less than PART_NAME_LEN.
> > 
> > Fixes: 69a752983171 ("fastboot: Fix possible buffer overrun")
> > Signed-off-by: Matthias Schiffer 
> > ---
> >   drivers/fastboot/fb_mmc.c | 4 ++--
> >   1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/fastboot/fb_mmc.c b/drivers/fastboot/fb_mmc.c
> > index 2f3837e559..33fd6c21af 100644
> > --- a/drivers/fastboot/fb_mmc.c
> > +++ b/drivers/fastboot/fb_mmc.c
> > @@ -40,7 +40,7 @@ static int raw_part_get_info_by_name(struct blk_desc 
> > *dev_desc,
> >   
> > /* check for raw partition descriptor */
> > strcpy(env_desc_name, "fastboot_raw_partition_");
> > -   strlcat(env_desc_name, name, PART_NAME_LEN);
> > +   strlcat(env_desc_name, name, sizeof(env_desc_name));
> > raw_part_desc = strdup(env_get(env_desc_name));
> > if (raw_part_desc == NULL)
> > return -ENODEV;
> > @@ -114,7 +114,7 @@ static int part_get_info_by_name_or_alias(struct 
> > blk_desc **dev_desc,
> >   
> > /* check for alias */
> > strcpy(env_alias_name, "fastboot_partition_alias_");
> > -   strlcat(env_alias_name, name, PART_NAME_LEN);
> > +   strlcat(env_alias_name, name, sizeof(env_alias_name));
> > aliased_part_name = env_get(env_alias_name);
> > if (aliased_part_name != NULL)
> > ret = do_get_part_info(dev_desc, aliased_part_name,
> > 
> 
> Reviewed-by: Sean Anderson 

Hi,
what's the status here? It would be great to have this bugfix in the
next release.

Regards,
Matthias

Re: [PATCH] imx: imx7d-sdb: fix ethernet, sync .dts with linux

[Tom Rini]

On Tue, Sep 28, 2021 at 12:18:10PM +0200, Rasmus Villemoes wrote:

> On 16/09/2021 18.52, Fabio Estevam wrote:
> > Hi Rasmus,
> > 
> > On Thu, Sep 16, 2021 at 11:53 AM Rasmus Villemoes
> >  wrote:
> >>
> >> Commit 0d52bab46 (mx7dsabre: Enable DM_ETH) changed these flags from 0
> >> (aka GPIO_ACTIVE_HIGH) to GPIO_ACTIVE_LOW. It claimed to "Also sync
> >> device tree with v5.5-rc1", but in the linux tree, these gpios have
> >> always been GPIO_ACTIVE_HIGH ever since this node was introduced
> >> around v4.13 (linux commit 184f39b5).
> >>
> >> I'm guessing that the reason for the GPIO_ACTIVE_LOW was to work
> >> around the behaviour of the soft-spi driver back then, which
> >> effectively defaulted to spi-mode 3 and not 0. That was arguably a bug
> >> in the soft-spi driver, which then got fixed in 0e146993bb3 (spi: add
> >> support for all spi modes with soft spi), but that commit then broke
> >> ethernet on this board.
> >>
> >> Fix it by setting the gpios as active high, which as a bonus actually
> >> brings us in sync with the .dts in the linux source tree.
> >>
> >> Without this, one gets
> >>
> >> Net:   Could not get PHY for FEC0: addr 0
> >> No ethernet found.
> >>
> >> With this, ethernet (at least ping and tftp) works as expected from
> >> the U-Boot shell.
> >>
> >> Cc: Fabio Estevam 
> >> Cc: Joris Offouga 
> >> Cc: "Christian Bräuner Sørensen" 
> >> Signed-off-by: Rasmus Villemoes 
> > 
> > Thanks for the fix:
> > 
> > Reviewed-by: Fabio Estevam 
> > 
> 
> Any chance this can make it in before v2021.10 is released?

Yes, I'll pick it up.

-- 
Tom


signature.asc
Description: PGP signature

Re: Please pull u-boot-i2c/next

[Heiko Schocher]

Hi Tom,

On 28.09.21 14:20, Tom Rini wrote:
> On Tue, Sep 28, 2021 at 09:26:43AM +0200, Heiko Schocher wrote:
>> Hello Patrice,
>>
>> On 28.09.21 09:05, Patrice CHOTARD wrote:
>>> Hi Heiko, Tom
>>>
>>> Is this PR can be merged into v2021.10 ?
>>> The patch "mtd: nand: raw: convert nand_dt_init() to ofnode_xx() interface" 
>>> is fixing 
>>> an issue for all platforms for which OF_LIVE flag is enabled.
>>>
>>> For all these platforms, all nand DT property can't be read 
>>> (nand-bus-width, nand-on-flash-bbt, 
>>> nand-ecc-mode.nand-ecc-strength andnand-ecc-step-size properties are 
>>> concerned)
>>>
>>> It has been detected on STM32MP1 platforms.
>>
>> From my side yes, but as it is in next I think it cannot go directly
>> into master ...  may tom pickup this patch directly?
> 
> I can put:
> https://patchwork.ozlabs.org/project/uboot/patch/20210913142553.24333-1-patrice.chot...@foss.st.com/
> in to my regression fixes bundle, which I'll apply shortly.
> 

Fine with me, thanks!

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

Re: imx6 DM_VIDEObroken

[Anatolij Gustschin]

Hey Tim,

On Mon, 27 Sep 2021 17:25:58 -0700
Tim Harvey thar...@gateworks.com wrote:

> Anatolij,
> 
> Since commit d37618d18d49 ("imx: convert gwventana board to DM_VIDEO")
> video support for IMX6 based Ventana boards has been broken.

Back then I've tested similar DM_VIDEO conversion changes on i.mx6q
nitrogen6q board and on i.mx6d/i.mx6s wandboards, it was okay if
the board configuration uses the video console output during the
boot sequence (i.e. configured to show splash screen or to output
strings on vidconsole).
 
> I find that while the bind function for fsl_imx6q_ipu is called the
> probe never is (ipuv3_video_probe). Do you know why this is?

Is video console output used during the boot? If not, then it
might be the reason. With DM, the devices are probed when a subsystem
actually tries to use them. You can try to trigger probing via
switching to the video console output, i.e.:

 => setenv stdout vidconsole
> 
> I see that with commit 57f065fee2a4 ("video: ipuv3: add DM_VIDEO
> support") you mention that DTS files must include
> 'u-boot,dm-pre-reloc' for soc/ipu nodes to enable driver binding to
> ipu device but I haven't been able to get that to make a difference
> nor have I found a board that does this. You did add those props to
> imx6qdl.dtsi at one point but they are no longer there.

Does your board dts include imx6qdl-u-boot.dtsi ?

The u-boot,dm-pre-reloc properties were moved to this U-Boot specific
dtsi in 7932b1c9fdb73393aa110249c89bd426533c0649
(imx: imx6qdl: dtsi: move U-Boot specific change to u-boot.dtsi)

> There must have been several other IMX6 boards with video support that
> were affected by this so perhaps I'm missing something simple.

I did not test it recently, it looks I'll have to do it before the
new release.

--
Anatolij

Re: [PATCH 01/25] arch: powerpc: mpc85xx: ensure mdiodev->name is NULL terminated after MDIO_NAME_LEN truncation

[Ramon Fried]

On Mon, Sep 27, 2021 at 2:22 PM Vladimir Oltean  wrote:
>
> strncpy() simply bails out when copying a source string whose size
> exceeds the destination string size, potentially leaving the destination
> string unterminated.
>
> One possible way to address is to pass MDIO_NAME_LEN - 1 and a
> previously zero-initialized destination string, but this is more
> difficult to maintain.
>
> The chosen alternative is to use strlcpy(), which properly limits the
> copy len in the (srclen >= size) case to "size - 1", and which is also
> more efficient than the strncpy() byte-by-byte implementation by using
> memcpy. The destination string returned by strlcpy() is always NULL
> terminated.
>
> Signed-off-by: Vladimir Oltean 
> ---
>  arch/powerpc/cpu/mpc85xx/ether_fcc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/cpu/mpc85xx/ether_fcc.c 
> b/arch/powerpc/cpu/mpc85xx/ether_fcc.c
> index 3c4eb1a7eba9..1f6f55707321 100644
> --- a/arch/powerpc/cpu/mpc85xx/ether_fcc.c
> +++ b/arch/powerpc/cpu/mpc85xx/ether_fcc.c
> @@ -444,7 +444,7 @@ int fec_initialize(struct bd_info *bis)
> struct mii_dev *mdiodev = mdio_alloc();
> if (!mdiodev)
> return -ENOMEM;
> -   strncpy(mdiodev->name, dev->name, MDIO_NAME_LEN);
> +   strlcpy(mdiodev->name, dev->name, MDIO_NAME_LEN);
> mdiodev->read = bb_miiphy_read;
> mdiodev->write = bb_miiphy_write;
>
> --
> 2.25.1
>
Reviewed-by: Ramon Fried 

Re: [PATCH 02/25] board: gdsys: a38x: ensure mdiodev->name is NULL terminated after MDIO_NAME_LEN truncation

[Ramon Fried]

On Mon, Sep 27, 2021 at 2:22 PM Vladimir Oltean  wrote:
>
> strncpy() simply bails out when copying a source string whose size
> exceeds the destination string size, potentially leaving the destination
> string unterminated.
>
> One possible way to address is to pass MDIO_NAME_LEN - 1 and a
> previously zero-initialized destination string, but this is more
> difficult to maintain.
>
> The chosen alternative is to use strlcpy(), which properly limits the
> copy len in the (srclen >= size) case to "size - 1", and which is also
> more efficient than the strncpy() byte-by-byte implementation by using
> memcpy. The destination string returned by strlcpy() is always NULL
> terminated.
>
> Signed-off-by: Vladimir Oltean 
> ---
>  board/gdsys/a38x/ihs_phys.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/board/gdsys/a38x/ihs_phys.c b/board/gdsys/a38x/ihs_phys.c
> index c23d15092144..e09c0006b76f 100644
> --- a/board/gdsys/a38x/ihs_phys.c
> +++ b/board/gdsys/a38x/ihs_phys.c
> @@ -110,9 +110,7 @@ int register_miiphy_bus(uint k, struct mii_dev **bus)
>
> if (!mdiodev)
> return -ENOMEM;
> -   strncpy(mdiodev->name,
> -   name,
> -   MDIO_NAME_LEN);
> +   strlcpy(mdiodev->name, name, MDIO_NAME_LEN);
> mdiodev->read = bb_miiphy_read;
> mdiodev->write = bb_miiphy_write;
>
> --
> 2.25.1
>
Reviewed-by: Ramon Fried 

Re: [PATCH 2/9] include: import if_vlan.h from Linux

[Ramon Fried]

On Tue, Sep 28, 2021 at 2:48 AM Vladimir Oltean  wrote:
>
> This is needed for the VLAN header structure.
>
> Signed-off-by: Vladimir Oltean 
> ---
>  include/linux/if_vlan.h | 26 ++
>  1 file changed, 26 insertions(+)
>  create mode 100644 include/linux/if_vlan.h
>
> diff --git a/include/linux/if_vlan.h b/include/linux/if_vlan.h
> new file mode 100644
> index ..cbc82f4cc217
> --- /dev/null
> +++ b/include/linux/if_vlan.h
> @@ -0,0 +1,26 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +/*
> + * VLANAn implementation of 802.1Q VLAN tagging.
> + *
> + * Authors:Ben Greear 
> + */
> +#ifndef _LINUX_IF_VLAN_H_
> +#define _LINUX_IF_VLAN_H_
> +
> +/**
> + * struct vlan_ethhdr - vlan ethernet header (ethhdr + vlan_hdr)
> + * @h_dest: destination ethernet address
> + * @h_source: source ethernet address
> + * @h_vlan_proto: ethernet protocol
> + * @h_vlan_TCI: priority and VLAN ID
> + * @h_vlan_encapsulated_proto: packet type ID or len
> + */
> +struct vlan_ethhdr {
> +   unsigned char   h_dest[ETH_ALEN];
> +   unsigned char   h_source[ETH_ALEN];
> +   __be16  h_vlan_proto;
> +   __be16  h_vlan_TCI;
> +   __be16  h_vlan_encapsulated_proto;
> +};
> +
> +#endif /* !(_LINUX_IF_VLAN_H_) */
> --
> 2.25.1
>
Reviewed-by: Ramon Fried 

Re: [PATCH 7/9] arm: dts: ls1021a-tsn: add sja1105 and eth2 bindings

[Ramon Fried]

On Tue, Sep 28, 2021 at 2:48 AM Vladimir Oltean  wrote:
>
> The eth aliases are for correct probing order, so that each Ethernet
> port will get a predictable MAC address from the environment.
>
> Signed-off-by: Vladimir Oltean 
> ---
>  arch/arm/dts/ls1021a-tsn.dts | 103 +++
>  1 file changed, 103 insertions(+)
>
> diff --git a/arch/arm/dts/ls1021a-tsn.dts b/arch/arm/dts/ls1021a-tsn.dts
> index f633074099dc..48ad7d1ad5db 100644
> --- a/arch/arm/dts/ls1021a-tsn.dts
> +++ b/arch/arm/dts/ls1021a-tsn.dts
> @@ -14,6 +14,81 @@
> enet1-sgmii-phy = &sgmii_phy1;
> spi0 = &qspi;
> spi1 = &dspi1;
> +   ethernet0 = &enet0;
> +   ethernet1 = &enet1;
> +   ethernet2 = &enet2;
> +   ethernet3 = &swp2;
> +   ethernet4 = &swp3;
> +   ethernet5 = &swp4;
> +   ethernet6 = &swp5;
> +   };
> +};
> +
> +&dspi0 {
> +   bus-num = <0>;
> +   status = "okay";
> +
> +   sja1105: ethernet-switch@1 {
> +   reg = <0x1>;
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   compatible = "nxp,sja1105t";
> +   /* 12 MHz */
> +   spi-max-frequency = <1200>;
> +   /* Sample data on trailing clock edge */
> +   spi-cpha;
> +   /* SPI controller settings for SJA1105 timing requirements */
> +   fsl,spi-cs-sck-delay = <1000>;
> +   fsl,spi-sck-cs-delay = <1000>;
> +
> +   ports {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +
> +   swp5: port@0 {
> +   /* ETH5 written on chassis */
> +   label = "swp5";
> +   phy-handle = <&rgmii_phy6>;
> +   phy-mode = "rgmii-id";
> +   reg = <0>;
> +   };
> +
> +   swp2: port@1 {
> +   /* ETH2 written on chassis */
> +   label = "swp2";
> +   phy-handle = <&rgmii_phy3>;
> +   phy-mode = "rgmii-id";
> +   reg = <1>;
> +   };
> +
> +   swp3: port@2 {
> +   /* ETH3 written on chassis */
> +   label = "swp3";
> +   phy-handle = <&rgmii_phy4>;
> +   phy-mode = "rgmii-id";
> +   reg = <2>;
> +   };
> +
> +   swp4: port@3 {
> +   /* ETH4 written on chassis */
> +   label = "swp4";
> +   phy-handle = <&rgmii_phy5>;
> +   phy-mode = "rgmii-id";
> +   reg = <3>;
> +   };
> +
> +   port@4 {
> +   /* Internal port connected to eth2 */
> +   ethernet = <&enet2>;
> +   phy-mode = "rgmii";
> +   reg = <4>;
> +
> +   fixed-link {
> +   speed = <1000>;
> +   full-duplex;
> +   };
> +   };
> +   };
> };
>  };
>
> @@ -31,6 +106,17 @@
> status = "okay";
>  };
>
> +/* RGMII delays added via PCB traces */
> +&enet2 {
> +   phy-mode = "rgmii";
> +   status = "okay";
> +
> +   fixed-link {
> +   speed = <1000>;
> +   full-duplex;
> +   };
> +};
> +
>  &i2c0 {
> status = "okay";
>  };
> @@ -46,6 +132,23 @@
> reg = <0x2>;
> };
>
> +   /* BCM5464 quad PHY */
> +   rgmii_phy3: ethernet-phy@3 {
> +   reg = <0x3>;
> +   };
> +
> +   rgmii_phy4: ethernet-phy@4 {
> +   reg = <0x4>;
> +   };
> +
> +   rgmii_phy5: ethernet-phy@5 {
> +   reg = <0x5>;
> +   };
> +
> +   rgmii_phy6: ethernet-phy@6 {
> +   reg = <0x6>;
> +   };
> +
> /* SGMII PCS for enet0 */
> tbi0: tbi-phy@1f {
> reg = <0x1f>;
> --
> 2.25.1
>
Reviewed-by: Ramon Fried 

Re: [PATCH 9/9] configs: ls1021a-tsn: enable the generation of random Ethernet MAC addresses

[Ramon Fried]

On Tue, Sep 28, 2021 at 2:48 AM Vladimir Oltean  wrote:
>
> Don't fail when booting a board with an empty EEPROM for MAC addresses.
>
> Signed-off-by: Vladimir Oltean 
> ---
>  configs/ls1021atsn_qspi_defconfig   | 1 +
>  configs/ls1021atsn_sdcard_defconfig | 1 +
>  2 files changed, 2 insertions(+)
>
> diff --git a/configs/ls1021atsn_qspi_defconfig 
> b/configs/ls1021atsn_qspi_defconfig
> index cb89f73583d9..f8854a4976c0 100644
> --- a/configs/ls1021atsn_qspi_defconfig
> +++ b/configs/ls1021atsn_qspi_defconfig
> @@ -42,6 +42,7 @@ CONFIG_SPI_FLASH_DATAFLASH=y
>  CONFIG_PHY_ATHEROS=y
>  CONFIG_PHY_BROADCOM=y
>  CONFIG_PHY_FIXED=y
> +CONFIG_NET_RANDOM_ETHADDR=y
>  CONFIG_DM_ETH=y
>  CONFIG_DM_MDIO=y
>  CONFIG_DM_DSA=y
> diff --git a/configs/ls1021atsn_sdcard_defconfig 
> b/configs/ls1021atsn_sdcard_defconfig
> index 49cd3edcb68c..ba17febc4f40 100644
> --- a/configs/ls1021atsn_sdcard_defconfig
> +++ b/configs/ls1021atsn_sdcard_defconfig
> @@ -53,6 +53,7 @@ CONFIG_SPI_FLASH_DATAFLASH=y
>  CONFIG_PHY_ATHEROS=y
>  CONFIG_PHY_BROADCOM=y
>  CONFIG_PHY_FIXED=y
> +CONFIG_NET_RANDOM_ETHADDR=y
>  CONFIG_DM_ETH=y
>  CONFIG_DM_MDIO=y
>  CONFIG_DM_DSA=y
> --
> 2.25.1
>
Reviewed-by: Ramon Fried 

Re: [PATCH 8/9] configs: ls1021a-tsn: enable sja1105 switch driver

[Ramon Fried]

On Tue, Sep 28, 2021 at 2:48 AM Vladimir Oltean  wrote:
>
> The sja1105 is a 5-port switch that uses a DM_DSA driver. Its 5th (CPU)
> port is connected internally to the eth2 port of the LS1021A SoC.
>
> Signed-off-by: Vladimir Oltean 
> ---
>  configs/ls1021atsn_qspi_defconfig   | 2 ++
>  configs/ls1021atsn_sdcard_defconfig | 2 ++
>  2 files changed, 4 insertions(+)
>
> diff --git a/configs/ls1021atsn_qspi_defconfig 
> b/configs/ls1021atsn_qspi_defconfig
> index 6103ab32a49e..cb89f73583d9 100644
> --- a/configs/ls1021atsn_qspi_defconfig
> +++ b/configs/ls1021atsn_qspi_defconfig
> @@ -44,6 +44,8 @@ CONFIG_PHY_BROADCOM=y
>  CONFIG_PHY_FIXED=y
>  CONFIG_DM_ETH=y
>  CONFIG_DM_MDIO=y
> +CONFIG_DM_DSA=y
> +CONFIG_SJA1105=y
>  CONFIG_PHY_GIGE=y
>  CONFIG_MII=y
>  CONFIG_TSEC_ENET=y
> diff --git a/configs/ls1021atsn_sdcard_defconfig 
> b/configs/ls1021atsn_sdcard_defconfig
> index 8cc0360ae7c5..49cd3edcb68c 100644
> --- a/configs/ls1021atsn_sdcard_defconfig
> +++ b/configs/ls1021atsn_sdcard_defconfig
> @@ -55,6 +55,8 @@ CONFIG_PHY_BROADCOM=y
>  CONFIG_PHY_FIXED=y
>  CONFIG_DM_ETH=y
>  CONFIG_DM_MDIO=y
> +CONFIG_DM_DSA=y
> +CONFIG_SJA1105=y
>  CONFIG_PHY_GIGE=y
>  CONFIG_MII=y
>  CONFIG_TSEC_ENET=y
> --
> 2.25.1
>
Reviewed-by: Ramon Fried 

Re: [PATCH 24/25] arch: powerpc: mpc85xx: free MDIO bus if mdio_register fails

[Ramon Fried]

On Mon, Sep 27, 2021 at 2:22 PM Vladimir Oltean  wrote:
>
> If mdio_register fails, it is nice to not leave behind dangling
> allocated memory.
>
> Signed-off-by: Vladimir Oltean 
> ---
>  arch/powerpc/cpu/mpc85xx/ether_fcc.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/cpu/mpc85xx/ether_fcc.c 
> b/arch/powerpc/cpu/mpc85xx/ether_fcc.c
> index 1f6f55707321..5cf0a3fb227a 100644
> --- a/arch/powerpc/cpu/mpc85xx/ether_fcc.c
> +++ b/arch/powerpc/cpu/mpc85xx/ether_fcc.c
> @@ -449,8 +449,10 @@ int fec_initialize(struct bd_info *bis)
> mdiodev->write = bb_miiphy_write;
>
> retval = mdio_register(mdiodev);
> -   if (retval < 0)
> +   if (retval < 0) {
> +   mdio_free(mdiodev);
> return retval;
> +   }
>  #endif
> }
>
> --
> 2.25.1
>
Reviewed-by: Ramon Fried 

Re: [PATCH 1/2] net: dsa: pass CPU port fixed PHY to .port_disable

[Ramon Fried]

On Sat, Sep 18, 2021 at 2:50 PM Vladimir Oltean  wrote:
>
> While adding the logic for DSA to register a fixed-link PHY for the CPU
> port, I forgot to pass it to the .port_disable method too, just
> .port_enable.
>
> Bug had no impact for felix_switch.c, due to the phy argument not being
> used, but ksz9477.c does use it => NULL pointer dereference.
>
> Fixes: fc054d563bfb ("net: Introduce DSA class for Ethernet switches")
> Signed-off-by: Vladimir Oltean 
> ---
>  net/dsa-uclass.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/dsa-uclass.c b/net/dsa-uclass.c
> index 9b8ae1e82b92..d1c6c78acd6c 100644
> --- a/net/dsa-uclass.c
> +++ b/net/dsa-uclass.c
> @@ -100,7 +100,7 @@ static void dsa_port_stop(struct udevice *pdev)
>
> port_pdata = dev_get_parent_plat(pdev);
> ops->port_disable(dev, port_pdata->index, port_pdata->phy);
> -   ops->port_disable(dev, priv->cpu_port, NULL);
> +   ops->port_disable(dev, priv->cpu_port, 
> priv->cpu_port_fixed_phy);
> }
>
> eth_get_ops(master)->stop(master);
> --
> 2.25.1
>
Reviewed-by: Ramon Fried 

Re: [PATCH 2/2] net: dsa: remove unused variables

[Ramon Fried]

On Sat, Sep 18, 2021 at 2:50 PM Vladimir Oltean  wrote:
>
> "dev" and "dsa_pdata" are unused inside dsa_port_of_to_pdata.
>
> "dsa_priv" is unused inside dsa_port_probe.
>
> Signed-off-by: Vladimir Oltean 
> ---
>  net/dsa-uclass.c | 14 +-
>  1 file changed, 1 insertion(+), 13 deletions(-)
>
> diff --git a/net/dsa-uclass.c b/net/dsa-uclass.c
> index d1c6c78acd6c..8a2918816e30 100644
> --- a/net/dsa-uclass.c
> +++ b/net/dsa-uclass.c
> @@ -199,9 +199,7 @@ static int dsa_port_free_pkt(struct udevice *pdev, uchar 
> *packet, int length)
>  static int dsa_port_of_to_pdata(struct udevice *pdev)
>  {
> struct dsa_port_pdata *port_pdata;
> -   struct dsa_pdata *dsa_pdata;
> struct eth_pdata *eth_pdata;
> -   struct udevice *dev;
> const char *label;
> u32 index;
> int err;
> @@ -213,9 +211,6 @@ static int dsa_port_of_to_pdata(struct udevice *pdev)
> if (err)
> return err;
>
> -   dev = dev_get_parent(pdev);
> -   dsa_pdata = dev_get_uclass_plat(dev);
> -
> port_pdata = dev_get_parent_plat(pdev);
> port_pdata->index = index;
>
> @@ -272,12 +267,10 @@ static int dsa_port_probe(struct udevice *pdev)
> struct udevice *dev = dev_get_parent(pdev);
> struct dsa_ops *ops = dsa_get_ops(dev);
> struct dsa_port_pdata *port_pdata;
> -   struct dsa_priv *dsa_priv;
> struct udevice *master;
> int err;
>
> port_pdata = dev_get_parent_plat(pdev);
> -   dsa_priv = dev_get_uclass_priv(dev);
>
> port_pdata->phy = dm_eth_phy_connect(pdev);
> if (!port_pdata->phy)
> @@ -312,12 +305,7 @@ static int dsa_port_probe(struct udevice *pdev)
>
>  static int dsa_port_remove(struct udevice *pdev)
>  {
> -   struct udevice *dev = dev_get_parent(pdev);
> -   struct dsa_port_pdata *port_pdata;
> -   struct dsa_priv *dsa_priv;
> -
> -   port_pdata = dev_get_parent_plat(pdev);
> -   dsa_priv = dev_get_uclass_priv(dev);
> +   struct dsa_port_pdata *port_pdata = dev_get_parent_plat(pdev);
>
> port_pdata->phy = NULL;
>
> --
> 2.25.1
>
Reviewed-by: Ramon Fried 

Re: [PATCH] net: phy: genphy_init can be static

[Ramon Fried]

On Sat, Sep 18, 2021 at 3:09 PM Bin Meng  wrote:
>
> On Sat, Sep 18, 2021 at 7:55 PM Vladimir Oltean  
> wrote:
> >
> > To avoid a warning with W=1 about this function not having a previous
> > prototype, declare it as static, because it is not used outside of this
> > translation module.
> >
> > Signed-off-by: Vladimir Oltean 
> > ---
> >  drivers/net/phy/phy.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
>
> Reviewed-by: Bin Meng 
Reviewed-by: Ramon Fried 

Re: [PATCH 1/4] net: replace the "xfi" phy-mode with "10gbase-r"

[Ramon Fried]

On Sat, Sep 18, 2021 at 3:34 PM Vladimir Oltean  wrote:
>
> As part of the effort of making U-Boot work with the same device tree as
> Linux, there is an issue with the "xfi" phy-mode. To be precise, in
> Linux there was a discussion (for those who have time to read:
> https://lore.kernel.org/netdev/1576768881-24971-2-git-send-email-madalin.bu...@oss.nxp.com/)
>
> which led to a patch:
> https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=c114574ebfdf42f826776f717c8056a00fa94881
>
> TL;DR: "xfi" was standardized in Linux as "10gbase-r".
>
> This patch changes the relevant occurrences in U-Boot to use "10gbase-r"
> instead of "xfi" wherever applicable.
>
> Signed-off-by: Vladimir Oltean 
> ---
>  arch/arm/cpu/armv8/fsl-layerscape/cpu.c   |  2 +-
>  .../cpu/armv8/fsl-layerscape/doc/README.soc   |  8 +++
>  .../cpu/armv8/fsl-layerscape/ls1088a_serdes.c |  2 +-
>  arch/arm/dts/fsl-ls1088a-qds-sd1-21.dtsi  |  4 ++--
>  arch/arm/dts/fsl-ls1088a-qds-sd1-29.dtsi  |  4 ++--
>  arch/arm/dts/fsl-ls2080a-qds-sd1-42.dtsi  | 16 +++---
>  arch/arm/dts/fsl-ls2088a-rdb-qspi.dts | 16 +++---
>  arch/arm/dts/fsl-sch-30841.dtsi   |  2 +-
>  arch/arm/dts/fsl-sch-30842.dtsi   |  2 +-
>  board/Marvell/octeon_ebb7304/board.c  |  6 ++---
>  board/freescale/ls1043aqds/README |  2 +-
>  board/freescale/ls1043aqds/eth.c  |  4 ++--
>  board/freescale/ls1043ardb/README |  2 +-
>  board/freescale/ls1043ardb/eth.c  |  2 +-
>  board/freescale/ls1046aqds/README |  2 +-
>  board/freescale/ls1046aqds/eth.c  |  4 ++--
>  board/freescale/ls1046ardb/README |  4 ++--
>  board/freescale/ls1046ardb/eth.c  |  2 +-
>  board/freescale/ls1088a/README|  4 ++--
>  board/freescale/ls1088a/eth_ls1088ardb.c  |  6 ++---
>  board/freescale/ls2080aqds/README |  2 +-
>  board/freescale/ls2080aqds/eth.c  | 13 +--
>  board/freescale/ls2080ardb/README |  2 +-
>  board/freescale/t102xrdb/README   |  2 +-
>  board/freescale/t102xrdb/eth_t102xrdb.c   |  2 +-
>  board/freescale/t208xqds/README   | 18 +++
>  board/freescale/t208xqds/eth_t208xqds.c   | 22 +--
>  board/freescale/t208xqds/t208xqds.c   |  8 +++
>  board/freescale/t208xrdb/README   |  4 ++--
>  board/freescale/t4rdb/eth.c   |  2 +-
>  doc/device-tree-bindings/net/ethernet.txt | 12 +-
>  drivers/net/fm/b4860.c|  2 +-
>  drivers/net/fm/memac.c|  4 ++--
>  drivers/net/fsl_enetc.c   |  4 ++--
>  drivers/net/mscc_eswitch/felix_switch.c   |  2 +-
>  drivers/net/phy/aquantia.c| 14 ++--
>  include/phy.h |  2 +-
>  include/phy_interface.h   |  4 ++--
>  38 files changed, 111 insertions(+), 102 deletions(-)
>
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c 
> b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
> index d0103fc8811e..1a359d060e82 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
> @@ -1147,7 +1147,7 @@ int arch_early_init_r(void)
>  #endif
>  #ifdef CONFIG_SYS_FSL_HAS_RGMII
> /* some dpmacs in armv8a based freescale layerscape SOCs can be
> -* configured via both serdes(sgmii, xfi, xlaui etc) bits and via
> +* configured via both serdes(sgmii, 10gbase-r, xlaui etc) bits and 
> via
>  * EC*_PMUX(rgmii) bits in RCW.
>  * e.g. dpmac 17 and 18 in LX2160A can be configured as SGMII from
>  * serdes bits and as RGMII via EC1_PMUX/EC2_PMUX bits
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/doc/README.soc 
> b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.soc
> index f33d05d0539f..f2efd4cc1d70 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/doc/README.soc
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.soc
> @@ -31,7 +31,7 @@ The LS1043A SoC includes the following function and 
> features:
> - Hardware buffer management for buffer allocation and de-allocation 
> (BMan)
> - Cryptography acceleration (SEC)
>   - Ethernet interfaces by FMan
> -   - Up to 1 x XFI supporting 10G interface
> +   - Up to 1 x 10GBase-R supporting 10G interface
> - Up to 1 x QSGMII
> - Up to 4 x SGMII supporting 1000Mbps
> - Up to 2 x SGMII supporting 2500Mbps
> @@ -190,7 +190,7 @@ The LS1046A SoC includes the following function and 
> features:
> - Two PLLs per four-lane SerDes
> - Support for 10G operation
>   - Ethernet interfaces by FMan
> -   - Up to 2 x XFI supporting 10G interface (MAC 9, 10)
> +   - Up to 2 x 10GBase-R supporting 10G interface (MAC 9, 10)
> - Up to 1 x QSGMII (MAC 5, 6, 10, 1)
> - Up to 4 x SGMII supporting 1000Mbps (MAC 5, 6, 9, 10)
> - Up to 3 x SGM

Re: [PATCH 2/4] net: freescale: replace usage of phy-mode = "sgmii-2500" with "2500base-x"

[Ramon Fried]

On Sat, Sep 18, 2021 at 3:34 PM Vladimir Oltean  wrote:
>
> After the discussion here:
> https://lore.kernel.org/netdev/20210603143453.if7hgifupx5k433b@pali/
>
> which resulted in this patch:
> https://patchwork.kernel.org/project/netdevbpf/patch/20210704134325.24842-1-p...@kernel.org/
>
> and many other discussions before it, notably:
> https://patchwork.kernel.org/project/linux-arm-kernel/patch/1512016235-15909-1-git-send-email-bhaskar.upadh...@nxp.com/
>
> it became apparent that nobody really knows what "SGMII 2500" is.
> Certainly, Freescale/NXP hardware engineers name this protocol
> "SGMII 2500" in the reference manuals, but the PCS devices do not
> support any "SGMII" specific features when operating at the speed of
> 2500 Mbps, no in-band autoneg and no speed change via symbol replication
> . So that leaves a fixed speed of 2500 Mbps using a coding of 8b/10b
> with a SERDES lane frequency of 3.125 GHz. In fact, "SGMII 2500 without
> in-band autoneg and at a fixed speed" is indistinguishable from
> "2500base-x without in-band autoneg", which is precisely what these NXP
> devices support.
>
> So it just appears that "SGMII 2500" is an unclear name with no clear
> definition that stuck.
>
> As such, in the Linux kernel, the drivers which use this SERDES protocol
> use the 2500base-x phy-mode.
>
> This patch converts U-Boot to use 2500base-x too, or at least, as much
> as it can.
>
> Note that I would have really liked to delete PHY_INTERFACE_MODE_SGMII_2500
> completely, but the mvpp2 driver seems to even distinguish between SGMII
> 2500 and 2500base-X. Namely, it enables in-band autoneg for one but not
> the other, and forces flow control for one but not the other. This goes
> back to the idea that maybe 2500base-X is a fiber protocol and SGMII-2500
> is an MII protocol (connects a MAC to a PHY such as Aquantia), but the
> two are practically indistinguishable through everything except use case.
>
> NXP devices can support both use cases through an identical configuration,
> for example RX flow control can be unconditionally enabled in order to
> support rate adaptation performed by an Aquantia PHY. At least I can
> find no indication in online documents published by Cisco which would
> point towards "SGMII-2500" being an actual standard with an actual
> definition, so I cannot say "yes, NXP devices support it".
>
> Signed-off-by: Vladimir Oltean 
> ---
>  arch/arm/dts/fsl-ls1028a-qds-6xxx-sch-30842.dtsi  |  2 +-
>  arch/arm/dts/fsl-ls1028a-qds--sch-30841.dtsi  |  8 
>  arch/arm/dts/fsl-ls1028a-qds-7xx7-sch-30841R.dtsi |  4 ++--
>  arch/arm/dts/fsl-ls1028a-qds-x7xx-sch-30842.dtsi  |  2 +-
>  arch/arm/dts/fsl-ls1028a-qds-xx7x-sch-30842.dtsi  |  2 +-
>  arch/arm/dts/fsl-sch-30841.dtsi   |  2 +-
>  arch/arm/dts/fsl-sch-30842.dtsi   |  2 +-
>  board/freescale/ls1012aqds/eth.c  |  4 ++--
>  board/freescale/ls1012aqds/ls1012aqds.c   |  4 ++--
>  board/freescale/ls1012aqds/ls1012aqds_pfe.h   |  2 +-
>  board/freescale/ls1012ardb/eth.c  |  4 ++--
>  board/freescale/ls1043aqds/eth.c  |  8 
>  board/freescale/ls1046aqds/eth.c  |  4 ++--
>  board/freescale/t102xrdb/eth_t102xrdb.c   |  6 +++---
>  drivers/net/fm/eth.c  | 10 +-
>  drivers/net/fm/ls1043.c   |  4 ++--
>  drivers/net/fm/ls1046.c   |  2 +-
>  drivers/net/fm/memac.c|  2 +-
>  drivers/net/fm/t1024.c|  2 +-
>  drivers/net/fsl_enetc.c   |  4 ++--
>  drivers/net/mscc_eswitch/felix_switch.c   |  4 ++--
>  drivers/net/pfe_eth/pfe_mdio.c|  4 ++--
>  drivers/net/phy/aquantia.c|  4 ++--
>  23 files changed, 45 insertions(+), 45 deletions(-)
>
> diff --git a/arch/arm/dts/fsl-ls1028a-qds-6xxx-sch-30842.dtsi 
> b/arch/arm/dts/fsl-ls1028a-qds-6xxx-sch-30842.dtsi
> index c6558ae2e07b..96c9455e6d39 100644
> --- a/arch/arm/dts/fsl-ls1028a-qds-6xxx-sch-30842.dtsi
> +++ b/arch/arm/dts/fsl-ls1028a-qds-6xxx-sch-30842.dtsi
> @@ -14,6 +14,6 @@
>
>  &enetc0 {
> status = "okay";
> -   phy-mode = "sgmii-2500";
> +   phy-mode = "2500base-x";
> phy-handle = <&{/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@02}>;
>  };
> diff --git a/arch/arm/dts/fsl-ls1028a-qds--sch-30841.dtsi 
> b/arch/arm/dts/fsl-ls1028a-qds--sch-30841.dtsi
> index 5a0f060c16e5..006e382991f2 100644
> --- a/arch/arm/dts/fsl-ls1028a-qds--sch-30841.dtsi
> +++ b/arch/arm/dts/fsl-ls1028a-qds--sch-30841.dtsi
> @@ -30,25 +30,25 @@
>
>  &mscc_felix_port0 {
> status = "okay";
> -   phy-mode = "sgmii-2500";
> +   phy-mode = "2500base-x";
> phy-handle = <&{/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@00}>;
>  };
>
>  &mscc_felix_port1 {
> status = "okay";
> -   phy-mode = "sgmii-2500";
> +   phy-m

Re: [PATCH 3/4] net: enetc: remove support for "xgmii" phy-mode

[Ramon Fried]

On Sat, Sep 18, 2021 at 3:34 PM Vladimir Oltean  wrote:
>
> The enetc driver runs only on NXP LS1028A, which most definitely does
> not support the parallel 10G interface, just USXGMII, and that only up
> to 2.5Gbps (toned down from 10 Gbps via symbol replication).
>
> Signed-off-by: Vladimir Oltean 
> ---
>  drivers/net/fsl_enetc.c | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/drivers/net/fsl_enetc.c b/drivers/net/fsl_enetc.c
> index 045527dcf7d9..f56f9e7a129b 100644
> --- a/drivers/net/fsl_enetc.c
> +++ b/drivers/net/fsl_enetc.c
> @@ -226,7 +226,6 @@ static void enetc_setup_mac_iface(struct udevice *dev,
> case PHY_INTERFACE_MODE_RGMII_TXID:
> enetc_init_rgmii(dev, phydev);
> break;
> -   case PHY_INTERFACE_MODE_XGMII:
> case PHY_INTERFACE_MODE_USXGMII:
> case PHY_INTERFACE_MODE_10GBASER:
> /* set ifmode to (US)XGMII */
> @@ -294,7 +293,6 @@ static void enetc_start_pcs(struct udevice *dev)
> case PHY_INTERFACE_MODE_2500BASEX:
> enetc_init_sgmii(dev);
> break;
> -   case PHY_INTERFACE_MODE_XGMII:
> case PHY_INTERFACE_MODE_USXGMII:
> case PHY_INTERFACE_MODE_10GBASER:
> enetc_init_sxgmii(dev);
> --
> 2.25.1
>
Reviewed-by: Ramon Fried 

Re: [PATCH 4/4] net: dsa: felix: remove "xgmii" phy-mode

[Ramon Fried]

On Sat, Sep 18, 2021 at 3:34 PM Vladimir Oltean  wrote:
>
> The felix driver runs only on NXP LS1028A, which most definitely does
> not support the parallel 10G interface, just USXGMII, and that only up
> to 2.5Gbps (toned down from 10 Gbps via symbol replication).
>
> Signed-off-by: Vladimir Oltean 
> ---
>  drivers/net/mscc_eswitch/felix_switch.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/drivers/net/mscc_eswitch/felix_switch.c 
> b/drivers/net/mscc_eswitch/felix_switch.c
> index bd40c3b8b1bb..47ac45b354da 100644
> --- a/drivers/net/mscc_eswitch/felix_switch.c
> +++ b/drivers/net/mscc_eswitch/felix_switch.c
> @@ -222,7 +222,6 @@ static void felix_start_pcs(struct udevice *dev, int port,
> case PHY_INTERFACE_MODE_QSGMII:
> felix_init_sgmii(imdio, port, autoneg);
> break;
> -   case PHY_INTERFACE_MODE_XGMII:
> case PHY_INTERFACE_MODE_10GBASER:
> case PHY_INTERFACE_MODE_USXGMII:
> if (felix_init_sxgmii(imdio, port))
> --
> 2.25.1
>
Reviewed-by: Ramon Fried 

Re: [PATCH 1/2] net: tsec: only call tsec_get_interface as fallback to DT-specified PHY mode

[Ramon Fried]

On Sun, Sep 19, 2021 at 10:32 AM Bin Meng  wrote:
>
> On Sat, Sep 18, 2021 at 8:47 PM Vladimir Oltean  
> wrote:
> >
> > Currently the init_phy function may overwrite the priv->interface
> > property, since it calls tsec_get_interface which tries to determine it
> > dynamically based on default register values in ECNTRL.
> >
> > Let's do that only if phy-connection-type happens to not be defined in
> > the device tree.
> >
> > Signed-off-by: Vladimir Oltean 
> > ---
> >  drivers/net/tsec.c | 9 +++--
> >  1 file changed, 3 insertions(+), 6 deletions(-)
> >
>
> Reviewed-by: Bin Meng 
> Tested-by: Bin Meng 
Reviewed-by: Ramon Fried 

Re: [PATCH 2/2] net: tsec: read the phy-mode property as fallback to phy-connection-type

[Ramon Fried]

On Sun, Sep 19, 2021 at 10:32 AM Bin Meng  wrote:
>
> On Sat, Sep 18, 2021 at 8:47 PM Vladimir Oltean  
> wrote:
> >
> > The two should be equivalent, but at the moment some platforms
> > (ls1021a-tsn.dts) use phy-mode only, which is not parsed.
> >
> > Signed-off-by: Vladimir Oltean 
> > ---
> >  drivers/net/tsec.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
>
> Reviewed-by: Bin Meng 
> Tested-by: Bin Meng 
Reviewed-by: Ramon Fried 

Re: Please pull u-boot-i2c/next

[Patrice CHOTARD]

Hi Tom

On 9/28/21 2:20 PM, Tom Rini wrote:
> On Tue, Sep 28, 2021 at 09:26:43AM +0200, Heiko Schocher wrote:
>> Hello Patrice,
>>
>> On 28.09.21 09:05, Patrice CHOTARD wrote:
>>> Hi Heiko, Tom
>>>
>>> Is this PR can be merged into v2021.10 ?
>>> The patch "mtd: nand: raw: convert nand_dt_init() to ofnode_xx() interface" 
>>> is fixing 
>>> an issue for all platforms for which OF_LIVE flag is enabled.
>>>
>>> For all these platforms, all nand DT property can't be read 
>>> (nand-bus-width, nand-on-flash-bbt, 
>>> nand-ecc-mode.nand-ecc-strength andnand-ecc-step-size properties are 
>>> concerned)
>>>
>>> It has been detected on STM32MP1 platforms.
>>
>> From my side yes, but as it is in next I think it cannot go directly
>> into master ...  may tom pickup this patch directly?
> 
> I can put:
> https://patchwork.ozlabs.org/project/uboot/patch/20210913142553.24333-1-patrice.chot...@foss.st.com/
> in to my regression fixes bundle, which I'll apply shortly.
> 

Perfect ;-)

Thanks, Patrice

Re: [PATCH 03/25] net: armada100_fec: ensure mdiodev->name is NULL terminated after MDIO_NAME_LEN truncation

[Ramon Fried]

On Mon, Sep 27, 2021 at 2:22 PM Vladimir Oltean  wrote:
>
> strncpy() simply bails out when copying a source string whose size
> exceeds the destination string size, potentially leaving the destination
> string unterminated.
>
> One possible way to address is to pass MDIO_NAME_LEN - 1 and a
> previously zero-initialized destination string, but this is more
> difficult to maintain.
>
> The chosen alternative is to use strlcpy(), which properly limits the
> copy len in the (srclen >= size) case to "size - 1", and which is also
> more efficient than the strncpy() byte-by-byte implementation by using
> memcpy. The destination string returned by strlcpy() is always NULL
> terminated.
>
> Signed-off-by: Vladimir Oltean 
> ---
>  drivers/net/armada100_fec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/armada100_fec.c b/drivers/net/armada100_fec.c
> index 018891e173c3..5d4b90c6ba72 100644
> --- a/drivers/net/armada100_fec.c
> +++ b/drivers/net/armada100_fec.c
> @@ -717,7 +717,7 @@ int armada100_fec_register(unsigned long base_addr)
> struct mii_dev *mdiodev = mdio_alloc();
> if (!mdiodev)
> return -ENOMEM;
> -   strncpy(mdiodev->name, dev->name, MDIO_NAME_LEN);
> +   strlcpy(mdiodev->name, dev->name, MDIO_NAME_LEN);
> mdiodev->read = smi_reg_read;
> mdiodev->write = smi_reg_write;
>
> --
> 2.25.1
>
Reviewed-by: Ramon Fried 

Re: [PATCH 04/25] net: at91_emac: ensure mdiodev->name is NULL terminated after MDIO_NAME_LEN truncation

[Ramon Fried]

On Mon, Sep 27, 2021 at 2:22 PM Vladimir Oltean  wrote:
>
> strncpy() simply bails out when copying a source string whose size
> exceeds the destination string size, potentially leaving the destination
> string unterminated.
>
> One possible way to address is to pass MDIO_NAME_LEN - 1 and a
> previously zero-initialized destination string, but this is more
> difficult to maintain.
>
> The chosen alternative is to use strlcpy(), which properly limits the
> copy len in the (srclen >= size) case to "size - 1", and which is also
> more efficient than the strncpy() byte-by-byte implementation by using
> memcpy. The destination string returned by strlcpy() is always NULL
> terminated.
>
> Signed-off-by: Vladimir Oltean 
> ---
>  drivers/net/at91_emac.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/at91_emac.c b/drivers/net/at91_emac.c
> index e40b94ad892d..b4581d8c9320 100644
> --- a/drivers/net/at91_emac.c
> +++ b/drivers/net/at91_emac.c
> @@ -507,7 +507,7 @@ int at91emac_register(struct bd_info *bis, unsigned long 
> iobase)
> struct mii_dev *mdiodev = mdio_alloc();
> if (!mdiodev)
> return -ENOMEM;
> -   strncpy(mdiodev->name, dev->name, MDIO_NAME_LEN);
> +   strlcpy(mdiodev->name, dev->name, MDIO_NAME_LEN);
> mdiodev->read = at91emac_mii_read;
> mdiodev->write = at91emac_mii_write;
>
> --
> 2.25.1
>
Reviewed-by: Ramon Fried 

Re: [PATCH 05/25] net: bcm-sf2: ensure mdiodev->name is NULL terminated after MDIO_NAME_LEN truncation

[Ramon Fried]

On Mon, Sep 27, 2021 at 2:22 PM Vladimir Oltean  wrote:
>
> strncpy() simply bails out when copying a source string whose size
> exceeds the destination string size, potentially leaving the destination
> string unterminated.
>
> One possible way to address is to pass MDIO_NAME_LEN - 1 and a
> previously zero-initialized destination string, but this is more
> difficult to maintain.
>
> The chosen alternative is to use strlcpy(), which properly limits the
> copy len in the (srclen >= size) case to "size - 1", and which is also
> more efficient than the strncpy() byte-by-byte implementation by using
> memcpy. The destination string returned by strlcpy() is always NULL
> terminated.
>
> Signed-off-by: Vladimir Oltean 
> ---
>  drivers/net/bcm-sf2-eth.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/bcm-sf2-eth.c b/drivers/net/bcm-sf2-eth.c
> index c862c141461c..88dc3ab38466 100644
> --- a/drivers/net/bcm-sf2-eth.c
> +++ b/drivers/net/bcm-sf2-eth.c
> @@ -250,7 +250,7 @@ int bcm_sf2_eth_register(struct bd_info *bis, u8 dev_num)
>
> if (!mdiodev)
> return -ENOMEM;
> -   strncpy(mdiodev->name, dev->name, MDIO_NAME_LEN);
> +   strlcpy(mdiodev->name, dev->name, MDIO_NAME_LEN);
> mdiodev->read = eth->miiphy_read;
> mdiodev->write = eth->miiphy_write;
>
> --
> 2.25.1
>
Reviewed-by: Ramon Fried 

Re: [PATCH 06/25] net: eepro100: ensure mdiodev->name is NULL terminated after MDIO_NAME_LEN truncation

[Ramon Fried]

On Mon, Sep 27, 2021 at 2:22 PM Vladimir Oltean  wrote:
>
> strncpy() simply bails out when copying a source string whose size
> exceeds the destination string size, potentially leaving the destination
> string unterminated.
>
> One possible way to address is to pass MDIO_NAME_LEN - 1 and a
> previously zero-initialized destination string, but this is more
> difficult to maintain.
>
> The chosen alternative is to use strlcpy(), which properly limits the
> copy len in the (srclen >= size) case to "size - 1", and which is also
> more efficient than the strncpy() byte-by-byte implementation by using
> memcpy. The destination string returned by strlcpy() is always NULL
> terminated.
>
> Signed-off-by: Vladimir Oltean 
> ---
>  drivers/net/eepro100.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/eepro100.c b/drivers/net/eepro100.c
> index 934b881219e9..935cd9c99cef 100644
> --- a/drivers/net/eepro100.c
> +++ b/drivers/net/eepro100.c
> @@ -493,7 +493,7 @@ static int eepro100_initialize_mii(struct eepro100_priv 
> *priv)
> if (!mdiodev)
> return -ENOMEM;
>
> -   strncpy(mdiodev->name, priv->name, MDIO_NAME_LEN);
> +   strlcpy(mdiodev->name, priv->name, MDIO_NAME_LEN);
> mdiodev->read = eepro100_miiphy_read;
> mdiodev->write = eepro100_miiphy_write;
> mdiodev->priv = priv;
> --
> 2.25.1
>
Reviewed-by: Ramon Fried 

Re: [PATCH 07/25] net: ep93xx: ensure mdiodev->name is NULL terminated after MDIO_NAME_LEN truncation

[Ramon Fried]

On Mon, Sep 27, 2021 at 2:22 PM Vladimir Oltean  wrote:
>
> strncpy() simply bails out when copying a source string whose size
> exceeds the destination string size, potentially leaving the destination
> string unterminated.
>
> One possible way to address is to pass MDIO_NAME_LEN - 1 and a
> previously zero-initialized destination string, but this is more
> difficult to maintain.
>
> The chosen alternative is to use strlcpy(), which properly limits the
> copy len in the (srclen >= size) case to "size - 1", and which is also
> more efficient than the strncpy() byte-by-byte implementation by using
> memcpy. The destination string returned by strlcpy() is always NULL
> terminated.
>
> Signed-off-by: Vladimir Oltean 
> ---
>  drivers/net/ep93xx_eth.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ep93xx_eth.c b/drivers/net/ep93xx_eth.c
> index 0218349b0450..9f8df7de0609 100644
> --- a/drivers/net/ep93xx_eth.c
> +++ b/drivers/net/ep93xx_eth.c
> @@ -427,7 +427,7 @@ int ep93xx_miiphy_initialize(struct bd_info * const bd)
> struct mii_dev *mdiodev = mdio_alloc();
> if (!mdiodev)
> return -ENOMEM;
> -   strncpy(mdiodev->name, "ep93xx_eth0", MDIO_NAME_LEN);
> +   strlcpy(mdiodev->name, "ep93xx_eth0", MDIO_NAME_LEN);
> mdiodev->read = ep93xx_miiphy_read;
> mdiodev->write = ep93xx_miiphy_write;
>
> --
> 2.25.1
>
Reviewed-by: Ramon Fried 

Re: [PATCH 08/25] net: enetc: ensure imdio.name is NULL terminated after MDIO_NAME_LEN truncation

[Ramon Fried]

On Mon, Sep 27, 2021 at 2:22 PM Vladimir Oltean  wrote:
>
> strncpy() simply bails out when copying a source string whose size
> exceeds the destination string size, potentially leaving the destination
> string unterminated.
>
> One possible way to address is to pass MDIO_NAME_LEN - 1 and a
> previously zero-initialized destination string, but this is more
> difficult to maintain.
>
> The chosen alternative is to use strlcpy(), which properly limits the
> copy len in the (srclen >= size) case to "size - 1", and which is also
> more efficient than the strncpy() byte-by-byte implementation by using
> memcpy. The destination string returned by strlcpy() is always NULL
> terminated.
>
> Signed-off-by: Vladimir Oltean 
> ---
>  drivers/net/fsl_enetc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/fsl_enetc.c b/drivers/net/fsl_enetc.c
> index 566cdc7e546a..b7e2c1f0880c 100644
> --- a/drivers/net/fsl_enetc.c
> +++ b/drivers/net/fsl_enetc.c
> @@ -270,7 +270,7 @@ static void enetc_start_pcs(struct udevice *dev)
> priv->imdio.read = enetc_mdio_read;
> priv->imdio.write = enetc_mdio_write;
> priv->imdio.priv = priv->port_regs + ENETC_PM_IMDIO_BASE;
> -   strncpy(priv->imdio.name, dev->name, MDIO_NAME_LEN);
> +   strlcpy(priv->imdio.name, dev->name, MDIO_NAME_LEN);
> if (!miiphy_get_dev_by_name(priv->imdio.name))
> mdio_register(&priv->imdio);
> }
> --
> 2.25.1
>
Reviewed-by: Ramon Fried 

Re: [PATCH 09/25] net: mcdmafec: ensure bus->name is NULL terminated after MDIO_NAME_LEN truncation

[Ramon Fried]

On Mon, Sep 27, 2021 at 2:22 PM Vladimir Oltean  wrote:
>
> strncpy() simply bails out when copying a source string whose size
> exceeds the destination string size, potentially leaving the destination
> string unterminated.
>
> One possible way to address is to pass MDIO_NAME_LEN - 1 and a
> previously zero-initialized destination string, but this is more
> difficult to maintain.
>
> The chosen alternative is to use strlcpy(), which properly limits the
> copy len in the (srclen >= size) case to "size - 1", and which is also
> more efficient than the strncpy() byte-by-byte implementation by using
> memcpy. The destination string returned by strlcpy() is always NULL
> terminated.
>
> Signed-off-by: Vladimir Oltean 
> ---
>  drivers/net/fsl_mcdmafec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/fsl_mcdmafec.c b/drivers/net/fsl_mcdmafec.c
> index c20aef4ab28d..e103f79305e7 100644
> --- a/drivers/net/fsl_mcdmafec.c
> +++ b/drivers/net/fsl_mcdmafec.c
> @@ -541,7 +541,7 @@ static int mcdmafec_probe(struct udevice *dev)
> info->bus = mdio_alloc();
> if (!info->bus)
> return -ENOMEM;
> -   strncpy(info->bus->name, dev->name, MDIO_NAME_LEN);
> +   strlcpy(info->bus->name, dev->name, MDIO_NAME_LEN);
> info->bus->read = mcffec_miiphy_read;
> info->bus->write = mcffec_miiphy_write;
>
> --
> 2.25.1
>
Reviewed-by: Ramon Fried 

Re: [PATCH 11/25] net: lpc32xx: ensure mdiodev->name is NULL terminated after MDIO_NAME_LEN truncation

[Ramon Fried]

On Mon, Sep 27, 2021 at 2:22 PM Vladimir Oltean  wrote:
>
> strncpy() simply bails out when copying a source string whose size
> exceeds the destination string size, potentially leaving the destination
> string unterminated.
>
> One possible way to address is to pass MDIO_NAME_LEN - 1 and a
> previously zero-initialized destination string, but this is more
> difficult to maintain.
>
> The chosen alternative is to use strlcpy(), which properly limits the
> copy len in the (srclen >= size) case to "size - 1", and which is also
> more efficient than the strncpy() byte-by-byte implementation by using
> memcpy. The destination string returned by strlcpy() is always NULL
> terminated.
>
> Signed-off-by: Vladimir Oltean 
> ---
>  drivers/net/lpc32xx_eth.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/lpc32xx_eth.c b/drivers/net/lpc32xx_eth.c
> index 3f281a515c6a..1a5734343935 100644
> --- a/drivers/net/lpc32xx_eth.c
> +++ b/drivers/net/lpc32xx_eth.c
> @@ -638,7 +638,7 @@ int lpc32xx_eth_initialize(struct bd_info *bis)
> struct mii_dev *mdiodev = mdio_alloc();
> if (!mdiodev)
> return -ENOMEM;
> -   strncpy(mdiodev->name, dev->name, MDIO_NAME_LEN);
> +   strlcpy(mdiodev->name, dev->name, MDIO_NAME_LEN);
> mdiodev->read = mii_reg_read;
> mdiodev->write = mii_reg_write;
>
> --
> 2.25.1
>
Reviewed-by: Ramon Fried 

Re: [PATCH 10/25] net: ftmac110: ensure mdiodev->name is NULL terminated after MDIO_NAME_LEN truncation

[Ramon Fried]

On Mon, Sep 27, 2021 at 2:22 PM Vladimir Oltean  wrote:
>
> strncpy() simply bails out when copying a source string whose size
> exceeds the destination string size, potentially leaving the destination
> string unterminated.
>
> One possible way to address is to pass MDIO_NAME_LEN - 1 and a
> previously zero-initialized destination string, but this is more
> difficult to maintain.
>
> The chosen alternative is to use strlcpy(), which properly limits the
> copy len in the (srclen >= size) case to "size - 1", and which is also
> more efficient than the strncpy() byte-by-byte implementation by using
> memcpy. The destination string returned by strlcpy() is always NULL
> terminated.
>
> Signed-off-by: Vladimir Oltean 
> ---
>  drivers/net/ftmac110.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ftmac110.c b/drivers/net/ftmac110.c
> index 265d813c4f89..7e54d4642ddf 100644
> --- a/drivers/net/ftmac110.c
> +++ b/drivers/net/ftmac110.c
> @@ -476,7 +476,7 @@ int ftmac110_initialize(struct bd_info *bis)
> struct mii_dev *mdiodev = mdio_alloc();
> if (!mdiodev)
> return -ENOMEM;
> -   strncpy(mdiodev->name, dev->name, MDIO_NAME_LEN);
> +   strlcpy(mdiodev->name, dev->name, MDIO_NAME_LEN);
> mdiodev->read = ftmac110_mdio_read;
> mdiodev->write = ftmac110_mdio_write;
>
> --
> 2.25.1
>
Reviewed-by: Ramon Fried 

Re: [PATCH 12/25] net: macb: ensure mdiodev->name is NULL terminated after MDIO_NAME_LEN truncation

[Ramon Fried]

On Mon, Sep 27, 2021 at 2:22 PM Vladimir Oltean  wrote:
>
> strncpy() simply bails out when copying a source string whose size
> exceeds the destination string size, potentially leaving the destination
> string unterminated.
>
> One possible way to address is to pass MDIO_NAME_LEN - 1 and a
> previously zero-initialized destination string, but this is more
> difficult to maintain.
>
> The chosen alternative is to use strlcpy(), which properly limits the
> copy len in the (srclen >= size) case to "size - 1", and which is also
> more efficient than the strncpy() byte-by-byte implementation by using
> memcpy. The destination string returned by strlcpy() is always NULL
> terminated.
>
> Signed-off-by: Vladimir Oltean 
> ---
>  drivers/net/macb.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/macb.c b/drivers/net/macb.c
> index 57ea45e2dc7f..8151104acfc0 100644
> --- a/drivers/net/macb.c
> +++ b/drivers/net/macb.c
> @@ -1245,7 +1245,7 @@ int macb_eth_initialize(int id, void *regs, unsigned 
> int phy_addr)
> struct mii_dev *mdiodev = mdio_alloc();
> if (!mdiodev)
> return -ENOMEM;
> -   strncpy(mdiodev->name, netdev->name, MDIO_NAME_LEN);
> +   strlcpy(mdiodev->name, netdev->name, MDIO_NAME_LEN);
> mdiodev->read = macb_miiphy_read;
> mdiodev->write = macb_miiphy_write;
>
> @@ -1403,7 +1403,7 @@ static int macb_eth_probe(struct udevice *dev)
> macb->bus = mdio_alloc();
> if (!macb->bus)
> return -ENOMEM;
> -   strncpy(macb->bus->name, dev->name, MDIO_NAME_LEN);
> +   strlcpy(macb->bus->name, dev->name, MDIO_NAME_LEN);
> macb->bus->read = macb_miiphy_read;
> macb->bus->write = macb_miiphy_write;
>
> --
> 2.25.1
>
Reviewed-by: Ramon Fried 

Re: [PATCH 13/25] net: mpc8xx_fec: ensure mdiodev->name is NULL terminated after MDIO_NAME_LEN truncation

[Ramon Fried]

On Mon, Sep 27, 2021 at 2:22 PM Vladimir Oltean  wrote:
>
> strncpy() simply bails out when copying a source string whose size
> exceeds the destination string size, potentially leaving the destination
> string unterminated.
>
> One possible way to address is to pass MDIO_NAME_LEN - 1 and a
> previously zero-initialized destination string, but this is more
> difficult to maintain.
>
> The chosen alternative is to use strlcpy(), which properly limits the
> copy len in the (srclen >= size) case to "size - 1", and which is also
> more efficient than the strncpy() byte-by-byte implementation by using
> memcpy. The destination string returned by strlcpy() is always NULL
> terminated.
>
> Signed-off-by: Vladimir Oltean 
> ---
>  drivers/net/mpc8xx_fec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/mpc8xx_fec.c b/drivers/net/mpc8xx_fec.c
> index 282c2599d3c4..4eb826028111 100644
> --- a/drivers/net/mpc8xx_fec.c
> +++ b/drivers/net/mpc8xx_fec.c
> @@ -160,7 +160,7 @@ int fec_initialize(struct bd_info *bis)
> struct mii_dev *mdiodev = mdio_alloc();
> if (!mdiodev)
> return -ENOMEM;
> -   strncpy(mdiodev->name, dev->name, MDIO_NAME_LEN);
> +   strlcpy(mdiodev->name, dev->name, MDIO_NAME_LEN);
> mdiodev->read = fec8xx_miiphy_read;
> mdiodev->write = fec8xx_miiphy_write;
>
> --
> 2.25.1
>
Reviewed-by: Ramon Fried 

Re: [PATCH 15/25] net: mvgbe: ensure mdiodev->name is NULL terminated after MDIO_NAME_LEN truncation

[Ramon Fried]

On Mon, Sep 27, 2021 at 2:22 PM Vladimir Oltean  wrote:
>
> strncpy() simply bails out when copying a source string whose size
> exceeds the destination string size, potentially leaving the destination
> string unterminated.
>
> One possible way to address is to pass MDIO_NAME_LEN - 1 and a
> previously zero-initialized destination string, but this is more
> difficult to maintain.
>
> The chosen alternative is to use strlcpy(), which properly limits the
> copy len in the (srclen >= size) case to "size - 1", and which is also
> more efficient than the strncpy() byte-by-byte implementation by using
> memcpy. The destination string returned by strlcpy() is always NULL
> terminated.
>
> Signed-off-by: Vladimir Oltean 
> ---
>  drivers/net/mvgbe.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/mvgbe.c b/drivers/net/mvgbe.c
> index ce5b8eed64b4..954bf86121a4 100644
> --- a/drivers/net/mvgbe.c
> +++ b/drivers/net/mvgbe.c
> @@ -883,7 +883,7 @@ int mvgbe_initialize(struct bd_info *bis)
> struct mii_dev *mdiodev = mdio_alloc();
> if (!mdiodev)
> return -ENOMEM;
> -   strncpy(mdiodev->name, dev->name, MDIO_NAME_LEN);
> +   strlcpy(mdiodev->name, dev->name, MDIO_NAME_LEN);
> mdiodev->read = smi_reg_read;
> mdiodev->write = smi_reg_write;
>
> --
> 2.25.1
>
Reviewed-by: Ramon Fried 

Re: [PATCH 17/25] net: smc911x: ensure mdiodev->name is NULL terminated after MDIO_NAME_LEN truncation

[Ramon Fried]

On Mon, Sep 27, 2021 at 2:22 PM Vladimir Oltean  wrote:
>
> strncpy() simply bails out when copying a source string whose size
> exceeds the destination string size, potentially leaving the destination
> string unterminated.
>
> One possible way to address is to pass MDIO_NAME_LEN - 1 and a
> previously zero-initialized destination string, but this is more
> difficult to maintain.
>
> The chosen alternative is to use strlcpy(), which properly limits the
> copy len in the (srclen >= size) case to "size - 1", and which is also
> more efficient than the strncpy() byte-by-byte implementation by using
> memcpy. The destination string returned by strlcpy() is always NULL
> terminated.
>
> Signed-off-by: Vladimir Oltean 
> ---
>  drivers/net/smc911x.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c
> index 8f420261fa8d..5d9a73f23d75 100644
> --- a/drivers/net/smc911x.c
> +++ b/drivers/net/smc911x.c
> @@ -425,7 +425,7 @@ static int smc911x_initialize_mii(struct smc911x_priv 
> *priv)
> if (!mdiodev)
> return -ENOMEM;
>
> -   strncpy(mdiodev->name, priv->dev.name, MDIO_NAME_LEN);
> +   strlcpy(mdiodev->name, priv->dev.name, MDIO_NAME_LEN);
> mdiodev->read = smc911x_miiphy_read;
> mdiodev->write = smc911x_miiphy_write;
>
> --
> 2.25.1
>
Reviewed-by: Ramon Fried 

Re: [PATCH 16/25] net: sh_eth: ensure mdiodev->name is NULL terminated after MDIO_NAME_LEN truncation

[Ramon Fried]

On Mon, Sep 27, 2021 at 2:22 PM Vladimir Oltean  wrote:
>
> strncpy() simply bails out when copying a source string whose size
> exceeds the destination string size, potentially leaving the destination
> string unterminated.
>
> One possible way to address is to pass MDIO_NAME_LEN - 1 and a
> previously zero-initialized destination string, but this is more
> difficult to maintain.
>
> The chosen alternative is to use strlcpy(), which properly limits the
> copy len in the (srclen >= size) case to "size - 1", and which is also
> more efficient than the strncpy() byte-by-byte implementation by using
> memcpy. The destination string returned by strlcpy() is always NULL
> terminated.
>
> Signed-off-by: Vladimir Oltean 
> ---
>  drivers/net/sh_eth.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/sh_eth.c b/drivers/net/sh_eth.c
> index 3143a5813a6d..4055f07b2feb 100644
> --- a/drivers/net/sh_eth.c
> +++ b/drivers/net/sh_eth.c
> @@ -657,7 +657,7 @@ int sh_eth_initialize(struct bd_info *bd)
> mdiodev = mdio_alloc();
> if (!mdiodev)
> return -ENOMEM;
> -   strncpy(mdiodev->name, dev->name, MDIO_NAME_LEN);
> +   strlcpy(mdiodev->name, dev->name, MDIO_NAME_LEN);
> mdiodev->read = bb_miiphy_read;
> mdiodev->write = bb_miiphy_write;
>
> --
> 2.25.1
>
Reviewed-by: Ramon Fried 

Re: [PATCH 18/25] net: davinci_emac: ensure mdiodev->name is NULL terminated after MDIO_NAME_LEN truncation

[Ramon Fried]

On Mon, Sep 27, 2021 at 2:22 PM Vladimir Oltean  wrote:
>
> strncpy() simply bails out when copying a source string whose size
> exceeds the destination string size, potentially leaving the destination
> string unterminated.
>
> One possible way to address is to pass MDIO_NAME_LEN - 1 and a
> previously zero-initialized destination string, but this is more
> difficult to maintain.
>
> The chosen alternative is to use strlcpy(), which properly limits the
> copy len in the (srclen >= size) case to "size - 1", and which is also
> more efficient than the strncpy() byte-by-byte implementation by using
> memcpy. The destination string returned by strlcpy() is always NULL
> terminated.
>
> Signed-off-by: Vladimir Oltean 
> ---
>  drivers/net/ti/davinci_emac.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ti/davinci_emac.c b/drivers/net/ti/davinci_emac.c
> index bfe1b84cd566..2dfadbd82d5b 100644
> --- a/drivers/net/ti/davinci_emac.c
> +++ b/drivers/net/ti/davinci_emac.c
> @@ -816,7 +816,7 @@ static int davinci_emac_probe(struct udevice *dev)
> struct mii_dev *mdiodev = mdio_alloc();
> if (!mdiodev)
> return -ENOMEM;
> -   strncpy(mdiodev->name, phy[i].name, MDIO_NAME_LEN);
> +   strlcpy(mdiodev->name, phy[i].name, MDIO_NAME_LEN);
> mdiodev->read = davinci_mii_phy_read;
> mdiodev->write = davinci_mii_phy_write;
>
> --
> 2.25.1
>
Reviewed-by: Ramon Fried 

Re: [PATCH 20/25] net: mdio-uclass: rewrite dm_mdio_post_probe using strlcpy

[Ramon Fried]

On Mon, Sep 27, 2021 at 2:22 PM Vladimir Oltean  wrote:
>
> dm_mdio_post_probe used to be vulnerable after truncation, but has been
> patched by commit 398e7512d8d7 ("net: Fix Covarity Defect 244093").
> Nonetheless, we can use strlcpy like the rest of the code base now,
> which yields the same result.
>
> Signed-off-by: Vladimir Oltean 
> ---
>  net/mdio-uclass.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/mdio-uclass.c b/net/mdio-uclass.c
> index 1b687765b8ca..e74e34f78f9c 100644
> --- a/net/mdio-uclass.c
> +++ b/net/mdio-uclass.c
> @@ -101,7 +101,7 @@ static int dm_mdio_post_probe(struct udevice *dev)
> pdata->mii_bus->write = mdio_write;
> pdata->mii_bus->reset = mdio_reset;
> pdata->mii_bus->priv = dev;
> -   strncpy(pdata->mii_bus->name, dev->name, MDIO_NAME_LEN - 1);
> +   strlcpy(pdata->mii_bus->name, dev->name, MDIO_NAME_LEN);
>
> return mdio_register(pdata->mii_bus);
>  }
> --
> 2.25.1
>
Reviewed-by: Ramon Fried 

Re: [PATCH 22/25] net: dsa: felix: check return code of mdio_alloc and mdio_register

[Ramon Fried]

On Mon, Sep 27, 2021 at 2:22 PM Vladimir Oltean  wrote:
>
> These functions can return errors, it's best to catch them and trigger
> the driver unwind code path.
>
> Signed-off-by: Vladimir Oltean 
> ---
>  drivers/net/mscc_eswitch/felix_switch.c | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/mscc_eswitch/felix_switch.c 
> b/drivers/net/mscc_eswitch/felix_switch.c
> index 4c2e57755967..98ae39e81d65 100644
> --- a/drivers/net/mscc_eswitch/felix_switch.c
> +++ b/drivers/net/mscc_eswitch/felix_switch.c
> @@ -276,6 +276,7 @@ static void felix_init(struct udevice *dev)
>  static int felix_probe(struct udevice *dev)
>  {
> struct felix_priv *priv = dev_get_priv(dev);
> +   int err;
>
> if (ofnode_valid(dev_ofnode(dev)) &&
> !ofnode_is_available(dev_ofnode(dev))) {
> @@ -300,11 +301,18 @@ static int felix_probe(struct udevice *dev)
> struct mii_dev *mii_bus;
>
> mii_bus = mdio_alloc();
> +   if (!mii_bus)
> +   return -ENOMEM;
> +
> mii_bus->read = felix_mdio_read;
> mii_bus->write = felix_mdio_write;
> mii_bus->priv = priv->imdio_base + FELIX_PM_IMDIO_BASE;
> strlcpy(mii_bus->name, dev->name, MDIO_NAME_LEN);
> -   mdio_register(mii_bus);
> +   err = mdio_register(mii_bus);
> +   if (err) {
> +   mdio_free(mii_bus);
> +   return err;
> +   }
> }
>
> dm_pci_clrset_config16(dev, PCI_COMMAND, 0, PCI_COMMAND_MEMORY);
> --
> 2.25.1
>
Reviewed-by: Ramon Fried 

Re: [PATCH 23/25] net: dsa: ensure port names are NULL-terminated after DSA_PORT_NAME_LENGTH truncation

[Ramon Fried]

On Mon, Sep 27, 2021 at 2:22 PM Vladimir Oltean  wrote:
>
> strncpy() simply bails out when copying a source string whose size
> exceeds the destination string size, potentially leaving the destination
> string unterminated.
>
> One possible way to address is to pass DSA_PORT_NAME_LENGTH - 1 and a
> previously zero-initialized destination string, but this is more
> difficult to maintain.
>
> The chosen alternative is to use strlcpy(), which properly limits the
> copy len in the (srclen >= size) case to "size - 1", and which is also
> more efficient than the strncpy() byte-by-byte implementation by using
> memcpy. The destination string returned by strlcpy() is always NULL
> terminated.
>
> Signed-off-by: Vladimir Oltean 
> ---
>  net/dsa-uclass.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/dsa-uclass.c b/net/dsa-uclass.c
> index 9b8ae1e82b92..8db0de686e2a 100644
> --- a/net/dsa-uclass.c
> +++ b/net/dsa-uclass.c
> @@ -221,7 +221,7 @@ static int dsa_port_of_to_pdata(struct udevice *pdev)
>
> label = ofnode_read_string(dev_ofnode(pdev), "label");
> if (label)
> -   strncpy(port_pdata->name, label, DSA_PORT_NAME_LENGTH);
> +   strlcpy(port_pdata->name, label, DSA_PORT_NAME_LENGTH);
>
> eth_pdata = dev_get_plat(pdev);
> eth_pdata->priv_pdata = port_pdata;
> @@ -433,7 +433,7 @@ static int dsa_post_bind(struct udevice *dev)
> struct dsa_port_pdata *port_pdata;
>
> port_pdata = dev_get_parent_plat(pdev);
> -   strncpy(port_pdata->name, name, DSA_PORT_NAME_LENGTH);
> +   strlcpy(port_pdata->name, name, DSA_PORT_NAME_LENGTH);
> pdev->name = port_pdata->name;
> }
>
> --
> 2.25.1
>
Reviewed-by: Ramon Fried 

Re: [PATCH] net: phy: mscc: add support for VSC8502 in dual RGMII mode

[Ramon Fried]

On Tue, Sep 28, 2021 at 2:13 AM Vladimir Oltean  wrote:
>
> The VSC8502 is a Microchip (formerly Microsemi, formerly Vitesse)
> dual port, gigabit Ethernet copper PHY which supports the MII, GMII and
> RGMII MAC-side interfaces.
>
> Of these, I could only test RGMII, and my board needed RGMII delays to
> be applied by software, so I am able to confirm that this patch handles
> that properly.
>
> Signed-off-by: Vladimir Oltean 
> ---
>  drivers/net/phy/mscc.c | 56 ++
>  1 file changed, 56 insertions(+)
>
> diff --git a/drivers/net/phy/mscc.c b/drivers/net/phy/mscc.c
> index d1a643cf5a0c..f9482b21a010 100644
> --- a/drivers/net/phy/mscc.c
> +++ b/drivers/net/phy/mscc.c
> @@ -19,6 +19,7 @@
>  /* Microsemi PHY ID's */
>  #define PHY_ID_VSC8530  0x00070560
>  #define PHY_ID_VSC8531  0x00070570
> +#define PHY_ID_VSC8502 0x00070630
>  #define PHY_ID_VSC8540  0x00070760
>  #define PHY_ID_VSC8541  0x00070770
>  #define PHY_ID_VSC8574 0x000704a0
> @@ -1513,6 +1514,50 @@ static int vsc8584_config(struct phy_device *phydev)
> return vsc8584_config_init(phydev);
>  }
>
> +static int vsc8502_config(struct phy_device *phydev)
> +{
> +   bool rgmii_rx_delay = false, rgmii_tx_delay = false;
> +   u16 reg = 0;
> +   int ret;
> +
> +   /* Assume nothing needs to be done for the default GMII/MII mode */
> +   if (!phy_interface_is_rgmii(phydev))
> +   return 0;
> +
> +   /* Set Extended PHY Control 1 register to RGMII */
> +   phy_write(phydev, MDIO_DEVAD_NONE, MSCC_PHY_EXT_PHY_CNTL_1_REG,
> + BIT(13) | BIT(12));
> +
> +   /* Soft reset required after changing PHY mode from the default
> +* of GMII/MII
> +*/
> +   ret = mscc_phy_soft_reset(phydev);
> +   if (ret)
> +   return ret;
> +
> +   if (phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID ||
> +   phydev->interface == PHY_INTERFACE_MODE_RGMII_ID)
> +   rgmii_rx_delay = true;
> +   if (phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID ||
> +   phydev->interface == PHY_INTERFACE_MODE_RGMII_ID)
> +   rgmii_tx_delay = true;
> +
> +   phy_write(phydev, MDIO_DEVAD_NONE, MSCC_EXT_PAGE_ACCESS,
> + MSCC_PHY_PAGE_EXT2);
> +
> +   if (rgmii_rx_delay)
> +   reg |= VSC_PHY_RGMII_DELAY_2000_PS << RGMII_RX_CLK_DELAY_POS;
> +   if (rgmii_tx_delay)
> +   reg |= VSC_PHY_RGMII_DELAY_2000_PS << RGMII_TX_CLK_DELAY_POS;
> +
> +   phy_write(phydev, MDIO_DEVAD_NONE, MSCC_PHY_RGMII_CNTL_REG, reg);
> +
> +   phy_write(phydev, MDIO_DEVAD_NONE, MSCC_EXT_PAGE_ACCESS,
> + MSCC_PHY_PAGE_STD);
> +
> +   return 0;
> +}
> +
>  static struct phy_driver VSC8530_driver = {
> .name = "Microsemi VSC8530",
> .uid = PHY_ID_VSC8530,
> @@ -1533,6 +1578,16 @@ static struct phy_driver VSC8531_driver = {
> .shutdown = &genphy_shutdown,
>  };
>
> +static struct phy_driver VSC8502_driver = {
> +   .name = "Microsemi VSC8502",
> +   .uid = PHY_ID_VSC8502,
> +   .mask = 0x0000,
> +   .features = PHY_GBIT_FEATURES,
> +   .config = &vsc8502_config,
> +   .startup = &mscc_startup,
> +   .shutdown = &genphy_shutdown,
> +};
> +
>  static struct phy_driver VSC8540_driver = {
> .name = "Microsemi VSC8540",
> .uid = PHY_ID_VSC8540,
> @@ -1577,6 +1632,7 @@ int phy_mscc_init(void)
>  {
> phy_register(&VSC8530_driver);
> phy_register(&VSC8531_driver);
> +   phy_register(&VSC8502_driver);
> phy_register(&VSC8540_driver);
> phy_register(&VSC8541_driver);
> phy_register(&VSC8574_driver);
> --
> 2.25.1
>
Reviewed-by: Ramon Fried 

Re: [PATCH 1/9] net: tsec: add support for promiscuous mode

[Ramon Fried]

On Tue, Sep 28, 2021 at 2:48 AM Vladimir Oltean  wrote:
>
> The Freescale TSEC can be a DSA master, and the ports of the attached
> DSA switch can have different MAC addresses compared to the TSEC.
> Nonetheless, the TSEC must receive the packets on behalf of those switch
> ports. Therefore, implement the promiscuous mode method to allow DSA to
> set this.
>
> Note that the init_registers() function called from eth_ops :: start
> overwrites this setting. There is no reason why the RCTRL register
> should be zero-initialized, so just stop clearing it so that the setting
> we applied in eth_ops :: set_promisc sticks.
>
> Signed-off-by: Vladimir Oltean 
> ---
>  drivers/net/tsec.c | 20 
>  include/tsec.h |  2 ++
>  2 files changed, 18 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c
> index f0cf0a7559ab..6f9abdae9269 100644
> --- a/drivers/net/tsec.c
> +++ b/drivers/net/tsec.c
> @@ -156,6 +156,19 @@ static int tsec_mcast_addr(struct udevice *dev, const u8 
> *mcast_mac, int join)
> return 0;
>  }
>
> +static int tsec_set_promisc(struct udevice *dev, bool enable)
> +{
> +   struct tsec_private *priv = dev_get_priv(dev);
> +   struct tsec __iomem *regs = priv->regs;
> +
> +   if (enable)
> +   setbits_be32(®s->rctrl, RCTRL_PROM);
> +   else
> +   clrbits_be32(®s->rctrl, RCTRL_PROM);
> +
> +   return 0;
> +}
> +
>  /*
>   * Initialized required registers to appropriate values, zeroing
>   * those we don't care about (unless zero is bad, in which case,
> @@ -186,8 +199,6 @@ static void init_registers(struct tsec __iomem *regs)
> out_be32(®s->hash.gaddr6, 0);
> out_be32(®s->hash.gaddr7, 0);
>
> -   out_be32(®s->rctrl, 0x);
> -
> /* Init RMON mib registers */
> memset((void *)®s->rmon, 0, sizeof(regs->rmon));
>
> @@ -454,7 +465,7 @@ void redundant_init(struct tsec_private *priv)
> 0x71, 0x72};
>
> /* Enable promiscuous mode */
> -   setbits_be32(®s->rctrl, 0x8);
> +   setbits_be32(®s->rctrl, RCTRL_PROM);
> /* Enable loopback mode */
> setbits_be32(®s->maccfg1, MACCFG1_LOOPBACK);
> /* Enable transmit and receive */
> @@ -506,7 +517,7 @@ void redundant_init(struct tsec_private *priv)
> if (fail)
> panic("eTSEC init fail!\n");
> /* Disable promiscuous mode */
> -   clrbits_be32(®s->rctrl, 0x8);
> +   clrbits_be32(®s->rctrl, RCTRL_PROM);
> /* Disable loopback mode */
> clrbits_be32(®s->maccfg1, MACCFG1_LOOPBACK);
>  }
> @@ -932,6 +943,7 @@ static const struct eth_ops tsec_ops = {
> .free_pkt = tsec_free_pkt,
> .stop = tsec_halt,
> .mcast = tsec_mcast_addr,
> +   .set_promisc = tsec_set_promisc,
>  };
>
>  static struct tsec_data etsec2_data = {
> diff --git a/include/tsec.h b/include/tsec.h
> index 5433cfd96610..044ee35a91bd 100644
> --- a/include/tsec.h
> +++ b/include/tsec.h
> @@ -122,6 +122,8 @@
>  #define ECNTRL_REDUCED_MII_MODE0x0004
>  #define ECNTRL_SGMII_MODE  0x0002
>
> +#define RCTRL_PROM 0x0008
> +
>  #ifndef CONFIG_SYS_TBIPA_VALUE
>  # define CONFIG_SYS_TBIPA_VALUE0x1f
>  #endif
> --
> 2.25.1
>
Reviewed-by: Ramon Fried 

Re: [PATCH 3/9] net: dsa: allow drivers to get the port OF node

[Ramon Fried]

On Tue, Sep 28, 2021 at 2:48 AM Vladimir Oltean  wrote:
>
> In the current DSA switch driver API, only the udevice of the switch
> (belonging to UCLASS_DSA) is exposed, as well as an "int port" argument.
> So drivers do not have access to the udevice of individual ports
> (belonging to UCLASS_ETH), one of the reasons being that not all ports
> have an associated UCLASS_ETH udevice.
>
> However, all DSA ports have an OF node, and in some cases the driver
> needs a handle to it, for all ports including the CPU port. Example: the
> following Linux per-port device tree property:
>
> managed = "in-band-status";
>
> states whether a port should operate with clause 37 in-band autoneg
> enabled or not.
>
> This patch exposes a function which can be called by individual drivers
> as needed.
>
> Signed-off-by: Vladimir Oltean 
> ---
>  include/net/dsa.h | 12 
>  net/dsa-uclass.c  | 20 
>  2 files changed, 32 insertions(+)
>
> diff --git a/include/net/dsa.h b/include/net/dsa.h
> index ab2a9dfbea2d..d165427fcd4c 100644
> --- a/include/net/dsa.h
> +++ b/include/net/dsa.h
> @@ -6,6 +6,7 @@
>  #ifndef __DSA_H__
>  #define __DSA_H__
>
> +#include 
>  #include 
>  #include 
>
> @@ -145,6 +146,17 @@ int dsa_set_tagging(struct udevice *dev, ushort 
> headroom, ushort tailroom);
>   */
>  struct udevice *dsa_get_master(struct udevice *dev);
>
> +/**
> + * dsa_port_get_ofnode() - Return a reference to the given port's OF node
> + *
> + * Can be called at driver probe time or later.
> + *
> + * @dev:   DSA switch udevice pointer
> + * @port:  Port index
> + * @return OF node reference if OK, NULL on error
> + */
> +ofnode dsa_port_get_ofnode(struct udevice *dev, int port);
> +
>  /**
>   * dsa_port_get_pdata() - Helper that returns the platdata of an active
>   * (non-CPU) DSA port device.
> diff --git a/net/dsa-uclass.c b/net/dsa-uclass.c
> index a9b4484d6d24..61bb47d0102d 100644
> --- a/net/dsa-uclass.c
> +++ b/net/dsa-uclass.c
> @@ -44,6 +44,26 @@ int dsa_set_tagging(struct udevice *dev, ushort headroom, 
> ushort tailroom)
> return 0;
>  }
>
> +ofnode dsa_port_get_ofnode(struct udevice *dev, int port)
> +{
> +   struct dsa_pdata *pdata = dev_get_uclass_plat(dev);
> +   struct dsa_port_pdata *port_pdata;
> +   struct udevice *pdev;
> +
> +   if (port == pdata->cpu_port)
> +   return pdata->cpu_port_node;
> +
> +   for (device_find_first_child(dev, &pdev);
> +pdev;
> +device_find_next_child(&pdev)) {
> +   port_pdata = dev_get_parent_plat(pdev);
> +   if (port_pdata->index == port)
> +   return dev_ofnode(pdev);
> +   }
> +
> +   return ofnode_null();
> +}
> +
>  /* returns the DSA master Ethernet device */
>  struct udevice *dsa_get_master(struct udevice *dev)
>  {
> --
> 2.25.1
>
Reviewed-by: Ramon Fried 

Re: [PATCH 4/9] net: introduce a helper to determine whether to use in-band autoneg

[Ramon Fried]

On Tue, Sep 28, 2021 at 2:48 AM Vladimir Oltean  wrote:
>
> Certain serial SERDES protocols like 1000base-x, 2500base-x, SGMII,
> USXGMII can operate either in a mode where the PHY (be it on-board or
> inside an SFP module) passes the link parameters (speed, duplex, pause)
> to the MAC through in-band through control words standardized by IEEE
> 802.3 clause 37, or in a mode where the MAC must configure (force) its
> link parameters based on information obtained out-of-band (MDIO reads,
> guesswork etc).
>
> In Linux, the OF node property named "managed" is parsed by the phylink
> framework, and the convention is that if a driver uses phylink, then the
> presence of this property means that in-band autoneg should be enabled,
> otherwise it shouldn't.
>
> To be compatible with the OF node bindings of drivers that use phylink
> in Linux, introduce parsing support for this property in U-Boot too.
>
> Signed-off-by: Vladimir Oltean 
> ---
>  drivers/core/of_extra.c | 12 
>  include/dm/of_extra.h   | 14 ++
>  2 files changed, 26 insertions(+)
>
> diff --git a/drivers/core/of_extra.c b/drivers/core/of_extra.c
> index 632a1c2210e8..59ce9174ad07 100644
> --- a/drivers/core/of_extra.c
> +++ b/drivers/core/of_extra.c
> @@ -155,3 +155,15 @@ bool ofnode_phy_is_fixed_link(ofnode eth_node, ofnode 
> *phy_node)
>
> return true;
>  }
> +
> +bool ofnode_eth_uses_inband_aneg(ofnode eth_node)
> +{
> +   bool inband_aneg = false;
> +   const char *managed;
> +
> +   managed = ofnode_read_string(eth_node, "managed");
> +   if (managed && !strcmp(managed, "in-band-status"))
> +   inband_aneg = true;
> +
> +   return inband_aneg;
> +}
> diff --git a/include/dm/of_extra.h b/include/dm/of_extra.h
> index f0d205491c16..c2498aa5859c 100644
> --- a/include/dm/of_extra.h
> +++ b/include/dm/of_extra.h
> @@ -114,4 +114,18 @@ int ofnode_decode_memory_region(ofnode config_node, 
> const char *mem_type,
>   */
>  bool ofnode_phy_is_fixed_link(ofnode eth_node, ofnode *phy_node);
>
> +/**
> + * ofnode_eth_uses_inband_aneg() - Detect whether MAC should use in-band 
> autoneg
> + *
> + * This function detects whether the Ethernet controller should use IEEE 
> 802.3
> + * clause 37 in-band autonegotiation for serial protocols such as 1000base-x,
> + * SGMII, USXGMII, etc. The property is relevant when the Ethernet controller
> + * is connected to an on-board PHY or an SFP cage, and is not relevant when 
> it
> + * has a fixed link (in that case, in-band autoneg should not be used).
> + *
> + * @param eth_node ofnode belonging to the Ethernet controller
> + * @return true if in-band autoneg should be used, false otherwise
> + */
> +bool ofnode_eth_uses_inband_aneg(ofnode eth_node);
> +
>  #endif
> --
> 2.25.1
>
Reviewed-by: Ramon Fried 

Re: [PATCH 5/9] net: dsa: felix: configure the in-band autoneg property based on OF node info

[Ramon Fried]

On Tue, Sep 28, 2021 at 2:48 AM Vladimir Oltean  wrote:
>
> Instead of trying to guess which operating modes need in-band
> negotiation to be active and which ones don't, parse the available
> information from the device tree. That will be correct in the cases we
> can already guess, and more.
>
> Signed-off-by: Vladimir Oltean 
> ---
>  drivers/net/mscc_eswitch/felix_switch.c | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/mscc_eswitch/felix_switch.c 
> b/drivers/net/mscc_eswitch/felix_switch.c
> index 6aa79784460d..1df7d03fc40c 100644
> --- a/drivers/net/mscc_eswitch/felix_switch.c
> +++ b/drivers/net/mscc_eswitch/felix_switch.c
> @@ -16,6 +16,7 @@
>   */
>
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -210,17 +211,14 @@ static int felix_init_sxgmii(struct mii_dev *imdio, int 
> pidx)
>  static void felix_start_pcs(struct udevice *dev, int port,
> struct phy_device *phy, struct mii_dev *imdio)
>  {
> -   bool autoneg = true;
> -
> -   if (phy->phy_id == PHY_FIXED_ID ||
> -   phy->interface == PHY_INTERFACE_MODE_SGMII_2500)
> -   autoneg = false;
> +   ofnode node = dsa_port_get_ofnode(dev, port);
> +   bool inband_an = ofnode_eth_uses_inband_aneg(node);
>
> switch (phy->interface) {
> case PHY_INTERFACE_MODE_SGMII:
> case PHY_INTERFACE_MODE_SGMII_2500:
> case PHY_INTERFACE_MODE_QSGMII:
> -   felix_init_sgmii(imdio, port, autoneg);
> +   felix_init_sgmii(imdio, port, inband_an);
> break;
> case PHY_INTERFACE_MODE_XGMII:
> case PHY_INTERFACE_MODE_XFI:
> --
> 2.25.1
>
Reviewed-by: Ramon Fried 

Re: [PATCH 14/25] net: dsa: felix: ensure mii_bus->name is NULL terminated after MDIO_NAME_LEN truncation

[Ramon Fried]

On Mon, Sep 27, 2021 at 2:22 PM Vladimir Oltean  wrote:
>
> strncpy() simply bails out when copying a source string whose size
> exceeds the destination string size, potentially leaving the destination
> string unterminated.
>
> One possible way to address is to pass MDIO_NAME_LEN - 1 and a
> previously zero-initialized destination string, but this is more
> difficult to maintain.
>
> The chosen alternative is to use strlcpy(), which properly limits the
> copy len in the (srclen >= size) case to "size - 1", and which is also
> more efficient than the strncpy() byte-by-byte implementation by using
> memcpy. The destination string returned by strlcpy() is always NULL
> terminated.
>
> Signed-off-by: Vladimir Oltean 
> ---
>  drivers/net/mscc_eswitch/felix_switch.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/mscc_eswitch/felix_switch.c 
> b/drivers/net/mscc_eswitch/felix_switch.c
> index 6aa79784460d..4c2e57755967 100644
> --- a/drivers/net/mscc_eswitch/felix_switch.c
> +++ b/drivers/net/mscc_eswitch/felix_switch.c
> @@ -258,7 +258,7 @@ static void felix_init(struct udevice *dev)
> priv->imdio.read = felix_mdio_read;
> priv->imdio.write = felix_mdio_write;
> priv->imdio.priv = priv->imdio_base + FELIX_PM_IMDIO_BASE;
> -   strncpy(priv->imdio.name, dev->name, MDIO_NAME_LEN);
> +   strlcpy(priv->imdio.name, dev->name, MDIO_NAME_LEN);
>
> /* set up CPU port */
> out_le32(base + FELIX_QSYS_SYSTEM_EXT_CPU_CFG,
> @@ -303,7 +303,7 @@ static int felix_probe(struct udevice *dev)
> mii_bus->read = felix_mdio_read;
> mii_bus->write = felix_mdio_write;
> mii_bus->priv = priv->imdio_base + FELIX_PM_IMDIO_BASE;
> -   strncpy(mii_bus->name, dev->name, MDIO_NAME_LEN);
> +   strlcpy(mii_bus->name, dev->name, MDIO_NAME_LEN);
> mdio_register(mii_bus);
> }
>
> --
> 2.25.1
>
Reviewed-by: Ramon Fried 

Re: [PATCH 19/25] net: qe: uec: ensure mdiodev->name is NULL terminated after MDIO_NAME_LEN truncation

[Ramon Fried]

On Mon, Sep 27, 2021 at 2:22 PM Vladimir Oltean  wrote:
>
> strncpy() simply bails out when copying a source string whose size
> exceeds the destination string size, potentially leaving the destination
> string unterminated.
>
> One possible way to address is to pass MDIO_NAME_LEN - 1 and a
> previously zero-initialized destination string, but this is more
> difficult to maintain.
>
> The chosen alternative is to use strlcpy(), which properly limits the
> copy len in the (srclen >= size) case to "size - 1", and which is also
> more efficient than the strncpy() byte-by-byte implementation by using
> memcpy. The destination string returned by strlcpy() is always NULL
> terminated.
>
> Signed-off-by: Vladimir Oltean 
> ---
>  drivers/qe/uec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/qe/uec.c b/drivers/qe/uec.c
> index 5da971ddc0af..c4bd5c4a147f 100644
> --- a/drivers/qe/uec.c
> +++ b/drivers/qe/uec.c
> @@ -1407,7 +1407,7 @@ int uec_initialize(struct bd_info *bis, struct uec_inf 
> *uec_info)
>
> if (!mdiodev)
> return -ENOMEM;
> -   strncpy(mdiodev->name, dev->name, MDIO_NAME_LEN);
> +   strlcpy(mdiodev->name, dev->name, MDIO_NAME_LEN);
> mdiodev->read = uec_miiphy_read;
> mdiodev->write = uec_miiphy_write;
>
> --
> 2.25.1
>
Reviewed-by: Ramon Fried 

Re: [PATCH 1/2] net: dsa: pass CPU port fixed PHY to .port_disable

[Tim Harvey]

On Sat, Sep 18, 2021 at 4:50 AM Vladimir Oltean  wrote:
>
> While adding the logic for DSA to register a fixed-link PHY for the CPU
> port, I forgot to pass it to the .port_disable method too, just
> .port_enable.
>
> Bug had no impact for felix_switch.c, due to the phy argument not being
> used, but ksz9477.c does use it => NULL pointer dereference.
>
> Fixes: fc054d563bfb ("net: Introduce DSA class for Ethernet switches")
> Signed-off-by: Vladimir Oltean 
> ---
>  net/dsa-uclass.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/dsa-uclass.c b/net/dsa-uclass.c
> index 9b8ae1e82b92..d1c6c78acd6c 100644
> --- a/net/dsa-uclass.c
> +++ b/net/dsa-uclass.c
> @@ -100,7 +100,7 @@ static void dsa_port_stop(struct udevice *pdev)
>
> port_pdata = dev_get_parent_plat(pdev);
> ops->port_disable(dev, port_pdata->index, port_pdata->phy);
> -   ops->port_disable(dev, priv->cpu_port, NULL);
> +   ops->port_disable(dev, priv->cpu_port, 
> priv->cpu_port_fixed_phy);
> }
>
> eth_get_ops(master)->stop(master);
> --
> 2.25.1
>

Turns out ksz9477.c only used it if debug was enabled as right after
the debug print it would return for cpu port.

Tested on imx8mm-venice-gw7901 with ksz9477 switch.

Tested-By: Tim Harvey 

Re: [PATCH u-boot-spi v2 2/9] mtd: spi-nor-core: Check return value of write_enable() in spi_nor_erase()

[Pratyush Yadav]

On 25/09/21 07:33PM, Marek Behún wrote:
> From: Marek Behún 
> 
> The spi_nor_erase() function does not check return value of the
> write_enable() call. Fix this.

This is the case for many more calls for write_enable(), but we can fix 
them later I suppose.

Reviewed-by: Pratyush Yadav 

> 
> Signed-off-by: Marek Behún 
> Reviewed-by: Simon Glass 
> Reviewed-by: Jagan Teki 
> Tested-by: Masami Hiramatsu 
> ---
>  drivers/mtd/spi/spi-nor-core.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
> index 529e7e9178..d2018ab702 100644
> --- a/drivers/mtd/spi/spi-nor-core.c
> +++ b/drivers/mtd/spi/spi-nor-core.c
> @@ -929,7 +929,9 @@ static int spi_nor_erase(struct mtd_info *mtd, struct 
> erase_info *instr)
>   if (ret < 0)
>   goto erase_err;
>  #endif
> - write_enable(nor);
> + ret = write_enable(nor);
> + if (ret < 0)
> + goto erase_err;
>  
>   ret = spi_nor_erase_sector(nor, addr);
>   if (ret < 0)
> -- 
> 2.32.0
> 

-- 
Regards,
Pratyush Yadav
Texas Instruments Inc.

Re: [PATCH u-boot-spi v2 1/9] mtd: spi-nor-core: Try cleaning up in case writing BAR failed

[Pratyush Yadav]

On 25/09/21 07:33PM, Marek Behún wrote:
> From: Marek Behún 
> 
> Use the cleanup codepath of spi_nor_erase() also in the event of failure
> of writing the BAR register.
> 
> Signed-off-by: Marek Behún 
> Reviewed-by: Simon Glass 
> Reviewed-by: Jagan Teki 
> Tested-by: Masami Hiramatsu 

Reviewed-by: Pratyush Yadav 

-- 
Regards,
Pratyush Yadav
Texas Instruments Inc.

Re: [PATCH u-boot-spi v2 5/9] mtd: spi-nor-core: Don't check for zero length in spi_nor_erase()

[Pratyush Yadav]

On 25/09/21 07:33PM, Marek Behún wrote:
> From: Marek Behún 
> 
> This check is already done in mtdcore's mtd_erase(), no reason to do
> this here as well.

But do we always get here via mtd_erase()? What about "sf erase"? I 
looked at the code and I don't see any checks for 0 length there.

> 
> Signed-off-by: Marek Behún 
> Reviewed-by: Simon Glass 
> Tested-by: Masami Hiramatsu 
> ---
>  drivers/mtd/spi/spi-nor-core.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
> index 9e936cbe1a..211eea22a4 100644
> --- a/drivers/mtd/spi/spi-nor-core.c
> +++ b/drivers/mtd/spi/spi-nor-core.c
> @@ -912,9 +912,6 @@ static int spi_nor_erase(struct mtd_info *mtd, struct 
> erase_info *instr)
>   dev_dbg(nor->dev, "at 0x%llx, len %lld\n", (long long)instr->addr,
>   (long long)instr->len);
>  
> - if (!instr->len)
> - return 0;
> -
>   div_u64_rem(instr->len, mtd->erasesize, &rem);
>   if (rem)
>   return -EINVAL;
> -- 
> 2.32.0
> 

-- 
Regards,
Pratyush Yadav
Texas Instruments Inc.

Re: imx6 DM_VIDEObroken

[Tim Harvey]

On Tue, Sep 28, 2021 at 5:55 AM Anatolij Gustschin  wrote:
>
> Hey Tim,
>
> On Mon, 27 Sep 2021 17:25:58 -0700
> Tim Harvey thar...@gateworks.com wrote:
>
> > Anatolij,
> >
> > Since commit d37618d18d49 ("imx: convert gwventana board to DM_VIDEO")
> > video support for IMX6 based Ventana boards has been broken.
>
> Back then I've tested similar DM_VIDEO conversion changes on i.mx6q
> nitrogen6q board and on i.mx6d/i.mx6s wandboards, it was okay if
> the board configuration uses the video console output during the
> boot sequence (i.e. configured to show splash screen or to output
> strings on vidconsole).
>
> > I find that while the bind function for fsl_imx6q_ipu is called the
> > probe never is (ipuv3_video_probe). Do you know why this is?
>
> Is video console output used during the boot? If not, then it
> might be the reason. With DM, the devices are probed when a subsystem
> actually tries to use them. You can try to trigger probing via
> switching to the video console output, i.e.:
>
>  => setenv stdout vidconsole

Yes, this calls ipuv3_video_probe. I guess I expected the display to
just work by default as it did before.

I looked over doc/README.console. It may be out of date as it refers
to 'video' instead of 'vidconsole'. What is the difference?

How do I get back to the state where a splash-screen is shown on the
display by default?

> >
> > I see that with commit 57f065fee2a4 ("video: ipuv3: add DM_VIDEO
> > support") you mention that DTS files must include
> > 'u-boot,dm-pre-reloc' for soc/ipu nodes to enable driver binding to
> > ipu device but I haven't been able to get that to make a difference
> > nor have I found a board that does this. You did add those props to
> > imx6qdl.dtsi at one point but they are no longer there.
>
> Does your board dts include imx6qdl-u-boot.dtsi ?
>
> The u-boot,dm-pre-reloc properties were moved to this U-Boot specific
> dtsi in 7932b1c9fdb73393aa110249c89bd426533c0649
> (imx: imx6qdl: dtsi: move U-Boot specific change to u-boot.dtsi)
>

No, I'm not including that but that is the right place for it.

Strangely, I found that if I don't have 'u-boot,dm-pre-reloc' for
soc/ipu nodes enabling video via 'setenv stdout serial,vidconsole'
works. Is there some reason why the prop is no longer required?

> > There must have been several other IMX6 boards with video support that
> > were affected by this so perhaps I'm missing something simple.
>
> I did not test it recently, it looks I'll have to do it before the
> new release.

I would think the other board maintainers would have raised a red flag
if things broke for their boards, I just haven't tested it in quite
some time for gwventana_*_defconfig.

How do you go about testing this by the way without having all the
boards and displays?

Best regards,

Tim

[PATCH] tools/image-host.c: Fix spelling of "expected".

[Vagrant Cascadian]

Signed-off-by: Vagrant Cascadian 
---

 tools/image-host.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/image-host.c b/tools/image-host.c
index d3a882ec29..a6b0a94420 100644
--- a/tools/image-host.c
+++ b/tools/image-host.c
@@ -313,7 +313,7 @@ static int fit_image_read_data(char *filename, unsigned 
char *data,
 
/* Check that we have read all the file */
if (n != sbuf.st_size) {
-   printf("Can't read all file %s (read %zd bytes, expexted 
%lld)\n",
+   printf("Can't read all file %s (read %zd bytes, expected 
%lld)\n",
   filename, n, (long long)sbuf.st_size);
goto err;
}
-- 
2.30.2

Re: [PATCH 6/9] net: add driver for NXP SJA1105 DSA L2 switch

[Ramon Fried]

On Tue, Sep 28, 2021 at 2:48 AM Vladimir Oltean  wrote:
>
> The SJA1105 driver is largely reused from Linux. Its programming model
> is that it is blank out of reset, and it waits for a static
> configuration stream over SPI, which contains all runtime parameters (it
> has no notion of "default values").
>
> Keeping a binary array for the configuration stream would have meant
> that aspects such as the CPU port and the MAC speeds could have not been
> configured easily, and would have been static and board-dependent.
> Live-patching the binary array means recalculating the static config
> table CRCs, which is not a fun process.
>
> So we create an abstraction over the static config tables, using the
> packing API, same as in Linux. The tables are kept as C structures, and
> the binary configuration stream is constructed on-the-go, with CRC and
> all.
>
> All static config tables instantiated in this driver are mandatory.
> The hardware reference manual can be found at:
> https://www.nxp.com/docs/en/user-guide/UM10944.pdf
>
> For tagging, a simplified version of tag_8021q from Linux is used. The
> VLAN EtherType is the same (0xdadb) but since we don't want switching in
> U-Boot, there is no reason to have a TX VLAN and an RX VLAN for each
> port. We just need the RX VLANs to act as the unique pvid of each
> front-panel port, to decode the switch port number. The RX VLAN is used
> for both RX and TX.
>
> The device tree bindings are the same as in Linux.
>
> Signed-off-by: Vladimir Oltean 
> ---
>  drivers/net/Kconfig   |   16 +
>  drivers/net/Makefile  |1 +
>  drivers/net/sja1105.c | 3351 +
>  3 files changed, 3368 insertions(+)
>  create mode 100644 drivers/net/sja1105.c
>
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index d4dc72046c4e..a6e90dad0b4f 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -542,6 +542,22 @@ config RTL8169
>   This driver supports Realtek 8169 series gigabit ethernet family of
>   PCI/PCIe chipsets/adapters.
>
> +config SJA1105
> +   bool "NXP SJA1105 Ethernet switch family driver"
> +   depends on DM_DSA && DM_SPI
> +   select BITREVERSE
> +   help
> + This is the driver for the NXP SJA1105 automotive Ethernet switch
> + family. These are 5-port devices and are managed over an SPI
> + interface. Probing is handled based on OF bindings. The driver
> + supports the following revisions:
> +   - SJA1105E (Gen. 1, No TT-Ethernet)
> +   - SJA1105T (Gen. 1, TT-Ethernet)
> +   - SJA1105P (Gen. 2, No SGMII, No TT-Ethernet)
> +   - SJA1105Q (Gen. 2, No SGMII, TT-Ethernet)
> +   - SJA1105R (Gen. 2, SGMII, No TT-Ethernet)
> +   - SJA1105S (Gen. 2, SGMII, TT-Ethernet)
> +
>  config SMC911X
> bool "SMSC LAN911x and LAN921x controller driver"
>
> diff --git a/drivers/net/Makefile b/drivers/net/Makefile
> index b94ccea1003b..d9c394ee3dab 100644
> --- a/drivers/net/Makefile
> +++ b/drivers/net/Makefile
> @@ -28,6 +28,7 @@ obj-$(CONFIG_DM_ETH_PHY) += eth-phy-uclass.o
>  obj-$(CONFIG_E1000) += e1000.o
>  obj-$(CONFIG_E1000_SPI) += e1000_spi.o
>  obj-$(CONFIG_EEPRO100) += eepro100.o
> +obj-$(CONFIG_SJA1105) += sja1105.o
>  obj-$(CONFIG_SUN4I_EMAC) += sunxi_emac.o
>  obj-$(CONFIG_SUN8I_EMAC) += sun8i_emac.o
>  obj-$(CONFIG_EP93XX) += ep93xx_eth.o
> diff --git a/drivers/net/sja1105.c b/drivers/net/sja1105.c
> new file mode 100644
> index ..99a73e41ef8e
> --- /dev/null
> +++ b/drivers/net/sja1105.c
> @@ -0,0 +1,3351 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright 2016-2018 NXP
> + * Copyright 2018, Sensor-Technik Wiedemann GmbH
> + * Copyright 2018-2019, Vladimir Oltean 
> + * Copyright 2020-2021 NXP
> + *
> + * Ported from Linux (drivers/net/dsa/sja1105/).
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +enum packing_op {
> +   PACK,
> +   UNPACK,
> +};
> +
> +#define ETHER_CRC32_POLY   0x04C11DB7
> +#define ETH_P_SJA1105  0xdadb
> +#define SJA1105_NUM_PORTS  5
> +#define SJA1110_NUM_PORTS  11
> +#define SJA1105_MAX_NUM_PORTS  SJA1110_NUM_PORTS
> +#define SJA1105_NUM_TC 8
> +#define SJA1105ET_FDB_BIN_SIZE 4
> +#define SJA1105_SIZE_CGU_CMD   4
> +#define SJA1105_SIZE_RESET_CMD 4
> +#define SJA1105_SIZE_MDIO_CMD  4
> +#define SJA1105_SIZE_SPI_MSG_HEADER4
> +#define SJA1105_SIZE_SPI_MSG_MAXLEN(64 * 4)
> +#define SJA1105_SIZE_DEVICE_ID 4
> +#define SJA1105_SIZE_TABLE_HEADER  12
> +#def

Re: [PATCH v2 1/3] efi_loader: add SMBIOS table measurement

[Ilias Apalodimas]

Hi Simon,


[...]
> > > > We've mentioned this in the past.  The sandbox TPM is very limited wrt
> > > > tpm testing for the EFI TCG protocol.
> > >
> > > So let's add some more features? If it helps, think of the sandbox TPM
> > > as test code, not an emulator. It is a very simple kind of emulator to
> > > allow tests to work.
> >
> > The amount of features needed to test EFI TCG are not minimal.  Since I'll
> > upstream the mmio tpm anyway,  we'll just test TCG there.  If someone wants
> > to go ahead and make the sandbox TPM a TIS compliant device that covers the
> > requirements of the EFI TCG,  I am fine using it.
>
> Do you know how many features? There's 250 LOC in this patch.

I haven't checked for a while but back when I tested it
tpm2_get_capability() was failing on a number of cases.  The EFI TCG
code expects:
- TPM2_PT_MAX_COMMAND_SIZE
- TPM2_PT_MAX_RESPONSE_SIZE
- TPM2_PT_MANUFACTURER
- TPM2_PT_PCR_COUNT
- TPM2_CAP_PCRS
when querying capabilities.  Ideally we'd also want to extend more
than 1 PCRs and verify that worked correctly.

>
> >
> > >
> > > > I did send TPM MMIO patches a while back [1].  This would allow us to
> > > > test everything under QEMU,  but you asked for *another* device to be
> > > > part of the API I posted (apart from the MMIO).  I've found some time
> > >
> > > Yes that is because if you just add a new protocol you have not made
> > > anything better, just added one more way of doing things.
> >
> > Our perspective of 'better' seems to be different.
> >
> > I added a TIS API for any driver to use.  I actually did 2 iterations of
> > the driver.  The first one was replicating all the code and you said 'why
> > are we replicating code',  which was done already in a bunch of drivers
> > already...
> > Then I added an API and a driver using it but you wanted to convert more
> > *existing* drivers to the API before merging it. But the fact is that if
> > anyone wants to add a new driver he has to code  ~900 lines instead of the
> > ~150 needed with the API in place,  not to mention the duplication of bugs
> > all over the place
>
> It would be like adding a new filesystem in U-Boot with its own new
> framework for filesystems. It creates technical debt and we don't know
> if anyone will actually use it.
>
> https://xkcd.com/927/
>
> I think your API is a great idea but we need some effort to migrate to
> it, to avoid the problem above. After all, who else is going to do it?

I ordered the SPI TPM, so hopefully, I'll be able to have the MMIO and
SPI drivers using it!

Cheers
/Ilias

error -22 whilst initialising SD Card - New Raspberry Pi 4b 4GB (C0 stepping)

[Craig Setera]

Hello,

I wasn't quite sure where to report this, so I figured I would start 
with the mailing list.  If there is another place I should go, please 
feel free to redirect me.


I'm a user if IPFire which uses u-boot.  I recently bought a new 
Raspberry Pi 4b 4gb device, but it fails to boot with a loop that says:


|invalid bus width error -22 whilst initialising SD Card |I originally opened up a bug report with the IPFire team (https://bugzilla.ipfire.org/show_bug.cgi?id=12690), but it now appears that this is a|but somewhere in u-boot. I downloaded an Ubuntu 20.04 image that 
behaves the same way. As I stated in the IPFire issue, I'm seeing this 
behavior on a Raspberry Pi, but not on an older device. I ran a number 
of tests:|


To validate that this is an issue with newer hardware, I was able to take 
advantage of another Pi 4 that is probably a year or so old in my Retropie 
setup.  I used that Pi and a Samsung 32G EVO SD card.  I tried the following 
combinations, all with a monitor and keyboard attached (and SERIAL set to off 
in uEnv.txt):

* RaspiOS - "old" Pi 4 - Works
* RaspiOS - "new" Pi 4 - Works
* IPFire - "old" Pi 4 - Works
* IPFire - "new" Pi 4 - Boot loops

As discussed in the forum thread, this looks suspiciously like an issue with 
U-Boot on newer Pi 4 hardware as discussed here:

*https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255080  

*https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255080#c47  


Craig

||

Re: Status of the various RISC-V specification and policy

[Palmer Dabbelt]

On Mon, 27 Sep 2021 08:57:15 PDT (-0700), markhimelst...@riscv.org wrote:
the words in this document : 


https://wiki.riscv.org/plugins/servlet/mobile?contentId=13098230#content/view/13098230

make it very clear when changes are allowed or not and likely or not.

if you think the verbiage is somehow ambiguous please help us make it better.


I'm not really worried about changes, I'm worried about a committment to 
future compatibility.  When we take code into the kernel (and most other 
core systems projects) we're taking on the burden of supporting (until 
someone can prove there are no more users), which is very difficult to 
do when the ISA changes in an incompatible fashion.  The whole point of 
agreeing on the frozen thing was that it gave us a committment from the 
specifcation authors that the future ISA would be compatible with th 
frozen extensions.


We're already in this spot with the V extension and the whole stable 
thing, this definitaion of frozen looks very much like what was has led 
to the issues there.  Saying the spec won't change really isn't 
meaningful, it's saying future specs will be compatible that's 
important.  Nothing in this whole rule touches on compatibility, and I 
really don't want to end up in a bigger mess than we're already in.


(Also: some PGE subcontractor drove a crane into my house, so things are 
a bit chaotic on my end.  If you have that list of what's officially 
frozen, can you send it out?  I'll try to take a look ASAP, as then I 
can at least focus the discussion on what's relevant right now.)




Mark

sent from a mobile device. please forgive any typos.


On Sep 27, 2021, at 8:50 AM, Palmer Dabbelt  wrote:

On Tue, 21 Sep 2021 17:20:17 PDT (-0700), ati...@atishpatra.org wrote:

Hi All,
Please find the below email from Stephano about the freeze announcement for
various RISC-V specifications that will be part of privilege specification
v1.12.
All the review discussions are happening in the isa-dev mailing list. The
review period will be open for 45 days ending Sunday October 31, 2021.

I just want to highlight the fact that the *H*, *V, SvPBMT, CMO extensions
are frozen now. *This will help us merge some patches that have been
present in the mailing list for a while.

Here are the ratification policy and extension life cycle documents present
in the public. If you have any questions regarding this, please check with
Mark/Stephano (cc'd).

Ratification policy:
https://docs.google.com/document/d/1-UlaSGqk59_myeuPMrV9gyuaIgnmFzGh5Gfy_tpViwM/edit

Extension life cycle:
https://docs.google.com/presentation/d/1nQ5uFb39KA6gvUi5SReWfIQSiRN7hp6z7ZPfctE4mKk/edit#slide=id.p1


I'm still buried after Plumbers, but one of the bits on my TODO list was to 
look throught the new definitions for frozen and stable.  Nothing in this 
extension life cycle talks about the point at which compatibility will be 
maintained, which was really the central point behind frozen before.

Are there more concrete definitions somewhere?

Re: [PATCH] mtd: nand: raw: convert nand_dt_init() to ofnode_xx() interface

[Tom Rini]

On Mon, Sep 13, 2021 at 04:25:53PM +0200, Patrice Chotard wrote:

> nand_dt_init() is still using fdtdec_xx() interface.
> If OF_LIVE flag is enabled, dt property can't be get anymore.
> Updating all fdtdec_xx() interface to ofnode_xx() to solve this issue.
> 
> For doing this, node parameter type must be ofnode.
> 
> First idea was to convert "node" parameter to ofnode type inside
> nand_dt_init() using offset_to_ofnode(node). But offset_to_ofnode()
> is not bijective, in case OF_LIVE flag is enabled, it performs an assert().
> 
> So, this leads to update nand_chip struct flash_node field from int to
> ofnode and to update all nand_dt_init() callers.
> 
> Signed-off-by: Patrice Chotard 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [RFC][PATCH] mtd: spi: Set CONFIG_SF_DEFAULT_MODE default to 0

[Tom Rini]

On Tue, Sep 14, 2021 at 08:28:24PM +0200, Marek Vasut wrote:

> Before e2e95e5e254 ("spi: Update speed/mode on change") most systems
> silently defaulted to SF bus mode 0. Now the mode is always updated,
> which causes breakage. It seems most SF which are used as boot media
> operate in bus mode 0, so switch that as the default.
> 
> This should fix booting at least on Altera SoCFPGA, ST STM32, Xilinx
> ZynqMP, NXP iMX and Rockchip SoCs, which recently ran into trouble
> with mode 3. Marvell Kirkwood and Xilinx microblaze need to be checked
> as those might need mode 3.
> 
> Signed-off-by: Marek Vasut 
> Cc: Aleksandar Gerasimovski 
> Cc: Andreas Biessmann 
> Cc: Eugen Hristev 
> Cc: Michal Simek 
> Cc: Patrice Chotard 
> Cc: Patrick Delaunay 
> Cc: Peng Fan 
> Cc: Siew Chin Lim 
> Cc: Tom Rini 
> Cc: Valentin Longchamp 
> Cc: Vignesh Raghavendra 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] imx: imx7d-sdb: fix ethernet, sync .dts with linux

[Tom Rini]

On Thu, Sep 16, 2021 at 04:53:14PM +0200, Rasmus Villemoes wrote:

> Commit 0d52bab46 (mx7dsabre: Enable DM_ETH) changed these flags from 0
> (aka GPIO_ACTIVE_HIGH) to GPIO_ACTIVE_LOW. It claimed to "Also sync
> device tree with v5.5-rc1", but in the linux tree, these gpios have
> always been GPIO_ACTIVE_HIGH ever since this node was introduced
> around v4.13 (linux commit 184f39b5).
> 
> I'm guessing that the reason for the GPIO_ACTIVE_LOW was to work
> around the behaviour of the soft-spi driver back then, which
> effectively defaulted to spi-mode 3 and not 0. That was arguably a bug
> in the soft-spi driver, which then got fixed in 0e146993bb3 (spi: add
> support for all spi modes with soft spi), but that commit then broke
> ethernet on this board.
> 
> Fix it by setting the gpios as active high, which as a bonus actually
> brings us in sync with the .dts in the linux source tree.
> 
> Without this, one gets
> 
> Net:   Could not get PHY for FEC0: addr 0
> No ethernet found.
> 
> With this, ethernet (at least ping and tftp) works as expected from
> the U-Boot shell.
> 
> Cc: Fabio Estevam 
> Cc: Joris Offouga 
> Cc: "Christian Bräuner Sørensen" 
> Signed-off-by: Rasmus Villemoes 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v4 1/2] mtd: cfi_flash: use cfi_flash_num_flash_banks only when supported

[Tom Rini]

On Wed, Sep 22, 2021 at 06:29:07PM +0200, Patrick Delaunay wrote:

> When CONFIG_SYS_MAX_FLASH_BANKS_DETECT is activated,
> CONFIG_SYS_MAX_FLASH_BANKS is replaced by cfi_flash_num_flash_banks,
> but this variable is defined in drivers/mtd/cfi_flash.c, which is
> compiled only when CONFIG_FLASH_CFI_DRIVER is activated, in U-Boot
> or in SPL when CONFIG_SPL_MTD_SUPPORT is activated.
> 
> This patch deactivates this feature CONFIG_SYS_MAX_FLASH_BANKS_DETECT
> when flash cfi driver is not activated to avoid compilation issue in
> the next patch, when CONFIG_SYS_MAX_FLASH_BANKS is used in spi_nor_scan().
> 
> Signed-off-by: Patrick Delaunay 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v4 2/2] mtd: spi: nor: force mtd name to "nor%d"

[Tom Rini]

On Wed, Sep 22, 2021 at 06:29:08PM +0200, Patrick Delaunay wrote:

> Force the mtd name of spi-nor to "nor" + the driver sequence number:
> "nor0", "nor1"... beginning after the existing nor devices.
> 
> This patch is coherent with existing "nand" and "spi-nand"
> mtd device names.
> 
> When CFI MTD NOR device are supported, the spi-nor index is chosen after
> the last CFI device defined by CONFIG_SYS_MAX_FLASH_BANKS.
> 
> When CONFIG_SYS_MAX_FLASH_BANKS_DETECT is activated, this config
> is replaced by to cfi_flash_num_flash_banks in the include file
> mtd/cfi_flash.h.
> 
> This generic name "nor%d" can be use to identify the mtd spi-nor device
> without knowing the real device name or the DT path of the device,
> used with API get_mtd_device_nm() and is used in mtdparts command.
> 
> This patch also avoids issue when the same NOR device is present 2 times,
> for example on STM32MP15F-EV1:
> 
> STM32MP> mtd list
> SF: Detected mx66l51235l with page size 256 Bytes, erase size 64 KiB, \
> total 64 MiB
> 
> List of MTD devices:
> * nand0
>   - type: NAND flash
>   - block size: 0x4 bytes
>   - min I/O: 0x1000 bytes
>   - OOB size: 224 bytes
>   - OOB available: 118 bytes
>   - ECC strength: 8 bits
>   - ECC step size: 512 bytes
>   - bitflip threshold: 6 bits
>   - 0x-0x4000 : "nand0"
> * mx66l51235l
>   - device: mx66l51235l@0
>   - parent: spi@58003000
>   - driver: jedec_spi_nor
>   - path: /soc/spi@58003000/mx66l51235l@0
>   - type: NOR flash
>   - block size: 0x1 bytes
>   - min I/O: 0x1 bytes
>   - 0x-0x0400 : "mx66l51235l"
> * mx66l51235l
>   - device: mx66l51235l@1
>   - parent: spi@58003000
>   - driver: jedec_spi_nor
>   - path: /soc/spi@58003000/mx66l51235l@1
>   - type: NOR flash
>   - block size: 0x1 bytes
>   - min I/O: 0x1 bytes
>   - 0x-0x0400 : "mx66l51235l"
> 
> The same mtd name "mx66l51235l" identify the 2 instances
> mx66l51235l@0 and mx66l51235l@1.
> 
> This patch fixes a ST32CubeProgrammer / stm32prog command issue
> with nor0 target on STM32MP157C-EV1 board introduced by
> commit b7f060565e31 ("mtd: spi-nor: allow registering multiple MTDs when
> DM is enabled").
> 
> Fixes: b7f060565e31 ("mtd: spi-nor: allow registering multiple MTDs when DM 
> is enabled")
> Signed-off-by: Patrick Delaunay 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Please pull u-boot-net/network_master

[Ramon Fried]

Hi Tom,
Please pull u-boot-net/network_master.

The following changes since commit 0b9bcf665cd98fe9db0956c894006b250a7d465f:

  Prepare v2021.10-rc5 (2021-09-27 09:34:20 -0400)

are available in the Git repository at:

  https://source.denx.de/u-boot/custodians/u-boot-net.git

for you to fetch changes up to 17d7482fd816316bce74db5e93e29430a9b01a3d:

  scripts: ensure the cocci script for miiphy_register does not leak
the MDIO bus (2021-09-28 20:10:53 +0300)


Ramon Fried (1):
  net: tsec: Mark tsec_get_interface as __maybe_unused

Vladimir Oltean (41):
  net: dsa: felix: felix_init() can be static
  net: dsa: use "err" instead of "ret" in dsa_port_probe
  net: dsa: refactor the code to set the port MAC address into a
dedicated function
  net: dsa: introduce a .port_probe() method in struct dsa_ops
  net: dsa: felix: call phy_config at .port_probe() time
  net: dsa: felix: propagate the error code from phy_startup()
  net: update NXP copyright text
  net: dsa: pass CPU port fixed PHY to .port_disable
  net: dsa: remove unused variables
  net: phy: genphy_init can be static
  net: replace the "xfi" phy-mode with "10gbase-r"
  net: freescale: replace usage of phy-mode = "sgmii-2500" with "2500base-x"
  net: enetc: remove support for "xgmii" phy-mode
  net: dsa: felix: remove "xgmii" phy-mode
  net: tsec: only call tsec_get_interface as fallback to
DT-specified PHY mode
  net: tsec: read the phy-mode property as fallback to phy-connection-type
  arch: powerpc: mpc85xx: ensure mdiodev->name is NULL terminated
after MDIO_NAME_LEN truncation
  board: gdsys: a38x: ensure mdiodev->name is NULL terminated
after MDIO_NAME_LEN truncation
  net: armada100_fec: ensure mdiodev->name is NULL terminated
after MDIO_NAME_LEN truncation
  net: at91_emac: ensure mdiodev->name is NULL terminated after
MDIO_NAME_LEN truncation
  net: bcm-sf2: ensure mdiodev->name is NULL terminated after
MDIO_NAME_LEN truncation
  net: eepro100: ensure mdiodev->name is NULL terminated after
MDIO_NAME_LEN truncation
  net: ep93xx: ensure mdiodev->name is NULL terminated after
MDIO_NAME_LEN truncation
  net: enetc: ensure imdio.name is NULL terminated after
MDIO_NAME_LEN truncation
  net: mcdmafec: ensure bus->name is NULL terminated after
MDIO_NAME_LEN truncation
  net: ftmac110: ensure mdiodev->name is NULL terminated after
MDIO_NAME_LEN truncation
  net: lpc32xx: ensure mdiodev->name is NULL terminated after
MDIO_NAME_LEN truncation
  net: macb: ensure mdiodev->name is NULL terminated after
MDIO_NAME_LEN truncation
  net: mpc8xx_fec: ensure mdiodev->name is NULL terminated after
MDIO_NAME_LEN truncation
  net: dsa: felix: ensure mii_bus->name is NULL terminated after
MDIO_NAME_LEN truncation
  net: mvgbe: ensure mdiodev->name is NULL terminated after
MDIO_NAME_LEN truncation
  net: sh_eth: ensure mdiodev->name is NULL terminated after
MDIO_NAME_LEN truncation
  net: smc911x: ensure mdiodev->name is NULL terminated after
MDIO_NAME_LEN truncation
  net: davinci_emac: ensure mdiodev->name is NULL terminated after
MDIO_NAME_LEN truncation
  net: qe: uec: ensure mdiodev->name is NULL terminated after
MDIO_NAME_LEN truncation
  net: mdio-uclass: rewrite dm_mdio_post_probe using strlcpy
  scripts: ensure the cocci script for miiphy_register does not
leave NULL-unterminated strings
  net: dsa: felix: check return code of mdio_alloc and mdio_register
  net: dsa: ensure port names are NULL-terminated after
DSA_PORT_NAME_LENGTH truncation
  arch: powerpc: mpc85xx: free MDIO bus if mdio_register fails
  scripts: ensure the cocci script for miiphy_register does not
leak the MDIO bus

 arch/arm/cpu/armv8/fsl-layerscape/cpu.c|  2 +-
 arch/arm/cpu/armv8/fsl-layerscape/doc/README.soc   |  8 +--
 arch/arm/cpu/armv8/fsl-layerscape/ls1088a_serdes.c |  2 +-
 arch/arm/dts/fsl-ls1028a-qds-1xxx-sch-30842.dtsi   |  2 +-
 arch/arm/dts/fsl-ls1028a-qds-6xxx-sch-30842.dtsi   |  4 +-
 arch/arm/dts/fsl-ls1028a-qds--sch-30841.dtsi   | 10 +--
 arch/arm/dts/fsl-ls1028a-qds-7xx7-sch-30841R.dtsi  |  6 +-
 arch/arm/dts/fsl-ls1028a-qds-8xxx-sch-24801.dtsi   |  2 +-
 .../dts/fsl-ls1028a-qds--sch-24801-LBRW.dtsi   |  2 +-
 arch/arm/dts/fsl-ls1028a-qds--sch-24801.dtsi   |  2 +-
 .../dts/fsl-ls1028a-qds-x3xx-sch-30841-LBRW.dtsi   |  2 +-
 .../dts/fsl-ls1028a-qds-x5xx-sch-28021-LBRW.dtsi   |  2 +-
 arch/arm/dts/fsl-ls1028a-qds-x7xx-sch-30842.dtsi   |  4 +-
 arch/arm/dts/fsl-ls1028a-qds-xx7x-sch-30842.dtsi   |  4 +-
 arch/arm/dts/fsl-ls1088a-qds-sd1-21.dtsi   |  4 +-
 arch/arm/dts/fsl-ls1088a-qds-sd1-29.dtsi   |  4 +-
 arch/arm/dts/fsl-ls2080a-qds-sd1-42.dtsi   | 16 ++---
 arch/arm/dts/fsl-ls2088a-rdb-qspi.dts  | 16 ++---
 arch/arm/dts/fsl-sch-24801.dtsi|  2 +-
 arch/arm/dts/fsl-sc

linksys wrt1900acs v2 boot problem

[Dilyan Lazarov]

Hi,
I have a problem with my linksys wrt1900acs.
My main question is this a hardware problem or software problem?
Is it possible to address?
I have started researching and have tried with "kwboot" under Windows VM -
Ubuntu 20 - Linux but I have a problem with usb serial connection. I have
tried several things but I understand that it isn't possible to start USB
to Serial on a Windows VM.
I will expect your response.
Thank you in advance.

All the best
Dilyan

I see the following Log from U-Boot with PuTTy under Windows 10:
BootROM - 1.73
Booting from NAND flash

General initialization - Version: 1.0.0
Detected Device ID 6820
High speed PHY - Version: 2.0

Init RD NAS topology Serdes Lane 3 is USB3
Serdes Lane 4 is SGMII
board SerDes lanes topology details:
 | Lane #  | Speed |  Type   |
 
 |   0|  06   |  SATA0  |
 |   1|  05   |  PCIe0  |
 |   2|  06   |  SATA1  |
 |   3|  05   |  USB3 HOST1 |
 |   4|  05   |  PCIe1  |
 |   5|  00   |  SGMII2 |
 
:** Link is Gen1, check the EP capability
PCIe, Idx 0: Link upgraded to Gen2 based on client cpabilities
:** Link is Gen1, check the EP capability
PCIe, Idx 1: remains Gen1
High speed PHY - Ended Successfully
DDR3 Training Sequence - Ver TIP-1.26.0
mvSysEnvGetTopologyUpdateInfo: TWSI Read failed
WL Supp: IF 0 busId 1 Failed !
WL Supp: IF 0 failed
ddr3TipDynamicWriteLevelingSupp failure
   DRAM initialization Failed (res 0x1)   
DDR3 run algorithm - FAILED 0x1
DDR3 Training Sequence - FAILED


 **  DRAM initialization failed!   
-- 
Dilyan

Re: Status of the various RISC-V specification and policy

[Atish Patra]

On Tue, Sep 28, 2021 at 11:34 AM Palmer Dabbelt  wrote:
>
> On Mon, 27 Sep 2021 08:57:15 PDT (-0700), markhimelst...@riscv.org wrote:
> > the words in this document :
> >
> > https://wiki.riscv.org/plugins/servlet/mobile?contentId=13098230#content/view/13098230
> >
> > make it very clear when changes are allowed or not and likely or not.
> >
> > if you think the verbiage is somehow ambiguous please help us make it 
> > better.
>
> I'm not really worried about changes, I'm worried about a committment to
> future compatibility.  When we take code into the kernel (and most other
> core systems projects) we're taking on the burden of supporting (until
> someone can prove there are no more users), which is very difficult to
> do when the ISA changes in an incompatible fashion.  The whole point of
> agreeing on the frozen thing was that it gave us a committment from the
> specifcation authors that the future ISA would be compatible with th
> frozen extensions.
>
> We're already in this spot with the V extension and the whole stable
> thing, this definitaion of frozen looks very much like what was has led
> to the issues there.  Saying the spec won't change really isn't
> meaningful, it's saying future specs will be compatible that's
> important.  Nothing in this whole rule touches on compatibility, and I
> really don't want to end up in a bigger mess than we're already in.
>
> (Also: some PGE subcontractor drove a crane into my house, so things are
> a bit chaotic on my end.  If you have that list of what's officially
> frozen, can you send it out?  I'll try to take a look ASAP, as then I
> can at least focus the discussion on what's relevant right now.)

Here is the list of the specs that are frozen.
https://wiki.riscv.org/display/TECH/ISA+Extensions+On+Deck+for+Freeze+Milestone
I will let Mark comment on the compatibility thing.

>
> >
> > Mark
> > 
> > sent from a mobile device. please forgive any typos.
> >
> >> On Sep 27, 2021, at 8:50 AM, Palmer Dabbelt  wrote:
> >>
> >> On Tue, 21 Sep 2021 17:20:17 PDT (-0700), ati...@atishpatra.org wrote:
> >>> Hi All,
> >>> Please find the below email from Stephano about the freeze announcement 
> >>> for
> >>> various RISC-V specifications that will be part of privilege specification
> >>> v1.12.
> >>> All the review discussions are happening in the isa-dev mailing list. The
> >>> review period will be open for 45 days ending Sunday October 31, 2021.
> >>>
> >>> I just want to highlight the fact that the *H*, *V, SvPBMT, CMO extensions
> >>> are frozen now. *This will help us merge some patches that have been
> >>> present in the mailing list for a while.
> >>>
> >>> Here are the ratification policy and extension life cycle documents 
> >>> present
> >>> in the public. If you have any questions regarding this, please check with
> >>> Mark/Stephano (cc'd).
> >>>
> >>> Ratification policy:
> >>> https://docs.google.com/document/d/1-UlaSGqk59_myeuPMrV9gyuaIgnmFzGh5Gfy_tpViwM/edit
> >>>
> >>> Extension life cycle:
> >>> https://docs.google.com/presentation/d/1nQ5uFb39KA6gvUi5SReWfIQSiRN7hp6z7ZPfctE4mKk/edit#slide=id.p1
> >>
> >> I'm still buried after Plumbers, but one of the bits on my TODO list was 
> >> to look throught the new definitions for frozen and stable.  Nothing in 
> >> this extension life cycle talks about the point at which compatibility 
> >> will be maintained, which was really the central point behind frozen 
> >> before.
> >>
> >> Are there more concrete definitions somewhere?



-- 
Regards,
Atish

Re: Status of the various RISC-V specification and policy

[Palmer Dabbelt]

On Tue, 28 Sep 2021 13:05:53 PDT (-0700), ati...@atishpatra.org wrote:

On Tue, Sep 28, 2021 at 11:34 AM Palmer Dabbelt  wrote:


On Mon, 27 Sep 2021 08:57:15 PDT (-0700), markhimelst...@riscv.org wrote:
> the words in this document :
>
> 
https://wiki.riscv.org/plugins/servlet/mobile?contentId=13098230#content/view/13098230
>
> make it very clear when changes are allowed or not and likely or not.
>
> if you think the verbiage is somehow ambiguous please help us make it better.

I'm not really worried about changes, I'm worried about a committment to
future compatibility.  When we take code into the kernel (and most other
core systems projects) we're taking on the burden of supporting (until
someone can prove there are no more users), which is very difficult to
do when the ISA changes in an incompatible fashion.  The whole point of
agreeing on the frozen thing was that it gave us a committment from the
specifcation authors that the future ISA would be compatible with th
frozen extensions.

We're already in this spot with the V extension and the whole stable
thing, this definitaion of frozen looks very much like what was has led
to the issues there.  Saying the spec won't change really isn't
meaningful, it's saying future specs will be compatible that's
important.  Nothing in this whole rule touches on compatibility, and I
really don't want to end up in a bigger mess than we're already in.

(Also: some PGE subcontractor drove a crane into my house, so things are
a bit chaotic on my end.  If you have that list of what's officially
frozen, can you send it out?  I'll try to take a look ASAP, as then I
can at least focus the discussion on what's relevant right now.)


Here is the list of the specs that are frozen.
https://wiki.riscv.org/display/TECH/ISA+Extensions+On+Deck+for+Freeze+Milestone


How does that indicate what is frozen?  I see "ISA Extensions On Deck 
for Freeze Milestone" as the title, which makes it sound like these are 
extension that are not yet frozen but will be eventually.


Scrolling down to the end of that list, it lists pointer masking.  The 
best I can find is 
https://github.com/riscv/riscv-j-extension/blob/master/pointer-masking-proposal.adoc 
, which says "Version: v0.1-draft", which definately doesn't sound 
frozen.  The README says "Working Draft of the RISC-V J Extension 
Specification", which also doesn't sound frozen.



I will let Mark comment on the compatibility thing.



>
> Mark
> 
> sent from a mobile device. please forgive any typos.
>
>> On Sep 27, 2021, at 8:50 AM, Palmer Dabbelt  wrote:
>>
>> On Tue, 21 Sep 2021 17:20:17 PDT (-0700), ati...@atishpatra.org wrote:
>>> Hi All,
>>> Please find the below email from Stephano about the freeze announcement for
>>> various RISC-V specifications that will be part of privilege specification
>>> v1.12.
>>> All the review discussions are happening in the isa-dev mailing list. The
>>> review period will be open for 45 days ending Sunday October 31, 2021.
>>>
>>> I just want to highlight the fact that the *H*, *V, SvPBMT, CMO extensions
>>> are frozen now. *This will help us merge some patches that have been
>>> present in the mailing list for a while.
>>>
>>> Here are the ratification policy and extension life cycle documents present
>>> in the public. If you have any questions regarding this, please check with
>>> Mark/Stephano (cc'd).
>>>
>>> Ratification policy:
>>> 
https://docs.google.com/document/d/1-UlaSGqk59_myeuPMrV9gyuaIgnmFzGh5Gfy_tpViwM/edit
>>>
>>> Extension life cycle:
>>> 
https://docs.google.com/presentation/d/1nQ5uFb39KA6gvUi5SReWfIQSiRN7hp6z7ZPfctE4mKk/edit#slide=id.p1
>>
>> I'm still buried after Plumbers, but one of the bits on my TODO list was to 
look throught the new definitions for frozen and stable.  Nothing in this extension 
life cycle talks about the point at which compatibility will be maintained, which was 
really the central point behind frozen before.
>>
>> Are there more concrete definitions somewhere?




--
Regards,
Atish

Re: [PATCH] sandbox: Remove OF_HOSTFILE

[Simon Glass]

Hi Ilias,

On Tue, 28 Sept 2021 at 03:05, Ilias Apalodimas
 wrote:
>
> OF_HOSTFILE is used on sandbox configs only.  Although it's pretty
> unique not a source of any confusions,  we are better of having simple
> config options for the DTB.
> So let's replace that with the existing OF_BOARD.  This will make U-Boot
> have only three different config options for the DTB origin.
> - OF_SEPARATE, build separately from U-Boot
> - OF_BOARD, board specific way of providing the DTB
> - OF_EMBED embedded in the u-boot binary, but discouraged from being used
>   in production
>
> Signed-off-by: Ilias Apalodimas 
> ---
>  Makefile  |  6 +++---
>  arch/sandbox/cpu/cpu.c| 21 -
>  arch/sandbox/include/asm/u-boot-sandbox.h |  8 
>  configs/sandbox64_defconfig   |  2 +-
>  configs/sandbox_defconfig |  2 +-
>  configs/sandbox_flattree_defconfig|  2 +-
>  configs/sandbox_noinst_defconfig  |  2 +-
>  configs/sandbox_spl_defconfig |  2 +-
>  configs/tools-only_defconfig  |  2 +-
>  doc/develop/devicetree/control.rst|  7 +++
>  dts/Kconfig   |  9 -
>  lib/fdtdec.c  |  5 -
>  scripts/Makefile.spl  |  4 ++--
>  13 files changed, 26 insertions(+), 46 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 3014788e14e8..cf3d98d00a62 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -957,7 +957,7 @@ INPUTS-$(CONFIG_BINMAN_STANDALONE_FDT) += u-boot.dtb
>  ifeq ($(CONFIG_SPL_FRAMEWORK),y)
>  INPUTS-$(CONFIG_OF_SEPARATE) += u-boot-dtb.img
>  endif
> -INPUTS-$(CONFIG_OF_HOSTFILE) += u-boot.dtb
> +INPUTS-$(CONFIG_SANDBOX) += u-boot.dtb
>  ifneq ($(CONFIG_SPL_TARGET),)
>  INPUTS-$(CONFIG_SPL) += $(CONFIG_SPL_TARGET:"%"=%)
>  endif
> @@ -1423,7 +1423,7 @@ u-boot-lzma.img: u-boot.bin.lzma FORCE
>
>  u-boot-dtb.img u-boot.img u-boot.kwb u-boot.pbl u-boot-ivt.img: \
> $(if $(CONFIG_SPL_LOAD_FIT),u-boot-nodtb.bin \
> -   $(if 
> $(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_OF_HOSTFILE)$(CONFIG_BINMAN_STANDALONE_FDT),dts/dt.dtb)
>  \
> +   $(if 
> $(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_SANDBOX)$(CONFIG_BINMAN_STANDALONE_FDT),dts/dt.dtb)
>  \
> ,$(UBOOT_BIN)) FORCE
> $(call if_changed,mkimage)
> $(BOARD_SIZE_CHECK)
> @@ -1437,7 +1437,7 @@ MKIMAGEFLAGS_u-boot.itb += -B 0x8
>
>  ifdef U_BOOT_ITS
>  u-boot.itb: u-boot-nodtb.bin \
> -   $(if 
> $(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_OF_HOSTFILE),dts/dt.dtb) \
> +   $(if 
> $(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_SANDBOX),dts/dt.dtb) \
> $(U_BOOT_ITS) FORCE
> $(call if_changed,mkfitimage)
> $(BOARD_SIZE_CHECK)
> diff --git a/arch/sandbox/cpu/cpu.c b/arch/sandbox/cpu/cpu.c
> index 48636ab63919..bc67a5a5a10b 100644
> --- a/arch/sandbox/cpu/cpu.c
> +++ b/arch/sandbox/cpu/cpu.c
> @@ -291,44 +291,47 @@ void invalidate_dcache_range(unsigned long start, 
> unsigned long stop)
>  {
>  }
>
> -int sandbox_read_fdt_from_file(void)
> +void *board_fdt_blob_setup(void)

Can you instead keep the function and call it from your new
board_fdt_blob_setup() function? That way the error path goes through
one place and we don't need to add goto.

The other problem is that we need to know whether a DT is required
(i.e. -d, -D or -T). So it must fail (and exit) if it is required but
cannot be loaded.

>  {
> struct sandbox_state *state = state_get_current();
> const char *fname = state->fdt_fname;
> -   void *blob;
> +   void *blob = NULL;
> loff_t size;
> int err;
> int fd;
>
> +   printf("SETUP BLOB\n");

drop debugging

> blob = map_sysmem(CONFIG_SYS_FDT_LOAD_ADDR, 0);
> if (!state->fdt_fname) {
> err = fdt_create_empty_tree(blob, 256);
> if (!err)
> goto done;
> printf("Unable to create empty FDT: %s\n", fdt_strerror(err));
> -   return -EINVAL;
> +   goto fail;
> }
>
> err = os_get_filesize(fname, &size);
> if (err < 0) {
> printf("Failed to file FDT file '%s'\n", fname);
> -   return err;
> +   goto fail;
> }
> fd = os_open(fname, OS_O_RDONLY);
> if (fd < 0) {
> printf("Failed to open FDT file '%s'\n", fname);
> -   return -EACCES;
> +   goto fail;
> }
> +
> if (os_read(fd, blob, size) != size) {
> os_close(fd);
> -   return -EIO;
> +   printf("Failed to read file '%s'\n", fname);
> +   goto fail;
> }
> os_close(fd);
>
>  done:
> -   gd->fdt_blob = blob;
> -
> -   return 0;
> +   return blob;
> +fail:
> +   return NULL;
>

Re: Please pull u-boot-i2c/next

[Tom Rini]

On Tue, Sep 28, 2021 at 08:32:17AM +0200, Heiko Schocher wrote:

> Hello Tom,
> 
> please pull from u-boot-i2c next
> 
> The following changes since commit 1d1f98c8eed7bb4792300e655c2cb70136928f74:
> 
>   Merge tag 'dm-pull-next-27sep21' of 
> https://source.denx.de/u-boot/custodians/u-boot-dm into next
> (2021-09-27 11:09:23 -0400)
> 
> are available in the Git repository at:
> 
>   https://source.denx.de/u-boot/custodians/u-boot-i2c.git 20210928-for-next
> 
> for you to fetch changes up to a70c3f9fb84524243eabefd28e0aa539f22e6226:
> 
>   mtd: nand: raw: convert nand_dt_init() to ofnode_xx() interface (2021-09-28 
> 06:34:45 +0200)
> 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 1/3] doc: ti: Convert am335x_evm README to rST

[Tom Rini]

On Sat, Sep 11, 2021 at 08:57:31AM -0400, Tom Rini wrote:

> Convert the existing documentation to rST, keeping to just making
> formatting changes to start with.
> 
> Signed-off-by: Tom Rini 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 04/17] keystone2: Move CONFIG_AEMIF_CNTRL_BASE out of CONFIG namespace

[Tom Rini]

On Sun, Sep 12, 2021 at 08:32:20PM -0400, Tom Rini wrote:

> This is only used in the aemif driver that is otherwise currently
> keystone2 centric.  Moving forward, if this is applicable to some other
> platform then such base addresses should be able to be obtained via the
> device tree.  Use KS2_AEMIF_CNTRL_BASE directly now rather than
> indirectly.
> 
> Signed-off-by: Tom Rini 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 05/17] usb: phy: ti: Remove non-DM PHY code

[Tom Rini]

On Sun, Sep 12, 2021 at 08:32:21PM -0400, Tom Rini wrote:

> At this point in time, all platforms that had previously used
> drivers/usb/phy/omap_usb_phy.c have been migrated to DM and related
> options.  Remove this now unused code and some related unused defines.
> 
> Signed-off-by: Tom Rini 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 06/17] Convert CONFIG_USB_XHCI_OMAP to Kconfig

[Tom Rini]

On Sun, Sep 12, 2021 at 08:32:22PM -0400, Tom Rini wrote:

> This converts the following to Kconfig:
>CONFIG_USB_XHCI_OMAP
> 
> Signed-off-by: Tom Rini 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 07/17] compulab: Clean up some unused symbols

[Tom Rini]

On Sun, Sep 12, 2021 at 08:32:23PM -0400, Tom Rini wrote:

> Since cm_t35 was removed, CONFIG_CM_T3X does not exist.  This lets us
> simplify the code in board/compulab/common/eeprom.c a bit.
> 
> Cc: Igor Grinberg 
> Cc: Nikita Kiryanov 
> Signed-off-by: Tom Rini 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 2/3] doc: ti: am335x_evm: Minor general updates

[Tom Rini]

On Sat, Sep 11, 2021 at 08:57:32AM -0400, Tom Rini wrote:

> - At this point there are a large number of Beaglebone boards, refer to
>   them as a family rather than a growing list.
> - Reword customization as we're largely Kconfig-oriented now.
> - Remove the NOR section as the relevant defconfigs have long been
>   removed and the general support was not updated.
> 
> Signed-off-by: Tom Rini 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 08/17] ti: keystone: Clean up or migrate some NAND related options.

[Tom Rini]

On Sun, Sep 12, 2021 at 08:32:24PM -0400, Tom Rini wrote:

> The COFNIG_KEYSTONE_RBL_NAND option is always enabled for the driver on
> keystone platforms, but not older davinci platforms.  Use def_bool for
> the symbol. For CONFIG_KEYSTONE_NAND_MAX_RBL_PAGE, it's only used within
> the driver and derived from another symbol, so remove CONFIG from the
> name.  Finally, CONFIG_KEYSTONE_NAND_MAX_RBL_SIZE is a bit more fixed.
> For now, use the value directly.  Long term, as part of DM'ifying NAND,
> this should come from the device tree.
> 
> Signed-off-by: Tom Rini 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 09/17] ti: keystone: dma: Migrate to Kconfig

[Tom Rini]

On Sun, Sep 12, 2021 at 08:32:25PM -0400, Tom Rini wrote:

> Move the main option for handling drivers/dma/keystone_nav* to Kconfig,
> and enable it by default.  All of the sub-symbols are not configurable,
> so remove them from the CONFIG namespace.
> 
> Signed-off-by: Tom Rini 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 10/17] omapl138_lcdk: Stop using CONFIG_MACH_OMAPL138_LCDK

[Tom Rini]

On Sun, Sep 12, 2021 at 08:32:26PM -0400, Tom Rini wrote:

> We have one places that uses this symbol and CONFIG_TARGET_OMAPL138_LCDK
> works equally well, switch to that.
> 
> Signed-off-by: Tom Rini 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 11/17] usb: ehci-omap: Drop non-DM_USB legacy code

[Tom Rini]

On Sun, Sep 12, 2021 at 08:32:27PM -0400, Tom Rini wrote:

> Now that DM_USB is always enabled, we can drop some legacy code.
> 
> Signed-off-by: Tom Rini 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 12/17] Convert CONFIG_OMAP_EHCI_PHY1_RESET_GPIO et al to Kconfig

[Tom Rini]

On Sun, Sep 12, 2021 at 08:32:28PM -0400, Tom Rini wrote:

> This converts the following to Kconfig:
>CONFIG_OMAP_EHCI_PHY1_RESET_GPIO
>CONFIG_OMAP_EHCI_PHY2_RESET_GPIO
>CONFIG_OMAP_EHCI_PHY3_RESET_GPIO
> 
> To do this, we also introduce CONFIG_HAS_CONFIG_OMAP_EHCI_PHYn_RESET_GPIO
> options to get setting the GPIO number.
> 
> Signed-off-by: Tom Rini 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 13/17] am3517_evm: Remove unused comments/code

[Tom Rini]

On Sun, Sep 12, 2021 at 08:32:29PM -0400, Tom Rini wrote:

> Clean up the config header file by removing some now irrelevant code /
> comments.
> 
> Signed-off-by: Tom Rini 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 14/17] omap3_logic: Remove unused comments/code

[Tom Rini]

On Sun, Sep 12, 2021 at 08:32:30PM -0400, Tom Rini wrote:

> Clean up the config header file by removing some now irrelevant code /
> comments.
> 
> Signed-off-by: Tom Rini 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature