Re: [PATCH 0/3] efi_selftest: Update SIMPLE_NETWORK_PROTOCOL selftest

2021-10-03 Thread Masami Hiramatsu
Hi Heinrich, What is the current status of this patch series? Could you give me any comments? Thank you, 2021年9月17日(金) 13:47 Masami Hiramatsu : > > Hi Heinrich, > > 2021年9月17日(金) 12:54 Heinrich Schuchardt : > > > > On 9/16/21 10:53 AM, Masami Hiramatsu wrote: > > > Hello Heinrich, > > > > > >

[resent RFC 22/22] efi_selftest: block device: adjust dp for a test disk

2021-10-03 Thread AKASHI Takahiro
Due to efi_disk-dm integration, the resultant device path for a test disk got slightly changed, with efi_root contained as the first component. Signed-off-by: AKASHI Takahiro --- lib/efi_selftest/efi_selftest_block_device.c | 26 ++-- 1 file changed, 24 insertions(+), 2

[resent RFC 21/22] efi_driver: cleanup after efi_disk-dm integration

2021-10-03 Thread AKASHI Takahiro
efi_driver-specific binding will be no longer needed now that efi_disk- dm integration takes care of efi_driver case as well. Signed-off-by: AKASHI Takahiro --- lib/efi_driver/efi_block_device.c | 24 1 file changed, 24 deletions(-) diff --git

[resent RFC 20/22] efi_driver: align with efi_disk-dm integration

2021-10-03 Thread AKASHI Takahiro
Signed-off-by: AKASHI Takahiro --- lib/efi_driver/efi_block_device.c | 6 ++ lib/efi_loader/efi_device_path.c | 29 + lib/efi_loader/efi_disk.c | 12 +++- 3 files changed, 46 insertions(+), 1 deletion(-) diff --git

[resent RFC 19/22] dm: blk: call efi's device-removal hook

2021-10-03 Thread AKASHI Takahiro
Adding the callback function, efi_disk_delete(), in block devices's pre_remove hook will allows for automatically deleting efi_disk objects per block device. This will eliminate any improper efi_disk objects which hold a link to non-existing udevice structures when associated block devices are

[resent RFC 18/22] efi_loader: efi_disk: a helper function to delete efi_disk objects

2021-10-03 Thread AKASHI Takahiro
This function is expected to be called, in particular from dm's pre_remove hook, when associated block devices no longer exist. Signed-off-by: AKASHI Takahiro --- include/efi_loader.h | 2 ++ lib/efi_loader/efi_disk.c | 54 +++ 2 files changed, 56

[resent RFC 17/22] efi_loader: add efi_remove_handle()

2021-10-03 Thread AKASHI Takahiro
This function is a counterpart of efi_add_handle() and will be used in order to remove an efi_disk object in a later patch. Signed-off-by: AKASHI Takahiro --- include/efi_loader.h | 2 ++ lib/efi_loader/efi_boottime.c | 8 2 files changed, 10 insertions(+) diff --git

[resent RFC 16/22] efi_loader: cleanup after efi_disk-dm integration

2021-10-03 Thread AKASHI Takahiro
efi_disk_register() will be no longer needed now that all efi_disks are set to be created with device model thanks to efi_disk-dm integration. Signed-off-by: AKASHI Takahiro --- include/efi_loader.h | 2 - lib/efi_loader/efi_disk.c | 102 -

[resent RFC 14/22] efi_loader: disk: a helper function to create efi_disk objects from udevice

2021-10-03 Thread AKASHI Takahiro
Add efi_disk_create() function. Any UEFI handle created by efi_disk_create() can be treated as a efi_disk object, the udevice is either a UCLASS_BLK (a whole raw disk) or UCLASS_PARTITION (a disk partition). So this function is expected to be called every time such an udevice is detected and

[resent RFC 15/22] dm: blk: call efi's device-probe hook

2021-10-03 Thread AKASHI Takahiro
Adding this callback function, efi_disk_create() in block devices's post_probe hook will allows for automatically creating efi_disk objects per block device. This will end up not only eliminating efi_disk_register() called in UEFI initialization, but also enabling detections of new block devices

[resent RFC 13/22] efi_loader: remove !CONFIG_BLK code from efi_disk

2021-10-03 Thread AKASHI Takahiro
The change in this patch will probably have been covered by other guy's patch. Signed-off-by: AKASHI Takahiro --- lib/efi_loader/efi_disk.c | 49 --- 1 file changed, 49 deletions(-) diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c index

[resent RFC 12/22] dm: add a hidden link to efi object

2021-10-03 Thread AKASHI Takahiro
This member field in udevice will be used to dereference from udevice to efi_object (or efi_handle). Signed-off-by: AKASHI Takahiro --- include/dm/device.h | 4 1 file changed, 4 insertions(+) diff --git a/include/dm/device.h b/include/dm/device.h index 0a9718a5b81a..33b09a836f06 100644

[resent RFC 11/22] efi_loader: disk: use udevice instead of blk_desc

2021-10-03 Thread AKASHI Takahiro
In most of all usages, we can avoid using blk_desc which is expected to be data private to the device not be accessed outside device drivers. Signed-off-by: AKASHI Takahiro --- lib/efi_loader/efi_disk.c | 25 - 1 file changed, 12 insertions(+), 13 deletions(-) diff

[resent RFC 10/22] dm: blk: add read/write interfaces with udevice

2021-10-03 Thread AKASHI Takahiro
In include/blk.h, Simon suggested: ===> /* * These functions should take struct udevice instead of struct blk_desc, * but this is convenient for migration to driver model. Add a 'd' prefix * to the function operations, so that blk_read(), etc. can be reserved for * functions with the correct

[resent RFC 09/22] dm: blk: add a device-probe hook for scanning disk partitions

2021-10-03 Thread AKASHI Takahiro
Now that all the block device drivers have enable a probe hook, we will call blk_create_partitions() to enumerate all the partitions and create associated udevices when a block device is detected. Signed-off-by: AKASHI Takahiro --- drivers/block/blk-uclass.c | 15 +++ 1 file

[resent RFC 08/22] dm: blk: add UCLASS_PARTITION

2021-10-03 Thread AKASHI Takahiro
UCLASS_PARTITION device will be created as a child node of UCLASS_BLK device. Signed-off-by: AKASHI Takahiro --- drivers/block/blk-uclass.c | 111 + include/blk.h | 9 +++ include/dm/uclass-id.h | 1 + 3 files changed, 121 insertions(+)

[resent RFC 07/22] block: ide: call device_probe() after scanning

2021-10-03 Thread AKASHI Takahiro
Every time an ide bus/port is scanned and a new device is detected, we want to call device_probe() as it will give us a chance to run additional post-processings for some purposes. In particular, support for creating partitions on a device will be added. Signed-off-by: AKASHI Takahiro ---

[resent RFC 06/22] sata: call device_probe() after scanning

2021-10-03 Thread AKASHI Takahiro
Every time a sata bus/port is scanned and a new device is detected, we want to call device_probe() as it will give us a chance to run additional post-processings for some purposes. In particular, support for creating partitions on a device will be added. Signed-off-by: AKASHI Takahiro ---

[resent RFC 05/22] nvme: call device_probe() after scanning

2021-10-03 Thread AKASHI Takahiro
Every time a nvme bus/port is scanned and a new device is detected, we want to call device_probe() as it will give us a chance to run additional post-processings for some purposes. In particular, support for creating partitions on a device will be added. Signed-off-by: AKASHI Takahiro ---

[resent RFC 04/22] mmc: call device_probe() after scanning

2021-10-03 Thread AKASHI Takahiro
Every time a mmc bus/port is scanned and a new device is detected, we want to call device_probe() as it will give us a chance to run additional post-processings for some purposes. In particular, support for creating partitions on a device will be added. Signed-off-by: AKASHI Takahiro ---

[resent RFC 03/22] usb: storage: call device_probe() after scanning

2021-10-03 Thread AKASHI Takahiro
Every time a usb bus/port is scanned and a new device is detected, we want to call device_probe() as it will give us a chance to run additional post-processings for some purposes. In particular, support for creating partitions on a device will be added. Signed-off-by: AKASHI Takahiro ---

[resent RFC 02/22] scsi: call device_probe() after scanning

2021-10-03 Thread AKASHI Takahiro
Every time a scsi bus/port is scanned and a new block device is detected, we want to call device_probe() as it will give us a chance to run additional post-processings for some purposes. In particular, support for creating partitions on a device will be added. Signed-off-by: AKASHI Takahiro ---

[resent RFC 01/22] part: call part_init() in blk_get_device_by_str() only for MMC

2021-10-03 Thread AKASHI Takahiro
In blk_get_device_by_str(), the comment says: "Updates the partition table for the specified hw partition." Since hw partition is supported only on MMC, it makes no sense to do so for other devices. Signed-off-by: AKASHI Takahiro --- disk/part.c | 3 ++- 1 file changed, 2 insertions(+), 1

[resent RFC 00/22] efi_loader: more tightly integrate UEFI disks to device model

2021-10-03 Thread AKASHI Takahiro
# Resending the RFC as some of patches were deplicately submitted. # See also https://git.linaro.org/people/takahiro.akashi/u-boot.git efi/dm_disk The purpose of this RPC is to reignite the discussion about how UEFI subystem would best be integrated into U-Boot device model. In the past, I

Re: [RFC 07/22] dm: blk: add UCLASS_PARTITION

2021-10-03 Thread AKASHI Takahiro
On Fri, Oct 01, 2021 at 11:30:37AM +0200, Heinrich Schuchardt wrote: > > > On 10/1/21 07:01, AKASHI Takahiro wrote: > > UCLASS_PARTITION device will be created as a child node of > > UCLASS_BLK device. > > > > Signed-off-by: AKASHI Takahiro > > --- > > drivers/block/blk-uclass.c | 111

Re: [RFC 01/22] part: call part_init() in blk_get_device_by_str() only for MMC

2021-10-03 Thread AKASHI Takahiro
Hi Peter, On Fri, Oct 01, 2021 at 12:48:24PM +0100, Peter Robinson wrote: > On Fri, Oct 1, 2021 at 6:03 AM AKASHI Takahiro > wrote: > > > > In blk_get_device_by_str(), the comment says: "Updates the partition table > > for the specified hw partition." > > Since hw partition is supported only on

Re: [RFC 01/22] part: call part_init() in blk_get_device_by_str() only for MMC

2021-10-03 Thread AKASHI Takahiro
Heinrich, On Fri, Oct 01, 2021 at 08:41:52AM +0200, Heinrich Schuchardt wrote: > > > On 10/1/21 7:01 AM, AKASHI Takahiro wrote: > > In blk_get_device_by_str(), the comment says: "Updates the partition table > > for the specified hw partition." > > Since hw partition is supported only on MMC, it

Re: [PATCH v3 2/3] efi_loader: add UEFI GPT measurement

2021-10-03 Thread Masahisa Kojima
On Sat, 2 Oct 2021 at 01:28, Heinrich Schuchardt wrote: > > > > On 10/1/21 13:18, Masahisa Kojima wrote: > > This commit adds the UEFI GPT disk partition topology > > measurement required in TCG PC Client PFP Spec. > > > > Signed-off-by: Masahisa Kojima > > --- > > > > Changes in v3: > > -

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

2021-10-03 Thread Masahisa Kojima
On Sat, 2 Oct 2021 at 01:43, Heinrich Schuchardt wrote: > > > > On 10/1/21 13:18, Masahisa Kojima wrote: > > This commit adds the DeployedMode and AuditMode variable > > measurement required in TCG PC Client PFP Spec. > > > > Signed-off-by: Masahisa Kojima > > --- > > > > Changes in v3: > > -

[PATCH next v5 11/12] configs: aspeed: Make EXTRA_ENV_SETTINGS board specific

2021-10-03 Thread Chia-Wei Wang
Move CONFIG_EXTRA_ENV_SETTINGS to board-specific configuration headers. Signed-off-by: Chia-Wei Wang --- include/configs/aspeed-common.h | 9 - include/configs/evb_ast2500.h | 9 + include/configs/evb_ast2600.h | 9 + 3 files changed, 18 insertions(+), 9 deletions(-)

[PATCH next v5 10/12] configs: ast2600-evb: Enable SPL FIT support

2021-10-03 Thread Chia-Wei Wang
Enable SPL FIT image load and verification support. The HW accelerated SHA is also available with the newly added support of the HACE HW hash engine. The SPL thumb build is also enabled to keep the binary less than 64KB to fit into the Aspeed secure boot design. Signed-off-by: Chia-Wei Wang ---

[PATCH next v5 12/12] configs: ast2600: Boot kernel FIT in DRAM

2021-10-03 Thread Chia-Wei Wang
AST2600 leverages the FIT hash/signature verification to fulfill secure boot trust chain. To improve the performance and save SW code size for those crypto operations, the two HW crypto engine, HACE and ACRY, are enabled. However, both of the engines can only access to data stored in DRAM space.

[PATCH next v5 04/12] crypto: aspeed: Add AST2600 HACE support

2021-10-03 Thread Chia-Wei Wang
From: Johnny Huang Hash and Crypto Engine (HACE) is designed to accelerate the throughput of hash data digest, and symmetric-key encryption. Signed-off-by: Johnny Huang Signed-off-by: Chia-Wei Wang --- drivers/crypto/Kconfig | 2 + drivers/crypto/Makefile | 1 +

[PATCH next v5 03/12] clk: ast2600: Add YCLK control for HACE

2021-10-03 Thread Chia-Wei Wang
From: Joel Stanley Add YCLK enable for HACE, the HW hash engine of ASPEED AST2600 SoCs. Signed-off-by: Joel Stanley Signed-off-by: Chia-Wei Wang --- .../arm/include/asm/arch-aspeed/scu_ast2600.h | 5 +++-- drivers/clk/aspeed/clk_ast2600.c | 20 +++ 2 files

[PATCH next v5 09/12] ast2600: spl: Locate load buffer in DRAM space

2021-10-03 Thread Chia-Wei Wang
Return CONFIG_SYS_LOAD_ADDR pointing to DRAM space for spl_get_load_buffer() to allow generic SPL image loading code (e.g. FIT and Ymodem) to store data in DRAM. Signed-off-by: Chia-Wei Wang --- arch/arm/mach-aspeed/ast2600/spl.c | 9 + 1 file changed, 1 insertion(+), 8 deletions(-)

[PATCH next v5 08/12] ARM: dts: ast2600: Add ACRY to device tree

2021-10-03 Thread Chia-Wei Wang
Add ACRY DTS node and enable it for AST2600 EVB. Signed-off-by: Chia-Wei Wang --- arch/arm/dts/ast2600-evb.dts | 5 + arch/arm/dts/ast2600.dtsi| 9 + 2 files changed, 14 insertions(+) diff --git a/arch/arm/dts/ast2600-evb.dts b/arch/arm/dts/ast2600-evb.dts index

[PATCH next v5 07/12] crypto: aspeed: Add AST2600 ACRY support

2021-10-03 Thread Chia-Wei Wang
ACRY is deisnged to accerlerate ECC/RSA digital signature generation and verification. Signed-off-by: Chia-Wei Wang --- drivers/crypto/aspeed/Kconfig | 10 ++ drivers/crypto/aspeed/Makefile | 1 + drivers/crypto/aspeed/aspeed_acry.c | 182

[PATCH next v5 06/12] clk: ast2600: Add RSACLK control for ACRY

2021-10-03 Thread Chia-Wei Wang
Add RSACLK enable for ACRY, the HW RSA/ECC crypto engine of ASPEED AST2600 SoCs. As ACRY and HACE share the same reset control bit, we do not perform the reset-hold-n-release operation during their clock ungating process. Instead, only reset release is conducted to prevent mutual interference.

[PATCH next v5 05/12] ARM: dts: ast2600: Add HACE to device tree

2021-10-03 Thread Chia-Wei Wang
From: Joel Stanley Add HACE DTS node and enable it for AST2600 EVB. Signed-off-by: Joel Stanley Signed-off-by: Chia-Wei Wang --- arch/arm/dts/ast2600-evb.dts | 5 + arch/arm/dts/ast2600.dtsi| 8 2 files changed, 13 insertions(+) diff --git a/arch/arm/dts/ast2600-evb.dts

[PATCH next v5 00/12] aspeed: Support secure boot chain with FIT image verification

2021-10-03 Thread Chia-Wei Wang
This patch series intends to provide a secure boot chain from SPL to Linux kernel based on the hash and signature verification of FIT image paradigm. To improve the performance and save code size (SPL is limited to 64KB due to HW-RoT), the drviers of two HW crypto engine HACE and ACRY are also

[PATCH next v5 02/12] aspeed: ast2600: Enlarge SRAM size

2021-10-03 Thread Chia-Wei Wang
The AST2600 SRAM has been extended to 88KB since A1 chip revision. This patch updates the SRAM size to offer more space for early stack/heap use. Signed-off-by: Chia-Wei Wang --- arch/arm/include/asm/arch-aspeed/platform.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH next v5 01/12] image: fit: Fix parameter name for hash algorithm

2021-10-03 Thread Chia-Wei Wang
Fix inconsistent function parameter name of the hash algorithm. Signed-off-by: Chia-Wei Wang Fixes: 92055e138f2 ("image: Drop if/elseif hash selection in calculate_hash()") --- common/image-fit.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/common/image-fit.c

RE: [PATCH next v4 09/11] configs: ast2600-evb: Enable SPL FIT support

2021-10-03 Thread ChiaWei Wang
Hi Tom, > From: Tom Rini > Sent: Monday, October 4, 2021 2:41 AM > > On Thu, Sep 16, 2021 at 04:52:19PM +0800, Chia-Wei Wang wrote: > > > Enable SPL FIT image load and verification support. > > The HW accelerated SHA is also available with the newly added support > > of the HACE HW hash

[RFC 3/3] usb: ehci-omap: Enable phy drivers to enable/reset phy

2021-10-03 Thread Adam Ford
Several omap boards use CONFIG_OMAP_EHCI_PHYx_RESET_GPIO to pull the phy out of reset, when this should really be done inside the phy driver. Add functions to determine which phys are associated the EHCI driver, hold them in reset before EHCI is initialized, initialize the EHCI, then release the

[RFC 2/3] phy: nop-phy: Enable reset-gpios support

2021-10-03 Thread Adam Ford
Some usb-nop-xceiv devices use a gpio to put them in reset. Add a reset function to put them into that state, and have the init function take them out of reset Signed-off-by: Adam Ford diff --git a/drivers/phy/nop-phy.c b/drivers/phy/nop-phy.c index 9f12ebc062..be993a764f 100644 ---

[RFC 1/3] usb: ehci-omap: Remove dead code

2021-10-03 Thread Adam Ford
Since it's expected that DM_USB is enabled by now, remove some dead code and the checks for DM_USB. Signed-off-by: Adam Ford diff --git a/arch/arm/include/asm/ehci-omap.h b/arch/arm/include/asm/ehci-omap.h index f970bba937..2b51b5eb99 100644 --- a/arch/arm/include/asm/ehci-omap.h +++

Re: [PATCH v8 5/5] iot2050: Enable watchdog support, but do not auto-start it

2021-10-03 Thread Tom Rini
On Sat, Sep 18, 2021 at 08:17:56AM +0200, Jan Kiszka wrote: > From: Jan Kiszka > > This allows to use the watchdog in custom scripts but does not enforce > that the OS has to support it as well. > > Signed-off-by: Jan Kiszka Applied to u-boot/next, thanks! -- Tom signature.asc

Re: [PATCH v8 4/5] watchdog: rti_wdt: Add support for loading firmware

2021-10-03 Thread Tom Rini
On Sat, Sep 18, 2021 at 08:17:55AM +0200, Jan Kiszka wrote: > From: Jan Kiszka > > To avoid the need of extra boot scripting on AM65x for loading a > watchdog firmware, add the required rproc init and loading logic for the > first R5F core to the watchdog start handler. In case the R5F cluster

Re: [PATCH v8 2/5] board: siemens: Add support for SIMATIC IOT2050 devices

2021-10-03 Thread Tom Rini
On Sat, Sep 18, 2021 at 08:17:53AM +0200, Jan Kiszka wrote: > From: Jan Kiszka > > This adds support for the IOT2050 Basic and Advanced devices. The Basic > used the dual-core AM6528 GP processor, the Advanced one the AM6548 HS > quad-core version. > > Both variants are booted via a

Re: [PATCH v8 1/5] arm: dts: Add IOT2050 device tree files

2021-10-03 Thread Tom Rini
On Sat, Sep 18, 2021 at 08:17:52AM +0200, Jan Kiszka wrote: > From: Jan Kiszka > > Prepares for the addition of the IOT2050 board which is based on the TI > AM65x. The board comes in four variants, Basic and Advanced, each as > product generation 1 (SR1.0) and 2 (SR2.x), so there are separate

Re: [PATCH 11/11] pci: pcie_layerscape_fixup_common: lx2_board_fix_fdt can be static

2021-10-03 Thread Tom Rini
On Fri, Sep 17, 2021 at 03:11:30PM +0300, Vladimir Oltean wrote: > To avoid W=1 build warnings, declare this function as static, since it > is not used outside of this translation module. > > Signed-off-by: Vladimir Oltean > Reviewed-by: Bin Meng Applied to u-boot/next, thanks! -- Tom

Re: [PATCH 10/11] pci: pcie_layerscape_fixup_common: include fdt_support.h for ft_pci_setup

2021-10-03 Thread Tom Rini
On Fri, Sep 17, 2021 at 03:11:29PM +0300, Vladimir Oltean wrote: > The function prototype for ft_pci_setup is inside fdt_support.h, we need > to include that header. > > Signed-off-by: Vladimir Oltean > Reviewed-by: Bin Meng Applied to u-boot/next, thanks! -- Tom signature.asc

Re: [PATCH 08/11] pci: _dm_pci_phys_to_bus can be static

2021-10-03 Thread Tom Rini
On Fri, Sep 17, 2021 at 03:11:27PM +0300, Vladimir Oltean wrote: > To avoid W=1 build warnings, declare this function as static, since it > is not used outside of this translation module. > > Signed-off-by: Vladimir Oltean > Reviewed-by: Bin Meng Applied to u-boot/next, thanks! -- Tom

Re: [PATCH 09/11] pci: layerscape: ls_pcie_conf_address can be static

2021-10-03 Thread Tom Rini
On Fri, Sep 17, 2021 at 03:11:28PM +0300, Vladimir Oltean wrote: > To avoid W=1 build warnings, declare this function as static, since it > is not used outside of this translation module. > > Signed-off-by: Vladimir Oltean > Reviewed-by: Bin Meng Applied to u-boot/next, thanks! -- Tom

Re: [PATCH 07/11] pci: pci_read_config can be static

2021-10-03 Thread Tom Rini
On Fri, Sep 17, 2021 at 03:11:26PM +0300, Vladimir Oltean wrote: > To avoid W=1 build warnings, declare this function as static, since it > is not used outside of this translation module. > > Signed-off-by: Vladimir Oltean > Reviewed-by: Bin Meng Applied to u-boot/next, thanks! -- Tom

Re: [PATCH 06/11] pci: pci_write_config can be static

2021-10-03 Thread Tom Rini
On Fri, Sep 17, 2021 at 03:11:25PM +0300, Vladimir Oltean wrote: > To avoid W=1 build warnings, declare this function as static, since it > is not used outside of this translation module. > > Signed-off-by: Vladimir Oltean > Reviewed-by: Bin Meng Applied to u-boot/next, thanks! -- Tom

Re: [PATCH 05/11] pci: pciinfo_header can be static

2021-10-03 Thread Tom Rini
On Fri, Sep 17, 2021 at 03:11:24PM +0300, Vladimir Oltean wrote: > To avoid W=1 build warnings, declare this function as static, since it > is not used outside of this translation module. > > Signed-off-by: Vladimir Oltean > Reviewed-by: Bin Meng Applied to u-boot/next, thanks! -- Tom

Re: [PATCH 04/11] pci: pci_header_show can be static

2021-10-03 Thread Tom Rini
On Fri, Sep 17, 2021 at 03:11:23PM +0300, Vladimir Oltean wrote: > To avoid W=1 build warnings, declare this function as static, since it > is not used outside of this translation module. > > Signed-off-by: Vladimir Oltean > Reviewed-by: Bin Meng Applied to u-boot/next, thanks! -- Tom

Re: [PATCH 03/11] pci: pci_bar_show can be static

2021-10-03 Thread Tom Rini
On Fri, Sep 17, 2021 at 03:11:22PM +0300, Vladimir Oltean wrote: > To avoid W=1 build warnings, declare this function as static, since it > is not used outside of this translation module. > > Signed-off-by: Vladimir Oltean > Reviewed-by: Bin Meng Applied to u-boot/next, thanks! -- Tom

Re: [PATCH 02/11] pci: include pci_internal.h inside pci_auto.c

2021-10-03 Thread Tom Rini
On Fri, Sep 17, 2021 at 03:11:21PM +0300, Vladimir Oltean wrote: > To avoid a build warning with W=1, provide a function prototype for > dm_pciauto_prescan_setup_bridge, which is a non-static function whose > definition is inside pci_auto.c. > > Signed-off-by: Vladimir Oltean > Reviewed-by: Bin

Re: [PATCH 01/11] pci: provide prototype for pci_skip_dev outside of #if defined(CONFIG_DM_PCI_COMPAT)

2021-10-03 Thread Tom Rini
On Fri, Sep 17, 2021 at 03:11:20PM +0300, Vladimir Oltean wrote: > The weak definition of pci_skip_dev from drivers/pci/pci_common.c is not > under CONFIG_DM_PCI_COMPAT, and that definition needs a previous > function prototype declaration to avoid W=1 build warnings. > > That prototype is not

Re: [PATCH 4/4] rtc: rx8025: revise single register write to use offset

2021-10-03 Thread Tom Rini
On Fri, Sep 17, 2021 at 06:46:04AM +, Mathew McBride wrote: > Writing of individual registers was not functioning > correctly as a 0 'offset' byte under DM-managed > I2C was being appended in front of register we > wanted to access. > > Signed-off-by: Mathew McBride Applied to u-boot/next,

Re: [PATCH 3/4] rtc: rx8025: set date in a single i2c transaction

2021-10-03 Thread Tom Rini
On Fri, Sep 17, 2021 at 06:46:03AM +, Mathew McBride wrote: > The RX8025/RX8035 does not like having it's time registers > set byte-by-byte in separate I2C transactions. > > From the note at the top of the file, it appears > target-dependent workarounds have been used in the > past for this.

Re: [PATCH 2/4] rtc: rx8025: add support for EPSON RX8035.

2021-10-03 Thread Tom Rini
On Fri, Sep 17, 2021 at 06:46:02AM +, Mathew McBride wrote: > The RX8035 is a newer model from EPSON which is > very similar in operation to the RX8025. > > The changes mirror similar ones that will be > in Linux 5.15: >

Re: [PATCH 1/4] rtc: rx8025: drop non-DM support

2021-10-03 Thread Tom Rini
On Fri, Sep 17, 2021 at 06:46:01AM +, Mathew McBride wrote: > A search of the tree showed there is only one user > of this driver (soon to be two) - board/socrates > > The second user will be the Traverse Ten64 board. > > Both these boards have DM_RTC. > > Signed-off-by: Mathew McBride

Re: [PATCH] ARM: dts: ast2600: Make WDT by default disabled

2021-10-03 Thread Tom Rini
On Thu, Sep 16, 2021 at 02:10:09PM +0800, Chia-Wei Wang wrote: > The WDT devices described in the general .dtsi file > should be marked as "disabled" by default. > > A WDT should be then enabled in the board specific > .dts file on demands. > > Signed-off-by: Chia-Wei Wang > Reviewed-by: Ryan

Re: [PATCH] arm: ti: k3: Resync dts files and bindings with Linux Kernel v5.14

2021-10-03 Thread Tom Rini
On Fri, Sep 10, 2021 at 05:37:43PM -0400, Tom Rini wrote: > This resyncs the dts files for all of the currently in-tree K3 > platforms, along with relevant bindings, with the v5.14 Linux Kernel > release. Of note are that the main-navss/mcu-navss nodes were renamed > to main_navss / mcu_navss

Re: [PATCH] dt-bindings: pinctrl: k3: Synchronize with v5.14 kernel

2021-10-03 Thread Tom Rini
On Tue, Aug 31, 2021 at 01:12:24PM -0500, Nishanth Menon wrote: > Synchronize with the upstream version as of v5.14 kernel tag > > Signed-off-by: Nishanth Menon Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature

Re: [PATCH 1/2] docs: dt: Fix a few grammar nits in the binding/schema docs

2021-10-03 Thread Randy Dunlap
On 10/3/21 11:50 AM, Simon Glass wrote: Add missing hyphens and reword one sentence for clarity. Signed-off-by: Simon Glass --- .../devicetree/bindings/example-schema.yaml | 14 - .../devicetree/bindings/writing-bindings.rst | 2 +- .../devicetree/bindings/writing-schema.rst

[PATCH 2/2] dt-bindings: u-boot: Add an initial binding for config

2021-10-03 Thread Simon Glass
U-Boot makes use of the devicetree for its driver model. Devices are bound based on the hardware description in the devicetree. Since U-Boot is not an operating system, it has no command line or user space to provide configuration and policy information. This must be made available in some other

[PATCH 1/2] docs: dt: Fix a few grammar nits in the binding/schema docs

2021-10-03 Thread Simon Glass
Add missing hyphens and reword one sentence for clarity. Signed-off-by: Simon Glass --- .../devicetree/bindings/example-schema.yaml | 14 - .../devicetree/bindings/writing-bindings.rst | 2 +- .../devicetree/bindings/writing-schema.rst| 29 ++- 3 files changed,

Re: [PATCH v8 3/5] arm64: dts: ti: k3-am65-mcu: Add RTI watchdog entry

2021-10-03 Thread Tom Rini
On Sat, Sep 18, 2021 at 08:17:54AM +0200, Jan Kiszka wrote: > From: Jan Kiszka > > Add the DT entry for a watchdog based on RTI1. It requires additional > firmware on the MCU R5F cores to handle the expiry, e.g. > https://github.com/siemens/k3-rti-wdt. As this firmware will also lock > the

Re: [PATCH next v4 09/11] configs: ast2600-evb: Enable SPL FIT support

2021-10-03 Thread Tom Rini
On Thu, Sep 16, 2021 at 04:52:19PM +0800, Chia-Wei Wang wrote: > Enable SPL FIT image load and verification support. > The HW accelerated SHA is also available with the > newly added support of the HACE HW hash engine. > > The SPL thumb build is also enabled to keep the binary > less than 64KB

[PATCH v2 7/7] doc: board: apple: Add Apple M1 documentation

2021-10-03 Thread Mark Kettenis
Provide preliminary instructions on how to get U-Boot to run on Apple Silicon Macs. Signed-off-by: Mark Kettenis --- doc/board/apple/index.rst | 9 +++ doc/board/apple/m1.rst| 56 +++ doc/board/index.rst | 1 + 3 files changed, 66

[PATCH v2 6/7] arm: dts: apple: Add preliminary device trees

2021-10-03 Thread Mark Kettenis
Add preliminary device trees for the Apple M1 mini (2020) and Apple M1 Macbook Pro 13" (2020). Device tree bindings for the Apple M1 SoC are still being formalized and these device trees will be synchronized with the Linux kernel as needed. These device trees are provided as a reference only as

[PATCH v2 5/7] iommu: Add Apple DART driver

2021-10-03 Thread Mark Kettenis
The DART is an IOMMU that is used on Apple's M1 SoC. This driver configures the DART such that it operates in bypass mode which is enough to support DMA for the USB3 ports integrated on the SoC. Signed-off-by: Mark Kettenis --- arch/arm/Kconfig | 1 + drivers/iommu/Kconfig | 10

[PATCH v2 4/7] serial: s5p: Add Apple M1 support

2021-10-03 Thread Mark Kettenis
Apple M1 SoCs include an S5L UART which is a variant of the S5P UART. Add support for this variant and enable it by default on Apple SoCs. Signed-off-by: Mark Kettenis --- arch/arm/Kconfig| 1 + arch/arm/include/asm/arch-m1/uart.h | 41 +++

[PATCH v2 3/7] arm: apple: Add initial support for Apple's M1 SoC

2021-10-03 Thread Mark Kettenis
Add support for Apple's M1 SoC that is used in "Apple Silicon" Macs. 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. Signed-off-by: Mark Kettenis --- arch/arm/Kconfig| 21 arch/arm/Makefile

[PATCH v2 2/7] test: Add tests for IOMMU uclass

2021-10-03 Thread Mark Kettenis
Add a set of tests for the IOMMU uclass. Signed-off-by: Mark Kettenis --- arch/sandbox/dts/test.dts | 6 ++ configs/sandbox64_defconfig| 1 + configs/sandbox_defconfig | 1 + configs/sandbox_flattree_defconfig | 1 + configs/sandbox_noinst_defconfig | 1 +

[PATCH v2 1/7] iommu: Add IOMMU uclass

2021-10-03 Thread Mark Kettenis
This uclass is intended to manage IOMMUs on systems where the IOMMUs are not in bypass mode by default. In that case U-Boot cannot ignore the IOMMUs if it wants to use devices that need to do DMA and sit behind such an IOMMU. This initial IOMMU uclass implementation does not implement and device

[PATCH v2 0/7] Apple M1 Support

2021-10-03 Thread Mark Kettenis
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 allows booting various open source OSes.

Re: [PATCH v2 6/6] arm: dts: ls1088a: change dwc3 compatible to match dwc3-generic driver

2021-10-03 Thread Michael Walle
> Benefit is, besides host mode, now user can choose device mode with > setting of dr_mode = ?peripheral?; > > Signed-off-by: Ran Wang > --- > Change in v2: > - Remove property 'snps,dis_rxdet_inp3_quirk' due to its side effect to Linux >kernel (USB device no detected) > >

[PATCH] sunxi: Add support for FriendlyARM NanoPi R1S H5

2021-10-03 Thread Chukun Pan
This adds support for the NanoPi R1S H5 board. Allwinner H5 SoC 512MB DDR3 RAM 10/100/1000M Ethernet x 2 RTL8189ETV WiFi 802.11b/g/n USB 2.0 host port (A) MicroSD Slot Reset button Serial Debug Port WAN - LAN - SYS LED The dts file is taken from Linux 5.14 tag, and includes the change to the

[PATCH V2] ARM: omap3_logic: Cleanup usage of MUX_VAL

2021-10-03 Thread Adam Ford
The macro called MUX_VAL generates a writel instruction with semicolon at the end. This table was written to use semicolons, however one was missed: MUX_VAL(CP(SYS_BOOT2), (IEN | PTD | DIS | M4))/* GPIO_4 */ Since the extra semicolon is unnecessary with the use of the macro, remove

[PATCH] arm: mvebu: Select SPL_SKIP_LOWLEVEL_INIT on ARMADA_32BIT

2021-10-03 Thread Stefan Roese
Select SPL_SKIP_LOWLEVEL_INIT on 32bit Armada platforms via Kconfig, as this was removed from mach/config.h in a2ac2b96 ("Convert CONFIG_SKIP_LOWLEVEL_INIT et al to Kconfig"). Signed-off-by: Stefan Roese Fixes: a2ac2b96 ("Convert CONFIG_SKIP_LOWLEVEL_INIT et al to Kconfig") Cc: Tom Rini Cc:

Re: [PATCH u-boot-marvell v3 00/39] kwboot higher baudrate

2021-10-03 Thread Stefan Roese
Hi Tom, On 01.10.21 14:59, Tom Rini wrote: On Fri, Oct 01, 2021 at 01:01:37PM +0200, Stefan Roese wrote: Added to Tom to Cc On 01.10.21 12:43, Stefan Roese wrote: On 01.10.21 12:39, Pali Rohár wrote: Hello! On Friday 01 October 2021 12:28:34 Stefan Roese wrote: First the test on "next"

[PATCH v3 1/4] efi_loader: treat UEFI variable name as const

2021-10-03 Thread Heinrich Schuchardt
UEFI variable names are typically constants and hence should be defined as const. Unfortunately some of our API functions do not define the parameters for UEFI variable names as const. This requires unnecessary conversions. Adjust parameters of several internal functions to tre UEFI variable

[PATCH v3 0/4] efi_loader: centralize known vendor GUIDs

2021-10-03 Thread Heinrich Schuchardt
The UEFI specification defines which vendor GUIDs should be used for predefined variables like 'PK'. Currently we have multiple places where this relationship is stored. With this patch series a function for retrieving the GUID is provided and existing code is adjusted to used it. v3:

[PATCH v3 2/4] efi_loader: function to get GUID for variable name

2021-10-03 Thread Heinrich Schuchardt
In multiple places we need the default GUID matching a variable name. The patch provides a library function. For secure boot related variables like 'PK', 'KEK', 'db' a lookup table is used. For all other variable names EFI_GLOBAL_VARIABLE is returned. Signed-off-by: Heinrich Schuchardt --- v3:

[PATCH v3 4/4] efi_loader: simplify tcg2_measure_secure_boot_variable()

2021-10-03 Thread Heinrich Schuchardt
Don't duplicate GUIDs. Signed-off-by: Heinrich Schuchardt --- v3: no change v2: no change --- lib/efi_loader/efi_tcg2.c | 29 + 1 file changed, 13 insertions(+), 16 deletions(-) diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c index

[PATCH v3 3/4] efi_loader: simplify efi_sigstore_parse_sigdb()

2021-10-03 Thread Heinrich Schuchardt
Simplify efi_sigstore_parse_sigdb() by using existing functions. Signed-off-by: Heinrich Schuchardt --- v3: Keep error handling in efi_sigstore_parse_sigdb() v2: remove a superfluous check --- lib/efi_loader/efi_signature.c | 11 ++- 1 file changed, 2 insertions(+), 9