* Re: [PATCH net] net: ethernet: mtk_eth_soc: fix supported_interface set after phylink_create
From: Daniel Golle @ 2026-06-15 15:33 UTC (permalink / raw)
To: Christian Marangi
Cc: Felix Fietkau, Lorenzo Bianconi, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Matthias Brugger,
AngeloGioacchino Del Regno, Russell King, netdev, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <20260615151106.15438-1-ansuelsmth@gmail.com>
On Mon, Jun 15, 2026 at 05:11:00PM +0200, Christian Marangi wrote:
> Everything configured in phylink_config it's assumed to be set before
> calling phylink_create() to permit correct parsing of all the different
> modes and capabilities.
>
> Commit 51cf06ddafc9 ("net: ethernet: mtk_eth_soc: add support for MT7988
> internal 2.5G PHY") while introducing support for 2.5G phy for MT7988,
> probably due to an auto-rebase, placed the configuration of the INTERNAL
> interface mode for the supported_interfaces for phylink_config right after
> phylink_create() introducing a possible problem with supported interfaces
> parsing.
>
> While this doesn't currently create any problem/bug, move setting this bit
> before phylink_create() to prevent any possible regression in future code
> change in phylink core.
>
> Fixes: 51cf06ddafc9 ("net: ethernet: mtk_eth_soc: add support for MT7988 internal 2.5G PHY")
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Daniel Golle <daniel@makrotopia.org>
As no user-visible bug surfaces because of that it is questionable though if
the Fixes:-tag is justified.
^ permalink raw reply
* Re: [PATCH v2] arm64: errata: Handle Apple WFI State Loss
From: Sven Peter @ 2026-06-15 15:27 UTC (permalink / raw)
To: Will Deacon, Yureka Lilian
Cc: Catalin Marinas, linux-arm-kernel, linux-kernel, asahi,
Sasha Finkelstein
In-Reply-To: <ajAT9fWgOd9HY7ei@willie-the-truck>
On 15.06.26 17:02, Will Deacon wrote:
> On Mon, Jun 15, 2026 at 02:21:36PM +0200, Yureka Lilian wrote:
>> Apple Silicon CPUs can lose register state in WFI, leading to crashes
>> in the idle loop early in the boot process.
>> This applies to any previous Apple Silicon CPUs too, but is worked
>> around by configuring the WFI mode in SYS_IMP_APL_CYC_OVRD sysreg
>> during m1n1's chickens setup.
>> This workaround no longer exists since M4.
>>
>> Add a workaround capability for replacing wfi and wfit with nop, and
>> an erratum to enable it on the affected CPUs if the workaround using the
>> sysreg is not already applied. Leave the decision whether the sysreg
>> workaround can be used up to the earlier parts of the boot chain which
>> already configure the Apple Silicon chicken bits.
>>
>> This alternative has to be applied in early boot, since otherwise some
>> cores might enter the idle loop before apply_alternatives_all() is run.
>>
>> Reviewed-by: Sasha Finkelstein <k@chaosmail.tech>
>> Signed-off-by: Yureka Lilian <yureka@cyberchaos.dev>
>> ---
>> Changes since v1:
>> Restricted the erratum to EL2 only, since in EL1 we'd expect the
>> hypervisor to trap WFI and handle the erratum.
>>
>> Tested on M4 and M4 Pro (which now sometimes nondeterministically
>> crash later during boot).
>> Successfully booted on M3 Max with the SYS_IMP_APL_CYC_OVRD
>> workaround disabled in the bootloader, as well as A18 Pro (which,
>> like M4 / M4 Pro, doesn't have SYS_IMP_APL_CYC_OVRD).
>>
>> There is probably a better place for the SYS_IMP_APL_CYC_OVRD
>> defines, which I currently put in the middle of cpu_errata.c, but I
>> wouldn't know where.
>> ---
>> arch/arm64/Kconfig | 12 ++++++++++++
>> arch/arm64/include/asm/barrier.h | 19 ++++++++++++++++---
>> arch/arm64/kernel/cpu_errata.c | 21 +++++++++++++++++++++
>> arch/arm64/tools/cpucaps | 1 +
>> 4 files changed, 50 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index b3afe0688919..8c8ff069856f 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -453,6 +453,18 @@ config AMPERE_ERRATUM_AC04_CPU_23
>>
>> If unsure, say Y.
>>
>> +config APPLE_ERRATUM_WFI_STATE
>> + bool "Apple Silicon: WFI loses state"
>> + default y
>> + help
>> + This option adds an alternative code sequence to work around some
>> + Apple Silicon CPUs losing register state during wfi and wfit
>> + instructions.
>> +
>> + As a workaround, the wfi and wfit instructions are replaced with nop
>> + operations via the alternative framework if an affected CPU is
>> + detected.
>> +
>> config ARM64_WORKAROUND_CLEAN_CACHE
>> bool
>>
>> diff --git a/arch/arm64/include/asm/barrier.h b/arch/arm64/include/asm/barrier.h
>> index 9495c4441a46..f72eddc7c434 100644
>> --- a/arch/arm64/include/asm/barrier.h
>> +++ b/arch/arm64/include/asm/barrier.h
>> @@ -20,9 +20,22 @@
>> #define wfe() asm volatile("wfe" : : : "memory")
>> #define wfet(val) asm volatile("msr s0_3_c1_c0_0, %0" \
>> : : "r" (val) : "memory")
>> -#define wfi() asm volatile("wfi" : : : "memory")
>> -#define wfit(val) asm volatile("msr s0_3_c1_c0_1, %0" \
>> - : : "r" (val) : "memory")
>> +#define wfi() \
>> + do { \
>> + asm volatile( \
>> + ALTERNATIVE("wfi", \
>> + "nop", \
>> + ARM64_WORKAROUND_WFI_STATE) \
>> + : : : "memory"); \
>> + } while (0)
>> +#define wfit(val) \
>> + do { \
>> + asm volatile( \
>> + ALTERNATIVE("msr s0_3_c1_c0_1, %0", \
>> + "nop", \
>> + ARM64_WORKAROUND_WFI_STATE) \
>> + : : "r" (val) : "memory"); \
>> + } while (0)
>
> How can you guarantee that we don't run one of these prior to patching?
>
> I wonder if we're better off doing something like x86 and having an "idle="
> cmdline option. which could choose between e.g. nop, wfe, wfi and yield, for
> example? In fact, would wfe be a better choice than nop for you?
I think that should also solve the issue of detecting if we're running
on bare metal and need this or if there's something that mitigates the
issue (e.g. M1-M3 where we can still enable that chicken bit or a
hypervisor that just traps wfi): Just let the bootloader decide and
inject that cmdline option.
Best,
Sven
^ permalink raw reply
* Re: [PATCH net] net: ethernet: mtk_eth_soc: fix supported_interface set after phylink_create
From: Maxime Chevallier @ 2026-06-15 15:27 UTC (permalink / raw)
To: Christian Marangi, Felix Fietkau, Lorenzo Bianconi, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Matthias Brugger, AngeloGioacchino Del Regno, Russell King,
Daniel Golle, netdev, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <20260615151106.15438-1-ansuelsmth@gmail.com>
On 6/15/26 17:11, Christian Marangi wrote:
> Everything configured in phylink_config it's assumed to be set before
> calling phylink_create() to permit correct parsing of all the different
> modes and capabilities.
>
> Commit 51cf06ddafc9 ("net: ethernet: mtk_eth_soc: add support for MT7988
> internal 2.5G PHY") while introducing support for 2.5G phy for MT7988,
> probably due to an auto-rebase, placed the configuration of the INTERNAL
> interface mode for the supported_interfaces for phylink_config right after
> phylink_create() introducing a possible problem with supported interfaces
> parsing.
>
> While this doesn't currently create any problem/bug, move setting this bit
> before phylink_create() to prevent any possible regression in future code
> change in phylink core.
Agreed
>
> Fixes: 51cf06ddafc9 ("net: ethernet: mtk_eth_soc: add support for MT7988 internal 2.5G PHY")
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Maxime
^ permalink raw reply
* Re: [PATCH v7 2/6] firmware: hwrng: arm_smccc_trng: Register as an SMCCC device
From: Andre Przywara @ 2026-06-15 15:15 UTC (permalink / raw)
To: Aneesh Kumar K.V (Arm), linux-coco, linux-arm-kernel,
linux-kernel
Cc: Catalin Marinas, Greg KH, Jeremy Linton, Jonathan Cameron,
Lorenzo Pieralisi, Mark Rutland, Sudeep Holla, Will Deacon,
Steven Price, Suzuki K Poulose
In-Reply-To: <20260611130429.295516-3-aneesh.kumar@kernel.org>
Hi Aneesh,
thanks for doing this, we have thought about this for quite a while, but
no one dared to just bite the bullet...
On 6/11/26 15:04, Aneesh Kumar K.V (Arm) wrote:
> The SMCCC TRNG interface is a firmware-provided SMCCC service rather than a
> standalone platform device. Now that the SMCCC core has an SMCCC bus,
> create an arm-smccc-trng device for the discovered TRNG service and convert
> the hwrng driver to an SMCCC driver.
>
> The SMCCC id table preserves module autoloading for systems where the TRNG
> driver is built as a module.
>
> The sysfs device path changes from the old smccc_trng platform-device path
> to an arm-smccc device path. No known userspace dependency on the old path
> was found; a Debian Code Search lookup for the existing platform-device
> name/path did not find any users.
>
> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
> ---
> arch/arm64/include/asm/archrandom.h | 2 +-
> drivers/char/hw_random/arm_smccc_trng.c | 32 +++++++++-----
> drivers/firmware/smccc/smccc.c | 58 +++++++++++++++++++++----
> 3 files changed, 71 insertions(+), 21 deletions(-)
>
> diff --git a/arch/arm64/include/asm/archrandom.h b/arch/arm64/include/asm/archrandom.h
> index 8babfbe31f95..7605dd81bd1e 100644
> --- a/arch/arm64/include/asm/archrandom.h
> +++ b/arch/arm64/include/asm/archrandom.h
> @@ -12,7 +12,7 @@
>
> extern bool smccc_trng_available;
>
> -static inline bool __init smccc_probe_trng(void)
> +static inline bool smccc_probe_trng(void)
> {
> struct arm_smccc_res res;
>
> diff --git a/drivers/char/hw_random/arm_smccc_trng.c b/drivers/char/hw_random/arm_smccc_trng.c
> index dcb8e7f37f25..8f7f9d830cf2 100644
> --- a/drivers/char/hw_random/arm_smccc_trng.c
> +++ b/drivers/char/hw_random/arm_smccc_trng.c
> @@ -16,8 +16,10 @@
> #include <linux/device.h>
> #include <linux/hw_random.h>
> #include <linux/module.h>
> -#include <linux/platform_device.h>
> #include <linux/arm-smccc.h>
> +#include <linux/arm-smccc-bus.h>
> +
> +#include <asm/archrandom.h>
>
> #ifdef CONFIG_ARM64
> #define ARM_SMCCC_TRNG_RND ARM_SMCCC_TRNG_RND64
> @@ -94,29 +96,37 @@ static int smccc_trng_read(struct hwrng *rng, void *data, size_t max, bool wait)
> return copied;
> }
>
> -static int smccc_trng_probe(struct platform_device *pdev)
> +static int smccc_trng_probe(struct arm_smccc_device *sdev)
> {
> struct hwrng *trng;
>
> - trng = devm_kzalloc(&pdev->dev, sizeof(*trng), GFP_KERNEL);
> + /* validate the minimum version requirement */
> + if (!smccc_probe_trng())
> + return -ENODEV;
> +
> + trng = devm_kzalloc(&sdev->dev, sizeof(*trng), GFP_KERNEL);
> if (!trng)
> return -ENOMEM;
>
> trng->name = "smccc_trng";
> trng->read = smccc_trng_read;
>
> - return devm_hwrng_register(&pdev->dev, trng);
> + return devm_hwrng_register(&sdev->dev, trng);
> }
>
> -static struct platform_driver smccc_trng_driver = {
> - .driver = {
> - .name = "smccc_trng",
> - },
> - .probe = smccc_trng_probe,
> +static const struct arm_smccc_device_id smccc_trng_id_table[] = {
> + { .name = "arm-smccc-trng" },
> + {}
> +};
> +MODULE_DEVICE_TABLE(arm_smccc, smccc_trng_id_table);
> +
> +static struct arm_smccc_driver smccc_trng_driver = {
> + .name = KBUILD_MODNAME,
> + .probe = smccc_trng_probe,
> + .id_table = smccc_trng_id_table,
> };
> -module_platform_driver(smccc_trng_driver);
> +module_arm_smccc_driver(smccc_trng_driver);
>
> -MODULE_ALIAS("platform:smccc_trng");
> MODULE_AUTHOR("Andre Przywara");
> MODULE_DESCRIPTION("Arm SMCCC TRNG firmware interface support");
> MODULE_LICENSE("GPL");
> diff --git a/drivers/firmware/smccc/smccc.c b/drivers/firmware/smccc/smccc.c
> index bdee057db2fd..a47696f3a5de 100644
> --- a/drivers/firmware/smccc/smccc.c
> +++ b/drivers/firmware/smccc/smccc.c
> @@ -9,7 +9,8 @@
> #include <linux/init.h>
> #include <linux/arm-smccc.h>
> #include <linux/kernel.h>
> -#include <linux/platform_device.h>
> +#include <linux/arm-smccc-bus.h>
> +
> #include <asm/archrandom.h>
>
> static u32 smccc_version = ARM_SMCCC_VERSION_1_0;
> @@ -81,16 +82,55 @@ bool arm_smccc_hypervisor_has_uuid(const uuid_t *hyp_uuid)
> }
> EXPORT_SYMBOL_GPL(arm_smccc_hypervisor_has_uuid);
>
> +struct smccc_device_info {
> + u32 func_id;
> + bool requires_smc;
> + const char *device_name;
> +};
> +
> +static const struct smccc_device_info smccc_devices[] __initconst = {
> + {
> + .func_id = ARM_SMCCC_TRNG_VERSION,
> + .requires_smc = false,
> + .device_name = "arm-smccc-trng",
> + },
> +};
> +
> +static bool __init smccc_probe_smccc_device(const struct smccc_device_info *smccc_dev)
> +{
> + unsigned long ret;
> + struct arm_smccc_res res;
> +
> + if (smccc_conduit == SMCCC_CONDUIT_NONE)
> + return false;
> +
> + if (smccc_dev->requires_smc && smccc_conduit != SMCCC_CONDUIT_SMC)
> + return false;
> +
> + arm_smccc_1_1_invoke(smccc_dev->func_id, &res);
> + ret = res.a0;
Mostly a nit:
Why the assignment to a variable of the same type here? Wouldn't it be
cleaner to let "ret" be an "int"? Then you can save the cast below.
Or drop the assignment, and just cast res.a0 below directly.
In any case, I tested this in a KVM guest, and it worked flawlessly: the
device is created, works, and sysfs looks good, both with this file
compiled in (=y), and also as a module. Module autoloading also seems to
work.
So that's:
Tested-by: Andre Przywara <andre.przywara@arm.com>
Cheers,
Andre.
> +
> + if ((s32)ret == SMCCC_RET_NOT_SUPPORTED)
> + return false;
> +
> + return true;
> +}
> +
> static int __init smccc_devices_init(void)
> {
> - struct platform_device *pdev;
> -
> - if (smccc_trng_available) {
> - pdev = platform_device_register_simple("smccc_trng", -1,
> - NULL, 0);
> - if (IS_ERR(pdev))
> - pr_err("smccc_trng: could not register device: %ld\n",
> - PTR_ERR(pdev));
> + struct arm_smccc_device *sdev;
> + const struct smccc_device_info *smccc_dev;
> +
> + for (int i = 0; i < ARRAY_SIZE(smccc_devices); i++) {
> + smccc_dev = &smccc_devices[i];
> +
> + if (!smccc_probe_smccc_device(smccc_dev))
> + continue;
> +
> + sdev = arm_smccc_device_register(smccc_dev->device_name);
> + if (IS_ERR(sdev))
> + pr_err("%s: could not register device: %ld\n",
> + smccc_dev->device_name, PTR_ERR(sdev));
> }
>
> return 0;
^ permalink raw reply
* Re: [PATCH v2] dmaengine: sun6i-dma: Fix use-after-free in error handling paths
From: Jernej Škrabec @ 2026-06-15 15:13 UTC (permalink / raw)
To: vkoul, Frank.Li, wens, samuel, mripard, arnd, Hongling Zeng
Cc: dmaengine, linux-arm-kernel, linux-sunxi, linux-kernel,
zhongling0719, Hongling Zeng
In-Reply-To: <20260615022400.13454-1-zenghongling@kylinos.cn>
Dne ponedeljek, 15. junij 2026 ob 04:23:59 Srednjeevropski poletni čas je Hongling Zeng napisal(a):
> In error handling paths, the for loop frees v_lli in the loop body,
> then accesses v_lli->v_lli_next and v_lli->p_lli_next in the
> increment expression, which is use-after-free.
>
> Fix by saving both the next virtual and physical pointers before
> freeing the current node.
>
> Fixes: 555859308723 ("dmaengine: Add driver for Allwinner sun6i DMA")
> Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
> Suggested-by: Jernej Skrabec <jernej.skrabec@gmail.com>
>
> ---
> Changes in v2:
> -Refactored the fix to avoid code duplication by creating a helper function
> sun6i_dma_free_lli_list() that handles LLI list cleanup
> -Add Suggested-by: Jernej Skrabec <jernej.skrabec@gmail.com>
> ---
> drivers/dma/sun6i-dma.c | 26 ++++++++++++++------------
> 1 file changed, 14 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
> index a9a254dbf8cb..02dd07001d5a 100644
> --- a/drivers/dma/sun6i-dma.c
> +++ b/drivers/dma/sun6i-dma.c
> @@ -406,16 +406,12 @@ static inline void sun6i_dma_dump_lli(struct sun6i_vchan *vchan,
> v_lli->len, v_lli->para, v_lli->p_lli_next);
> }
>
> -static void sun6i_dma_free_desc(struct virt_dma_desc *vd)
> +static void sun6i_dma_free_lli_list(struct sun6i_dma_dev *sdev,
> + struct sun6i_desc *txd)
> {
> - struct sun6i_desc *txd = to_sun6i_desc(&vd->tx);
> - struct sun6i_dma_dev *sdev = to_sun6i_dma_dev(vd->tx.chan->device);
> struct sun6i_dma_lli *v_lli, *v_next;
> dma_addr_t p_lli, p_next;
>
> - if (unlikely(!txd))
> - return;
> -
> p_lli = txd->p_lli;
> v_lli = txd->v_lli;
>
> @@ -428,7 +424,17 @@ static void sun6i_dma_free_desc(struct virt_dma_desc *vd)
> v_lli = v_next;
> p_lli = p_next;
> }
> +}
>
> +static void sun6i_dma_free_desc(struct virt_dma_desc *vd)
> +{
> + struct sun6i_desc *txd = to_sun6i_desc(&vd->tx);
> + struct sun6i_dma_dev *sdev = to_sun6i_dma_dev(vd->tx.chan->device);
> +
> + if (unlikely(!txd))
> + return;
> +
> + sun6i_dma_free_lli_list(sdev, txd);
> kfree(txd);
Why not also move txd handling? That way even more code can be put in one place.
Best regards,
Jernej
> }
>
> @@ -788,9 +794,7 @@ static struct dma_async_tx_descriptor *sun6i_dma_prep_slave_sg(
> return vchan_tx_prep(&vchan->vc, &txd->vd, flags);
>
> err_lli_free:
> - for (p_lli = txd->p_lli, v_lli = txd->v_lli; v_lli;
> - p_lli = v_lli->p_lli_next, v_lli = v_lli->v_lli_next)
> - dma_pool_free(sdev->pool, v_lli, p_lli);
> + sun6i_dma_free_lli_list(sdev, txd);
> kfree(txd);
> return NULL;
> }
> @@ -869,9 +873,7 @@ static struct dma_async_tx_descriptor *sun6i_dma_prep_dma_cyclic(
> return vchan_tx_prep(&vchan->vc, &txd->vd, flags);
>
> err_lli_free:
> - for (p_lli = txd->p_lli, v_lli = txd->v_lli; v_lli;
> - p_lli = v_lli->p_lli_next, v_lli = v_lli->v_lli_next)
> - dma_pool_free(sdev->pool, v_lli, p_lli);
> + sun6i_dma_free_lli_list(sdev, txd);
> kfree(txd);
> return NULL;
> }
>
^ permalink raw reply
* [PATCH net] net: ethernet: mtk_eth_soc: fix supported_interface set after phylink_create
From: Christian Marangi @ 2026-06-15 15:11 UTC (permalink / raw)
To: Felix Fietkau, Lorenzo Bianconi, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Matthias Brugger,
AngeloGioacchino Del Regno, Russell King, Daniel Golle, netdev,
linux-kernel, linux-arm-kernel, linux-mediatek
Cc: Christian Marangi
Everything configured in phylink_config it's assumed to be set before
calling phylink_create() to permit correct parsing of all the different
modes and capabilities.
Commit 51cf06ddafc9 ("net: ethernet: mtk_eth_soc: add support for MT7988
internal 2.5G PHY") while introducing support for 2.5G phy for MT7988,
probably due to an auto-rebase, placed the configuration of the INTERNAL
interface mode for the supported_interfaces for phylink_config right after
phylink_create() introducing a possible problem with supported interfaces
parsing.
While this doesn't currently create any problem/bug, move setting this bit
before phylink_create() to prevent any possible regression in future code
change in phylink core.
Fixes: 51cf06ddafc9 ("net: ethernet: mtk_eth_soc: add support for MT7988 internal 2.5G PHY")
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
---
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 7d771168b990..5d291e50a47b 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -4960,6 +4960,11 @@ static int mtk_add_mac(struct mtk_eth *eth, struct device_node *np)
if (MTK_HAS_CAPS(eth->soc->caps, MTK_SOC_MT7628))
mac_ops = &rt5350_phylink_ops;
+ if (MTK_HAS_CAPS(mac->hw->soc->caps, MTK_2P5GPHY) &&
+ id == MTK_GMAC2_ID)
+ __set_bit(PHY_INTERFACE_MODE_INTERNAL,
+ mac->phylink_config.supported_interfaces);
+
phylink = phylink_create(&mac->phylink_config,
of_fwnode_handle(mac->of_node),
phy_mode, mac_ops);
@@ -4970,11 +4975,6 @@ static int mtk_add_mac(struct mtk_eth *eth, struct device_node *np)
mac->phylink = phylink;
- if (MTK_HAS_CAPS(mac->hw->soc->caps, MTK_2P5GPHY) &&
- id == MTK_GMAC2_ID)
- __set_bit(PHY_INTERFACE_MODE_INTERNAL,
- mac->phylink_config.supported_interfaces);
-
SET_NETDEV_DEV(eth->netdev[id], eth->dev);
eth->netdev[id]->watchdog_timeo = 5 * HZ;
eth->netdev[id]->netdev_ops = &mtk_netdev_ops;
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] KVM: arm64: Sync SPSR_EL1 when injecting an exception into a pVM
From: Will Deacon @ 2026-06-15 15:10 UTC (permalink / raw)
To: Fuad Tabba
Cc: Marc Zyngier, Oliver Upton, linux-arm-kernel, kvmarm,
linux-kernel, Joey Gouly, Steffen Eiden, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Sascha Bischoff, Andrew Jones
In-Reply-To: <CA+EHjTzL4GKw8RQrGnMq81Ohquo48_L4-MNJrCdGnBpMPR7XcA@mail.gmail.com>
On Mon, Jun 15, 2026 at 04:03:17PM +0100, Fuad Tabba wrote:
> On Mon, 15 Jun 2026 at 15:42, Will Deacon <will@kernel.org> wrote:
> >
> > On Mon, Jun 15, 2026 at 11:52:10AM +0100, Fuad Tabba wrote:
> > > On Mon, 15 Jun 2026 at 11:05, Will Deacon <will@kernel.org> wrote:
> > > >
> > > > On Fri, Jun 12, 2026 at 12:34:14PM +0100, Fuad Tabba wrote:
> > > > > When pKVM injects a synchronous exception into a protected guest, it
> > > > > re-enters without restoring the guest's EL1 sysregs and writes the EL1
> > > > > exception registers to hardware by hand: ESR_EL1 and ELR_EL1, but not
> > > > > SPSR_EL1. enter_exception64() sets SPSR_EL1 (the interrupted PSTATE)
> > > > > only in memory, so the guest's handler reads a stale SPSR_EL1 and
> > > > > restores the wrong PSTATE on eret.
> > > > >
> > > > > Write SPSR_EL1 alongside the other exception registers.
> > > > >
> > > > > Fixes: 6c30bfb18d0b ("KVM: arm64: Add handlers for protected VM System Registers")
> > > > > Reported-by: sashiko <sashiko@sashiko.dev>
> > > > > Signed-off-by: Fuad Tabba <tabba@google.com>
> > > > > ---
> > > > > arch/arm64/kvm/hyp/nvhe/sys_regs.c | 1 +
> > > > > 1 file changed, 1 insertion(+)
> > > > >
> > > > > diff --git a/arch/arm64/kvm/hyp/nvhe/sys_regs.c b/arch/arm64/kvm/hyp/nvhe/sys_regs.c
> > > > > index 8c3fbb413a06..1a7d5cd16d72 100644
> > > > > --- a/arch/arm64/kvm/hyp/nvhe/sys_regs.c
> > > > > +++ b/arch/arm64/kvm/hyp/nvhe/sys_regs.c
> > > > > @@ -268,6 +268,7 @@ static void inject_sync64(struct kvm_vcpu *vcpu, u64 esr)
> > > > >
> > > > > write_sysreg_el1(esr, SYS_ESR);
> > > > > write_sysreg_el1(read_sysreg_el2(SYS_ELR), SYS_ELR);
> > > > > + write_sysreg_el1(read_sysreg_el2(SYS_SPSR), SYS_SPSR);
> > > > > write_sysreg_el2(*vcpu_pc(vcpu), SYS_ELR);
> > > > > write_sysreg_el2(*vcpu_cpsr(vcpu), SYS_SPSR);
> > > > > }
> > > >
> > > > Is SPSR_EL1 not set in enter_exception64() using vcpu_cpsr(vcpu), which
> > > > *is* set here? I'm just a bit wary of the report, as I'd have expected
> > > > fireworks if we weren't initialising the guest's SPSR on the exception
> > > > injection path.
> > >
> > > Yes, enter_exception64() sets SPSR_EL1, but only in memory:
> > > __vcpu_write_spsr() takes the nVHE path and calls
> > > __vcpu_assign_sys_reg(vcpu, SPSR_EL1, val), which writes
> > > vcpu->arch.ctxt.sys_regs[SPSR_EL1] without touching the hardware
> > > register.
> > >
> > > In the normal nVHE entry path that memory value reaches hardware via
> > > __sysreg_restore_state_nvhe() before __guest_enter(). But
> > > inject_sync64() runs inside the fixup_guest_exit() loop, which
> > > re-enters the guest directly without a sysreg restore pass. ESR_EL1
> > > and ELR_EL1 are already written to hardware by hand for this reason
> > > but SPSR_EL1 was missed.
> >
> > Ah, I see. Does that mean that all the in-memory updates performed by
> > enter_exception64() (e.g. the construction of the cpsr) are ignored too?
>
> From looking at the code, no. inject_sync64() reads back the cpsr and
> PC that enter_exception64() computed in memory and writes them to
> hardware:
>
> write_sysreg_el2(*vcpu_pc(vcpu), SYS_ELR);
> write_sysreg_el2(*vcpu_cpsr(vcpu), SYS_SPSR);
>
> So the guest re-enters with the right PSTATE. The only value left
> stranded in memory is SPSR_EL1.
Ah, thanks. I had pissed that inject_sync64() calls __kvm_adjust_pc()
immediately after pending the exception. So you've convinced me:
Acked-by: Will Deacon <will@kernel.org>
Will
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Sync SPSR_EL1 when injecting an exception into a pVM
From: Fuad Tabba @ 2026-06-15 15:03 UTC (permalink / raw)
To: Will Deacon
Cc: Marc Zyngier, Oliver Upton, linux-arm-kernel, kvmarm,
linux-kernel, Joey Gouly, Steffen Eiden, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Sascha Bischoff, Andrew Jones
In-Reply-To: <ajAPNFDsQ63k_jAS@willie-the-truck>
On Mon, 15 Jun 2026 at 15:42, Will Deacon <will@kernel.org> wrote:
>
> On Mon, Jun 15, 2026 at 11:52:10AM +0100, Fuad Tabba wrote:
> > On Mon, 15 Jun 2026 at 11:05, Will Deacon <will@kernel.org> wrote:
> > >
> > > On Fri, Jun 12, 2026 at 12:34:14PM +0100, Fuad Tabba wrote:
> > > > When pKVM injects a synchronous exception into a protected guest, it
> > > > re-enters without restoring the guest's EL1 sysregs and writes the EL1
> > > > exception registers to hardware by hand: ESR_EL1 and ELR_EL1, but not
> > > > SPSR_EL1. enter_exception64() sets SPSR_EL1 (the interrupted PSTATE)
> > > > only in memory, so the guest's handler reads a stale SPSR_EL1 and
> > > > restores the wrong PSTATE on eret.
> > > >
> > > > Write SPSR_EL1 alongside the other exception registers.
> > > >
> > > > Fixes: 6c30bfb18d0b ("KVM: arm64: Add handlers for protected VM System Registers")
> > > > Reported-by: sashiko <sashiko@sashiko.dev>
> > > > Signed-off-by: Fuad Tabba <tabba@google.com>
> > > > ---
> > > > arch/arm64/kvm/hyp/nvhe/sys_regs.c | 1 +
> > > > 1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/arch/arm64/kvm/hyp/nvhe/sys_regs.c b/arch/arm64/kvm/hyp/nvhe/sys_regs.c
> > > > index 8c3fbb413a06..1a7d5cd16d72 100644
> > > > --- a/arch/arm64/kvm/hyp/nvhe/sys_regs.c
> > > > +++ b/arch/arm64/kvm/hyp/nvhe/sys_regs.c
> > > > @@ -268,6 +268,7 @@ static void inject_sync64(struct kvm_vcpu *vcpu, u64 esr)
> > > >
> > > > write_sysreg_el1(esr, SYS_ESR);
> > > > write_sysreg_el1(read_sysreg_el2(SYS_ELR), SYS_ELR);
> > > > + write_sysreg_el1(read_sysreg_el2(SYS_SPSR), SYS_SPSR);
> > > > write_sysreg_el2(*vcpu_pc(vcpu), SYS_ELR);
> > > > write_sysreg_el2(*vcpu_cpsr(vcpu), SYS_SPSR);
> > > > }
> > >
> > > Is SPSR_EL1 not set in enter_exception64() using vcpu_cpsr(vcpu), which
> > > *is* set here? I'm just a bit wary of the report, as I'd have expected
> > > fireworks if we weren't initialising the guest's SPSR on the exception
> > > injection path.
> >
> > Yes, enter_exception64() sets SPSR_EL1, but only in memory:
> > __vcpu_write_spsr() takes the nVHE path and calls
> > __vcpu_assign_sys_reg(vcpu, SPSR_EL1, val), which writes
> > vcpu->arch.ctxt.sys_regs[SPSR_EL1] without touching the hardware
> > register.
> >
> > In the normal nVHE entry path that memory value reaches hardware via
> > __sysreg_restore_state_nvhe() before __guest_enter(). But
> > inject_sync64() runs inside the fixup_guest_exit() loop, which
> > re-enters the guest directly without a sysreg restore pass. ESR_EL1
> > and ELR_EL1 are already written to hardware by hand for this reason
> > but SPSR_EL1 was missed.
>
> Ah, I see. Does that mean that all the in-memory updates performed by
> enter_exception64() (e.g. the construction of the cpsr) are ignored too?
From looking at the code, no. inject_sync64() reads back the cpsr and
PC that enter_exception64() computed in memory and writes them to
hardware:
write_sysreg_el2(*vcpu_pc(vcpu), SYS_ELR);
write_sysreg_el2(*vcpu_cpsr(vcpu), SYS_SPSR);
So the guest re-enters with the right PSTATE. The only value left
stranded in memory is SPSR_EL1.
Cheers,
/fuad
>
> Will
^ permalink raw reply
* Re: [PATCH v9 2/9] drm/bridge: fsl-ldb: Get the next non-panel bridge
From: Frank Li @ 2026-06-15 15:02 UTC (permalink / raw)
To: Laurentiu Palcu
Cc: Ying Liu, Luca Ceresoli, Andrzej Hajda, Neil Armstrong,
Robert Foss, Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, linux-clk, imx, devicetree, linux-arm-kernel,
linux-kernel, dri-devel
In-Reply-To: <20260612-dcif-upstreaming-v9-2-8d0ff89aa3c5@oss.nxp.com>
On Fri, Jun 12, 2026 at 02:58:33PM +0300, Laurentiu Palcu wrote:
> From: Liu Ying <victor.liu@nxp.com>
>
> The next bridge in bridge chain could be a panel bridge or a non-panel
> bridge. Use devm_drm_of_get_bridge() to replace the combination
> function calls of of_drm_find_panel() and devm_drm_panel_bridge_add()
> to get either a panel bridge or a non-panel bridge, instead of getting
> a panel bridge only.
>
> Signed-off-by: Liu Ying <victor.liu@nxp.com>
> Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> drivers/gpu/drm/bridge/fsl-ldb.c | 31 ++++++++++++-------------------
> 1 file changed, 12 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/fsl-ldb.c b/drivers/gpu/drm/bridge/fsl-ldb.c
> index 9bfaa3f933709..bd03c36ee696c 100644
> --- a/drivers/gpu/drm/bridge/fsl-ldb.c
> +++ b/drivers/gpu/drm/bridge/fsl-ldb.c
> @@ -15,7 +15,6 @@
> #include <drm/drm_atomic_helper.h>
> #include <drm/drm_bridge.h>
> #include <drm/drm_of.h>
> -#include <drm/drm_panel.h>
>
> #define LDB_CTRL_CH0_ENABLE BIT(0)
> #define LDB_CTRL_CH0_DI_SELECT BIT(1)
> @@ -86,7 +85,6 @@ static const struct fsl_ldb_devdata fsl_ldb_devdata[] = {
> struct fsl_ldb {
> struct device *dev;
> struct drm_bridge bridge;
> - struct drm_bridge *panel_bridge;
> struct clk *clk;
> struct regmap *regmap;
> const struct fsl_ldb_devdata *devdata;
> @@ -119,7 +117,7 @@ static int fsl_ldb_attach(struct drm_bridge *bridge,
> {
> struct fsl_ldb *fsl_ldb = to_fsl_ldb(bridge);
>
> - return drm_bridge_attach(encoder, fsl_ldb->panel_bridge,
> + return drm_bridge_attach(encoder, fsl_ldb->bridge.next_bridge,
> bridge, flags);
> }
>
> @@ -296,9 +294,8 @@ static const struct drm_bridge_funcs funcs = {
> static int fsl_ldb_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> - struct device_node *panel_node;
> struct device_node *remote1, *remote2;
> - struct drm_panel *panel;
> + struct drm_bridge *next_bridge;
> struct fsl_ldb *fsl_ldb;
> int dual_link;
>
> @@ -321,36 +318,32 @@ static int fsl_ldb_probe(struct platform_device *pdev)
> if (IS_ERR(fsl_ldb->regmap))
> return PTR_ERR(fsl_ldb->regmap);
>
> - /* Locate the remote ports and the panel node */
> + /* Locate the remote ports. */
> remote1 = of_graph_get_remote_node(dev->of_node, 1, 0);
> remote2 = of_graph_get_remote_node(dev->of_node, 2, 0);
> fsl_ldb->ch0_enabled = (remote1 != NULL);
> fsl_ldb->ch1_enabled = (remote2 != NULL);
> - panel_node = of_node_get(remote1 ? remote1 : remote2);
> of_node_put(remote1);
> of_node_put(remote2);
>
> - if (!fsl_ldb->ch0_enabled && !fsl_ldb->ch1_enabled) {
> - of_node_put(panel_node);
> - return dev_err_probe(dev, -ENXIO, "No panel node found");
> - }
> + if (!fsl_ldb->ch0_enabled && !fsl_ldb->ch1_enabled)
> + return dev_err_probe(dev, -ENXIO, "No next bridge node found");
>
> dev_dbg(dev, "Using %s\n",
> fsl_ldb_is_dual(fsl_ldb) ? "dual-link mode" :
> fsl_ldb->ch0_enabled ? "channel 0" : "channel 1");
>
> - panel = of_drm_find_panel(panel_node);
> - of_node_put(panel_node);
> - if (IS_ERR(panel))
> - return PTR_ERR(panel);
> -
> if (of_property_present(dev->of_node, "nxp,enable-termination-resistor"))
> fsl_ldb->use_termination_resistor = true;
>
> - fsl_ldb->panel_bridge = devm_drm_panel_bridge_add(dev, panel);
> - if (IS_ERR(fsl_ldb->panel_bridge))
> - return PTR_ERR(fsl_ldb->panel_bridge);
> + next_bridge = devm_drm_of_get_bridge(dev, dev->of_node,
> + fsl_ldb->ch0_enabled ? 1 : 2,
> + 0);
> + if (IS_ERR(next_bridge))
> + return dev_err_probe(dev, PTR_ERR(next_bridge),
> + "failed to get next bridge\n");
>
> + fsl_ldb->bridge.next_bridge = drm_bridge_get(next_bridge);
>
> if (fsl_ldb_is_dual(fsl_ldb)) {
> struct device_node *port1, *port2;
>
> --
> 2.51.0
>
^ permalink raw reply
* Re: [PATCH v9 4/9] dt-bindings: display: imx: Add i.MX94 DCIF
From: Frank Li @ 2026-06-15 15:01 UTC (permalink / raw)
To: Laurentiu Palcu
Cc: Ying Liu, Luca Ceresoli, Philipp Zabel, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, linux-clk,
imx, devicetree, linux-arm-kernel, linux-kernel, dri-devel
In-Reply-To: <20260612-dcif-upstreaming-v9-4-8d0ff89aa3c5@oss.nxp.com>
On Fri, Jun 12, 2026 at 02:58:35PM +0300, Laurentiu Palcu wrote:
>
> DCIF is the i.MX94 Display Controller Interface which is used to
> drive a TFT LCD panel or connects to a display interface depending
> on the chip configuration.
>
> Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
> ---
> .../bindings/display/imx/nxp,imx94-dcif.yaml | 90 ++++++++++++++++++++++
> 1 file changed, 90 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/imx/nxp,imx94-dcif.yaml b/Documentation/devicetree/bindings/display/imx/nxp,imx94-dcif.yaml
> new file mode 100644
> index 0000000000000..8894e87666972
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/imx/nxp,imx94-dcif.yaml
> @@ -0,0 +1,90 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +# Copyright 2025 NXP
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/imx/nxp,imx94-dcif.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: i.MX94 Display Control Interface (DCIF)
> +
> +maintainers:
> + - Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
> +
> +description:
> + The Display Control Interface(DCIF) is a system master that fetches graphics
> + stored in memory and displays them on a TFT LCD panel or connects to a
> + display interface depending on the chip configuration.
> +
> +properties:
> + compatible:
> + const: nxp,imx94-dcif
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + items:
> + - description: CPU domain 0 (controlled by common registers group).
> + - description: CPU domain 1 (controlled by background layer registers group).
> + - description: CPU domain 2 (controlled by foreground layer registers group).
> +
> + interrupt-names:
> + items:
> + - const: common
> + - const: bg_layer
> + - const: fg_layer
> +
> + clocks:
> + maxItems: 3
> +
> + clock-names:
> + items:
> + - const: apb
> + - const: axi
> + - const: pix
> +
> + power-domains:
> + maxItems: 1
> +
> + port:
> + $ref: /schemas/graph.yaml#/$defs/port-base
> + unevaluatedProperties: false
> + description: Display Pixel Interface(DPI) output port
> +
> + properties:
> + endpoint:
> + $ref: /schemas/media/video-interfaces.yaml#
> + unevaluatedProperties: false
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - clocks
> + - power-domains
> + - port
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> + display-controller@4b120000 {
> + compatible = "nxp,imx94-dcif";
> + reg = <0x4b120000 0x300000>;
> + interrupts = <GIC_SPI 377 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 378 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 379 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "common", "bg_layer", "fg_layer";
> + clocks = <&scmi_clk 69>, <&scmi_clk 70>, <&dispmix_csr 0>;
> + clock-names = "apb", "axi", "pix";
> + assigned-clocks = <&dispmix_csr 0>;
> + assigned-clock-parents = <&ldb_pll_pixel>;
> + power-domains = <&scmi_devpd 11>;
Nit: need extra empty line here
> + port {
> + dcif_out: endpoint {
Needn't label here for example
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> + remote-endpoint = <&ldb_in>;
> + };
> + };
> + };
>
> --
> 2.51.0
>
^ permalink raw reply
* Re: [PATCH v2] arm64: errata: Handle Apple WFI State Loss
From: Will Deacon @ 2026-06-15 15:02 UTC (permalink / raw)
To: Yureka Lilian
Cc: Catalin Marinas, linux-arm-kernel, linux-kernel, asahi,
Sasha Finkelstein
In-Reply-To: <20260615-wfi-erratum-v2-1-59a73467f70d@cyberchaos.dev>
On Mon, Jun 15, 2026 at 02:21:36PM +0200, Yureka Lilian wrote:
> Apple Silicon CPUs can lose register state in WFI, leading to crashes
> in the idle loop early in the boot process.
> This applies to any previous Apple Silicon CPUs too, but is worked
> around by configuring the WFI mode in SYS_IMP_APL_CYC_OVRD sysreg
> during m1n1's chickens setup.
> This workaround no longer exists since M4.
>
> Add a workaround capability for replacing wfi and wfit with nop, and
> an erratum to enable it on the affected CPUs if the workaround using the
> sysreg is not already applied. Leave the decision whether the sysreg
> workaround can be used up to the earlier parts of the boot chain which
> already configure the Apple Silicon chicken bits.
>
> This alternative has to be applied in early boot, since otherwise some
> cores might enter the idle loop before apply_alternatives_all() is run.
>
> Reviewed-by: Sasha Finkelstein <k@chaosmail.tech>
> Signed-off-by: Yureka Lilian <yureka@cyberchaos.dev>
> ---
> Changes since v1:
> Restricted the erratum to EL2 only, since in EL1 we'd expect the
> hypervisor to trap WFI and handle the erratum.
>
> Tested on M4 and M4 Pro (which now sometimes nondeterministically
> crash later during boot).
> Successfully booted on M3 Max with the SYS_IMP_APL_CYC_OVRD
> workaround disabled in the bootloader, as well as A18 Pro (which,
> like M4 / M4 Pro, doesn't have SYS_IMP_APL_CYC_OVRD).
>
> There is probably a better place for the SYS_IMP_APL_CYC_OVRD
> defines, which I currently put in the middle of cpu_errata.c, but I
> wouldn't know where.
> ---
> arch/arm64/Kconfig | 12 ++++++++++++
> arch/arm64/include/asm/barrier.h | 19 ++++++++++++++++---
> arch/arm64/kernel/cpu_errata.c | 21 +++++++++++++++++++++
> arch/arm64/tools/cpucaps | 1 +
> 4 files changed, 50 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index b3afe0688919..8c8ff069856f 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -453,6 +453,18 @@ config AMPERE_ERRATUM_AC04_CPU_23
>
> If unsure, say Y.
>
> +config APPLE_ERRATUM_WFI_STATE
> + bool "Apple Silicon: WFI loses state"
> + default y
> + help
> + This option adds an alternative code sequence to work around some
> + Apple Silicon CPUs losing register state during wfi and wfit
> + instructions.
> +
> + As a workaround, the wfi and wfit instructions are replaced with nop
> + operations via the alternative framework if an affected CPU is
> + detected.
> +
> config ARM64_WORKAROUND_CLEAN_CACHE
> bool
>
> diff --git a/arch/arm64/include/asm/barrier.h b/arch/arm64/include/asm/barrier.h
> index 9495c4441a46..f72eddc7c434 100644
> --- a/arch/arm64/include/asm/barrier.h
> +++ b/arch/arm64/include/asm/barrier.h
> @@ -20,9 +20,22 @@
> #define wfe() asm volatile("wfe" : : : "memory")
> #define wfet(val) asm volatile("msr s0_3_c1_c0_0, %0" \
> : : "r" (val) : "memory")
> -#define wfi() asm volatile("wfi" : : : "memory")
> -#define wfit(val) asm volatile("msr s0_3_c1_c0_1, %0" \
> - : : "r" (val) : "memory")
> +#define wfi() \
> + do { \
> + asm volatile( \
> + ALTERNATIVE("wfi", \
> + "nop", \
> + ARM64_WORKAROUND_WFI_STATE) \
> + : : : "memory"); \
> + } while (0)
> +#define wfit(val) \
> + do { \
> + asm volatile( \
> + ALTERNATIVE("msr s0_3_c1_c0_1, %0", \
> + "nop", \
> + ARM64_WORKAROUND_WFI_STATE) \
> + : : "r" (val) : "memory"); \
> + } while (0)
How can you guarantee that we don't run one of these prior to patching?
I wonder if we're better off doing something like x86 and having an "idle="
cmdline option. which could choose between e.g. nop, wfe, wfi and yield, for
example? In fact, would wfe be a better choice than nop for you?
Will
^ permalink raw reply
* Re: [PATCH v9 3/9] drm/bridge: fsl-ldb: Add support for i.MX94
From: Frank Li @ 2026-06-15 15:00 UTC (permalink / raw)
To: Laurentiu Palcu
Cc: Ying Liu, Luca Ceresoli, Andrzej Hajda, Neil Armstrong,
Robert Foss, Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, linux-clk, imx, devicetree, linux-arm-kernel,
linux-kernel, dri-devel
In-Reply-To: <20260612-dcif-upstreaming-v9-3-8d0ff89aa3c5@oss.nxp.com>
On Fri, Jun 12, 2026 at 02:58:34PM +0300, Laurentiu Palcu wrote:
>
> i.MX94 series LDB controller shares the same LDB and LVDS control
> registers as i.MX8MP and i.MX93 but supports a higher maximum clock
> frequency.
>
> Add a 'max_clk_khz' member to the fsl_ldb_devdata structure in order to
> be able to set different max frequencies for other platforms.
>
> Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> drivers/gpu/drm/bridge/fsl-ldb.c | 15 ++++++++++++++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/fsl-ldb.c b/drivers/gpu/drm/bridge/fsl-ldb.c
> index bd03c36ee696c..b4959f654f2ac 100644
> --- a/drivers/gpu/drm/bridge/fsl-ldb.c
> +++ b/drivers/gpu/drm/bridge/fsl-ldb.c
> @@ -57,6 +57,7 @@ enum fsl_ldb_devtype {
> IMX6SX_LDB,
> IMX8MP_LDB,
> IMX93_LDB,
> + IMX94_LDB,
> };
>
> struct fsl_ldb_devdata {
> @@ -64,21 +65,31 @@ struct fsl_ldb_devdata {
> u32 lvds_ctrl;
> bool lvds_en_bit;
> bool single_ctrl_reg;
> + u32 max_clk_khz;
> };
>
> static const struct fsl_ldb_devdata fsl_ldb_devdata[] = {
> [IMX6SX_LDB] = {
> .ldb_ctrl = 0x18,
> .single_ctrl_reg = true,
> + .max_clk_khz = 80000,
> },
> [IMX8MP_LDB] = {
> .ldb_ctrl = 0x5c,
> .lvds_ctrl = 0x128,
> + .max_clk_khz = 80000,
> },
> [IMX93_LDB] = {
> .ldb_ctrl = 0x20,
> .lvds_ctrl = 0x24,
> .lvds_en_bit = true,
> + .max_clk_khz = 80000,
> + },
> + [IMX94_LDB] = {
> + .ldb_ctrl = 0x04,
> + .lvds_ctrl = 0x08,
> + .lvds_en_bit = true,
> + .max_clk_khz = 148500,
> },
> };
>
> @@ -274,7 +285,7 @@ fsl_ldb_mode_valid(struct drm_bridge *bridge,
> {
> struct fsl_ldb *fsl_ldb = to_fsl_ldb(bridge);
>
> - if (mode->clock > (fsl_ldb_is_dual(fsl_ldb) ? 160000 : 80000))
> + if (mode->clock > (fsl_ldb_is_dual(fsl_ldb) ? 2 : 1) * fsl_ldb->devdata->max_clk_khz)
> return MODE_CLOCK_HIGH;
>
> return MODE_OK;
> @@ -386,6 +397,8 @@ static const struct of_device_id fsl_ldb_match[] = {
> .data = &fsl_ldb_devdata[IMX8MP_LDB], },
> { .compatible = "fsl,imx93-ldb",
> .data = &fsl_ldb_devdata[IMX93_LDB], },
> + { .compatible = "fsl,imx94-ldb",
> + .data = &fsl_ldb_devdata[IMX94_LDB], },
> { /* sentinel */ },
> };
> MODULE_DEVICE_TABLE(of, fsl_ldb_match);
>
> --
> 2.51.0
>
^ permalink raw reply
* Re: [PATCH v9 5/9] drm/imx: Add support for i.MX94 DCIF
From: Frank Li @ 2026-06-15 14:58 UTC (permalink / raw)
To: Laurentiu Palcu
Cc: Ying Liu, Luca Ceresoli, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, linux-clk,
imx, devicetree, linux-arm-kernel, linux-kernel, dri-devel
In-Reply-To: <20260612-dcif-upstreaming-v9-5-8d0ff89aa3c5@oss.nxp.com>
On Fri, Jun 12, 2026 at 02:58:36PM +0300, Laurentiu Palcu wrote:
> The i.MX94 Display Control Interface features:
> * Up to maximum 3 layers of alpha blending:
> - 1 background layer(Layer 0);
> - 1 foreground layer(Layer 1);
> - A programmable constant color behind the background layer;
> * Each layer supports:
> - programmable plane size;
> - programmable background color;
> - embedded alpha and global alpha;
> * Data output with CRC checksum for 4 programmable regions;
>
> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> # bridge refcounting
> Signed-off-by: Sandor Yu <sandor.yu@nxp.com>
> Co-developed-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
> Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH v2] arm64: tlbflush: Don't broadcast if mm was only active on local cpu
From: Will Deacon @ 2026-06-15 14:44 UTC (permalink / raw)
To: Mark Rutland
Cc: Linu Cherian, Catalin Marinas, Ryan Roberts, Kevin Brodsky,
Anshuman Khandual, Yang Shi, Huang Ying, linux-arm-kernel,
linux-kernel
In-Reply-To: <ai_yj7GA_q1hD9cr@J2N7QTR9R3.cambridge.arm.com>
On Mon, Jun 15, 2026 at 01:39:43PM +0100, Mark Rutland wrote:
> On Sun, Jun 14, 2026 at 12:04:44PM +0100, Will Deacon wrote:
> > On Sat, May 23, 2026 at 07:17:10PM +0530, Linu Cherian wrote:
>
> > > static inline void flush_tlb_mm(struct mm_struct *mm)
> > > {
> > > unsigned long asid;
> > > + bool local;
> > >
> > > - dsb(ishst);
> > > + local = flush_tlb_user_pre(mm, TLBF_NONE);
> > > asid = __TLBI_VADDR(0, ASID(mm));
> > > - __tlbi(aside1is, asid);
> > > - __tlbi_user(aside1is, asid);
> > > - __tlbi_sync_s1ish(mm);
> > > + if (local) {
> > > + __tlbi(aside1, asid);
> > > + __tlbi_user(aside1, asid);
> > > + dsb(nsh);
> > > + } else {
> > > + __tlbi(aside1is, asid);
> > > + __tlbi_user(aside1is, asid);
> > > + __tlbi_sync_s1ish(mm);
> > > + }
> > > + flush_tlb_user_post(local);
> >
> > I think you've changed this since Ryan's original patch, but why are you
> > only calling __tlbi_sync_s1ish() for the !local case? Doesn't that break
> > the erratum workaround when running as a VM if the vCPU is migrated?
>
> The errata mitigated by __tlbi_sync_s1ish() only affect broadcast
> maintenance (the 'ish' in the name was intended to convey that). No
> workaround is necessary for local TLB maintenance; aside from anything
> else, when some PE executes the DSB to complete the maintenance, that
> DSB alone is sufficient to complete memory accesses made by that PE.
>
> If it would make things clearer, we could add a __tlbi_sync_s1nsh()
> helper for the local case, which would boil down to a DSB NSH.
No, I don't think that's what I'm concerned about.
> Regardless of the erratum, to correctly handle a vCPU being migrated
> from pCPU-x to pCPU-y, we rely on:
>
> * The host to set HCR_EL2.FB to ensure that TLB maintenance is
> broadcast to the ISH domain.
>
> * The host to set HCR_EL2.BSU to ensure the DSB is upgrade to ISH such
> that any guest-issued DSB NSH will it can complete any TLB maintenance
> that was upgraded to ISH.
>
> * The host to issue a DSB ISH on pCPU-x before the vCPU can run on
> pCPU-y, to complete any outstanding maintenance that was issued on
> pCPU-x. IIUC a DSB ISH on pCPU-y is not architecturally sufficient; it
> must be executed on the same CPU which issued the TLB maintenance.
>
> ... but as above, all of that should be independent of any of the errata
> that require the workaround.
Yes, I understand all of the above but the case I'm struggling with is
where a vCPU runs on a system that needs the TLB invalidation to be
performed twice. For non-broadcast invalidation (from the guest
perspective), this patch will mean that it only performs the
invalidation once. So if the vCPU migrates to another physical CPU, can
that effectively undo the HCR_EL2.FB upgrade unless KVM issues TLB
invalidation as well as a DSB on migration?
Maybe I'm missing something, as it looks like upstream already elides
the call to __tlbi_sync_s1ish() for the NOBROADCAST case.
Will
^ permalink raw reply
* Re: [PATCH net-next v7 05/12] net: phylink: support late PCS provider attach
From: Maxime Chevallier @ 2026-06-15 14:44 UTC (permalink / raw)
To: Christian Marangi
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Simon Horman, Jonathan Corbet, Shuah Khan, Lorenzo Bianconi,
Heiner Kallweit, Russell King, Saravana Kannan, Philipp Zabel,
Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt,
netdev, devicetree, linux-kernel, linux-doc, linux-arm-kernel,
linux-mediatek, llvm
In-Reply-To: <6a300da0.d5af3cef.1ca29d.19c4@mx.google.com>
On 6/15/26 16:35, Christian Marangi wrote:
> On Mon, Jun 15, 2026 at 04:29:04PM +0200, Maxime Chevallier wrote:
>>
>>
>> On 6/15/26 16:10, Christian Marangi wrote:
>>> On Mon, Jun 15, 2026 at 04:07:03PM +0200, Maxime Chevallier wrote:
>>>> Hi Christian,
>>>>
>>>> On 6/15/26 14:29, Christian Marangi wrote:
>>>>> Add support for late PCS provider attachment to a phylink instance.
>>>>> This works by creating a global notifier for the PCS provider and
>>>>> making each phylink instance that makes use of fwnode subscribe to
>>>>> this notifier.
>>>>>
>>>>> The PCS notifier will emit the event FWNODE_PCS_PROVIDER_ADD every time
>>>>> a new PCS provider is added.
>>>>>
>>>>> phylink will then react to this event and will call the new function
>>>>> fwnode_phylink_pcs_get_from_fwnode() that will check if the PCS fwnode
>>>>> provided by the event is present in the pcs-handle property of the
>>>>> phylink instance.
>>>>>
>>>>> If a related PCS is found, then such PCS is added to the phylink
>>>>> instance PCS list.
>>>>>
>>>>> Then we link the PCS to the phylink instance and we refresh the supported
>>>>> interfaces of the phylink instance.
>>>>>
>>>>> Finally we check if we are in a major_config_failed scenario and trigger
>>>>> an interface reconfiguration in the next phylink resolve.
>>>>>
>>>>> In the example scenario where the link was previously torn down due to
>>>>> removal of PCS, the link will be established again as the PCS came back
>>>>> and is now available to phylink.
>>>>>
>>>>> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
>>>>> ---
>>>>
>>>> [...]
>>>>
>>>>> @@ -2151,6 +2204,10 @@ void phylink_destroy(struct phylink *pl)
>>>>> if (pl->link_gpio)
>>>>> gpiod_put(pl->link_gpio);
>>>>>
>>>>> + /* Unregister notifier for late PCS attach */
>>>>> + if (pl->fwnode_pcs_nb.notifier_call)
>>>>> + unregister_fwnode_pcs_notifier(&pl->fwnode_pcs_nb);
>>>>
>>>> I wanted to try this out, but I get :
>>>>
>>>> drivers/net/phy/phylink.c:2218:17: error: implicit declaration of function ‘unregister_fwnode_pcs_notifier’; did you mean ‘register_fwnode_pcs_notifier’? [-Werror=implicit-function-declaration]
>>>> 2218 | unregister_fwnode_pcs_notifier(&pl->fwnode_pcs_nb);
>>>> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>> | register_fwnode_pcs_notifier
>>>>
>>>> I guess you either need to stub this, or there's a missing Kconfig
>>>> dependency somewhere
>>>>
>>>
>>> Hi yes if you want toi test just enable CONFIG_FWNODE_PCS. I forgot to add
>>> the static declaration for unregister_fwnode_pcs_notifier.
>>
>> I'll give it a go with this yeah, I have a few devices here I'd like to
>> try this on.
>>
>> Can you CC me for the next rounds ?
>>
>
> Sure, if you can would be good to check also the other commit if everything
> is logically correct.
Absolutely, I'm planning on doing this :) This is quite the series though,
I'll try to give it some deeper look in the upcoming days, I expect net-next
to close soon anyways, so that's as good as it gets for reviewing this :)
Also, it's probably a good idea to have Sean in CC as well, I know a few people
interested in the Xilinx PCS his series brought, hopefully he can follow-up on
this series with the other new PCS drivers.
>
> BTW by checking test from patchwork I can see also another fix is needed if
> you want to test this revision.
>
> phylink_create()
>
> -if (config->num_possible_pcs && pl->mac_ops->mac_select_pcs) {
> +if (config->num_possible_pcs && mac_ops->mac_select_pcs) {
Ack, I'll test it with this change, thanks :)
Maxime
>
> Aside from these change I expect the current legacy code to be not
> affected by these change.
I'll probably have things to say about this "legacy" naming :)
Thanks for driving this work forwards anyway, that's
>
^ permalink raw reply
* Re: [PATCH v2] arm64: tlbflush: Don't broadcast if mm was only active on local cpu
From: Will Deacon @ 2026-06-15 14:43 UTC (permalink / raw)
To: Ryan Roberts
Cc: Linu Cherian, Catalin Marinas, Kevin Brodsky, Anshuman Khandual,
Yang Shi, Mark Rutland, Huang Ying, linux-arm-kernel,
linux-kernel, shameerali.kolothum.thodi
In-Reply-To: <bfc8803d-b375-477e-bba7-806edaf86578@arm.com>
On Mon, Jun 15, 2026 at 12:21:19PM +0100, Ryan Roberts wrote:
> On 14/06/2026 12:04, Will Deacon wrote:
> > On Sat, May 23, 2026 at 07:17:10PM +0530, Linu Cherian wrote:
> >> From: Ryan Roberts <ryan.roberts@arm.com>
> >>
> >> Testing with 7.1-rc4 :
> >> +-----------------------+---------------------------------------------------+-------------+
> >> | Benchmark | Result Class | Improvement|
> >> +=======================+===================================================+=============+
> >> | perf/syscall | fork (ops/sec) | (I) 3.25% |
> >> +-----------------------+---------------------------------------------------+-------------+
> >> | pts/memtier-benchmark | Protocol: Redis Clients: 100 Ratio: 1:5 (Ops/sec) | (I) 2.70% |
> >> | | Protocol: Redis Clients: 100 Ratio: 5:1 (Ops/sec) | (I) 2.13% |
> >> +-----------------------+---------------------------------------------------+-------------+
> >
> > I think we need a much more comprehensive set of benchmarks before we can
> > begin to consider a change like this.
>
> I believe that Linu ran a wider set of benchmarks and didn't find any
> regressions. These are just the ones that show improvement (Linu, please correct
> me and/or provide details).
I think it's important to show the ones that suffer as well... and also
look at different configurations (e.g. preemptible settings) and different
environments (e.g. native vs in a VM).
> Additionally Huang Ying did some testing against the RFC and reported 4.5%
> improvement with Redis:
>
> https://lore.kernel.org/linux-arm-kernel/87segumv6w.fsf@DESKTOP-5N7EMDA
To be clear: I'm not disputing that some benchmarks appear to show a small
boost from this series. I'm just worried that's not the whole story.
> >> arch/arm64/include/asm/mmu.h | 12 +++
> >> arch/arm64/include/asm/mmu_context.h | 2 +
> >> arch/arm64/include/asm/tlbflush.h | 127 +++++++++++++++++++++------
> >> arch/arm64/mm/context.c | 30 ++++++-
> >> 4 files changed, 141 insertions(+), 30 deletions(-)
> >
> > Doesn't this break BTM/SVM with the SMMU? I think that's a non-starter
> > even if you can provide some more compelling numbers.
>
> AIUI, we don't support BTM upstream - the SMMU uses private ASIDs and implements
> MMU notifiers to forward the TLBIs via its command queue interface.
>
> I was also under the impression that supporting BTM upsteam was not desired;
> Please correct me if that's not accurate or if you're aware of plans to add
> support. I've been (coincidentlly) looking at some other stuff that could
> benefit from BTM but had concluded it wouldn't be an acceptable approach upstream.
>
> If we did ever want to add SMMU BTM support though, I think it would be simple
> enough to add an interface to allow the SMMU to disable the optimization (i.e.
> force active_cpu to ACTIVE_CPU_MULTIPLE)?
We used to have some initial BTM support in the SMMUv3 driver but the
main problem was finding an upstream driver/soc that can use it properly
and so it was ultimately removed in d38c28dbefee ("iommu/arm-smmu-v3: Put
the SVA mmu notifier in the smmu_domain") because it was getting in the
way of wider driver rework and we couldn't test it.
However, there *is* work to re-enable it on top of that rework (and other
changes):
https://lore.kernel.org/linux-iommu/20250319173202.78988-6-shameerali.kolothum.thodi@huawei.com/
although I don't know if Shameer intends to repost that...
> >> +static inline bool flush_tlb_user_pre(struct mm_struct *mm, tlbf_t flags)
> >> +{
> >> + unsigned int self, active;
> >> + bool local;
> >> +
> >> + migrate_disable();
> >> +
> >> + if (flags & TLBF_NOBROADCAST) {
> >> + dsb(nshst);
> >> + return true;
> >> + }
> >
> > Why does the NOBROADCAST case need migration disabled? It didn't before...
>
> The existing semantic for TLBF_BOBROADCAST is that it emits a local TLBI on
> whatever CPU we happen to be executing on. It's used for lazily fixing up
> spurious faults (i.e. hitting RO TLB entries when the PTE has been relaxed to
> RW). So it's still functionally correct if the thread migrates CPU between
> taking the fault and issuing the local TLBI - in the worst case it just leads to
> another spurious fault.
>
> For this new case, we need to ensure we don't get migrated between reading
> active_cpu and issuing the local TLBI, otherwise we would only issue a local
> TLBI when a broadcast was required.
Sounds like those two users probably need separating out, then?
> >> + self = smp_processor_id();
> >> +
> >> + /*
> >> + * The load of mm->context.active_cpu must not be reordered before the
> >> + * store to the pgtable that necessitated this flush. This ensures that
> >> + * if the value read is our cpu id, then no other cpu can have seen the
> >> + * old pgtable value and therefore does not need this old value to be
> >> + * flushed from its tlb. But we don't want to upgrade the dsb(ishst),
> >> + * needed to make the pgtable updates visible to the walker, to a
> >> + * dsb(ish) by default. So speculatively load without a barrier and if
> >> + * it indicates our cpu id, then upgrade the barrier and re-load.
> >> + */
> >> + active = READ_ONCE(mm->context.active_cpu);
> >> + if (active == self) {
> >> + dsb(ish);
> >> + active = READ_ONCE(mm->context.active_cpu);
> >> + } else {
> >> + dsb(ishst);
> >> + }
> >
> > Why can't you just do:
> >
> > dsb(ishst);
> > active = READ_ONCE(mm->context.active_cpu);
> >
> > ?
>
> Prior to this optimization, we always issued a dsb(ishst) here. Catalin
> suggested the same simplification against the RFC. I believe Linu tried it but
> saw regressions; Hopefully Linu can provide the details.
I don't follow...
The old code always did dsb(ishst). The proposed code here does either
dsb(ish) or dsb(ishst). How can that possibly be faster?
> >> + local = active == self;
> >> + if (!local)
> >> + migrate_enable();
> >> +
> >> + return local;
> >> +}
> >> +
> >> +static inline void flush_tlb_user_post(bool local)
> >> +{
> >> + if (local)
> >> + migrate_enable();
> >> +}
> >
> > I was under the impression that disabling/enabling migration was an
> > expensive thing to do, so I'd really want to see some more numbers to
> > justify this (including from inside a VM) and allow us to consider the
> > trade-offs properly. It's also not at all clear to me that it's safe
> > from such a low-level TLB invalidation helper.
>
> I had assumed it wasn't very expensive, but perhaps I'm wrong. I know
> preempt_enable() can be expensive because it has to test to see if it needs to
> reschedule. But I assumed for disabling/enabling migration, it would just be a
> counter and the scheduler would check that it's zero before considing moving the
> task to another run queue. (But I have practically zero understanding of the
> scheduler so I'll assume I'm wrong...).
I'm not an expert here either, but reading the code shows that it has
a preempt guard along with additional book-keeping.
> Instead of disabling migration, perhaps we could re-check active_cpu after
> issuing the local tlbi - if it's now reporting "multiple" we must have been
> migrated and we need to upgrade to a braodcast TLBI?
That's an interesting idea, although I suppose it means the
post-invalidation DSB needs to be ISH for the local case to check the
active_cpu safely?
> >> * TLB Invalidation
> >> * ================
> >> @@ -408,12 +482,20 @@ static inline void flush_tlb_all(void)
> >> static inline void flush_tlb_mm(struct mm_struct *mm)
> >> {
> >> unsigned long asid;
> >> + bool local;
> >>
> >> - dsb(ishst);
> >> + local = flush_tlb_user_pre(mm, TLBF_NONE);
> >> asid = __TLBI_VADDR(0, ASID(mm));
> >> - __tlbi(aside1is, asid);
> >> - __tlbi_user(aside1is, asid);
> >> - __tlbi_sync_s1ish(mm);
> >> + if (local) {
> >> + __tlbi(aside1, asid);
> >> + __tlbi_user(aside1, asid);
> >> + dsb(nsh);
> >> + } else {
> >> + __tlbi(aside1is, asid);
> >> + __tlbi_user(aside1is, asid);
> >> + __tlbi_sync_s1ish(mm);
> >> + }
> >> + flush_tlb_user_post(local);
> >
> > I think you've changed this since Ryan's original patch, but why are you
> > only calling __tlbi_sync_s1ish() for the !local case? Doesn't that break
> > the erratum workaround when running as a VM if the vCPU is migrated?
>
> Hmm. So from the guest kernel's perspective, it has concluded that it only needs
> to target the local (v)CPU. Since the errata only affect boardcast TLBIs, it
> concludes there is no need to issue the workarounds. But since it's a VM, the HW
> will upgrade the local TLBIs to broadcast TLBIs, but will not magically
> re-instate the workarounds. I guess the simplest solution would be to disable
> the optimization when either workaround is enabled.
That's what I was thinking, but Mark seems to think it's ok. I'll reply
to him on the other part of the thread.
> Perhaps this is all getting a bit too complex for not enough benefit...
I don't think the complexity is unmanageable, but I'm not yet convinced
that this offers any real benefit overall.
Will
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Sync SPSR_EL1 when injecting an exception into a pVM
From: Will Deacon @ 2026-06-15 14:41 UTC (permalink / raw)
To: Fuad Tabba
Cc: Marc Zyngier, Oliver Upton, linux-arm-kernel, kvmarm,
linux-kernel, Joey Gouly, Steffen Eiden, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Sascha Bischoff, Andrew Jones
In-Reply-To: <CA+EHjTyMOoCLQ7d6+TgkrnOJF-PV9K-BKtb4CNuAg8p4gtg6wg@mail.gmail.com>
On Mon, Jun 15, 2026 at 11:52:10AM +0100, Fuad Tabba wrote:
> On Mon, 15 Jun 2026 at 11:05, Will Deacon <will@kernel.org> wrote:
> >
> > On Fri, Jun 12, 2026 at 12:34:14PM +0100, Fuad Tabba wrote:
> > > When pKVM injects a synchronous exception into a protected guest, it
> > > re-enters without restoring the guest's EL1 sysregs and writes the EL1
> > > exception registers to hardware by hand: ESR_EL1 and ELR_EL1, but not
> > > SPSR_EL1. enter_exception64() sets SPSR_EL1 (the interrupted PSTATE)
> > > only in memory, so the guest's handler reads a stale SPSR_EL1 and
> > > restores the wrong PSTATE on eret.
> > >
> > > Write SPSR_EL1 alongside the other exception registers.
> > >
> > > Fixes: 6c30bfb18d0b ("KVM: arm64: Add handlers for protected VM System Registers")
> > > Reported-by: sashiko <sashiko@sashiko.dev>
> > > Signed-off-by: Fuad Tabba <tabba@google.com>
> > > ---
> > > arch/arm64/kvm/hyp/nvhe/sys_regs.c | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/arch/arm64/kvm/hyp/nvhe/sys_regs.c b/arch/arm64/kvm/hyp/nvhe/sys_regs.c
> > > index 8c3fbb413a06..1a7d5cd16d72 100644
> > > --- a/arch/arm64/kvm/hyp/nvhe/sys_regs.c
> > > +++ b/arch/arm64/kvm/hyp/nvhe/sys_regs.c
> > > @@ -268,6 +268,7 @@ static void inject_sync64(struct kvm_vcpu *vcpu, u64 esr)
> > >
> > > write_sysreg_el1(esr, SYS_ESR);
> > > write_sysreg_el1(read_sysreg_el2(SYS_ELR), SYS_ELR);
> > > + write_sysreg_el1(read_sysreg_el2(SYS_SPSR), SYS_SPSR);
> > > write_sysreg_el2(*vcpu_pc(vcpu), SYS_ELR);
> > > write_sysreg_el2(*vcpu_cpsr(vcpu), SYS_SPSR);
> > > }
> >
> > Is SPSR_EL1 not set in enter_exception64() using vcpu_cpsr(vcpu), which
> > *is* set here? I'm just a bit wary of the report, as I'd have expected
> > fireworks if we weren't initialising the guest's SPSR on the exception
> > injection path.
>
> Yes, enter_exception64() sets SPSR_EL1, but only in memory:
> __vcpu_write_spsr() takes the nVHE path and calls
> __vcpu_assign_sys_reg(vcpu, SPSR_EL1, val), which writes
> vcpu->arch.ctxt.sys_regs[SPSR_EL1] without touching the hardware
> register.
>
> In the normal nVHE entry path that memory value reaches hardware via
> __sysreg_restore_state_nvhe() before __guest_enter(). But
> inject_sync64() runs inside the fixup_guest_exit() loop, which
> re-enters the guest directly without a sysreg restore pass. ESR_EL1
> and ELR_EL1 are already written to hardware by hand for this reason
> but SPSR_EL1 was missed.
Ah, I see. Does that mean that all the in-memory updates performed by
enter_exception64() (e.g. the construction of the cpsr) are ignored too?
Will
^ permalink raw reply
* Re: [PATCH net-next v7 05/12] net: phylink: support late PCS provider attach
From: Christian Marangi @ 2026-06-15 14:35 UTC (permalink / raw)
To: Maxime Chevallier
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Simon Horman, Jonathan Corbet, Shuah Khan, Lorenzo Bianconi,
Heiner Kallweit, Russell King, Saravana Kannan, Philipp Zabel,
Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt,
netdev, devicetree, linux-kernel, linux-doc, linux-arm-kernel,
linux-mediatek, llvm
In-Reply-To: <7702ac09-75fd-49de-8ad2-fceaa122b627@bootlin.com>
On Mon, Jun 15, 2026 at 04:29:04PM +0200, Maxime Chevallier wrote:
>
>
> On 6/15/26 16:10, Christian Marangi wrote:
> > On Mon, Jun 15, 2026 at 04:07:03PM +0200, Maxime Chevallier wrote:
> >> Hi Christian,
> >>
> >> On 6/15/26 14:29, Christian Marangi wrote:
> >>> Add support for late PCS provider attachment to a phylink instance.
> >>> This works by creating a global notifier for the PCS provider and
> >>> making each phylink instance that makes use of fwnode subscribe to
> >>> this notifier.
> >>>
> >>> The PCS notifier will emit the event FWNODE_PCS_PROVIDER_ADD every time
> >>> a new PCS provider is added.
> >>>
> >>> phylink will then react to this event and will call the new function
> >>> fwnode_phylink_pcs_get_from_fwnode() that will check if the PCS fwnode
> >>> provided by the event is present in the pcs-handle property of the
> >>> phylink instance.
> >>>
> >>> If a related PCS is found, then such PCS is added to the phylink
> >>> instance PCS list.
> >>>
> >>> Then we link the PCS to the phylink instance and we refresh the supported
> >>> interfaces of the phylink instance.
> >>>
> >>> Finally we check if we are in a major_config_failed scenario and trigger
> >>> an interface reconfiguration in the next phylink resolve.
> >>>
> >>> In the example scenario where the link was previously torn down due to
> >>> removal of PCS, the link will be established again as the PCS came back
> >>> and is now available to phylink.
> >>>
> >>> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> >>> ---
> >>
> >> [...]
> >>
> >>> @@ -2151,6 +2204,10 @@ void phylink_destroy(struct phylink *pl)
> >>> if (pl->link_gpio)
> >>> gpiod_put(pl->link_gpio);
> >>>
> >>> + /* Unregister notifier for late PCS attach */
> >>> + if (pl->fwnode_pcs_nb.notifier_call)
> >>> + unregister_fwnode_pcs_notifier(&pl->fwnode_pcs_nb);
> >>
> >> I wanted to try this out, but I get :
> >>
> >> drivers/net/phy/phylink.c:2218:17: error: implicit declaration of function ‘unregister_fwnode_pcs_notifier’; did you mean ‘register_fwnode_pcs_notifier’? [-Werror=implicit-function-declaration]
> >> 2218 | unregister_fwnode_pcs_notifier(&pl->fwnode_pcs_nb);
> >> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >> | register_fwnode_pcs_notifier
> >>
> >> I guess you either need to stub this, or there's a missing Kconfig
> >> dependency somewhere
> >>
> >
> > Hi yes if you want toi test just enable CONFIG_FWNODE_PCS. I forgot to add
> > the static declaration for unregister_fwnode_pcs_notifier.
>
> I'll give it a go with this yeah, I have a few devices here I'd like to
> try this on.
>
> Can you CC me for the next rounds ?
>
Sure, if you can would be good to check also the other commit if everything
is logically correct.
BTW by checking test from patchwork I can see also another fix is needed if
you want to test this revision.
phylink_create()
-if (config->num_possible_pcs && pl->mac_ops->mac_select_pcs) {
+if (config->num_possible_pcs && mac_ops->mac_select_pcs) {
Aside from these change I expect the current legacy code to be not
affected by these change.
--
Ansuel
^ permalink raw reply
* [PATCH net-next v7 05/12] net: phylink: support late PCS provider attach
From: Christian Marangi @ 2026-06-15 12:29 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Simon Horman, Jonathan Corbet, Shuah Khan, Christian Marangi,
Lorenzo Bianconi, Heiner Kallweit, Russell King, Saravana Kannan,
Philipp Zabel, Nathan Chancellor, Nick Desaulniers, Bill Wendling,
Justin Stitt, netdev, devicetree, linux-kernel, linux-doc,
linux-arm-kernel, linux-mediatek, llvm
In-Reply-To: <20260615122950.22281-1-ansuelsmth@gmail.com>
Add support for late PCS provider attachment to a phylink instance.
This works by creating a global notifier for the PCS provider and
making each phylink instance that makes use of fwnode subscribe to
this notifier.
The PCS notifier will emit the event FWNODE_PCS_PROVIDER_ADD every time
a new PCS provider is added.
phylink will then react to this event and will call the new function
fwnode_phylink_pcs_get_from_fwnode() that will check if the PCS fwnode
provided by the event is present in the pcs-handle property of the
phylink instance.
If a related PCS is found, then such PCS is added to the phylink
instance PCS list.
Then we link the PCS to the phylink instance and we refresh the supported
interfaces of the phylink instance.
Finally we check if we are in a major_config_failed scenario and trigger
an interface reconfiguration in the next phylink resolve.
In the example scenario where the link was previously torn down due to
removal of PCS, the link will be established again as the PCS came back
and is now available to phylink.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
---
drivers/net/pcs/pcs.c | 49 ++++++++++++++++++++++++++++++++
drivers/net/phy/phylink.c | 57 +++++++++++++++++++++++++++++++++++++
include/linux/pcs/pcs.h | 60 +++++++++++++++++++++++++++++++++++++++
3 files changed, 166 insertions(+)
diff --git a/drivers/net/pcs/pcs.c b/drivers/net/pcs/pcs.c
index 67f9716f48fd..713b2ec22c97 100644
--- a/drivers/net/pcs/pcs.c
+++ b/drivers/net/pcs/pcs.c
@@ -22,6 +22,19 @@ struct fwnode_pcs_provider {
static LIST_HEAD(fwnode_pcs_providers);
static DEFINE_MUTEX(fwnode_pcs_mutex);
+static BLOCKING_NOTIFIER_HEAD(fwnode_pcs_notify_list);
+
+int register_fwnode_pcs_notifier(struct notifier_block *nb)
+{
+ return blocking_notifier_chain_register(&fwnode_pcs_notify_list, nb);
+}
+EXPORT_SYMBOL_GPL(register_fwnode_pcs_notifier);
+
+int unregister_fwnode_pcs_notifier(struct notifier_block *nb)
+{
+ return blocking_notifier_chain_unregister(&fwnode_pcs_notify_list, nb);
+}
+EXPORT_SYMBOL_GPL(unregister_fwnode_pcs_notifier);
struct phylink_pcs *fwnode_pcs_simple_get(struct fwnode_reference_args *pcsspec,
void *data)
@@ -55,6 +68,10 @@ int fwnode_pcs_add_provider(struct fwnode_handle *fwnode,
fwnode_dev_initialized(fwnode, true);
+ blocking_notifier_call_chain(&fwnode_pcs_notify_list,
+ FWNODE_PCS_PROVIDER_ADD,
+ fwnode);
+
return 0;
}
EXPORT_SYMBOL_GPL(fwnode_pcs_add_provider);
@@ -150,6 +167,38 @@ struct phylink_pcs *fwnode_pcs_get(struct fwnode_handle *fwnode, unsigned int in
}
EXPORT_SYMBOL_GPL(fwnode_pcs_get);
+struct phylink_pcs *
+fwnode_phylink_pcs_get_from_fwnode(struct fwnode_handle *fwnode,
+ struct fwnode_handle *pcs_fwnode)
+{
+ struct fwnode_reference_args pcsspec;
+ int index = 0;
+ int ret;
+
+ /* Loop until we find a matching PCS node or
+ * fwnode_parse_pcsspec() returns error
+ * if we don't have any other PCS reference to check.
+ */
+ while (true) {
+ ret = fwnode_parse_pcsspec(fwnode, index, NULL, &pcsspec);
+ if (ret)
+ return ERR_PTR(ret);
+
+ /* Exit loop if we found the matching PCS node */
+ if (pcsspec.fwnode == pcs_fwnode) {
+ fwnode_handle_put(pcsspec.fwnode);
+ break;
+ }
+
+ /* Check the next PCS reference */
+ fwnode_handle_put(pcsspec.fwnode);
+ index++;
+ }
+
+ return fwnode_pcs_get(fwnode, index);
+}
+EXPORT_SYMBOL_GPL(fwnode_phylink_pcs_get_from_fwnode);
+
unsigned int fwnode_phylink_pcs_count(struct fwnode_handle *fwnode)
{
struct fwnode_reference_args out_args;
diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
index ca4dad4b140a..0734c98498a9 100644
--- a/drivers/net/phy/phylink.c
+++ b/drivers/net/phy/phylink.c
@@ -12,6 +12,7 @@
#include <linux/netdevice.h>
#include <linux/of.h>
#include <linux/of_mdio.h>
+#include <linux/pcs/pcs.h>
#include <linux/phy.h>
#include <linux/phy_fixed.h>
#include <linux/phylink.h>
@@ -62,6 +63,7 @@ struct phylink {
/* List of available PCS */
struct list_head pcs_list;
+ struct notifier_block fwnode_pcs_nb;
/* What interface are supported by the current link.
* Can change on removal or addition of new PCS.
@@ -1997,6 +1999,51 @@ static int phylink_fill_available_pcs(struct phylink *pl,
return ret;
}
+static int pcs_provider_notify(struct notifier_block *self,
+ unsigned long val, void *data)
+{
+ struct phylink *pl = container_of(self, struct phylink, fwnode_pcs_nb);
+ struct fwnode_handle *pcs_fwnode = data;
+ struct phylink_pcs *pcs;
+
+ /* Check if the just added PCS provider is
+ * in the phylink instance pcs-handle property.
+ */
+ pcs = fwnode_phylink_pcs_get_from_fwnode(dev_fwnode(pl->config->dev),
+ pcs_fwnode);
+ if (IS_ERR(pcs))
+ return NOTIFY_DONE;
+
+ /* Add the PCS */
+ rtnl_lock();
+
+ mutex_lock(&pl->state_mutex);
+
+ /* Link PCS with phylink */
+ list_add(&pcs->list, &pl->pcs_list);
+ pcs->phylink = pl;
+
+ /* Refresh supported interfaces */
+ phy_interface_copy(pl->supported_interfaces,
+ pl->config->supported_interfaces);
+ list_for_each_entry(pcs, &pl->pcs_list, list)
+ phy_interface_or(pl->supported_interfaces,
+ pl->supported_interfaces,
+ pcs->supported_interfaces);
+
+ /* Force an interface reconfig if major config fail */
+ if (pl->major_config_failed)
+ pl->force_major_config = true;
+
+ mutex_unlock(&pl->state_mutex);
+
+ rtnl_unlock();
+
+ phylink_run_resolve(pl);
+
+ return NOTIFY_OK;
+}
+
/**
* phylink_create() - create a phylink instance
* @config: a pointer to the target &struct phylink_config
@@ -2068,6 +2115,12 @@ struct phylink *phylink_create(struct phylink_config *config,
pl->supported_interfaces,
pcs->supported_interfaces);
+ /* Register notifier for late PCS attach */
+ if (!phy_interface_empty(config->pcs_interfaces)) {
+ pl->fwnode_pcs_nb.notifier_call = pcs_provider_notify;
+ register_fwnode_pcs_notifier(&pl->fwnode_pcs_nb);
+ }
+
pl->config = config;
if (config->type == PHYLINK_NETDEV) {
pl->netdev = to_net_dev(config->dev);
@@ -2151,6 +2204,10 @@ void phylink_destroy(struct phylink *pl)
if (pl->link_gpio)
gpiod_put(pl->link_gpio);
+ /* Unregister notifier for late PCS attach */
+ if (pl->fwnode_pcs_nb.notifier_call)
+ unregister_fwnode_pcs_notifier(&pl->fwnode_pcs_nb);
+
/* Drop link between PCS and phylink */
list_for_each_entry(pcs, &pl->pcs_list, list)
pcs->phylink = NULL;
diff --git a/include/linux/pcs/pcs.h b/include/linux/pcs/pcs.h
index df1e6f32cfad..9de3f273428e 100644
--- a/include/linux/pcs/pcs.h
+++ b/include/linux/pcs/pcs.h
@@ -4,7 +4,36 @@
#include <linux/phylink.h>
+enum fwnode_pcs_notify_event {
+ FWNODE_PCS_PROVIDER_ADD,
+};
+
#if IS_ENABLED(CONFIG_FWNODE_PCS)
+/**
+ * register_fwnode_pcs_notifier - Register a notifier block for fwnode
+ * PCS events
+ * @nb: pointer to the notifier block
+ *
+ * Registers a notifier block to the fwnode_pcs_notify_list blocking
+ * notifier chain. This allows phylink instance to subscribe for
+ * PCS provider events.
+ *
+ * Returns: 0 or a negative error.
+ */
+int register_fwnode_pcs_notifier(struct notifier_block *nb);
+
+/**
+ * unregister_fwnode_pcs_notifier - Unregister a notifier block for fwnode
+ * PCS events
+ * @nb: pointer to the notifier block
+ *
+ * Unregisters a notifier block to the fwnode_pcs_notify_list blocking
+ * notifier chain.
+ *
+ * Returns: 0 or a negative error.
+ */
+int unregister_fwnode_pcs_notifier(struct notifier_block *nb);
+
/**
* fwnode_pcs_get - Retrieves a PCS from a firmware node
* @fwnode: firmware node
@@ -20,6 +49,25 @@
struct phylink_pcs *fwnode_pcs_get(struct fwnode_handle *fwnode,
unsigned int index);
+/**
+ * fwnode_phylink_pcs_get_from_fwnode - Retrieves the PCS provided
+ * by the firmware node from a
+ * firmware node
+ * @fwnode: firmware node
+ * @pcs_fwnode: PCS firmware node
+ *
+ * Parse 'pcs-handle' in 'fwnode' and get the PCS that match
+ * 'pcs_fwnode' firmware node.
+ *
+ * Returns: a pointer to the phylink_pcs or a negative
+ * error pointer. Can return -EPROBE_DEFER if the PCS is not
+ * present in global providers list (either due to driver
+ * still needs to be probed or it failed to probe/removed)
+ */
+struct phylink_pcs *
+fwnode_phylink_pcs_get_from_fwnode(struct fwnode_handle *fwnode,
+ struct fwnode_handle *pcs_fwnode);
+
/**
* fwnode_phylink_pcs_count - count PCS entries described in firmware node
* @fwnode: firmware node
@@ -53,12 +101,24 @@ int fwnode_phylink_pcs_parse(struct fwnode_handle *fwnode,
struct phylink_pcs **available_pcs,
unsigned int num_pcs);
#else
+static inline int register_fwnode_pcs_notifier(struct notifier_block *nb)
+{
+ return -EOPNOTSUPP;
+}
+
static inline struct phylink_pcs *fwnode_pcs_get(struct fwnode_handle *fwnode,
int index)
{
return ERR_PTR(-ENOENT);
}
+static inline struct phylink_pcs *
+fwnode_phylink_pcs_get_from_fwnode(struct fwnode_handle *fwnode,
+ struct fwnode_handle *pcs_fwnode)
+{
+ return ERR_PTR(-ENOENT);
+}
+
static inline unsigned int fwnode_phylink_pcs_count(struct fwnode_handle *fwnode)
{
return 0;
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2 02/11] ASoC: fsl_audmix: Use guard() for spin locks
From: Frank Li @ 2026-06-15 14:30 UTC (permalink / raw)
To: phucduc.bui
Cc: Mark Brown, Liam Girdwood, Jaroslav Kysela, Takashi Iwai,
Shengjiu Wang, Xiubo Li, Frank Li, Fabio Estevam, Nicolin Chen,
Sascha Hauer, Pengutronix Kernel Team, linux-sound, linux-kernel,
linux-arm-kernel, imx, linuxppc-dev
In-Reply-To: <20260615093824.115751-3-phucduc.bui@gmail.com>
On Mon, Jun 15, 2026 at 04:38:15PM +0700, phucduc.bui@gmail.com wrote:
> From: bui duc phuc <phucduc.bui@gmail.com>
>
> Clean up the code using guard() for spin locks.
> Merely code refactoring, and no behavior change.
>
> Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> sound/soc/fsl/fsl_audmix.c | 11 ++++-------
> 1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/sound/soc/fsl/fsl_audmix.c b/sound/soc/fsl/fsl_audmix.c
> index 40a3b7432174..066239c64037 100644
> --- a/sound/soc/fsl/fsl_audmix.c
> +++ b/sound/soc/fsl/fsl_audmix.c
> @@ -280,7 +280,6 @@ static int fsl_audmix_dai_trigger(struct snd_pcm_substream *substream, int cmd,
> struct snd_soc_dai *dai)
> {
> struct fsl_audmix *priv = snd_soc_dai_get_drvdata(dai);
> - unsigned long lock_flags;
>
> /* Capture stream shall not be handled */
> if (substream->stream == SNDRV_PCM_STREAM_CAPTURE)
> @@ -290,16 +289,14 @@ static int fsl_audmix_dai_trigger(struct snd_pcm_substream *substream, int cmd,
> case SNDRV_PCM_TRIGGER_START:
> case SNDRV_PCM_TRIGGER_RESUME:
> case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
> - spin_lock_irqsave(&priv->lock, lock_flags);
> - priv->tdms |= BIT(dai->driver->id);
> - spin_unlock_irqrestore(&priv->lock, lock_flags);
> + scoped_guard(spinlock_irqsave, &priv->lock)
> + priv->tdms |= BIT(dai->driver->id);
> break;
> case SNDRV_PCM_TRIGGER_STOP:
> case SNDRV_PCM_TRIGGER_SUSPEND:
> case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
> - spin_lock_irqsave(&priv->lock, lock_flags);
> - priv->tdms &= ~BIT(dai->driver->id);
> - spin_unlock_irqrestore(&priv->lock, lock_flags);
> + scoped_guard(spinlock_irqsave, &priv->lock)
> + priv->tdms &= ~BIT(dai->driver->id);
> break;
> default:
> return -EINVAL;
> --
> 2.43.0
>
>
^ permalink raw reply
* Re: [PATCH net-next v7 05/12] net: phylink: support late PCS provider attach
From: Maxime Chevallier @ 2026-06-15 14:29 UTC (permalink / raw)
To: Christian Marangi
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Simon Horman, Jonathan Corbet, Shuah Khan, Lorenzo Bianconi,
Heiner Kallweit, Russell King, Saravana Kannan, Philipp Zabel,
Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt,
netdev, devicetree, linux-kernel, linux-doc, linux-arm-kernel,
linux-mediatek, llvm
In-Reply-To: <6a3007ce.73de60af.3a056d.d903@mx.google.com>
On 6/15/26 16:10, Christian Marangi wrote:
> On Mon, Jun 15, 2026 at 04:07:03PM +0200, Maxime Chevallier wrote:
>> Hi Christian,
>>
>> On 6/15/26 14:29, Christian Marangi wrote:
>>> Add support for late PCS provider attachment to a phylink instance.
>>> This works by creating a global notifier for the PCS provider and
>>> making each phylink instance that makes use of fwnode subscribe to
>>> this notifier.
>>>
>>> The PCS notifier will emit the event FWNODE_PCS_PROVIDER_ADD every time
>>> a new PCS provider is added.
>>>
>>> phylink will then react to this event and will call the new function
>>> fwnode_phylink_pcs_get_from_fwnode() that will check if the PCS fwnode
>>> provided by the event is present in the pcs-handle property of the
>>> phylink instance.
>>>
>>> If a related PCS is found, then such PCS is added to the phylink
>>> instance PCS list.
>>>
>>> Then we link the PCS to the phylink instance and we refresh the supported
>>> interfaces of the phylink instance.
>>>
>>> Finally we check if we are in a major_config_failed scenario and trigger
>>> an interface reconfiguration in the next phylink resolve.
>>>
>>> In the example scenario where the link was previously torn down due to
>>> removal of PCS, the link will be established again as the PCS came back
>>> and is now available to phylink.
>>>
>>> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
>>> ---
>>
>> [...]
>>
>>> @@ -2151,6 +2204,10 @@ void phylink_destroy(struct phylink *pl)
>>> if (pl->link_gpio)
>>> gpiod_put(pl->link_gpio);
>>>
>>> + /* Unregister notifier for late PCS attach */
>>> + if (pl->fwnode_pcs_nb.notifier_call)
>>> + unregister_fwnode_pcs_notifier(&pl->fwnode_pcs_nb);
>>
>> I wanted to try this out, but I get :
>>
>> drivers/net/phy/phylink.c:2218:17: error: implicit declaration of function ‘unregister_fwnode_pcs_notifier’; did you mean ‘register_fwnode_pcs_notifier’? [-Werror=implicit-function-declaration]
>> 2218 | unregister_fwnode_pcs_notifier(&pl->fwnode_pcs_nb);
>> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> | register_fwnode_pcs_notifier
>>
>> I guess you either need to stub this, or there's a missing Kconfig
>> dependency somewhere
>>
>
> Hi yes if you want toi test just enable CONFIG_FWNODE_PCS. I forgot to add
> the static declaration for unregister_fwnode_pcs_notifier.
I'll give it a go with this yeah, I have a few devices here I'd like to
try this on.
Can you CC me for the next rounds ?
Maxime
>
^ permalink raw reply
* Re: [PATCH v2 11/11] ASoC: fsl: mpc5200_psc_ac97: Use guard() for mutex locks
From: Frank Li @ 2026-06-15 14:26 UTC (permalink / raw)
To: phucduc.bui
Cc: Mark Brown, Liam Girdwood, Jaroslav Kysela, Takashi Iwai,
Shengjiu Wang, Xiubo Li, Frank Li, Fabio Estevam, Nicolin Chen,
Sascha Hauer, Pengutronix Kernel Team, linux-sound, linux-kernel,
linux-arm-kernel, imx, linuxppc-dev
In-Reply-To: <20260615093824.115751-12-phucduc.bui@gmail.com>
On Mon, Jun 15, 2026 at 04:38:24PM +0700, phucduc.bui@gmail.com wrote:
> From: bui duc phuc <phucduc.bui@gmail.com>
>
> Clean up the code using guard() for mutex locks.
> Merely code refactoring, and no behavior change.
>
> Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
>
> Changes in v2:
> - psc_ac97_cold_reset(): Fix scoped_guard() usage by replacing
> scoped_guard(mutex_lock, ...) with scoped_guard(mutex, ...).
>
> sound/soc/fsl/mpc5200_psc_ac97.c | 34 +++++++++++---------------------
> 1 file changed, 12 insertions(+), 22 deletions(-)
>
> diff --git a/sound/soc/fsl/mpc5200_psc_ac97.c b/sound/soc/fsl/mpc5200_psc_ac97.c
> index 8554fb690772..d4d9f5b6bc07 100644
> --- a/sound/soc/fsl/mpc5200_psc_ac97.c
> +++ b/sound/soc/fsl/mpc5200_psc_ac97.c
> @@ -31,14 +31,13 @@ static unsigned short psc_ac97_read(struct snd_ac97 *ac97, unsigned short reg)
> int status;
> unsigned int val;
>
> - mutex_lock(&psc_dma->mutex);
> + guard(mutex)(&psc_dma->mutex);
>
> /* Wait for command send status zero = ready */
> status = spin_event_timeout(!(in_be16(&psc_dma->psc_regs->sr_csr.status) &
> MPC52xx_PSC_SR_CMDSEND), 100, 0);
> if (status == 0) {
> pr_err("timeout on ac97 bus (rdy)\n");
> - mutex_unlock(&psc_dma->mutex);
> return -ENODEV;
> }
>
> @@ -54,19 +53,16 @@ static unsigned short psc_ac97_read(struct snd_ac97 *ac97, unsigned short reg)
> if (status == 0) {
> pr_err("timeout on ac97 read (val) %x\n",
> in_be16(&psc_dma->psc_regs->sr_csr.status));
> - mutex_unlock(&psc_dma->mutex);
> return -ENODEV;
> }
> /* Get the data */
> val = in_be32(&psc_dma->psc_regs->ac97_data);
> if (((val >> 24) & 0x7f) != reg) {
> pr_err("reg echo error on ac97 read\n");
> - mutex_unlock(&psc_dma->mutex);
> return -ENODEV;
> }
> val = (val >> 8) & 0xffff;
>
> - mutex_unlock(&psc_dma->mutex);
> return (unsigned short) val;
> }
>
> @@ -75,52 +71,46 @@ static void psc_ac97_write(struct snd_ac97 *ac97,
> {
> int status;
>
> - mutex_lock(&psc_dma->mutex);
> + guard(mutex)(&psc_dma->mutex);
>
> /* Wait for command status zero = ready */
> status = spin_event_timeout(!(in_be16(&psc_dma->psc_regs->sr_csr.status) &
> MPC52xx_PSC_SR_CMDSEND), 100, 0);
> if (status == 0) {
> pr_err("timeout on ac97 bus (write)\n");
> - goto out;
> + return;
> }
> /* Write data */
> out_be32(&psc_dma->psc_regs->ac97_cmd,
> ((reg & 0x7f) << 24) | (val << 8));
> -
> - out:
> - mutex_unlock(&psc_dma->mutex);
> }
>
> static void psc_ac97_warm_reset(struct snd_ac97 *ac97)
> {
> struct mpc52xx_psc __iomem *regs = psc_dma->psc_regs;
>
> - mutex_lock(&psc_dma->mutex);
> + guard(mutex)(&psc_dma->mutex);
>
> out_be32(®s->sicr, psc_dma->sicr | MPC52xx_PSC_SICR_AWR);
> udelay(3);
> out_be32(®s->sicr, psc_dma->sicr);
> -
> - mutex_unlock(&psc_dma->mutex);
> }
>
> static void psc_ac97_cold_reset(struct snd_ac97 *ac97)
> {
> struct mpc52xx_psc __iomem *regs = psc_dma->psc_regs;
>
> - mutex_lock(&psc_dma->mutex);
> - dev_dbg(psc_dma->dev, "cold reset\n");
> + scoped_guard(mutex, &psc_dma->mutex) {
> + dev_dbg(psc_dma->dev, "cold reset\n");
>
> - mpc5200_psc_ac97_gpio_reset(psc_dma->id);
> + mpc5200_psc_ac97_gpio_reset(psc_dma->id);
>
> - /* Notify the PSC that a reset has occurred */
> - out_be32(®s->sicr, psc_dma->sicr | MPC52xx_PSC_SICR_ACRB);
> + /* Notify the PSC that a reset has occurred */
> + out_be32(®s->sicr, psc_dma->sicr | MPC52xx_PSC_SICR_ACRB);
>
> - /* Re-enable RX and TX */
> - out_8(®s->command, MPC52xx_PSC_TX_ENABLE | MPC52xx_PSC_RX_ENABLE);
> -
> - mutex_unlock(&psc_dma->mutex);
> + /* Re-enable RX and TX */
> + out_8(®s->command, MPC52xx_PSC_TX_ENABLE | MPC52xx_PSC_RX_ENABLE);
> + }
>
> usleep_range(1000, 2000);
> psc_ac97_warm_reset(ac97);
> --
> 2.43.0
>
>
^ permalink raw reply
* Re: [PATCH v2 06/11] ASoC: fsl_ssi: Use guard() for mutex locks
From: Frank Li @ 2026-06-15 14:25 UTC (permalink / raw)
To: phucduc.bui
Cc: Mark Brown, Liam Girdwood, Jaroslav Kysela, Takashi Iwai,
Shengjiu Wang, Xiubo Li, Frank Li, Fabio Estevam, Nicolin Chen,
Sascha Hauer, Pengutronix Kernel Team, linux-sound, linux-kernel,
linux-arm-kernel, imx, linuxppc-dev
In-Reply-To: <20260615093824.115751-7-phucduc.bui@gmail.com>
On Mon, Jun 15, 2026 at 04:38:19PM +0700, phucduc.bui@gmail.com wrote:
> From: bui duc phuc <phucduc.bui@gmail.com>
>
> Clean up the code using guard() for mutex locks.
> Merely code refactoring, and no behavior change.
>
> Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> sound/soc/fsl/fsl_ssi.c | 13 ++++---------
> 1 file changed, 4 insertions(+), 9 deletions(-)
>
> diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
> index b2e1da1781ae..dc022976c982 100644
> --- a/sound/soc/fsl/fsl_ssi.c
> +++ b/sound/soc/fsl/fsl_ssi.c
> @@ -1218,13 +1218,13 @@ static void fsl_ssi_ac97_write(struct snd_ac97 *ac97, unsigned short reg,
> if (reg > 0x7f)
> return;
>
> - mutex_lock(&fsl_ac97_data->ac97_reg_lock);
> + guard(mutex)(&fsl_ac97_data->ac97_reg_lock);
>
> ret = clk_prepare_enable(fsl_ac97_data->clk);
> if (ret) {
> pr_err("ac97 write clk_prepare_enable failed: %d\n",
> ret);
> - goto ret_unlock;
> + return;
> }
>
> lreg = reg << 12;
> @@ -1238,9 +1238,6 @@ static void fsl_ssi_ac97_write(struct snd_ac97 *ac97, unsigned short reg,
> udelay(100);
>
> clk_disable_unprepare(fsl_ac97_data->clk);
> -
> -ret_unlock:
> - mutex_unlock(&fsl_ac97_data->ac97_reg_lock);
> }
>
> static unsigned short fsl_ssi_ac97_read(struct snd_ac97 *ac97,
> @@ -1252,12 +1249,12 @@ static unsigned short fsl_ssi_ac97_read(struct snd_ac97 *ac97,
> unsigned int lreg;
> int ret;
>
> - mutex_lock(&fsl_ac97_data->ac97_reg_lock);
> + guard(mutex)(&fsl_ac97_data->ac97_reg_lock);
>
> ret = clk_prepare_enable(fsl_ac97_data->clk);
> if (ret) {
> pr_err("ac97 read clk_prepare_enable failed: %d\n", ret);
> - goto ret_unlock;
> + return val;
> }
>
> lreg = (reg & 0x7f) << 12;
> @@ -1272,8 +1269,6 @@ static unsigned short fsl_ssi_ac97_read(struct snd_ac97 *ac97,
>
> clk_disable_unprepare(fsl_ac97_data->clk);
>
> -ret_unlock:
> - mutex_unlock(&fsl_ac97_data->ac97_reg_lock);
> return val;
> }
>
> --
> 2.43.0
>
>
^ permalink raw reply
* Re: [PATCH v2 03/11] ASoC: fsl_easrc: Use guard() for spin locks
From: Frank Li @ 2026-06-15 14:24 UTC (permalink / raw)
To: phucduc.bui
Cc: Mark Brown, Liam Girdwood, Jaroslav Kysela, Takashi Iwai,
Shengjiu Wang, Xiubo Li, Frank Li, Fabio Estevam, Nicolin Chen,
Sascha Hauer, Pengutronix Kernel Team, linux-sound, linux-kernel,
linux-arm-kernel, imx, linuxppc-dev
In-Reply-To: <20260615093824.115751-4-phucduc.bui@gmail.com>
On Mon, Jun 15, 2026 at 04:38:16PM +0700, phucduc.bui@gmail.com wrote:
> From: bui duc phuc <phucduc.bui@gmail.com>
>
> Clean up the code using guard() for spin locks.
> Merely code refactoring, and no behavior change.
>
> Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> sound/soc/fsl/fsl_easrc.c | 36 ++++++++++--------------------------
> 1 file changed, 10 insertions(+), 26 deletions(-)
>
> diff --git a/sound/soc/fsl/fsl_easrc.c b/sound/soc/fsl/fsl_easrc.c
> index 114a6c0b6b73..edfd943197a0 100644
> --- a/sound/soc/fsl/fsl_easrc.c
> +++ b/sound/soc/fsl/fsl_easrc.c
> @@ -1025,7 +1025,6 @@ static int fsl_easrc_config_context(struct fsl_asrc *easrc, unsigned int ctx_id)
> struct fsl_easrc_ctx_priv *ctx_priv;
> struct fsl_asrc_pair *ctx;
> struct device *dev;
> - unsigned long lock_flags;
> int ret;
>
> if (!easrc)
> @@ -1053,9 +1052,8 @@ static int fsl_easrc_config_context(struct fsl_asrc *easrc, unsigned int ctx_id)
> if (ret)
> return ret;
>
> - spin_lock_irqsave(&easrc->lock, lock_flags);
> - ret = fsl_easrc_config_slot(easrc, ctx->index);
> - spin_unlock_irqrestore(&easrc->lock, lock_flags);
> + scoped_guard(spinlock_irqsave, &easrc->lock)
> + ret = fsl_easrc_config_slot(easrc, ctx->index);
> if (ret)
> return ret;
>
> @@ -1301,13 +1299,12 @@ static int fsl_easrc_request_context(int channels, struct fsl_asrc_pair *ctx)
> enum asrc_pair_index index = ASRC_INVALID_PAIR;
> struct fsl_asrc *easrc = ctx->asrc;
> struct device *dev;
> - unsigned long lock_flags;
> int ret = 0;
> int i;
>
> dev = &easrc->pdev->dev;
>
> - spin_lock_irqsave(&easrc->lock, lock_flags);
> + guard(spinlock_irqsave)(&easrc->lock);
>
> for (i = ASRC_PAIR_A; i < EASRC_CTX_MAX_NUM; i++) {
> if (easrc->pair[i])
> @@ -1331,8 +1328,6 @@ static int fsl_easrc_request_context(int channels, struct fsl_asrc_pair *ctx)
> easrc->channel_avail -= channels;
> }
>
> - spin_unlock_irqrestore(&easrc->lock, lock_flags);
> -
> return ret;
> }
>
> @@ -1343,7 +1338,6 @@ static int fsl_easrc_request_context(int channels, struct fsl_asrc_pair *ctx)
> */
> static void fsl_easrc_release_context(struct fsl_asrc_pair *ctx)
> {
> - unsigned long lock_flags;
> struct fsl_asrc *easrc;
>
> if (!ctx)
> @@ -1351,14 +1345,12 @@ static void fsl_easrc_release_context(struct fsl_asrc_pair *ctx)
>
> easrc = ctx->asrc;
>
> - spin_lock_irqsave(&easrc->lock, lock_flags);
> + guard(spinlock_irqsave)(&easrc->lock);
>
> fsl_easrc_release_slot(easrc, ctx->index);
>
> easrc->channel_avail += ctx->channels;
> easrc->pair[ctx->index] = NULL;
> -
> - spin_unlock_irqrestore(&easrc->lock, lock_flags);
> }
>
> /*
> @@ -2292,15 +2284,13 @@ static int fsl_easrc_runtime_suspend(struct device *dev)
> {
> struct fsl_asrc *easrc = dev_get_drvdata(dev);
> struct fsl_easrc_priv *easrc_priv = easrc->private;
> - unsigned long lock_flags;
>
> regcache_cache_only(easrc->regmap, true);
>
> clk_disable_unprepare(easrc->mem_clk);
>
> - spin_lock_irqsave(&easrc->lock, lock_flags);
> - easrc_priv->firmware_loaded = 0;
> - spin_unlock_irqrestore(&easrc->lock, lock_flags);
> + scoped_guard(spinlock_irqsave, &easrc->lock)
> + easrc_priv->firmware_loaded = 0;
>
> return 0;
> }
> @@ -2311,7 +2301,6 @@ static int fsl_easrc_runtime_resume(struct device *dev)
> struct fsl_easrc_priv *easrc_priv = easrc->private;
> struct fsl_easrc_ctx_priv *ctx_priv;
> struct fsl_asrc_pair *ctx;
> - unsigned long lock_flags;
> int ret;
> int i;
>
> @@ -2323,13 +2312,11 @@ static int fsl_easrc_runtime_resume(struct device *dev)
> regcache_mark_dirty(easrc->regmap);
> regcache_sync(easrc->regmap);
>
> - spin_lock_irqsave(&easrc->lock, lock_flags);
> - if (easrc_priv->firmware_loaded) {
> - spin_unlock_irqrestore(&easrc->lock, lock_flags);
> - goto skip_load;
> + scoped_guard(spinlock_irqsave, &easrc->lock) {
> + if (easrc_priv->firmware_loaded)
> + return 0;
> + easrc_priv->firmware_loaded = 1;
> }
> - easrc_priv->firmware_loaded = 1;
> - spin_unlock_irqrestore(&easrc->lock, lock_flags);
>
> ret = fsl_easrc_get_firmware(easrc);
> if (ret) {
> @@ -2377,9 +2364,6 @@ static int fsl_easrc_runtime_resume(struct device *dev)
> goto disable_mem_clk;
> }
>
> -skip_load:
> - return 0;
> -
> disable_mem_clk:
> clk_disable_unprepare(easrc->mem_clk);
> return ret;
> --
> 2.43.0
>
>
^ permalink raw reply
* Re: [PATCH v2 07/11] ASoC: fsl_xcvr: Use guard() for spin locks
From: Frank Li @ 2026-06-15 14:19 UTC (permalink / raw)
To: phucduc.bui
Cc: Mark Brown, Liam Girdwood, Jaroslav Kysela, Takashi Iwai,
Shengjiu Wang, Xiubo Li, Frank Li, Fabio Estevam, Nicolin Chen,
Sascha Hauer, Pengutronix Kernel Team, linux-sound, linux-kernel,
linux-arm-kernel, imx, linuxppc-dev
In-Reply-To: <20260615093824.115751-8-phucduc.bui@gmail.com>
On Mon, Jun 15, 2026 at 04:38:20PM +0700, phucduc.bui@gmail.com wrote:
> From: bui duc phuc <phucduc.bui@gmail.com>
>
> Clean up the code using guard() for spin locks.
> Merely code refactoring, and no behavior change.
>
> Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> sound/soc/fsl/fsl_xcvr.c | 29 ++++++++++++-----------------
> 1 file changed, 12 insertions(+), 17 deletions(-)
>
> diff --git a/sound/soc/fsl/fsl_xcvr.c b/sound/soc/fsl/fsl_xcvr.c
> index 6677d3bf36ec..41d100500534 100644
> --- a/sound/soc/fsl/fsl_xcvr.c
> +++ b/sound/soc/fsl/fsl_xcvr.c
> @@ -797,10 +797,9 @@ static int fsl_xcvr_trigger(struct snd_pcm_substream *substream, int cmd,
> {
> struct fsl_xcvr *xcvr = snd_soc_dai_get_drvdata(dai);
> bool tx = substream->stream == SNDRV_PCM_STREAM_PLAYBACK;
> - unsigned long lock_flags;
> int ret = 0;
>
> - spin_lock_irqsave(&xcvr->lock, lock_flags);
> + guard(spinlock_irqsave)(&xcvr->lock);
>
> switch (cmd) {
> case SNDRV_PCM_TRIGGER_START:
> @@ -812,7 +811,7 @@ static int fsl_xcvr_trigger(struct snd_pcm_substream *substream, int cmd,
> FSL_XCVR_EXT_CTRL_DPTH_RESET(tx));
> if (ret < 0) {
> dev_err(dai->dev, "Failed to set DPATH RESET: %d\n", ret);
> - goto release_lock;
> + return ret;
> }
>
> if (tx) {
> @@ -824,7 +823,7 @@ static int fsl_xcvr_trigger(struct snd_pcm_substream *substream, int cmd,
> FSL_XCVR_ISR_CMDC_TX_EN);
> if (ret < 0) {
> dev_err(dai->dev, "err updating isr %d\n", ret);
> - goto release_lock;
> + return ret;
> }
> fallthrough;
> case FSL_XCVR_MODE_SPDIF:
> @@ -833,7 +832,7 @@ static int fsl_xcvr_trigger(struct snd_pcm_substream *substream, int cmd,
> FSL_XCVR_TX_DPTH_CTRL_STRT_DATA_TX);
> if (ret < 0) {
> dev_err(dai->dev, "Failed to start DATA_TX: %d\n", ret);
> - goto release_lock;
> + return ret;
> }
> break;
> }
> @@ -844,14 +843,14 @@ static int fsl_xcvr_trigger(struct snd_pcm_substream *substream, int cmd,
> FSL_XCVR_EXT_CTRL_DMA_DIS(tx), 0);
> if (ret < 0) {
> dev_err(dai->dev, "Failed to enable DMA: %d\n", ret);
> - goto release_lock;
> + return ret;
> }
>
> ret = regmap_update_bits(xcvr->regmap, FSL_XCVR_EXT_IER0,
> FSL_XCVR_IRQ_EARC_ALL, FSL_XCVR_IRQ_EARC_ALL);
> if (ret < 0) {
> dev_err(dai->dev, "Error while setting IER0: %d\n", ret);
> - goto release_lock;
> + return ret;
> }
>
> /* clear DPATH RESET */
> @@ -860,7 +859,7 @@ static int fsl_xcvr_trigger(struct snd_pcm_substream *substream, int cmd,
> 0);
> if (ret < 0) {
> dev_err(dai->dev, "Failed to clear DPATH RESET: %d\n", ret);
> - goto release_lock;
> + return ret;
> }
>
> break;
> @@ -873,14 +872,14 @@ static int fsl_xcvr_trigger(struct snd_pcm_substream *substream, int cmd,
> FSL_XCVR_EXT_CTRL_DMA_DIS(tx));
> if (ret < 0) {
> dev_err(dai->dev, "Failed to disable DMA: %d\n", ret);
> - goto release_lock;
> + return ret;
> }
>
> ret = regmap_update_bits(xcvr->regmap, FSL_XCVR_EXT_IER0,
> FSL_XCVR_IRQ_EARC_ALL, 0);
> if (ret < 0) {
> dev_err(dai->dev, "Failed to clear IER0: %d\n", ret);
> - goto release_lock;
> + return ret;
> }
>
> if (tx) {
> @@ -891,7 +890,7 @@ static int fsl_xcvr_trigger(struct snd_pcm_substream *substream, int cmd,
> FSL_XCVR_TX_DPTH_CTRL_STRT_DATA_TX);
> if (ret < 0) {
> dev_err(dai->dev, "Failed to stop DATA_TX: %d\n", ret);
> - goto release_lock;
> + return ret;
> }
> if (xcvr->soc_data->spdif_only)
> break;
> @@ -905,7 +904,7 @@ static int fsl_xcvr_trigger(struct snd_pcm_substream *substream, int cmd,
> if (ret < 0) {
> dev_err(dai->dev,
> "Err updating ISR %d\n", ret);
> - goto release_lock;
> + return ret;
> }
> break;
> }
> @@ -916,8 +915,6 @@ static int fsl_xcvr_trigger(struct snd_pcm_substream *substream, int cmd,
> break;
> }
>
> -release_lock:
> - spin_unlock_irqrestore(&xcvr->lock, lock_flags);
> return ret;
> }
>
> @@ -1448,11 +1445,10 @@ static void reset_rx_work(struct work_struct *work)
> {
> struct fsl_xcvr *xcvr = container_of(work, struct fsl_xcvr, work_rst);
> struct device *dev = &xcvr->pdev->dev;
> - unsigned long lock_flags;
> u32 ext_ctrl;
>
> dev_dbg(dev, "reset rx path\n");
> - spin_lock_irqsave(&xcvr->lock, lock_flags);
> + guard(spinlock_irqsave)(&xcvr->lock);
> regmap_read(xcvr->regmap, FSL_XCVR_EXT_CTRL, &ext_ctrl);
>
> if (!(ext_ctrl & FSL_XCVR_EXT_CTRL_DMA_RD_DIS)) {
> @@ -1469,7 +1465,6 @@ static void reset_rx_work(struct work_struct *work)
> FSL_XCVR_EXT_CTRL_RX_DPTH_RESET,
> 0);
> }
> - spin_unlock_irqrestore(&xcvr->lock, lock_flags);
> }
>
> static irqreturn_t irq0_isr(int irq, void *devid)
> --
> 2.43.0
>
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox