December 2021 - U-Boot

[PATCH 0/4] gpio: sunxi: Handle pin configuration flags
by Samuel Holland 30 Jan '22

30 Jan '22

This series updates the sunxi GPIO driver to handle pin pull-up/down, so consumer drivers do not need to call the non-DM sunxi_gpio_set_* functions. As an example, the last patch updates the MMC driver to use this functionality. The helpers added here will also be used for the upcoming DM_PINCTRL driver. Samuel Holland (4): sunxi: gpio: Return void from setter functions sunxi: gpio: Add per-bank drive and pull setters gpio: sunxi: Implement .set_flags mmc: sunxi: Use DM_GPIO flags to set pull-up arch/arm/include/asm/arch-sunxi/gpio.h | 6 ++- arch/arm/mach-sunxi/pinmux.c | 28 +++++++----- drivers/gpio/sunxi_gpio.c | 62 +++++++++++--------------- drivers/mmc/sunxi_mmc.c | 8 +--- 4 files changed, 51 insertions(+), 53 deletions(-) -- 2.32.0

5 16

[PATCH] squashfs: Fix sqfsls errors when root is a ldir
by Campbell Suter 29 Jan '22

29 Jan '22

Previously, if root had more than 256 files or otherwise needed to be an ldir, sqfsls would emit the error 'Inode not found.' which was caused by code in sqfs_search_dir assuming it was a regular directory inode. Signed-off-by: Campbell Suter <campbell(a)snapit.group> --- fs/squashfs/sqfs.c | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/fs/squashfs/sqfs.c b/fs/squashfs/sqfs.c index e2d91c654c..4d7bf76fa3 100644 --- a/fs/squashfs/sqfs.c +++ b/fs/squashfs/sqfs.c @@ -482,13 +482,20 @@ static int sqfs_search_dir(struct squashfs_dir_stream *dirs, char **token_list, /* Initialize squashfs_dir_stream members */ dirs->table += SQFS_DIR_HEADER_SIZE; - dirs->size = get_unaligned_le16(&dir->file_size) - SQFS_DIR_HEADER_SIZE; + if (le16_to_cpu(dirs->i_dir.inode_type) == SQFS_DIR_TYPE) + dirs->size = get_unaligned_le16(&dir->file_size); + else + dirs->size = get_unaligned_le32(&ldir->file_size); + dirs->size -= SQFS_DIR_HEADER_SIZE; dirs->entry_count = dirs->dir_header->count + 1; /* No path given -> root directory */ if (!strcmp(token_list[0], "/")) { dirs->table = &dirs->dir_table[offset]; - memcpy(&dirs->i_dir, dir, sizeof(*dir)); + if (le16_to_cpu(dirs->i_dir.inode_type) == SQFS_DIR_TYPE) + memcpy(&dirs->i_dir, dir, sizeof(*dir)); + else + memcpy(&dirs->i_ldir, ldir, sizeof(*ldir)); return 0; } @@ -608,7 +615,10 @@ static int sqfs_search_dir(struct squashfs_dir_stream *dirs, char **token_list, } dirs->table += SQFS_DIR_HEADER_SIZE; - dirs->size = get_unaligned_le16(&dir->file_size); + if (le16_to_cpu(dirs->i_dir.inode_type) == SQFS_DIR_TYPE) + dirs->size = get_unaligned_le16(&dir->file_size); + else + dirs->size = get_unaligned_le32(&ldir->file_size); dirs->entry_count = dirs->dir_header->count + 1; dirs->size -= SQFS_DIR_HEADER_SIZE; free(dirs->entry); -- 2.33.1

3 2

[PATCH 0/4] Add vibration motor support to U-Boot
by Samuel Dionne-Riel 28 Jan '22

28 Jan '22

This series of patch adds support for vibration motors (often called vibrators) to U-Boot. The support adds the necessary plumbing to support SPL usage of vibration motors. This can be used to vibrate the device, like a phone, as early as possible during the boot process. A `vibrator` command allows scripts, or customised boot commands, to vibrate the device. This can be used to provide feedback to the end-user about failure state, or boot stage. An example use case of the command is, in a customized boot command, to signify that an error happend, by synchronizing red LED flashes with a few short vibrations. Samuel Dionne-Riel (4): drivers: Introduce vibrator uclass vibrator: Add vibrator_gpio driver cmd: Add vibrator command pinephone_defconfig: Add gpio vibrator support arch/sandbox/dts/test.dts | 10 ++ cmd/Kconfig | 10 ++ cmd/Makefile | 1 + cmd/vibrator.c | 148 +++++++++++++++++++++++++++++ configs/pinephone_defconfig | 2 + configs/sandbox_defconfig | 2 + drivers/Kconfig | 2 + drivers/Makefile | 1 + drivers/vibrator/Kconfig | 37 ++++++++ drivers/vibrator/Makefile | 6 ++ drivers/vibrator/vibrator-uclass.c | 62 ++++++++++++ drivers/vibrator/vibrator_gpio.c | 122 ++++++++++++++++++++++++ include/dm/uclass-id.h | 1 + include/vibrator.h | 87 +++++++++++++++++ test/dm/Makefile | 1 + test/dm/vibrator.c | 97 +++++++++++++++++++ 16 files changed, 589 insertions(+) create mode 100644 cmd/vibrator.c create mode 100644 drivers/vibrator/Kconfig create mode 100644 drivers/vibrator/Makefile create mode 100644 drivers/vibrator/vibrator-uclass.c create mode 100644 drivers/vibrator/vibrator_gpio.c create mode 100644 include/vibrator.h create mode 100644 test/dm/vibrator.c -- 2.34.0

3 8

[PATCH] fastboot: only look up real partition names when no alias exists
by Matthias Schiffer 28 Jan '22

28 Jan '22

Having U-Boot look up the passed partition name even though an alias exists is unexpected, leading to warning messages (when the alias name doesn't exist as a real partition name) or the use of the wrong partition. Change part_get_info_by_name_or_alias() to consider real partitions names only if no alias of the same name exists, allowing to use aliases to override the configuration for existing partition names. Also change one use of strcpy() to strlcpy(). Signed-off-by: Matthias Schiffer <matthias.schiffer(a)ew.tq-group.com> --- drivers/fastboot/fb_mmc.c | 29 ++++++++++++----------------- 1 file changed, 12 insertions(+), 17 deletions(-) diff --git a/drivers/fastboot/fb_mmc.c b/drivers/fastboot/fb_mmc.c index 2738dc836e..fb7791d9da 100644 --- a/drivers/fastboot/fb_mmc.c +++ b/drivers/fastboot/fb_mmc.c @@ -104,23 +104,18 @@ static int part_get_info_by_name_or_alias(struct blk_desc **dev_desc, const char *name, struct disk_partition *info) { - int ret; - - ret = do_get_part_info(dev_desc, name, info); - if (ret < 0) { - /* strlen("fastboot_partition_alias_") + PART_NAME_LEN + 1 */ - char env_alias_name[25 + PART_NAME_LEN + 1]; - char *aliased_part_name; - - /* check for alias */ - strcpy(env_alias_name, "fastboot_partition_alias_"); - 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, - info); - } - return ret; + /* strlen("fastboot_partition_alias_") + PART_NAME_LEN + 1 */ + char env_alias_name[25 + PART_NAME_LEN + 1]; + char *aliased_part_name; + + /* check for alias */ + strlcpy(env_alias_name, "fastboot_partition_alias_", sizeof(env_alias_name)); + strlcat(env_alias_name, name, sizeof(env_alias_name)); + aliased_part_name = env_get(env_alias_name); + if (aliased_part_name) + name = aliased_part_name; + + return do_get_part_info(dev_desc, name, info); } /** -- 2.25.1

3 5

[PATCH] dfu: handle short frame result of UPLOAD in state_dfu_idle
by Patrick Delaunay 28 Jan '22

28 Jan '22

In DFU v1.1 specification [1] the DFU_UPLOAD (Short Frame) is handled only in dfuUPLOADIDLE state: - Figure A.1 Interface state transition diagram - the state description in chapter A.2 A.2.3 State 2 dfuIDLE on Receipt of the DFU_UPLOAD request,and bitCanUpload = 1 the Next State is dfuUPLOADIDLE A.2.10 State 9 dfuUPLOAD-IDLE When the length of the data transferred by the device in response to a DFU_UPLOAD request is less than wLength. (Short frame) the Next State is dfuIDLE In current code, when an UPLOAD is completely performed after the first request (for example with wLength=200 and data read = 9), the DFU state stay at dfuUPLOADIDLE until receiving a DFU_UPLOAD or a DFU_ABORT request even it is unnecessary as the previous DFU_UPLOAD request already reached the EOF. This patch proposes to finish the DFU uploading (don't go to dfuUPLOADIDLE) and completes the control-read operation (go to DFU_STATE_dfuIDLE) when the first UPLOAD response has a short frame as an end of file (EOF) indicator even if it is not explicitly allowed in the DFU specification but this seems logical. [1] https://www.usb.org/sites/default/files/DFU_1.1.pdf Signed-off-by: Patrick Delaunay <patrick.delaunay(a)foss.st.com> --- Hi Lukasz, This case is correctly handle in dfu-util, see dfu_load.c dfuload_do_upload() { .... while (1) { ... rc = dfu_upload(dif->dev_handle, dif->interface, xfer_size, transaction++, buf); .... dfu_file_write_crc(fd, 0, buf, rc); total_bytes += rc; if (total_bytes < 0) errx(EX_SOFTWARE, "\nReceived too many bytes (wraparound)"); if (rc < xfer_size) { /* last block, return */ ret = 0; break; } } } In the upload loop the code doesn't make difference for the first request and the next one: the last block is detected as soon as the received data < requested size. So it is safe to do the same in U-Boot's DFU stack, skip the dfuUPLOADIDLE state when the upload operation is finished after the first request. This patch avoid to ABORT the unfinished UPLOAD request before the next command. This patch was previously sent as RFC = [RFC] dfu: handle short frame result of UPLOAD in state_dfu_idle http://patchwork.ozlabs.org/project/uboot/list/?series=248838&state=* Patrick. drivers/usb/gadget/f_dfu.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/gadget/f_dfu.c b/drivers/usb/gadget/f_dfu.c index 4bedc7d3a1..e9340ff5cb 100644 --- a/drivers/usb/gadget/f_dfu.c +++ b/drivers/usb/gadget/f_dfu.c @@ -336,6 +336,8 @@ static int state_dfu_idle(struct f_dfu *f_dfu, f_dfu->dfu_state = DFU_STATE_dfuUPLOAD_IDLE; f_dfu->blk_seq_num = 0; value = handle_upload(req, len); + if (value >= 0 && value < len) + f_dfu->dfu_state = DFU_STATE_dfuIDLE; break; case USB_REQ_DFU_ABORT: /* no zlp? */ -- 2.25.1

2 1

[PATCH] fastboot: fix fastboot_set_reboot_flag()
by Roman Stratiienko 28 Jan '22

28 Jan '22

In case CONFIG_FASTBOOT_FLASH_MMC_DEV == 0, compile-time condition is not met and fastboot_set_reboot_flag() fails. Fixes: a362ce214f03 ("fastboot: Implement generic fastboot_set_reboot_flag") Signed-off-by: Roman Stratiienko <r.stratiienko(a)gmail.com> --- drivers/fastboot/fb_common.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/fastboot/fb_common.c b/drivers/fastboot/fb_common.c index cbcc3683c47..ef399d0c4ab 100644 --- a/drivers/fastboot/fb_common.c +++ b/drivers/fastboot/fb_common.c @@ -91,7 +91,7 @@ void fastboot_okay(const char *reason, char *response) */ int __weak fastboot_set_reboot_flag(enum fastboot_reboot_reason reason) { -#if CONFIG_IS_ENABLED(FASTBOOT_FLASH_MMC_DEV) +#ifdef CONFIG_FASTBOOT_FLASH_MMC_DEV static const char * const boot_cmds[] = { [FASTBOOT_REBOOT_REASON_BOOTLOADER] = "bootonce-bootloader", [FASTBOOT_REBOOT_REASON_FASTBOOTD] = "boot-fastboot", -- 2.27.0

4 3

[PATCH 1/3] dfu: use pointer to pass length to dfu_write()
by Frieder Schrempf 28 Jan '22

28 Jan '22

From: Frieder Schrempf <frieder.schrempf(a)kontron.de> This doesn't include any functional changes, but allows us to use the size parameter to report the actual written bytes back to the caller. This is useful in cases of unaligned writes to serial flash where the first write covers only a part of the buffer (until the next sector boundary) and the remaining bytes need to be written in a further call to dfu_write(). While at it, we also adjust the data type of the 'write' and 'left' variable in dfu_write_from_mem_addr() to match the values passed. Signed-off-by: Frieder Schrempf <frieder.schrempf(a)kontron.de> --- drivers/dfu/dfu.c | 23 ++++++++++++----------- include/dfu.h | 2 +- 2 files changed, 13 insertions(+), 12 deletions(-) diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c index ff1859d946..5b2659ee7d 100644 --- a/drivers/dfu/dfu.c +++ b/drivers/dfu/dfu.c @@ -334,12 +334,12 @@ int dfu_flush(struct dfu_entity *dfu, void *buf, int size, int blk_seq_num) return ret; } -int dfu_write(struct dfu_entity *dfu, void *buf, int size, int blk_seq_num) +int dfu_write(struct dfu_entity *dfu, void *buf, int *size, int blk_seq_num) { int ret; debug("%s: name: %s buf: 0x%p size: 0x%x p_num: 0x%x offset: 0x%llx bufoffset: 0x%lx\n", - __func__, dfu->name, buf, size, blk_seq_num, dfu->offset, + __func__, dfu->name, buf, *size, blk_seq_num, dfu->offset, (unsigned long)(dfu->i_buf - dfu->i_buf_start)); ret = dfu_transaction_initiate(dfu, false); @@ -371,7 +371,7 @@ int dfu_write(struct dfu_entity *dfu, void *buf, int size, int blk_seq_num) dfu->i_blk_seq_num = (dfu->i_blk_seq_num + 1) & 0xffff; /* flush buffer if overflow */ - if ((dfu->i_buf + size) > dfu->i_buf_end) { + if ((dfu->i_buf + *size) > dfu->i_buf_end) { ret = dfu_write_buffer_drain(dfu); if (ret) { dfu_transaction_cleanup(dfu); @@ -381,19 +381,19 @@ int dfu_write(struct dfu_entity *dfu, void *buf, int size, int blk_seq_num) } /* we should be in buffer now (if not then size too large) */ - if ((dfu->i_buf + size) > dfu->i_buf_end) { + if ((dfu->i_buf + *size) > dfu->i_buf_end) { pr_err("Buffer overflow! (0x%p + 0x%x > 0x%p)\n", dfu->i_buf, - size, dfu->i_buf_end); + *size, dfu->i_buf_end); dfu_transaction_cleanup(dfu); dfu_error_callback(dfu, "Buffer overflow"); return -1; } - memcpy(dfu->i_buf, buf, size); - dfu->i_buf += size; + memcpy(dfu->i_buf, buf, *size); + dfu->i_buf += *size; /* if end or if buffer full flush */ - if (size == 0 || (dfu->i_buf + size) > dfu->i_buf_end) { + if (*size == 0 || (dfu->i_buf + *size) > dfu->i_buf_end) { ret = dfu_write_buffer_drain(dfu); if (ret) { dfu_transaction_cleanup(dfu); @@ -704,7 +704,8 @@ int dfu_get_alt(char *name) int dfu_write_from_mem_addr(struct dfu_entity *dfu, void *buf, int size) { - unsigned long dfu_buf_size, write, left = size; + unsigned int write, left = size; + unsigned long dfu_buf_size; int i, ret = 0; void *dp = buf; @@ -720,9 +721,9 @@ int dfu_write_from_mem_addr(struct dfu_entity *dfu, void *buf, int size) for (i = 0; left > 0; i++) { write = min(dfu_buf_size, left); - debug("%s: dp: 0x%p left: %lu write: %lu\n", __func__, + debug("%s: dp: 0x%p left: %lu write: %u\n", __func__, dp, left, write); - ret = dfu_write(dfu, dp, write, i); + ret = dfu_write(dfu, dp, &write, i); if (ret) { pr_err("DFU write failed\n"); return ret; diff --git a/include/dfu.h b/include/dfu.h index f6868982df..2df55e507e 100644 --- a/include/dfu.h +++ b/include/dfu.h @@ -335,7 +335,7 @@ int dfu_read(struct dfu_entity *de, void *buf, int size, int blk_seq_num); * @blk_seq_num: block sequence number * Return: 0 for success, -1 for error */ -int dfu_write(struct dfu_entity *de, void *buf, int size, int blk_seq_num); +int dfu_write(struct dfu_entity *de, void *buf, int *size, int blk_seq_num); /** * dfu_flush() - flush to dfu entity -- 2.33.0

2 3

[RFC v2 00/20] efi_loader: more tightly integrate UEFI disks to driver model
by AKASHI Takahiro 28 Jan '22

28 Jan '22

# This is a kind of snapshot of my current work. # I submit this to show my progress on this effort, and then # I haven't addressed all the issues in this version. # See the change history below. The purpose of this RPC is to reignite the discussion about how UEFI subystem would best be integrated into U-Boot driver model. In the past, I poposed a couple of patch series, the latest one[1], while Heinrich revealed his idea[2], and the approach taken here is something between them, with a focus on block device handlings. # The code is a PoC and not well tested yet. Disks in UEFI world: ==================== In general in UEFI world, accessing to any device is performed through a 'protocol' interface which are installed to (or associated with) the device's UEFI handle (or an opaque pointer to UEFI object data). Protocols are implemented by either the UEFI system itself or UEFI drivers. For block IO's, it is a device which has EFI_BLOCK_IO_PROTOCOL (efi_disk hereafter). Currently, every efi_disk may have one of two origins: a.U-Boot's block devices or related partitions (lib/efi_loader/efi_disk.c) b.UEFI objects which are implemented as a block device by UEFI drivers. (lib/efi_driver/efi_block_device.c) All the efi_diskss as (a) will be enumelated and created only once at UEFI subsystem initialization (efi_disk_register()), which is triggered by first executing one of UEFI-related U-Boot commands, like "bootefi", "setenv -e" or "efidebug". EFI_BLOCK_IO_PROTOCOL is implemented by UEFI system using blk_desc(->ops) in the corresponding udevice(UCLASS_BLK). On the other hand, efi_disk as (b) will be created each time UEFI boot services' connect_controller() is executed in UEFI app which, as a (device) controller, gives the method to access the device's data, ie. EFI_BLOCK_IO_PROTOCOL. >>> more details >>> Internally, connect_controller() search for UEFI driver that can support this controller/protocol, 'efi_block' driver(UCLASS_EFI) in this case, then calls the driver's 'bind' interface, which eventually installs the controller's EFI_BLOCK_IO_PROTOCOL to efi_disk object. 'efi_block' driver also create a corresponding udevice(UCLASS_BLK) for * creating additional partitions efi_disk's, and * supporting a file system (EFI_SIMPLE_FILE_SYSTEM_PROTOCOL) on it. <<< <<< Issues: ======= 1. While an efi_disk represents a device equally for either a whole disk or a partition in UEFI world, the driver model treats only a whole disk as a real block device or udevice(UCLASS_BLK). 2. efi_disk holds and makes use of "blk_desc" data even though blk_desc in plat_data is supposed to be private and not to be accessed outside the driver model. # This issue, though, exists for all the implmenetation of U-Boot # file systems as well. For efi_disk(a), 3. A block device can be enumelated dynamically by 'scanning' a device bus in U-Boot, but UEFI subsystem is not able to update efi_disks accordingly. For examples, => scsi rescan; efidebug devices => usb start; efidebug devices ... (A) (A) doesn't show any usb devices detected. => scsi rescan; efidebug boot add -b 0 TEST scsi 0:1 ... => scsi rescan ... (B) => bootefi bootmgr ... (C) (C) may de-reference a bogus blk_desc pointer which has been freed by (B). (Please note that "scsi rescan" removes all udevices/blk_desc and then re-create them even if nothing is changed on a bus.) For efi_disk(b), 4. A "controller (handle)", combined with efi_block driver, has no corresponding udevice as a parent of efi_disks in DM tree, unlike, say, a scsi controller, even though it provides methods for block io operations. 5. There is no way supported to remove efi_disk's even after disconnect_controller() is called. My approach in this RFC: ======================== Due to functional differences in semantics, it would be difficult to identify "udevice" structure as a handle in UEFI world. Instead, we will have to somehow maintain a relationship between a udevice and a handle. 1-1. add a dedicated uclass, UCLASS_PARTITION, for partitions Currently, the uclass for paritions is not a UCLASS_BLK. It can be possible to define partitions as UCLASS_BLK (with IF_TYPE_PARTION?), but I'm afraid that it may introduce some chaos since udevice(UCLASS_BLK) is tightly coupled with 'struct blk_desc' data which is still used as a "structure to a whole disk" in a lot of interfaces. (I hope that you understand what it means.) In DM tree, a UCLASS_PARTITON instance has a UCLASS_BLK parent: For instance, UCLASS_SCSI --- UCLASS_BLK --- UCLASS_PARTITION (IF_TYPE_SCSI) | +- struct blk_desc +- struct disk_part +- scsi_blk_ops +- blk_part_ops 1-2. create partition udevices in the context of device_probe() part_init() is already called in blk_post_probe(). See the commit d0851c893706 ("blk: Call part_init() in the post_probe() method"). Why not enumelate partitions as well in there. 2. add new block access interfaces, which takes a *udevice* as a target device, in U-Boot and use those functions to implement efi_disk operations (i.e. EFI_BLOCK_IO_PROTOCOL). 3-1. maintain a bi-directional link between a udevice and an efi_disk by adding - a UEFI handle pointer as a tag for a udevice - a udevice pointer in UEFI handle (in fact, in "struct efi_disk_obj") 3-2. synchronize the lifetime of efi_disk objects in UEFI world with the driver model using - event notification associated with device's probe/remove. 4. I have no answer to issue(4) and (5) yet. Patchs: ======= For easy understandings, patches may be categorized into seperate groups of changes. Patch#1-#10: DM: add device_probe() for later use of events Patch#11-#12: DM: add new features (tag and event notification) Patch#13-#16: UEFI: dynamically create/remove efi_disk's for a raw disk and its partitions For removal case, we may need more consideration since removing handles unconditionally may end up breaking integrity of handles (as some may still be held and referenced to by a UEFI app). Patch#17-#18: UEFI: use udevice read/write interfaces Patch#19-#20: UEFI: fix-up efi_driver, aligning with changes in DM integration [1] https://lists.denx.de/pipermail/u-boot/2019-February/357923.html [2] https://lists.denx.de/pipermail/u-boot/2021-June/452297.html Change history: =============== RFCv2 (Dec 10, 2021) * rebased on 2022-rc3 * re-order and merge some related commits into ones * call device_probe() in MMC (not bind, but) probe hook (patch#5) * fix a wrong name of variable (patch#7) * add patch#9 * invoke device_probe() for virtio devices (patch#10) * add DM event notitication (from Simon) (patch#11) * add DM tag support (patch#12) * move UCLASS_PARTITION driver under disk/ (patch#13) * create partition's dp using its parent's. This change is necessary in particular for 'efi_blk' efi_disk (patch#13) * modify the code so that we will use new features like tags and event notification (patch#13,15,16,20) * rename new functions from blk_read/write() to dev_read/write() (patch#17,18) * isolate changes in efi_driver from the rest (in efi_loader) (patch#19) * drop the previous patch#22 ("efi_selftest: block device: adjust dp for a test") due to the fix in patch#13 RFC (Nov 16, 2021) * initial RFC AKASHI Takahiro (19): part: call part_init() in blk_get_device_by_str() only for MMC blk: add a helper function, blk_probe_or_unbind() scsi: call device_probe() after scanning usb: storage: call device_probe() after scanning mmc: call device_probe() after scanning nvme: call device_probe() after scanning sata: call device_probe() after scanning block: ide: call device_probe() after scanning dm: fix an 'undefined' error in some macros virtio: call device_probe() in scanning dm: add tag support dm: disk: add UCLASS_PARTITION dm: blk: add a device-probe hook for scanning disk partitions efi_loader: disk: a helper function to create efi_disk objects from udevice efi_loader: disk: a helper function to delete efi_disk objects dm: disk: add read/write interfaces with udevice efi_loader: disk: use udevice instead of blk_desc efi_loader: disk: not create BLK device for BLK(IF_TYPE_EFI) devices efi_driver: align with efi_disk-dm integration Simon Glass (1): dm: add event notification cmd/virtio.c | 21 +- common/Kconfig | 11 + common/Makefile | 2 + common/board_f.c | 2 + common/event.c | 103 ++++++++++ common/log.c | 1 + common/usb_storage.c | 4 + disk/Makefile | 3 + disk/disk-uclass.c | 249 ++++++++++++++++++++++ disk/part.c | 3 +- drivers/ata/dwc_ahsata.c | 5 + drivers/ata/fsl_sata.c | 11 + drivers/ata/sata_mv.c | 5 + drivers/ata/sata_sil.c | 12 ++ drivers/block/blk-uclass.c | 17 ++ drivers/block/ide.c | 4 + drivers/core/Makefile | 2 +- drivers/core/device-remove.c | 9 + drivers/core/device.c | 9 + drivers/core/tag.c | 162 +++++++++++++++ drivers/mmc/mmc-uclass.c | 13 ++ drivers/nvme/nvme.c | 4 + drivers/scsi/scsi.c | 5 + include/asm-generic/global_data.h | 3 + include/blk.h | 12 ++ include/dm/device-internal.h | 10 + include/dm/device.h | 8 +- include/dm/tag.h | 76 +++++++ include/dm/uclass-id.h | 1 + include/efi_loader.h | 4 +- include/event.h | 105 ++++++++++ include/event_internal.h | 34 +++ include/log.h | 2 + include/part.h | 18 ++ lib/efi_driver/efi_block_device.c | 34 +-- lib/efi_loader/Kconfig | 2 + lib/efi_loader/efi_disk.c | 329 ++++++++++++++++++++++-------- lib/efi_loader/efi_setup.c | 11 +- test/common/Makefile | 1 + test/common/event.c | 87 ++++++++ test/test-main.c | 5 + 41 files changed, 1274 insertions(+), 125 deletions(-) create mode 100644 common/event.c create mode 100644 disk/disk-uclass.c create mode 100644 drivers/core/tag.c create mode 100644 include/dm/tag.h create mode 100644 include/event.h create mode 100644 include/event_internal.h create mode 100644 test/common/event.c -- 2.33.0

5 50

[RFC PATCH v3 0/5] imx8m: move env_get_location for imx8mn and imx8mp at board level
by Tommaso Merciai 27 Jan '22

27 Jan '22

This series move env_get_location from soc to board level. As suggested by Michael <michael(a)amarulasolutions.com> make no sense to define an unique way for multiple board. One board can boot from emmc and having env on spi flash etc.. Anyways, this function is kept in imx8mn_evk, imx8mp_evk, phycore-imx8mp and imx8mn_beacon boards instead of being completely dropped. Tommaso Merciai (5): imx8m: drop env_get_location for imx8mn and imx8mp imx: imx8mn_evk: override env_get_location imx: imx8mp_evk: override env_get_location beacon: imx8mn: override env_get_location in imx8mn_beacon.c phytec: phycore_imx8mp: override env_get_location in phycore-imx8mp.c arch/arm/mach-imx/imx8m/soc.c | 39 -------------------- board/beacon/imx8mn/imx8mn_beacon.c | 35 +++++++++++++++++- board/freescale/imx8mn_evk/imx8mn_evk.c | 35 ++++++++++++++++++ board/freescale/imx8mp_evk/imx8mp_evk.c | 34 +++++++++++++++++ board/phytec/phycore_imx8mp/phycore-imx8mp.c | 33 +++++++++++++++++ 5 files changed, 136 insertions(+), 40 deletions(-) -- 2.25.1

4 21

[PATCH 0/8 v7] TPM cleanups and MMIO driver
by Ilias Apalodimas 27 Jan '22

27 Jan '22

Hi! This is the update for [1]. Changes since v6: - added a few missing @return in function documentation - switched TPM1_ defines to TPM_INFINEON_ Changes since v5: - Fixed 2 tpmv1.2 drivers. Some of the internal driver functions were conflicting with the new API Changes since v4: - renamed struct udevice *udev -> struct udevice *dev - added comments on struct tpm_tis_phy_ops - removed duplicate defines from tpm2_tis_spi driver (now in tpm_tis.h) - moved API function description for the .c to the .h file - added Reviewed-by tags from Simon and Heinrich Changes since v3: - Coverted SPI TPM to use the API as well - moved some log_info to log_debug - Added documentation on how to run QEMU and enabled TPM by default o arm qemu builds Changes since v2: - Add myself as a maintainer on TPM drivers Changes since v1: - split off the tis core code into a different file Ilias Apalodimas (6): tpm2: Introduce TIS tpm core tpm2: Add a TPMv2 MMIO TIS driver tpm: Use the new API on tpm2 spi driver configs: Enable tpmv2 mmio on qemu for arm/arm64 doc: qemu: Add instructions for swtpm usage MAINTAINERS: Add entry for TPM drivers [1] https://lore.kernel.org/u-boot/20211107213312.263357-1-ilias.apalodimas@lin… Ilias Apalodimas (8): tpm: refactor function names and macros for infineon v1.2 TPM tpm: refactor function names for LPC based TPMs tpm2: Introduce TIS tpm core tpm2: Add a TPMv2 MMIO TIS driver tpm: Use the new API on tpm2 spi driver configs: Enable tpmv2 mmio on qemu for arm/arm64 doc: qemu: Add instructions for swtpm usage MAINTAINERS: Add entry for TPM drivers MAINTAINERS | 5 + configs/qemu_arm64_defconfig | 2 + configs/qemu_arm_defconfig | 2 + doc/board/emulation/qemu-arm.rst | 25 ++ drivers/tpm/Kconfig | 9 + drivers/tpm/Makefile | 3 +- drivers/tpm/tpm2_tis_core.c | 463 +++++++++++++++++++++++++++++++ drivers/tpm/tpm2_tis_mmio.c | 157 +++++++++++ drivers/tpm/tpm2_tis_spi.c | 447 +++-------------------------- drivers/tpm/tpm_tis.h | 136 +++++++++ drivers/tpm/tpm_tis_infineon.c | 34 +-- drivers/tpm/tpm_tis_lpc.c | 4 +- include/tpm-v2.h | 1 + 13 files changed, 852 insertions(+), 436 deletions(-) create mode 100644 drivers/tpm/tpm2_tis_core.c create mode 100644 drivers/tpm/tpm2_tis_mmio.c -- 2.33.1

3 15