Hello Philip,
On 26.10.23 05:44, Heiko Schocher wrote:
> Hello Philip,
>
> On 20.10.23 11:02, Philip Richard Oberfichtner wrote:
>> This adds a generic I2C bootcounter adhering to driver model to replace
>> the previously removed legacy implementation.
>>
>> There is no change in functionality,
Hi Ilias,
On Fri, Oct 27, 2023 at 03:23:07PM +0300, Ilias Apalodimas wrote:
> Akashi-san
>
> On Fri, 27 Oct 2023 at 04:00, Tom Rini wrote:
> >
> > On Fri, Oct 27, 2023 at 09:25:44AM +0900, AKASHI Takahiro wrote:
> > > On Thu, Oct 26, 2023 at 01:01:52PM +0200, Heinrich Schuchardt wrote:
> > > >
Add support for exposing the whole mmc device by setting the 'size'
parameter to 0. This can be useful in case it is not clear what the
total device size is up front. Update the documentation accordingly.
Signed-off-by: Marek Vasut
---
Cc: Lukasz Majewski
Cc: Mattijs Korpershoek
Cc: Tom Rini
On Sun, Oct 29, 2023 at 2:33 PM Peter Robinson wrote:
>
> On Sun, Oct 29, 2023 at 9:25 PM Marek Vasut wrote:
> >
> > On 10/27/23 08:03, Hector Martin wrote:
> > > On 27/10/2023 09.36, Marek Vasut wrote:
> > >> On 10/27/23 01:26, Hector Martin wrote:
> > >>> Gah, I should've paid more attention
On Sun, Oct 29, 2023 at 9:25 PM Marek Vasut wrote:
>
> On 10/27/23 08:03, Hector Martin wrote:
> > On 27/10/2023 09.36, Marek Vasut wrote:
> >> On 10/27/23 01:26, Hector Martin wrote:
> >>> Gah, I should've paid more attention to that rebase. Here's a dumb
> >>> fixup for this patch. I'll squash
On 10/27/23 08:03, Hector Martin wrote:
On 27/10/2023 09.36, Marek Vasut wrote:
On 10/27/23 01:26, Hector Martin wrote:
Gah, I should've paid more attention to that rebase. Here's a dumb
fixup for this patch. I'll squash it into a v2 if needed alongside
any other changes, or if it looks good
On 10/29/23 16:50, Hector Martin wrote:
On 29/10/2023 21.04, Marek Vasut wrote:
On 10/29/23 08:24, 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
On 10/29/23 16:54, Hector Martin wrote:
On 29/10/2023 21.11, Marek Vasut wrote:
On 10/29/23 08:23, Hector Martin wrote:
This makes things work properly on devices with >= 2 TiB
capacity. If u-boot is built without CONFIG_SYS_64BIT_LBA,
the capacity will be clamped at 2^32 - 1 sectors.
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
On 29/10/2023 21.11, Marek Vasut wrote:
> On 10/29/23 08:23, Hector Martin wrote:
>> This makes things work properly on devices with >= 2 TiB
>> capacity. If u-boot is built without CONFIG_SYS_64BIT_LBA,
>> the capacity will be clamped at 2^32 - 1 sectors.
>>
>> Signed-off-by: Hector Martin
>>
On 29/10/2023 21.04, Marek Vasut wrote:
> On 10/29/23 08:24, 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
>>
On 10/29/23 07:37, Hector Martin wrote:
A bunch of miscellaneous debug messages to aid in working out USB
issues.
Signed-off-by: Hector Martin
---
drivers/usb/host/xhci-ring.c | 29 ++---
1 file changed, 26 insertions(+), 3 deletions(-)
diff --git
On 10/29/23 07:37, Hector Martin wrote:
We need to get the DMA address before incrementing the pointer, as that
might move us onto another segment.
Signed-off-by: Hector Martin
Reviewed-by: Marek Vasut
On 10/29/23 07:37, Hector Martin wrote:
Now that we always check the return value, just return NULL on timeouts.
We can still log the error since this is a problem, but it's not reason
to panic.
Signed-off-by: Hector Martin
---
drivers/usb/host/xhci-ring.c | 5 +++--
1 file changed, 3
On 10/29/23 07:37, Hector Martin wrote:
This isn't going to work, don't pretend it will and then end up timing
out.
Signed-off-by: Hector Martin
---
drivers/usb/host/xhci-ring.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-ring.c
On 10/29/23 07:37, Hector Martin wrote:
There is currently no codepath to recover from this case. In principle
we could require that the upper layer do this explicitly, but let's just
do it in xHCI when the next bulk transfer is started, since that
reasonably implies whatever caused the problem
On 10/29/23 07:37, Hector Martin wrote:
There is a race where an endpoint may halt by itself while we are trying
to halt it, which results in a context state error. See xHCI 4.6.9 which
mentions this case.
This also avoids BUGging when we attempt to stop an endpoint which was
already stopped to
On 10/29/23 07:37, Hector Martin wrote:
If the xHC has a problem with our STOP ENDPOINT command, it is likely to
return a completion directly instead of first a transfer event for the
in-progress transfer. Handle that more gracefully.
We still BUG() on the error code, but at least we don't end
On 10/29/23 07:37, Hector Martin wrote:
xhci_wait_for_event returns NULL on timeout, so the caller always has to
check for that. This addresses immediate explosions in this part
of the code when timeouts happen, but not the root cause for the
timeout.
Signed-off-by: Hector Martin
On 10/29/23 08:09, Hector Martin wrote:
Some devices like YubiKeys need more time before SET_ADDRESS. The spec
says we need to wait 10ms.
Signed-off-by: Hector Martin
Reviewed-by: Marek Vasut
On 10/29/23 08:09, Hector Martin wrote:
We currently only support one USB keyboard device, but some devices
emulate keyboards for other purposes. Most commonly, people run into
this with Yubikeys, so let's ignore those.
Even if we end up supporting multiple keyboards in the future, it's
safer
On 10/29/23 08:23, Hector Martin wrote:
This makes things work properly on devices with >= 2 TiB
capacity. If u-boot is built without CONFIG_SYS_64BIT_LBA,
the capacity will be clamped at 2^32 - 1 sectors.
Signed-off-by: Hector Martin
---
common/usb_storage.c | 132
On 10/29/23 08:23, Hector Martin wrote:
USB UFI uses fixed 12-byte commands (as does RBC, which is not
supported), but SCSI does not have this limitation. Use the correct
command block lengths depending on the subclass.
Signed-off-by: Hector Martin
Reviewed-by: Marek Vasut
On 10/29/23 08:23, Hector Martin wrote:
Some USB devices (like hard disks) can take a long time to initially
respond to read/write requests. Explicitly specify a much longer timeout
than normal.
Signed-off-by: Hector Martin
Can we make this configurable with e.g. env variable, similar to
On 10/29/23 08:23, Hector Martin wrote:
0x9e isn't Read Capacity, it's a service action and the read capacity
command is a subcommand.
READ16 is not 0x48, it's 0x88. 0x48 is SANITIZE and that sounds like we
might have been destroying data instead of reading data. No bueno.
Signed-off-by:
On 10/29/23 08:24, 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
On 10/29/23 08:36, Hector Martin wrote:
The old USB code was interrupt-driven and just polled at the top level.
This has been obsolete since interrupts were removed, which means the
timeout support has been completely broken.
Rip out the top-level polling and just pass through the timeout
On 10/29/23 08:36, Hector Martin wrote:
Now that the USB core passes through timeout info to the host
controller, actually hook it up.
Signed-off-by: Hector Martin
Except for the negative timeout value question, which needs to be sorted
out:
Reviewed-by: Marek Vasut
On 10/29/23 08:36, Hector Martin wrote:
The old USB code was interrupt-driven and just polled at the top level.
This has been obsolete since interrupts were removed, which means the
timeout support has been completely broken.
Rip out the top-level polling and just pass through the timeout
On 10/29/23 08:36, 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
se 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.
>
> [
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!
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
++
> 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!
On Sun, Oct 29, 2023 at 05:28:13PM +1300, Simon Glass wrote:
> Some of the Python tests are a pain because they don't reset the TPM
> state before each test. Driver model tests do this, so convert the
> tests to C.
>
> This means that these tests won't run on real hardware, but we have
> tests
On 10/28/23 23:48, Sean Anderson wrote:
spl_nand_fit_read unconditionally accesses load->priv. Ensure it is set.
Fixes: 00e180cc513 ("spl: nand: support loading i.MX container format file")
Fixes: 4620e8aabc1 ("spl: nand: support loading legacy image with payload
compressed")
Signed-off-by:
Hi,
On Mon Sep 25, 2023 at 11:55 PM CEST, Jonas Karlman wrote:
> With MMC_PWRSEQ enabled the following link issue may happen when
> building SPL and SPL_PWRSEQ is not enabled.
>
> aarch64-linux-gnu-ld.bfd: drivers/mmc/meson_gx_mmc.o: in function
> `meson_mmc_probe':
>
Hi
On Sun, Oct 29, 2023 at 4:48 AM Sean Anderson wrote:
>
> All other implementations of nand_spl_load_image only read as many pages as
> are necessary to load the image. However, nand_spl_loaders.c loads the full
> block. Align it with other load functions so that it is easier to
> determine
Hi
On Sun, Oct 29, 2023 at 4:48 AM Sean Anderson wrote:
>
> When no manufacturer is matched, manufacturer_desc is NULL. Avoid
> dereferencing it in that case.
>
> Fixes: 4e67c571252 ("mtd,ubi,ubifs: sync with linux v3.15")
> Signed-off-by: Sean Anderson
> ---
>
>
The Zkr ISA extension (ratified Nov 2021) introduced the seed CSR. It
provides an interface to a physical entropy source.
A RNG driver based on the seed CSR is provided. It depends on
mseccfg.sseed being set in the SBI firmware.
Signed-off-by: Heinrich Schuchardt
---
v2:
Resume after
If CSRs like seed are readable by S-mode, may not be determinable by
S-mode. For safe driver probing allow to resume via a longjmp after an
exception.
Signed-off-by: Heinrich Schuchardt
---
v2:
new patch
---
arch/riscv/lib/interrupts.c | 13 +
include/interrupt.h |
The Zkr ISA extension (ratified Nov 2021) introduced the seed CSR. It
provides an interface to a physical entropy source.
A RNG driver based on the seed CSR is provided. It depends on
mseccfg.sseed being set in the SBI firmware.
If the seed CSR readable, is not determinable by S-mode without
Hi Michal,
thanks, built all m68k stuff, no issues.
Also tested on stmark2, all is ok.
Reviewed-by: Angelo Dureghello
On 25/10/23 9:25 AM, Michal Simek wrote:
Similar change was done by commit b4c2c151b14b ("Kconfig: Remove all
default n/no options") and again sync is required.
default n/no
On 10/29/23 06:39, Chanho Park wrote:
Hi,
-Original Message-
From: U-Boot On Behalf Of Heinrich
Schuchardt
Sent: Sunday, October 29, 2023 8:26 AM
To: Rick Chen ; Leo
Cc: Sughosh Ganu ; u-boot@lists.denx.de; Heinrich
Schuchardt
Subject: [RFC 1/1] rng: Provide a RNG based on the
Now that the USB core passes through timeout info to the host
controller, actually hook it up.
Signed-off-by: Hector Martin
---
drivers/usb/host/xhci-ring.c | 32
drivers/usb/host/xhci.c | 23 +--
include/usb/xhci.h | 14
The old USB code was interrupt-driven and just polled at the top level.
This has been obsolete since interrupts were removed, which means the
timeout support has been completely broken.
Rip out the top-level polling and just pass through the timeout
parameter to host controller drivers. Right now
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
endpoint setups.
+*/
+ break;
+ }
epno = dev->config.if_desc[ifno].no_of_ep;
if_desc = >config.if_desc[ifno];
if (epno >= USB_MAXENDPOINTS) {
---
base-commit: 8ad1c9c26f7740806a162818b790d4a72f5
This makes things work properly on devices with >= 2 TiB
capacity. If u-boot is built without CONFIG_SYS_64BIT_LBA,
the capacity will be clamped at 2^32 - 1 sectors.
Signed-off-by: Hector Martin
---
common/usb_storage.c | 132 ---
1 file changed,
USB UFI uses fixed 12-byte commands (as does RBC, which is not
supported), but SCSI does not have this limitation. Use the correct
command block lengths depending on the subclass.
Signed-off-by: Hector Martin
---
common/usb_storage.c | 22 ++
1 file changed, 14
0x9e isn't Read Capacity, it's a service action and the read capacity
command is a subcommand.
READ16 is not 0x48, it's 0x88. 0x48 is SANITIZE and that sounds like we
might have been destroying data instead of reading data. No bueno.
Signed-off-by: Hector Martin
---
drivers/ata/ahci.c | 9
Some USB devices (like hard disks) can take a long time to initially
respond to read/write requests. Explicitly specify a much longer timeout
than normal.
Signed-off-by: Hector Martin
---
common/usb_storage.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git
ich 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 S
Some devices like YubiKeys need more time before SET_ADDRESS. The spec
says we need to wait 10ms.
Signed-off-by: Hector Martin
---
common/usb_hub.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/common/usb_hub.c b/common/usb_hub.c
index ba11a188ca64..858ada0f73be 100644
---
We currently only support one USB keyboard device, but some devices
emulate keyboards for other purposes. Most commonly, people run into
this with Yubikeys, so let's ignore those.
Even if we end up supporting multiple keyboards in the future, it's
safer to ignore known non-keyboard devices.
This
---
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
A bunch of miscellaneous debug messages to aid in working out USB
issues.
Signed-off-by: Hector Martin
---
drivers/usb/host/xhci-ring.c | 29 ++---
1 file changed, 26 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
We need to get the DMA address before incrementing the pointer, as that
might move us onto another segment.
Signed-off-by: Hector Martin
---
drivers/usb/host/xhci-ring.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-ring.c
Now that we always check the return value, just return NULL on timeouts.
We can still log the error since this is a problem, but it's not reason
to panic.
Signed-off-by: Hector Martin
---
drivers/usb/host/xhci-ring.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git
This isn't going to work, don't pretend it will and then end up timing
out.
Signed-off-by: Hector Martin
---
drivers/usb/host/xhci-ring.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index
There is currently no codepath to recover from this case. In principle
we could require that the upper layer do this explicitly, but let's just
do it in xHCI when the next bulk transfer is started, since that
reasonably implies whatever caused the problem has been dealt with.
Signed-off-by:
There is a race where an endpoint may halt by itself while we are trying
to halt it, which results in a context state error. See xHCI 4.6.9 which
mentions this case.
This also avoids BUGging when we attempt to stop an endpoint which was
already stopped to begin with, which is probably a bug
If the xHC has a problem with our STOP ENDPOINT command, it is likely to
return a completion directly instead of first a transfer event for the
in-progress transfer. Handle that more gracefully.
We still BUG() on the error code, but at least we don't end up timing
out on the event and ending up
xhci_wait_for_event returns NULL on timeout, so the caller always has to
check for that. This addresses immediate explosions in this part
of the code when timeouts happen, but not the root cause for the
timeout.
Signed-off-by: Hector Martin
---
drivers/usb/host/xhci-ring.c | 15 +++
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
65 matches
Mail list logo
