On Wed, 22 May 2024 08:15:27 +0200, Jonas Richardsen wrote:
> The pointer `sdhci.mci` is currently not being set for the bcm2835. This
> leads to a null pointer dereference for example in `sdhci_wait_idle()`
> if the `sdhci_read` function fails or times out.
>
> Set the pointer within the `bcm28
On Wed, 22 May 2024 10:07:32 +0200, Ahmad Fatoum wrote:
> All other messages printed in sdhci.c use the host's device to prefix
> the message, except this one debug message here that uses the card's
> instead. Unify this by using the host device everywhere.
>
>
Applied, thanks!
[1/3] mci: sdh
On Fri, 24 May 2024 12:35:14 +0200, Ahmad Fatoum wrote:
> When targeting older OP-TEE versions, a PTA for BSEC access may not be
> available. Allow disabling STM32_BSEC_OPTEE_TA in this case, so the
> driver falls back to the secure monitor call silicon provider service.
>
>
Applied, thanks!
When targeting older OP-TEE versions, a PTA for BSEC access may not be
available. Allow disabling STM32_BSEC_OPTEE_TA in this case, so the
driver falls back to the secure monitor call silicon provider service.
Reported-by: Xogium
Signed-off-by: Ahmad Fatoum
---
drivers/nvmem/Kconfig | 7 +--
On Thu, 23 May 2024 16:40:27 +0200, Stefan Kerkmann wrote:
> I ran into the same problem as Roland with this Phy driver and missed
> the fix that landed in 095cd32961aab64cfe72941ce43d99876852e12b ("net:
> phy: dp83867: reset PHY on probe"). I'm still submitting this series as
> a refactoring of
