>> On Wed, Oct 4, 2023 at 9:01 PM MrChromebox
> wrote:
> >> >
> >> > Add the ClockRate field to the UNIVERSAL_PAYLOAD_SERIAL_PORT_INFO
> >> > struct, so that the field can be used by UefiPayloadPkg to properly
> >> > set up the serial p
On Thu, Oct 5, 2023 at 12:45 PM Pedro Falcato
wrote:
> On Wed, Oct 4, 2023 at 9:01 PM MrChromebox
> wrote:
> >
> > Add the ClockRate field to the UNIVERSAL_PAYLOAD_SERIAL_PORT_INFO
> > struct, so that the field can be used by UefiPayloadPkg to properly
> > set up t
Fixes serial output on platforms using coreboot and a non-default
clock rate such as AMD Picasso and newer Zen-based platforms.
Signed-off-by: Matt DeVillier
Change-Id: I91290397852176754e9a34ec6e5829044f41d15a
---
UefiPayloadPkg/Library/PlatformHookLib/PlatformHookLib.c | 5 +
UefiPayload
Extract and use the serial port clock rate provided by coreboot via
the InputHertz field.
Signed-off-by: Matt DeVillier
Change-Id: If764bd7c0b691cf887205471d0343fdf62372141
---
UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/UefiPayloadPkg/U
Add the ClockRate field to the UNIVERSAL_PAYLOAD_SERIAL_PORT_INFO
struct, so that the field can be used by UefiPayloadPkg to properly
set up the serial port on boards using a non-standard clock rate.
Signed-off-by: Matt DeVillier
Change-Id: I9bcaf03ab63f6a45d2cf25a580f7a2eba388cbbd
---
MdeModule
seems this patch got truncated during a rebase, here is the correct version.
For device that does not respond to GetProtocolRequest(), the original flow is:
a.1 Execute GetProtocolRequest()
a.2 Timeout occurs for GetProtocolRequest()
a.3 Conditionally execute UsbSetProtocolRequest()
The proposed
Acked-by Matt DeVillier
On Mon, Sep 7, 2020 at 2:31 PM Laszlo Ersek wrote:
>
> ... for git-shortlog purposes.
>
> Cc: Matt DeVillier
> Cc: Philippe Mathieu-Daudé
> Signed-off-by: Laszlo Ersek
> ---
> .mailmap | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/.mailmap b/.mailmap
> inde
The endpoint selected by the driver needs to not
only be an interrupt type, but have direction IN
as required to set up an asynchronous interrupt transfer.
Currently, the driver assumes that the first INT endpoint
will be of type IN, but that is not true of all devices,
and will silently fail on d
---
MdeModulePkg/Bus/Usb/UsbKbDxe/KeyBoard.c | 90 +---
1 file changed, 47 insertions(+), 43 deletions(-)
diff --git a/MdeModulePkg/Bus/Usb/UsbKbDxe/KeyBoard.c
b/MdeModulePkg/Bus/Usb/UsbKbDxe/KeyBoard.c
index 7505951c82..37c9388161 100644
--- a/MdeModulePkg/Bus/Usb/UsbKbDxe/K
The endpoint selected by the driver needs to not
only be an interrupt type, but have direction IN
as required to set up an asynchronous interrupt transfer.
Currently, the driver assumes that the first INT endpoint
will be of type IN, but that is not true of all devices,
and will silently fail on d
The endpoint selected by the driver needs to not
only be an interrupt type, but have direction IN
as required to set up an asynchronous interrupt transfer.
Currently, the driver assumes that the first INT endpoint
will be of type IN, but that is not true of all devices,
and will silently fail on d
The endpoint selected by the driver needs to not
only be an interrupt type, but have direction IN
as required to set up an asynchronous interrupt transfer.
Currently, the driver assumes that the first INT endpoint
will be of type IN, but that is not true of all devices,
and will silently fail on d
The endpoint selected by the driver needs to not
only be an interrupt type, but have direction IN
as required to set up an asynchronous interrupt transfer.
Currently, the driver assumes that the first INT endpoint
will be of type IN, but that is not true of all devices,
and will silently fail on d
USB keyboard initialization fails if the OUT interrupt
endpoint precedes the IN endpoint. Fix that.
Matt DeVillier (1):
MdeModulePkg/Usb/EfiKey: Fix endpoint selection
MdeModulePkg/Bus/Usb/UsbKbDxe/EfiKey.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--
2.20.1
-=-=-=-=-=-=-=
The endpoint selected by the driver needs to not
only be an interrupt type, but have direction IN
as required to set up an asynchronous interrupt transfer.
Currently, the driver assumes that the first INT endpoint
will be of type IN, but that is not true of all devices,
and will silently fail on d
>From e7648a8c3efae0540586ad497a5366ffd0c87fb7 Mon Sep 17 00:00:00 2001
From: Matt DeVillier
Date: Thu, 12 Dec 2019 12:46:47 -0600
Subject: [PATCH 1/2] MdeModulePkg/Usb/EfiKey: Fix endpoint selection
The endpoint selected by the driver needs to not
only be an interrupt type, but have direction IN
>From 2a8e343f8a5848825d3d12ba76df0fb4212ab5b8 Mon Sep 17 00:00:00 2001
From: Matt DeVillier
Date: Thu, 12 Dec 2019 12:54:14 -0600
Subject: [PATCH 2/2] MdeModulePkg/Usb/UsbMouse: Fix endpoint selection
The endpoint selected by the driver needs to not
only be an interrupt type, but have direction
Greetings!
I have a Chromebook here which has a detachable USB keyboard/touchpad which is
failing to initialize in the edk2 environment (regardless if connected before
boot or after), but works fine once an OS is booted (both Windows and Linux).
I've compiled a debug build, but having a hard ti
18 matches
Mail list logo
