* Re: [PATCH v7 5/6] firmware: smccc: arm-cca-guest: Bind the TSM provider to an SMCCC device
From: Suzuki K Poulose @ 2026-06-11 17:06 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, Andre Przywara
In-Reply-To: <20260611130429.295516-6-aneesh.kumar@kernel.org>
On 11/06/2026 14:04, Aneesh Kumar K.V (Arm) wrote:
> The Arm CCA guest TSM provider currently binds through the arm-cca-dev
> platform device. Like arm-smccc-trng, this device is not an independent
> platform resource; it is a software representation of the RSI firmware
> service discovered through SMCCC.
>
> Move RSI discovery into the SMCCC firmware driver. When the SMCCC conduit
> is SMC and if RSI ABI version call is supported, create an arm-rsi-dev
> SMCCC device. Convert the Arm CCA guest TSM provider to an SMCCC driver so
> it binds to that discovered RSI service and keeps module autoloading
> through the SMCCC device id table.
>
> Keep the old arm-cca-dev platform-device registration for now. Userspace
> has used that device as a Realm-guest indicator, so removing it is left to
> a follow-up patch that adds a replacement sysfs ABI.
>
> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
> ---
> arch/arm64/include/asm/rsi.h | 2 -
> arch/arm64/kernel/rsi.c | 2 +-
> drivers/firmware/smccc/smccc.c | 7 +++
> drivers/virt/coco/arm-cca-guest/Kconfig | 1 +
> drivers/virt/coco/arm-cca-guest/arm-cca.c | 56 +++++++++++------------
> include/linux/arm-smccc-rsi.h | 2 +
> 6 files changed, 39 insertions(+), 31 deletions(-)
>
> diff --git a/arch/arm64/include/asm/rsi.h b/arch/arm64/include/asm/rsi.h
> index 88b50d660e85..5f9c8623183d 100644
> --- a/arch/arm64/include/asm/rsi.h
> +++ b/arch/arm64/include/asm/rsi.h
> @@ -10,8 +10,6 @@
> #include <linux/jump_label.h>
> #include <asm/rsi_cmds.h>
>
> -#define RSI_PDEV_NAME "arm-cca-dev"
> -
> DECLARE_STATIC_KEY_FALSE(rsi_present);
>
> void __init arm64_rsi_init(void);
> diff --git a/arch/arm64/kernel/rsi.c b/arch/arm64/kernel/rsi.c
> index 92160f2e57ff..da440f71bb64 100644
> --- a/arch/arm64/kernel/rsi.c
> +++ b/arch/arm64/kernel/rsi.c
> @@ -161,7 +161,7 @@ void __init arm64_rsi_init(void)
> }
>
> static struct platform_device rsi_dev = {
> - .name = RSI_PDEV_NAME,
> + .name = "arm-cca-dev",
> .id = PLATFORM_DEVID_NONE
> };
>
> diff --git a/drivers/firmware/smccc/smccc.c b/drivers/firmware/smccc/smccc.c
> index a47696f3a5de..7127af3dbe5c 100644
> --- a/drivers/firmware/smccc/smccc.c
> +++ b/drivers/firmware/smccc/smccc.c
> @@ -10,6 +10,7 @@
> #include <linux/arm-smccc.h>
> #include <linux/kernel.h>
> #include <linux/arm-smccc-bus.h>
> +#include <linux/arm-smccc-rsi.h>
>
> #include <asm/archrandom.h>
>
> @@ -94,6 +95,12 @@ static const struct smccc_device_info smccc_devices[] __initconst = {
> .requires_smc = false,
> .device_name = "arm-smccc-trng",
> },
> +
> + {
> + .func_id = SMC_RSI_ABI_VERSION,
> + .requires_smc = true,
> + .device_name = RSI_DEV_NAME,
> + },
> };
>
> static bool __init smccc_probe_smccc_device(const struct smccc_device_info *smccc_dev)
> diff --git a/drivers/virt/coco/arm-cca-guest/Kconfig b/drivers/virt/coco/arm-cca-guest/Kconfig
> index 3f0f013f03f1..ad7538750c5a 100644
> --- a/drivers/virt/coco/arm-cca-guest/Kconfig
> +++ b/drivers/virt/coco/arm-cca-guest/Kconfig
> @@ -1,6 +1,7 @@
> config ARM_CCA_GUEST
> tristate "Arm CCA Guest driver"
> depends on ARM64
> + depends on HAVE_ARM_SMCCC_DISCOVERY
> select TSM_REPORTS
> help
> The driver provides userspace interface to request and
> diff --git a/drivers/virt/coco/arm-cca-guest/arm-cca.c b/drivers/virt/coco/arm-cca-guest/arm-cca.c
> index 0bbd1fa53ee4..4f9289ccf498 100644
> --- a/drivers/virt/coco/arm-cca-guest/arm-cca.c
> +++ b/drivers/virt/coco/arm-cca-guest/arm-cca.c
> @@ -4,6 +4,7 @@
> */
>
> #include <linux/arm-smccc.h>
> +#include <linux/arm-smccc-bus.h>
> #include <linux/cc_platform.h>
> #include <linux/kernel.h>
> #include <linux/mod_devicetable.h>
> @@ -189,16 +190,12 @@ static const struct tsm_report_ops arm_cca_tsm_report_ops = {
> .report_new = arm_cca_report_new,
> };
>
> -/**
> - * arm_cca_guest_init - Register with the Trusted Security Module (TSM)
> - * interface.
> - *
> - * Return:
> - * * %0 - Registered successfully with the TSM interface.
> - * * %-ENODEV - The execution context is not an Arm Realm.
> - * * %-EBUSY - Already registered.
> - */
> -static int __init arm_cca_guest_init(void)
> +static void unregister_cca_tsm_report(void *data)
> +{
> + tsm_report_unregister(&arm_cca_tsm_report_ops);
> +}
> +
> +static int cca_tsm_probe(struct arm_smccc_device *sdev)
> {
> int ret;
>
> @@ -206,30 +203,33 @@ static int __init arm_cca_guest_init(void)
> return -ENODEV;
>
> ret = tsm_report_register(&arm_cca_tsm_report_ops, NULL);
> - if (ret < 0)
> - pr_err("Error %d registering with TSM\n", ret);
> + if (ret < 0) {
> + dev_err_probe(&sdev->dev, ret, "Error registering with TSM\n");
> + return ret;
> + }
>
> - return ret;
> -}
> -module_init(arm_cca_guest_init);
> + ret = devm_add_action_or_reset(&sdev->dev, unregister_cca_tsm_report,
> + NULL);
> + if (ret < 0) {
> + dev_err_probe(&sdev->dev, ret, "Error registering devm action\n");
> + return ret;
> + }
>
> -/**
> - * arm_cca_guest_exit - unregister with the Trusted Security Module (TSM)
> - * interface.
> - */
> -static void __exit arm_cca_guest_exit(void)
> -{
> - tsm_report_unregister(&arm_cca_tsm_report_ops);
> + return 0;
> }
> -module_exit(arm_cca_guest_exit);
>
> -/* modalias, so userspace can autoload this module when RSI is available */
> -static const struct platform_device_id arm_cca_match[] __maybe_unused = {
> - { RSI_PDEV_NAME, 0},
> - { }
> +static const struct arm_smccc_device_id cca_tsm_id_table[] = {
> + { .name = RSI_DEV_NAME },
> + {}
> };
> +MODULE_DEVICE_TABLE(arm_smccc, cca_tsm_id_table);
>
> -MODULE_DEVICE_TABLE(platform, arm_cca_match);
> +static struct arm_smccc_driver cca_tsm_driver = {
> + .name = KBUILD_MODNAME,
> + .probe = cca_tsm_probe,
> + .id_table = cca_tsm_id_table,
> +};
> +module_arm_smccc_driver(cca_tsm_driver);
> MODULE_AUTHOR("Sami Mujawar <sami.mujawar@arm.com>");
> MODULE_DESCRIPTION("Arm CCA Guest TSM Driver");
> MODULE_LICENSE("GPL");
> diff --git a/include/linux/arm-smccc-rsi.h b/include/linux/arm-smccc-rsi.h
> index fddb77986f70..ae663aa8fd7f 100644
> --- a/include/linux/arm-smccc-rsi.h
> +++ b/include/linux/arm-smccc-rsi.h
> @@ -8,6 +8,8 @@
>
> #include <linux/arm-smccc.h>
>
> +#define RSI_DEV_NAME "arm-rsi-dev"
This shouldn't be here ? This is not part of the SMCCC RSI standard, but
a linux thing. May be in drivers/firmware/../rsi.h ?
Rest looks fine.
Suzuki
> +
> /*
> * This file describes the Realm Services Interface (RSI) Application Binary
> * Interface (ABI) for SMC calls made from within the Realm to the RMM and
^ permalink raw reply
* [PATCH] power: supply: macsmc: Support macOS 27 SMC firmware
From: Sasha Finkelstein @ 2026-06-11 16:49 UTC (permalink / raw)
To: Sven Peter, Janne Grunau, Neal Gompa, Sebastian Reichel
Cc: asahi, linux-arm-kernel, linux-pm, linux-kernel,
Sasha Finkelstein
The SMC firmware included in macOS 27 changed the size of BCF0 key from
4 to 1 bytes. This key is used for indicating that battery state is
critically low.
Signed-off-by: Sasha Finkelstein <k@chaosmail.tech>
---
drivers/power/supply/macsmc-power.c | 34 +++++++++++++++++++++++++++++++---
1 file changed, 31 insertions(+), 3 deletions(-)
diff --git a/drivers/power/supply/macsmc-power.c b/drivers/power/supply/macsmc-power.c
index 33ca07460f3a..650dc8740f71 100644
--- a/drivers/power/supply/macsmc-power.c
+++ b/drivers/power/supply/macsmc-power.c
@@ -86,6 +86,7 @@ struct macsmc_power {
bool has_ch0i; /* Force discharge (Older firmware) */
bool has_ch0c; /* Inhibit charge (Older firmware) */
bool has_chte; /* Inhibit charge (Modern firmware) */
+ bool bcf0_1byte; /* Battery critical */
u8 num_cells;
int nominal_voltage_mv;
@@ -273,6 +274,18 @@ static int macsmc_battery_get_date(const char *s, int *out)
return 0;
}
+static int macsmc_battery_read_bcf0(struct macsmc_power *power, u32 *val)
+{
+ u8 tval;
+ int ret;
+
+ if (!power->bcf0_1byte)
+ return apple_smc_read_u32(power->smc, SMC_KEY(BCF0), val);
+ ret = apple_smc_read_u8(power->smc, SMC_KEY(BCF0), &tval);
+ *val = tval;
+ return ret;
+}
+
static int macsmc_battery_get_capacity_level(struct macsmc_power *power)
{
bool flag;
@@ -280,7 +293,7 @@ static int macsmc_battery_get_capacity_level(struct macsmc_power *power)
int ret;
/* Check for emergency shutdown condition */
- if (apple_smc_read_u32(power->smc, SMC_KEY(BCF0), &val) >= 0 && val)
+ if (macsmc_battery_read_bcf0(power, &val) >= 0 && val)
return POWER_SUPPLY_CAPACITY_LEVEL_CRITICAL;
/* Check AC status for whether we could boot in this state */
@@ -577,7 +590,7 @@ static void macsmc_power_critical_work(struct work_struct *wrk)
* Check if SMC flagged the battery as empty.
* We trigger a graceful shutdown to let the OS save data.
*/
- if (apple_smc_read_u32(power->smc, SMC_KEY(BCF0), &bcf0) == 0 && bcf0 != 0) {
+ if (macsmc_battery_read_bcf0(power, &bcf0) == 0 && bcf0 != 0) {
power->orderly_shutdown_triggered = true;
dev_crit(power->dev, "Battery critical (empty flag set). Triggering orderly shutdown.\n");
orderly_poweroff(true);
@@ -616,6 +629,7 @@ static int macsmc_power_probe(struct platform_device *pdev)
struct device *dev = &pdev->dev;
struct apple_smc *smc = dev_get_drvdata(pdev->dev.parent);
struct power_supply_config psy_cfg = {};
+ struct apple_smc_key_info info;
struct macsmc_power *power;
bool has_battery = false;
bool has_ac_adapter = false;
@@ -714,6 +728,20 @@ static int macsmc_power_probe(struct platform_device *pdev)
if (apple_smc_key_exists(smc, SMC_KEY(CH0I)))
power->has_ch0i = true;
+ ret = apple_smc_get_key_info(power->smc, SMC_KEY(BCF0), &info);
+ if (ret) {
+ dev_err(&pdev->dev, "Failed to determine BCF0 key size\n");
+ return ret;
+ }
+ if (info.size == 1)
+ power->bcf0_1byte = true;
+ else if (info.size == 4)
+ power->bcf0_1byte = false;
+ else {
+ dev_err(&pdev->dev, "Unexpected BCF0 key size %d\n", info.size);
+ return -EIO;
+ }
+
/* Reset "Optimised Battery Charging" flags to default state */
if (power->has_chte)
apple_smc_write_u32(smc, SMC_KEY(CHTE), 0);
@@ -766,7 +794,7 @@ static int macsmc_power_probe(struct platform_device *pdev)
power->nominal_voltage_mv = MACSMC_NOMINAL_CELL_VOLTAGE_MV * power->num_cells;
/* Enable critical shutdown notifications by reading status once */
- apple_smc_read_u32(power->smc, SMC_KEY(BCF0), &val32);
+ macsmc_battery_read_bcf0(power, &val32);
psy_cfg.drv_data = power;
power->batt = devm_power_supply_register(dev, &power->batt_desc, &psy_cfg);
---
base-commit: 9716c086c8e8b141d35aa61f2e96a2e83de212a7
change-id: 20260611-gate-power-cfd726dc0d7f
Best regards,
--
Sasha Finkelstein <k@chaosmail.tech>
^ permalink raw reply related
* Re: [PATCH v22 08/13] mfd: core: Add firmware-node support to MFD cells
From: Shivendra Pratap @ 2026-06-11 16:44 UTC (permalink / raw)
To: Lee Jones
Cc: Bartosz Golaszewski, Sebastian Reichel, Mark Rutland,
Lorenzo Pieralisi, Rafael J. Wysocki, Daniel Lezcano,
Christian Loehle, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Arnd Bergmann,
Souvik Chakravarty, Andy Yan, Matthias Brugger, John Stultz,
Moritz Fischer, Sudeep Holla, linux-pm, linux-kernel,
linux-arm-msm, linux-arm-kernel, devicetree, Florian Fainelli,
Krzysztof Kozlowski, Dmitry Baryshkov, Mukesh Ojha, Andre Draszik,
Greg Kroah-Hartman, Kathiravan Thirumoorthy, Srinivas Kandagatla,
Bartosz Golaszewski
In-Reply-To: <20260611164211.GD1212816@google.com>
On 11-06-2026 22:12, Lee Jones wrote:
> /* Sashiko Automation: Reviewed (0 Findings) */
>
> On Thu, 04 Jun 2026, Shivendra Pratap wrote:
>
>>
>>
>> On 25-05-2026 15:04, Shivendra Pratap wrote:
>>>
>>>
>>> On 22-05-2026 14:38, Bartosz Golaszewski wrote:
>>>> On Thu, May 21, 2026 at 6:27 PM Lee Jones <lee@kernel.org> wrote:
>>>>>
>>>>> On Thu, 21 May 2026, Bartosz Golaszewski wrote:
>>>>>
>>>>>> On Thu, May 21, 2026 at 3:24 PM Lee Jones <lee@kernel.org> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> I suggested it because of its flexibility. The alternative I had in
>>>>>>>> mind is something like a new field in mfd_cell:
>>>>>>>>
>>>>>>>> const char *cell_node_name;
>>>>>>>>
>>>>>>>> Which - if set - would tell MFD to look up an fwnode
>>>>>>>> that's a child of
>>>>>>>> the parent device's node by name - as it may not have a compatible.
>>>>>>>
>>>>>>> Remind me why the chlid device can't look-up its own fwnode?
>>>>>>>
>>>>>>
>>>>>> Oh sure it can, but should it? I'm not sure it's logically sound to
>>>>>> have the child device reach into the parent, look up the fwnode and
>>>>>> then assign it to itself after it's already attached to the driver.
>>>>>> This should be done at the subsystem level before the device is
>>>>>> registered.
>>>>>
>>>>> Leaf drivers reach back into the parent all the time.
>>>>>
>>>>
>>>> But drivers don't generally assign firmware nodes to devices they are
>>>> already bound to. This is racy as in probe() the device is already
>>>> visible to the system. There's no synchronization of device property
>>>> access - properties are assumed to be read-only for a registered
>>>> device.
>>>
>>> thanks Bart/Lee. Any pointers to take this from here?
>>
>> Hi Lee,
>>
>> To take this patchset forward, it would be helpful to get your views on
>> fwnode based addition in mfd-core. Maybe, a member like "*named_fwnode" in
>> mfd-core and then a lookup logic, or any alternatives?
>
> Can you please make your best pick and resubmit the set please?
>
> I'll comment on a fresh set with fresh eyes.
sure. thanks.
thanks,
Shivendra
^ permalink raw reply
* Re: [PATCH v22 08/13] mfd: core: Add firmware-node support to MFD cells
From: Lee Jones @ 2026-06-11 16:42 UTC (permalink / raw)
To: Shivendra Pratap
Cc: Bartosz Golaszewski, Sebastian Reichel, Mark Rutland,
Lorenzo Pieralisi, Rafael J. Wysocki, Daniel Lezcano,
Christian Loehle, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Arnd Bergmann,
Souvik Chakravarty, Andy Yan, Matthias Brugger, John Stultz,
Moritz Fischer, Sudeep Holla, linux-pm, linux-kernel,
linux-arm-msm, linux-arm-kernel, devicetree, Florian Fainelli,
Krzysztof Kozlowski, Dmitry Baryshkov, Mukesh Ojha, Andre Draszik,
Greg Kroah-Hartman, Kathiravan Thirumoorthy, Srinivas Kandagatla,
Bartosz Golaszewski
In-Reply-To: <81680397-3bbd-4f66-9166-546c8fe753fc@oss.qualcomm.com>
/* Sashiko Automation: Reviewed (0 Findings) */
On Thu, 04 Jun 2026, Shivendra Pratap wrote:
>
>
> On 25-05-2026 15:04, Shivendra Pratap wrote:
> >
> >
> > On 22-05-2026 14:38, Bartosz Golaszewski wrote:
> > > On Thu, May 21, 2026 at 6:27 PM Lee Jones <lee@kernel.org> wrote:
> > > >
> > > > On Thu, 21 May 2026, Bartosz Golaszewski wrote:
> > > >
> > > > > On Thu, May 21, 2026 at 3:24 PM Lee Jones <lee@kernel.org> wrote:
> > > > > >
> > > > > > >
> > > > > > > I suggested it because of its flexibility. The alternative I had in
> > > > > > > mind is something like a new field in mfd_cell:
> > > > > > >
> > > > > > > const char *cell_node_name;
> > > > > > >
> > > > > > > Which - if set - would tell MFD to look up an fwnode
> > > > > > > that's a child of
> > > > > > > the parent device's node by name - as it may not have a compatible.
> > > > > >
> > > > > > Remind me why the chlid device can't look-up its own fwnode?
> > > > > >
> > > > >
> > > > > Oh sure it can, but should it? I'm not sure it's logically sound to
> > > > > have the child device reach into the parent, look up the fwnode and
> > > > > then assign it to itself after it's already attached to the driver.
> > > > > This should be done at the subsystem level before the device is
> > > > > registered.
> > > >
> > > > Leaf drivers reach back into the parent all the time.
> > > >
> > >
> > > But drivers don't generally assign firmware nodes to devices they are
> > > already bound to. This is racy as in probe() the device is already
> > > visible to the system. There's no synchronization of device property
> > > access - properties are assumed to be read-only for a registered
> > > device.
> >
> > thanks Bart/Lee. Any pointers to take this from here?
>
> Hi Lee,
>
> To take this patchset forward, it would be helpful to get your views on
> fwnode based addition in mfd-core. Maybe, a member like "*named_fwnode" in
> mfd-core and then a lookup logic, or any alternatives?
Can you please make your best pick and resubmit the set please?
I'll comment on a fresh set with fresh eyes.
--
Lee Jones
^ permalink raw reply
* Re: [PATCH v7 4/8] mfd: khadas-mcu: Add support for VIM4 MCU variant
From: Lee Jones @ 2026-06-11 16:40 UTC (permalink / raw)
To: linux-kernel-dev
Cc: Neil Armstrong, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Andi Shyti, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Beniamino Galvani, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Liam Girdwood, Mark Brown, linux-amlogic, devicetree,
linux-kernel, linux-i2c, linux-arm-kernel, linux-pm
In-Reply-To: <20260603-add-mcu-fan-khadas-vim4-v7-4-594ba8a965d8@aliel.fr>
/* Sashiko Automation: Reviewed (0 Findings) */
On Wed, 03 Jun 2026, Ronald Claveau via B4 Relay wrote:
> From: Ronald Claveau <linux-kernel-dev@aliel.fr>
>
> Refactor probe() to use per-variant values
> instead of hardcoded globals.
>
> Add dedicated regmap configuration for the VIM4 MCU,
> with its own volatile/writeable registers.
>
> Add the fan control register
> (0–100 levels vs 0–3 for previous supported boards).
>
> Add a new compatible string "khadas,vim4-mcu".
>
> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
> ---
> drivers/mfd/khadas-mcu.c | 115 ++++++++++++++++++++++++++++++++++++++++-------
> 1 file changed, 99 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/mfd/khadas-mcu.c b/drivers/mfd/khadas-mcu.c
> index ba981a7886921..1bf260729d73b 100644
> --- a/drivers/mfd/khadas-mcu.c
> +++ b/drivers/mfd/khadas-mcu.c
> @@ -75,47 +75,129 @@ static const struct regmap_config khadas_mcu_regmap_config = {
> .cache_type = REGCACHE_MAPLE,
> };
>
> -static struct mfd_cell khadas_mcu_fan_cells[] = {
> +static const struct khadas_mcu_fan_pdata khadas_mcu_fan_pdata = {
> + .fan_reg = KHADAS_MCU_CMD_FAN_STATUS_CTRL_REG,
> + .max_level = 3, /* Fan speed: 0 = off, 1 = low, 2 = medium, 3 = high */
Instead of this comment, you could always just define the value(s)?
> +};
> +
> +static const struct mfd_cell khadas_mcu_fan_cells[] = {
> /* VIM1/2 Rev13+ and VIM3 only */
> - { .name = "khadas-mcu-fan-ctrl", },
> + {
> + .name = "khadas-mcu-fan-ctrl",
> + .platform_data = &khadas_mcu_fan_pdata,
> + .pdata_size = sizeof(khadas_mcu_fan_pdata),
No need to attempt to align the '=' like this, please.
> + },
> };
>
> -static struct mfd_cell khadas_mcu_cells[] = {
> +static const struct mfd_cell khadas_mcu_cells[] = {
> { .name = "khadas-mcu-user-mem", },
> };
>
> +static bool khadas_mcu_vim4_reg_volatile(struct device *dev, unsigned int reg)
> +{
> + switch (reg) {
> + case KHADAS_MCU_PWR_OFF_CMD_REG:
> + case KHADAS_MCU_VIM4_REST_CONF_REG:
> + case KHADAS_MCU_WOL_INIT_START_REG:
> + case KHADAS_MCU_VIM4_LED_ON_RAM_REG:
> + case KHADAS_MCU_VIM4_FAN_CTRL_REG:
> + case KHADAS_MCU_VIM4_WDT_EN_REG:
> + case KHADAS_MCU_VIM4_SYS_RST_REG:
> + return true;
> + default:
> + return false;
> + }
> +}
> +
> +static bool khadas_mcu_vim4_reg_writeable(struct device *dev, unsigned int reg)
> +{
> + switch (reg) {
> + case KHADAS_MCU_VERSION_0_REG:
> + case KHADAS_MCU_VERSION_1_REG:
> + case KHADAS_MCU_SHUTDOWN_NORMAL_STATUS_REG:
> + return false;
> + default:
> + return true;
> + }
> +}
> +
> +static const struct regmap_config khadas_mcu_vim4_regmap_config = {
> + .reg_bits = 8,
> + .reg_stride = 1,
> + .val_bits = 8,
> + .max_register = KHADAS_MCU_VIM4_SYS_RST_REG,
> + .volatile_reg = khadas_mcu_vim4_reg_volatile,
> + .writeable_reg = khadas_mcu_vim4_reg_writeable,
> + .cache_type = REGCACHE_MAPLE,
> +};
> +
> +static const struct khadas_mcu_fan_pdata khadas_vim4_fan_pdata = {
> + .fan_reg = KHADAS_MCU_VIM4_FAN_CTRL_REG,
> + .max_level = 0x64,
> +};
> +
> +static const struct mfd_cell khadas_mcu_vim4_cells[] = {
> + {
> + .name = "khadas-mcu-fan-ctrl",
> + .platform_data = &khadas_vim4_fan_pdata,
> + .pdata_size = sizeof(khadas_vim4_fan_pdata),
> + },
> +};
> +
> static int khadas_mcu_probe(struct i2c_client *client)
> {
> + const struct mfd_cell *cells, *fan_cells;
> + const struct regmap_config *regmap_cfg;
> struct device *dev = &client->dev;
> + int ncells, nfan_cells, ret;
> struct khadas_mcu *ddata;
> - int ret;
>
> ddata = devm_kzalloc(dev, sizeof(*ddata), GFP_KERNEL);
> if (!ddata)
> return -ENOMEM;
>
> + switch ((uintptr_t)i2c_get_match_data(client)) {
> + case KHADAS_MCU_GENERIC:
> + regmap_cfg = &khadas_mcu_regmap_config;
> + cells = khadas_mcu_cells;
> + ncells = ARRAY_SIZE(khadas_mcu_cells);
> + fan_cells = khadas_mcu_fan_cells;
> + nfan_cells = ARRAY_SIZE(khadas_mcu_fan_cells);
> + break;
> + case KHADAS_MCU_VIM4:
> + regmap_cfg = &khadas_mcu_vim4_regmap_config;
> + cells = NULL;
> + ncells = 0;
> + fan_cells = khadas_mcu_vim4_cells;
> + nfan_cells = ARRAY_SIZE(khadas_mcu_vim4_cells);
I'm not as offended by this as I thought I would be!
> + break;
> + default:
> + return -ENODEV;
> + }
> +
> i2c_set_clientdata(client, ddata);
>
> ddata->dev = dev;
>
> - ddata->regmap = devm_regmap_init_i2c(client, &khadas_mcu_regmap_config);
> + ddata->regmap = devm_regmap_init_i2c(client, regmap_cfg);
> if (IS_ERR(ddata->regmap)) {
> ret = PTR_ERR(ddata->regmap);
> - dev_err(dev, "Failed to allocate register map: %d\n", ret);
> - return ret;
> + return dev_err_probe(dev, ret, "Failed to allocate register map\n");
> }
>
> - ret = devm_mfd_add_devices(dev, PLATFORM_DEVID_NONE,
> - khadas_mcu_cells,
> - ARRAY_SIZE(khadas_mcu_cells),
> - NULL, 0, NULL);
> - if (ret)
> - return ret;
> + if (cells && ncells) {
> + ret = devm_mfd_add_devices(dev, PLATFORM_DEVID_NONE,
> + cells,
> + ncells,
> + NULL, 0, NULL);
> + if (ret)
> + return ret;
> + }
>
> if (of_property_present(dev->of_node, "#cooling-cells"))
> return devm_mfd_add_devices(dev, PLATFORM_DEVID_NONE,
> - khadas_mcu_fan_cells,
> - ARRAY_SIZE(khadas_mcu_fan_cells),
> + fan_cells,
> + nfan_cells,
> NULL, 0, NULL);
>
> return 0;
> @@ -123,7 +205,8 @@ static int khadas_mcu_probe(struct i2c_client *client)
>
> #ifdef CONFIG_OF
> static const struct of_device_id khadas_mcu_of_match[] = {
> - { .compatible = "khadas,mcu", },
> + { .compatible = "khadas,mcu", .data = (void *)KHADAS_MCU_GENERIC },
> + { .compatible = "khadas,vim4-mcu", .data = (void *)KHADAS_MCU_VIM4 },
> {},
> };
> MODULE_DEVICE_TABLE(of, khadas_mcu_of_match);
>
> --
> 2.49.0
>
>
--
Lee Jones
^ permalink raw reply
* Re: [PATCH 3/4] mfd: mt6397-core: add mt6323 AUXADC support
From: Lee Jones @ 2026-06-11 16:37 UTC (permalink / raw)
To: rva333
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, linux-iio, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, Ben Grisdale
In-Reply-To: <20260602-mt6323-adc-v1-3-68ec737508ee@protonmail.com>
Interesting. Has this been considered?
/* Sashiko Automation: Issues Found (1 Findings) */
On Tue, 02 Jun 2026, Roman Vivchar via B4 Relay wrote:
> From: Roman Vivchar <rva333@protonmail.com>
>
> The mt6323 PMIC includes an AUXADC. Register the AUXADC in the mt6323
> devices array to allow the corresponding driver to probe using compatible
> string.
>
> Tested-by: Ben Grisdale <bengris32@protonmail.ch> # Amazon Echo Dot (2nd Generation)
> Signed-off-by: Roman Vivchar <rva333@protonmail.com>
> ---
> drivers/mfd/mt6397-core.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/mfd/mt6397-core.c b/drivers/mfd/mt6397-core.c
> index 3e58d0764c7e..013b0857fb54 100644
> --- a/drivers/mfd/mt6397-core.c
> +++ b/drivers/mfd/mt6397-core.c
> @@ -125,6 +125,9 @@ static const struct resource mt6323_pwrc_resources[] = {
>
> static const struct mfd_cell mt6323_devs[] = {
> {
> + .name = "mt6323-auxadc",
> + .of_compatible = "mediatek,mt6323-auxadc",
[Severity: High]
Does adding this compatible string expose an unhandled edge case in the
auxadc driver?
If this device is instantiated directly from a Device Tree without an MFD
parent (e.g., at the DT root), dev->parent could be the platform bus
(which has a NULL parent) or NULL itself.
Looking at mt6323_auxadc_probe() in drivers/iio/adc/mt6323-auxadc.c:
regmap = dev_get_regmap(dev->parent->parent, NULL);
Could blindly dereferencing dev->parent->parent here, or passing a NULL
device to dev_get_regmap() (which calls devres_find()), result in a
kernel oops if probed as a root node?
> + }, {
> .name = "mt6323-rtc",
> .num_resources = ARRAY_SIZE(mt6323_rtc_resources),
> .resources = mt6323_rtc_resources,
>
> --
> 2.54.0
>
>
--
Lee Jones
^ permalink raw reply
* Re: [PATCH v3 2/3] dt-bindings: mfd: syscon: Drop custom select for older dtschema
From: Rob Herring @ 2026-06-11 16:31 UTC (permalink / raw)
To: Conor Dooley
Cc: Krzysztof Kozlowski, Lee Jones, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Jacky Huang,
Shan-Chun Hung, Geert Uytterhoeven, Magnus Damm, Heiko Stuebner,
Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, linux-renesas-soc, linux-rockchip, linux-omap
In-Reply-To: <20260609-vertical-antarctic-e18a7ec91685@spud>
On Tue, Jun 09, 2026 at 05:28:21PM +0100, Conor Dooley wrote:
> On Mon, Jun 08, 2026 at 10:44:25PM +0200, Krzysztof Kozlowski wrote:
> > Older dtschema <2024.02 required custom select to avoid applying this
> > binding to anything having "syscon" compatible. That's not the case
> > anymore and this additional select has two headaches:
> >
> > 1. Duplicates all the compatibles listed in the schema.
> >
> > 2. Is error-prone, because it requires contributor to add the compatible
> > in two places, otherwise the schema will be silently ignored.
> > The select list already misses mentioning compatibles:
> > mediatek,mt8365-infracfg-nao and renesas,r9a08g046-lvds-cmn (with the
> > latter being reverted for different reasons).
> >
> > This requires bumping minimum dtschema requirement to v2024.04, which
> > feels old enough to be a safe requirement.
>
> I agree, seems reasonable enough given it's a jump from 2023.09 and not
> some large jump.
> The diff is nice too!
> I assume Rob will be taking it, but just in case..
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
I expect Lee to take this. I suspect syscon.yaml has other conflicting
changes.
Rob
^ permalink raw reply
* Re: iio: adc: KASAN wild-memory-access in complete() on early IRQ
From: Jonathan Cameron @ 2026-06-11 16:22 UTC (permalink / raw)
To: Jaeyoung Chung
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Vladimir Zapolskiy,
Piotr Wojtaszczyk, linux-iio, linux-arm-kernel, linux-kernel,
Sangyun Kim, Kyungwook Boo
In-Reply-To: <20260610115700.774689-1-jjy600901@snu.ac.kr>
On Wed, 10 Jun 2026 20:57:00 +0900
Jaeyoung Chung <jjy600901@snu.ac.kr> wrote:
> Hi,
>
> lpc32xx_adc_probe() in drivers/iio/adc/lpc32xx_adc.c and
> spear_adc_probe() in drivers/iio/adc/spear_adc.c register their
> interrupt handler with devm_request_irq() before they initialize
> st->completion with init_completion(). If an interrupt arrives after
> devm_request_irq() and before init_completion(), the handler calls
> complete() on an uninitialized completion, causing a kernel panic.
>
> The probe path, in lpc32xx_adc_probe():
>
> iodev = devm_iio_device_alloc(&pdev->dev, sizeof(*st)); /* st kzalloc-zeroed */
> ...
> retval = devm_request_irq(&pdev->dev, irq, lpc32xx_adc_isr, 0,
> LPC32XXAD_NAME, st); /* register handler */
> ...
> init_completion(&st->completion); /* initialize completion */
>
> spear_adc_probe() has the same ordering: devm_request_irq() for
> spear_adc_isr() before init_completion(&st->completion).
>
> Both interrupt handlers, lpc32xx_adc_isr() and spear_adc_isr(), call
> complete():
>
> complete(&st->completion);
>
> If the device raises an interrupt before init_completion() runs,
> complete() acquires the uninitialized wait.lock and walks the zeroed
> task_list in swake_up_locked(). The zeroed task_list makes list_empty()
> return false, so swake_up_locked() dereferences a NULL list entry,
> triggering a KASAN wild-memory-access.
>
> Suggested fix: move init_completion(&st->completion) above
> devm_request_irq(), so the completion is valid before the handler can run.
>
> Reported-by: Sangyun Kim <sangyun.kim@snu.ac.kr>
> Reported-by: Kyungwook Boo <bookyungwook@gmail.com>
Hi I think the report is valid, but I'm curious to whether you ran these
drivers given the hardware is pretty obscure! If not how did KASAN detect
anything (unless there is a static analysis version I'm not aware of)
Given age of drivers and that this only occurs if a spurious IRQ turns
up I'm not going to rush to fix this. However, I'd certainly welcome
patches.
Thanks,
Jonathan
>
> Thanks,
> Jaeyoung Chung
^ permalink raw reply
* Re: [PATCHv2] PCI: mvebu: Use fixed-width interrupt masks
From: Bjorn Helgaas @ 2026-06-11 16:17 UTC (permalink / raw)
To: Rosen Penev
Cc: linux-pci, Thomas Petazzoni, Pali Rohár, Lorenzo Pieralisi,
linusw, Krzysztof Wilczyński, Manivannan Sadhasivam,
Rob Herring, Bjorn Helgaas,
moderated list:PCI DRIVER FOR MVEBU (Marvell Armada 370 and Ar...),linusw@kernel.org,
open list
In-Reply-To: <20260526044016.1025613-1-rosenp@gmail.com>
On Mon, May 25, 2026 at 09:40:16PM -0700, Rosen Penev wrote:
> Use u32-typed BIT and GENMASK helpers for PCIe interrupt register
> masks. This keeps inverted masks in the same width as the registers
> and avoids truncation warnings on 64-bit compile-test builds.
>
> Fixes this and similar warnings:
>
> drivers/pci/controller/pci-mvebu.c:316:21: error: implicit conversion from
> 'unsigned long' to 'u32' (aka 'unsigned int') changes value from
> 18446744069414584320 to 0 [-Werror,-Wconstant-conversion]
> 316 | mvebu_writel(port, ~PCIE_INT_ALL_MASK, PCIE_INT_UNMASK_OFF);
>
> Assisted-by: Codex:GPT-5.5
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> ---
> v2: remove sys_to_pcie change
> drivers/pci/controller/pci-mvebu.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pci/controller/pci-mvebu.c b/drivers/pci/controller/pci-mvebu.c
> index e568528bad85..f5a3f7370552 100644
> --- a/drivers/pci/controller/pci-mvebu.c
> +++ b/drivers/pci/controller/pci-mvebu.c
> @@ -57,9 +57,9 @@
> #define PCIE_CONF_DATA_OFF 0x18fc
> #define PCIE_INT_CAUSE_OFF 0x1900
> #define PCIE_INT_UNMASK_OFF 0x1910
> -#define PCIE_INT_INTX(i) BIT(24+i)
> -#define PCIE_INT_PM_PME BIT(28)
> -#define PCIE_INT_ALL_MASK GENMASK(31, 0)
> +#define PCIE_INT_INTX(i) BIT_U32(24 + (i))
> +#define PCIE_INT_PM_PME BIT_U32(28)
> +#define PCIE_INT_ALL_MASK GENMASK_U32(31, 0)
This looks like something that could be an issue in dozens of drivers.
Is it? If so, I'd prefer to fix them all at once in a single patch
instead of a slow trickle.
^ permalink raw reply
* Re: [PATCH 2/4] nvmem: add mt6323 PMIC EFUSE driver
From: Andy Shevchenko @ 2026-06-11 16:13 UTC (permalink / raw)
To: rva333
Cc: Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Srinivas Kandagatla, Andy Shevchenko,
Jonathan Cameron, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, Ben Grisdale
In-Reply-To: <20260611-mt6323-nvmem-v1-2-b5e1b9ce51f2@protonmail.com>
On Thu, Jun 11, 2026 at 1:21 PM Roman Vivchar via B4 Relay
<devnull+rva333.protonmail.com@kernel.org> wrote:
>
> Add support for the EFUSE controller found in the Mediatek MT6323 PMIC.
> The MT6323 EFUSE stores 24 bytes of hardware-related data, such as
> thermal sensor calibration values.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
...
> +static int mt6323_efuse_read(void *context, unsigned int offset, void *val,
> + size_t bytes)
> +{
> + struct regmap *map = context;
> + u32 tmp;
> + u16 *buf = val;
> + int ret;
Perhaps reversed xmas tree order? And it's actually better to see
assignments first.
> + /*
> + * A manual loop using regmap_read is required because PWRAP is not
> + * a continuous MMIO space, but rather a FSM that doesn't implement the
> + * necessary read callback for the regmap_read_raw and regmap_read_bulk
> + * functions.
> + */
> + for (size_t i = 0; i < bytes; i += sizeof(*buf)) {
> + ret = regmap_read(map, MT6323_EFUSE_DOUT_BASE + offset + i, &tmp);
> + if (ret)
> + return ret;
> +
> + *buf++ = tmp;
> + }
> +
> + return 0;
> +}
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] net: ethernet: mediatek: fix refcount leak in mtk_probe()
From: Simon Horman @ 2026-06-11 16:11 UTC (permalink / raw)
To: Wentao Liang
Cc: nbd, lorenzo, andrew+netdev, davem, edumazet, kuba, pabeni,
matthias.bgg, angelogioacchino.delregno, netdev, linux-kernel,
linux-arm-kernel, linux-mediatek, stable
In-Reply-To: <20260609081300.208168-1-vulab@iscas.ac.cn>
On Tue, Jun 09, 2026 at 08:13:00AM +0000, Wentao Liang wrote:
> If mtk_sgmii_init() fails after successfully creating some PCS
> instances, it returns an error without cleaning up the partially
> created ones. mtk_pcs_lynxi_create() increments the fwnode
> refcount for each PCS it creates, but this refcount is never
> released because mtk_probe() uses a plain "return err" instead of
> a goto to the err_destroy_sgmii label. This leaks both the PCS
> devices and their fwnode references.
>
> Fix the leak by jumping to the existing err_destroy_sgmii path
> which calls mtk_sgmii_destroy() to safely release all allocated
> resources.
>
> Cc: stable@vger.kernel.org
> Fixes: 9ffee4a8276c ("net: ethernet: mediatek: Extend SGMII related functions")
> Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
I think that a better approach would be, on error, for mtk_sgmii_init()
to release any resources it has allocated before returning.
Also, I'm not convinced this is stable material
as I'm not sure it's bothering anyone.
...
^ permalink raw reply
* Re: iio: adc: KASAN wild-memory-access in complete() on early IRQ
From: Maxwell Doose @ 2026-06-11 16:07 UTC (permalink / raw)
To: Jaeyoung Chung
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Vladimir Zapolskiy, Piotr Wojtaszczyk, linux-iio,
linux-arm-kernel, linux-kernel, Sangyun Kim, Kyungwook Boo
In-Reply-To: <20260610115700.774689-1-jjy600901@snu.ac.kr>
On Wed, Jun 10, 2026 at 7:04 AM Jaeyoung Chung <jjy600901@snu.ac.kr> wrote:
>
> Hi,
>
> lpc32xx_adc_probe() in drivers/iio/adc/lpc32xx_adc.c and
> spear_adc_probe() in drivers/iio/adc/spear_adc.c register their
> interrupt handler with devm_request_irq() before they initialize
> st->completion with init_completion(). If an interrupt arrives after
> devm_request_irq() and before init_completion(), the handler calls
> complete() on an uninitialized completion, causing a kernel panic.
>
> The probe path, in lpc32xx_adc_probe():
>
> iodev = devm_iio_device_alloc(&pdev->dev, sizeof(*st)); /* st kzalloc-zeroed */
> ...
> retval = devm_request_irq(&pdev->dev, irq, lpc32xx_adc_isr, 0,
> LPC32XXAD_NAME, st); /* register handler */
> ...
> init_completion(&st->completion); /* initialize completion */
>
> spear_adc_probe() has the same ordering: devm_request_irq() for
> spear_adc_isr() before init_completion(&st->completion).
>
> Both interrupt handlers, lpc32xx_adc_isr() and spear_adc_isr(), call
> complete():
>
> complete(&st->completion);
>
> If the device raises an interrupt before init_completion() runs,
> complete() acquires the uninitialized wait.lock and walks the zeroed
> task_list in swake_up_locked(). The zeroed task_list makes list_empty()
> return false, so swake_up_locked() dereferences a NULL list entry,
> triggering a KASAN wild-memory-access.
>
> Suggested fix: move init_completion(&st->completion) above
> devm_request_irq(), so the completion is valid before the handler can run.
>
> Reported-by: Sangyun Kim <sangyun.kim@snu.ac.kr>
> Reported-by: Kyungwook Boo <bookyungwook@gmail.com>
>
Thanks for reporting this; I can start working on a fix shortly
(assuming nobody else is already working on it).
--
best regards,
max
^ permalink raw reply
* Re: [PATCH v7 3/6] firmware: smccc: Move RSI definitions to include/linux
From: Suzuki K Poulose @ 2026-06-11 16:04 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, Andre Przywara
In-Reply-To: <20260611130429.295516-4-aneesh.kumar@kernel.org>
On 11/06/2026 14:04, Aneesh Kumar K.V (Arm) wrote:
> The RSI SMCCC function IDs describe a firmware ABI and are not arm64
> architecture specific definitions. Follow-up changes need to use them from
> non-arch code, including drivers/firmware/smccc and the Arm CCA guest
> driver.
>
> Move the RSI SMCCC definitions from arch/arm64/include/asm/ to
> include/linux/ so they can be shared with the driver code. This also
> keeps the firmware interface outside architecture code, as requested [1].
Please could we also mention about moving the "wrappers" only used by
drivers accordingly ?
>
> [1] https://lore.kernel.org/all/agsNO9cc7H-b0H8L@willie-the-truck
>
> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
> ---
> arch/arm64/include/asm/rsi_cmds.h | 74 +---------------
> .../virt/coco/arm-cca-guest/arm-cca-guest.c | 2 +
> drivers/virt/coco/arm-cca-guest/rsi.h | 84 +++++++++++++++++++
> .../linux/arm-smccc-rsi.h | 6 +-
> 4 files changed, 90 insertions(+), 76 deletions(-)
> create mode 100644 drivers/virt/coco/arm-cca-guest/rsi.h
> rename arch/arm64/include/asm/rsi_smc.h => include/linux/arm-smccc-rsi.h (98%)
>
> diff --git a/arch/arm64/include/asm/rsi_cmds.h b/arch/arm64/include/asm/rsi_cmds.h
> index 2c8763876dfb..633123a4e5d5 100644
> --- a/arch/arm64/include/asm/rsi_cmds.h
> +++ b/arch/arm64/include/asm/rsi_cmds.h
> @@ -8,10 +8,9 @@
>
> #include <linux/arm-smccc.h>
> #include <linux/string.h>
> +#include <linux/arm-smccc-rsi.h>
super minor nit: Please keep them in the alphabetical order.
With that:
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Suzuki
> #include <asm/memory.h>
>
> -#include <asm/rsi_smc.h>
> -
> #define RSI_GRANULE_SHIFT 12
> #define RSI_GRANULE_SIZE (_AC(1, UL) << RSI_GRANULE_SHIFT)
>
> @@ -88,75 +87,4 @@ static inline long rsi_set_addr_range_state(phys_addr_t start,
> return res.a0;
> }
>
> -/**
> - * rsi_attestation_token_init - Initialise the operation to retrieve an
> - * attestation token.
> - *
> - * @challenge: The challenge data to be used in the attestation token
> - * generation.
> - * @size: Size of the challenge data in bytes.
> - *
> - * Initialises the attestation token generation and returns an upper bound
> - * on the attestation token size that can be used to allocate an adequate
> - * buffer. The caller is expected to subsequently call
> - * rsi_attestation_token_continue() to retrieve the attestation token data on
> - * the same CPU.
> - *
> - * Returns:
> - * On success, returns the upper limit of the attestation report size.
> - * Otherwise, -EINVAL
> - */
> -static inline long
> -rsi_attestation_token_init(const u8 *challenge, unsigned long size)
> -{
> - struct arm_smccc_1_2_regs regs = { 0 };
> -
> - /* The challenge must be at least 32bytes and at most 64bytes */
> - if (!challenge || size < 32 || size > 64)
> - return -EINVAL;
> -
> - regs.a0 = SMC_RSI_ATTESTATION_TOKEN_INIT;
> - memcpy(®s.a1, challenge, size);
> - arm_smccc_1_2_smc(®s, ®s);
> -
> - if (regs.a0 == RSI_SUCCESS)
> - return regs.a1;
> -
> - return -EINVAL;
> -}
> -
> -/**
> - * rsi_attestation_token_continue - Continue the operation to retrieve an
> - * attestation token.
> - *
> - * @granule: {I}PA of the Granule to which the token will be written.
> - * @offset: Offset within Granule to start of buffer in bytes.
> - * @size: The size of the buffer.
> - * @len: The number of bytes written to the buffer.
> - *
> - * Retrieves up to a RSI_GRANULE_SIZE worth of token data per call. The caller
> - * is expected to call rsi_attestation_token_init() before calling this
> - * function to retrieve the attestation token.
> - *
> - * Return:
> - * * %RSI_SUCCESS - Attestation token retrieved successfully.
> - * * %RSI_INCOMPLETE - Token generation is not complete.
> - * * %RSI_ERROR_INPUT - A parameter was not valid.
> - * * %RSI_ERROR_STATE - Attestation not in progress.
> - */
> -static inline unsigned long rsi_attestation_token_continue(phys_addr_t granule,
> - unsigned long offset,
> - unsigned long size,
> - unsigned long *len)
> -{
> - struct arm_smccc_res res;
> -
> - arm_smccc_1_1_invoke(SMC_RSI_ATTESTATION_TOKEN_CONTINUE,
> - granule, offset, size, 0, &res);
> -
> - if (len)
> - *len = res.a1;
> - return res.a0;
> -}
> -
> #endif /* __ASM_RSI_CMDS_H */
> diff --git a/drivers/virt/coco/arm-cca-guest/arm-cca-guest.c b/drivers/virt/coco/arm-cca-guest/arm-cca-guest.c
> index 66d00b6ceb78..8b6854e7a188 100644
> --- a/drivers/virt/coco/arm-cca-guest/arm-cca-guest.c
> +++ b/drivers/virt/coco/arm-cca-guest/arm-cca-guest.c
> @@ -14,6 +14,8 @@
>
> #include <asm/rsi.h>
>
> +#include "rsi.h"
> +
> /**
> * struct arm_cca_token_info - a descriptor for the token buffer.
> * @challenge: Pointer to the challenge data
> diff --git a/drivers/virt/coco/arm-cca-guest/rsi.h b/drivers/virt/coco/arm-cca-guest/rsi.h
> new file mode 100644
> index 000000000000..f7303f4bce17
> --- /dev/null
> +++ b/drivers/virt/coco/arm-cca-guest/rsi.h
> @@ -0,0 +1,84 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright (C) 2026 ARM Ltd.
> + */
> +
> +#ifndef _VIRT_COCO_RSI_H_
> +#define _VIRT_COCO_RSI_H_
> +
> +#include <linux/arm-smccc-rsi.h>
> +
> +/**
> + * rsi_attestation_token_init - Initialise the operation to retrieve an
> + * attestation token.
> + *
> + * @challenge: The challenge data to be used in the attestation token
> + * generation.
> + * @size: Size of the challenge data in bytes.
> + *
> + * Initialises the attestation token generation and returns an upper bound
> + * on the attestation token size that can be used to allocate an adequate
> + * buffer. The caller is expected to subsequently call
> + * rsi_attestation_token_continue() to retrieve the attestation token data on
> + * the same CPU.
> + *
> + * Returns:
> + * On success, returns the upper limit of the attestation report size.
> + * Otherwise, -EINVAL
> + */
> +static inline long
> +rsi_attestation_token_init(const u8 *challenge, unsigned long size)
> +{
> + struct arm_smccc_1_2_regs regs = { 0 };
> +
> + /* The challenge must be at least 32bytes and at most 64bytes */
> + if (!challenge || size < 32 || size > 64)
> + return -EINVAL;
> +
> + regs.a0 = SMC_RSI_ATTESTATION_TOKEN_INIT;
> + memcpy(®s.a1, challenge, size);
> + arm_smccc_1_2_smc(®s, ®s);
> +
> + if (regs.a0 == RSI_SUCCESS)
> + return regs.a1;
> +
> + return -EINVAL;
> +}
> +
> +/**
> + * rsi_attestation_token_continue - Continue the operation to retrieve an
> + * attestation token.
> + *
> + * @granule: {I}PA of the Granule to which the token will be written.
> + * @offset: Offset within Granule to start of buffer in bytes.
> + * @size: The size of the buffer.
> + * @len: The number of bytes written to the buffer.
> + *
> + * Retrieves up to a RSI_GRANULE_SIZE worth of token data per call. The caller
> + * is expected to call rsi_attestation_token_init() before calling this
> + * function to retrieve the attestation token.
> + *
> + * Return:
> + * * %RSI_SUCCESS - Attestation token retrieved successfully.
> + * * %RSI_INCOMPLETE - Token generation is not complete.
> + * * %RSI_ERROR_INPUT - A parameter was not valid.
> + * * %RSI_ERROR_STATE - Attestation not in progress.
> + */
> +static inline unsigned long rsi_attestation_token_continue(phys_addr_t granule,
> + unsigned long offset,
> + unsigned long size,
> + unsigned long *len)
> +{
> + struct arm_smccc_res res;
> +
> + arm_smccc_1_1_invoke(SMC_RSI_ATTESTATION_TOKEN_CONTINUE,
> + granule, offset, size, 0, &res);
> +
> + if (len)
> + *len = res.a1;
> + return res.a0;
> +}
> +
> +
> +
> +#endif
> diff --git a/arch/arm64/include/asm/rsi_smc.h b/include/linux/arm-smccc-rsi.h
> similarity index 98%
> rename from arch/arm64/include/asm/rsi_smc.h
> rename to include/linux/arm-smccc-rsi.h
> index e19253f96c94..fddb77986f70 100644
> --- a/arch/arm64/include/asm/rsi_smc.h
> +++ b/include/linux/arm-smccc-rsi.h
> @@ -3,8 +3,8 @@
> * Copyright (C) 2023 ARM Ltd.
> */
>
> -#ifndef __ASM_RSI_SMC_H_
> -#define __ASM_RSI_SMC_H_
> +#ifndef __LINUX_ARM_SMCCC_RSI_H_
> +#define __LINUX_ARM_SMCCC_RSI_H_
>
> #include <linux/arm-smccc.h>
>
> @@ -190,4 +190,4 @@ struct realm_config {
> */
> #define SMC_RSI_HOST_CALL SMC_RSI_FID(0x199)
>
> -#endif /* __ASM_RSI_SMC_H_ */
> +#endif /* __LINUX_ARM_SMCCC_RSI_H_ */
^ permalink raw reply
* Re: [PATCH v3] arm64: errata: Workaround NVIDIA Olympus device store/load ordering erratum
From: Shanker Donthineni @ 2026-06-11 16:00 UTC (permalink / raw)
To: Vladimir Murzin, Will Deacon
Cc: Catalin Marinas, Jason Gunthorpe, linux-arm-kernel, Mark Rutland,
linux-kernel, linux-doc, Vikram Sethi, Jason Sequeira
In-Reply-To: <aee00047-81b9-4562-be47-500b2643f7f6@arm.com>
Hi Vladimir,
On 6/11/2026 10:08 AM, Vladimir Murzin wrote:
> External email: Use caution opening links or attachments
>
>
> Hi,
>
> On 6/11/26 14:34, Will Deacon wrote:
>> On Wed, Jun 10, 2026 at 11:48:22AM -0500, Shanker Donthineni wrote:
>>> On systems with NVIDIA Olympus cores, a Device-nGnR* load can be
>>> observed by a peripheral before an older, non-overlapping Device-nGnR*
>>> store to the same peripheral. This breaks the program-order guarantee
>>> that software expects for Device-nGnR* accesses and can leave a
>>> peripheral in an incorrect state, as a load is observed before an
>>> earlier store takes effect.
>>>
>>> The erratum can occur only when all of the following apply:
>>>
>>> - A PE executes a Device-nGnR* store followed by a younger
>>> Device-nGnR* load.
>>> - The store is not a store-release.
>>> - The accesses target the same peripheral and do not overlap in bytes.
>>> - There is at most one intervening Device-nGnR* store in program
>>> order, and there are no intervening Device-nGnR* loads.
>>> - There is no DSB, and no DMB that orders loads, between the store and
>>> the load.
>>> - Specific micro-architectural and timing conditions occur.
>>>
>>> Promote the raw MMIO store helpers (__raw_writeb/w/l/q) from plain str*
>>> to stlr* (Store-Release), which removes the "store is not a
>>> store-release" condition for every device write the kernel issues.
>>> Because writel() and writel_relaxed() are both built on __raw_writel()
>>> in asm-generic/io.h, patching the raw variants covers both the
>>> non-relaxed and relaxed APIs without touching the higher layers. Note
>>> that writel()'s own barrier sits before the store, so it does not order
>>> the store against a subsequent readl(); the store-release promotion is
>>> what provides that ordering.
>>>
>>> Like ARM64_ERRATUM_832075 on the load side, the change is gated on a new
>>> ARM64_WORKAROUND_DEVICE_STORE_RELEASE capability and only activated on
>>> parts that match MIDR_NVIDIA_OLYMPUS, so unaffected CPUs continue to use
>>> the plain str* sequence.
>>>
>>> Note: stlr* only supports base-register addressing, so affected CPUs use
>>> a base-register stlr* path. Unaffected CPUs keep the original
>>> offset-addressed str* sequence introduced by commit d044d6ba6f02
>>> ("arm64: io: permit offset addressing").
>>>
>>> The __const_memcpy_toio_aligned32() and __const_memcpy_toio_aligned64()
>>> helpers are left unchanged. These helpers are intended for
>>> write-combining mappings, which are Normal-NC on arm64. Replacing their
>>> contiguous str* groups would defeat the write-combining behavior used to
>>> improve store performance.
>>>
>>> Co-developed-by: Vikram Sethi <vsethi@nvidia.com>
>>> Signed-off-by: Vikram Sethi <vsethi@nvidia.com>
>>> Signed-off-by: Shanker Donthineni <sdonthineni@nvidia.com>
>>> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
>>> ---
>>> Changes since v2:
>>> - Reworked the raw MMIO write helpers so unaffected CPUs keep the
>>> existing offset-addressed STR sequence, while affected CPUs use the
>>> base-register STLR path.
>>> - Updated the commit message to match the code changes.
>>> - Rebased on top of the arm64 for-next/errata branch:
>>> https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=for-next/errata
>>>
>>> Changes since v1:
>>> - Updated the commit message based on feedback from Vladimir Murzin.
>>>
>>> Documentation/arch/arm64/silicon-errata.rst | 2 ++
>>> arch/arm64/Kconfig | 23 ++++++++++++++++
>>> arch/arm64/include/asm/io.h | 30 +++++++++++++++++++++
>>> arch/arm64/kernel/cpu_errata.c | 8 ++++++
>>> arch/arm64/tools/cpucaps | 1 +
>>> 5 files changed, 64 insertions(+)
>>>
>>> diff --git a/Documentation/arch/arm64/silicon-errata.rst b/Documentation/arch/arm64/silicon-errata.rst
>>> index ad09bbb10da80..fc45125dc2f80 100644
>>> --- a/Documentation/arch/arm64/silicon-errata.rst
>>> +++ b/Documentation/arch/arm64/silicon-errata.rst
>>> @@ -298,6 +298,8 @@ stable kernels.
>>> +----------------+-----------------+-----------------+-----------------------------+
>>> | NVIDIA | Carmel Core | N/A | NVIDIA_CARMEL_CNP_ERRATUM |
>>> +----------------+-----------------+-----------------+-----------------------------+
>>> +| NVIDIA | Olympus core | T410-OLY-1027 | NVIDIA_OLYMPUS_1027_ERRATUM |
>>> ++----------------+-----------------+-----------------+-----------------------------+
>>> | NVIDIA | Olympus core | T410-OLY-1029 | ARM64_ERRATUM_4118414 |
>>> +----------------+-----------------+-----------------+-----------------------------+
>>> | NVIDIA | T241 GICv3/4.x | T241-FABRIC-4 | N/A |
>>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>>> index c65cef81be86a..d633eb70de1ac 100644
>>> --- a/arch/arm64/Kconfig
>>> +++ b/arch/arm64/Kconfig
>>> @@ -564,6 +564,29 @@ config ARM64_ERRATUM_832075
>>>
>>> If unsure, say Y.
>>>
>>> +config NVIDIA_OLYMPUS_1027_ERRATUM
>>> + bool "NVIDIA Olympus: device store/load ordering erratum"
>>> + default y
>>> + help
>>> + This option adds an alternative code sequence to work around an
>>> + NVIDIA Olympus core erratum where a Device-nGnR* store can be
>>> + observed by a peripheral after a younger Device-nGnR* load to the
>>> + same peripheral. This breaks the program order that drivers rely
>>> + on for MMIO and can leave a device in an incorrect state.
>>> +
>>> + The workaround promotes the raw MMIO store helpers
>>> + (__raw_writeb/w/l/q) to Store-Release (STLR), which restores the
>>> + required ordering. Because writel() and writel_relaxed() are built
>>> + on __raw_writel(), both are covered without changes to the higher
>>> + layers.
>>> +
>>> + The fix is applied through the alternatives framework, so enabling
>>> + this option does not by itself activate the workaround: it is
>>> + patched in only when an affected CPU is detected, and is a no-op on
>>> + unaffected CPUs.
>>> +
>>> + If unsure, say Y.
>>> +
>>> config ARM64_ERRATUM_834220
>>> bool "Cortex-A57: 834220: Stage 2 translation fault might be incorrectly reported in presence of a Stage 1 fault (rare)"
>>> depends on KVM
>>> diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
>>> index 8cbd1e96fd50b..801223e754c90 100644
>>> --- a/arch/arm64/include/asm/io.h
>>> +++ b/arch/arm64/include/asm/io.h
>>> @@ -22,10 +22,22 @@
>>> /*
>>> * Generic IO read/write. These perform native-endian accesses.
>>> */
>>> +static __always_inline bool arm64_needs_device_store_release(void)
>>> +{
>>> + return alternative_has_cap_unlikely(
>>> + ARM64_WORKAROUND_DEVICE_STORE_RELEASE);
>>> +}
>>> +
>>> #define __raw_writeb __raw_writeb
>>> static __always_inline void __raw_writeb(u8 val, volatile void __iomem *addr)
>>> {
>>> volatile u8 __iomem *ptr = addr;
>>> +
>>> + if (arm64_needs_device_store_release()) {
>>> + asm volatile("stlrb %w0, [%1]" : : "rZ" (val), "r" (addr));
>>> + return;
>>> + }
>>> +
>>> asm volatile("strb %w0, %1" : : "rZ" (val), "Qo" (*ptr));
>>> }
>> Use an 'else' clause instead of the early return? (similarly for the other
>> changes).
> Perhaps I'm missing something, but it is not clear to me why all that
> complexity is required.
>
> IIUC, benefits coming with d044d6ba6f02 ("arm64: io: permit offset
> addressing") are from better code generation, so we:
> - save code
> - open opportunity for write-combining
>
> d044d6ba6f02 ("arm64: io: permit offset addressing") comes with simple
> benchmark to measure effect of code generation:
>
> | void writeq_zero_8_times(void *ptr)
> | {
> | writeq_relaxed(0, ptr + 8 * 0);
> | writeq_relaxed(0, ptr + 8 * 1);
> | writeq_relaxed(0, ptr + 8 * 2);
> | writeq_relaxed(0, ptr + 8 * 3);
> | writeq_relaxed(0, ptr + 8 * 4);
> | writeq_relaxed(0, ptr + 8 * 5);
> | writeq_relaxed(0, ptr + 8 * 6);
> | writeq_relaxed(0, ptr + 8 * 7);
> | }
>
> which compiles to
>
> | <writeq_zero_8_times>:
> | str xzr, [x0]
> | str xzr, [x0, #8]
> | str xzr, [x0, #16]
> | str xzr, [x0, #24]
> | str xzr, [x0, #32]
> | str xzr, [x0, #40]
> | str xzr, [x0, #48]
> | str xzr, [x0, #56]
>
>
> v1/v2 compiles to
>
> | <writeq_zero_8_times>:
> | str xzr, [x0]
> | add x1, x0, #0x8
> | str xzr, [x1]
> | add x1, x0, #0x10
> | str xzr, [x1]
> | add x1, x0, #0x18
> | str xzr, [x1]
> | add x1, x0, #0x20
> | str xzr, [x1]
> | add x1, x0, #0x28
> | str xzr, [x1]
> | add x1, x0, #0x30
> | str xzr, [x1]
> | add x0, x0, #0x38
> | str xzr, [x0]
>
> were alternatives are swapping str with stlr. In other words, we are
> rolling back to the pre-d044d6ba6f02 implementation.
>
> v3 compiles to:
>
> | <writeq_zero_8_times>:
> | nop
> | str xzr, [x0]
> | add x1, x0, #0x8
> | nop
> | str xzr, [x1]
> | add x1, x0, #0x10
> | nop
> | str xzr, [x1]
> | add x1, x0, #0x18
> | nop
> | str xzr, [x1]
> | add x1, x0, #0x20
> | nop
> | str xzr, [x1]
> | add x1, x0, #0x28
> | nop
> | str xzr, [x1]
> | add x1, x0, #0x30
> | nop
> | str xzr, [x1]
> | add x0, x0, #0x38
> | nop
> | str xzr, [x0]
> | ret
>
> where static branch swapping nop with branch to stlr and back to add.
>
> So it looks to me that we're losing an opportunity for write
> combining, but in terms of code size, v1/v2 seems to be the lesser of
> two evils.
Thanks, that makes sense.
My intent with the v3 change was to keep the offset-addressed STR sequence on
unaffected CPUs and use the base-register STLR sequence only on affected CPUs.
However, as you point out, because STLR only supports base-register addressing,
the affected path still forces the address to be materialized in a register, and
the alternative_has_cap_unlikely() check adds another instruction at each write
site. So the generated code no longer preserves the benefit from d044d6ba6f02 in
practice.
Given that, I agree the extra complexity is not justified. I’ll simplify the raw
MMIO write helpers back to the direct ALTERNATIVE() form from v1/v2, where both
the STR and STLR paths use base-register addressing. That is still a regression
from the offset-addressed STR sequence on unaffected CPUs, but it avoids the
additional static-branch/nop overhead and is the smaller of the two options.
-Shanker
^ permalink raw reply
* Re: [PATCH v2 05/16] usb: hub: Associate port@ fwnode with USB port device
From: Heikki Krogerus @ 2026-06-11 15:48 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Andy Shevchenko, Greg Kroah-Hartman, Daniel Scally, Sakari Ailus,
Rafael J. Wysocki, Danilo Krummrich, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Alan Stern, linux-acpi, driver-core,
linux-pm, linux-usb, devicetree, linux-mediatek, linux-arm-kernel,
linux-kernel, Manivannan Sadhasivam, Chen-Yu Tsai
In-Reply-To: <CAMRc=MdRN7YitmMX8PknbzLh+MdsWm+dDg0MLtCVYOorqNobTw@mail.gmail.com>
On Thu, Jun 11, 2026 at 11:35:13AM +0200, Bartosz Golaszewski wrote:
> On Thu, Jun 11, 2026 at 10:37 AM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> >
> > On Thu, Jun 11, 2026 at 04:20:58AM -0400, Bartosz Golaszewski wrote:
> > > On Wed, 10 Jun 2026 16:16:12 +0200, Andy Shevchenko
> > > <andriy.shevchenko@linux.intel.com> said:
> > > > On Wed, Jun 10, 2026 at 04:40:39PM +0800, Chen-Yu Tsai wrote:
> > > >> When a USB hub port is connected to a connector in a firmware node
> > > >> graph, the port itself has a node in the graph.
> > > >>
> > > >> Associate the port's firmware node with the USB port's device,
> > > >> usb_port::dev. This is used in later changes for the M.2 slot power
> > > >> sequencing provider to match against the requesting port.
> > > >
> > > > Okay, would this affect ACPI-based systems? if so, how?
> > > > Can you elaborate on that, please?
> > >
> > > Is it possible that there's an ACPI device node associated with the port like
> > > on some DT systems? I don't think so and there should be no impact IMO but I
> > > also don't know enough about ACPI.
There are device nodes for the USB ports in ACPI, and I think they get
always assigned in drivers/usb/core/usb-acpi.c.
> > The API is agnostic. There is a possibility to have software nodes associated
> > with the port. I think the best is to be sure that ACPI-aware people who are
> > experts in USB will check this (Heikki?).
I can't say what's the impact from this patch - I'm not an expert with
this side of USB. Is there a danger that we end up overwriting the
ACPI node for the port, or something else?
> Even if there is a software node - it shouldn't really matter. It will
> just be assigned to the port device.
thanks,
--
heikki
^ permalink raw reply
* Re: [PATCH v7 2/2] ARM: dts: aspeed: ventura2: Add Meta ventura2 BMC
From: Andrew Lunn @ 2026-06-11 15:57 UTC (permalink / raw)
To: Kyle Hsieh
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel
In-Reply-To: <20260611-ventura2_initial_dts-v7-2-a61d8902bc5f@gmail.com>
> + /* Marvell 88E6393X EEPROM */
> + eeprom@50 {
> + compatible = "atmel,24c64";
> + reg = <0x50>;
> + };
How is this on both a host I2C bus, and the switches I2C bus? Are you
using multi-master? Is there a GPIO to hold the switch in reset while
the host access the EEPROM?
Andrew
^ permalink raw reply
* Re: [PATCH net-next v4 0/3] Add standard stats for HSR/PRP
From: Andrew Lunn @ 2026-06-11 15:50 UTC (permalink / raw)
To: MD Danish Anwar
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Jonathan Corbet, Shuah Khan, Roger Quadros,
Andrew Lunn, Meghana Malladi, Jacob Keller, David Carlier,
Vadim Fedorenko, Kevin Hao, Markus Elfring, Hangbin Liu,
Fernando Fernandez Mancera, Jan Vaclav, netdev, linux-doc,
linux-kernel, linux-arm-kernel, Felix Maurer, Luka Gejak
In-Reply-To: <20260611095035.852370-1-danishanwar@ti.com>
On Thu, Jun 11, 2026 at 03:20:32PM +0530, MD Danish Anwar wrote:
> Add standard stats for HSR / PRP. This series was initially adding HSR/PRP
> related stats for ICSSG driver. Based on maintainers' comments on v2 I am
> now adding support to dump standard stats for HSR/PRP.
>
> The drivers which support offload can populate these standard stats.
>
> This series only implements offloaded stats. For software-only interfaces
> Felix Maurer had said he will do it later [1]
That is ideally the wrong way around. Offloading it used to accelerate
what Linux can already do in software. Statistics should be part of
this, you first define software statistics, and then get the hardware
to report those.
So please get the software statistics merged first.
Andrew
^ permalink raw reply
* Re: [PATCH 2/2] arm64: tlbflush: Reset active_cpu on ASID rollover
From: Catalin Marinas @ 2026-06-11 15:37 UTC (permalink / raw)
To: sk
Cc: linux-arm-kernel, linux-kernel, Will Deacon, Ryan Roberts,
Andrew Morton, David Hildenbrand, Anshuman Khandual,
Mike Rapoport, Dev Jain, Kevin Brodsky, Marc Zyngier,
Oliver Upton, cl, Sayali Kulkarni
In-Reply-To: <20260609213615.2788698-3-sk@gentwo.org>
On Tue, Jun 09, 2026 at 02:34:33PM -0700, sk@gentwo.org wrote:
> From: Sayali Kulkarni <sskulkarni@amperecomputing.com>
>
> Once active_cpu flips to ACTIVE_CPU_MULTIPLE, it never resets, even if
> the process settles back to one CPU. Reset it to ACTIVE_CPU_NONE when
> a new ASID is assigned after rollover, since flush_context() already
> issued a global TLB flush at that point meaning no stale TLB entries
> exist on any CPU.
>
> This gives processes a fresh chance at the local-only flush fast path
> after each ASID generation rollover.
flush_context() does not invalidate any TLBs, just marks the in a bitmap
which CPUs need to flush, locally, on the next context switch.
Check Sashiko's comments, it has some good points (you can ignore the
comments on the first patch as we no longer rely on DVM for SVA.
https://sashiko.dev/#/patchset/20260609213615.2788698-1-sk@gentwo.org
> Signed-off-by: Sayali Kulkarni <sskulkarni@amperecomputing.com>
> ---
> arch/arm64/mm/context.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/mm/context.c b/arch/arm64/mm/context.c
> index f34ed78393e0..0c92cc8fb4cd 100644
> --- a/arch/arm64/mm/context.c
> +++ b/arch/arm64/mm/context.c
> @@ -250,6 +250,7 @@ void check_and_switch_context(struct mm_struct *mm)
> if (!asid_gen_match(asid)) {
> asid = new_context(mm);
> atomic64_set(&mm->context.id, asid);
> + WRITE_ONCE(mm->context.active_cpu, ACTIVE_CPU_NONE);
> }
This breaks the case where you have another thread of the current
process running on a different CPU. new_context(mm) will reuse the
current ASID, just bump the generation, so setting active_cpu to
ACTIVE_CPU_NONE is incorrect.
A better place for this would be in new_context() after the "set_asid"
label.
> if (cpumask_test_and_clear_cpu(cpu, &tlb_flush_pending))
> @@ -321,6 +322,7 @@ unsigned long arm64_mm_context_get(struct mm_struct *mm)
> */
> asid = new_context(mm);
> atomic64_set(&mm->context.id, asid);
> + WRITE_ONCE(mm->context.active_cpu, ACTIVE_CPU_NONE);
> }
And it would cover this path as well (not that this function is used
currently).
--
Catalin
^ permalink raw reply
* Re: [PATCH] phy: rockchip: inno-usb2: Add missing clkout_ctl_phy kerneldoc
From: Vinod Koul @ 2026-06-11 15:35 UTC (permalink / raw)
To: Heiko Stuebner
Cc: neil.armstrong, jonas, linux-phy, linux-arm-kernel,
linux-rockchip, linux-kernel, kernel test robot
In-Reply-To: <20260520102859.1357411-1-heiko@sntech.de>
On Wed, 20 May 2026 12:28:59 +0200, Heiko Stuebner wrote:
> Add the missing documentation for the newly added clkout_ctl_phy field.
>
>
Applied, thanks!
[1/1] phy: rockchip: inno-usb2: Add missing clkout_ctl_phy kerneldoc
commit: 2ace2e949979b82f82f12dd76d7c5a6145246ca3
Best regards,
--
~Vinod
^ permalink raw reply
* Re: [PATCH v2] phy: freescale: phy-fsl-imx8qm-lvds-phy: Fix missing pm_runtime_disable() on probe error path
From: Vinod Koul @ 2026-06-11 15:35 UTC (permalink / raw)
To: Neil Armstrong, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Liu Ying, Felix Gu
Cc: linux-phy, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260605-lvds-v2-1-3ce7539d1104@gmail.com>
On Fri, 05 Jun 2026 19:57:20 +0800, Felix Gu wrote:
> If mixel_lvds_phy_reset() fails in probe after pm_runtime_enable(),
> the function returns directly without calling pm_runtime_disable(),
> leaving runtime PM permanently enabled for the device.
>
> Fix this by using devm_pm_runtime_enable() so that cleanup is
> automatic on any probe failure or driver unbind. This also allows
> removing the manual err label and the .remove callback.
>
> [...]
Applied, thanks!
[1/1] phy: freescale: phy-fsl-imx8qm-lvds-phy: Fix missing pm_runtime_disable() on probe error path
commit: 799e7cf2f0b50b34660b5ffce0f7d8dec376a0d5
Best regards,
--
~Vinod
^ permalink raw reply
* Re: [PATCH] phy: freescale: phy-fsl-imx8qm-lvds-phy: Use synchronous PM runtime put in reset
From: Vinod Koul @ 2026-06-11 15:35 UTC (permalink / raw)
To: Neil Armstrong, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Liu Ying, Felix Gu
Cc: linux-phy, imx, linux-arm-kernel, linux-kernel, sashiko
In-Reply-To: <20260609-lvds-phy-v1-1-6ad790c6d0ea@gmail.com>
On Tue, 09 Jun 2026 22:48:50 +0800, Felix Gu wrote:
> The mixel_lvds_phy_reset() function pairs pm_runtime_resume_and_get()
> with pm_runtime_put(). The asynchronous variant queues a work item
> to handle the idle check and potential suspend, which can be cancelled
> by a subsequent pm_runtime_disable() call if probe fails after the reset.
>
> Switch to pm_runtime_put_sync() to run the idle check and suspend
> synchronously.
>
> [...]
Applied, thanks!
[1/1] phy: freescale: phy-fsl-imx8qm-lvds-phy: Use synchronous PM runtime put in reset
commit: b28ec8ce03d8f9a0f7a9ec84f1ed9b5a6f393791
Best regards,
--
~Vinod
^ permalink raw reply
* Re: [PATCH v7 24/30] drm/vc4: hdmi: Use common TMDS char rate constants
From: Maxime Ripard @ 2026-06-11 15:32 UTC (permalink / raw)
To: Cristian Ciocaltea
Cc: dri-devel, kernel, linux-arm-kernel, linux-kernel, linux-rockchip,
Andrzej Hajda, Andy Yan, Daniel Stone, Dave Stevenson,
David Airlie, Heiko Stübner, Jernej Skrabec, Jonas Karlman,
Laurent Pinchart, Luca Ceresoli, Maarten Lankhorst, Maxime Ripard,
Maíra Canal, Neil Armstrong, Raspberry Pi Kernel Maintenance,
Robert Foss, Sandy Huang, Simona Vetter, Thomas Zimmermann
In-Reply-To: <20260602-dw-hdmi-qp-scramb-v7-24-445eb54ee1ed@collabora.com>
On Tue, 2 Jun 2026 01:44:24 +0300, Cristian Ciocaltea wrote:
> Replace HDMI_14_MAX_TMDS_CLK defined locally with
> HDMI_1_3_TMDS_CHAR_RATE_MAX_HZ provided by linux/hdmi.h. Note this
> incorrectly referenced HDMI 1.4, as the 340 MHz maximum TMDS character
> rate was actually introduced in HDMI 1.3.
>
>
> [ ... ]
Acked-by: Maxime Ripard <mripard@kernel.org>
Thanks!
Maxime
^ permalink raw reply
* Re: [PATCH 1/2] arm64: tlbflush: Don't broadcast if mm was only active on local cpu
From: Catalin Marinas @ 2026-06-11 15:29 UTC (permalink / raw)
To: sk
Cc: linux-arm-kernel, linux-kernel, Will Deacon, Ryan Roberts,
Andrew Morton, David Hildenbrand, Anshuman Khandual,
Mike Rapoport, Dev Jain, Kevin Brodsky, Marc Zyngier,
Oliver Upton, cl, Huang Ying, Linu Cherian
In-Reply-To: <20260609213615.2788698-2-sk@gentwo.org>
On Tue, Jun 09, 2026 at 02:34:32PM -0700, sk@gentwo.org wrote:
> From: Ryan Roberts <ryan.roberts@arm.com>
>
> There are 3 variants of tlb flush that invalidate user mappings:
> flush_tlb_mm(), flush_tlb_page() and __flush_tlb_range(). All of these
> would previously unconditionally broadcast their tlbis to all cpus in
> the inner shareable domain.
>
> But this is a waste of effort if we can prove that the mm for which we
> are flushing the mappings has only ever been active on the local cpu. In
> that case, it is safe to avoid the broadcast and simply invalidate the
> current cpu.
>
> So let's track in mm_context_t::active_cpu either the mm has never been
> active on any cpu, has been active on more than 1 cpu, or has been
> active on precisely 1 cpu - and in that case, which one. We update this
> when switching context, being careful to ensure that it gets updated
> *before* installing the mm's pgtables. On the reader side, we ensure we
> read *after* the previous write(s) to the pgtable(s) that necessitated
> the tlb flush have completed. This guarrantees that if a cpu that is
> doing a tlb flush sees it's own id in active_cpu, then the old pgtable
> entry cannot have been seen by any other cpu and we can flush only the
> local cpu.
>
> Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
> Tested-by: Huang Ying <ying.huang@linux.alibaba.com>
> [linu.cherian@arm.com: Adapted for v7.1 flush tlb API changes]
> Signed-off-by: Linu Cherian <linu.cherian@arm.com>
Nit: if you repost someone's patch, please add your signed-off-by.
--
Catalin
^ permalink raw reply
* Re: [PATCH v7 05/30] drm/display: hdmi_state_helper: Add ctx-aware hotplug helper for SCDC sync
From: Maxime Ripard @ 2026-06-11 15:25 UTC (permalink / raw)
To: Cristian Ciocaltea
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Luca Ceresoli, Sandy Huang,
Heiko Stübner, Andy Yan, Daniel Stone, Dave Stevenson,
Maíra Canal, Raspberry Pi Kernel Maintenance, kernel,
dri-devel, linux-kernel, linux-arm-kernel, linux-rockchip
In-Reply-To: <20260602-dw-hdmi-qp-scramb-v7-5-445eb54ee1ed@collabora.com>
[-- Attachment #1: Type: text/plain, Size: 5580 bytes --]
On Tue, Jun 02, 2026 at 01:44:05AM +0300, Cristian Ciocaltea wrote:
> Introduce drm_atomic_helper_connector_hdmi_hotplug_ctx(), a variant of
> drm_atomic_helper_connector_hdmi_hotplug() that accepts a
> drm_modeset_acquire_ctx.
>
> This enables SCDC status synchronization on hotplug events, which
> requires lock acquisition context for performing the CRTC reset
> triggered by drm_scdc_sync_status().
>
> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
> ---
> drivers/gpu/drm/display/drm_hdmi_state_helper.c | 40 ++++++++++++++++++++-----
> include/drm/display/drm_hdmi_state_helper.h | 4 +++
> 2 files changed, 37 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/display/drm_hdmi_state_helper.c b/drivers/gpu/drm/display/drm_hdmi_state_helper.c
> index a331ebdd65af..a96d81cbf94f 100644
> --- a/drivers/gpu/drm/display/drm_hdmi_state_helper.c
> +++ b/drivers/gpu/drm/display/drm_hdmi_state_helper.c
> @@ -12,6 +12,7 @@
> #include <drm/display/drm_hdmi_cec_helper.h>
> #include <drm/display/drm_hdmi_helper.h>
> #include <drm/display/drm_hdmi_state_helper.h>
> +#include <drm/display/drm_scdc_helper.h>
>
> /**
> * DOC: hdmi helpers
> @@ -1150,18 +1151,20 @@ drm_atomic_helper_connector_hdmi_clear_audio_infoframe(struct drm_connector *con
> }
> EXPORT_SYMBOL(drm_atomic_helper_connector_hdmi_clear_audio_infoframe);
>
> -static void
> +static int
> drm_atomic_helper_connector_hdmi_update(struct drm_connector *connector,
> - enum drm_connector_status status)
> + enum drm_connector_status status,
> + struct drm_modeset_acquire_ctx *ctx)
> {
> const struct drm_edid *drm_edid;
> + int ret = 0;
>
> if (status == connector_status_disconnected) {
> - // TODO: also handle scramber, HDMI sink disconnected.
> + ret = drm_scdc_sync_status(connector, false, ctx);
> drm_connector_hdmi_audio_plugged_notify(connector, false);
> drm_edid_connector_update(connector, NULL);
> drm_connector_cec_phys_addr_invalidate(connector);
> - return;
> + return ret;
> }
>
> if (connector->hdmi.funcs->read_edid)
> @@ -1174,10 +1177,12 @@ drm_atomic_helper_connector_hdmi_update(struct drm_connector *connector,
> drm_edid_free(drm_edid);
>
> if (status == connector_status_connected) {
> - // TODO: also handle scramber, HDMI sink is now connected.
> + ret = drm_scdc_sync_status(connector, true, ctx);
> drm_connector_hdmi_audio_plugged_notify(connector, true);
> drm_connector_cec_phys_addr_set(connector);
> }
> +
> + return ret;
> }
>
> /**
> @@ -1191,10 +1196,31 @@ drm_atomic_helper_connector_hdmi_update(struct drm_connector *connector,
> void drm_atomic_helper_connector_hdmi_hotplug(struct drm_connector *connector,
> enum drm_connector_status status)
> {
> - drm_atomic_helper_connector_hdmi_update(connector, status);
> + drm_atomic_helper_connector_hdmi_update(connector, status, NULL);
> }
> EXPORT_SYMBOL(drm_atomic_helper_connector_hdmi_hotplug);
>
> +/**
> + * drm_atomic_helper_connector_hdmi_hotplug_ctx - Handle the hotplug event for the HDMI connector
> + * @connector: A pointer to the HDMI connector
> + * @status: Connection status
> + * @ctx: Lock acquisition context to be used for resetting CRTC
> + *
> + * This function should be called as a part of the .detect() / .detect_ctx()
> + * callbacks for all status changes.
> + *
> + * Returns:
> + * Zero on success, error code on failure.
> + * If @ctx is set, it might also return -EDEADLK.
> + */
> +int drm_atomic_helper_connector_hdmi_hotplug_ctx(struct drm_connector *connector,
> + enum drm_connector_status status,
> + struct drm_modeset_acquire_ctx *ctx)
> +{
> + return drm_atomic_helper_connector_hdmi_update(connector, status, ctx);
> +}
> +EXPORT_SYMBOL(drm_atomic_helper_connector_hdmi_hotplug_ctx);
> +
> /**
> * drm_atomic_helper_connector_hdmi_force - HDMI Connector implementation of the force callback
> * @connector: A pointer to the HDMI connector
> @@ -1206,6 +1232,6 @@ EXPORT_SYMBOL(drm_atomic_helper_connector_hdmi_hotplug);
> */
> void drm_atomic_helper_connector_hdmi_force(struct drm_connector *connector)
> {
> - drm_atomic_helper_connector_hdmi_update(connector, connector->status);
> + drm_atomic_helper_connector_hdmi_update(connector, connector->status, NULL);
> }
> EXPORT_SYMBOL(drm_atomic_helper_connector_hdmi_force);
> diff --git a/include/drm/display/drm_hdmi_state_helper.h b/include/drm/display/drm_hdmi_state_helper.h
> index 13375bd0f4ae..75fedd4a3ba8 100644
> --- a/include/drm/display/drm_hdmi_state_helper.h
> +++ b/include/drm/display/drm_hdmi_state_helper.h
> @@ -7,6 +7,7 @@ struct drm_atomic_commit;
> struct drm_connector;
> struct drm_connector_state;
> struct drm_display_mode;
> +struct drm_modeset_acquire_ctx;
> struct hdmi_audio_infoframe;
>
> enum drm_connector_status;
> @@ -24,6 +25,9 @@ int drm_atomic_helper_connector_hdmi_update_infoframes(struct drm_connector *con
> struct drm_atomic_commit *state);
> void drm_atomic_helper_connector_hdmi_hotplug(struct drm_connector *connector,
> enum drm_connector_status status);
> +int drm_atomic_helper_connector_hdmi_hotplug_ctx(struct drm_connector *connector,
> + enum drm_connector_status status,
> + struct drm_modeset_acquire_ctx *ctx);
There's not a lot of users, so I'd prefer if we were just changing the
prototype of drm_atomic_helper_connector_hdmi_hotplug()
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v4 1/2] net: airoha: refactor QDMA start/stop into reusable helpers
From: Lorenzo Bianconi @ 2026-06-11 15:21 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: linux-arm-kernel, linux-mediatek, netdev, Madhur Agrawal
In-Reply-To: <20260610-airoha-ethtool-priv_flags-v4-1-60e89cf28fea@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 3392 bytes --]
> Factor out airoha_qdma_start() and airoha_qdma_stop() from
> airoha_dev_open() and airoha_dev_stop(). These helpers will be reused
> by the QDMA hot-migration logic introduced in the next patch to
> dynamically switch GDM3/GDM4 ports between LAN and WAN QDMA blocks.
> Add a DMA engine busy poll in airoha_qdma_stop() to wait for in-flight
> DMA transfers to complete before cleaning up TX queues.
>
> Tested-by: Madhur Agrawal <madhur.agrawal@airoha.com>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> drivers/net/ethernet/airoha/airoha_eth.c | 53 ++++++++++++++++++++++----------
> 1 file changed, 36 insertions(+), 17 deletions(-)
Both of the issues reportd by sashiko here are not introduced by this patch
https://sashiko.dev/#/patchset/20260610-airoha-ethtool-priv_flags-v4-0-60e89cf28fea%40kernel.org
Regards,
Lorenzo
>
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 5a8e84fa9918..aeac66df5f3b 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -1771,6 +1771,40 @@ static void airoha_update_hw_stats(struct airoha_gdm_dev *dev)
> spin_unlock(&port->stats.lock);
> }
>
> +static void airoha_qdma_start(struct airoha_qdma *qdma)
> +{
> + airoha_qdma_set(qdma, REG_QDMA_GLOBAL_CFG,
> + GLOBAL_CFG_TX_DMA_EN_MASK |
> + GLOBAL_CFG_RX_DMA_EN_MASK);
> + atomic_inc(&qdma->users);
> +}
> +
> +static void airoha_qdma_stop(struct airoha_qdma *qdma)
> +{
> + u32 status;
> +
> + if (!atomic_dec_and_test(&qdma->users))
> + return;
> +
> + airoha_qdma_clear(qdma, REG_QDMA_GLOBAL_CFG,
> + GLOBAL_CFG_TX_DMA_EN_MASK |
> + GLOBAL_CFG_RX_DMA_EN_MASK);
> +
> + if (read_poll_timeout(airoha_qdma_rr, status,
> + !(status & (GLOBAL_CFG_TX_DMA_BUSY_MASK |
> + GLOBAL_CFG_RX_DMA_BUSY_MASK)),
> + USEC_PER_MSEC, 50 * USEC_PER_MSEC, true,
> + qdma, REG_QDMA_GLOBAL_CFG))
> + dev_warn(qdma->eth->dev, "QDMA DMA engine busy timeout\n");
> +
> + for (int i = 0; i < ARRAY_SIZE(qdma->q_tx); i++) {
> + if (!qdma->q_tx[i].ndesc)
> + continue;
> +
> + airoha_qdma_cleanup_tx_queue(&qdma->q_tx[i]);
> + }
> +}
> +
> static int airoha_dev_open(struct net_device *netdev)
> {
> int err, len = ETH_HLEN + netdev->mtu + ETH_FCS_LEN;
> @@ -1806,10 +1840,7 @@ static int airoha_dev_open(struct net_device *netdev)
> }
> port->users++;
>
> - airoha_qdma_set(qdma, REG_QDMA_GLOBAL_CFG,
> - GLOBAL_CFG_TX_DMA_EN_MASK |
> - GLOBAL_CFG_RX_DMA_EN_MASK);
> - atomic_inc(&qdma->users);
> + airoha_qdma_start(qdma);
>
> if (!airoha_is_lan_gdm_dev(dev) &&
> airoha_ppe_is_enabled(qdma->eth, 1))
> @@ -1862,19 +1893,7 @@ static int airoha_dev_stop(struct net_device *netdev)
> airoha_set_gdm_port_fwd_cfg(qdma->eth,
> REG_GDM_FWD_CFG(port->id),
> FE_PSE_PORT_DROP);
> -
> - if (atomic_dec_and_test(&qdma->users)) {
> - airoha_qdma_clear(qdma, REG_QDMA_GLOBAL_CFG,
> - GLOBAL_CFG_TX_DMA_EN_MASK |
> - GLOBAL_CFG_RX_DMA_EN_MASK);
> -
> - for (i = 0; i < ARRAY_SIZE(qdma->q_tx); i++) {
> - if (!qdma->q_tx[i].ndesc)
> - continue;
> -
> - airoha_qdma_cleanup_tx_queue(&qdma->q_tx[i]);
> - }
> - }
> + airoha_qdma_stop(qdma);
>
> return 0;
> }
>
> --
> 2.54.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ 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