* Re: [PATCH 17/18] pinctrl: airoha: prepare for en7523 adding
From: Bartosz Golaszewski @ 2026-06-08 16:15 UTC (permalink / raw)
To: Mikhail Kshevetskiy
Cc: Linus Walleij, Sean Wang, Lorenzo Bianconi, Matthias Brugger,
AngeloGioacchino Del Regno, Christian Marangi,
Bartosz Golaszewski, Benjamin Larsson, linux-kernel, linux-gpio,
linux-mediatek, linux-arm-kernel, Matheus Sampaio Queiroga,
Markus Gothe
In-Reply-To: <20260607001654.1439480-18-mikhail.kshevetskiy@iopsys.eu>
On Sun, 7 Jun 2026 02:16:53 +0200, Mikhail Kshevetskiy
<mikhail.kshevetskiy@iopsys.eu> said:
> en7523 a bit differs from an7581/an7583. It has different register
> offsets and slightly different bitfield masks.
>
> Let's adapt common header and existing drivers for the future addition
> of en7523.
>
> Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
> ---
Looks good to me.
Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 16/18] pinctrl: airoha: an7583: remove an7583 prefix from variable names
From: Bartosz Golaszewski @ 2026-06-08 16:17 UTC (permalink / raw)
To: Mikhail Kshevetskiy
Cc: Linus Walleij, Sean Wang, Lorenzo Bianconi, Matthias Brugger,
AngeloGioacchino Del Regno, Christian Marangi,
Bartosz Golaszewski, Benjamin Larsson, linux-kernel, linux-gpio,
linux-mediatek, linux-arm-kernel, Matheus Sampaio Queiroga,
Markus Gothe
In-Reply-To: <20260607001654.1439480-17-mikhail.kshevetskiy@iopsys.eu>
On Sun, 7 Jun 2026 02:16:52 +0200, Mikhail Kshevetskiy
<mikhail.kshevetskiy@iopsys.eu> said:
> We have only an7583 specific code in the pinctrl-an7583 kernel module,
> so 'an75831_' prefix is not necessary anymore. Remove it.
>
> Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
> ---
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v2 1/6] ACPI: RISC-V: Fix riscv_acpi_irq_get_dep() loop termination
From: Sunil V L @ 2026-06-08 16:24 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Rafael J. Wysocki, Len Brown, Sunil V L, Marc Zyngier,
Thomas Gleixner, Huacai Chen, Anup Patel, Hanjun Guo,
Sudeep Holla, Catalin Marinas, Will Deacon, linux-riscv,
linux-kernel, linux-acpi, linux-arm-kernel, loongarch
In-Reply-To: <20260603-gic-v5-acpi-iwb-probe-deferral-v2-1-23ffa16b6ebb@kernel.org>
Hi Lorenzo,
On Wed, Jun 3, 2026 at 1:51 PM Lorenzo Pieralisi <lpieralisi@kernel.org> wrote:
>
> In riscv_acpi_add_irq_dep() the main loop condition would currently stop
> the loop if an interrupt descriptor contains an interrupt for which the
> respective GSI handle is NULL, which is not correct because subsequent
> interrupts in the interrupt descriptor might still have a GSI dependency
> that must not be skipped.
>
> Rework riscv_acpi_add_irq_dep() and the riscv_acpi_irq_get_dep() call chain
> to fix it - by not forcing the loop to stop in order to guarantee
> dependency detection for all the interrupt entries in the CRS descriptor.
>
> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
> Cc: "Rafael J. Wysocki" <rafael@kernel.org>
> Cc: Sunil V L <sunilvl@ventanamicro.com>
> ---
> drivers/acpi/riscv/irq.c | 10 ++++++----
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/acpi/riscv/irq.c b/drivers/acpi/riscv/irq.c
> index 9b88d0993e88..cd83c3035cf6 100644
> --- a/drivers/acpi/riscv/irq.c
> +++ b/drivers/acpi/riscv/irq.c
> @@ -299,6 +299,7 @@ static acpi_status riscv_acpi_irq_get_parent(struct acpi_resource *ares, void *c
> return AE_OK;
>
> ctx->handle = riscv_acpi_get_gsi_handle(eirq->interrupts[ctx->index]);
> + ctx->rc = 0;
> return AE_CTRL_TERMINATE;
> }
>
> @@ -314,10 +315,8 @@ static int riscv_acpi_irq_get_dep(acpi_handle handle, unsigned int index, acpi_h
>
> acpi_walk_resources(handle, METHOD_NAME__CRS, riscv_acpi_irq_get_parent, &ctx);
> *gsi_handle = ctx.handle;
> - if (*gsi_handle)
> - return 1;
>
> - return 0;
> + return ctx.rc;
> }
>
> static u32 riscv_acpi_add_prt_dep(acpi_handle handle)
> @@ -381,8 +380,11 @@ static u32 riscv_acpi_add_irq_dep(acpi_handle handle)
> int i;
>
> for (i = 0;
> - riscv_acpi_irq_get_dep(handle, i, &gsi_handle);
> + !riscv_acpi_irq_get_dep(handle, i, &gsi_handle);
> i++) {
> + if (!gsi_handle)
> + continue;
> +
> dep_devices.count = 1;
> dep_devices.handles = kzalloc_objs(*dep_devices.handles, 1);
> if (!dep_devices.handles) {
>
Do these fixes need the Fixes tag?
Otherwise, LGTM.
Reviewed-by: Sunil V L <sunilvl@oss.qualcomm.com>
Thanks!
Sunil
^ permalink raw reply
* Re: [PATCHv2] dmaengine: st_fdma: simplify allocation
From: Frank Li @ 2026-06-08 16:25 UTC (permalink / raw)
To: Rosen Penev
Cc: dmaengine, Patrice Chotard, Vinod Koul, Frank Li, Kees Cook,
Gustavo A. R. Silva, moderated list:ARM/STI ARCHITECTURE,
open list,
open list:KERNEL HARDENING (not covered by other areas):Keyword:b__counted_by(_le|_be|_ptr)?b
In-Reply-To: <20260608051829.7390-1-rosenp@gmail.com>
On Sun, Jun 07, 2026 at 10:18:29PM -0700, Rosen Penev wrote:
Nit: dmaengine: st_fdma: simplify allocation by using flexible array
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> Use a flexible array member to combine kzalloc and kcalloc to a single
> allocation.
>
> Add __counted_by for extra runtime analysis. Assign counting variable
> after allocation before any array accesses.
>
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> ---
>
^ permalink raw reply
* Re: [PATCH] dmaengine: qcom: hidma: use sysfs_emit() in sysfs show callbacks
From: Frank Li @ 2026-06-08 16:27 UTC (permalink / raw)
To: Hungyu Lin
Cc: okaya, vkoul, Frank.Li, linux-arm-kernel, linux-arm-msm,
dmaengine, linux-kernel
In-Reply-To: <20260607163119.78717-1-dennylin0707@gmail.com>
On Sun, Jun 07, 2026 at 04:31:19PM +0000, Hungyu Lin wrote:
> [You don't often get email from dennylin0707@gmail.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> Replace sprintf() and strlen() patterns in sysfs show callbacks
> with sysfs_emit().
>
> sysfs_emit() is the preferred helper for formatting sysfs output
> and simplifies the implementation.
>
> Signed-off-by: Hungyu Lin <dennylin0707@gmail.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> drivers/dma/qcom/hidma.c | 6 ++----
> drivers/dma/qcom/hidma_mgmt_sys.c | 19 ++++++++-----------
> 2 files changed, 10 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
> index 5a8dca8db5ce..7a7f302a9699 100644
> --- a/drivers/dma/qcom/hidma.c
> +++ b/drivers/dma/qcom/hidma.c
> @@ -624,12 +624,10 @@ static ssize_t hidma_show_values(struct device *dev,
> {
> struct hidma_dev *mdev = dev_get_drvdata(dev);
>
> - buf[0] = 0;
> -
> if (strcmp(attr->attr.name, "chid") == 0)
> - sprintf(buf, "%d\n", mdev->chidx);
> + return sysfs_emit(buf, "%d\n", mdev->chidx);
>
> - return strlen(buf);
> + return 0;
> }
>
> static inline void hidma_sysfs_uninit(struct hidma_dev *dev)
> diff --git a/drivers/dma/qcom/hidma_mgmt_sys.c b/drivers/dma/qcom/hidma_mgmt_sys.c
> index 930eae0a6257..9672ef9ee8fc 100644
> --- a/drivers/dma/qcom/hidma_mgmt_sys.c
> +++ b/drivers/dma/qcom/hidma_mgmt_sys.c
> @@ -102,15 +102,12 @@ static ssize_t show_values(struct device *dev, struct device_attribute *attr,
> struct hidma_mgmt_dev *mdev = dev_get_drvdata(dev);
> unsigned int i;
>
> - buf[0] = 0;
> -
> for (i = 0; i < ARRAY_SIZE(hidma_mgmt_files); i++) {
> - if (strcmp(attr->attr.name, hidma_mgmt_files[i].name) == 0) {
> - sprintf(buf, "%d\n", hidma_mgmt_files[i].get(mdev));
> - break;
> - }
> + if (strcmp(attr->attr.name, hidma_mgmt_files[i].name) == 0)
> + return sysfs_emit(buf, "%d\n",
> + hidma_mgmt_files[i].get(mdev));
> }
> - return strlen(buf);
> + return 0;
> }
>
> static ssize_t set_values(struct device *dev, struct device_attribute *attr,
> @@ -143,15 +140,15 @@ static ssize_t show_values_channel(struct kobject *kobj,
> struct hidma_chan_attr *chattr;
> struct hidma_mgmt_dev *mdev;
>
> - buf[0] = 0;
> chattr = container_of(attr, struct hidma_chan_attr, attr);
> mdev = chattr->mdev;
> +
> if (strcmp(attr->attr.name, "priority") == 0)
> - sprintf(buf, "%d\n", mdev->priority[chattr->index]);
> + return sysfs_emit(buf, "%d\n", mdev->priority[chattr->index]);
> else if (strcmp(attr->attr.name, "weight") == 0)
> - sprintf(buf, "%d\n", mdev->weight[chattr->index]);
> + return sysfs_emit(buf, "%d\n", mdev->weight[chattr->index]);
>
> - return strlen(buf);
> + return 0;
> }
>
> static ssize_t set_values_channel(struct kobject *kobj,
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v6 3/4] firmware: smccc: arm-cca-guest: Bind the TSM provider to an SMCCC device
From: Suzuki K Poulose @ 2026-06-08 16:27 UTC (permalink / raw)
To: Sudeep Holla, Aneesh Kumar K.V
Cc: linux-coco, linux-arm-kernel, linux-kernel, Catalin Marinas,
Greg KH, Jeremy Linton, Jonathan Cameron, Lorenzo Pieralisi,
Mark Rutland, Will Deacon, Steven Price
In-Reply-To: <20260608-hot-fascinating-tortoise-cccc61@sudeepholla>
On 08/06/2026 13:32, Sudeep Holla wrote:
> On Mon, Jun 08, 2026 at 04:56:29PM +0530, Aneesh Kumar K.V wrote:
>> Suzuki K Poulose <suzuki.poulose@arm.com> writes:
>>
>>> On 08/06/2026 09:19, Aneesh Kumar K.V wrote:
>>>> Sudeep Holla <sudeep.holla@kernel.org> writes:
>>>>
>>>>> On Thu, Jun 04, 2026 at 06:56:28PM +0530, Aneesh Kumar K.V wrote:
>>>>>> Sudeep Holla <sudeep.holla@kernel.org> writes:
>>>>>>
>>>>>> ...
>>
>> ...
>>
>>>>> I was trying to avoid conditional compilation altogether and hence the
>>>>> reason for keeping it as simple as possible. Also IS_ENABLED(CONFIG_ARM64)
>>>>> in above snippet must come as some condition to this generic probe.
>>>>>
>>>>> Adding any more logic or callback defeats the bus idea here if we need
>>>>> to rely/depend on multiple conditional compilation or callbacks IMO.
>>>>>
>>>>> Let's find see if it can work with what we are adding now and may add in
>>>>> near future and then decide.
>>>>>
>>>>
>>>> If we move all the conditional checks to the driver probe path, then I
>>>> think this can work. Something like the below:
>>>>
>>>> struct smccc_device_info {
>>>> u32 func_id;
>>>> bool requires_smc;
>>>> const char *device_name;
>>>> };
>>>>
>>>> static const struct smccc_device_info smccc_devices[] __initconst = {
>>>> {
>>>> .func_id = ARM_SMCCC_TRNG_VERSION,
>>>> .requires_smc = false,
>>>> .device_name = "arm-smccc-trng",
>>>> },
>>>>
>>>> {
>>>> .func_id = RSI_ABI_VERSION,
>>>
>>> Don't we need parameters passed to this (Requested Interface version for
>>> e.g.) ? See more below.
>>>
>>
>> The idea is that we only check whether the function ID is supported. All
>> other conditional logic should be handled in the driver probe path, as
>> demonstrated by the changes in drivers/char/hw_random/arm_smccc_trng.c.
>>
>
> +1. Yes, we just want to know whether the firmware is aware of that feature
> before creating the `smccc_device` for it. The device probe can then perform a
> more thorough, feature-specific check to determine whether the device/feature
> is usable.
>
> That is the main idea behind the approach I suggested. Please let me know if
> you still see any issues or think this may not work.
Ok, yea, I kind of forgot that we are boot strapping a driver based on
this "smccc device" and the device is only an indication of the firmware
service, the driver would decide if the service matches its expectation.
Thanks for the clarification, apologies for the noise.
Suzuki
>
^ permalink raw reply
* Re: [PATCH 00/39] Add i.MX95 DPU/DSI/LVDS support
From: Marek Vasut @ 2026-06-08 16:29 UTC (permalink / raw)
To: Liu Ying, Piyush Patle
Cc: dri-devel, imx, linux-arm-kernel, linux-clk, devicetree,
Shawn Guo, Fabio Estevam, Peng Fan, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lucas Stach, Laurent Pinchart,
Thomas Zimmermann, Abel Vesa, Pengutronix Kernel Team
In-Reply-To: <aiZzxhljfyYQ68Gl@raspi>
On 6/8/26 9:48 AM, Liu Ying wrote:
Hello everyone,
>> I brought this series up on the i.MX95 15x15 FRDM (IT6263 LVDS-to-HDMI on
>> LVDS ch1). It mostly works, but I ran into a few issues around DI routing,
>> LVDS format handling, and DC enable sequencing which needed rework before
>> HDMI would come up reliably on the board.
>>
>> I don't see a v2 of the series and things seem to have been quiet since
>> November. Are you planning to post an updated version?
>
> My plan was to enable prefetch engine support[1] for i.MX8QXP display
> controller and add device tree for a whole i.MX8QXP LVDS display pipeline,
> before adding i.MX95 display controller support.
>
> Unfortunately, it seems that Marek is not a big fan of [1]
I am fine with [1] as long as it can be isolated and does not affect
every SoC that might reuse this driver, which I think it can be done.
> and I'm busy
> with downstream development so the plan doesn't move forward well. I still
> think [1] makes sense(maybe I need to rebase it on latest drm-misc-next),
> so I'd like to see review comments on [1] and hopefully people think that
> the overall idea of [1] is ok.
My only concern is, to keep it isolated to MX8Q, so this driver can be
reused by MX95.
>> I've accumulated a fair amount of rework while getting this running on the
>> FRDM. If you're not planning a v2, I can clean things up and send one based
>> on the current series.
>
> I still think that i.MX95 display controller driver should be in a separate
> driver, rather than sharing the same driver with i.MX8QXP display controller
> like this patch series does, because the two display controllers are quite
> different as I mentioned in comments on this patch series and in discussion
> in [1]. Also, the common part between the two display controllers should
> be extracted to a common helper library as I mentioned there too.
Are they really? It seems this series adds support for the MX95 DC
without that many changes, so are the DCs really that different ? It
seems the MX95 DC is simply a reuse/evolution of the MX8Q DC blocks, so
duplicating the code seems like the wrong direction, it will only lead
to disparate sets of bugs in two drivers, which isn't desired.
(I might not fully understand what you have in mind with the helper
library though?)
^ permalink raw reply
* Re: [PATCH v2 3/6] ACPI: RISC-V: Fix riscv_acpi_add_prt_dep() loop handling
From: Sunil V L @ 2026-06-08 16:30 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Rafael J. Wysocki, Len Brown, Sunil V L, Marc Zyngier,
Thomas Gleixner, Huacai Chen, Anup Patel, Hanjun Guo,
Sudeep Holla, Catalin Marinas, Will Deacon, linux-riscv,
linux-kernel, linux-acpi, linux-arm-kernel, loongarch
In-Reply-To: <20260603-gic-v5-acpi-iwb-probe-deferral-v2-3-23ffa16b6ebb@kernel.org>
On Wed, Jun 3, 2026 at 2:18 PM Lorenzo Pieralisi <lpieralisi@kernel.org> wrote:
>
> The loop in riscv_acpi_add_prt_dep() includes error conditions that are
> handled in a dubious - if not outright wrong - way, by continuining the
> loop (which skips and misses the entry pointer update to point to the next
> entry).
>
> Rewrite the loop as a for loop (that handles the continuation correctly)
> and wrap the condition and update statements using helper functions to make
> it cleaner.
>
> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
> Cc: "Rafael J. Wysocki" <rafael@kernel.org>
> Cc: Sunil V L <sunilvl@ventanamicro.com>
> ---
> drivers/acpi/riscv/irq.c | 19 +++++++++++++++----
> 1 file changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/acpi/riscv/irq.c b/drivers/acpi/riscv/irq.c
> index 75170151c614..0cdec5dd575e 100644
> --- a/drivers/acpi/riscv/irq.c
> +++ b/drivers/acpi/riscv/irq.c
> @@ -319,6 +319,20 @@ static int riscv_acpi_irq_get_dep(acpi_handle handle, unsigned int index, acpi_h
> return ctx.rc;
> }
>
> +static bool acpi_prt_entry_valid(void *prt_entry)
> +{
> + struct acpi_pci_routing_table *entry = prt_entry;
> +
> + return entry && entry->length > 0;
> +}
> +
> +static void *acpi_prt_next_entry(void *prt_entry)
> +{
> + struct acpi_pci_routing_table *entry = prt_entry;
> +
> + return prt_entry + entry->length;
> +}
> +
> static u32 riscv_acpi_add_prt_dep(acpi_handle handle)
> {
> struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
> @@ -337,7 +351,7 @@ static u32 riscv_acpi_add_prt_dep(acpi_handle handle)
> }
>
> entry = buffer.pointer;
> - while (entry && (entry->length > 0)) {
> + for (; acpi_prt_entry_valid(entry); entry = acpi_prt_next_entry(entry)) {
> if (entry->source[0]) {
> status = acpi_get_handle(handle, entry->source, &link_handle);
> if (ACPI_FAILURE(status))
> @@ -365,9 +379,6 @@ static u32 riscv_acpi_add_prt_dep(acpi_handle handle)
> dep_devices.handles[0] = gsi_handle;
> count += acpi_scan_add_dep(handle, &dep_devices);
> }
> -
> - entry = (struct acpi_pci_routing_table *)
> - ((unsigned long)entry + entry->length);
> }
>
Reviewed-by: Sunil V L <sunilvl@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v2 2/6] ACPI: RISC-V: Check acpi_get_handle() status in riscv_acpi_add_prt_dep()
From: Sunil V L @ 2026-06-08 16:31 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Rafael J. Wysocki, Len Brown, Sunil V L, Marc Zyngier,
Thomas Gleixner, Huacai Chen, Anup Patel, Hanjun Guo,
Sudeep Holla, Catalin Marinas, Will Deacon, linux-riscv,
linux-kernel, linux-acpi, linux-arm-kernel, loongarch
In-Reply-To: <20260603-gic-v5-acpi-iwb-probe-deferral-v2-2-23ffa16b6ebb@kernel.org>
On Wed, Jun 3, 2026 at 1:52 PM Lorenzo Pieralisi <lpieralisi@kernel.org> wrote:
>
> In riscv_acpi_add_prt_dep(), the acpi_get_handle() call can fail which
> would leave link_handle uninitialized.
>
> Fix it by checking the acpi_get_handle() return status and skip the entry
> if it fails.
>
> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
> Cc: "Rafael J. Wysocki" <rafael@kernel.org>
> Cc: Sunil V L <sunilvl@ventanamicro.com>
> ---
> drivers/acpi/riscv/irq.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/riscv/irq.c b/drivers/acpi/riscv/irq.c
> index cd83c3035cf6..75170151c614 100644
> --- a/drivers/acpi/riscv/irq.c
> +++ b/drivers/acpi/riscv/irq.c
> @@ -339,7 +339,9 @@ static u32 riscv_acpi_add_prt_dep(acpi_handle handle)
> entry = buffer.pointer;
> while (entry && (entry->length > 0)) {
> if (entry->source[0]) {
> - acpi_get_handle(handle, entry->source, &link_handle);
> + status = acpi_get_handle(handle, entry->source, &link_handle);
> + if (ACPI_FAILURE(status))
> + continue;
> dep_devices.count = 1;
>
Reviewed-by: Sunil V L <sunilvl@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Add kvm_for_each_vncr_tlb() helper
From: Oliver Upton @ 2026-06-08 16:33 UTC (permalink / raw)
To: Marc Zyngier
Cc: kvmarm, kvm, linux-arm-kernel, Steffen Eiden, Joey Gouly,
Suzuki K Poulose, Zenghui Yu, Hyunwoo Kim, stable
In-Reply-To: <20260607175745.297793-1-maz@kernel.org>
Hey Marc,
Especially since this is a stable-worthy fix, it might be worth calling
out the bug in the shortlog, e.g.
KVM: arm64: nv: Avoid dereferencing NULL VNCR pseudo-TLB
On Sun, Jun 07, 2026 at 06:57:45PM +0100, Marc Zyngier wrote:
> VNCR TLB invalidation occurs from MMU notifiers or TLBI instructions,
> and either can race against a vcpu not being onlined yet (no pseudo-TLB
> allocated). Similarly, the TLB might be invalid, and the invalidation
> should be skipped in this case.
>
> Both kvm_invalidate_vncr_ipa() and kvm_invalidate_vncr_va() are
> expected to perform the same checks, except that the latter doesn't
> check for the allocation and blindly dereferences the pointer.
>
> Solve this by introducing a new iterator built on top of the usual
> kvm_for_each_vcpu() that checks for both of the above conditions,
> and convert the two users to it.
>
> Reported-by: Hyunwoo Kim <imv4bel@gmail.com>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> Link: https://lore.kernel.org/r/aiUvSbrWndQeUPc8@v4bel
> Fixes: 4ffa72ad8f37 ("KVM: arm64: nv: Add S1 TLB invalidation primitive for VNCR_EL2")
> Cc: stable@vger.kernel.org
Looks good
Reviewed-by: Oliver Upton <oupton@kernel.org>
Thanks,
Oliver
> ---
> arch/arm64/kvm/nested.c | 36 +++++++++++++++---------------------
> 1 file changed, 15 insertions(+), 21 deletions(-)
>
> diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
> index f8d3f3a723282..690b8e8564166 100644
> --- a/arch/arm64/kvm/nested.c
> +++ b/arch/arm64/kvm/nested.c
> @@ -908,9 +908,21 @@ static void invalidate_vncr(struct vncr_tlb *vt)
> clear_fixmap(vncr_fixmap(vt->cpu));
> }
>
> +/*
> + * VNCR TLB invalidation occurs from MMU notifiers or TLBI instructions, and
> + * either can race against a vcpu not being onlined yet (no pseudo-TLB
> + * allocated). Similarly, the TLB might be invalid. Skip those, as they
> + * obviously don't participate in the invalidation at this stage.
> + */
> +#define kvm_for_each_vncr_tlb(idx, vcpup, tlbp, kvm) \
> + kvm_for_each_vcpu(idx, vcpup, kvm) \
> + if (((tlbp) = vcpup->arch.vncr_tlb) && \
> + (tlbp)->valid)
> +
> static void kvm_invalidate_vncr_ipa(struct kvm *kvm, u64 start, u64 end)
> {
> struct kvm_vcpu *vcpu;
> + struct vncr_tlb *vt;
> unsigned long i;
>
> lockdep_assert_held_write(&kvm->mmu_lock);
> @@ -918,24 +930,9 @@ static void kvm_invalidate_vncr_ipa(struct kvm *kvm, u64 start, u64 end)
> if (!kvm_has_feat(kvm, ID_AA64MMFR4_EL1, NV_frac, NV2_ONLY))
> return;
>
> - kvm_for_each_vcpu(i, vcpu, kvm) {
> - struct vncr_tlb *vt = vcpu->arch.vncr_tlb;
> + kvm_for_each_vncr_tlb(i, vcpu, vt, kvm) {
> u64 ipa_start, ipa_end, ipa_size;
>
> - /*
> - * Careful here: We end-up here from an MMU notifier,
> - * and this can race against a vcpu not being onlined
> - * yet, without the pseudo-TLB being allocated.
> - *
> - * Skip those, as they obviously don't participate in
> - * the invalidation at this stage.
> - */
> - if (!vt)
> - continue;
> -
> - if (!vt->valid)
> - continue;
> -
> ipa_size = ttl_to_size(pgshift_level_to_ttl(vt->wi.pgshift,
> vt->wr.level));
> ipa_start = vt->wr.pa & ~(ipa_size - 1);
> @@ -965,17 +962,14 @@ static void invalidate_vncr_va(struct kvm *kvm,
> struct s1e2_tlbi_scope *scope)
> {
> struct kvm_vcpu *vcpu;
> + struct vncr_tlb *vt;
> unsigned long i;
>
> lockdep_assert_held_write(&kvm->mmu_lock);
>
> - kvm_for_each_vcpu(i, vcpu, kvm) {
> - struct vncr_tlb *vt = vcpu->arch.vncr_tlb;
> + kvm_for_each_vncr_tlb(i, vcpu, vt, kvm) {
> u64 va_start, va_end, va_size;
>
> - if (!vt->valid)
> - continue;
> -
> va_size = ttl_to_size(pgshift_level_to_ttl(vt->wi.pgshift,
> vt->wr.level));
> va_start = vt->gva & ~(va_size - 1);
> --
> 2.47.3
>
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Hold kvm->mmu_lock while initialising vcpu->arch.vncr_tlb
From: Oliver Upton @ 2026-06-08 16:34 UTC (permalink / raw)
To: Marc Zyngier
Cc: kvmarm, kvm, linux-arm-kernel, Steffen Eiden, Joey Gouly,
Suzuki K Poulose, Zenghui Yu
In-Reply-To: <20260608081108.2244133-1-maz@kernel.org>
On Mon, Jun 08, 2026 at 09:11:08AM +0100, Marc Zyngier wrote:
> Sashiko reports that there is a race between initialising vncr_tlb
> and making use of it, as we don't hold the mmu_lock at this point.
>
> Additionally, it identifies a memory leak, should userspace repeatedly
> invokes the KVM_RUN ioctl after a failure of kvm_arch_vcpu_run_pid_change(),
> as we assign vncr_tlb blindly on first run, irrespective of prior
> allocations.
>
> Slap the two bugs in one go by taking the kvm->mmu_lock on assigning
> vncr_tlb, preventing the race for good, and by checking that vncr_tlb
> is indeed NULL prior to allocation.
>
> Reported-by: Sashiko <sashiko-bot@kernel.org>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> Link: https://lore.kernel.org/r/20260607180815.85FBC1F00893@smtp.kernel.org
Reviewed-by: Oliver Upton <oupton@kernel.org>
Thanks,
Oliver
> ---
> arch/arm64/kvm/nested.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
> index 690b8e8564166..d11e36b3cfcc2 100644
> --- a/arch/arm64/kvm/nested.c
> +++ b/arch/arm64/kvm/nested.c
> @@ -1253,8 +1253,14 @@ int kvm_vcpu_allocate_vncr_tlb(struct kvm_vcpu *vcpu)
> if (!kvm_has_feat(vcpu->kvm, ID_AA64MMFR4_EL1, NV_frac, NV2_ONLY))
> return 0;
>
> - vcpu->arch.vncr_tlb = kzalloc_obj(*vcpu->arch.vncr_tlb,
> - GFP_KERNEL_ACCOUNT);
> + if (!vcpu->arch.vncr_tlb) {
> + struct vncr_tlb *vt = kzalloc_obj(*vcpu->arch.vncr_tlb,
> + GFP_KERNEL_ACCOUNT);
> +
> + scoped_guard(write_lock, &vcpu->kvm->mmu_lock)
> + vcpu->arch.vncr_tlb = vt;
> + }
> +
> if (!vcpu->arch.vncr_tlb)
> return -ENOMEM;
>
> --
> 2.47.3
>
^ permalink raw reply
* Re: [PATCH v2 4/6] ACPI: irq: Move RISC-V interrupt controllers autodep to ACPI IRQ code
From: Sunil V L @ 2026-06-08 16:38 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Rafael J. Wysocki, Len Brown, Sunil V L, Marc Zyngier,
Thomas Gleixner, Huacai Chen, Anup Patel, Hanjun Guo,
Sudeep Holla, Catalin Marinas, Will Deacon, linux-riscv,
linux-kernel, linux-acpi, linux-arm-kernel, loongarch
In-Reply-To: <20260603-gic-v5-acpi-iwb-probe-deferral-v2-4-23ffa16b6ebb@kernel.org>
On Wed, Jun 3, 2026 at 1:54 PM Lorenzo Pieralisi <lpieralisi@kernel.org> wrote:
>
> RISC-V implements arch code to detect probe dependencies for devices and
> the interrupt controller the devices GSIs are routed to.
>
> The code itself is arch agnostic apart from an arch specific helper
> function required to retrieve the acpi_handle of the interrupt controller
> that manages the device GSI interrupt.
>
> In order to enable IRQ probe dependencies detection on other architectures,
> move RISC-V IRQ probe dependency detection code to generic ACPI IRQ code.
>
> Allow interrupt controller drivers to register an arch specific function to
> determine the acpi_handle for a specific GSI number to use the mechanism if
> needed by the respective interrupt controller drivers.
>
> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
> Cc: Huacai Chen <chenhuacai@kernel.org>
> Cc: Thomas Gleixner <tglx@kernel.org>
> Cc: Anup Patel <anup@brainfault.org>
> Cc: "Rafael J. Wysocki" <rafael@kernel.org>
> Cc: Sunil V L <sunilvl@ventanamicro.com>
> Cc: Marc Zyngier <maz@kernel.org>
> ---
> arch/riscv/include/asm/acpi.h | 1 +
> drivers/acpi/irq.c | 172 +++++++++++++++++++++++++++++++++++-
> drivers/acpi/riscv/irq.c | 156 +-------------------------------
> drivers/irqchip/irq-gic-v3.c | 2 +-
> drivers/irqchip/irq-gic-v5.c | 2 +-
> drivers/irqchip/irq-gic.c | 2 +-
> drivers/irqchip/irq-loongarch-cpu.c | 2 +-
> drivers/irqchip/irq-riscv-intc.c | 3 +-
> include/linux/acpi.h | 5 +-
> 9 files changed, 181 insertions(+), 164 deletions(-)
>
LGTM.
Reviewed-by: Sunil V L <sunilvl@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH] ARM: footbridge: convert to sparse IRQs
From: Ethan Nelson-Moore @ 2026-06-08 16:40 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-arm-kernel, linux-input, linux-serial, Russell King,
Arnd Bergmann, Greg Kroah-Hartman, Dmitry Torokhov, Jiri Slaby,
Russell King (Oracle), Kees Cook, Nathan Chancellor,
Sebastian Andrzej Siewior, Steven Rostedt, Thomas Weissschuh,
Peter Zijlstra
In-Reply-To: <CAD++jLmUW4KjxEjwv7_an_dEMTSOtvG=q2MjhqKvnuGrWaaCsQ@mail.gmail.com>
Hi, Linus,
On Mon, Jun 8, 2026 at 1:50 AM Linus Walleij <linusw@kernel.org> wrote:
> Have you tested this on real hardware?
> The commit doesn't really say.
No, I haven't. I can try to test it in GXemul, but I'm not sure if it
can boot Linux. The developer only lists it as capable of booting
NetBSD.
Ethan
^ permalink raw reply
* Re: [RFC PATCH 2/2] firmware: arm_scmi: Add bus support for autoloading
From: Cristian Marussi @ 2026-06-08 16:51 UTC (permalink / raw)
To: Daniel Lezcano
Cc: Cristian Marussi, arm-scmi, guomin_chen, linux-arm-kernel,
peng.fan, quic_xinqzhan, sudeep.holla
In-Reply-To: <aibW10NMmzw3QnZ5@mai.linaro.org>
On Mon, Jun 08, 2026 at 04:51:03PM +0200, Daniel Lezcano wrote:
> On Mon, Feb 03, 2025 at 10:01:54AM +0000, Cristian Marussi wrote:
> > Emit proper MODALIAS uevents when SCMI devices are created and make sure
> > all the standard protocol devices are requested when the bus is
> > initialized.
> >
> > Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
> > ---
>
> Hi Cristian,
>
Hi Daniel,
nice to hear from you in the SCMI land :P
> what is the status of this patch ?
....I'd say forgotten/abandoned...I worked on that a bit when I realized
only part of the stack was autoloaded...then it did NOT received much
love and then I forgot it....buried by other prios....
Indeed I have still the local branch...but after a quick check I think
is the same as the RFC posted.
bbd14b0f7733 firmware: arm_scmi: Add bus support for autoloading
8d982393b505 firmware: arm_scmi: Generate aliases for SCMI modules
383c127faa97 (scmi_vendors_autoload_V2) firmware: arm_scmi: Add aliases to transport modules
00caa894bce2 firmware: arm_scmi: Add module aliases to i.MX vendor protocols
d900620c46bb firmware: arm_scmi: Support vendor protocol modules autoloading
4fe57bbeb6dc firmware: arm_scmi: Allow transport properties for multiple instances
ad236e5a7f01 Linux 6.13-rc1
...where scmi_vendors_autoload_V2 is merged already...
Thoughts ? Plans ?
Thanks,
Cristian
^ permalink raw reply
* Re: [PATCH v3] coresight: etm3x: Fix cntr_val_show() to match cntr_val_store() behavior
From: Kuan-Wei Chiu @ 2026-06-08 16:55 UTC (permalink / raw)
To: Suzuki K Poulose
Cc: James Clark, mike.leach, alexander.shishkin, gregkh,
mathieu.poirier, leo.yan, Al.Grant, jserv, marscheng, ericchancf,
milesjiang, nickpan, coresight, linux-arm-kernel, linux-kernel,
stable
In-Reply-To: <ac-BEX0Rfe9RBJJn@google.com>
Hi Suzuki,
On Fri, Apr 03, 2026 at 04:57:59PM +0800, Kuan-Wei Chiu wrote:
> Hi Suzuki,
>
> On Mon, Feb 02, 2026 at 09:33:59AM +0000, Suzuki K Poulose wrote:
> > Hello
> >
> > On 02/02/2026 05:09, Kuan-Wei Chiu wrote:
> > > On Tue, Dec 02, 2025 at 09:26:19AM +0000, James Clark wrote:
> > > >
> > > >
> > > > On 02/12/2025 8:26 am, Kuan-Wei Chiu wrote:
> > > > > The cntr_val_show() function was intended to print the values of all
> > > > > counters using a loop. However, due to a buffer overwrite issue with
> > > > > sprintf(), it effectively only displayed the value of the last counter.
> > > > >
> > > > > The companion function, cntr_val_store(), allows users to modify a
> > > > > specific counter selected by 'cntr_idx'. To maintain consistency
> > > > > between read and write operations and to align with the ETM4x driver
> > > > > behavior, modify cntr_val_show() to report only the value of the
> > > > > currently selected counter.
> > > > >
> > > > > This change removes the loop and the "counter %d:" prefix, printing
> > > > > only the hexadecimal value. It also adopts sysfs_emit() for standard
> > > > > sysfs output formatting.
> > > > >
> > > > > Fixes: a939fc5a71ad ("coresight-etm: add CoreSight ETM/PTM driver")
> > > > > Cc: stable@vger.kernel.org
> > > > > Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
> > > > > ---
> > > > > Build test only.
> > > > >
> > > > > Changes in v3:
> > > > > - Switch format specifier to %#x to include the 0x prefix.
> > > > > - Add Cc stable
> > > > >
> > > > > v2: https://lore.kernel.org/lkml/20251201095228.1905489-1-visitorckw@gmail.com/
> > > > >
> > > > > .../hwtracing/coresight/coresight-etm3x-sysfs.c | 15 ++++-----------
> > > > > 1 file changed, 4 insertions(+), 11 deletions(-)
> > > > >
> > > > > diff --git a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
> > > > > index 762109307b86..b3c67e96a82a 100644
> > > > > --- a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
> > > > > +++ b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
> > > > > @@ -717,26 +717,19 @@ static DEVICE_ATTR_RW(cntr_rld_event);
> > > > > static ssize_t cntr_val_show(struct device *dev,
> > > > > struct device_attribute *attr, char *buf)
> > > > > {
> > > > > - int i, ret = 0;
> > > > > u32 val;
> > > > > struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
> > > > > struct etm_config *config = &drvdata->config;
> > > > > if (!coresight_get_mode(drvdata->csdev)) {
> > > > > spin_lock(&drvdata->spinlock);
> > > > > - for (i = 0; i < drvdata->nr_cntr; i++)
> > > > > - ret += sprintf(buf, "counter %d: %x\n",
> > > > > - i, config->cntr_val[i]);
> > > > > + val = config->cntr_val[config->cntr_idx];
> > > > > spin_unlock(&drvdata->spinlock);
> > > > > - return ret;
> > > > > - }
> > > > > -
> > > > > - for (i = 0; i < drvdata->nr_cntr; i++) {
> > > > > - val = etm_readl(drvdata, ETMCNTVRn(i));
> > > > > - ret += sprintf(buf, "counter %d: %x\n", i, val);
> > > > > + } else {
> > > > > + val = etm_readl(drvdata, ETMCNTVRn(config->cntr_idx));
> > > > > }
> > > > > - return ret;
> > > > > + return sysfs_emit(buf, "%#x\n", val);
> > > > > }
> > > > > static ssize_t cntr_val_store(struct device *dev,
> > > >
> > > > Reviewed-by: James Clark <james.clark@linaro.org>
> > > >
> > > Thanks for the review!
> > > Is there anything else I need to do for this fix to land?
> >
> > Thanks for the patch, I will queue this for the next release (v7.1).
> >
> Just a gentle ping.
>
> Since the v7.1 merge window is presumably opening in about a week, I
> noticed this patch isn't in linux-next yet and wanted to send a quick
> reminder. Thanks.
>
This patch still applies cleanly on top of linux-next.
I suspect this patch may have fallen through the cracks.
Would you still be willing to pick it up?
Regards,
Kuan-Wei
^ permalink raw reply
* [PATCH v2 0/7] KVM: arm64: Forward FFA_NOTIFICATION* calls to TrustZone
From: Sebastian Ene @ 2026-06-08 16:55 UTC (permalink / raw)
To: catalin.marinas, maz, oupton, will
Cc: joey.gouly, korneld, kvmarm, linux-arm-kernel, linux-kernel,
android-kvm, mrigendra.chaubey, perlarsen, sebastianene,
suzuki.poulose, vdonnefort, yuzenghui
Remove the FFA_NOTIFICATION* calls from the blocklist used by the pKVM
FF-A proxy. This restriction was preventing the use of asynchronous
signaling mechanisms defined by the Arm FF-A specification to
communicate with the secure services.
While these calls are markes as optional, there is no reason why the
hypervisor proxy would block them because:
1. Host is the Sole Non-Secure Endpoint: The Host operates as the
only Non-Secure VM ID (VM ID 0) recognized by the Secure World.
Because all forwarded notifications are inherently attributed to
the Host by the SPMC, there is no risk of VM ID spoofing
originating from the Normal World.
2. No Memory Pointers or Addresses: The FFA_NOTIFICATION_* ABIs
operate strictly via register-based parameters, passing only
VM IDs, VCPU IDs, flags, and bitmaps. Because these calls do
not contain memory addresses, offsets, or pointers, forwarding
them doesn't pose a risk of memory-based confused deputy attack
(e.g., tricking the SPMC into overwriting protected memory).
While the pKVM proxy behaves as a relayer, it doesn't currently have its
own FF-A ID(only the host has the ID 0). The behavior of the setup
flow is covered by the spec in the: '10.9 Notification support without
a Hypervisor'.
---
Changes in v2:
- enforce the MBZ/SBZ fields
- split the calls into separate patches
- rebase on 7.1-rc7
Link to v1:
https://lore.kernel.org/all/20260501114447.2389222-2-sebastianene@google.com/
Sebastian Ene (7):
KVM: arm64: Support FFA_NOTIFICATION_BITMAP_CREATE in host handler
KVM: arm64: Support FFA_NOTIFICATION_BITMAP_DESTROY in host handler
KVM: arm64: Support FFA_NOTIFICATION_BIND in host handler
KVM: arm64: Support FFA_NOTIFICATION_UNBIND in host handler
KVM: arm64: Support FFA_NOTIFICATION_SET in host handler
KVM: arm64: Support FFA_NOTIFICATION_GET in host handler
KVM: arm64: Support FFA_NOTIFICATION_INFO_GET in host handler
arch/arm64/kvm/hyp/nvhe/ffa.c | 190 ++++++++++++++++++++++++++++++++--
1 file changed, 182 insertions(+), 8 deletions(-)
--
2.54.0.1064.gd145956f57-goog
^ permalink raw reply
* [PATCH v2 1/7] KVM: arm64: Support FFA_NOTIFICATION_BITMAP_CREATE in host handler
From: Sebastian Ene @ 2026-06-08 16:55 UTC (permalink / raw)
To: catalin.marinas, maz, oupton, will
Cc: joey.gouly, korneld, kvmarm, linux-arm-kernel, linux-kernel,
android-kvm, mrigendra.chaubey, perlarsen, sebastianene,
suzuki.poulose, vdonnefort, yuzenghui
In-Reply-To: <20260608165549.1479409-1-sebastianene@google.com>
Allow FF-A notification bitmap creation messages to be forwarded to
Trustzone from the host and introduce a helper to check for SBZ
register fields.
Signed-off-by: Sebastian Ene <sebastianene@google.com>
---
arch/arm64/kvm/hyp/nvhe/ffa.c | 36 ++++++++++++++++++++++++++++++++++-
1 file changed, 35 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
index 1af722771178..c20d45191085 100644
--- a/arch/arm64/kvm/hyp/nvhe/ffa.c
+++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
@@ -71,6 +71,18 @@ static u32 hyp_ffa_version;
static bool has_version_negotiated;
static hyp_spinlock_t version_lock;
+static bool ffa_check_unused_args_sbz(struct kvm_cpu_context *ctxt, int first_reg)
+{
+ int reg;
+
+ for (reg = first_reg; reg < 17; reg++) {
+ if (cpu_reg(ctxt, reg))
+ return true;
+ }
+
+ return false;
+}
+
static void ffa_to_smccc_error(struct arm_smccc_1_2_regs *res, u64 ffa_errno)
{
*res = (struct arm_smccc_1_2_regs) {
@@ -676,7 +688,6 @@ static bool ffa_call_supported(u64 func_id)
case FFA_MEM_DONATE:
case FFA_MEM_RETRIEVE_REQ:
/* Optional notification interfaces added in FF-A 1.1 */
- case FFA_NOTIFICATION_BITMAP_CREATE:
case FFA_NOTIFICATION_BITMAP_DESTROY:
case FFA_NOTIFICATION_BIND:
case FFA_NOTIFICATION_UNBIND:
@@ -862,6 +873,26 @@ static void do_ffa_part_get(struct arm_smccc_1_2_regs *res,
hyp_spin_unlock(&host_buffers.lock);
}
+static void do_ffa_notif_bitmap_create(struct arm_smccc_1_2_regs *res,
+ struct kvm_cpu_context *ctxt)
+{
+ DECLARE_REG(u32, vmid, ctxt, 1);
+ struct arm_smccc_1_2_regs *args;
+
+ if (ffa_check_unused_args_sbz(ctxt, 3)) {
+ ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
+ return;
+ }
+
+ if (vmid != HOST_FFA_ID) {
+ ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
+ return;
+ }
+
+ args = (void *)&ctxt->regs.regs[0];
+ arm_smccc_1_2_smc(args, res);
+}
+
bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
{
struct arm_smccc_1_2_regs res;
@@ -920,6 +951,9 @@ bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
case FFA_PARTITION_INFO_GET:
do_ffa_part_get(&res, host_ctxt);
goto out_handled;
+ case FFA_NOTIFICATION_BITMAP_CREATE:
+ do_ffa_notif_bitmap_create(&res, host_ctxt);
+ goto out_handled;
}
if (ffa_call_supported(func_id))
--
2.54.0.1064.gd145956f57-goog
^ permalink raw reply related
* [PATCH v2 5/7] KVM: arm64: Support FFA_NOTIFICATION_SET in host handler
From: Sebastian Ene @ 2026-06-08 16:55 UTC (permalink / raw)
To: catalin.marinas, maz, oupton, will
Cc: joey.gouly, korneld, kvmarm, linux-arm-kernel, linux-kernel,
android-kvm, mrigendra.chaubey, perlarsen, sebastianene,
suzuki.poulose, vdonnefort, yuzenghui
In-Reply-To: <20260608165549.1479409-1-sebastianene@google.com>
Allow FF-A notification SET messages to be proxied from the pKVM
hypervisor to Trustzone and enforce MBZ/SBZ fields.
Signed-off-by: Sebastian Ene <sebastianene@google.com>
---
arch/arm64/kvm/hyp/nvhe/ffa.c | 30 +++++++++++++++++++++++++++++-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
index ca285e89516e..3270381679b4 100644
--- a/arch/arm64/kvm/hyp/nvhe/ffa.c
+++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
@@ -690,7 +690,6 @@ static bool ffa_call_supported(u64 func_id)
case FFA_MEM_DONATE:
case FFA_MEM_RETRIEVE_REQ:
/* Optional notification interfaces added in FF-A 1.1 */
- case FFA_NOTIFICATION_SET:
case FFA_NOTIFICATION_GET:
case FFA_NOTIFICATION_INFO_GET:
/* Optional interfaces added in FF-A 1.2 */
@@ -959,6 +958,32 @@ static void do_ffa_notif_unbind(struct arm_smccc_1_2_regs *res,
arm_smccc_1_2_smc(args, res);
}
+static void do_ffa_notif_set(struct arm_smccc_1_2_regs *res,
+ struct kvm_cpu_context *ctxt)
+{
+ DECLARE_REG(u32, endp_id, ctxt, 1);
+ DECLARE_REG(u32, flags, ctxt, 2);
+ struct arm_smccc_1_2_regs *args;
+
+ if (FIELD_GET(FFA_NOTIF_SENDER_ENDP_MASK, endp_id) != HOST_FFA_ID) {
+ ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
+ return;
+ }
+
+ if (ffa_check_unused_args_sbz(ctxt, 5)) {
+ ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
+ return;
+ }
+
+ if (flags & GENMASK(15, 2)) {
+ ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
+ return;
+ }
+
+ args = (void *)&ctxt->regs.regs[0];
+ arm_smccc_1_2_smc(args, res);
+}
+
bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
{
struct arm_smccc_1_2_regs res;
@@ -1029,6 +1054,9 @@ bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
case FFA_NOTIFICATION_UNBIND:
do_ffa_notif_unbind(&res, host_ctxt);
goto out_handled;
+ case FFA_NOTIFICATION_SET:
+ do_ffa_notif_set(&res, host_ctxt);
+ goto out_handled;
}
if (ffa_call_supported(func_id))
--
2.54.0.1064.gd145956f57-goog
^ permalink raw reply related
* [PATCH v2 3/7] KVM: arm64: Support FFA_NOTIFICATION_BIND in host handler
From: Sebastian Ene @ 2026-06-08 16:55 UTC (permalink / raw)
To: catalin.marinas, maz, oupton, will
Cc: joey.gouly, korneld, kvmarm, linux-arm-kernel, linux-kernel,
android-kvm, mrigendra.chaubey, perlarsen, sebastianene,
suzuki.poulose, vdonnefort, yuzenghui
In-Reply-To: <20260608165549.1479409-1-sebastianene@google.com>
Verify the arguments of the FF-A notification bind call and forward the
message to Trustzone.
Signed-off-by: Sebastian Ene <sebastianene@google.com>
---
arch/arm64/kvm/hyp/nvhe/ffa.c | 32 +++++++++++++++++++++++++++++++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
index 91e89d889c44..eedb01955a45 100644
--- a/arch/arm64/kvm/hyp/nvhe/ffa.c
+++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
@@ -42,6 +42,8 @@
*/
#define HOST_FFA_ID 0
+#define FFA_NOTIF_SENDER_ENDP_MASK GENMASK(31, 16)
+
/*
* A buffer to hold the maximum descriptor size we can see from the host,
* which is required when the SPMD returns a fragmented FFA_MEM_RETRIEVE_RESP
@@ -688,7 +690,6 @@ static bool ffa_call_supported(u64 func_id)
case FFA_MEM_DONATE:
case FFA_MEM_RETRIEVE_REQ:
/* Optional notification interfaces added in FF-A 1.1 */
- case FFA_NOTIFICATION_BIND:
case FFA_NOTIFICATION_UNBIND:
case FFA_NOTIFICATION_SET:
case FFA_NOTIFICATION_GET:
@@ -912,6 +913,32 @@ static void do_ffa_notif_bitmap_destroy(struct arm_smccc_1_2_regs *res,
arm_smccc_1_2_smc(args, res);
}
+static void do_ffa_notif_bind(struct arm_smccc_1_2_regs *res,
+ struct kvm_cpu_context *ctxt)
+{
+ DECLARE_REG(u32, endp_id, ctxt, 1);
+ DECLARE_REG(u32, flags, ctxt, 2);
+ struct arm_smccc_1_2_regs *args;
+
+ if (ffa_check_unused_args_sbz(ctxt, 5)) {
+ ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
+ return;
+ }
+
+ if (FIELD_GET(FFA_NOTIF_SENDER_ENDP_MASK, endp_id) != HOST_FFA_ID) {
+ ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
+ return;
+ }
+
+ if (flags & GENMASK(31, 1)) {
+ ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
+ return;
+ }
+
+ args = (void *)&ctxt->regs.regs[0];
+ arm_smccc_1_2_smc(args, res);
+}
+
bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
{
struct arm_smccc_1_2_regs res;
@@ -976,6 +1003,9 @@ bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
case FFA_NOTIFICATION_BITMAP_DESTROY:
do_ffa_notif_bitmap_destroy(&res, host_ctxt);
goto out_handled;
+ case FFA_NOTIFICATION_BIND:
+ do_ffa_notif_bind(&res, host_ctxt);
+ goto out_handled;
}
if (ffa_call_supported(func_id))
--
2.54.0.1064.gd145956f57-goog
^ permalink raw reply related
* [PATCH v2 4/7] KVM: arm64: Support FFA_NOTIFICATION_UNBIND in host handler
From: Sebastian Ene @ 2026-06-08 16:55 UTC (permalink / raw)
To: catalin.marinas, maz, oupton, will
Cc: joey.gouly, korneld, kvmarm, linux-arm-kernel, linux-kernel,
android-kvm, mrigendra.chaubey, perlarsen, sebastianene,
suzuki.poulose, vdonnefort, yuzenghui
In-Reply-To: <20260608165549.1479409-1-sebastianene@google.com>
Verify the arguments of the FF-A notification unbind call and forward
the message to Trustzone.
Signed-off-by: Sebastian Ene <sebastianene@google.com>
---
arch/arm64/kvm/hyp/nvhe/ffa.c | 25 ++++++++++++++++++++++++-
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
index eedb01955a45..ca285e89516e 100644
--- a/arch/arm64/kvm/hyp/nvhe/ffa.c
+++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
@@ -690,7 +690,6 @@ static bool ffa_call_supported(u64 func_id)
case FFA_MEM_DONATE:
case FFA_MEM_RETRIEVE_REQ:
/* Optional notification interfaces added in FF-A 1.1 */
- case FFA_NOTIFICATION_UNBIND:
case FFA_NOTIFICATION_SET:
case FFA_NOTIFICATION_GET:
case FFA_NOTIFICATION_INFO_GET:
@@ -939,6 +938,27 @@ static void do_ffa_notif_bind(struct arm_smccc_1_2_regs *res,
arm_smccc_1_2_smc(args, res);
}
+static void do_ffa_notif_unbind(struct arm_smccc_1_2_regs *res,
+ struct kvm_cpu_context *ctxt)
+{
+ DECLARE_REG(u32, endp_id, ctxt, 1);
+ DECLARE_REG(u32, reserved, ctxt, 2);
+ struct arm_smccc_1_2_regs *args;
+
+ if (ffa_check_unused_args_sbz(ctxt, 5) || reserved) {
+ ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
+ return;
+ }
+
+ if (FIELD_GET(FFA_NOTIF_SENDER_ENDP_MASK, endp_id) != HOST_FFA_ID) {
+ ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
+ return;
+ }
+
+ args = (void *)&ctxt->regs.regs[0];
+ arm_smccc_1_2_smc(args, res);
+}
+
bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
{
struct arm_smccc_1_2_regs res;
@@ -1006,6 +1026,9 @@ bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
case FFA_NOTIFICATION_BIND:
do_ffa_notif_bind(&res, host_ctxt);
goto out_handled;
+ case FFA_NOTIFICATION_UNBIND:
+ do_ffa_notif_unbind(&res, host_ctxt);
+ goto out_handled;
}
if (ffa_call_supported(func_id))
--
2.54.0.1064.gd145956f57-goog
^ permalink raw reply related
* [PATCH v2 2/7] KVM: arm64: Support FFA_NOTIFICATION_BITMAP_DESTROY in host handler
From: Sebastian Ene @ 2026-06-08 16:55 UTC (permalink / raw)
To: catalin.marinas, maz, oupton, will
Cc: joey.gouly, korneld, kvmarm, linux-arm-kernel, linux-kernel,
android-kvm, mrigendra.chaubey, perlarsen, sebastianene,
suzuki.poulose, vdonnefort, yuzenghui
In-Reply-To: <20260608165549.1479409-1-sebastianene@google.com>
Allow FF-A notification bitmap destruction messages to be forwarded to
Trustzone from the host.
Signed-off-by: Sebastian Ene <sebastianene@google.com>
---
arch/arm64/kvm/hyp/nvhe/ffa.c | 24 +++++++++++++++++++++++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
index c20d45191085..91e89d889c44 100644
--- a/arch/arm64/kvm/hyp/nvhe/ffa.c
+++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
@@ -688,7 +688,6 @@ static bool ffa_call_supported(u64 func_id)
case FFA_MEM_DONATE:
case FFA_MEM_RETRIEVE_REQ:
/* Optional notification interfaces added in FF-A 1.1 */
- case FFA_NOTIFICATION_BITMAP_DESTROY:
case FFA_NOTIFICATION_BIND:
case FFA_NOTIFICATION_UNBIND:
case FFA_NOTIFICATION_SET:
@@ -893,6 +892,26 @@ static void do_ffa_notif_bitmap_create(struct arm_smccc_1_2_regs *res,
arm_smccc_1_2_smc(args, res);
}
+static void do_ffa_notif_bitmap_destroy(struct arm_smccc_1_2_regs *res,
+ struct kvm_cpu_context *ctxt)
+{
+ DECLARE_REG(u32, vmid, ctxt, 1);
+ struct arm_smccc_1_2_regs *args;
+
+ if (ffa_check_unused_args_sbz(ctxt, 2)) {
+ ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
+ return;
+ }
+
+ if (vmid != HOST_FFA_ID) {
+ ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
+ return;
+ }
+
+ args = (void *)&ctxt->regs.regs[0];
+ arm_smccc_1_2_smc(args, res);
+}
+
bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
{
struct arm_smccc_1_2_regs res;
@@ -954,6 +973,9 @@ bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
case FFA_NOTIFICATION_BITMAP_CREATE:
do_ffa_notif_bitmap_create(&res, host_ctxt);
goto out_handled;
+ case FFA_NOTIFICATION_BITMAP_DESTROY:
+ do_ffa_notif_bitmap_destroy(&res, host_ctxt);
+ goto out_handled;
}
if (ffa_call_supported(func_id))
--
2.54.0.1064.gd145956f57-goog
^ permalink raw reply related
* [PATCH v2 6/7] KVM: arm64: Support FFA_NOTIFICATION_GET in host handler
From: Sebastian Ene @ 2026-06-08 16:55 UTC (permalink / raw)
To: catalin.marinas, maz, oupton, will
Cc: joey.gouly, korneld, kvmarm, linux-arm-kernel, linux-kernel,
android-kvm, mrigendra.chaubey, perlarsen, sebastianene,
suzuki.poulose, vdonnefort, yuzenghui
In-Reply-To: <20260608165549.1479409-1-sebastianene@google.com>
Allow FF-A notification GET messages to be proxied from the pKVM
hypervisor to Trustzone and enforce MBZ/SBZ fields.
Signed-off-by: Sebastian Ene <sebastianene@google.com>
---
arch/arm64/kvm/hyp/nvhe/ffa.c | 24 +++++++++++++++++++++++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
index 3270381679b4..28b6cb0e14c4 100644
--- a/arch/arm64/kvm/hyp/nvhe/ffa.c
+++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
@@ -690,7 +690,6 @@ static bool ffa_call_supported(u64 func_id)
case FFA_MEM_DONATE:
case FFA_MEM_RETRIEVE_REQ:
/* Optional notification interfaces added in FF-A 1.1 */
- case FFA_NOTIFICATION_GET:
case FFA_NOTIFICATION_INFO_GET:
/* Optional interfaces added in FF-A 1.2 */
case FFA_MSG_SEND_DIRECT_REQ2: /* Optional per 7.5.1 */
@@ -984,6 +983,26 @@ static void do_ffa_notif_set(struct arm_smccc_1_2_regs *res,
arm_smccc_1_2_smc(args, res);
}
+static void do_ffa_notif_get(struct arm_smccc_1_2_regs *res,
+ struct kvm_cpu_context *ctxt)
+{
+ DECLARE_REG(u32, flags, ctxt, 2);
+ struct arm_smccc_1_2_regs *args;
+
+ if (ffa_check_unused_args_sbz(ctxt, 3)) {
+ ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
+ return;
+ }
+
+ if (flags & GENMASK(31, 4)) {
+ ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
+ return;
+ }
+
+ args = (void *)&ctxt->regs.regs[0];
+ arm_smccc_1_2_smc(args, res);
+}
+
bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
{
struct arm_smccc_1_2_regs res;
@@ -1057,6 +1076,9 @@ bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
case FFA_NOTIFICATION_SET:
do_ffa_notif_set(&res, host_ctxt);
goto out_handled;
+ case FFA_NOTIFICATION_GET:
+ do_ffa_notif_get(&res, host_ctxt);
+ goto out_handled;
}
if (ffa_call_supported(func_id))
--
2.54.0.1064.gd145956f57-goog
^ permalink raw reply related
* [PATCH v2 7/7] KVM: arm64: Support FFA_NOTIFICATION_INFO_GET in host handler
From: Sebastian Ene @ 2026-06-08 16:55 UTC (permalink / raw)
To: catalin.marinas, maz, oupton, will
Cc: joey.gouly, korneld, kvmarm, linux-arm-kernel, linux-kernel,
android-kvm, mrigendra.chaubey, perlarsen, sebastianene,
suzuki.poulose, vdonnefort, yuzenghui
In-Reply-To: <20260608165549.1479409-1-sebastianene@google.com>
Allow the host to query the FF-A notifiction status and proxy the info
get message to Trustzone. Make sure that the SBZ fields are enforced.
Signed-off-by: Sebastian Ene <sebastianene@google.com>
---
arch/arm64/kvm/hyp/nvhe/ffa.c | 19 +++++++++++++++++--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
index 28b6cb0e14c4..463a845557f9 100644
--- a/arch/arm64/kvm/hyp/nvhe/ffa.c
+++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
@@ -689,8 +689,6 @@ static bool ffa_call_supported(u64 func_id)
case FFA_RXTX_MAP:
case FFA_MEM_DONATE:
case FFA_MEM_RETRIEVE_REQ:
- /* Optional notification interfaces added in FF-A 1.1 */
- case FFA_NOTIFICATION_INFO_GET:
/* Optional interfaces added in FF-A 1.2 */
case FFA_MSG_SEND_DIRECT_REQ2: /* Optional per 7.5.1 */
case FFA_MSG_SEND_DIRECT_RESP2: /* Optional per 7.5.1 */
@@ -1003,6 +1001,20 @@ static void do_ffa_notif_get(struct arm_smccc_1_2_regs *res,
arm_smccc_1_2_smc(args, res);
}
+static void do_ffa_notif_info_get(struct arm_smccc_1_2_regs *res,
+ struct kvm_cpu_context *ctxt)
+{
+ struct arm_smccc_1_2_regs *args;
+
+ if (ffa_check_unused_args_sbz(ctxt, 1)) {
+ ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
+ return;
+ }
+
+ args = (void *)&ctxt->regs.regs[0];
+ arm_smccc_1_2_smc(args, res);
+}
+
bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
{
struct arm_smccc_1_2_regs res;
@@ -1079,6 +1091,9 @@ bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
case FFA_NOTIFICATION_GET:
do_ffa_notif_get(&res, host_ctxt);
goto out_handled;
+ case FFA_NOTIFICATION_INFO_GET:
+ do_ffa_notif_info_get(&res, host_ctxt);
+ goto out_handled;
}
if (ffa_call_supported(func_id))
--
2.54.0.1064.gd145956f57-goog
^ permalink raw reply related
* Re: [PATCH] ARM: footbridge: convert to sparse IRQs
From: Dmitry Torokhov @ 2026-06-08 16:56 UTC (permalink / raw)
To: Ethan Nelson-Moore
Cc: linux-arm-kernel, linux-input, linux-serial, Russell King,
Arnd Bergmann, Greg Kroah-Hartman, Jiri Slaby,
Russell King (Oracle), Linus Walleij, Kees Cook,
Nathan Chancellor, Sebastian Andrzej Siewior, Steven Rostedt,
Thomas Weissschuh, Peter Zijlstra
In-Reply-To: <20260510052107.555825-1-enelsonmoore@gmail.com>
Hi Ethan,
On Sat, May 09, 2026 at 10:20:49PM -0700, Ethan Nelson-Moore wrote:
> diff --git a/drivers/input/serio/i8042-io.h b/drivers/input/serio/i8042-io.h
> index a8f4b2d70e59..cea72bd888af 100644
> --- a/drivers/input/serio/i8042-io.h
> +++ b/drivers/input/serio/i8042-io.h
> @@ -15,9 +15,9 @@
> * IRQs.
> */
>
> -#if defined(__arm__)
> -/* defined in include/asm-arm/arch-xxx/irqs.h */
> -#include <asm/irq.h>
> +#ifdef CONFIG_ARCH_FOOTBRIDGE
> +/* defined in arch/arm/mach-footbridge/include/mach/irqs.h */
> +#include <mach/irqs.h>
> #elif defined(CONFIG_PPC)
> extern int of_i8042_kbd_irq;
> extern int of_i8042_aux_irq;
This does not look right. Did you mean to drop inclusion of asm/irq.h
for all other arms?
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2 49/78] drm/mediatek: dp: Switch to atomic_create_state
From: AngeloGioacchino Del Regno @ 2026-06-08 15:32 UTC (permalink / raw)
To: Maxime Ripard, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Luca Ceresoli,
Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter
Cc: Dmitry Baryshkov, dri-devel, Chun-Kuang Hu, Philipp Zabel,
Matthias Brugger, linux-mediatek, linux-kernel, linux-arm-kernel
In-Reply-To: <20260608-drm-no-more-bridge-reset-v2-49-0a91018bf886@kernel.org>
On 6/8/26 16:36, Maxime Ripard wrote:
> The drm_bridge_funcs.atomic_reset callback and its
> drm_atomic_helper_bridge_reset() helper are deprecated.
>
> Switch to the atomic_create_state callback and its
> drm_atomic_helper_bridge_create_state() counterpart.
>
> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> To: Chun-Kuang Hu <chunkuang.hu@kernel.org>
> To: Philipp Zabel <p.zabel@pengutronix.de>
> To: Matthias Brugger <matthias.bgg@gmail.com>
> To: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-mediatek@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
^ 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