u-boot.git/common, branch v2023.01-rc1

Merge tag 'efi-2023-01-rc1-4' of https://source.denx.de/u-boot/custodians/u-boot-efi

2022-11-06T12:51:44Z

Pull request for efi-2023-01-rc1-4 Documentation: * Provide a document about security issue handling. UEFI: * Let networking support depend on NETDEVICES. * Discover if no efi_system_partition is set. Other: * MAINTAINERS: add arch/arm/lib/*_efi.* to EFI_PAYLOAD.

efi_loader: remove CONFIG_EFI_SETUP_EARLY

2022-11-06T09:50:04Z

Since the commit a9bf024b2933 ("efi_loader: disk: a helper function to create efi_disk objects from udevice"), CONFIG_EFI_SETUP_EARLY option is by default on and will never be turned off. So just remove this option. Signed-off-by: AKASHI Takahiro Reviewed-by: Heinrich Schuchardt Reviewed-by: Ilias Apalodimas

Merge https://source.denx.de/u-boot/custodians/u-boot-usb

2022-11-04T15:19:58Z

- 3 important fixes

usb: storage: continue probe on "Invalid device"

2022-11-04T11:22:45Z

Fixes a crash during probing of sd card readers without medium present. Seen with the device below but reported for many other devices. idVendor 0x0bda Realtek Semiconductor Corp. idProduct 0x0326 Card reader bcdDevice 11.24 iManufacturer 1 Realtek iProduct 2 USB3.0 Card Reader iSerial 3 201404081410 Link: https://github.com/AsahiLinux/linux/issues/44 Link: https://lists.denx.de/pipermail/u-boot/2022-July/489717.html Signed-off-by: Janne Grunau Reviewed-by: Simon Glass Reviewed-by: Marek Vasut

usb: Add 1ms delay after first Get Descriptor request

2022-11-03T22:36:48Z

Logitech Unifying Receiver 046d:c52b bcdDevice 12.10 seems sensitive about the first Get Descriptor request. If there are any other requests in the same microframe, the device reports bogus data, first of the descriptor parts is not sent to the host. Wait over one microframe duration before issuing subsequent requests to avoid probe failure with this device, since it can be used to connect USB keyboards. Signed-off-by: Marek Vasut Tested-by: Janne Grunau

mips: mtmips: spl/Kconfig: Set CONFIG_SPL_PAD_TO to 0x0 for ARCH_MTMIPS

2022-11-02T20:54:26Z

It was noticed that while converting CONFIG_SPL_PAD_TO to Kconfig its value for the MIPS MT762x/8x targets got not ported correctly. Its default is not 0x10000 instead of 0x0. This patch fixes this issue. Fixes: ca8a329a1b7f ("Convert CONFIG_SPL_PAD_TO et al to Kconfig") Signed-off-by: Stefan Roese Cc: Ruben Winters Cc: Weijie Gao Cc: Daniel Schwierzeck Cc: Tom Rini

cyclic: get rid of cyclic_init()

2022-11-02T07:42:03Z

Currently, we must call cyclic_init() at some point before cyclic_register() becomes possible. That turns out to be somewhat awkward, especially with SPL, and has resulted in a watchdog callback not being registered, thus causing the board to prematurely reset. We already rely on gd->cyclic reliably being set to NULL by the asm code that clears all of gd. Now that the cyclic list is a hlist, and thus an empty list is represented by a NULL head pointer, and struct cyclic_drv has no other members, we can just as well drop a level of indirection and put the hlist_head directly in struct global_data. This doesn't increase the size of struct global_data, gets rid of an early malloc(), and generates slightly smaller code. But primarily, this avoids having to call cyclic_init() early; the cyclic infrastructure is simply ready to register callbacks as soon as we enter C code. We can still end up with schedule() being called from asm very early, so we still need to check that gd itself has been properly initialized [*], but once it has, gd->cyclic_list is perfectly fine to access, and will just be an empty list. As for cyclic_uninit(), it was never really the opposite of cyclic_init() since it didn't free the struct cyclic_drv nor set gd->cyclic to NULL. Rename it to cyclic_unregister_all() and use that in test/, and also insert a call at the end of the board_init_f sequence so that gd->cyclic_list is a fresh empty list before we enter board_init_r(). A small piece of ugliness is that I had to add a cast in cyclic_get_list() to silence a "discards 'volatile' qualifier" warning, but that is completely equivalent to the existing handling of the uclass_root_s list_head member. [*] I'm not really sure where we guarantee that the register used for gd contains 0 until it gets explicitly initialized, but that must be the case, otherwise testing gd for being NULL would not make much sense. Signed-off-by: Rasmus Villemoes Reviewed-by: Stefan Roese Tested-by: Stefan Roese Tested-by: Tim Harvey # imx8mm-venice-*

cyclic: switch to using hlist instead of list

2022-11-02T07:41:55Z

A hlist is headed by just a single pointer, so can only be traversed forwards, and insertions can only happen at the head (or before/after an existing list member). But each list node still consists of two pointers, so arbitrary elements can still be removed in O(1). This is precisely what we need for the cyclic_list - we never need to traverse it backwards, and the order the callbacks appear in the list should really not matter. One advantage, and the main reason for doing this switch, is that an empty list is represented by a NULL head pointer, so unlike a list_head, it does not need separate C code to initialize - a memset(,0,) of the containing structure is sufficient. This is mostly mechanical: - The iterators are updated with an h prefix, and the type of the temporary variable changed to struct hlist_node*. - Adding/removing is now just hlist_add_head (and not tail) and hlist_del(). - struct members and function return values updated. Signed-off-by: Rasmus Villemoes Reviewed-by: Stefan Roese Tested-by: Stefan Roese Tested-by: Tim Harvey # imx8mm-venice-*

cyclic: drop redundant cyclic_ready flag

2022-11-02T07:41:42Z

We're already relying on gd->cyclic being NULL before cyclic_init() is called - i.e., we're relying on all of gd being zeroed before entering any C code. And when we do populate gd->cyclic, its ->cyclic_ready member is automatically set to true. So we can actually just rely on testing gd->cyclic itself. The only wrinkle is that cyclic_uninit() actually did set ->cyclic_ready to false. However, since it doesn't free gd->cyclic, the cyclic infrastructure is actually still ready (i.e., the list_head is properly initialized as an empty list). Signed-off-by: Rasmus Villemoes Reviewed-by: Stefan Roese Tested-by: Stefan Roese Tested-by: Tim Harvey # imx8mm-venice-*

cyclic: use a flag in gd->flags for recursion protection

2022-11-02T07:41:20Z

As a preparation for future patches, use a flag in gd->flags rather than a separate member in (the singleton) struct cyclic_drv to keep track of whether we're already inside cyclic_run(). Signed-off-by: Rasmus Villemoes Reviewed-by: Stefan Roese Tested-by: Stefan Roese Tested-by: Tim Harvey # imx8mm-venice-*