Re: [PATCH v2 5/5] arm: apple: Do not list bootflows on boot

2024-04-18 Thread Neal Gompa
On Thu, Apr 18, 2024 at 3:00 PM Janne Grunau via B4 Relay
 wrote:
>
> From: Janne Grunau 
>
> The bootflow list is only seen briefly and is probably more confusing
> than helpful.
>
> Signed-off-by: Janne Grunau 
> ---
>  configs/apple_m1_defconfig | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/configs/apple_m1_defconfig b/configs/apple_m1_defconfig
> index c30aec7c55..4eac1a9e2d 100644
> --- a/configs/apple_m1_defconfig
> +++ b/configs/apple_m1_defconfig
> @@ -8,6 +8,7 @@ CONFIG_SYS_CBSIZE=256
>  CONFIG_SYS_PBSIZE=276
>  # CONFIG_DISPLAY_CPUINFO is not set
>  CONFIG_DISPLAY_BOARDINFO_LATE=y
> +CONFIG_BOOTCOMMAND="bootflow scan -b"
>  CONFIG_BOARD_LATE_INIT=y
>  CONFIG_CMD_SELECT_FONT=y
>  # CONFIG_NET is not set
>
> --
> 2.44.0
>

Reviewed-by: Neal Gompa 


-- 
真実はいつも一つ!/ Always, there's only one truth!


Re: [PATCH v2 4/5] arm: apple: Switch to standard boot

2024-04-18 Thread Neal Gompa
On Thu, Apr 18, 2024 at 3:00 PM Janne Grunau via B4 Relay
 wrote:
>
> From: Janne Grunau 
>
> Use standard boot instead of the distro boot scripts. Use
> BOOTSTD_FULL instead of BOOTSTD_DEFAULTS for easier interactive use.
>
> Signed-off-by: Janne Grunau 
> ---
>  arch/arm/Kconfig|  2 +-
>  include/configs/apple.h | 20 ++--
>  2 files changed, 3 insertions(+), 19 deletions(-)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 01d6556c42..9b83b2e6f8 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1034,7 +1034,7 @@ config ARCH_APPLE
> select USB
> imply CMD_DM
> imply CMD_GPT
> -   imply DISTRO_DEFAULTS
> +   imply BOOTSTD_FULL
> imply OF_HAS_PRIOR_STAGE
>
>  config ARCH_OWL
> diff --git a/include/configs/apple.h b/include/configs/apple.h
> index a70440b3ad..1e08b11448 100644
> --- a/include/configs/apple.h
> +++ b/include/configs/apple.h
> @@ -9,26 +9,10 @@
> "stdout=vidconsole,serial\0" \
> "stderr=vidconsole,serial\0"
>
> -#if IS_ENABLED(CONFIG_CMD_NVME)
> -   #define BOOT_TARGET_NVME(func) func(NVME, nvme, 0)
> -#else
> -   #define BOOT_TARGET_NVME(func)
> -#endif
> -
> -#if IS_ENABLED(CONFIG_CMD_USB)
> -   #define BOOT_TARGET_USB(func) func(USB, usb, 0)
> -#else
> -   #define BOOT_TARGET_USB(func)
> -#endif
> -
> -#define BOOT_TARGET_DEVICES(func) \
> -   BOOT_TARGET_NVME(func) \
> -   BOOT_TARGET_USB(func)
> -
> -#include 
> +#define BOOT_TARGETS   "nvme usb"
>
>  #define CFG_EXTRA_ENV_SETTINGS \
> ENV_DEVICE_SETTINGS \
> -   BOOTENV
> +   "boot_targets=" BOOT_TARGETS "\0"
>
>  #endif
>
> --
> 2.44.0
>

Reviewed-by: Neal Gompa 


-- 
真実はいつも一つ!/ Always, there's only one truth!


Re: [PATCH 0/4] configs: apple: Switch to standard boot + small adjustments

2024-03-17 Thread Neal Gompa
On Sun, Mar 17, 2024 at 7:54 AM Janne Grunau via B4 Relay
 wrote:
>
> This series contains a few misc config changes for Apple silicon
> systems:
> - switch from the deprecated distro boot scripts to standard boot
> - allows EFI console resizing based on the video console size
> - enables 16x32 bitmap fonts as Apple devices come with high DPI
>   displays
> - enables 64-bit LBA addressing for USB storage devices larger than 2TB
>
> Signed-off-by: Janne Grunau 
> ---
> Hector Martin (1):
>   apple_m1_defconfig: Turn on CONFIG_SYS_64BIT_LBA
>
> Janne Grunau (3):
>   configs: apple: Use "vidconsole,serial" as stdout/stderr
>   configs: apple: Enable CMD_SELECT_FONT and FONT_16X32
>   arm: apple: Switch to standard boot
>
>  arch/arm/Kconfig   |  2 +-
>  configs/apple_m1_defconfig |  3 +++
>  include/configs/apple.h| 24 
>  3 files changed, 8 insertions(+), 21 deletions(-)
> ---
> base-commit: f3c979dd0053c082d2df170446923e7ce5edbc2d
> change-id: 20240317-apple_config-981fcd9028b9
>

LGTM.

Reviewed-by: Neal Gompa 


-- 
真実はいつも一つ!/ Always, there's only one truth!


Re: [PATCH v2 0/6] USB keyboard improvements for asahi / desktop systems

2024-03-17 Thread Neal Gompa
On Sun, Mar 17, 2024 at 4:07 AM Janne Grunau via B4 Relay
 wrote:
>
> Apple USB Keyboards from 2021 need quirks to be useable. The boot HID
> keyboard protocol is unfortunately not described in the first interface
> descriptor but the second. This needs several changes. The USB keyboard
> driver has to look at all (2) interface descriptors during probing.
> Since I didn't want to rebuild the USB driver probe code the Apple
> keyboards are bound to the keyboard driver via USB vendor and product
> IDs.
> To make the keyboards useable on Apple silicon devices the xhci driver
> needs to initializes rings for the endpoints of the first two interface
> descriptors. If this is causes concerns regarding regressions or memory
> use the USB_MAX_ACTIVE_INTERFACES define could be turned into a CONFIG
> option.
> Even after this changes the keyboards still do not probe successfully
> since they apparently do not behave HID standard compliant. They only
> generate reports on key events. This leads the final check whether the
> keyboard is operational to fail unless the user presses keys during the
> probe. Skip this check for known keyboards.
> Keychron seems to emulate Apple keyboards (some models even "re-use"
> Apple's USB vendor ID) so apply this quirk as well.
>
> Some devices like Yubikeys emulate a keyboard. since u-boot only binds a
> single keyboard block this kind of devices from the USB keyboard driver.
>
> Signed-off-by: Janne Grunau 
> ---
> Changes in v2:
> - rewritten commit message for "[PATCH 2/6] usb: xhci: Set up endpoints for 
> the first 2 interfaces"
> - Replaced the usb keyboard Yubikey block with an env based USB device 
> blocklist
> - Use "-EINVAL" as return value in "[PATCH 3/6] usb: xhci: Abort transfers 
> with unallocated rings"
> - added "Reviewed-by:" tags
> - Link to v1: 
> https://lore.kernel.org/r/20240221-asahi-keyboards-v1-0-814b2e741...@jannau.net
>
> ---
> Janne Grunau (6):
>   usb: xhci: refactor xhci_set_configuration
>   usb: xhci: Set up endpoints for the first 2 interfaces
>   usb: xhci: Abort transfers with unallocated rings
>   usb: Add environment based device blocklist
>   usb: kbd: support Apple Magic Keyboards (2021)
>   usb: kbd: Add probe quirk for Apple and Keychron keyboards
>
>  common/usb.c |  56 +++
>  common/usb_kbd.c |  61 +++--
>  doc/usage/environment.rst|  12 +
>  drivers/usb/host/xhci-ring.c |   5 ++
>  drivers/usb/host/xhci.c  | 126 
> +++
>  include/env_default.h|  11 
>  include/usb.h|   6 +++
>  7 files changed, 227 insertions(+), 50 deletions(-)
> ---
> base-commit: 37345abb97ef0dd9c50a03b2a72617612dcae585
> change-id: 20240218-asahi-keyboards-f2ddaf0022b2
>

Series LGTM. Thanks for this! :)

Reviewed-by: Neal Gompa 


-- 
真実はいつも一つ!/ Always, there's only one truth!


Re: [PATCH v2] arm: apple: t602x: Add missing MMIO regions to memmap

2023-12-01 Thread Neal Gompa
On Fri, Dec 1, 2023 at 2:12 AM Janne Grunau via B4 Relay
 wrote:
>
> From: Janne Grunau 
>
> The memory maps for Apple's M2 Pro/Max/Ultra left MMIO space out which
> was not used by any driver at the time. The display out exposed as
> simple-framebuffer use a power-domain controlled by a device in an
> unmapped region.
> Add a map covering this region as well as another MMIO region in the
> range 0x4'' - 0x5''. The added regions cover all MMIO
> annotated in Apple's device tree in this range.
>
> Signed-off-by: Janne Grunau 
> ---
> Changes in v2:
> - use SZ_1G as block size
> - Link to v1: 
> https://lore.kernel.org/r/20231130-apple_t602x_extend_memmap-v1-1-cd96b251d...@jannau.net
> ---
>  arch/arm/mach-apple/board.c | 48 
> +
>  1 file changed, 48 insertions(+)
>
> diff --git a/arch/arm/mach-apple/board.c b/arch/arm/mach-apple/board.c
> index 47393babbc..7a6151a972 100644
> --- a/arch/arm/mach-apple/board.c
> +++ b/arch/arm/mach-apple/board.c
> @@ -370,6 +370,22 @@ static struct mm_region t6020_mem_map[] = {
> .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
>  PTE_BLOCK_NON_SHARE |
>  PTE_BLOCK_PXN | PTE_BLOCK_UXN
> +   }, {
> +   /* I/O */
> +   .virt = 0x4,
> +   .phys = 0x4,
> +   .size = SZ_1G,
> +   .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> +   PTE_BLOCK_NON_SHARE |
> +   PTE_BLOCK_PXN | PTE_BLOCK_UXN
> +   }, {
> +   /* I/O */
> +   .virt = 0x48000,
> +   .phys = 0x48000,
> +   .size = SZ_1G,
> +   .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> +   PTE_BLOCK_NON_SHARE |
> +   PTE_BLOCK_PXN | PTE_BLOCK_UXN
> }, {
> /* I/O */
> .virt = 0x58000,
> @@ -471,6 +487,22 @@ static struct mm_region t6022_mem_map[] = {
> .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
>  PTE_BLOCK_NON_SHARE |
>  PTE_BLOCK_PXN | PTE_BLOCK_UXN
> +   }, {
> +   /* I/O */
> +   .virt = 0x4,
> +   .phys = 0x4,
> +   .size = SZ_1G,
> +   .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> +   PTE_BLOCK_NON_SHARE |
> +   PTE_BLOCK_PXN | PTE_BLOCK_UXN
> +   }, {
> +   /* I/O */
> +   .virt = 0x48000,
> +   .phys = 0x48000,
> +   .size = SZ_1G,
> +   .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> +   PTE_BLOCK_NON_SHARE |
> +   PTE_BLOCK_PXN | PTE_BLOCK_UXN
> }, {
> /* I/O */
> .virt = 0x58000,
> @@ -551,6 +583,22 @@ static struct mm_region t6022_mem_map[] = {
> .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
>  PTE_BLOCK_NON_SHARE |
>  PTE_BLOCK_PXN | PTE_BLOCK_UXN
> +   }, {
> +   /* I/O */
> +   .virt = 0x24,
> +   .phys = 0x24,
> +   .size = SZ_1G,
> +   .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> +   PTE_BLOCK_NON_SHARE |
> +   PTE_BLOCK_PXN | PTE_BLOCK_UXN
> +   }, {
> +   /* I/O */
> +   .virt = 0x248000,
> +   .phys = 0x248000,
> +   .size = SZ_1G,
> +   .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> +   PTE_BLOCK_NON_SHARE |
> +   PTE_BLOCK_PXN | PTE_BLOCK_UXN
> }, {
> /* I/O */
> .virt = 0x258000,
>
> ---
> base-commit: 43f2873fa98b1da6eb56d756315c7bd7db63db27
> change-id: 20231130-apple_t602x_extend_memmap-c82c522ca8c0
>

LGTM.

Reviewed-by: Neal Gompa 


-- 
真実はいつも一つ!/ Always, there's only one truth!


Re: [PATCH v2 0/8] USB fixes: xHCI error handling

2023-10-29 Thread Neal Gompa
On Sun, Oct 29, 2023 at 2:38 AM Hector Martin  wrote:
>
> This series is the first of a few bundles of USB fixes we have been
> carrying downstream on the Asahi U-Boot branch for a few months.
>
> Patches #1-#6 fix a series of related robustness issues. Certain
> conditions related to endpoint stalls revealed a chain of bugs
> throughout the stack that caused U-Boot to completely fail when
> encountering some errors (and errors are a fact of life with USB).
>
> Example scenario:
> - The device stalls a bulk endpoint due to an error
> - The upper layer driver tries to use the endpoint again
> - There is no endpoint stall clear wired up in the API, so for starters
>   this is doomed to fail (fix: #4)
> - xHCI knows the endpoint is halted, but tries to queue the TRB anyway,
>   which can't work (fix: #5)
> - Since the endpoint is halted nothing happens, so the transfer times
>   out.
> - The timeout handling tries to abort the transfer
> - abort_td() tries to stop the endpoint, but since it is already halted,
>   this results in a context state error. As the transfer never started,
>   there is no completion event, so xhci_wait_for_event() is waiting for
>   the wrong event type, and logs an error and returns NULL. (fix: #2)
> - abort_td() crashes due to failing to guard against the NULL event
>   (fix: #1)
> - Even after fixing all that, abort_td() would not handle the context
>   state error properly and BUG() (fix: #3). This also fixes a race
>   condition documented in the xHCI spec that could occur even in the
>   absence of all the other bugs.
>
> Patch #6 addresses a related robustness issue where
> xhci_wait_for_event() panics on event timeouts other than for transfers.
> While this is clearly an unexpected condition and indicates a bug
> elsewhere, it's no reason to outright crash. USB is notoriously
> impossible to get 100% right, and we can't afford to be breaking users'
> systems at any sign of trouble. Error conditions should always be dealt
> with as gracefully as possible (even if that results in a completely
> broken USB controller, that is much preferable to aborting the boot
> process entirely, especially on devices with non-USB storage and
> keyboards where USB support is effectively optional for most users).
> Since after patch #1 we now guard all callers to xhci_wait_for_event()
> with at least trivial NULL checks, it's okay to return and continue in
> case of timeouts.
>
> Patch #7 addresses an unrelated bug I ran into while debugging all this,
> and patch #8 adds extra debug logs to make finding future issues less
> painful.
>
> I believe this should fix this Fedora bug too, which is either an
> instance of the above sequence of events, or (more likely, given the
> difficulty reproducing) the race condition documented in xHCI 4.6.9:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=2244305
>
> Signed-off-by: Hector Martin 
> ---
> Changes in v2:
> - Squashed in a trivial fix for patch #1
> - Removed spurious blank line
> - Added a longer description to the cover letter
> - Link to v1: 
> https://lore.kernel.org/r/20231027-usb-fixes-1-v1-0-1c879bbcd...@marcan.st
>
> ---
> Hector Martin (8):
>   usb: xhci: Guard all calls to xhci_wait_for_event
>   usb: xhci: Better error handling in abort_td()
>   usb: xhci: Allow context state errors when halting an endpoint
>   usb: xhci: Recover from halted bulk endpoints
>   usb: xhci: Fail on attempt to queue TRBs to a halted endpoint
>   usb: xhci: Do not panic on event timeouts
>   usb: xhci: Fix DMA address calculation in queue_trb
>   usb: xhci: Add more debugging
>
>  drivers/usb/host/xhci-ring.c | 99 
> 
>  drivers/usb/host/xhci.c  |  9 
>  include/usb/xhci.h   |  2 +
>  3 files changed, 92 insertions(+), 18 deletions(-)
> ---
> base-commit: 7c0d668103abae3ec14cd96d882ba20134bb4529
> change-id: 20231027-usb-fixes-1-83bfc7013012
>

Series LGTM.

Reviewed-by: Neal Gompa 


-- 
真実はいつも一つ!/ Always, there's only one truth!


Re: [PATCH 0/2] USB fixes: (Re)implement timeouts

2023-10-29 Thread Neal Gompa
On Sun, Oct 29, 2023 at 3:36 AM Hector Martin  wrote:
>
> A long time ago, the USB code was interrupt-driven and used top-level
> timeout handling. This has long been obsolete, and that code is just
> broken dead cruft. HC drivers instead hardcode timeouts today.
>
> We need to be able to specify timeouts explicitly to handle cases like
> USB hard disks spinning up, without having ridiculously long timeouts
> across the board (which would cause endless waiting when things go
> wrong anywhere else). So, it's time to rip out the old broken nonsense
> and actually pass through timeouts to USB host controller drivers, so
> they can be implemented properly.
>
> This series adds the necessary top-level scaffolding for control/bulk
> timeouts, and implements them in xHCI. I didn't bother with interrupt
> transfers, since I figure those probably never need long timeouts
> anyway.
>
> The platform I deal with only has xHCI, so I'll leave implementing this
> for EHCI/OHCI to someone else if anyone cares :)
>
> This series needs to be applied after [1], since the xHCI changes depend
> on changes made there.
>
> [1] 
> https://lore.kernel.org/u-boot/20231029-usb-fixes-1-v2-0-623533f63...@marcan.st/
>
> Signed-off-by: Hector Martin 
> ---
> Hector Martin (2):
>   usb: Pass through timeout to drivers
>   usb: xhci: Hook up timeouts
>
>  common/usb.c| 21 ++---
>  drivers/usb/host/ehci-hcd.c |  5 +++--
>  drivers/usb/host/ohci-hcd.c |  5 +++--
>  drivers/usb/host/r8a66597-hcd.c |  5 +++--
>  drivers/usb/host/usb-sandbox.c  |  6 --
>  drivers/usb/host/usb-uclass.c   |  9 +
>  drivers/usb/host/xhci-ring.c| 32 
>  drivers/usb/host/xhci.c | 28 
>  include/usb.h   | 10 ++
>  include/usb/xhci.h  | 14 ++
>  10 files changed, 72 insertions(+), 63 deletions(-)
> ---
> base-commit: 3d5d748e4d66b98109669c05d0c473fe67795801
> change-id: 20231029-usb-fixes-5-ca87bbedb40c
>

Series LGTM.

Reviewed-by: Neal Gompa 


-- 
真実はいつも一つ!/ Always, there's only one truth!


Re: [PATCH] usb: Ignore endpoints in non-zero altsettings

2023-10-29 Thread Neal Gompa
On Sun, Oct 29, 2023 at 3:25 AM Hector Martin  wrote:
>
> We currently do not really handle altsettings properly, and no driver
> uses them. Ignore the respective endpoint descriptors for secondary
> altsettings, to avoid creating duplicate endpoint records in the
> interface.
>
> This will have to be revisited if/when we have a driver that needs
> altsettings to work properly.
>
> Signed-off-by: Hector Martin 
> ---
>  common/usb.c | 9 +
>  1 file changed, 9 insertions(+)
>
> diff --git a/common/usb.c b/common/usb.c
> index aad13fd9c557..90f72fda00bc 100644
> --- a/common/usb.c
> +++ b/common/usb.c
> @@ -463,6 +463,15 @@ static int usb_parse_config(struct usb_device *dev,
> puts("Endpoint descriptor out of order!\n");
> break;
> }
> +   if (if_desc->num_altsetting > 1) {
> +   /*
> +* Ignore altsettings, which can trigger 
> duplicate
> +* endpoint errors below. Revisit this when 
> some
> +* driver actually needs altsettings with 
> differing
> +* endpoint setups.
> +*/
> +   break;
> +   }
> epno = dev->config.if_desc[ifno].no_of_ep;
> if_desc = >config.if_desc[ifno];
> if (epno >= USB_MAXENDPOINTS) {
>
> ---
> base-commit: 8ad1c9c26f7740806a162818b790d4a72f515b7e
> change-id: 20231029-usb-fixes-4-ba6931acf217
>

Irritating, but makes sense.

Reviewed-by: Neal Gompa 



--
真実はいつも一つ!/ Always, there's only one truth!


Re: [PATCH 0/4] USB fixes: Mass Storage bugs & 64bit support

2023-10-29 Thread Neal Gompa
On Sun, Oct 29, 2023 at 3:23 AM Hector Martin  wrote:
>
> This series fixes some bugs in the USBMS driver and adds 64-bit LBA
> support. This is required to make USB HDDs >=4TB work.
>
> Note that the increased timeout won't actually work right now, due to
> broken handling in the underlying USB infrastructure. That will be fixed
> in a follow-up series, which depends on [1] being applied first. The
> USBMS part is logically stand-alone and can be applied in parallel
> before that.
>
> [1] 
> https://lore.kernel.org/u-boot/20231029-usb-fixes-1-v2-0-623533f63...@marcan.st/
>
> Signed-off-by: Hector Martin 
> ---
> Hector Martin (4):
>   scsi: Fix a bunch of SCSI definitions.
>   usb: storage: Increase read/write timeout
>   usb: storage: Use the correct CBW lengths
>   usb: storage: Implement 64-bit LBA support
>
>  common/usb_storage.c | 164 
> ++-
>  drivers/ata/ahci.c   |   9 ++-
>  drivers/scsi/scsi.c  |   4 +-
>  include/scsi.h   |   8 ++-
>  4 files changed, 150 insertions(+), 35 deletions(-)
> ---
> base-commit: 8ad1c9c26f7740806a162818b790d4a72f515b7e
> change-id: 20231029-usb-fixes-3-c72f829ba61b

Series LGTM.

Reviewed-by: Neal Gompa 


-- 
真実はいつも一つ!/ Always, there's only one truth!


Re: [PATCH 0/2] USB fixes: Add missing timeout, ignore YubiKeys

2023-10-29 Thread Neal Gompa
On Sun, Oct 29, 2023 at 3:09 AM Hector Martin  wrote:
>
> This mini series fixes one bug, but in the process makes YubiKeys work,
> which then regresses people who have one *and* a USB keyboard, since we
> only support a single keyboard device.
>
> Therefore patch #1 makes U-Boot ignore YubiKeys, so #2 does not
> regress things.
>
> Signed-off-by: Hector Martin 
> ---
> Hector Martin (2):
>   usb: kbd: Ignore Yubikeys
>   usb: hub: Add missing reset recovery delay
>
>  common/usb_hub.c |  7 +++
>  common/usb_kbd.c | 19 +++
>  2 files changed, 26 insertions(+)
> ---
> base-commit: 8ad1c9c26f7740806a162818b790d4a72f515b7e
> change-id: 20231029-usb-fixes-2-976486d1603c
>

Series LGTM.

Reviewed-by: Neal Gompa 


-- 
真実はいつも一つ!/ Always, there's only one truth!


Re: [PATCH 0/8] USB fixes: xHCI error handling

2023-10-27 Thread Neal Gompa
On Fri, Oct 27, 2023 at 2:58 PM Neal Gompa  wrote:
>
> On Thu, Oct 26, 2023 at 7:26 PM Hector Martin  wrote:
> >
> > This series is the first of a few bundles of USB fixes we have been
> > carrying downstream on the Asahi U-Boot branch for a few months.
> >
> > Most importantly, this related set of patches makes xHCI error/stall
> > recovery more robust (or work at all in some cases). There are also a
> > couple patches fixing other xHCI bugs and adding better debug logs.
> >
> > I believe this should fix this Fedora bug too:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=2244305
> >
> > Signed-off-by: Hector Martin 
> > ---
> > Hector Martin (8):
> >   usb: xhci: Guard all calls to xhci_wait_for_event
> >   usb: xhci: Better error handling in abort_td()
> >   usb: xhci: Allow context state errors when halting an endpoint
> >   usb: xhci: Recover from halted non-control endpoints
> >   usb: xhci: Fail on attempt to queue TRBs to a halted endpoint
> >   usb: xhci: Do not panic on event timeouts
> >   usb: xhci: Fix DMA address calculation in queue_trb
> >   usb: xhci: Add more debugging
> >
> >  drivers/usb/host/xhci-ring.c | 100 
> > +++
> >  drivers/usb/host/xhci.c  |   9 
> >  include/usb/xhci.h   |   2 +
> >  3 files changed, 92 insertions(+), 19 deletions(-)
> > ---
> > base-commit: fb428b61819444b9337075f49c72f326f5d12085
> > change-id: 20231027-usb-fixes-1-83bfc7013012
> >
>
> The series looks reasonable and has worked quite well in Fedora Asahi.
>
> Reviewed-by: Neal Gompa 
>

Resending now that I'm subscribed to the U-Boot mailing list...

Reviewed-by: Neal Gompa 



-- 
真実はいつも一つ!/ Always, there's only one truth!


Re: [PATCH 0/8] USB fixes: xHCI error handling

2023-10-27 Thread Neal Gompa
On Thu, Oct 26, 2023 at 7:26 PM Hector Martin  wrote:
>
> This series is the first of a few bundles of USB fixes we have been
> carrying downstream on the Asahi U-Boot branch for a few months.
>
> Most importantly, this related set of patches makes xHCI error/stall
> recovery more robust (or work at all in some cases). There are also a
> couple patches fixing other xHCI bugs and adding better debug logs.
>
> I believe this should fix this Fedora bug too:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=2244305
>
> Signed-off-by: Hector Martin 
> ---
> Hector Martin (8):
>   usb: xhci: Guard all calls to xhci_wait_for_event
>   usb: xhci: Better error handling in abort_td()
>   usb: xhci: Allow context state errors when halting an endpoint
>   usb: xhci: Recover from halted non-control endpoints
>   usb: xhci: Fail on attempt to queue TRBs to a halted endpoint
>   usb: xhci: Do not panic on event timeouts
>   usb: xhci: Fix DMA address calculation in queue_trb
>   usb: xhci: Add more debugging
>
>  drivers/usb/host/xhci-ring.c | 100 
> +++
>  drivers/usb/host/xhci.c  |   9 
>  include/usb/xhci.h   |   2 +
>  3 files changed, 92 insertions(+), 19 deletions(-)
> ---
> base-commit: fb428b61819444b9337075f49c72f326f5d12085
> change-id: 20231027-usb-fixes-1-83bfc7013012
>

The series looks reasonable and has worked quite well in Fedora Asahi.

Reviewed-by: Neal Gompa 



-- 
真実はいつも一つ!/ Always, there's only one truth!