* Re: [PATCH v2 4/4] arm64: dts: amlogic: t7: Add clk measure support
From: Neil Armstrong @ 2026-04-20 8:52 UTC (permalink / raw)
To: Jian Hu, Ronald Claveau
Cc: devicetree, linux-arm-kernel, linux-amlogic, linux-kernel,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Kevin Hilman,
Jerome Brunet, Martin Blumenstingl
In-Reply-To: <64cde9f6-4f28-4ba7-8362-aac28887ff22@amlogic.com>
On 4/20/26 05:25, Jian Hu wrote:
> Hi Ronald,
>
>
> Thanks for your review.
>
> On 4/17/2026 5:48 PM, Ronald Claveau wrote:
>> [ EXTERNAL EMAIL ]
>>
>> Hello Jian,
>>
>> On 4/15/26 10:33 AM, Jian Hu via B4 Relay wrote:
>>> From: Jian Hu <jian.hu@amlogic.com>
>>>
>>> Add the clock measure device to the T7 SoC family.
>>>
>>> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
>>> ---
>>> arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 5 +++++
>>> 1 file changed, 5 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
>>> index 7fe72c94ed62..cec2ea74850d 100644
>>> --- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
>>> +++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
>>> @@ -701,6 +701,11 @@ pwm_ao_cd: pwm@60000 {
>>> status = "disabled";
>>> };
>>>
>>> + clock-measurer@48000 {
>>> + compatible = "amlogic,t7-clk-measure";
>>> + reg = <0x0 0x48000 0x0 0x1c>;
>>> + };
>>> +
>> Can you please order by reg, it should be between pwm_ao_gh and pwm_ab.
>> Thank you.
>
>
> According to the "Order of Nodes" chapter in Documentation/devicetree/bindings/dts-coding-style.rst,
>
> nodes of the same type should be grouped together, and this takes higher priority.
>
> So I have placed the clock-measure node after all PWM nodes to avoid splitting the PWM group.
This is not something we ever followed in the past, and I don't think it makes sens here.
"""
Alternatively for some subarchitectures, nodes of the same type can be
grouped together, e.g. all I2C controllers one after another even if this
breaks unit address ordering.
"""
This doesn't apply here, so order strictly by address.
Neil
>
>
> Best regards,
>
> Jian
>
^ permalink raw reply
* Re: [RFC PATCH 4/4] firmware: arm_ffa: check pkvm initailised when initailise ffa driver
From: Will Deacon @ 2026-04-20 8:55 UTC (permalink / raw)
To: Yeoreum Yun
Cc: Marc Zyngier, linux-security-module, linux-kernel,
linux-integrity, linux-arm-kernel, kvmarm, paul, jmorris, serge,
zohar, roberto.sassu, dmitry.kasatkin, eric.snowberg, peterhuewe,
jarkko, jgg, sudeep.holla, oupton, joey.gouly, suzuki.poulose,
yuzenghui, catalin.marinas
In-Reply-To: <aeS4rAeVQ0yJIPYw@e129823.arm.com>
On Sun, Apr 19, 2026 at 12:12:44PM +0100, Yeoreum Yun wrote:
> Hi Marc,
>
> > On Sat, 18 Apr 2026 11:34:30 +0100,
> > Yeoreum Yun <yeoreum.yun@arm.com> wrote:
> > >
> > > > > @@ -2035,6 +2037,16 @@ static int __init ffa_init(void)
> > > > > u32 buf_sz;
> > > > > size_t rxtx_bufsz = SZ_4K;
> > > > >
> > > > > + /*
> > > > > + * When pKVM is enabled, the FF-A driver must be initialized
> > > > > + * after pKVM initialization. Otherwise, pKVM cannot negotiate
> > > > > + * the FF-A version or obtain RX/TX buffer information,
> > > > > + * which leads to failures in FF-A calls.
> > > > > + */
> > > > > + if (IS_ENABLED(CONFIG_KVM) && is_protected_kvm_enabled() &&
> > > > > + !is_kvm_arm_initialised())
> > > > > + return -EPROBE_DEFER;
> > > > > +
> > > >
> > > > That's still fundamentally wrong: pkvm is not ready until
> > > > finalize_pkvm() has finished, and that's not indicated by
> > > > is_kvm_arm_initialised().
> > >
> > > Thanks. I miss the TSC bit set in here.
> >
> > That's the least of the problems. None of the infrastructure is in
> > place at this stage...
> >
> > > IMHO, I'd like to make an new state check function --
> > > is_pkvm_arm_initialised() so that ff-a driver to know whether
> > > pkvm is initialised.
> >
> > Doesn't sound great, TBH.
> >
> > > or any other suggestion?
> >
> > Instead of adding more esoteric predicates, I'd rather you build on an
> > existing infrastructure. You have a dependency on KVM, use something
> > that is designed to enforce dependencies. Device links spring to mind
> > as something designed for that.
> >
> > Can you look into enabling this for KVM? If that's possible, then it
> > should be easy enough to delay the actual KVM registration after pKVM
> > is finalised.
>
> or what about some event notifier? Just like:
This seems a bit over-engineered to me. Why don't you just split the
FF-A initialisation into two steps: an early part which does the version
negotiation and then a later part which can fit in with whatever
dependencies you have on the TPM?
Will
^ permalink raw reply
* Re: [PATCH] gpio: aspeed: fix AST2700 debounce selector bit definitions
From: Bartosz Golaszewski @ 2026-04-20 9:15 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski, Joel Stanley, Andrew Jeffery,
Billy Tsai
Cc: Bartosz Golaszewski, linux-gpio, linux-arm-kernel, linux-aspeed,
linux-kernel
In-Reply-To: <20260415-gpio-fix-v1-1-b08a89b31e6f@aspeedtech.com>
On Wed, 15 Apr 2026 18:24:42 +0800, Billy Tsai wrote:
> The AST2700 datasheet defines reg_debounce_sel1 as the low bit and
> reg_debounce_sel2 as the high bit. The current driver uses the AST2600
> mapping instead, where sel1 is the high bit and sel2 is the low bit.
>
> As a result, the debounce selector bits are programmed in reverse on
> AST2700. Swap the G7 sel1/sel2 bit definitions so the driver matches the
> hardware definition.
>
> [...]
Applied, thanks!
[1/1] gpio: aspeed: fix AST2700 debounce selector bit definitions
https://git.kernel.org/brgl/c/e31eee4a961077d60ef2362507240c6743c1c2ae
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v2 4/4] arm64: dts: amlogic: t7: Add clk measure support
From: Ronald Claveau @ 2026-04-20 9:16 UTC (permalink / raw)
To: Jian Hu
Cc: devicetree, linux-arm-kernel, linux-amlogic, linux-kernel,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl
In-Reply-To: <64cde9f6-4f28-4ba7-8362-aac28887ff22@amlogic.com>
Hi Jian,
On 4/20/26 5:25 AM, Jian Hu wrote:
> Hi Ronald,
>
>
> Thanks for your review.
>
> On 4/17/2026 5:48 PM, Ronald Claveau wrote:
>> [ EXTERNAL EMAIL ]
>>
>> Hello Jian,
>>
>> On 4/15/26 10:33 AM, Jian Hu via B4 Relay wrote:
>>> From: Jian Hu <jian.hu@amlogic.com>
>>>
>>> Add the clock measure device to the T7 SoC family.
>>>
>>> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
>>> ---
>>> arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 5 +++++
>>> 1 file changed, 5 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/
>>> arm64/boot/dts/amlogic/amlogic-t7.dtsi
>>> index 7fe72c94ed62..cec2ea74850d 100644
>>> --- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
>>> +++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
>>> @@ -701,6 +701,11 @@ pwm_ao_cd: pwm@60000 {
>>> status = "disabled";
>>> };
>>>
>>> + clock-measurer@48000 {
>>> + compatible = "amlogic,t7-clk-measure";
>>> + reg = <0x0 0x48000 0x0 0x1c>;
>>> + };
>>> +
>> Can you please order by reg, it should be between pwm_ao_gh and pwm_ab.
>> Thank you.
>
>
> According to the "Order of Nodes" chapter in Documentation/devicetree/
> bindings/dts-coding-style.rst,
>
> nodes of the same type should be grouped together, and this takes higher
> priority.
>
> So I have placed the clock-measure node after all PWM nodes to avoid
> splitting the PWM group.
>
Thanks for your answer.
The documentation says nodes "shall be ordered by unit address" as the
primary rule.
The grouping by type is described as an alternative ("Alternatively"),
applicable to some subarchitectures, not as a rule that takes higher
priority.
So to me, I understand it as, unless your subarchitecture has an
established convention of grouping PWM nodes together, ordering by reg
remains the correct default here. And, in my opinion, sticking to a
single sorting method improves readability.
--
Best regards,
Ronald
^ permalink raw reply
* Re: [PATCH 2/3] gpio: axiado: add SGPIO controller support
From: Bartosz Golaszewski @ 2026-04-20 9:25 UTC (permalink / raw)
To: Petar Stepanovic
Cc: linux-gpio, devicetree, linux-arm-kernel, linux-kernel,
Tzu-Hao Wei, Swark Yang, Prasad Bolisetty, Linus Walleij,
Bartosz Golaszewski, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Harshit Shah, SriNavmani A
In-Reply-To: <20260414-axiado-ax3000-sgpio-controller-v1-2-b5c7e4c2e69b@axiado.com>
On Tue, 14 Apr 2026 15:48:33 +0200, Petar Stepanovic
<pstepanovic@axiado.com> said:
> Add support for the Axiado SGPIO controller.
>
> The controller provides a serialized interface for GPIOs with
> configurable direction and interrupt support.
>
> The driver registers the controller as a gpio_chip and uses
> regmap for register access.
>
> Signed-off-by: Petar Stepanovic <pstepanovic@axiado.com>
> ---
> drivers/gpio/Kconfig | 18 +
> drivers/gpio/Makefile | 1 +
> drivers/gpio/gpio-axiado-sgpio.c | 780 +++++++++++++++++++++++++++++++++++++++
> 3 files changed, 799 insertions(+)
>
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index bd185482a7fd..42c56d157092 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -198,6 +198,24 @@ config GPIO_ATH79
> Select this option to enable GPIO driver for
> Atheros AR71XX/AR724X/AR913X SoC devices.
>
> +config GPIO_AXIADO_SGPIO
> + bool "Axiado SGPIO support"
> + depends on OF_GPIO
You don't need this.
> + depends on ARCH_AXIADO || COMPILE_TEST
> + select GPIO_GENERIC
You don't seem to be using this.
> + select GPIOLIB_IRQCHIP
> + select REGMAP
> + help
> + Enable support for the Axiado Serial GPIO (SGPIO) controller.
> +
> + The SGPIO controller provides a serialized interface for
> + controlling multiple GPIO signals over a limited number of
> + physical lines. It supports configurable data direction and
> + interrupt handling.
> +
> + This driver integrates with the Linux GPIO subsystem and
> + exposes the controller as a standard GPIO provider.
> +
> config GPIO_RASPBERRYPI_EXP
> tristate "Raspberry Pi 3 GPIO Expander"
> default RASPBERRYPI_FIRMWARE
> diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
> index 2421a8fd3733..909a97551807 100644
> --- a/drivers/gpio/Makefile
> +++ b/drivers/gpio/Makefile
> @@ -42,6 +42,7 @@ obj-$(CONFIG_GPIO_ARIZONA) += gpio-arizona.o
> obj-$(CONFIG_GPIO_ASPEED) += gpio-aspeed.o
> obj-$(CONFIG_GPIO_ASPEED_SGPIO) += gpio-aspeed-sgpio.o
> obj-$(CONFIG_GPIO_ATH79) += gpio-ath79.o
> +obj-$(CONFIG_GPIO_AXIADO_SGPIO) += gpio-axiado-sgpio.o
> obj-$(CONFIG_GPIO_BCM_KONA) += gpio-bcm-kona.o
> obj-$(CONFIG_GPIO_BCM_XGS_IPROC) += gpio-xgs-iproc.o
> obj-$(CONFIG_GPIO_BD71815) += gpio-bd71815.o
> diff --git a/drivers/gpio/gpio-axiado-sgpio.c b/drivers/gpio/gpio-axiado-sgpio.c
> new file mode 100644
> index 000000000000..8cd349ec6f53
> --- /dev/null
> +++ b/drivers/gpio/gpio-axiado-sgpio.c
> @@ -0,0 +1,780 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (c) 2022-2026 Axiado Corporation
> + */
Please add a blank line here...
> +#include <linux/types.h>
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/module.h>
> +
> +#include <linux/platform_device.h>
> +#include <linux/io.h>
> +#include <linux/spinlock.h>
> +
> +#include <linux/interrupt.h>
> +#include <linux/irq.h>
> +#include <linux/irqdomain.h>
> +
> +#include <linux/gpio/driver.h>
> +
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/of_irq.h>
> +
> +#include <linux/regmap.h>
> +
... and keep the includes together as well as ordered alphabetically.
> +struct sgpio_reg_offsets {
> + u32 mux_0;
> + u32 preset_0;
> + u32 count_0;
> + u32 pos_0;
> +
> + u32 mux_1;
> + u32 ld;
> + u32 ld_ss;
> +
> + u32 preset_1;
> + u32 count_1;
> + u32 pos_1;
> +
> + u32 mux_2;
> + u32 dout;
> + u32 dout_ss;
> +
> + u32 preset_2;
> + u32 count_2;
> + u32 pos_2;
> +
> + u32 mux_3;
> + u32 preset_3;
> + u32 count_3;
> + u32 pos_3;
> +
> + u32 mux_4;
> + u32 oe;
> + u32 oe_ss;
> +
> + u32 preset_4;
> + u32 count_4;
> + u32 pos_4;
> +
> + u32 mask;
> + u32 ctrl_en;
> + u32 ctrl_en_pos;
> +
> + u32 din_ss;
> + u32 status;
> +};
> +
> +static const struct sgpio_reg_offsets sgpio_offsets_512 = {
> + .mux_0 = 0x000,
> + .preset_0 = 0x1dc,
> + .count_0 = 0x1f0,
> + .pos_0 = 0x204,
> +
> + .mux_1 = 0x004,
> + .ld = 0x014,
> + .ld_ss = 0x0d8,
> +
> + .preset_1 = 0x1e0,
> + .count_1 = 0x1f4,
> + .pos_1 = 0x208,
> +
> + .mux_2 = 0x008,
> + .dout = 0x054,
> + .dout_ss = 0x158,
> +
> + .preset_2 = 0x1e4,
> + .count_2 = 0x1f8,
> + .pos_2 = 0x20c,
> +
> + .mux_3 = 0x00c,
> + .preset_3 = 0x1e8,
> + .count_3 = 0x1fc,
> + .pos_3 = 0x210,
> +
> + .mux_4 = 0x010,
> + .oe = 0x0d4,
> + .oe_ss = 0x1d8,
> +
> + .preset_4 = 0x1ec,
> + .count_4 = 0x200,
> + .pos_4 = 0x214,
> +
> + .mask = 0x224,
> + .ctrl_en = 0x218,
> + .ctrl_en_pos = 0x21c,
> +
> + .din_ss = 0x198,
> + .status = 0x228,
> +};
> +
> +static const struct sgpio_reg_offsets sgpio_offsets_128 = {
> + .mux_0 = 0x000,
> + .preset_0 = 0x08c,
> + .count_0 = 0x0a0,
> + .pos_0 = 0x0b4,
> +
> + .mux_1 = 0x004,
> + .ld = 0x014,
> + .ld_ss = 0x048,
> +
> + .preset_1 = 0x090,
> + .count_1 = 0x0a4,
> + .pos_1 = 0x0b8,
> +
> + .mux_2 = 0x008,
> + .dout = 0x024,
> + .dout_ss = 0x068,
> +
> + .preset_2 = 0x094,
> + .count_2 = 0x0a8,
> + .pos_2 = 0x0bc,
> +
> + .mux_3 = 0x00c,
> + .preset_3 = 0x098,
> + .count_3 = 0x0ac,
> + .pos_3 = 0x0c0,
> +
> + .mux_4 = 0x010,
> + .oe = 0x044,
> + .oe_ss = 0x088,
> +
> + .preset_4 = 0x09c,
> + .count_4 = 0x0b0,
> + .pos_4 = 0x0c4,
> +
> + .mask = 0x0d4,
> + .ctrl_en = 0x0c8,
> + .ctrl_en_pos = 0x0cc,
> +
> + .din_ss = 0x078,
> + .status = 0x0d8,
> +};
> +
> +#define MAX_SGPIO_PINS 512
> +#define MAX_OFFSET_REG 16
> +#define MAX_SLICE_COUNT 5
> +
> +struct ax3000_slice_info {
> + u32 out_mux;
> + u32 sgpio_mux;
> + u32 slice_mux;
> + u32 reg[MAX_OFFSET_REG];
> + u32 reg_ss[MAX_OFFSET_REG];
> + u32 preset;
> + u32 count;
> + u32 pos;
> +};
> +
> +struct ax3000_sgpio {
> + u32 preset_value;
> + u32 count_value;
> + u32 pos_reg;
> + struct ax3000_slice_info
> + slices[MAX_SLICE_COUNT]; /* 0=clk,1=load,2=out,3=in,4=oe */
> + spinlock_t lock;
> + int ngpios;
> + int max_sgpio_pins;
> + int max_offset_regs;
> + struct gpio_chip chip;
> + u32 irq_unmasked[MAX_SGPIO_PINS];
> + int parent_irq;
> + struct regmap *regmap;
> + u32 regmap_base_offset;
> + struct sgpio_reg_offsets *regs;
> +};
> +
> +static int sgpio_set_irq_type(struct irq_data *d, unsigned int type);
> +static void sgpio_mask_irq(struct irq_data *d);
> +static void sgpio_unmask_irq(struct irq_data *d);
> +static void sgpio_irq_shutdown(struct irq_data *d);
> +
> +static const struct irq_chip axiado_sgpio_irqchip = {
> + .name = "axiado-sgpio",
> + .irq_mask = sgpio_mask_irq,
> + .irq_unmask = sgpio_unmask_irq,
> + .irq_set_type = sgpio_set_irq_type,
> + .irq_shutdown = sgpio_irq_shutdown,
> + .flags = IRQCHIP_IMMUTABLE | IRQCHIP_MASK_ON_SUSPEND,
> +};
> +
> +static void ax3000_sgpio_set(struct gpio_chip *chip, unsigned int offset,
> + int value)
> +{
> + struct ax3000_sgpio *sgpio = gpiochip_get_data(chip);
> + unsigned long flags;
> + u32 bank = (offset / 2) / 32;
> + u32 position = (offset / 2) % 32;
> +
> + spin_lock_irqsave(&sgpio->lock, flags);
Please use guards for locks.
> + if (value)
> + sgpio->slices[2].reg_ss[bank] |= BIT(position);
> + else
> + sgpio->slices[2].reg_ss[bank] &= ~BIT(position);
> +
> + spin_unlock_irqrestore(&sgpio->lock, flags);
> + regmap_write(sgpio->regmap,
> + sgpio->regmap_base_offset + sgpio->regs->dout_ss +
> + (bank * 4),
> + sgpio->slices[2].reg_ss[bank]);
> +}
> +
> +static int ax3000_sgpio_get(struct gpio_chip *chip, unsigned int offset)
> +{
> + struct ax3000_sgpio *sgpio = gpiochip_get_data(chip);
> + u32 bank = (offset / 2) / 32;
> + u32 position = (offset / 2) % 32;
> +
> + if (offset % 2 == 0)
> + return !!(sgpio->slices[3].reg_ss[bank] & BIT(position));
> + else
> + return !!(sgpio->slices[2].reg_ss[bank] & BIT(position));
> +}
> +
> +static int ax3000_sgpio_dir_in(struct gpio_chip *chip, unsigned int offset)
> +{
> + if (!(offset % 2))
> + return 0;
> + else
> + return -EINVAL;
> +}
> +
> +static int ax3000_sgpio_dir_out(struct gpio_chip *chip, unsigned int offset,
> + int value)
> +{
> + if (offset % 2) {
> + if (chip->set)
> + chip->set(chip, offset, value);
> + return 0;
> + } else {
> + return -EINVAL;
> + }
> +}
> +
> +static irqreturn_t sgpio_irq_handler(int irq, void *arg)
> +{
> + struct ax3000_sgpio *sgpio = (struct ax3000_sgpio *)arg;
> + unsigned long flags;
> + u32 status, new_value;
> + u32 changed_value;
> + int i, bit, reg_ptr;
> +
> + /* Read-on-clear (ACK) parent cause */
> + regmap_read(sgpio->regmap,
> + sgpio->regmap_base_offset + sgpio->regs->status, &status);
> + status >>= 16;
> +
> + bool has_shifted_layout = (sgpio->max_offset_regs == MAX_OFFSET_REG);
> +
> + reg_ptr = has_shifted_layout ? 16 - DIV_ROUND_UP(sgpio->ngpios, 32) : 0;
> +
> + for (i = 0; i < DIV_ROUND_UP(sgpio->ngpios, 32); i++, reg_ptr++) {
> + if (status & BIT(reg_ptr)) {
> + regmap_read(sgpio->regmap,
> + sgpio->regmap_base_offset +
> + sgpio->regs->din_ss + (reg_ptr * 4),
> + &new_value);
> + spin_lock_irqsave(&sgpio->lock, flags);
> + changed_value = sgpio->slices[3].reg_ss[i] ^ new_value;
> + sgpio->slices[3].reg_ss[i] = new_value;
> + spin_unlock_irqrestore(&sgpio->lock, flags);
> +
> + while (changed_value) {
> + bit = __ffs(changed_value);
> + changed_value &= ~BIT(bit);
> +
> + irq_hw_number_t hwirq = i * 32 + bit;
> +
> + if (sgpio->irq_unmasked[hwirq]) {
> + unsigned int child_irq;
> +
> + child_irq = irq_find_mapping(sgpio->chip.irq.domain,
> + hwirq);
> +
> + if (child_irq)
> + handle_nested_irq(child_irq);
> + }
> + }
> + }
> + }
> +
> + return IRQ_HANDLED;
> +}
> +
> +static void sgpio_hw_init(struct ax3000_sgpio *sgpio)
> +{
> + u32 bank;
> + u32 position;
> + int i = 0;
> + bool has_shifted_layout = (sgpio->max_offset_regs == MAX_OFFSET_REG);
> +
> + /* slice A0, Clock Pin - 0 */
> + regmap_write(sgpio->regmap,
> + sgpio->regmap_base_offset + sgpio->regs->mux_0, 0x306);
> + regmap_write(sgpio->regmap,
> + sgpio->regmap_base_offset + sgpio->regs->preset_0,
> + sgpio->preset_value);
> + regmap_write(sgpio->regmap,
> + sgpio->regmap_base_offset + sgpio->regs->count_0,
> + sgpio->count_value);
> + regmap_write(sgpio->regmap,
> + sgpio->regmap_base_offset + sgpio->regs->pos_0, 0x1f001f);
> +
> + /* Slice B1, Data Load Pin - 1 */
> + bank = (sgpio->ngpios - 1) / 32;
> + position = (sgpio->ngpios - 1) % 32;
> +
> + regmap_write(sgpio->regmap,
> + sgpio->regmap_base_offset + sgpio->regs->mux_1,
> + has_shifted_layout ? 0x30c : 0x304);
> +
> + for (i = 0; i < bank; i++) {
> + regmap_write(sgpio->regmap,
> + sgpio->regmap_base_offset + sgpio->regs->ld +
> + (i * 4),
> + 0xffffffff);
> + regmap_write(sgpio->regmap,
> + sgpio->regmap_base_offset + sgpio->regs->ld_ss +
> + (i * 4),
> + 0xffffffff);
> + }
> +
> + if (position) {
> + u32 val;
> +
> + val = sgpio->slices[1].reg_ss[i];
> + val |= GENMASK(position - 1, 0);
> +
> + regmap_write(sgpio->regmap,
> + sgpio->regmap_base_offset + sgpio->regs->ld +
> + (i * 4),
> + val);
> + regmap_write(sgpio->regmap,
> + sgpio->regmap_base_offset + sgpio->regs->ld_ss +
> + (i * 4),
> + val);
> + }
> +
> + regmap_write(sgpio->regmap,
> + sgpio->regmap_base_offset + sgpio->regs->preset_1,
> + sgpio->preset_value);
> + regmap_write(sgpio->regmap,
> + sgpio->regmap_base_offset + sgpio->regs->count_1,
> + sgpio->count_value);
> + regmap_write(sgpio->regmap,
> + sgpio->regmap_base_offset + sgpio->regs->pos_1,
> + sgpio->pos_reg);
> +
> + /* Slice C2, Data Out Pin - 2 */
> + bank = sgpio->ngpios / 32;
> + position = sgpio->ngpios % 32;
> +
> + regmap_write(sgpio->regmap,
> + sgpio->regmap_base_offset + sgpio->regs->mux_2,
> + has_shifted_layout ? 0x30c : 0x304);
> +
> + for (i = 0; i < bank; i++) {
> + regmap_write(sgpio->regmap,
> + sgpio->regmap_base_offset + sgpio->regs->dout +
> + (i * 4),
> + sgpio->slices[2].reg_ss[i]);
> + regmap_write(sgpio->regmap,
> + sgpio->regmap_base_offset + sgpio->regs->dout_ss +
> + (i * 4),
> + sgpio->slices[2].reg_ss[i]);
> + }
> +
> + if (position) {
> + regmap_write(sgpio->regmap,
> + sgpio->regmap_base_offset + sgpio->regs->dout +
> + (i * 4),
> + sgpio->slices[2].reg_ss[i]);
> + regmap_write(sgpio->regmap,
> + sgpio->regmap_base_offset + sgpio->regs->dout_ss +
> + (i * 4),
> + sgpio->slices[2].reg_ss[i]);
> + }
> +
> + regmap_write(sgpio->regmap,
> + sgpio->regmap_base_offset + sgpio->regs->preset_2,
> + sgpio->preset_value);
> + regmap_write(sgpio->regmap,
> + sgpio->regmap_base_offset + sgpio->regs->count_2,
> + sgpio->count_value);
> + regmap_write(sgpio->regmap,
> + sgpio->regmap_base_offset + sgpio->regs->pos_2,
> + sgpio->pos_reg);
> +
> + /* Slice D3, Data In Pin - 3 */
> + regmap_write(sgpio->regmap,
> + sgpio->regmap_base_offset + sgpio->regs->mux_3, 0x14C);
> + regmap_write(sgpio->regmap,
> + sgpio->regmap_base_offset + sgpio->regs->preset_3,
> + sgpio->preset_value);
> + regmap_write(sgpio->regmap,
> + sgpio->regmap_base_offset + sgpio->regs->count_3,
> + sgpio->count_value);
> + regmap_write(sgpio->regmap,
> + sgpio->regmap_base_offset + sgpio->regs->pos_3,
> + sgpio->pos_reg);
> +
> + /* Slice E4, Output Enable for respective pins */
> + regmap_write(sgpio->regmap,
> + sgpio->regmap_base_offset + sgpio->regs->mux_4,
> + has_shifted_layout ? 0x10c : 0x104);
> + regmap_write(sgpio->regmap, sgpio->regmap_base_offset + sgpio->regs->oe,
> + 0xffffffff);
> + regmap_write(sgpio->regmap,
> + sgpio->regmap_base_offset + sgpio->regs->oe_ss,
> + 0xffffffff);
> + regmap_write(sgpio->regmap,
> + sgpio->regmap_base_offset + sgpio->regs->preset_4,
> + sgpio->preset_value);
> + regmap_write(sgpio->regmap,
> + sgpio->regmap_base_offset + sgpio->regs->count_4,
> + sgpio->count_value);
> + regmap_write(sgpio->regmap,
> + sgpio->regmap_base_offset + sgpio->regs->pos_4, 0x1f001f);
> +
> + regmap_write(sgpio->regmap,
> + sgpio->regmap_base_offset + sgpio->regs->mask, 0xdfff);
> +
> + regmap_write(sgpio->regmap,
> + sgpio->regmap_base_offset + sgpio->regs->ctrl_en, 0xffff);
> + regmap_write(sgpio->regmap,
> + sgpio->regmap_base_offset + sgpio->regs->ctrl_en_pos,
> + 0xffff);
> +}
> +
> +static int sgpio_set_irq_type(struct irq_data *d, unsigned int type)
> +{
> + switch (type) {
> + case IRQ_TYPE_EDGE_BOTH:
> + case IRQ_TYPE_EDGE_RISING:
> + case IRQ_TYPE_EDGE_FALLING:
> + irq_set_handler_locked(d, handle_edge_irq);
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +static void sgpio_mask_irq(struct irq_data *d)
> +{
> + struct gpio_chip *chip;
> + struct ax3000_sgpio *sgpio;
> + u32 irq_num;
> +
> + chip = irq_data_get_irq_chip_data(d);
> + if (!chip) {
> + pr_err("Unable to get gpio_chip for IRQ\n");
> + return;
> + }
> +
> + sgpio = gpiochip_get_data(chip);
> + if (!sgpio) {
> + pr_err("Unable to get chip data\n");
> + return;
> + }
> +
> + irq_num = irqd_to_hwirq(d);
> + sgpio->irq_unmasked[irq_num / 2] = 0;
> +}
> +
> +static void sgpio_unmask_irq(struct irq_data *d)
> +{
> + struct gpio_chip *chip;
> + struct ax3000_sgpio *sgpio;
> + u32 irq_num;
> +
> + chip = irq_data_get_irq_chip_data(d);
> + if (!chip) {
> + pr_err("Unable to get gpio_chip for IRQ\n");
> + return;
> + }
> +
> + sgpio = gpiochip_get_data(chip);
> + if (!sgpio) {
> + pr_err("Unable to get chip data\n");
> + return;
> + }
> +
> + irq_num = irqd_to_hwirq(d);
> + sgpio->irq_unmasked[irq_num / 2] = 1;
> +}
> +
> +static void sgpio_irq_shutdown(struct irq_data *d)
> +{
> + sgpio_mask_irq(d);
> +}
> +
> +static int sgpio_probe(struct platform_device *pdev)
> +{
> + int rc;
> + int irq;
> + int i;
> + const __be32 *prop;
> + struct gpio_irq_chip *girq;
> + struct ax3000_sgpio *sgpio;
> + u32 variant;
> + u32 dout_value;
> + u32 bus_frequency;
> + u32 apb_frequency;
> + int dout_reverse;
> +
> + void __iomem *base;
> +
> + const struct regmap_config regmap_config = {
> + .reg_bits = 32,
> + .val_bits = 32,
> + .reg_stride = 4,
> + };
> +
> + sgpio = devm_kzalloc(&pdev->dev, sizeof(*sgpio), GFP_KERNEL);
> + if (!sgpio)
> + return -ENOMEM;
> +
> + spin_lock_init(&sgpio->lock);
> +
> + sgpio->regmap = dev_get_regmap(pdev->dev.parent, NULL);
> +
> + if (sgpio->regmap) {
> + rc = of_property_read_u32(pdev->dev.of_node, "reg",
> + &sgpio->regmap_base_offset);
Why are you mixing of_property_*() with device_property_*()?
> + if (rc) {
> + dev_err(&pdev->dev, "Failed to read reg property: %d\n",
> + rc);
> + return rc;
> + }
> + dev_info(&pdev->dev, "Using regmap with base offset: 0x%x\n",
> + sgpio->regmap_base_offset);
> + } else {
> + base = devm_platform_ioremap_resource(pdev, 0);
> + if (IS_ERR(base))
> + return PTR_ERR(base);
> +
> + sgpio->regmap =
> + devm_regmap_init_mmio(&pdev->dev, base, ®map_config);
> +
> + if (IS_ERR(sgpio->regmap))
> + return PTR_ERR(sgpio->regmap);
> +
> + sgpio->regmap_base_offset = 0;
> +
> + dev_info(&pdev->dev, "Using MMIO regmap\n");
> + }
> +
> + rc = device_property_read_u32(&pdev->dev, "ngpios", &sgpio->ngpios);
> + if (rc < 0) {
> + dev_err(&pdev->dev, "Could not read ngpios property\n");
> + return -EINVAL;
> + }
> +
> + if (device_property_read_u32(&pdev->dev, "design-variant", &variant)) {
> + dev_err(&pdev->dev, "design-variant not specified in DT\n");
> + return -EINVAL;
> + }
> +
> + if (variant == 128) {
> + sgpio->regs = &sgpio_offsets_128;
> + sgpio->max_sgpio_pins = 128;
> + sgpio->max_offset_regs = 4;
> + } else if (variant == 512) {
> + sgpio->regs = &sgpio_offsets_512;
> + sgpio->max_sgpio_pins = 512;
> + sgpio->max_offset_regs = 16;
> + } else {
> + return -EINVAL;
> + }
> +
> + if (sgpio->ngpios > sgpio->max_sgpio_pins) {
> + dev_err(&pdev->dev, "ngpio is greater than 512 pins\n");
> + return -EINVAL;
> + }
> +
> + rc = device_property_read_u32(&pdev->dev, "bus-frequency",
> + &bus_frequency);
> + if (rc < 0) {
> + dev_err(&pdev->dev, "Could not read bus-frequency property\n");
> + return -EINVAL;
> + }
> +
> + rc = device_property_read_u32(&pdev->dev, "apb-frequency",
> + &apb_frequency);
> + if (rc < 0) {
> + dev_err(&pdev->dev, "Could not read apb-frequency property\n");
> + return -EINVAL;
> + }
> +
> + sgpio->preset_value = (apb_frequency / bus_frequency) - 1;
> + sgpio->count_value = sgpio->preset_value;
> +
> + u32 pos;
> +
> + pos = sgpio->ngpios - 1;
> + sgpio->pos_reg = (pos << 16) | pos;
> +
> + prop = of_get_property(pdev->dev.of_node, "dout-init", NULL);
> + if (!prop) {
> + dev_err(&pdev->dev, "Failed to get dout-init\n");
> + return -EINVAL;
> + }
> +
> + for (i = 0; i < sgpio->max_offset_regs; i++) {
> + sgpio->slices[2].reg_ss[i] = 0;
> + dout_value = be32_to_cpu(prop[i]);
> +
> + for (dout_reverse = 0; dout_reverse < 32; ++dout_reverse) {
> + sgpio->slices[2].reg_ss[i] <<= 1;
> + sgpio->slices[2].reg_ss[i] |= (dout_value & 1);
> + dout_value >>= 1;
> + }
> + }
> +
> + sgpio_hw_init(sgpio);
> +
> + irq = platform_get_irq(pdev, 0);
> +
Unnecessary newline.
> + if (irq < 0) {
> + dev_err(&pdev->dev, "Failed to get parent IRQ: %d\n", irq);
> + return irq;
> + }
> + /* Store parent IRQ for cleanup */
> + sgpio->parent_irq = irq;
> +
> + rc = devm_request_threaded_irq(&pdev->dev, irq, NULL, sgpio_irq_handler,
> + IRQF_ONESHOT, "axiado-sgpio", sgpio);
> +
> + if (rc < 0) {
> + dev_err(&pdev->dev, "Failed to request threaded IRQ %d: %d\n",
> + irq, rc);
> + return rc;
> + }
> +
> + sgpio->chip.parent = &pdev->dev;
> + sgpio->chip.ngpio = sgpio->ngpios * 2;
> + sgpio->chip.owner = THIS_MODULE;
> + sgpio->chip.direction_input = ax3000_sgpio_dir_in;
> + sgpio->chip.direction_output = ax3000_sgpio_dir_out;
> + sgpio->chip.get = ax3000_sgpio_get;
> + sgpio->chip.set = ax3000_sgpio_set;
> + sgpio->chip.label = dev_name(&pdev->dev);
> + sgpio->chip.base = -1;
> +
> + girq = &sgpio->chip.irq;
> +
> + girq->chip = &axiado_sgpio_irqchip;
> + girq->handler = handle_edge_irq;
> + girq->default_type = IRQ_TYPE_NONE;
> + girq->num_parents = 1;
> + girq->parents =
> + devm_kcalloc(&pdev->dev, 1, sizeof(*girq->parents), GFP_KERNEL);
> + if (!girq->parents) {
> + dev_err(&pdev->dev, "Failed to allocate parents array\n");
Drop this message, returning -ENOMEM is enough.
> + return -ENOMEM;
> + }
> + girq->parents[0] = irq;
> +
> + rc = devm_gpiochip_add_data(&pdev->dev, &sgpio->chip, sgpio);
> + if (rc < 0) {
> + dev_err(&pdev->dev, "Could not register gpiochip, %d\n", rc);
> + return rc;
Use return dev_err_probe() here and elsewhere.
> + }
> +
> + /* Store driver data for remove() */
> + platform_set_drvdata(pdev, sgpio);
> + dev_info(&pdev->dev, "SGPIO registered with %d GPIOs\n",
> + sgpio->chip.ngpio);
No need for this info message, please drop it.
> +
> + return 0;
> +}
> +
> +static int sgpio_remove(struct platform_device *pdev)
> +{
> + struct ax3000_sgpio *sgpio = platform_get_drvdata(pdev);
> + int i;
> +
> + if (!sgpio)
> + return 0;
> +
> + /* Disable interrupts in hardware */
> + if (sgpio->regs) {
> + regmap_write(sgpio->regmap,
> + sgpio->regmap_base_offset + sgpio->regs->mask,
> + 0x0);
> + regmap_write(sgpio->regmap,
> + sgpio->regmap_base_offset + sgpio->regs->ctrl_en,
> + 0x0);
> + }
> +
> + /* Disable and synchronize parent IRQ to avoid races with handlers */
> + if (sgpio->parent_irq >= 0) {
> + disable_irq(sgpio->parent_irq);
> + synchronize_irq(sgpio->parent_irq);
> + }
> +
> + /* Ensure all GPIO IRQ handlers complete before removal */
> + if (sgpio->chip.irq.domain) {
> + struct irq_domain *domain = sgpio->chip.irq.domain;
> + unsigned int irq;
> + int hwirq;
> +
> + for (hwirq = 0; hwirq < sgpio->chip.ngpio; hwirq++) {
> + irq = irq_find_mapping(domain, hwirq);
> + if (irq) {
> + disable_irq(irq);
> + synchronize_irq(irq);
> + }
> + }
> + }
> +
> + /* Clear internal IRQ state */
> + for (i = 0; i < sgpio->max_sgpio_pins; i++)
> + sgpio->irq_unmasked[i] = 0;
> +
> + return 0;
> +}
> +
> +static const struct of_device_id ax_sgpio_match[] = {
> + { .compatible = "axiado,sgpio" },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, ax_sgpio_match);
> +
> +static struct platform_driver sgpio_driver = {
> + .driver = {
> + .name = "sgpio",
> + .owner = THIS_MODULE,
> + .of_match_table = ax_sgpio_match,
> + },
> + .probe = sgpio_probe,
> + .remove = sgpio_remove,
> +};
> +
> +static int __init ax_sgpio_init(void)
> +{
> + int ret;
> +
> + ret = platform_driver_register(&sgpio_driver);
> + if (ret < 0) {
> + pr_err("Failed to register SGPIO driver\n");
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static void __exit ax_sgpio_exit(void)
> +{
> + platform_driver_unregister(&sgpio_driver);
> +}
> +
> +module_init(ax_sgpio_init);
> +module_exit(ax_sgpio_exit);
Just use module_platform_driver().
> +
> +MODULE_DESCRIPTION("Axiado Serial GPIO Driver");
> +MODULE_AUTHOR("Axiado Corporation");
> +MODULE_LICENSE("GPL");
>
> --
> 2.34.1
>
>
Bart
^ permalink raw reply
* Re: [RFC PATCH 4/4] firmware: arm_ffa: check pkvm initailised when initailise ffa driver
From: Yeoreum Yun @ 2026-04-20 9:25 UTC (permalink / raw)
To: Will Deacon
Cc: Marc Zyngier, linux-security-module, linux-kernel,
linux-integrity, linux-arm-kernel, kvmarm, paul, jmorris, serge,
zohar, roberto.sassu, dmitry.kasatkin, eric.snowberg, peterhuewe,
jarkko, jgg, sudeep.holla, oupton, joey.gouly, suzuki.poulose,
yuzenghui, catalin.marinas
In-Reply-To: <aeXp7WSqpXNytNPG@willie-the-truck>
Hi Will,
> On Sun, Apr 19, 2026 at 12:12:44PM +0100, Yeoreum Yun wrote:
> > Hi Marc,
> >
> > > On Sat, 18 Apr 2026 11:34:30 +0100,
> > > Yeoreum Yun <yeoreum.yun@arm.com> wrote:
> > > >
> > > > > > @@ -2035,6 +2037,16 @@ static int __init ffa_init(void)
> > > > > > u32 buf_sz;
> > > > > > size_t rxtx_bufsz = SZ_4K;
> > > > > >
> > > > > > + /*
> > > > > > + * When pKVM is enabled, the FF-A driver must be initialized
> > > > > > + * after pKVM initialization. Otherwise, pKVM cannot negotiate
> > > > > > + * the FF-A version or obtain RX/TX buffer information,
> > > > > > + * which leads to failures in FF-A calls.
> > > > > > + */
> > > > > > + if (IS_ENABLED(CONFIG_KVM) && is_protected_kvm_enabled() &&
> > > > > > + !is_kvm_arm_initialised())
> > > > > > + return -EPROBE_DEFER;
> > > > > > +
> > > > >
> > > > > That's still fundamentally wrong: pkvm is not ready until
> > > > > finalize_pkvm() has finished, and that's not indicated by
> > > > > is_kvm_arm_initialised().
> > > >
> > > > Thanks. I miss the TSC bit set in here.
> > >
> > > That's the least of the problems. None of the infrastructure is in
> > > place at this stage...
> > >
> > > > IMHO, I'd like to make an new state check function --
> > > > is_pkvm_arm_initialised() so that ff-a driver to know whether
> > > > pkvm is initialised.
> > >
> > > Doesn't sound great, TBH.
> > >
> > > > or any other suggestion?
> > >
> > > Instead of adding more esoteric predicates, I'd rather you build on an
> > > existing infrastructure. You have a dependency on KVM, use something
> > > that is designed to enforce dependencies. Device links spring to mind
> > > as something designed for that.
> > >
> > > Can you look into enabling this for KVM? If that's possible, then it
> > > should be easy enough to delay the actual KVM registration after pKVM
> > > is finalised.
> >
> > or what about some event notifier? Just like:
>
> This seems a bit over-engineered to me. Why don't you just split the
> FF-A initialisation into two steps: an early part which does the version
> negotiation and then a later part which can fit in with whatever
> dependencies you have on the TPM?
Sorry, I may have misunderstood your suggestion and
I might be in missing your point.
But, The issue here is that FFA_VERSION, FFA_RXTX_MAP, and
FFA_PARTITION_INFO_GET, which are invoked from ffa_init()
as part of early initialisation, must be trapped by pKVM.
In other words, even the early part of the initialization,
including version negotiation, needs to happen after pKVM
is initialized.
Because of this dependency, simply splitting the FF-A
initialization into two phases within the driver does not
seem sufficient, as it still requires knowing when pKVM
has been initialized.
Am I missing something?
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: dts: amlogic: t7: khadas-vim4: Enable Bluetooth
From: Ronald Claveau @ 2026-04-20 9:26 UTC (permalink / raw)
To: Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel
In-Reply-To: <c9c3227f-2a46-47b5-963f-e784184f7f31@linaro.org>
On 4/20/26 10:47 AM, Neil Armstrong wrote:
>> Enable UART C on the Khadas VIM4 board and attach the BCM43438
>> compatible Bluetooth controller to it. The node configures the RTS/CTS
>> hardware flow control, the associated pinmux, the power supplies
>> (vddao_3v3
>> and vddao_1v8), the 32 kHz LPO clock shared with the wifi32k fixed
>> clock, and the GPIO lines used for host wakeup, device wakeup and
>> shutdown.
>>
>> Remove clocks and clock-names for UART A, as they are defined in DTSI.
>
> This should be a separate patch.
Thanks for your feedback.
I will then add the remove redundant clocks before that one.
--
Best regards,
Ronald
^ permalink raw reply
* [PATCH] ACPI: arm64: cpuidle: Tolerate platforms with no deep PSCI idle states
From: Breno Leitao @ 2026-04-20 9:27 UTC (permalink / raw)
To: Lorenzo Pieralisi, Hanjun Guo, Sudeep Holla, Catalin Marinas,
Will Deacon, Rafael J. Wysocki, Len Brown, Huisong Li
Cc: Rafael J. Wysocki, linux-acpi, linux-arm-kernel, linux-kernel,
pjaroszynski, rmikey, kernel-team, stable, Breno Leitao
Commit cac173bea57d ("ACPI: processor: idle: Rework the handling of
acpi_processor_ffh_lpi_probe()") moved the acpi_processor_ffh_lpi_probe()
call from acpi_processor_setup_cpuidle_dev(), where its return value was
ignored, to acpi_processor_get_power_info(), where it is now treated as
a hard failure. As a result, platforms where psci_acpi_cpu_init_idle()
returned -ENODEV stopped registering any cpuidle states, forcing CPUs to
busy-poll when idle.
On NVIDIA Grace (aarch64) systems with PSCIv1.1, pr->power.count is 1
(only WFI, no deep PSCI states beyond it), so the previous
"count = pr->power.count - 1; if (count <= 0) return -ENODEV;" check
returned -ENODEV for all 72 CPUs and disabled cpuidle entirely.
The lpi_states count is already validated in acpi_processor_get_lpi_info(),
so the check here is redundant. Simplify the loop to iterate over
lpi_states[1..power.count). When only WFI is present, the loop body
simply does not execute and the function returns 0, which is the correct
outcome: there is nothing to validate for FFH and no error to report.
Suggested-by: Huisong Li <lihuisong@huawei.com>
Cc: stable@vger.kernel.org
Fixes: cac173bea57d ("ACPI: processor: idle: Rework the handling of acpi_processor_ffh_lpi_probe()")
Signed-off-by: Breno Leitao <leitao@debian.org>
---
drivers/acpi/arm64/cpuidle.c | 10 +++-------
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/acpi/arm64/cpuidle.c b/drivers/acpi/arm64/cpuidle.c
index 801f9c4501425..c68a5db8ebba8 100644
--- a/drivers/acpi/arm64/cpuidle.c
+++ b/drivers/acpi/arm64/cpuidle.c
@@ -16,7 +16,7 @@
static int psci_acpi_cpu_init_idle(unsigned int cpu)
{
- int i, count;
+ int i;
struct acpi_lpi_state *lpi;
struct acpi_processor *pr = per_cpu(processors, cpu);
@@ -30,14 +30,10 @@ static int psci_acpi_cpu_init_idle(unsigned int cpu)
if (!psci_ops.cpu_suspend)
return -EOPNOTSUPP;
- count = pr->power.count - 1;
- if (count <= 0)
- return -ENODEV;
-
- for (i = 0; i < count; i++) {
+ for (i = 1; i < pr->power.count; i++) {
u32 state;
- lpi = &pr->power.lpi_states[i + 1];
+ lpi = &pr->power.lpi_states[i];
/*
* Only bits[31:0] represent a PSCI power_state while
* bits[63:32] must be 0x0 as per ARM ACPI FFH Specification
---
base-commit: 1c7cc4904160c6fc6377564140062d68a3dc93a0
change-id: 20260413-ffh-93f68b2f46a3
Best regards,
--
Breno Leitao <leitao@debian.org>
^ permalink raw reply related
* Re: [PATCH V13 02/12] PCI: host-generic: Add common helpers for parsing Root Port properties
From: mani @ 2026-04-20 9:35 UTC (permalink / raw)
To: Sherry Sun
Cc: Bjorn Helgaas, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, Frank Li, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com, lpieralisi@kernel.org,
kwilczynski@kernel.org, bhelgaas@google.com, Hongxing Zhu,
l.stach@pengutronix.de, imx@lists.linux.dev,
linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <VI0PR04MB12114304913B6AACF6A206E10922F2@VI0PR04MB12114.eurprd04.prod.outlook.com>
On Mon, Apr 20, 2026 at 08:24:57AM +0000, Sherry Sun wrote:
[...]
> > Even if there are PERST# GPIOs from the host, connected to downstream
> > ports of a PCIe switch, they could be stored in the Root Port's (pci_host_port)
> > struct as a list of PERST#. This is what pcie-qcom driver does.
> >
> > It is too clumsy to handle PERST# individually for each device. We tried it
> > before with pwrctrl, but it always ended up biting us on who gets to control
> > the PERST#. We can't let pwrctrl handle PERST# for a switch port and host
> > controller driver handle it for RP. And we cannot let pwrctrl handle PERST# for
> > all ports, because, host controller drivers also need to control them for RC
> > initialization.
> >
> > That's why it was decided to handle PERST# for all ports in the host controller
> > drivers. So following that pattern, this helper could also be extended to parse
> > the PERST# from all ports defined in DT and store them in the same Root Port
> > struct.
> >
> > It should be trivial to implement this logic in the current helper. @Sherry:
> > Could you please implement this logic?
>
> Hi Mani, do you mean the similar logic in this patch?
> https://lore.kernel.org/all/20251216-pci-pwrctrl-rework-v2-1-745a563b9be6@oss.qualcomm.com/
> If yes, of cause I can do this for current helper functions in pci-host-common.c.
>
Yes!
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH 1/6] drm/connector: report IRQ_HPD events to drm_connector_oob_hotplug_event()
From: Dmitry Baryshkov @ 2026-04-20 9:50 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: dri-devel, linux-kernel, linux-usb, intel-gfx, intel-xe,
linux-amlogic, linux-arm-kernel, linux-arm-msm, freedreno,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Heikki Krogerus, Greg Kroah-Hartman, Andrzej Hajda,
Neil Armstrong, Robert Foss, Laurent Pinchart, Jonas Karlman,
Jernej Skrabec, Adrien Grassein, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, Bjorn Andersson,
Konrad Dybcio, Pengyu Luo, Nikita Travkin, Yongxing Mou
In-Reply-To: <a2e60e74-a1be-469d-8f4d-ecce1f30b517@ideasonboard.com>
On Mon, Apr 20, 2026 at 07:50:46AM +0300, Tomi Valkeinen wrote:
> Hi,
>
> On 18/04/2026 01:32, Dmitry Baryshkov wrote:
> > On Thu, Apr 16, 2026 at 11:10:03AM +0300, Tomi Valkeinen wrote:
> > > Hi,
> > >
> > > On 16/04/2026 02:22, Dmitry Baryshkov wrote:
> > > > The DisplayPort standard defines a special kind of events called IRQ.
> > > > These events are used to notify DP Source about the events on the Sink
> > > > side. It is extremely important for DP MST handling, where the MST
> > > > events are reported through this IRQ.
> > > >
> > > > In case of the USB-C DP AltMode there is no actual HPD pulse, but the
> > > > events are ported through the bits in the AltMode VDOs.
> > > >
> > > > Extend the drm_connector_oob_hotplug_event() interface and report IRQ
> > > > events to the DisplayPort Sink drivers.
> > > >
> > > > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> > > > ---
> > > > drivers/gpu/drm/drm_connector.c | 4 +++-
> > > > drivers/usb/typec/altmodes/displayport.c | 12 ++++++++----
> > > > include/drm/drm_connector.h | 3 ++-
> > > > 3 files changed, 13 insertions(+), 6 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> > > > index 47dc53c4a738..5fdacbd84bd7 100644
> > > > --- a/drivers/gpu/drm/drm_connector.c
> > > > +++ b/drivers/gpu/drm/drm_connector.c
> > > > @@ -3510,6 +3510,7 @@ struct drm_connector *drm_connector_find_by_fwnode(struct fwnode_handle *fwnode)
> > > > * drm_connector_oob_hotplug_event - Report out-of-band hotplug event to connector
> > > > * @connector_fwnode: fwnode_handle to report the event on
> > > > * @status: hot plug detect logical state
> > > > + * @irq_hpd: HPD pulse detected
> > > > *
> > > > * On some hardware a hotplug event notification may come from outside the display
> > > > * driver / device. An example of this is some USB Type-C setups where the hardware
> > > > @@ -3520,7 +3521,8 @@ struct drm_connector *drm_connector_find_by_fwnode(struct fwnode_handle *fwnode)
> > > > * a drm_connector reference through calling drm_connector_find_by_fwnode().
> > > > */
> > > > void drm_connector_oob_hotplug_event(struct fwnode_handle *connector_fwnode,
> > > > - enum drm_connector_status status)
> > > > + enum drm_connector_status status,
> > > > + bool irq_hpd)
> > > I find the "IRQ HPD" naming always confusing, even if I'm somewhat familiar
> > > with DP, but if someone has mainly worked on HDMI, I'm sure it's even worse.
> > >
> > > Can we define this a bit more precisely? Is 'irq_hpd' only for displayport?
> > > If so, perhaps 'dp_irq_hpd' or 'displayport_irq_hpd'. I might even call it
> > > 'dp_hpd_pulse', but maybe that's not good as the spec talks about HPD pulse
> > > for both short and long ones (although in the kernel doc you just write "HPD
> > > pulse")... The kernel doc could be expanded a bit to make it clear what this
> > > flag indicates.
> >
> > I attempted to stay away from defining a DP-specific flag, keeping it
> > generic enough. HDMI is pretty close (IMO) to requiring separate flag in
>
> If it's not specifically the DP IRQ HPD, then we need to define what it
> means. I tried to think what it would mean with HDMI, but I didn't come up
> with anything.
I might be mistaken, but I had someting like HEAC HPD / EDID status
changes in mind (or HDCP-triggered HPD status changes). But here I
admit, I hadn't checked if it is actually applicable or not.
Anyway, for e.g. DVI or VGA that means nothing. But, my point really is
to abstain from defining someting as DP-only in the top-level API.
>
> > Linux. Likewise I'd rather not use "pulse". The DP AltMode defines a bit
> > in the VDO rather than a pulse.
> >
> > Anyway, if irq_hpd doesn't sound precise enough, what about "bool
> > extra_irq"? This would convey that this is the extra hpd-related IRQ,
> > but it would also be obvious that it's not related to the HPD pin
> > itself.
> We'd still need to define what exactly it means. I think it might be better
> to just define it as the DP IRQ HPD, as then the meaning is clear.
>
> Also, would an enum flags parameter be better than a bool parameter?
Maybe not enum, but u32 param. Then it can become:
@extra_status: additional type-specific information provided by the sink
without changing the HPD state
void drm_connector_oob_hotplug_event(..., u32 extra_status);
/* DP short HPD pulse or corresponding AltMode flag */
#define DRM_CONNECTOR_OOB_DP_IRQ_HPD BIT(0)
/* DP long HPD pulse, debounced XXX: do we need this? */
#define DRM_CONNECTOR_OOB_DP_REPLUG BIT(1)
For HDMI we might want to define:
/* HDMI 1.4b 8.5, HPD pulse */
#define DRM_CONNECTOR_OOB_HDMI_REPLUG BIT(0)
Or might not, 100ms is long enough for all debouncers.
For HDMI we potentially have another source of OOB events, CDC-messages
from CEC controller. I have not looked in the details of the HEAC 3.
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v7 3/4] KVM: arm64: PMU: Introduce FIXED_COUNTERS_ONLY
From: Marc Zyngier @ 2026-04-20 9:51 UTC (permalink / raw)
To: Akihiko Odaki
Cc: Oliver Upton, Joey Gouly, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon, Kees Cook, Gustavo A. R. Silva,
Paolo Bonzini, Jonathan Corbet, Shuah Khan, linux-arm-kernel,
kvmarm, linux-kernel, linux-hardening, devel, kvm, linux-doc,
linux-kselftest
In-Reply-To: <06c6664c-7f0c-47b2-babf-ba2a541fd9f2@rsg.ci.i.u-tokyo.ac.jp>
On Mon, 20 Apr 2026 09:36:16 +0100,
Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> wrote:
>
> On 2026/04/20 2:19, Marc Zyngier wrote:
> > On Sat, 18 Apr 2026 09:14:25 +0100,
> > Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> wrote:
> >>
> >> On a heterogeneous arm64 system, KVM's PMU emulation is based on the
> >> features of a single host PMU instance. When a vCPU is migrated to a
> >> pCPU with an incompatible PMU, counters such as PMCCNTR_EL0 stop
> >> incrementing.
> >>
> >> Although this behavior is permitted by the architecture, Windows does
> >> not handle it gracefully and may crash with a division-by-zero error.
> >>
> >> The current workaround requires VMMs to pin vCPUs to a set of pCPUs
> >> that share a compatible PMU. This is difficult to implement correctly in
> >> QEMU/libvirt, where pinning occurs after vCPU initialization, and it
> >> also restricts the guest to a subset of available pCPUs.
> >>
> >> Introduce the KVM_ARM_VCPU_PMU_V3_FIXED_COUNTERS_ONLY attribute to
> >> create a "fixed-counters-only" PMU. When set, KVM exposes a PMU that is
> >> compatible with all pCPUs but that does not support programmable
> >> event counters which may have different feature sets on different PMUs.
> >>
> >> This allows Windows guests to run reliably on heterogeneous systems
> >> without crashing, even without vCPU pinning, and enables VMMs to
> >> schedule vCPUs across all available pCPUs, making full use of the host
> >> hardware.
> >>
> >> Much like KVM_ARM_VCPU_PMU_V3_IRQ and other read-write attributes, this
> >> attribute provides a getter that facilitates kernel and userspace
> >> debugging/testing.
> >
> > OK, so that's the sales pitch. But how is it implemented? I would like
> > to be able to read a high-level description of the implementation
> > trade-offs.
>
> Implementation-wise it is very trivial. Essentially the following
> addition in kvm_arm_pmu_v3_get_attr() is the entire implementation:
> + case KVM_ARM_VCPU_PMU_V3_FIXED_COUNTERS_ONLY:
> + if (test_bit(KVM_ARCH_FLAG_PMU_V3_FIXED_COUNTERS_ONLY,
> &vcpu->kvm->arch.flags))
> + return 0;
>
> Both its functionality and code complexity is trivial. So we can argue that:
> - the functionality is too trivial to be useful or
> - the interface/implementation complexity is so trivial that it does not
> incur maintenance burden
>
> In this case the selftest uses the getter so I was more inclined to
> have it, but adding one just for the selftest sounds too ad-hoc, so
> here I looked into other attributes to ensure that it was not
> introducing inconsistency with existing interfaces.
>
> As the result, I found there are other read-write attributes; in fact
> there are more read-write attributes than write-only ones.
You're completely missing the point. I'm referring to the whole of the
commit message, which is more of a marketing slide than a technical
description.
I really don't care about the getter at this stage, which while
pointless, does not make things more awful than they already are.
>
> >
> >>
> >> Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
> >> ---
> >> Documentation/virt/kvm/devices/vcpu.rst | 29 ++++++
> >> arch/arm64/include/asm/kvm_host.h | 2 +
> >> arch/arm64/include/uapi/asm/kvm.h | 1 +
> >> arch/arm64/kvm/arm.c | 1 +
> >> arch/arm64/kvm/pmu-emul.c | 155 +++++++++++++++++++++++---------
> >> include/kvm/arm_pmu.h | 2 +
> >> 6 files changed, 147 insertions(+), 43 deletions(-)
> >>
> >> diff --git a/Documentation/virt/kvm/devices/vcpu.rst b/Documentation/virt/kvm/devices/vcpu.rst
> >> index 60bf205cb373..e0aeb1897d77 100644
> >> --- a/Documentation/virt/kvm/devices/vcpu.rst
> >> +++ b/Documentation/virt/kvm/devices/vcpu.rst
> >> @@ -161,6 +161,35 @@ explicitly selected, or the number of counters is out of range for the
> >> selected PMU. Selecting a new PMU cancels the effect of setting this
> >> attribute.
> >> +1.6 ATTRIBUTE: KVM_ARM_VCPU_PMU_V3_FIXED_COUNTERS_ONLY
> >> +------------------------------------------------------
> >> +
> >> +:Parameters: no additional parameter in kvm_device_attr.addr
> >> +
> >> +:Returns:
> >> +
> >> + ======= =====================================================
> >> + -EBUSY Attempted to set after initializing PMUv3 or running
> >> + VCPU, or attempted to set for the first time after
> >> + setting an event filter
> >> + -ENXIO Attempted to get before setting
> >> + -ENODEV Attempted to set while PMUv3 not supported
> >> + ======= =====================================================
> >> +
> >> +If set, PMUv3 will be emulated without programmable event counters. The VCPU
> >> +will use any compatible hardware PMU. This attribute is particularly useful on
> >
> > Not quite "any PMU". It will use *the* PMU of the physical CPU,
> > irrespective of the implementation.
>
> I think:
>
> - this comment
> - one on the KVM_EXIT_FAIL_ENTRY_CPU_UNSUPPORTED note
> - one on kvm_pmu_create_perf_event()
> - and one on kvm_arm_pmu_v3_set_pmu_fixed_counters_only()
>
> All boil down into one question: will it support all possible CPUs, or
> will it support a subset? Let me answer here:
>
> This patch is written to support a subset instead of all possible
> CPUs. If a pCPU does not have a compatible PMU, the pCPU will not be
> supported and cause KVM_EXIT_FAIL_ENTRY_CPU_UNSUPPORTED.
This is not a thing. Either *all* the CPUs have a PMU that can be used
for KVM, or PMU support is not offered to guests. That's a hard line
in the sand. And the code already upholds this by checking the
sanitised PMUVer field.
>
> This patch does not enforce all possible CPUs are covered by the
> compatible PMUs. Theoretically speaking,
> kvm_arm_pmu_get_pmuver_limit() enables the PMU emulation when real
> PMUv3 hardware covers all possible CPUs *or* the relevant registers
> can be trapped with IMPDEF, so some pCPU may not have a compatible PMU
> and only provide the IMPDEF trapping.
How is that possible? Please describe the case where that can happen,
and I will make sure that such a system stops booting. The intent is
definitely that that:
- for early CPUs, we take the minimal capability of all CPUs
- for late CPUs, either they match at least the capability recorded by
early CPUs, or they don't boot.
> Practically, I don't think any sane configuration will ever have such
> a subset support, so we can explicitly enforce all possible CPUs are
> covered by the compatible PMUs if desired.
That's not just desired. This is a requirement. And it is already
enforced AFAICS.
>
> >
> >> +heterogeneous systems where different hardware PMUs cover different physical
> >> +CPUs. The compatibility of hardware PMUs can be checked with
> >> +KVM_ARM_VCPU_PMU_V3_SET_PMU. All VCPUs in a VM share this attribute. It isn't
> >> +possible to set it for the first time if a PMU event filter is already present.
> >
> > "for the first time" gives the impression that it will work if you try
> > again. I'd rather we say that "This feature is incompatible with the
> > existence of a PMU event filter".
>
> The following sequence will work:
> 1. Set KVM_ARM_VCPU_PMU_V3_FIXED_COUNTERS_ONLY
> 2. Set KVM_ARM_VCPU_PMU_V3_FILTER
> 3. Set KVM_ARM_VCPU_PMU_V3_FIXED_COUNTERS_ONLY
>
> This is to make the behavior conistent with KVM_ARM_VCPU_PMU_V3_SET_PMU.
I don't think this is correct. Filtering is completely at odds with
this patch, and I don't want to have to reason about the combination.
[...]
> >> + int i;
> >> +
> >> + for_each_set_bit(i, &mask, 32) {
> >> + pmc = kvm_vcpu_idx_to_pmc(vcpu, i);
> >> + if (!pmc->perf_event)
> >> + continue;
> >> +
> >> + cpu_pmu = to_arm_pmu(pmc->perf_event->pmu);
> >> + if (!cpumask_test_cpu(vcpu->cpu, &cpu_pmu->supported_cpus)) {
> >> + kvm_make_request(KVM_REQ_RELOAD_PMU, vcpu);
> >> + break;
> >> + }
> >> + }
> >> +}
> >> +
> >
> > Why do we need to inflict this on VMs that do not have the fixed
> > counter restriction?
>
> This function is to re-create the perf_event in case the current
> perf_event does not support the pCPU because e.g., the pCPU is a
> E-core while the perf_event only covers the P-cores.
That's not what I meant. This code is only here to support the
fixed-function feature. It makes no sense outside of it, because *we
don't support counter migration across implementations*.
So what's the purpose of this stuff for the normal KVM setup?
>
> >
> > And even then, all you have to reconfigure is the cycle counter. So
> > why the loop? All we want to find out is whether the cycle counter is
> > instantiated on the PMU that matches the current CPU.
>
> I just wanted to avoid hardcoding assumptions on the fixed
> counter(s). FEAT_PMUv3_ICNTR will be naturaly handled with a loop, for
> example.
Well, not that loop, since ICNTR is counter 32. So please let's stop
the nonsense and only add what is required?
[...]
> >> +
> >> clear_bit(KVM_ARCH_FLAG_PMU_V3_FIXED_COUNTERS_ONLY,
> >> &kvm->arch.flags);
> >
> > Why does this need to be cleared? I'd rather we make sure it is never
> > set the first place.
>
> KVM_ARM_VCPU_PMU_V3_SET_PMU and
> KVM_ARM_VCPU_PMU_V3_FIXED_COUNTERS_ONLY can be set on the same
> VCPU. The last KVM_ARM_VCPU_PMU_V3_SET_PMU or
> KVM_ARM_VCPU_PMU_V3_FIXED_COUNTERS_ONLY setting will be effective.
>
> A VMM may try set these attributes to check if the setting is
> supported. For example, the RFC QEMU patch first uses
> KVM_ARM_VCPU_PMU_V3_SET_PMU to find a compatible PMU that covers all
> pCPUs, and then falls back to
> KVM_ARM_VCPU_PMU_V3_FIXED_COUNTERS_ONLY. The order of such probing is
> up to the VMM.
KVM_ARM_VCPU_PMU_V3_SET_PMU is not a probing mechanism. You must probe
the PMUs by looking in /sys/bus/event_source/devices/, like kvmtool
does.
So there is no reason to support this stuff, and the two flags should
be made mutually exclusive.
[...]
> >>
> >
> > In conclusion, I find this patch to be rather messy. For a start, it
> > needs to be split in at least 5 patches:
> >
> > - at least two for the refactoring
> > - one for the PMU core changes
> > - one for the UAPI
> > - one for documentation
>
> That clarifies the expected granurarity of patches. The next version
> will be in that layout, perhaps with more patches if an additional
> change. Thanks for the guidance.
>
> >
> > I'd also like some clarification on how this is intended to work if we
> > enable FEAT_PMUv3_ICNTR, because the definition seems to be designed
> > to encompass all fixed-function counters, and I expect this to grow
> > over time.
>
> Indeed the UAPI was designed to encompass all fixed-function counters
> as suggested by Oliver.
>
> To support the UAPI, the implementation avoids hardcoding the
> assumption on the fixed counter(s). FEAT_PMUv3_INCTR will be naturaly
> supported once the common code is properly updated (i.e., the size of
> the event counter bitmask is grown the corresponding registers are
> wired up with a proper check of the feature.)
>
> I expect migration will be handled with the conventional register
> getters and setters, but please share if you have a concern.
At the very least I want to see some documentation explaining that.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v3 6/8] arm64/module, sframe: Add sframe support for modules.
From: Jens Remus @ 2026-04-20 9:54 UTC (permalink / raw)
To: Dylan Hatch, Roman Gushchin, Weinan Liu, Will Deacon,
Josh Poimboeuf, Indu Bhagat, Peter Zijlstra, Steven Rostedt,
Catalin Marinas, Jiri Kosina, Indu Bhagat
Cc: Mark Rutland, Prasanna Kumar T S M, Puranjay Mohan, Song Liu,
joe.lawrence, linux-toolchains, linux-kernel, live-patching,
linux-arm-kernel, Heiko Carstens
In-Reply-To: <20260406185000.1378082-7-dylanbhatch@google.com>
On 4/6/2026 8:49 PM, Dylan Hatch wrote:
> Add sframe table to mod_arch_specific and support sframe PC lookups when
> an .sframe section can be found on incoming modules.
>
> Signed-off-by: Dylan Hatch <dylanbhatch@google.com>
> Signed-off-by: Weinan Liu <wnliu@google.com>
> diff --git a/kernel/unwind/sframe.c b/kernel/unwind/sframe.c
> +void sframe_module_init(struct module *mod, void *sframe, size_t sframe_size,
> + void *text, size_t text_size)
> +{
> + struct sframe_section sec;
> +
I think sec should better be explicitly zero-initialized, as it is done
in sframe_add_section() for user space. IIUC likewise is not needed in
init_sframe_table() for the kernel vmlinux, as static variables are
zero-initialized.
memset(&sec, 0, sizeof(sec));
> + sec.sec_type = SFRAME_KERNEL;
> + sec.sframe_start = (unsigned long)sframe;
> + sec.sframe_end = (unsigned long)sframe + sframe_size;
> + sec.text_start = (unsigned long)text;
> + sec.text_end = (unsigned long)text + text_size;
> +
> + if (WARN_ON(sframe_read_header(&sec)))
> + return;
> +
> + mod->arch.sframe_sec = sec;
> + mod->arch.sframe_init = true;
> +}
Regards,
Jens
--
Jens Remus
Linux on Z Development (D3303)
jremus@de.ibm.com / jremus@linux.ibm.com
IBM Deutschland Research & Development GmbH; Vorsitzender des Aufsichtsrats: Wolfgang Wendt; Geschäftsführung: David Faller; Sitz der Gesellschaft: Ehningen; Registergericht: Amtsgericht Stuttgart, HRB 243294
IBM Data Privacy Statement: https://www.ibm.com/privacy/
^ permalink raw reply
* Re: [PATCH v2 0/2] Add support for Amediatech X98Q (Amlogic S905W2)
From: Ferass El Hafidi @ 2026-04-20 9:56 UTC (permalink / raw)
To: linux-amlogic, christian.koever-draxl, robh, krzk+dt, conor+dt,
neil.armstrong, khilman
Cc: jbrunet, martin.blumenstingl, funderscore, devicetree,
linux-kernel, linux-arm-kernel, linux-amlogic,
christian.koever-draxl
In-Reply-To: <20260420061854.5421-1-christian.koever-draxl@student.uibk.ac.at>
Hi,
On Mon, 20 Apr 2026 06:18, christian.koever-draxl@student.uibk.ac.at wrote:
>From: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
>
>Supported features:
>- 1GB/2GB RAM (via U-Boot memory fixup)
>- 10/100 Ethernet (Internal PHY)
>- eMMC and SD card storage
>- PWM-based CPU voltage regulation
>- UART (Serial console)
>
>Changes in v2:
>- Split dt-bindings and dts changes into separate patches.
>- Updated model string to match documented vendor prefix.
>- Put vddio_sd states array in a single line.
>- Added a clarifying comment for the unsupported Amlogic W150S1 Wi-Fi module.
>
>Notes:
>- The console uses uart_b at 921600 baud.
>- Verified memory via /proc/device-tree; U-Boot patches the node to around 2GB.
>- Tested on the 2GB RAM plus 16GB eMMC variant.
>
Sorry I was not clear, but the patches need to have a description.
checkpatch.pl should complain about this. Please use it to check that
your patches are in the correct format.
See the kernel docs about sending patches here:
https://docs.kernel.org/process/submitting-patches.html#describe-your-changes
>Christian Stefan Kövér-Draxl (2):
> dt-bindings: arm: amlogic: add X98Q compatible
> arm64: dts: amlogic: add support for X98Q
>
> .../devicetree/bindings/arm/amlogic.yaml | 7 +
> arch/arm64/boot/dts/amlogic/Makefile | 1 +
> .../boot/dts/amlogic/meson-s4-s905w2-x98q.dts | 250 ++++++++++++++++++
> 3 files changed, 258 insertions(+)
> create mode 100644 arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts
>
>--
>2.53.0
--
Best regards,
Ferass
^ permalink raw reply
* Re: [PATCH 00/30] KVM: arm64: Add support for protected guest memory with pKVM
From: Will Deacon @ 2026-04-20 10:00 UTC (permalink / raw)
To: Pavan Kondeti
Cc: kvmarm, linux-arm-kernel, Marc Zyngier, Oliver Upton, Joey Gouly,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Quentin Perret,
Fuad Tabba, Vincent Donnefort, Mostafa Saleh
In-Reply-To: <3f52367b-f927-4d4d-9df3-bcd8cd954d47@quicinc.com>
On Mon, Apr 20, 2026 at 01:32:03PM +0530, Pavan Kondeti wrote:
> Hi Will,
>
> On Mon, Jan 05, 2026 at 03:49:08PM +0000, Will Deacon wrote:
> > Hi folks,
> >
> > Although pKVM has been shipping in Android kernels for a while now,
> > protected guest (pVM) support has been somewhat languishing upstream.
> > This has partly been because we've been waiting for guest_memfd() but
> > also because it hasn't been clear how to expose pVMs to userspace (which
> > is necessary for testing) without getting everything in place beforehand.
> > This has led to frustration on both sides of the fence [1] and so this
> > patch series attempts to get things moving again by exposing pVM
> > features in an incremental fashion based on top of anonymous memory,
> > which is what we have been using in Android. The big difference between
> > this series and the Android implementation is the graceful handling of
> > host stage-2 faults arising from accesses made using kernel mappings.
> > The hope is that this will unblock pKVM upstreaming efforts while the
> > guest_memfd() work continues to evolve.
> >
> > Specifically, this patch series implements support for protected guest
> > memory with pKVM, where pages are unmapped from the host as they are
> > faulted into the guest and can be shared back from the guest using pKVM
> > hypercalls. Protected guests are created using a new machine type
> > identifier and can be booted to a shell using the kvmtool patches
> > available at [2], which finally means that we are able to test the pVM
> > logic in pKVM. Since this is an incremental step towards full isolation
> > from the host (for example, the CPU register state and DMA accesses are
> > not yet isolated), creating a pVM requires a developer Kconfig option to
> > be enabled in addition to booting with 'kvm-arm.mode=protected' and
> > results in a kernel taint.
> >
>
> Good to see Protected VM support in upstream w/ pKVM.
>
> We (Qualcomm) have been trying to resume Gunyah upstreaming [1] efforts
> for some time but the path to re-use guest_memfd is not straight forward as
> guest_memfd is tightly coupled with KVM. While the efforts to use it for
> pKVM is pending and refactoring to make it use outside KVM is not
> happening anytime soon, we plan to send Gunyah series similar to how
> this series is dealt with pages lent/donated to the Guest. Please let us
> know if you have any suggestions/comments for us.
The major problem I see with this is that the host/hyp interface for
handling stage-2 faults is internal to pKVM. The exception is injected
back into the host using a funky ESR encoding and the hypercall used
to forcefully reclaim the page is not ABI. I have no appetite for
standardising these mechanisms (the flexibility is one of pKVM's big
advantages) but I also do not want to complicate EL1 fault handling path
with hypervisor-specific crap that we have to maintain forever.
Will
^ permalink raw reply
* [PATCH V3] dmaengine: imx-sdma: Fix SPBA bus detection on multi-SPBA platforms
From: Shengjiu Wang @ 2026-04-20 10:08 UTC (permalink / raw)
To: vkoul, Frank.Li, s.hauer, kernel, festevam, dmaengine, imx,
linux-arm-kernel, linux-kernel
i.MX8M platforms have multiple SPBA buses under different AIPS buses.
The current code searches the entire device tree and returns the first
SPBA bus found, which may not be under the same AIPS bus as the SDMA
controller.
This breaks SDMA P2P transfers because the SDMA script needs to know
if peripherals are on SPBA or AIPS to configure watermark levels
correctly. Using the wrong SPBA bus causes DMA timeouts and transfer
failures.
Fix by searching for the SPBA bus under the SDMA's parent node (AIPS)
first, then falling back to a global search for backward compatibility.
Example device tree showing the issue:
aips1 {
spba1 { sai@...; }; /* Correct SPBA for sdma1 */
sdma1@...;
};
aips2 {
spba2 { uart@...; }; /* Wrong SPBA - found first by old code */
};
Fixes: 8391ecf465ec ("dmaengine: imx-sdma: Add device to device support")
Cc: stable@vger.kernel.org
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
---
changs in v3:
- add fallback to a global search for backward compatibility, which is
to address comments from sashiko.dev
- update commit subject and commit message
- add comments in code.
- add Cc stable tag
- Don't add Frank's RB on v2 as there are several other changes.
changes in v2:
- add fixes tag
- use __free(device_node) for auto release.
drivers/dma/imx-sdma.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 3d527883776b..592705af2319 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -2364,7 +2364,18 @@ static int sdma_probe(struct platform_device *pdev)
return dev_err_probe(&pdev->dev, ret,
"failed to register controller\n");
- spba_bus = of_find_compatible_node(NULL, NULL, "fsl,spba-bus");
+ /*
+ * On i.MX8M platforms with multiple SPBA buses, we need to find
+ * the SPBA bus that's under the same AIPS bus as this SDMA controller.
+ * First check the SDMA's parent (AIPS bus) for a child SPBA bus.
+ * If not found, fall back to searching the entire device tree for
+ * backward compatibility with older platforms.
+ */
+ struct device_node *sdma_parent_np __free(device_node) = of_get_parent(np);
+
+ spba_bus = of_get_compatible_child(sdma_parent_np, "fsl,spba-bus");
+ if (!spba_bus)
+ spba_bus = of_find_compatible_node(NULL, NULL, "fsl,spba-bus");
ret = of_address_to_resource(spba_bus, 0, &spba_res);
if (!ret) {
sdma->spba_start_addr = spba_res.start;
--
2.34.1
^ permalink raw reply related
* tpm: spi: do not call blocking ops when !TASK_RUNNING; during shutdown
From: Stefan Wahren @ 2026-04-20 10:25 UTC (permalink / raw)
To: Peter Huewe, Jarkko Sakkinen, Jason Gunthorpe
Cc: linux-arm-kernel, linux-integrity, kernel, Frank Li, Sascha Hauer,
imx@lists.linux.dev
Hi,
we use a custom i.MX93 board, which based on Phytec Phycore i.MX93 with
a TPM connected via SPI. If I enable CONFIG_DEBUG_ATOMIC_SLEEP=y in our
kernel config with mainline kernel 6.18.23 and reboot our board, I will
get the following warning:
[ 43.287416] do not call blocking ops when !TASK_RUNNING; state=1 set
at [<000000005a2107f3>] prepare_to_wait_event+0x54/0x14c
[ 43.299009] WARNING: CPU: 0 PID: 1 at kernel/sched/core.c:8857
__might_sleep+0x74/0x7c
[ 43.306920] Modules linked in: polyval_ce flexcan rtc_rv3028 can_dev
mse102x phy_can_transceiver fuse autofs4
[ 43.316838] CPU: 0 UID: 0 PID: 1 Comm: systemd-shutdow Not tainted
6.18.23-00002-g626a194342f0 #2 PREEMPT
[ 43.326471] Hardware name: chargebyte Charge SOM Evaluation Kit (DT)
[ 43.332807] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS
BTYPE=--)
[ 43.339757] pc : __might_sleep+0x74/0x7c
[ 43.343675] lr : __might_sleep+0x74/0x7c
[ 43.347592] sp : ffff800081aab720
[ 43.350894] x29: ffff800081aab720 x28: 0000000000000080 x27:
ffff000000235880
[ 43.358018] x26: ffff800081897000 x25: 0000000000000018 x24:
0000000000000000
[ 43.365142] x23: ffff800081aab907 x22: 0000000000000000 x21:
0000000000000080
[ 43.372266] x20: 000000000000010f x19: ffff80008131cd00 x18:
0000000000000001
[ 43.379390] x17: 0000000000000000 x16: 000000000017d600 x15:
ffff00003fda4680
[ 43.386514] x14: 0000000000017e01 x13: 0000000000000209 x12:
0000000000000000
[ 43.393638] x11: 00000000000000c0 x10: 0000000000000950 x9 :
ffff800081aab5a0
[ 43.400762] x8 : ffff0000000d89b0 x7 : ffff00003fda3f00 x6 :
000000013417d29a
[ 43.407886] x5 : 0000000000000000 x4 : 0000000000000002 x3 :
0000000000000010
[ 43.415010] x2 : 0000000000000000 x1 : 0000000000000000 x0 :
ffff0000000d8000
[ 43.422135] Call trace:
[ 43.424570] __might_sleep+0x74/0x7c (P)
[ 43.428487] mutex_lock+0x24/0x80
[ 43.431797] spi_bus_lock+0x20/0x50
[ 43.435281] tpm_tis_spi_transfer_full+0x70/0x2c4
[ 43.439979] tpm_tis_spi_read_bytes+0x3c/0x48
[ 43.444321] tpm_tis_status+0x58/0xf8
[ 43.447978] wait_for_tpm_stat_cond+0x30/0x90
[ 43.452329] wait_for_tpm_stat+0x1cc/0x2e0
[ 43.456419] tpm_tis_send_data+0xdc/0x334
[ 43.460423] tpm_tis_send_main+0x74/0x160
[ 43.464427] tpm_tis_send+0xd4/0x13c
[ 43.467998] tpm_transmit+0xc4/0x3c4
[ 43.471569] tpm_transmit_cmd+0x38/0xd4
[ 43.475399] tpm2_shutdown+0x6c/0xa4
[ 43.478970] tpm_class_shutdown+0x60/0x88
[ 43.482974] device_shutdown+0x130/0x25c
[ 43.486891] kernel_restart+0x44/0xa4
[ 43.490549] __do_sys_reboot+0x114/0x254
[ 43.494466] __arm64_sys_reboot+0x24/0x30
[ 43.498470] invoke_syscall+0x48/0x10c
[ 43.502214] el0_svc_common.constprop.0+0x40/0xe0
[ 43.506911] do_el0_svc+0x1c/0x28
[ 43.510222] el0_svc+0x34/0xec
[ 43.513273] el0t_64_sync_handler+0xa0/0xe4
[ 43.517441] el0t_64_sync+0x198/0x19c
Best regards
^ permalink raw reply
* Re: [RFC PATCH 1/4] security: ima: move ima_init into late_initcall_sync
From: Jonathan McDowell @ 2026-04-20 10:32 UTC (permalink / raw)
To: Yeoreum Yun
Cc: linux-security-module, linux-kernel, linux-integrity,
linux-arm-kernel, kvmarm, paul, jmorris, serge, zohar,
roberto.sassu, dmitry.kasatkin, eric.snowberg, peterhuewe, jarkko,
jgg, sudeep.holla, maz, oupton, joey.gouly, suzuki.poulose,
yuzenghui, catalin.marinas, will
In-Reply-To: <20260417175759.3191279-2-yeoreum.yun@arm.com>
On Fri, Apr 17, 2026 at 06:57:56PM +0100, Yeoreum Yun wrote:
>To generate the boot_aggregate log in the IMA subsystem with TPM PCR values,
>the TPM driver must be built as built-in and
>must be probed before the IMA subsystem is initialized.
>
>However, when the TPM device operates over the FF-A protocol using
>the CRB interface, probing fails and returns -EPROBE_DEFER if
>the tpm_crb_ffa device — an FF-A device that provides the communication
>interface to the tpm_crb driver — has not yet been probed.
>
>To ensure the TPM device operating over the FF-A protocol with
>the CRB interface is probed before IMA initialization,
>the following conditions must be met:
>
> 1. The corresponding ffa_device must be registered,
> which is done via ffa_init().
>
> 2. The tpm_crb_driver must successfully probe this device via
> tpm_crb_ffa_init().
>
> 3. The tpm_crb driver using CRB over FF-A can then
> be probed successfully. (See crb_acpi_add() and
> tpm_crb_ffa_init() for reference.)
>
>Unfortunately, ffa_init(), tpm_crb_ffa_init(), and crb_acpi_driver_init() are
>all registered with device_initcall, which means crb_acpi_driver_init() may
>be invoked before ffa_init() and tpm_crb_ffa_init() are completed.
>
>When this occurs, probing the TPM device is deferred.
>However, the deferred probe can happen after the IMA subsystem
>has already been initialized, since IMA initialization is performed
>during late_initcall, and deferred_probe_initcall() is performed
>at the same level.
>
>To resolve this, move ima_init() into late_inicall_sync level
>so that let IMA not miss TPM PCR value when generating boot_aggregate
>log though TPM device presents in the system.
>
>Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
Awesome. This fixes the problems I saw with an SPI TPM on an NVIDIA
GB200 system and reported in
https://lore.kernel.org/linux-integrity/aYXEepLhUouN5f99@earth.li/
Reviewed-by: Jonathan McDowell <noodles@meta.com>
Tested-by: Jonathan McDowell <noodles@meta.com>
>---
> include/linux/lsm_hooks.h | 2 ++
> security/integrity/ima/ima_main.c | 2 +-
> security/lsm_init.c | 13 +++++++++++--
> 3 files changed, 14 insertions(+), 3 deletions(-)
>
>diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
>index d48bf0ad26f4..88fe105b7f00 100644
>--- a/include/linux/lsm_hooks.h
>+++ b/include/linux/lsm_hooks.h
>@@ -166,6 +166,7 @@ enum lsm_order {
> * @initcall_fs: LSM callback for fs_initcall setup, optional
> * @initcall_device: LSM callback for device_initcall() setup, optional
> * @initcall_late: LSM callback for late_initcall() setup, optional
>+ * @initcall_late_sync: LSM callback for late_initcall_sync() setup, optional
> */
> struct lsm_info {
> const struct lsm_id *id;
>@@ -181,6 +182,7 @@ struct lsm_info {
> int (*initcall_fs)(void);
> int (*initcall_device)(void);
> int (*initcall_late)(void);
>+ int (*initcall_late_sync)(void);
> };
>
> #define DEFINE_LSM(lsm) \
>diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
>index 1d6229b156fb..ace280fa3212 100644
>--- a/security/integrity/ima/ima_main.c
>+++ b/security/integrity/ima/ima_main.c
>@@ -1320,5 +1320,5 @@ DEFINE_LSM(ima) = {
> .order = LSM_ORDER_LAST,
> .blobs = &ima_blob_sizes,
> /* Start IMA after the TPM is available */
>- .initcall_late = init_ima,
>+ .initcall_late_sync = init_ima,
> };
>diff --git a/security/lsm_init.c b/security/lsm_init.c
>index 573e2a7250c4..4e5c59beb82a 100644
>--- a/security/lsm_init.c
>+++ b/security/lsm_init.c
>@@ -547,13 +547,22 @@ device_initcall(security_initcall_device);
> * security_initcall_late - Run the LSM late initcalls
> */
> static int __init security_initcall_late(void)
>+{
>+ return lsm_initcall(late);
>+}
>+late_initcall(security_initcall_late);
>+
>+/**
>+ * security_initcall_late_sync - Run the LSM late initcalls sync
>+ */
>+static int __init security_initcall_late_sync(void)
> {
> int rc;
>
>- rc = lsm_initcall(late);
>+ rc = lsm_initcall(late_sync);
> lsm_pr_dbg("all enabled LSMs fully activated\n");
> call_blocking_lsm_notifier(LSM_STARTED_ALL, NULL);
>
> return rc;
> }
>-late_initcall(security_initcall_late);
>+late_initcall_sync(security_initcall_late_sync);
>--
>LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}
>
>
J.
--
] https://www.earth.li/~noodles/ [] "Do I scare you?" "No." "Do you [
] PGP/GPG Key @ the.earth.li [] want me to?" -- Wayne's World. [
] via keyserver, web or email. [] [
] RSA: 4096/0x94FA372B2DA8B985 [] [
^ permalink raw reply
* Re: [RFC PATCH 4/4] firmware: arm_ffa: check pkvm initailised when initailise ffa driver
From: Will Deacon @ 2026-04-20 10:42 UTC (permalink / raw)
To: Yeoreum Yun
Cc: Marc Zyngier, linux-security-module, linux-kernel,
linux-integrity, linux-arm-kernel, kvmarm, paul, jmorris, serge,
zohar, roberto.sassu, dmitry.kasatkin, eric.snowberg, peterhuewe,
jarkko, jgg, sudeep.holla, oupton, joey.gouly, suzuki.poulose,
yuzenghui, catalin.marinas, sebastianene
In-Reply-To: <aeXxCe4hdizdQbFD@e129823.arm.com>
[+Seb for the pKVM FFA bits]
On Mon, Apr 20, 2026 at 10:25:29AM +0100, Yeoreum Yun wrote:
> > On Sun, Apr 19, 2026 at 12:12:44PM +0100, Yeoreum Yun wrote:
> > > > On Sat, 18 Apr 2026 11:34:30 +0100,
> > > > Yeoreum Yun <yeoreum.yun@arm.com> wrote:
> > > > >
> > > > > > > @@ -2035,6 +2037,16 @@ static int __init ffa_init(void)
> > > > > > > u32 buf_sz;
> > > > > > > size_t rxtx_bufsz = SZ_4K;
> > > > > > >
> > > > > > > + /*
> > > > > > > + * When pKVM is enabled, the FF-A driver must be initialized
> > > > > > > + * after pKVM initialization. Otherwise, pKVM cannot negotiate
> > > > > > > + * the FF-A version or obtain RX/TX buffer information,
> > > > > > > + * which leads to failures in FF-A calls.
> > > > > > > + */
> > > > > > > + if (IS_ENABLED(CONFIG_KVM) && is_protected_kvm_enabled() &&
> > > > > > > + !is_kvm_arm_initialised())
> > > > > > > + return -EPROBE_DEFER;
> > > > > > > +
> > > > > >
> > > > > > That's still fundamentally wrong: pkvm is not ready until
> > > > > > finalize_pkvm() has finished, and that's not indicated by
> > > > > > is_kvm_arm_initialised().
> > > > >
> > > > > Thanks. I miss the TSC bit set in here.
> > > >
> > > > That's the least of the problems. None of the infrastructure is in
> > > > place at this stage...
> > > >
> > > > > IMHO, I'd like to make an new state check function --
> > > > > is_pkvm_arm_initialised() so that ff-a driver to know whether
> > > > > pkvm is initialised.
> > > >
> > > > Doesn't sound great, TBH.
> > > >
> > > > > or any other suggestion?
> > > >
> > > > Instead of adding more esoteric predicates, I'd rather you build on an
> > > > existing infrastructure. You have a dependency on KVM, use something
> > > > that is designed to enforce dependencies. Device links spring to mind
> > > > as something designed for that.
> > > >
> > > > Can you look into enabling this for KVM? If that's possible, then it
> > > > should be easy enough to delay the actual KVM registration after pKVM
> > > > is finalised.
> > >
> > > or what about some event notifier? Just like:
> >
> > This seems a bit over-engineered to me. Why don't you just split the
> > FF-A initialisation into two steps: an early part which does the version
> > negotiation and then a later part which can fit in with whatever
> > dependencies you have on the TPM?
>
> Sorry, I may have misunderstood your suggestion and
> I might be in missing your point.
>
> But, The issue here is that FFA_VERSION, FFA_RXTX_MAP, and
> FFA_PARTITION_INFO_GET, which are invoked from ffa_init()
> as part of early initialisation, must be trapped by pKVM.
>
> In other words, even the early part of the initialization,
> including version negotiation, needs to happen after pKVM
> is initialized.
>
> Because of this dependency, simply splitting the FF-A
> initialization into two phases within the driver does not
> seem sufficient, as it still requires knowing when pKVM
> has been initialized.
>
> Am I missing something?
Ah sorry, I mixed up the ordering of 'module_init' vs 'rootfs_initcall'
and thought you wanted to probe the version earlier. But then I'm still
confused because, prior to 0e0546eabcd6 ("firmware: arm_ffa: Change
initcall level of ffa_init() to rootfs_initcall"), ffa_init() was a
'device_initcall' which is still called earlier than finalize_pkvm().
Will
^ permalink raw reply
* Re: [RFC PATCH 4/4] firmware: arm_ffa: check pkvm initailised when initailise ffa driver
From: Yeoreum Yun @ 2026-04-20 10:56 UTC (permalink / raw)
To: Will Deacon
Cc: Marc Zyngier, linux-security-module, linux-kernel,
linux-integrity, linux-arm-kernel, kvmarm, paul, jmorris, serge,
zohar, roberto.sassu, dmitry.kasatkin, eric.snowberg, peterhuewe,
jarkko, jgg, sudeep.holla, oupton, joey.gouly, suzuki.poulose,
yuzenghui, catalin.marinas, sebastianene
In-Reply-To: <aeYDMEgWdt8F9jWb@willie-the-truck>
Hi Will,
> [+Seb for the pKVM FFA bits]
>
> On Mon, Apr 20, 2026 at 10:25:29AM +0100, Yeoreum Yun wrote:
> > > On Sun, Apr 19, 2026 at 12:12:44PM +0100, Yeoreum Yun wrote:
> > > > > On Sat, 18 Apr 2026 11:34:30 +0100,
> > > > > Yeoreum Yun <yeoreum.yun@arm.com> wrote:
> > > > > >
> > > > > > > > @@ -2035,6 +2037,16 @@ static int __init ffa_init(void)
> > > > > > > > u32 buf_sz;
> > > > > > > > size_t rxtx_bufsz = SZ_4K;
> > > > > > > >
> > > > > > > > + /*
> > > > > > > > + * When pKVM is enabled, the FF-A driver must be initialized
> > > > > > > > + * after pKVM initialization. Otherwise, pKVM cannot negotiate
> > > > > > > > + * the FF-A version or obtain RX/TX buffer information,
> > > > > > > > + * which leads to failures in FF-A calls.
> > > > > > > > + */
> > > > > > > > + if (IS_ENABLED(CONFIG_KVM) && is_protected_kvm_enabled() &&
> > > > > > > > + !is_kvm_arm_initialised())
> > > > > > > > + return -EPROBE_DEFER;
> > > > > > > > +
> > > > > > >
> > > > > > > That's still fundamentally wrong: pkvm is not ready until
> > > > > > > finalize_pkvm() has finished, and that's not indicated by
> > > > > > > is_kvm_arm_initialised().
> > > > > >
> > > > > > Thanks. I miss the TSC bit set in here.
> > > > >
> > > > > That's the least of the problems. None of the infrastructure is in
> > > > > place at this stage...
> > > > >
> > > > > > IMHO, I'd like to make an new state check function --
> > > > > > is_pkvm_arm_initialised() so that ff-a driver to know whether
> > > > > > pkvm is initialised.
> > > > >
> > > > > Doesn't sound great, TBH.
> > > > >
> > > > > > or any other suggestion?
> > > > >
> > > > > Instead of adding more esoteric predicates, I'd rather you build on an
> > > > > existing infrastructure. You have a dependency on KVM, use something
> > > > > that is designed to enforce dependencies. Device links spring to mind
> > > > > as something designed for that.
> > > > >
> > > > > Can you look into enabling this for KVM? If that's possible, then it
> > > > > should be easy enough to delay the actual KVM registration after pKVM
> > > > > is finalised.
> > > >
> > > > or what about some event notifier? Just like:
> > >
> > > This seems a bit over-engineered to me. Why don't you just split the
> > > FF-A initialisation into two steps: an early part which does the version
> > > negotiation and then a later part which can fit in with whatever
> > > dependencies you have on the TPM?
> >
> > Sorry, I may have misunderstood your suggestion and
> > I might be in missing your point.
> >
> > But, The issue here is that FFA_VERSION, FFA_RXTX_MAP, and
> > FFA_PARTITION_INFO_GET, which are invoked from ffa_init()
> > as part of early initialisation, must be trapped by pKVM.
> >
> > In other words, even the early part of the initialization,
> > including version negotiation, needs to happen after pKVM
> > is initialized.
> >
> > Because of this dependency, simply splitting the FF-A
> > initialization into two phases within the driver does not
> > seem sufficient, as it still requires knowing when pKVM
> > has been initialized.
> >
> > Am I missing something?
>
> Ah sorry, I mixed up the ordering of 'module_init' vs 'rootfs_initcall'
> and thought you wanted to probe the version earlier. But then I'm still
> confused because, prior to 0e0546eabcd6 ("firmware: arm_ffa: Change
> initcall level of ffa_init() to rootfs_initcall"), ffa_init() was a
> 'device_initcall' which is still called earlier than finalize_pkvm().
Right, and this is what I missed when writing patch
0e0546eabcd6 ("firmware: arm_ffa: Change initcall level of ffa_init() to rootfs_initcall").
and it still exists even if it's device call.
However, rather than changing ffa_init to rootfs_initcall, moving ima_init
to late_initcall_sync is a better approach, as it also addresses similar
issues for TPM devices that do not use FF-A. For this reason,
the FF-A-related changes were reverted.
As a result, patch 4/4 addresses an issue that existed independently of
0e0546eabcd6, as you pointed out.
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* Re: [PATCH v1 00/27] KVM: s390: Introduce arm64 KVM
From: Marc Zyngier @ 2026-04-20 10:57 UTC (permalink / raw)
To: Steffen Eiden
Cc: kvm, kvmarm, linux-arm-kernel, linux-kernel, linux-s390,
Andreas Grapentin, Arnd Bergmann, Catalin Marinas,
Christian Borntraeger, Claudio Imbrenda, David Hildenbrand,
Gautam Gala, Hendrik Brueckner, Janosch Frank, Joey Gouly,
Nina Schoetterl-Glausch, Oliver Upton, Paolo Bonzini,
Suzuki K Poulose, Ulrich Weigand, Will Deacon, Zenghui Yu
In-Reply-To: <20260402042125.3948963-1-seiden@linux.ibm.com>
Hi Steffen, s390 folks,
On Thu, 02 Apr 2026 05:20:56 +0100,
Steffen Eiden <seiden@linux.ibm.com> wrote:
>
> By introducing a novel virtualization acceleration for the ARM architecture on
> s390 architecture, we aim to expand the platform's software ecosystem. This
> initial patch series lays the groundwork by enabling KVM-accelerated ARM CPU
> virtualization on s390. To achieve this, a common KVM layer between s390 and
> arm64 is introduced (see below for more details). Design considerations of
> arm64 on the s390 Architecture The s390 virtualization architecture is extended
> with a set of new instructions dedicated to supporting ARM-based virtual
> machines. The s390 KVM host acts as EL2 (hypervisor) for a EL1/EL0
> (OS/application) arm64 guest. To achieve this, the new Start-Arm-Execution
> (SAE) instruction enables accelerated execution of arm64 VMs. Additional new
> s390 instructions are introduced to query available arm64 features, used to
> populate the arm64 ID register contents, as well as, new s390 instructions to
> save/restore various arm64 registers in the VM context.
Apologises for the delay in responding to this, things got delayed a
bit with the Easter break. Since then, Will and I have been discussing
this series and what it means for the future of the arm64 port.
By way of opening the discussion, we want to be clear that we are
supportive of the effort. Our comments here should be seen as areas of
potential improvement and not as rejection of what you are trying to
achieve.
* Code movement:
The patches you have posted demonstrate that it is possible to
expose a large amount of arm64-specific code and definition to s390,
and yet still manage to build both architectures without regression.
However, the result looks rather messy and may adversely affect
maintainability on the arm64 side.
The moving of files into shared locations is particularly painful,
and gets in the way of overall maintainability. Not only does it
break our comfortable habits, it makes the backporting of fixes
harder. Importantly, these changes come with no benefit on the
arm64 side.
Would it be possible to try some other means of reaching the
arm64-specific files *in situ*, either by making use of relative
paths, or by using symbolic links? Even better, files that are
generated on arm64 (such as the sysreg definitions) should equally
be generated for s390, locally to the s390 part of the tree.
But that doesn't mean that we consider that the arm64 tree is
immutable and that we are not open to change, quite the opposite.
Most of the KVM/arm64 include files are an unholy mix of arch
definitions, data structures that have some arch relevance, but also
code and data that is strictly implementation specific. Splitting
these (as you already have for some include files) could both help
with sharing what is actually needed, keep the arm64-specific stuff
at bay, *and* benefit arm64's overall maintainability. We would need
some tooling to enforce the split and avoid regressing it, something
that could happen quickly given the level of activity on arm64. Yet
another way to achieve this could be to mechanically process the
arm64 files as part of the s390 build to extract the relevant
information, and we could help with this.
Looking a bit more into the distance, it is likely that KVM/arm64
will grow feature support quicker than s390 can absorb them, and
that some feature won't ever make any sense of s390 (pKVM, for
example). We need to establish how these features can be built
without arm64 being hindered by s390. This is also true when adding
architectural support for features that don't exist in the s390 view
of arm64.
* UAPI and guest API:
Obviously, one of our biggest concerns is the userspace API. We
appreciate that you want to reuse it as it is, warts and all, and
directly incorporate additional feature support as it becomes
available. This means that, should any divergence in UAPI appear,
the source of truth must be on the arm64 side. This has the
following consequences:
- s390 cannot add extensions to the UAPI
- s390 must be compatible with all future arm64 extensions
Similar concerns exist on the guest/hypervisor API, including:
- errata mitigation: this is unsurprisingly a hot topic, which keeps
causing us some massive headaches. We are particularly concerned
about errata that need to be disclosed to the guest and acted upon
via a hypercall. Should there be a need for those, how will we
coordinate the deployment of such hypercall?
The way it has been deployed so far is that PSCI has grown an
errata discovery mechanism. ARM assigns function numbers and
specifies what these hypercalls mitigate. KVM, in turn, takes part
in implementing the mitigation. We expect that s390 would follow
the same behaviour, including coordination with ARM for the
function numbering.
- device assignment: this is unknown territory for us, as we
commonly use vfio-pci (and more occasionally vfio-platform). How
would that look for an arm64 guest on s390?
- s390-specific ISA extension: although we obviously cannot control
how you will decide to expose features to your arm64 guests,
KVM/arm64 makes a point of forbidding any use of implementation
specific instruction or system registers. We expect the s390
implementation to uphold this.
- s390-specific hypercalls: aside from the errata handling
mentioned above, we would very much like to avoid anything that is
implementation specific, and keep the hypercall space as small as
possible. In other words, an unenlightened arm64 guest must work
and continue to work.
* Overall maintenance
Unsurprisingly, we are not totally familiar with s390. To say that
there is a learning gap would only be an understatement. So how do
we make sure we don't break things out of pure ignorance? Is there
any documentation we can refer to when hacking on code that will
eventually run on your side of the computing universe?
We need to be able to build and test what we produce. How do we go
about that? We appreciate that you may not be in a position to help
with this right now, but at least having a plan would be reassuring.
This should include things like automatic testing of our CI branches.
We are happy to test build s390 as part of our maintenance flow, if
pointed to existing binary toolchains compiled for arm64 and x86,
together with a typical configuration.
What about debugging? We expect that you'd have to help, should an
arm64 change cause a regression on s390, as it is fairly unlikely
that we would be able to reproduce it.
Finally, we feel it would be beneficial for both projects to swap
prisoners and have cross-reviewers in MAINTAINERS, so that there is
an s390 reviewer added to KVM/arm64, and an arm64 reviewer added to
KVM/s390.
It probably would be beneficial to work through some of these things
face-to-face. Maybe around LPC or KVM Forum if you manage to get
there? Or some other place/time?
Thanks,
Marc and Will
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH 05/40] arm64: dts: rockchip: Add frl-enable-gpios to rk3576-luckfox-core3576
From: Cristian Ciocaltea @ 2026-04-20 11:00 UTC (permalink / raw)
To: Heiko Stuebner, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <2282688.C4sosBPzcN@phil>
Hi Heiko,
On 4/18/26 2:12 AM, Heiko Stuebner wrote:
> Hi Cristian,
>
> Am Freitag, 17. April 2026, 18:34:17 Mitteleuropäische Sommerzeit schrieb Cristian Ciocaltea:
>> On 4/17/26 2:32 PM, Heiko Stuebner wrote:
>>> the comments below apply sort of to all patches in that series.
>>>
>>> Am Freitag, 17. April 2026, 11:24:39 Mitteleuropäische Sommerzeit schrieb Cristian Ciocaltea:
>>>> The board exposes the GPIO4_C6 line to control the voltage bias on the
>>>> HDMI data lines. It must be asserted when operating in HDMI 2.1 FRL
>>>> mode and deasserted for HDMI 1.4/2.0 TMDS mode.
>>>>
>>>> Wire up the HDMI node to the GPIO line using the frl-enable-gpios
>>>> property and drop the line from the vcc_5v0_hdmi regulator to allow
>>>> adjusting the bias when transitioning between TMDS and FRL operating
>>>> modes.
[...]
>>>
>>>
>>>> @@ -231,6 +228,8 @@ &gpu {
>>>> };
>>>>
>>>> &hdmi {
>>>> + pinctrl-0 = <&hdmi_txm0_pins &hdmi_tx_scl &hdmi_tx_sda &hdmi_frl_en>;
>>>> + frl-enable-gpios = <&gpio4 RK_PC6 GPIO_ACTIVE_LOW>;
>>>
>>> this should be sorted the other way around I think.
>>>
>>> Also please provide a pinctrl-names property too. If for whatever reason
>>> the dw-hdmi aquires a 2nd pinctrl state in the future, this makes sure
>>> board DTs are staying in the "old" compatible mode until they are adapted.
>>
>> Just to make sure I fully understand, the convention is that
>>
>> pinctrl-names = "default";
>>
>> should be always provided, even when the node overrides an existing pinctrl-0
>> property?
>>
>> E.g. in rk3576.dtsi we have:
>>
>> hdmi: hdmi@27da0000 {
>> ...
>> pinctrl-names = "default";
>> pinctrl-0 = <&hdmi_txm0_pins &hdmi_tx_scl &hdmi_tx_sda>;
>> ...
>> }
>>
>> Hence I omitted pinctrl-names which doesn't change and just appended
>> &hdmi_frl_en to pinctrl-0's original value.
>
> correct, please always provide a pinctrl-names entry when setting a new
> pinctrl-0 .
>
> The background is, imagine you have a base:
>
> pinctrl-names = "default";
> pinstrl-0 = <....>;
>
> and override pinctrl-0 in a board.
>
> Now a newer binding introduces a 2nd pinctrl state "foo". Of course
> we're backwards compatible, and both are valid and the driver checks
> what states are defined.
>
> So the base sets:
> pinctrl-names = "default", "foo";
> pinctrl-0 = <...>;
> pinctrl-1 = <...>;
>
> in your (old) board you override pinctrl-0, but the driver still sees
> the new variant with 2 pinctrl states, where it should've stayed with
> the legacy 1-state, until the board-dts might get adapted in the future.
>
>
> And I know, we're likely not doing that everywhere, and also in most
> cases it won't really matter, but still it is safer and sets the better
> precedent :-) .
Thanks for the detailed explanation, that clears things up!
There are several other nodes (e.g. i2c, pwm, uart) that also lack
pinctrl-names despite providing pinctrl-0 - I can address those in a
separate patch.
I also noticed an inconsistency in property ordering: some nodes place
pinctrl-names before pinctrl-<n> and others after. I have always used
the former, but we should probably prefer the latter to stay consistent
with how clocks, resets, phys, etc. are ordered.
Thoughts?
>
>>>> status = "okay";
>>>> };
>>>>
>>>> @@ -655,7 +654,7 @@ &pcie0 {
>>>>
>>>> &pinctrl {
>>>> hdmi {
>>>> - hdmi_con_en: hdmi-con-en {
>>>> + hdmi_frl_en: hdmi-frl-en {
>>>
>>> pinctrl names should ideally match the naming in schematics, for example the
>>> "HDMI0_TX_ON_H" for jaguar and tiger. This makes it way easier to> go from DT
>>> to schematics and back.
>>
>> I opted for a more descriptive name that could be used consistently across all
>> boards, given that not all schematics are publicly available.
>>
>> You make a fair point though, we should probably stick with the pretty terrible
>> hdmi[N]_tx_on_h naming instead.
>
> yep, we're doing that everywhere else already too, and sticking to the
> schematics naming, also prevents any discussions about how something
> should be named ;-) .
Indeed. :)
^ permalink raw reply
* Re: [PATCH 1/6] drm/connector: report IRQ_HPD events to drm_connector_oob_hotplug_event()
From: Tomi Valkeinen @ 2026-04-20 11:01 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: dri-devel, linux-kernel, linux-usb, intel-gfx, intel-xe,
linux-amlogic, linux-arm-kernel, linux-arm-msm, freedreno,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Heikki Krogerus, Greg Kroah-Hartman, Andrzej Hajda,
Neil Armstrong, Robert Foss, Laurent Pinchart, Jonas Karlman,
Jernej Skrabec, Adrien Grassein, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, Bjorn Andersson,
Konrad Dybcio, Pengyu Luo, Nikita Travkin, Yongxing Mou
In-Reply-To: <3vrqk67oivkgo26xdc3r774rvj3jn3t6sfydhlytyrfiftubhg@cipain7xxcjz>
Hi,
On 20/04/2026 12:50, Dmitry Baryshkov wrote:
> On Mon, Apr 20, 2026 at 07:50:46AM +0300, Tomi Valkeinen wrote:
>> Hi,
>>
>> On 18/04/2026 01:32, Dmitry Baryshkov wrote:
>>> On Thu, Apr 16, 2026 at 11:10:03AM +0300, Tomi Valkeinen wrote:
>>>> Hi,
>>>>
>>>> On 16/04/2026 02:22, Dmitry Baryshkov wrote:
>>>>> The DisplayPort standard defines a special kind of events called IRQ.
>>>>> These events are used to notify DP Source about the events on the Sink
>>>>> side. It is extremely important for DP MST handling, where the MST
>>>>> events are reported through this IRQ.
>>>>>
>>>>> In case of the USB-C DP AltMode there is no actual HPD pulse, but the
>>>>> events are ported through the bits in the AltMode VDOs.
>>>>>
>>>>> Extend the drm_connector_oob_hotplug_event() interface and report IRQ
>>>>> events to the DisplayPort Sink drivers.
>>>>>
>>>>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
>>>>> ---
>>>>> drivers/gpu/drm/drm_connector.c | 4 +++-
>>>>> drivers/usb/typec/altmodes/displayport.c | 12 ++++++++----
>>>>> include/drm/drm_connector.h | 3 ++-
>>>>> 3 files changed, 13 insertions(+), 6 deletions(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
>>>>> index 47dc53c4a738..5fdacbd84bd7 100644
>>>>> --- a/drivers/gpu/drm/drm_connector.c
>>>>> +++ b/drivers/gpu/drm/drm_connector.c
>>>>> @@ -3510,6 +3510,7 @@ struct drm_connector *drm_connector_find_by_fwnode(struct fwnode_handle *fwnode)
>>>>> * drm_connector_oob_hotplug_event - Report out-of-band hotplug event to connector
>>>>> * @connector_fwnode: fwnode_handle to report the event on
>>>>> * @status: hot plug detect logical state
>>>>> + * @irq_hpd: HPD pulse detected
>>>>> *
>>>>> * On some hardware a hotplug event notification may come from outside the display
>>>>> * driver / device. An example of this is some USB Type-C setups where the hardware
>>>>> @@ -3520,7 +3521,8 @@ struct drm_connector *drm_connector_find_by_fwnode(struct fwnode_handle *fwnode)
>>>>> * a drm_connector reference through calling drm_connector_find_by_fwnode().
>>>>> */
>>>>> void drm_connector_oob_hotplug_event(struct fwnode_handle *connector_fwnode,
>>>>> - enum drm_connector_status status)
>>>>> + enum drm_connector_status status,
>>>>> + bool irq_hpd)
>>>> I find the "IRQ HPD" naming always confusing, even if I'm somewhat familiar
>>>> with DP, but if someone has mainly worked on HDMI, I'm sure it's even worse.
>>>>
>>>> Can we define this a bit more precisely? Is 'irq_hpd' only for displayport?
>>>> If so, perhaps 'dp_irq_hpd' or 'displayport_irq_hpd'. I might even call it
>>>> 'dp_hpd_pulse', but maybe that's not good as the spec talks about HPD pulse
>>>> for both short and long ones (although in the kernel doc you just write "HPD
>>>> pulse")... The kernel doc could be expanded a bit to make it clear what this
>>>> flag indicates.
>>>
>>> I attempted to stay away from defining a DP-specific flag, keeping it
>>> generic enough. HDMI is pretty close (IMO) to requiring separate flag in
>>
>> If it's not specifically the DP IRQ HPD, then we need to define what it
>> means. I tried to think what it would mean with HDMI, but I didn't come up
>> with anything.
>
> I might be mistaken, but I had someting like HEAC HPD / EDID status
> changes in mind (or HDCP-triggered HPD status changes). But here I
> admit, I hadn't checked if it is actually applicable or not.
Possibly, I'm not familiar with those.
> Anyway, for e.g. DVI or VGA that means nothing. But, my point really is
> to abstain from defining someting as DP-only in the top-level API.
I'm fine with that, but then it really has to be defined =).
>>> Linux. Likewise I'd rather not use "pulse". The DP AltMode defines a bit
>>> in the VDO rather than a pulse.
>>>
>>> Anyway, if irq_hpd doesn't sound precise enough, what about "bool
>>> extra_irq"? This would convey that this is the extra hpd-related IRQ,
>>> but it would also be obvious that it's not related to the HPD pin
>>> itself.
>> We'd still need to define what exactly it means. I think it might be better
>> to just define it as the DP IRQ HPD, as then the meaning is clear.
>>
>> Also, would an enum flags parameter be better than a bool parameter?
>
> Maybe not enum, but u32 param. Then it can become:
>
> @extra_status: additional type-specific information provided by the sink
> without changing the HPD state
>
> void drm_connector_oob_hotplug_event(..., u32 extra_status);
>
> /* DP short HPD pulse or corresponding AltMode flag */
> #define DRM_CONNECTOR_OOB_DP_IRQ_HPD BIT(0)
> /* DP long HPD pulse, debounced XXX: do we need this? */
> #define DRM_CONNECTOR_OOB_DP_REPLUG BIT(1)
Why is u32 better than enum? So that we could e.g. pass short values
inside the extra_status?
> For HDMI we might want to define:
>
> /* HDMI 1.4b 8.5, HPD pulse */
> #define DRM_CONNECTOR_OOB_HDMI_REPLUG BIT(0)
>
> Or might not, 100ms is long enough for all debouncers.
As I read the spec, there's no usable HPD pulse in HDMI as such. It just
means that if HPD is low less than 100ms, it should be ignored, and if
it's low more than 100ms, it should be handled. In other words, from
spec perspective there's no difference between HPD being low 105ms or
five days, there's no upper limit for the "pulse".
Still, we probably want to handle the case where the HPD is low only for
a short period, so that we don't do a full disable/enable-cycle. We can
interpret it as the same monitor still being connected, we just need to
check the EDID again.
But isn't that just a drm_connector_hotplug_event with
drm_connector_status staying connected? The callee can see that the
connector was connected before, it's connected now, but we got an event,
so let's read the EDID again.
Tomi
^ permalink raw reply
* Re: [PATCH 00/40] arm64: dts: rockchip: Wire up frl-enable-gpios for RK3576/RK3588 boards
From: Cristian Ciocaltea @ 2026-04-20 11:10 UTC (permalink / raw)
To: Heiko Stuebner, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <2435759.n0HT0TaD9V@phil>
On 4/18/26 2:18 AM, Heiko Stuebner wrote:
> Hi Cristan,
>
> Am Freitag, 17. April 2026, 19:55:17 Mitteleuropäische Sommerzeit schrieb Cristian Ciocaltea:
>> On 4/17/26 2:34 PM, Heiko Stuebner wrote:
>>> Am Freitag, 17. April 2026, 11:24:34 Mitteleuropäische Sommerzeit schrieb Cristian Ciocaltea:
>>>
>>> [...]
>>>
>>>> Cristian Ciocaltea (40):
>>>> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-100ask-dshanpi-a1
>>>> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-armsom-sige5
>>>> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-evb1-v10
>>>> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-evb2-v10
>>>> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-luckfox-core3576
>>>> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-nanopi-m5
>>>> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-nanopi-r76s
>>>> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-roc-pc
>>>> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-rock-4d
>>>
>>> I do think one patch per SoC (rk3576, rk3588, rk3588s) would make more
>>> sense, because these patches really are mostly identical :-)
>>
>> Yeah, apologies for the large number of patches, I went this way to allow
>> per-board reviews. As previously noted, I tried to identify the GPIO pins from
>> multiple sources, so I'm not entirely sure about the accuracy in every case.
>>
>> Would it be preferable to squash the patches per SoC and board vendor, instead?
>
> I really would just do it per soc .. so 3 patches. That is a size that is
> still reviewable for people, who can then check for their board.
>
> If the patch is labeled "Add frl-enable-gpios for all RK3588s boards", I
> do expect people to notice it the same as "oh _my_ board gets changed".
> ("all" could also be "most" :-) ).
Ack.
I would still keep the more invasive changes — such as those touching
the regulator hacks — in separate patches, though.
Thanks,
Cristian
^ permalink raw reply
* Re: [PATCH 00/30] KVM: arm64: Add support for protected guest memory with pKVM
From: Pavan Kondeti @ 2026-04-20 11:26 UTC (permalink / raw)
To: Will Deacon
Cc: Pavan Kondeti, kvmarm, linux-arm-kernel, Marc Zyngier,
Oliver Upton, Joey Gouly, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Quentin Perret, Fuad Tabba, Vincent Donnefort,
Mostafa Saleh
In-Reply-To: <aeX5Q7QNxmBCmsqM@willie-the-truck>
On Mon, Apr 20, 2026 at 11:00:35AM +0100, Will Deacon wrote:
> On Mon, Apr 20, 2026 at 01:32:03PM +0530, Pavan Kondeti wrote:
> > Hi Will,
> >
> > On Mon, Jan 05, 2026 at 03:49:08PM +0000, Will Deacon wrote:
> > > Hi folks,
> > >
> > > Although pKVM has been shipping in Android kernels for a while now,
> > > protected guest (pVM) support has been somewhat languishing upstream.
> > > This has partly been because we've been waiting for guest_memfd() but
> > > also because it hasn't been clear how to expose pVMs to userspace (which
> > > is necessary for testing) without getting everything in place beforehand.
> > > This has led to frustration on both sides of the fence [1] and so this
> > > patch series attempts to get things moving again by exposing pVM
> > > features in an incremental fashion based on top of anonymous memory,
> > > which is what we have been using in Android. The big difference between
> > > this series and the Android implementation is the graceful handling of
> > > host stage-2 faults arising from accesses made using kernel mappings.
> > > The hope is that this will unblock pKVM upstreaming efforts while the
> > > guest_memfd() work continues to evolve.
> > >
> > > Specifically, this patch series implements support for protected guest
> > > memory with pKVM, where pages are unmapped from the host as they are
> > > faulted into the guest and can be shared back from the guest using pKVM
> > > hypercalls. Protected guests are created using a new machine type
> > > identifier and can be booted to a shell using the kvmtool patches
> > > available at [2], which finally means that we are able to test the pVM
> > > logic in pKVM. Since this is an incremental step towards full isolation
> > > from the host (for example, the CPU register state and DMA accesses are
> > > not yet isolated), creating a pVM requires a developer Kconfig option to
> > > be enabled in addition to booting with 'kvm-arm.mode=protected' and
> > > results in a kernel taint.
> > >
> >
> > Good to see Protected VM support in upstream w/ pKVM.
> >
> > We (Qualcomm) have been trying to resume Gunyah upstreaming [1] efforts
> > for some time but the path to re-use guest_memfd is not straight forward as
> > guest_memfd is tightly coupled with KVM. While the efforts to use it for
> > pKVM is pending and refactoring to make it use outside KVM is not
> > happening anytime soon, we plan to send Gunyah series similar to how
> > this series is dealt with pages lent/donated to the Guest. Please let us
> > know if you have any suggestions/comments for us.
>
> The major problem I see with this is that the host/hyp interface for
> handling stage-2 faults is internal to pKVM. The exception is injected
> back into the host using a funky ESR encoding and the hypercall used
> to forcefully reclaim the page is not ABI. I have no appetite for
> standardising these mechanisms (the flexibility is one of pKVM's big
> advantages) but I also do not want to complicate EL1 fault handling path
> with hypervisor-specific crap that we have to maintain forever.
Thanks Will for the feedback. Agree that we don't want to sprinkle Gunyah
specific checks in fault handling code. Do we need to handle anything
apart from
(a) user space access a memory that is lent to the guest. Gunyah will
inject Synchronous External Abort and the offending process will be killed.
(b) For kernel access, we need to unmap the memory at S1 while lending
it to the guest. Earlier, Elliot attempted this with [1]. I am thinking
we can leverage from Direct map removal work done for guest_memfd w/o
really using it :-) . I am hoping [2] can be made available for Gunyah
module as well.
For the (b) problem above, pKVM takes a different route in upstream i.e
pkvm_force_reclaim_guest_page(). I believe this avoids kernel panic at
the expense of memory corruption in the guest. correct?
Thanks,
Pavan
[1]
https://lore.kernel.org/all/20240222-gunyah-v17-19-1e9da6763d38@quicinc.com/
[2]
https://lore.kernel.org/all/20260317141031.514-3-kalyazin@amazon.com/
^ permalink raw reply
* Re: [PATCH 0/4] Add hstimer support for H616 and T113-S3
From: Michal Piekos @ 2026-04-20 11:27 UTC (permalink / raw)
To: Andre Przywara
Cc: Daniel Lezcano, Thomas Gleixner, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Maxime Ripard, linux-kernel, devicetree, linux-arm-kernel,
linux-sunxi
In-Reply-To: <20260419225539.718367e0@ryzen.lan>
On Sun, Apr 19, 2026 at 10:55:39PM +0200, Andre Przywara wrote:
> On Sun, 19 Apr 2026 14:46:06 +0200
> Michal Piekos <michal.piekos@mmpsystems.pl> wrote:
>
> Hi Michal,
>
> > Add support for Allwinner H616 high speed timer in sun5i hstimer driver
> > and describe corresponding nodes in dts for H616 and T113-S3.
> >
> > H616 uses same model as existing driver except register shift compared
> > to older variants.
> >
> > Added register layout abstraction in the driver, extended the binding
> > with new compatibles and wired up dts nodes for H616 and T113-S3 which
> > uses H616 as fallback compatible.
>
> Can you say *why* we need this? IIUC Linux only ever uses one clock
> source, and selects the (non-optional) Generic Timer (aka arch timer)
> for that? So can you say what this hstimer clock source adds? I guess
> higher resolution, but what is your use case, so why would you need the
> 200 MHz? And does this offset the higher access cost of an MMIO
> access, compared to the arch timer's sysreg based access? Also, IIUC,
> people would need to manually select this as the clocksource, why and
> when would they do so? (Given they even know about it in the first
> place).
> Also the hstimer hasn't been used since the A20, so nobody seemed to
> have missed it meanwhile?
>
> Cheers,
> Andre
>
I took the table from https://linux-sunxi.org/Linux_mainlining_effort as
a todo list and wanted to help with it. I do not have own use case for
this timer. If it is not needed then I will spin v2 to include your
comments and abandon it.
Michal
> >
> > Signed-off-by: Michal Piekos <michal.piekos@mmpsystems.pl>
> > ---
> > Michal Piekos (4):
> > dt-bindings: timer: allwinner,sun5i-a13-hstimer: add H616 and T113-S3
> > clocksource/drivers/sun5i: add H616 hstimer support
> > arm64: dts: allwinner: h616: add hstimer node
> > arm: dts: allwinner: t113s: add hstimer node
> >
> > .../timer/allwinner,sun5i-a13-hstimer.yaml | 8 +++-
> > arch/arm/boot/dts/allwinner/sun8i-t113s.dtsi | 12 +++++
> > arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi | 9 ++++
> > drivers/clocksource/timer-sun5i.c | 56 +++++++++++++++++++---
> > 4 files changed, 78 insertions(+), 7 deletions(-)
> > ---
> > base-commit: faeab166167f5787719eb8683661fd41a3bb1514
> > change-id: 20260413-h616-t113s-hstimer-62939948f91c
> >
> > Best regards,
>
>
^ 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