* Re: [PATCH RFC 1/2] arm64: vdso: Prepare for robust futex unlock support
From: Thomas Weißschuh @ 2026-04-22 13:02 UTC (permalink / raw)
To: André Almeida
Cc: Catalin Marinas, Will Deacon, Thomas Gleixner, Mark Rutland,
Mathieu Desnoyers, Sebastian Andrzej Siewior, Carlos O'Donell,
Peter Zijlstra, Florian Weimer, Rich Felker, Torvald Riegel,
Darren Hart, Ingo Molnar, Davidlohr Bueso, Arnd Bergmann,
Liam R . Howlett, Uros Bizjak, linux-arm-kernel, linux-kernel,
linux-arch, kernel-dev
In-Reply-To: <20260417-tonyk-robust_arm-v1-1-03aa64e2ff1a@igalia.com>
On 2026-04-17 11:56:10-0300, André Almeida wrote:
> There will be a VDSO function to unlock non-contended robust futexes in
> user space. The unlock sequence is racy vs. clearing the list_pending_op
> pointer in the task's robust list head. To plug this race the kernel needs
> to know the critical section window so it can clear the pointer when the
> task is interrupted within that race window. The window is determined by
> labels in the inline assembly.
>
> Signed-off-by: André Almeida <andrealmeid@igalia.com>
> ---
> RFC: Those symbols can't be found by the linker after patch 2/2, it fails with:
>
> ld: arch/arm64/kernel/vdso.o: in function `vdso_futex_robust_unlock_update_ips':
> arch/arm64/kernel/vdso.c:72:(.text+0x200): undefined reference to `__futex_list64_try_unlock_cs_success'
> ld: arch/arm64/kernel/vdso.o: relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `__futex_list64_try_unlock_cs_success' which may bind externally can not be used when making a shared object; recompile with -fPIC
> arch/arm64/kernel/vdso.c:72:(.text+0x200): dangerous relocation: unsupported relocation
arch/arm64/kernel/vdso.o is a kernel object.
__futex_list64_try_unlock_cs_success is a vDSO symbol.
They live in wholly different objects, which are never linked together.
Look at VDSO_SYMBOL() to get the offset of the vDSO symbol in kernel code.
(...)
Thomas
^ permalink raw reply
* Re: [REGRESSION] rseq: refactoring in v6.19 broke everyone on arm64 and tcmalloc everywhere
From: Peter Zijlstra @ 2026-04-22 12:56 UTC (permalink / raw)
To: Mathias Stearn
Cc: Thomas Gleixner, Mathieu Desnoyers, Catalin Marinas, Will Deacon,
Boqun Feng, Paul E. McKenney, Chris Kennelly, Dmitry Vyukov,
regressions, linux-kernel, linux-arm-kernel, Ingo Molnar,
Mark Rutland, Jinjie Ruan, Blake Oler
In-Reply-To: <CAHnCjA25b+nO2n5CeifknSKHssJpPrjnf+dtr7UgzRw4Zgu=oA@mail.gmail.com>
On Wed, Apr 22, 2026 at 11:50:26AM +0200, Mathias Stearn wrote:
> Additionally, it breaks tcmalloc specifically by failing to overwrite
> the cpu_id_start field at points where it was relied on for
> correctness.
This specific behaviour was documented as being wrong and running with
DEBUG_RSEQ would have flagged it.
The tcmalloc issue has been contentious for a long time. The tcmalloc
folks relied on something that was documented to be wrong. It has been
reported to the tcmalloc people many years ago and if you were to run
tcmalloc on most any kernel (very much including 6.19) with
DEBUG_RSEQ=y, it would have yelled.
The tcmalloc people didn't care. There was a proposal for an RSEQ
extension for what they need, and they didn't care. All this should be
in their bugzilla or whatever.
The RSEQ rework improved performance significantly for everyone, and
kept all the documented behaviour (+- arm64 bug). Tcmalloc got screwed
over because they relied on implementation behaviour that was
specifically documented to be broken. And they didn't care. Google was
very much aware of this. And hasn't lifted a finger to remedy it.
^ permalink raw reply
* Re: [PATCH RFC 1/2] arm64: vdso: Prepare for robust futex unlock support
From: Florian Weimer @ 2026-04-22 12:56 UTC (permalink / raw)
To: André Almeida
Cc: Catalin Marinas, Will Deacon, Thomas Gleixner, Mark Rutland,
Mathieu Desnoyers, Sebastian Andrzej Siewior, Carlos O'Donell,
Peter Zijlstra, Rich Felker, Torvald Riegel, Darren Hart,
Ingo Molnar, Davidlohr Bueso, Arnd Bergmann, Liam R . Howlett,
Uros Bizjak, Thomas Weißschuh, linux-arm-kernel,
linux-kernel, linux-arch, kernel-dev
In-Reply-To: <32642d18-8c83-47ad-8456-1813084c4622@igalia.com>
* André Almeida:
> Hi Florian,
>
> Em 17/04/2026 12:08, Florian Weimer escreveu:
>> * André Almeida:
>>
>>> There will be a VDSO function to unlock non-contended robust futexes in
>>> user space. The unlock sequence is racy vs. clearing the list_pending_op
>>> pointer in the task's robust list head. To plug this race the kernel needs
>>> to know the critical section window so it can clear the pointer when the
>>> task is interrupted within that race window. The window is determined by
>>> labels in the inline assembly.
>>>
>>> Signed-off-by: André Almeida <andrealmeid@igalia.com>
>>> ---
>>> RFC: Those symbols can't be found by the linker after patch 2/2, it fails with:
>>>
>>> ld: arch/arm64/kernel/vdso.o: in function `vdso_futex_robust_unlock_update_ips':
>>> arch/arm64/kernel/vdso.c:72:(.text+0x200): undefined reference to `__futex_list64_try_unlock_cs_success'
>>> ld: arch/arm64/kernel/vdso.o: relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `__futex_list64_try_unlock_cs_success' which may bind externally can not be used when making a shared object; recompile with -fPIC
>>> arch/arm64/kernel/vdso.c:72:(.text+0x200): dangerous relocation: unsupported relocation
>> I think your GLOBLS definition adds a 64 suffix. That shouldn't be
>> necessary on AArch64. It's not reflected in the references, so you end
>> up with an undefined symbol error.
>>
>
> Why aarch64 doesn't need the 64 suffix? objdump shows that the final
> label name is __futex_list64_try_unlock_cs_success, which should match
> what the linker is trying to find, AFAIC.
Sorry, I was confused about how this is expected to work.
Florian
^ permalink raw reply
* [PATCH] crypto: testmgr - disallow RSA PKCS#1 SHA-1 sig algs in FIPS mode
From: jeffbarnes @ 2026-04-22 12:49 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Maxime Coquelin, Alexandre Torgue
Cc: linux-crypto, linux-stm32, linux-arm-kernel, linux-kernel,
Jeff Barnes, Jeff Barnes
From: Jeff Barnes <jeffbarnes@microsoft.com>
When booted with fips=1, RSA signature generation using SHA-1 must not be
available. However, pkcs1pad(rsa,sha1) can currently be instantiated
because it is not present in alg_test_descs; alg_test() falls through the
no_test path and succeeds, after which the algorithm appears in /proc/crypto
as fips-capable. 【1-ebd9df】
Add explicit alg_test_descs entries for pkcs1pad(rsa,sha1) and pkcs1(rsa,sha1)
without marking them fips_allowed, so they are treated as not FIPS-allowed
when fips=1 is enabled.
Include both names to cover kernels where RSA sign/verify is provided via
the pkcs1(...) signature template, while pkcs1pad(...) remains for the
traditional wrapper naming and/or RSAES operations. 【2-17cc14】
Signed-off-by: Jeff Barnes <jeffbarnes@linux.microsoft.com>
---
This series fixes an issue where SHA-1 RSA signature generation remains
available when booted with fips=1.
On a FIPS-enabled system, pkcs1pad(rsa,sha1) can be instantiated even
though SHA-1 must not be available for signature generation. The reason
is that the algorithm is not listed in crypto/testmgr.c's alg_test_descs,
so alg_test() falls through the no_test path and succeeds. Once
instantiated, /proc/crypto reports the algorithm as "fips: yes".
This patch adds explicit alg_test_descs entries for:
- pkcs1pad(rsa,sha1)
- pkcs1(rsa,sha1)
without setting fips=1, so they are treated as not FIPS-allowed in
FIPS mode.
Both names are covered to handle kernels where RSA signature operations
are provided via the pkcs1(...) signature template, while pkcs1pad(...)
remains for the historical wrapper naming and/or RSAES operations.
Reproducer / evidence (current behavior):
1) Boot with fips=1 (confirm /proc/sys/crypto/fips_enabled == 1)
2) Allocate the transform:
crypto_alloc_akcipher("pkcs1pad(rsa,sha1)", 0, 0)
3) Observe that /proc/crypto now contains:
name : pkcs1pad(rsa,sha1)
fips : yes
selftest: passed
4) A simple in-kernel demo module can instantiate the transform and reach
the signing path in FIPS mode.
With this change, attempts to instantiate these SHA-1 RSA signing
templates in FIPS mode are rejected, preventing SHA-1 signature
generation in approved mode.
Thanks for taking a look.
Signed-off-by: Jeff Barnes <jeffbarnes@microsoft.com>
---
crypto/testmgr.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 30671e7bc349..e54d298a26c1 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -5306,6 +5306,9 @@ static const struct alg_test_desc alg_test_descs[] = {
.suite = {
.sig = __VECS(pkcs1_rsa_none_tv_template)
}
+ }, {
+ .alg = "pkcs1(rsa,sha1)",
+ .test = alg_test_null,
}, {
.alg = "pkcs1(rsa,sha224)",
.test = alg_test_null,
@@ -5341,6 +5344,9 @@ static const struct alg_test_desc alg_test_descs[] = {
.alg = "pkcs1pad(rsa)",
.test = alg_test_null,
.fips_allowed = 1,
+ }, {
+ .alg = "pkcs1pad(rsa,sha1)",
+ .test = alg_test_null,
}, {
.alg = "rfc3686(ctr(aes))",
.generic_driver = "rfc3686(ctr(aes-lib))",
---
base-commit: 8879a3c110cb8ca5a69c937643f226697aa551d9
change-id: 20260422-disallow_rsa_sha1_signing_in_fips_mode-8fbb6229ad54
Best regards,
--
Jeff Barnes <jeffbarnes@microsoft.com>
^ permalink raw reply related
* Re: [PATCH] net/stmmac: Fix typos: 'tx_undeflow_irq' -> 'tx_underflow_irq'
From: Andrew Lunn @ 2026-04-22 12:47 UTC (permalink / raw)
To: Jakub Raczynski
Cc: netdev, linux-kernel, kuba, davem, andrew+netdev, kernel-janitors,
linux-arm-kernel, linux-stm32
In-Reply-To: <aeiJ3zr4WJAm1UCk@AMDC4622.eu.corp.samsungelectronics.net>
> I don't see anything wrong with it?
> - naming is correct, same as stmmac_extra_stats from common.h, as it
> wouldn't compile otherwise
> - string length is ok, as max name length is ETH_GSTRING_LEN=32 and it is
> not close
> - ethtool just polls data from driver and in my tests it is ok
> - all instances of 'undeflow' are changed
> - 'underflow' semantic is ok, 'undeflow' is just not correct
>
> Please correct me if I am wrong, but imo no issues with this patch.
ABI
This name is published as part of the kAPI. You are changing its
name. User space could be looking for this name, even thought it has a
typo in it.
Andrew
^ permalink raw reply
* Re: [PATCH RFC 1/2] arm64: vdso: Prepare for robust futex unlock support
From: André Almeida @ 2026-04-22 12:46 UTC (permalink / raw)
To: Florian Weimer
Cc: Catalin Marinas, Will Deacon, Thomas Gleixner, Mark Rutland,
Mathieu Desnoyers, Sebastian Andrzej Siewior, Carlos O'Donell,
Peter Zijlstra, Rich Felker, Torvald Riegel, Darren Hart,
Ingo Molnar, Davidlohr Bueso, Arnd Bergmann, Liam R . Howlett,
Uros Bizjak, Thomas Weißschuh, linux-arm-kernel,
linux-kernel, linux-arch, kernel-dev
In-Reply-To: <lhu1pgd8w0f.fsf@oldenburg.str.redhat.com>
Hi Florian,
Em 17/04/2026 12:08, Florian Weimer escreveu:
> * André Almeida:
>
>> There will be a VDSO function to unlock non-contended robust futexes in
>> user space. The unlock sequence is racy vs. clearing the list_pending_op
>> pointer in the task's robust list head. To plug this race the kernel needs
>> to know the critical section window so it can clear the pointer when the
>> task is interrupted within that race window. The window is determined by
>> labels in the inline assembly.
>>
>> Signed-off-by: André Almeida <andrealmeid@igalia.com>
>> ---
>> RFC: Those symbols can't be found by the linker after patch 2/2, it fails with:
>>
>> ld: arch/arm64/kernel/vdso.o: in function `vdso_futex_robust_unlock_update_ips':
>> arch/arm64/kernel/vdso.c:72:(.text+0x200): undefined reference to `__futex_list64_try_unlock_cs_success'
>> ld: arch/arm64/kernel/vdso.o: relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `__futex_list64_try_unlock_cs_success' which may bind externally can not be used when making a shared object; recompile with -fPIC
>> arch/arm64/kernel/vdso.c:72:(.text+0x200): dangerous relocation: unsupported relocation
>
> I think your GLOBLS definition adds a 64 suffix. That shouldn't be
> necessary on AArch64. It's not reflected in the references, so you end
> up with an undefined symbol error.
>
Why aarch64 doesn't need the 64 suffix? objdump shows that the final
label name is __futex_list64_try_unlock_cs_success, which should match
what the linker is trying to find, AFAIC.
André
^ permalink raw reply
* Re: [PATCH 0/3] arm64/virt: Add Arm CCA measurement register support
From: Jason Gunthorpe @ 2026-04-22 12:40 UTC (permalink / raw)
To: Sami Mujawar
Cc: Suzuki Poulose, Dan Williams,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Catalin Marinas, will@kernel.org,
thuth@redhat.com, Steven Price, gshan@redhat.com, Yeoreum Yun,
cedric.xing@intel.com, Dan Williams, Dionna Glaze,
Aneesh Kumar K . V, Alexey Kardashevskiy,
linux-coco@lists.linux.dev
In-Reply-To: <AS8PR08MB680669CBFA9654BC12179D5E842F2@AS8PR08MB6806.eurprd08.prod.outlook.com>
On Wed, Apr 22, 2026 at 08:57:00AM +0000, Sami Mujawar wrote:
> > So this is tying it to the same FW event log that TPM uses.
> >
> > I think that strengthens my point this should all be uninform. TPM
> > drivers are directly exposing the event log today, but I guess that
> > needs generalization if non-TPM drivers are going to present it as
> > well.
> >
> > How do you imagine getting and manipulating the EFI event log to use
> > with this?
>
> The event logs from UEFI will be handed off to the OS using CCEL
> ACPI table. The CCEL table spec update can be seen at
> https://github.com/tianocore/edk2/issues/11384
I ment from linux userspace. event log is well establihsed in the aCPI
side for TPM and in Linux today it is only exposed to userspace
through TPM.
This is not TPM, so how do you intend to give the event log to
userspace?
Jason
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Validate the FF-A memory access descriptor placement
From: Marc Zyngier @ 2026-04-22 12:24 UTC (permalink / raw)
To: Sebastian Ene
Cc: oupton, will, ayrton, catalin.marinas, joey.gouly, korneld,
kvmarm, linux-arm-kernel, linux-kernel, android-kvm,
mrigendra.chaubey, perlarsen, suzuki.poulose, yuzenghui, stable
In-Reply-To: <20260422102540.1433704-1-sebastianene@google.com>
On Wed, 22 Apr 2026 11:25:40 +0100,
Sebastian Ene <sebastianene@google.com> wrote:
>
> Prevent the pKVM hypervisor from making assumptions that the
> endpoint memory access descriptor (EMAD) comes right after the
> FF-A memory region header and enforce a strict placement for it
> when validating an FF-A memory lend/share transaction.
As I read this, you want to remove a bad assumption...
>
> Prior to FF-A version 1.1 the header of the memory region
> didn't contain an offset to the endpoint memory access descriptor.
> The layout of a memory transaction looks like this:
>
> Field name | Offset
> -- 0
> [ Header (ffa_mem_region) |__ ep_mem_offset
> EMAD 1 (ffa_mem_region_attributes) |
> ]
>
> Reject the host from specifying a memory access descriptor offset
> that is different than the size of the memory region header.
And yet you decide that you want to enforce this assumption. I don't
understand how you arrive to this conclusion.
Looking at the spec, it appears that the offset is *designed* to allow
a gap between the header and the EMAD. Refusing to handle a it seems to be a
violation of the spec.
What am I missing?
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH 1/4] arm64: signal: Preserve POR_EL0 if poe_context is missing
From: Will Deacon @ 2026-04-22 12:19 UTC (permalink / raw)
To: Kevin Brodsky
Cc: linux-arm-kernel, linux-kernel, Catalin Marinas, Joey Gouly,
Mark Brown, Shuah Khan, linux-kselftest
In-Reply-To: <20260421144252.1440365-2-kevin.brodsky@arm.com>
Hey Kevin,
On Tue, Apr 21, 2026 at 03:42:49PM +0100, Kevin Brodsky wrote:
> Commit 2e8a1acea859 ("arm64: signal: Improve POR_EL0 handling to
> avoid uaccess failures") delayed the write to POR_EL0 in
> rt_sigreturn to avoid spurious uaccess failures. This change however
> relies on the poe_context frame record being present: on a system
> supporting POE, calling sigreturn without a poe_context record now
> results in writing arbitrary data from the kernel stack into POR_EL0.
>
> Fix this by adding a valid_fields member to struct
> user_access_state, and zeroing the struct on allocation.
> restore_poe_context() then indicates that the por_el0 field is valid
> by setting the corresponding bit in valid_fields, and
> restore_user_access_state() only touches POR_EL0 if there is a valid
> value to set it to. This is in line with how POR_EL0 was originally
> handled; all frame records are currently optional, except
> fpsimd_context.
>
> restore_user_access_state() is also called if setting up the signal
> frame fails, so we also initialise valid_fields in that case. For
> consistency, setup_sigframe() now also checks valid_fields to decide
> whether to write a poe_context record, avoiding another call to
> system_supports_poe().
>
> Fixes: 2e8a1acea859 ("arm64: signal: Improve POR_EL0 handling to avoid uaccess failures")
> Reported-by: Will Deacon <will@kernel.org>
> Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com>
Thanks for fixing this. I think your patch is correct, but I have a
couple of comments inline. Please let me know what you think.
> ---
> arch/arm64/kernel/signal.c | 19 ++++++++++++++-----
> 1 file changed, 14 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
> index 08ffc5a5aea4..3f17aed5b4f0 100644
> --- a/arch/arm64/kernel/signal.c
> +++ b/arch/arm64/kernel/signal.c
> @@ -67,6 +67,8 @@ struct rt_sigframe_user_layout {
> unsigned long end_offset;
> };
>
> +#define UA_STATE_HAS_POR_EL0 BIT(0)
> +
> /*
> * Holds any EL0-controlled state that influences unprivileged memory accesses.
> * This includes both accesses done in userspace and uaccess done in the kernel.
> @@ -74,8 +76,12 @@ struct rt_sigframe_user_layout {
> * This state needs to be carefully managed to ensure that it doesn't cause
> * uaccess to fail when setting up the signal frame, and the signal handler
> * itself also expects a well-defined state when entered.
> + *
> + * The valid_fields member is a bitfield (see UA_STATE_HAS_*), specifying which
> + * of the remaining fields is valid (has been set to a value).
> */
> struct user_access_state {
> + unsigned int valid_fields;
> u64 por_el0;
> };
Do you think it would be worth adding some accessors to make it easier
to keep the flags in sync? For example:
/* Stores por_el0 into uas->por_el0 and sets UA_STATE_HAS_POR_EL0 */
void set_ua_state_por_el0(struct user_access_state *uas, u64 por_el0);
/*
* If UA_STATE_HAS_POR_EL0, *por_el0 = uas->por_el0 and return 0.
* Otherwise, return -ENOENT.
*/
int get_ua_state_por_el0(struct user_access_state *uas, u64 *por_el0);
WDYT?
> @@ -1095,7 +1104,7 @@ SYSCALL_DEFINE0(rt_sigreturn)
> {
> struct pt_regs *regs = current_pt_regs();
> struct rt_sigframe __user *frame;
> - struct user_access_state ua_state;
> + struct user_access_state ua_state = {0};
nit: {} should do (no need for the '0'). Same in setup_rt_frame().
Will
^ permalink raw reply
* [PATCH] pinctrl: meson: amlogic-a4: fix deadlock issue
From: Xianwei Zhao via B4 Relay @ 2026-04-22 11:44 UTC (permalink / raw)
To: Linus Walleij, Neil Armstrong, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl
Cc: linux-amlogic, linux-gpio, linux-arm-kernel, linux-kernel,
Xianwei Zhao
From: Xianwei Zhao <xianwei.zhao@amlogic.com>
Accessing the pinconf-pins sysfs node may deadlock.
pinconf_pins_show() holds pctldev->mutex, and the platform driver
calls pinctrl_find_gpio_range_from_pin(), which tries to acquire
the same mutex again, leading to a deadlock.
Use pinctrl_find_gpio_range_from_pin_nolock() to fix this issue.
Fixes: 6e9be3abb78c ("pinctrl: Add driver support for Amlogic SoCs")
Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com>
---
Fix deadlock issue.
---
drivers/pinctrl/meson/pinctrl-amlogic-a4.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/pinctrl/meson/pinctrl-amlogic-a4.c b/drivers/pinctrl/meson/pinctrl-amlogic-a4.c
index e2293a872dcb..35d27626a336 100644
--- a/drivers/pinctrl/meson/pinctrl-amlogic-a4.c
+++ b/drivers/pinctrl/meson/pinctrl-amlogic-a4.c
@@ -292,7 +292,7 @@ static int aml_calc_reg_and_bit(struct pinctrl_gpio_range *range,
static int aml_pinconf_get_pull(struct aml_pinctrl *info, unsigned int pin)
{
struct pinctrl_gpio_range *range =
- pinctrl_find_gpio_range_from_pin(info->pctl, pin);
+ pinctrl_find_gpio_range_from_pin_nolock(info->pctl, pin);
struct aml_gpio_bank *bank = gpio_chip_to_bank(range->gc);
unsigned int reg, bit, val;
int ret, conf;
@@ -326,7 +326,7 @@ static int aml_pinconf_get_drive_strength(struct aml_pinctrl *info,
u16 *drive_strength_ua)
{
struct pinctrl_gpio_range *range =
- pinctrl_find_gpio_range_from_pin(info->pctl, pin);
+ pinctrl_find_gpio_range_from_pin_nolock(info->pctl, pin);
struct aml_gpio_bank *bank = gpio_chip_to_bank(range->gc);
unsigned int reg, bit;
unsigned int val;
@@ -365,7 +365,7 @@ static int aml_pinconf_get_gpio_bit(struct aml_pinctrl *info,
unsigned int reg_type)
{
struct pinctrl_gpio_range *range =
- pinctrl_find_gpio_range_from_pin(info->pctl, pin);
+ pinctrl_find_gpio_range_from_pin_nolock(info->pctl, pin);
struct aml_gpio_bank *bank = gpio_chip_to_bank(range->gc);
unsigned int reg, bit, val;
int ret;
---
base-commit: bd7fd288490c64835a74c05e631c102ce056d5e1
change-id: 20260422-fix-pinconf-42be1cc2f5af
Best regards,
--
Xianwei Zhao <xianwei.zhao@amlogic.com>
^ permalink raw reply related
* Re: [PATCH v4 2/2] arm64: dts: amlogic: add support for Amediatech X98Q
From: Christian Hewitt @ 2026-04-22 11:43 UTC (permalink / raw)
To: christian.koever-draxl
Cc: robh, krzk+dt, conor+dt, neil.armstrong, khilman, jbrunet,
martin.blumenstingl, devicetree, linux-amlogic, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260422095840.26139-3-christian.koever-draxl@student.uibk.ac.at>
> On 22 Apr 2026, at 1:58 pm, christian.koever-draxl@student.uibk.ac.at wrote:
>
> From: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
>
> Add dts enabling core hardware for the Amediatech X98Q TV box.
>
> The board features:
> - Amlogic S905W2 (Meson S4) SoC
> - 1 GiB RAM (2 GiB variants exist)
> - eMMC and microSD card slot
> - SDIO-based WiFi module (unsupported)
> - RMII Ethernet with internal PHY
> - IR receiver and UART console
> - Status LED
>
> Enabled peripherals:
> - eMMC (HS200)
> - SD card interface
> - SDIO bus (WiFi, no driver yet)
> - Ethernet (RMII)
> - UART_B
> - IR receiver
> - PWM-controlled CPU regulator
> - PWM and Fixed regulators for core and IO rails
>
> Known limitations:
> - No support for the onboard WiFi module
> - Missing multimedia (HDMI/audio)
>
> Signed-off-by: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
> ---
> arch/arm64/boot/dts/amlogic/Makefile | 1 +
> .../boot/dts/amlogic/meson-s4-s905w2-x98q.dts | 249 ++++++++++++++++++
> 2 files changed, 250 insertions(+)
> create mode 100644 arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts
>
> diff --git a/arch/arm64/boot/dts/amlogic/Makefile b/arch/arm64/boot/dts/amlogic/Makefile
> index 15f9c817e502..c7752684dea6 100644
> --- a/arch/arm64/boot/dts/amlogic/Makefile
> +++ b/arch/arm64/boot/dts/amlogic/Makefile
> @@ -85,6 +85,7 @@ dtb-$(CONFIG_ARCH_MESON) += meson-gxm-ugoos-am3.dtb
> dtb-$(CONFIG_ARCH_MESON) += meson-gxm-vega-s96.dtb
> dtb-$(CONFIG_ARCH_MESON) += meson-gxm-wetek-core2.dtb
> dtb-$(CONFIG_ARCH_MESON) += meson-s4-s805x2-aq222.dtb
> +dtb-$(CONFIG_ARCH_MESON) += meson-s4-s905w2-x98q.dtb
> dtb-$(CONFIG_ARCH_MESON) += meson-s4-s905y4-khadas-vim1s.dtb
> dtb-$(CONFIG_ARCH_MESON) += meson-sm1-a95xf3-air-gbit.dtb
> dtb-$(CONFIG_ARCH_MESON) += meson-sm1-a95xf3-air.dtb
> diff --git a/arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts b/arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts
> index 000000000000..3eecbc858522
> --- /dev/null
> +++ b/arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts
> @@ -0,0 +1,249 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2026 Christian Stefan Köver-Draxl
> + * Based on meson-s4-s905y4-khadas-vim1s.dts:
> + * - Copyright (c) 2026 Khadas Technology Co., Ltd.
> + */
> +
> +/dts-v1/;
> +
> +#include "meson-s4.dtsi"
> +
> +/ {
> + model = "Shenzhen Amediatech Technology Co., Ltd X98Q";
> + compatible = "amediatech,x98q", "amlogic,s905w2", "amlogic,s4";
> + interrupt-parent = <&gic>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + aliases {
> + mmc0 = &emmc; /* eMMC */
> + mmc1 = &sd; /* SD card */
> + mmc2 = &sdio; /* SDIO */
> + serial0 = &uart_b;
> + };
> +
> + memory@0 {
> + device_type = "memory";
> + reg = <0x0 0x0 0x0 0x40000000>;
> + };
> +
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + /* 52 MiB reserved for ARM Trusted Firmware */
> + secmon_reserved: secmon@5000000 {
> + reg = <0x0 0x05000000 0x0 0x3400000>;
> + no-map;
> + };
> + };
> +
> + emmc_pwrseq: emmc-pwrseq {
> + compatible = "mmc-pwrseq-emmc";
> + reset-gpios = <&gpio GPIOB_9 GPIO_ACTIVE_LOW>;
> + };
> +
> + sdio_32k: sdio-32k {
> + compatible = "pwm-clock";
> + #clock-cells = <0>;
> + clock-frequency = <32768>;
> + pwms = <&pwm_ef 0 30518 0>; /* PWM_E at 32.768KHz */
> + };
> +
> + sdio_pwrseq: sdio-pwrseq {
> + compatible = "mmc-pwrseq-simple";
> + reset-gpios = <&gpio GPIOX_6 GPIO_ACTIVE_LOW>;
> + clocks = <&sdio_32k>;
> + clock-names = "ext_clock";
> + };
> +
> + main_5v: regulator-main-5v {
> + compatible = "regulator-fixed";
> + regulator-name = "5V";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + regulator-always-on;
> + };
> +
> + sd_3v3: regulator-sd-3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "SD_3V3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + gpio = <&gpio GPIOD_4 GPIO_ACTIVE_LOW>;
> + regulator-always-on;
> + };
> +
> + vddio_sd: regulator-vddio-sd {
> + compatible = "regulator-gpio";
> + regulator-name = "VDDIO_SD";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3300000>;
> + gpios = <&gpio GPIOD_9 GPIO_ACTIVE_HIGH>;
> + gpios-states = <1>;
> + states = <1800000 1 3300000 0>;
> + };
> +
> + vddao_3v3: regulator-vddao-3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "VDDAO_3V3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + vin-supply = <&main_5v>;
> + regulator-always-on;
> + };
> +
> + vddio_ao1v8: regulator-vddio-ao1v8 {
> + compatible = "regulator-fixed";
> + regulator-name = "VDDIO_AO1V8";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + vin-supply = <&vddao_3v3>;
> + regulator-always-on;
> + };
> +
> + /* SY8120B1ABC DC/DC Regulator. */
> + vddcpu: regulator-vddcpu {
> + compatible = "pwm-regulator";
> +
> + regulator-name = "VDDCPU";
> + regulator-min-microvolt = <689000>;
> + regulator-max-microvolt = <1049000>;
> +
> + vin-supply = <&main_5v>;
> +
> + pwms = <&pwm_ij 1 1500 0>;
> + pwm-dutycycle-range = <100 0>;
> +
> + regulator-boot-on;
> + regulator-always-on;
> + /* Voltage Duty-Cycle */
> + voltage-table = <1049000 0>,
> + <1039000 3>,
> + <1029000 6>,
> + <1019000 9>,
> + <1009000 12>,
> + <999000 14>,
> + <989000 17>,
> + <979000 20>,
> + <969000 23>,
> + <959000 26>,
> + <949000 29>,
> + <939000 31>,
> + <929000 34>,
> + <919000 37>,
> + <909000 40>,
> + <899000 43>,
> + <889000 45>,
> + <879000 48>,
> + <869000 51>,
> + <859000 54>,
> + <849000 56>,
> + <839000 59>,
> + <829000 62>,
> + <819000 65>,
> + <809000 68>,
> + <799000 70>,
> + <789000 73>,
> + <779000 76>,
> + <769000 79>,
> + <759000 81>,
> + <749000 84>,
> + <739000 87>,
> + <729000 89>,
> + <719000 92>,
> + <709000 95>,
> + <699000 98>,
> + <689000 100>;
> + };
> +};
> +
> +&emmc {
> + status = "okay";
> + pinctrl-0 = <&emmc_pins>, <&emmc_ds_pins>;
> + pinctrl-1 = <&emmc_clk_gate_pins>;
> + pinctrl-names = "default", "clk-gate";
> +
> + bus-width = <8>;
> + cap-mmc-highspeed;
> + mmc-ddr-1_8v;
> + mmc-hs200-1_8v;
> + max-frequency = <200000000>;
> + non-removable;
> + disable-wp;
> +
> + mmc-pwrseq = <&emmc_pwrseq>;
> + vmmc-supply = <&vddao_3v3>;
> + vqmmc-supply = <&vddio_ao1v8>;
> +};
> +
> +ðmac {
> + status = "okay";
> + phy-handle = <&internal_ephy>;
> + phy-mode = "rmii";
> +};
> +
> +&ir {
> + status = "okay";
> + pinctrl-0 = <&remote_pins>;
> + pinctrl-names = "default";
> +};
> +
> +&pwm_ef {
> + status = "okay";
> + pinctrl-0 = <&pwm_e_pins1>;
> + pinctrl-names = "default";
> +};
> +
> +&pwm_ij {
> + status = "okay";
> +};
> +
> +&sd {
> + status = "okay";
> + pinctrl-0 = <&sdcard_pins>;
> + pinctrl-1 = <&sdcard_clk_gate_pins>;
> + pinctrl-names = "default", "clk-gate";
> + bus-width = <4>;
> + cap-sd-highspeed;
> + max-frequency = <50000000>;
> + disable-wp;
> +
> + cd-gpios = <&gpio GPIOC_6 GPIO_ACTIVE_LOW>;
> +
> + vmmc-supply = <&vddao_3v3>;
> + vqmmc-supply = <&vddao_3v3>;
> +};
> +
> + /*
> + * Wireless SDIO Module (Amlogic W150S1)
> + * Note: There is no driver for this at the moment.
> + */
^ drop this comment
> +
> +&sdio {
> + status = "okay";
> + pinctrl-0 = <&sdio_pins>;
> + pinctrl-1 = <&sdio_clk_gate_pins>;
> + pinctrl-names = "default", "clk-gate";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + bus-width = <4>;
> + cap-sd-highspeed;
> + sd-uhs-sdr50;
> + sd-uhs-sdr104;
> + max-frequency = <200000000>;
> + non-removable;
> + disable-wp;
> +
> + no-sd;
> + no-mmc;
> + mmc-pwrseq = <&sdio_pwrseq>;
> + vmmc-supply = <&vddao_3v3>;
> + vqmmc-supply = <&vddio_ao1v8>;
sdio: wifi@1 {
/* Amlogic W150S1 */
reg = <1>;
};
^ add this to generically describe the hardware without
the need for a specific compatible (as done in several of
the Amlogic reference designs where we cannot guarantee
which chipset is used). The reg value should be enough to
result in the downstream driver probing should a distro
choose to package it; thus avoiding the need for distros
to forever carry a device-tree patch to add support (as
Amlogic have no plans to upstream the driver). Should that
ever change the comment can be replaced with a compatible.
Christian
> +};
> +
> +&uart_b {
> + status = "okay";
> +};
> --
> 2.53.0
>
>
> _______________________________________________
> linux-amlogic mailing list
> linux-amlogic@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-amlogic
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: add tqma9596la-mba95xxca
From: Francesco Dolcini @ 2026-04-22 11:42 UTC (permalink / raw)
To: Alexander Stein, Daniel Baluta
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Geert Uytterhoeven, Magnus Damm, Shawn Guo, linux-arm-kernel,
Markus Niebel, devicetree, linux-kernel, imx, linux,
linux-renesas-soc
In-Reply-To: <5988897.DvuYhMxLoT@steina-w>
On Wed, Apr 22, 2026 at 07:58:11AM +0200, Alexander Stein wrote:
> Am Dienstag, 21. April 2026, 16:48:25 CEST schrieb Daniel Baluta:
> > [..]
> >
> > > +
> > > + reserved-memory {
> > > + #address-cells = <2>;
> > > + #size-cells = <2>;
> > > + ranges;
> > > +
> > > + linux_cma: linux,cma {
> > > + compatible = "shared-dma-pool";
> > > + reusable;
> > > + size = <0 0x28000000>;
> > > + alloc-ranges = <0 0x80000000 0 0x80000000>;
> > > + linux,cma-default;
> > > + };
> > > +
> > > + vpu_boot: vpu_boot@a0000000 {
> >
> > Should this be memory@a0000000 ?
>
> According to schema in dt-schema repository [1] the node name should
> describe the purpose, so I would keep that.
See this question on the topic, and the related answer from Rob,
https://lore.kernel.org/all/88456d17c91737cfc09af46673b49bb9a9d36dc0.camel@gmail.com/
Francesco
^ permalink raw reply
* Re: [PATCH v5 0/6] Add Rockchip RK3576 PWM Support Through MFPWM
From: Nicolas Frattaroli @ 2026-04-22 11:31 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Uwe Kleine-König, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiko Stuebner, Lee Jones, William Breathitt Gray,
Damon Ding, kernel, Jonas Karlman, Alexey Charkov, linux-rockchip,
linux-pwm, devicetree, linux-arm-kernel, linux-kernel, linux-iio,
Conor Dooley
In-Reply-To: <20260421165656.168fe262@jic23-huawei>
On Tuesday, 21 April 2026 17:56:56 Central European Summer Time Jonathan Cameron wrote:
> On Mon, 20 Apr 2026 15:52:37 +0200
> Nicolas Frattaroli <nicolas.frattaroli@collabora.com> wrote:
>
> > This series introduces support for some of the functions of the new PWM
> > silicon found on Rockchip's RK3576 SoC. Due to the wide range of
> > functionalities offered by it, including many parts which this series'
> > first iteration does not attempt to implement for now. The drivers are
> > modelled as an MFD, with no leakage of the MFD-ness into the binding, as
> > it's a Linux implementation detail.
>
> Just thought I'd point out that as this includes the linux-iio
> list sashiko took a look at it. Quite a few things and at least
> the first one I looked at was valid (a dereference before a validity
> check)
>
> https://sashiko.dev/#/patchset/20260420-rk3576-pwm-v5-0-ae7cfbbe5427%40collabora.com
>
> Whilst this tool does generate some false positives, it also finds
> quite a few things it seems us humans fail to spot.
>
> Jonathan
>
While I'm not entirely opposed to this, I do think reviews should happen
on-list when possible. Sashiko is a Google service, so it has about a 50%
chance of still being around in 2 years time. One of the benefits of the
kernel development workflow is that discussion going back decades is still
accessible.
The reason why these aren't posted to list goes into the other thing
that I currently am not stoked about, which is that I'd have to act as
a filter for a Bring-Your-Own-Brain noise generator to pick out the
parts that aren't convincing lies.
^ permalink raw reply
* Re: [PATCH v2 2/9] driver core: Add dev_set_drv_queue_sync_state()
From: Danilo Krummrich @ 2026-04-22 11:30 UTC (permalink / raw)
To: Ulf Hansson
Cc: Saravana Kannan, Rafael J . Wysocki, Greg Kroah-Hartman, linux-pm,
Sudeep Holla, Cristian Marussi, Kevin Hilman, Stephen Boyd,
Marek Szyprowski, Bjorn Andersson, Abel Vesa, Peng Fan,
Tomi Valkeinen, Maulik Shah, Konrad Dybcio, Thierry Reding,
Jonathan Hunter, Geert Uytterhoeven, Dmitry Baryshkov,
linux-arm-kernel, linux-kernel, Geert Uytterhoeven, driver-core
In-Reply-To: <CAPDyKFpeSv+fg=YKJE_qc=Q5BfiJFn0tR7Ar8SncqrD0UW1P1g@mail.gmail.com>
On Wed Apr 22, 2026 at 12:25 PM CEST, Ulf Hansson wrote:
> Most of the static inline functions in device.h lacks documentation.
> Are you suggesting that we should move towards documenting all of
> them?
I'd prefer that, yes. After all, if they are defined in device.h, they are
public APIs, so they should ideally have documentation.
(If a function is only used throughout the driver core, it should be in
drivers/base/base.h instead.)
^ permalink raw reply
* Re: [PATCH v3 4/4] docs: driver-api: add mod_name argument to __platform_register_drivers()
From: Greg Kroah-Hartman @ 2026-04-22 11:27 UTC (permalink / raw)
To: Shashank Balaji
Cc: Suzuki K Poulose, Mike Leach, James Clark, Alexander Shishkin,
Maxime Coquelin, Alexandre Torgue, Rafael J. Wysocki,
Danilo Krummrich, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Richard Cochran, Jonathan Corbet, Shuah Khan,
Rahul Bukte, linux-kernel, coresight, linux-arm-kernel,
driver-core, rust-for-linux, linux-doc, Daniel Palmer, Tim Bird
In-Reply-To: <20260422-acpi_mod_name-v3-4-a184eff9ff6f@sony.com>
On Wed, Apr 22, 2026 at 06:49:06PM +0900, Shashank Balaji wrote:
> Co-developed-by: Rahul Bukte <rahul.bukte@sony.com>
> Signed-off-by: Rahul Bukte <rahul.bukte@sony.com>
> Signed-off-by: Shashank Balaji <shashank.mahadasyam@sony.com>
> ---
> Documentation/driver-api/driver-model/platform.rst | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
For obvious reasons we can't take patches without any changelog text at
all (and neither should you want us to...)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 0/5] firmware/irqchip: Add FF-A DT interrupt support for donated NS SGIs
From: Marc Zyngier @ 2026-04-22 11:01 UTC (permalink / raw)
To: Sudeep Holla
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260412-b4-ffa_ns_sgi_gicv3-v1-0-af61243eb405@kernel.org>
On Sun, 12 Apr 2026 18:04:36 +0100,
Sudeep Holla <sudeep.holla@kernel.org> wrote:
>
> Hi all,
>
> This series wires FF-A notification interrupts up through DT using the
> standard interrupts property on the arm,ffa node and adds the
> required GICv3 and binding support for secure-donated non-secure SGIs.
>
> This has been long pending after the discussions here[1][2]. I have been
> waiting for some ACPI story to shape up for almost an year now, but no
> progress there. So posting this for now to start discussion on the approach
> taken here instead of waiting for another year to sort out ACPI 😉.
>
> It:
>
> - documents secure-donated NS SGIs in the GIC DT binding
> - teaches the GICv3 driver to accept and map those SGIs
> - adds a DT binding for the arm,ffa firmware node
> - updates the FF-A driver to use the arm,ffa node interrupt instead of
> synthesizing its own GIC mapping
> - adds an FVP DT node using SGI 8 as the FF-A notification interrupt
>
> The FF-A DT lookup expects a single interrupt entry, verifies that it is
> a per-CPU interrupt via the reported affinity mask, and cross-checks the
> resolved Linux IRQ hwirq against the interrupt ID returned by
> FFA_FEATURES.
I haven't looked at this in any detail, but these are the additional
issues someone needs to address:
- The GIC(v3) is dead, long live the GIC(v5)! SGIs don't exist in the
brave new world, so FFA needs to find new ways to signal interrupts.
- FFA doesn't necessarily live in secure world, and could be
implemented by a hypervisor. In the context of a single security
domain machine (that's what a VM is), the guest *owns* all SGIs. So
there is absolutely nothing to donate, and this doesn't work. FFA
also needs fixing here.
- All of the above should work with the other firmware description
(Avoid Critical Periodic Interrupts). But maybe FFA is not a thing
on these machines? If not, it should be made explicit.
Overall, it only indicates that FFA should behave as a device, and
use interrupts that are valid for a device.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v2 1/9] driver core: Enable suppliers to implement fine grained sync_state support
From: Danilo Krummrich @ 2026-04-22 10:59 UTC (permalink / raw)
To: Ulf Hansson
Cc: Saravana Kannan, Rafael J . Wysocki, Greg Kroah-Hartman, linux-pm,
Sudeep Holla, Cristian Marussi, Kevin Hilman, Stephen Boyd,
Marek Szyprowski, Bjorn Andersson, Abel Vesa, Peng Fan,
Tomi Valkeinen, Maulik Shah, Konrad Dybcio, Thierry Reding,
Jonathan Hunter, Geert Uytterhoeven, Dmitry Baryshkov,
linux-arm-kernel, linux-kernel, Geert Uytterhoeven, driver-core
In-Reply-To: <CAPDyKFqMDPiqvqJrq5Qs6Tw4Sc7szG4G-=y0NFkNSPoNd9kdVA@mail.gmail.com>
On Wed Apr 22, 2026 at 12:07 PM CEST, Ulf Hansson wrote:
> On Sat, 18 Apr 2026 at 13:23, Danilo Krummrich <dakr@kernel.org> wrote:
>> On Fri Apr 10, 2026 at 12:40 PM CEST, Ulf Hansson wrote:
>> > @@ -1126,6 +1128,9 @@ static void __device_links_queue_sync_state(struct device *dev,
>> > if (dev->state_synced)
>> > return;
>> >
>> > + if (dev->driver && dev->driver->queue_sync_state)
>> > + dev->driver->queue_sync_state(dev);
>>
>> This seems to be called without the device lock being held, which seems to allow
>> the queue_sync_state() callback to execute concurrently with remove(). This
>> opens the door for all kinds of UAF conditions in drivers.
>
> If that were the case, this whole function would be unsafe even before
> this change. I assume this isn't because of how the function is being
> called, but I may be wrong.
This function does not issue any driver callbacks intentionally; the existing
sync_state() callback is deferred to device_links_flush_sync_list(), which is
called without the device_links_write_lock() held, but takes the device_lock()
to protect against other concurrent driver callbacks, such as remove().
I.e. we can't take the device_lock() when the device_links_write_lock() is held,
as it would be prone to lock inversion.
The documentation of __device_links_queue_sync_state() actually slightly hints
at this, but focuses more on the other reason for the deferred semantics -- the
sync_state() callback may want to call device link APIs.
> Anyway, let me add a get/put_device() here somewhere, to ensure we
> prevent this from happening. I assume that is what you are proposing?
No, an additional device reference count won't protect against other concurrent
driver callbacks, such as remove().
^ permalink raw reply
* Re: [PATCH v6 1/2] dma: arm-dma350: enable ANYCH interrupt for shared IRQ wiring
From: Jun Guo @ 2026-04-22 10:33 UTC (permalink / raw)
To: Frank Li
Cc: peter.chen, fugang.duan, robh, krzk+dt, conor+dt, vkoul, ychuang3,
schung, robin.murphy, Frank.Li, dmaengine, devicetree,
linux-kernel, cix-kernel-upstream, linux-arm-kernel
In-Reply-To: <aeia3uoz4g8tlBaV@lizhi-Precision-Tower-5810>
On 4/22/2026 5:54 PM, Frank Li wrote:
> [Some people who received this message don't often get email from frank.li@nxp.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> EXTERNAL EMAIL
>
> On Tue, Apr 21, 2026 at 03:24:11PM +0800, Jun Guo wrote:
>> Hi Robin,
>>
>> Just pinging. I’d like to ask if you have any comments on the latest patch?
>>
>> On 3/25/2026 7:21 PM, Jun Guo wrote:
>>> Enable DMANSECCTRL.INTREN_ANYCHINTR during probe so channel
>>> interrupts are propagated when integrators wire DMA-350 channels
>>> onto a shared IRQ line.
>
> Your tag is wrong
>
> dmaegine: arm-dma350: enable ANYCH ...
Okay, I'll fix this in the next version.
>
>>>
>>> Signed-off-by: Jun Guo <jun.guo@cixtech.com>
>>> ---
>>> drivers/dma/arm-dma350.c | 9 +++++++++
>>> 1 file changed, 9 insertions(+)
>>>
>>> diff --git a/drivers/dma/arm-dma350.c b/drivers/dma/arm-dma350.c
>>> index 84220fa83029..09403aca8bb0 100644
>>> --- a/drivers/dma/arm-dma350.c
>>> +++ b/drivers/dma/arm-dma350.c
>>> @@ -13,6 +13,11 @@
>>> #include "dmaengine.h"
>>> #include "virt-dma.h"
>
> extra empty line between header file and macro
The space actually exists in the code, but it is hidden in the review
records.
>
>
>>> +#define DMANSECCTRL 0x200
>>> +
>>> +#define NSEC_CTRL 0x0c
>
> why need two layer regiser define, your use DMANSECCTRL + NSEC_CTRL，
>
> why not use one macro for 0x20c
>
DMANSECCTRL is the base address for a set of control registers.
Currently, only the NSEC_CTRL register within that set is being used.
All other registers in the same group share this same base address, and
a similar arrangement applies to DMAINFO.
>
>>> +#define INTREN_ANYCHINTR_EN BIT(0)
>>> +
>>> #define DMAINFO 0x0f00
>>> #define DMA_BUILDCFG0 0xb0
>>> @@ -582,6 +587,10 @@ static int d350_probe(struct platform_device *pdev)
>>> dmac->dma.device_issue_pending = d350_issue_pending;
>>> INIT_LIST_HEAD(&dmac->dma.channels);
>>> + reg = readl_relaxed(base + DMANSECCTRL + NSEC_CTRL);
>>> + writel_relaxed(reg | INTREN_ANYCHINTR_EN,
>>> + base + DMANSECCTRL + NSEC_CTRL);
>>> +
>>> /* Would be nice to have per-channel caps for this... */
>>> memset = true;
>>> for (int i = 0; i < nchan; i++) {
>>
^ permalink raw reply
* Re: [PATCH v2] perf/arm_pmu: Skip PMCCNTR_EL0 on NVIDIA Olympus
From: James Clark @ 2026-04-22 10:32 UTC (permalink / raw)
To: Besar Wicaksono, will, mark.rutland
Cc: linux-arm-kernel, linux-kernel, linux-tegra, treding, jonathanh,
vsethi, rwiley, sdonthineni, mochs, nirmoyd, skelley
In-Reply-To: <20260421203856.3539186-1-bwicaksono@nvidia.com>
On 21/04/2026 21:38, Besar Wicaksono wrote:
> The PMCCNTR_EL0 in NVIDIA Olympus CPU may increment while
> in WFI/WFE, which does not align with counting CPU_CYCLES
> on a programmable counter. Add a MIDR range entry and
> refuse PMCCNTR_EL0 for cycle events on affected parts so
> perf does not mix the two behaviors.
>
> Signed-off-by: Besar Wicaksono <bwicaksono@nvidia.com>
> ---
>
> Changes from v1:
> * add CONFIG_ARM64 check to fix build error found by kernel test robot
> * add explicit include of <asm/cputype.h>
> v1: https://lore.kernel.org/linux-arm-kernel/20260406232034.2566133-1-bwicaksono@nvidia.com/
>
> ---
> drivers/perf/arm_pmuv3.c | 44 ++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 44 insertions(+)
>
> diff --git a/drivers/perf/arm_pmuv3.c b/drivers/perf/arm_pmuv3.c
> index 8014ff766cff..7c39d0804b9f 100644
> --- a/drivers/perf/arm_pmuv3.c
> +++ b/drivers/perf/arm_pmuv3.c
> @@ -8,6 +8,7 @@
> * This code is based heavily on the ARMv7 perf event code.
> */
>
> +#include <asm/cputype.h>
> #include <asm/irq_regs.h>
> #include <asm/perf_event.h>
> #include <asm/virt.h>
> @@ -978,6 +979,41 @@ static int armv8pmu_get_chain_idx(struct pmu_hw_events *cpuc,
> return -EAGAIN;
> }
>
> +#ifdef CONFIG_ARM64
> +/*
> + * List of CPUs that should avoid using PMCCNTR_EL0.
> + */
> +static struct midr_range armv8pmu_avoid_pmccntr_cpus[] = {
> + /*
> + * The PMCCNTR_EL0 in Olympus CPU may still increment while in WFI/WFE state.
> + * This is an implementation specific behavior and not an erratum.
> + *
> + * From ARM DDI0487 D14.4:
> + * It is IMPLEMENTATION SPECIFIC whether CPU_CYCLES and PMCCNTR count
> + * when the PE is in WFI or WFE state, even if the clocks are not stopped.
> + *
> + * From ARM DDI0487 D24.5.2:
> + * All counters are subject to any changes in clock frequency, including
> + * clock stopping caused by the WFI and WFE instructions.
> + * This means that it is CONSTRAINED UNPREDICTABLE whether or not
> + * PMCCNTR_EL0 continues to increment when clocks are stopped by WFI and
> + * WFE instructions.
> + */
> + MIDR_ALL_VERSIONS(MIDR_NVIDIA_OLYMPUS),
> + {}
> +};
> +
> +static bool armv8pmu_is_in_avoid_pmccntr_cpus(void)
> +{
> + return is_midr_in_range_list(armv8pmu_avoid_pmccntr_cpus);
> +}
> +#else
> +static bool armv8pmu_is_in_avoid_pmccntr_cpus(void)
> +{
> + return false;
> +}
> +#endif
> +
> static bool armv8pmu_can_use_pmccntr(struct pmu_hw_events *cpuc,
> struct perf_event *event)
> {
> @@ -1011,6 +1047,14 @@ static bool armv8pmu_can_use_pmccntr(struct pmu_hw_events *cpuc,
> if (cpu_pmu->has_smt)
> return false;
>
> + /*
> + * On some CPUs, PMCCNTR_EL0 does not match the behavior of CPU_CYCLES
> + * programmable counter, so avoid routing cycles through PMCCNTR_EL0 to
> + * prevent inconsistency in the results.
> + */
> + if (armv8pmu_is_in_avoid_pmccntr_cpus())
> + return false;
> +
Hi Besar,
This is called from armpmu_event_init() before the event is scheduled on
the CPU so I don't think reading the MIDR at this point is safe.
When the PMU is probed you probably need to do an SMP call to get the
MIDR of CPUs in that PMU's mask and then cache the "avoid pmccntr"
result like has_smt. Or even rename has_smt to avoid_pmccntr and combine
the two results there.
I don't know what will happen if none of those CPUs are online when the
PMU is probed though...
James
> return true;
> }
>
^ permalink raw reply
* Re: [PATCH v2] mm/page_alloc: fix initialization of tags of the huge zero folio with init_on_free
From: Catalin Marinas @ 2026-04-22 10:32 UTC (permalink / raw)
To: David Hildenbrand (Arm)
Cc: linux-arm-kernel, Will Deacon, Andrew Morton, Lorenzo Stoakes,
Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Brendan Jackman,
Johannes Weiner, Zi Yan, Lance Yang, Ryan Roberts, Mark Brown,
Dev Jain, linux-kernel, linux-mm, stable
In-Reply-To: <20260421-zerotags-v2-1-05cb1035482e@kernel.org>
On Tue, Apr 21, 2026 at 05:39:07PM +0200, David Hildenbrand wrote:
> __GFP_ZEROTAGS semantics are currently a bit weird, but effectively this
> flag is only ever set alongside __GFP_ZERO and __GFP_SKIP_KASAN.
>
> If we run with init_on_free, we will zero out pages during
> __free_pages_prepare(), to skip zeroing on the allocation path.
>
> However, when allocating with __GFP_ZEROTAG set, post_alloc_hook() will
> consequently not only skip clearing page content, but also skip
> clearing tag memory.
>
> Not clearing tags through __GFP_ZEROTAGS is irrelevant for most pages that
> will get mapped to user space through set_pte_at() later: set_pte_at() and
> friends will detect that the tags have not been initialized yet
> (PG_mte_tagged not set), and initialize them.
>
> However, for the huge zero folio, which will be mapped through a PMD
> marked as special, this initialization will not be performed, ending up
> exposing whatever tags were still set for the pages.
>
> The docs (Documentation/arch/arm64/memory-tagging-extension.rst) state
> that allocation tags are set to 0 when a page is first mapped to user
> space. That no longer holds with the huge zero folio when init_on_free
> is enabled.
>
> Fix it by decoupling __GFP_ZEROTAGS from __GFP_ZERO, passing to
> tag_clear_highpages() whether we want to also clear page content.
>
> Invert the meaning of the tag_clear_highpages() return value to have
> clearer semantics.
>
> Reproduced with the huge zero folio by modifying the check_buffer_fill
> arm64/mte selftest to use a 2 MiB area, after making sure that pages have
> a non-0 tag set when freeing (note that, during boot, we will not
> actually initialize tags, but only set KASAN_TAG_KERNEL in the page
> flags).
>
> $ ./check_buffer_fill
> 1..20
> ...
> not ok 17 Check initial tags with private mapping, sync error mode and mmap memory
> not ok 18 Check initial tags with private mapping, sync error mode and mmap/mprotect memory
> ...
>
> This code needs more cleanups; we'll tackle that next, like
> decoupling __GFP_ZEROTAGS from __GFP_SKIP_KASAN.
>
> Fixes: adfb6609c680 ("mm/huge_memory: initialise the tags of the huge zero folio")
> Cc: stable@vger.kernel.org
> Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
The logic looks fine to me. Thanks!
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* [PATCH] KVM: arm64: Validate the FF-A memory access descriptor placement
From: Sebastian Ene @ 2026-04-22 10:25 UTC (permalink / raw)
To: maz, oupton, will
Cc: ayrton, catalin.marinas, joey.gouly, korneld, kvmarm,
linux-arm-kernel, linux-kernel, android-kvm, mrigendra.chaubey,
perlarsen, sebastianene, suzuki.poulose, yuzenghui, stable
Prevent the pKVM hypervisor from making assumptions that the
endpoint memory access descriptor (EMAD) comes right after the
FF-A memory region header and enforce a strict placement for it
when validating an FF-A memory lend/share transaction.
Prior to FF-A version 1.1 the header of the memory region
didn't contain an offset to the endpoint memory access descriptor.
The layout of a memory transaction looks like this:
Field name | Offset
-- 0
[ Header (ffa_mem_region) |__ ep_mem_offset
EMAD 1 (ffa_mem_region_attributes) |
]
Reject the host from specifying a memory access descriptor offset
that is different than the size of the memory region header.
Cc: stable@vger.kernel.org
Fixes: 42fb33dde42b ("KVM: arm64: Use FF-A 1.1 with pKVM")
Signed-off-by: Sebastian Ene <sebastianene@google.com>
---
arch/arm64/kvm/hyp/nvhe/ffa.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
index 94161ea1cd60..0703c0ad8dff 100644
--- a/arch/arm64/kvm/hyp/nvhe/ffa.c
+++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
@@ -508,6 +508,12 @@ static void __do_ffa_mem_xfer(const u64 func_id,
buf = hyp_buffers.tx;
memcpy(buf, host_buffers.tx, fraglen);
+ if (FFA_MEM_REGION_HAS_EP_MEM_OFFSET(hyp_ffa_version) &&
+ buf->ep_mem_offset != sizeof(struct ffa_mem_region)) {
+ ret = FFA_RET_INVALID_PARAMETERS;
+ goto out_unlock;
+ }
+
ep_mem_access = (void *)buf +
ffa_mem_desc_offset(buf, 0, hyp_ffa_version);
offset = ep_mem_access->composite_off;
--
2.54.0.rc1.555.g9c883467ad-goog
^ permalink raw reply related
* Re: [PATCH v2 2/9] driver core: Add dev_set_drv_queue_sync_state()
From: Ulf Hansson @ 2026-04-22 10:25 UTC (permalink / raw)
To: Danilo Krummrich
Cc: Saravana Kannan, Rafael J . Wysocki, Greg Kroah-Hartman, linux-pm,
Sudeep Holla, Cristian Marussi, Kevin Hilman, Stephen Boyd,
Marek Szyprowski, Bjorn Andersson, Abel Vesa, Peng Fan,
Tomi Valkeinen, Maulik Shah, Konrad Dybcio, Thierry Reding,
Jonathan Hunter, Geert Uytterhoeven, Dmitry Baryshkov,
linux-arm-kernel, linux-kernel, Geert Uytterhoeven, driver-core
In-Reply-To: <DHW8QV8K3CM1.307C6PW2BM5RN@kernel.org>
On Sat, 18 Apr 2026 at 13:24, Danilo Krummrich <dakr@kernel.org> wrote:
>
> On Fri Apr 10, 2026 at 12:40 PM CEST, Ulf Hansson wrote:
> > diff --git a/include/linux/device.h b/include/linux/device.h
> > index e65d564f01cd..f812e70bdf22 100644
> > --- a/include/linux/device.h
> > +++ b/include/linux/device.h
> > @@ -994,6 +994,18 @@ static inline int dev_set_drv_sync_state(struct device *dev,
> > return 0;
> > }
> >
> > +static inline int dev_set_drv_queue_sync_state(struct device *dev,
> > + void (*fn)(struct device *dev))
>
> As this is a public function, please add some documentation.
Most of the static inline functions in device.h lacks documentation.
Are you suggesting that we should move towards documenting all of
them?
In this case, dev_set_drv_sync_state() also lacks documentation and to
me, it doesn't make sense to add documentation only for
dev_set_drv_queue_sync_state(). Do you want me to add it for both?
[...]
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH v4 2/2] arm64: dts: amlogic: add support for Amediatech X98Q
From: Ferass El Hafidi @ 2026-04-22 10:02 UTC (permalink / raw)
To: linux-amlogic, christian.koever-draxl, robh, krzk+dt, conor+dt,
neil.armstrong, khilman
Cc: jbrunet, martin.blumenstingl, devicetree, linux-amlogic,
linux-arm-kernel, linux-kernel,
Christian Stefan Kövér-Draxl
In-Reply-To: <20260422095840.26139-3-christian.koever-draxl@student.uibk.ac.at>
On Wed, 22 Apr 2026 09:58, christian.koever-draxl@student.uibk.ac.at wrote:
>From: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
>
>Add dts enabling core hardware for the Amediatech X98Q TV box.
>
>The board features:
>- Amlogic S905W2 (Meson S4) SoC
>- 1 GiB RAM (2 GiB variants exist)
>- eMMC and microSD card slot
>- SDIO-based WiFi module (unsupported)
>- RMII Ethernet with internal PHY
>- IR receiver and UART console
>- Status LED
>
>Enabled peripherals:
>- eMMC (HS200)
>- SD card interface
>- SDIO bus (WiFi, no driver yet)
>- Ethernet (RMII)
>- UART_B
>- IR receiver
>- PWM-controlled CPU regulator
>- PWM and Fixed regulators for core and IO rails
>
>Known limitations:
>- No support for the onboard WiFi module
>- Missing multimedia (HDMI/audio)
>
>Signed-off-by: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
>---
> arch/arm64/boot/dts/amlogic/Makefile | 1 +
> .../boot/dts/amlogic/meson-s4-s905w2-x98q.dts | 249 ++++++++++++++++++
> 2 files changed, 250 insertions(+)
> create mode 100644 arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts
><...>
>+&sd {
>+ status = "okay";
>+ pinctrl-0 = <&sdcard_pins>;
>+ pinctrl-1 = <&sdcard_clk_gate_pins>;
>+ pinctrl-names = "default", "clk-gate";
>+ bus-width = <4>;
>+ cap-sd-highspeed;
>+ max-frequency = <50000000>;
>+ disable-wp;
>+
>+ cd-gpios = <&gpio GPIOC_6 GPIO_ACTIVE_LOW>;
>+
>+ vmmc-supply = <&vddao_3v3>;
>+ vqmmc-supply = <&vddao_3v3>;
>+};
>+
>+ /*
>+ * Wireless SDIO Module (Amlogic W150S1)
>+ * Note: There is no driver for this at the moment.
>+ */
>+
I didn't mean to indent, just to align the '*'.
Sorry it wasn't clear.
>+&sdio {
>+ status = "okay";
>+ pinctrl-0 = <&sdio_pins>;
>+ pinctrl-1 = <&sdio_clk_gate_pins>;
>+ pinctrl-names = "default", "clk-gate";
>+ #address-cells = <1>;
>+ #size-cells = <0>;
>+ bus-width = <4>;
>+ cap-sd-highspeed;
>+ sd-uhs-sdr50;
>+ sd-uhs-sdr104;
>+ max-frequency = <200000000>;
>+ non-removable;
>+ disable-wp;
>+
>+ no-sd;
>+ no-mmc;
>+ mmc-pwrseq = <&sdio_pwrseq>;
>+ vmmc-supply = <&vddao_3v3>;
>+ vqmmc-supply = <&vddio_ao1v8>;
>+};
>+
>+&uart_b {
>+ status = "okay";
>+};
>--
>2.53.0
--
Best regards,
Ferass
^ permalink raw reply
* Re: [PATCH v2 1/9] driver core: Enable suppliers to implement fine grained sync_state support
From: Ulf Hansson @ 2026-04-22 10:07 UTC (permalink / raw)
To: Danilo Krummrich
Cc: Saravana Kannan, Rafael J . Wysocki, Greg Kroah-Hartman, linux-pm,
Sudeep Holla, Cristian Marussi, Kevin Hilman, Stephen Boyd,
Marek Szyprowski, Bjorn Andersson, Abel Vesa, Peng Fan,
Tomi Valkeinen, Maulik Shah, Konrad Dybcio, Thierry Reding,
Jonathan Hunter, Geert Uytterhoeven, Dmitry Baryshkov,
linux-arm-kernel, linux-kernel, Geert Uytterhoeven, driver-core
In-Reply-To: <DHW8QPU1VU1F.3P6PH69HLFBYC@kernel.org>
On Sat, 18 Apr 2026 at 13:23, Danilo Krummrich <dakr@kernel.org> wrote:
>
> On Fri Apr 10, 2026 at 12:40 PM CEST, Ulf Hansson wrote:
> > The common sync_state support isn't fine grained enough for some types of
> > suppliers, like power domains for example. Especially when a supplier
> > provides multiple independent power domains, each with their own set of
> > consumers. In these cases we need to wait for all consumers for all the
> > provided power domains before invoking the supplier's ->sync_state().
> >
> > To allow a more fine grained sync_state support to be implemented on per
> > supplier's driver basis, let's add a new optional callback. As soon as
> > there is an update worth to consider in regards to managing sync_state for
> > a supplier device, __device_links_queue_sync_state() invokes the callback.
> >
> > Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> > ---
> > drivers/base/core.c | 7 ++++++-
> > include/linux/device/driver.h | 7 +++++++
> > 2 files changed, 13 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/base/core.c b/drivers/base/core.c
> > index 09b98f02f559..4085a011d8ca 100644
> > --- a/drivers/base/core.c
> > +++ b/drivers/base/core.c
> > @@ -1106,7 +1106,9 @@ int device_links_check_suppliers(struct device *dev)
> > * Queues a device for a sync_state() callback when the device links write lock
> > * isn't held. This allows the sync_state() execution flow to use device links
> > * APIs. The caller must ensure this function is called with
> > - * device_links_write_lock() held.
> > + * device_links_write_lock() held. Note, if the optional queue_sync_state()
> > + * callback has been assigned too, it gets called for every update to allowing a
>
> s/allowing/allow/
>
> > + * more fine grained support to be implemented on per supplier basis.
> > *
> > * This function does a get_device() to make sure the device is not freed while
> > * on this list.
> > @@ -1126,6 +1128,9 @@ static void __device_links_queue_sync_state(struct device *dev,
> > if (dev->state_synced)
> > return;
> >
> > + if (dev->driver && dev->driver->queue_sync_state)
> > + dev->driver->queue_sync_state(dev);
>
> This seems to be called without the device lock being held, which seems to allow
> the queue_sync_state() callback to execute concurrently with remove(). This
> opens the door for all kinds of UAF conditions in drivers.
If that were the case, this whole function would be unsafe even before
this change. I assume this isn't because of how the function is being
called, but I may be wrong.
Anyway, let me add a get/put_device() here somewhere, to ensure we
prevent this from happening. I assume that is what you are proposing?
>
> This also made me aware that the above dev_has_sync_state() is probably broken,
> as it also performs the following check without the device lock being held.
>
> dev->driver && dev->driver->sync_state
>
> I think nothing prevents dev->driver to become NULL concurrently; in this case
> READ_ONCE() should be sufficient though as it doesn't execute the callback.
>
> I will send a patch for this.
Okay, thanks!
>
> > +
> > list_for_each_entry(link, &dev->links.consumers, s_node) {
> > if (!device_link_test(link, DL_FLAG_MANAGED))
> > continue;
> > diff --git a/include/linux/device/driver.h b/include/linux/device/driver.h
> > index bbc67ec513ed..bc9ae1cbe03c 100644
> > --- a/include/linux/device/driver.h
> > +++ b/include/linux/device/driver.h
> > @@ -68,6 +68,12 @@ enum probe_type {
> > * be called at late_initcall_sync level. If the device has
> > * consumers that are never bound to a driver, this function
> > * will never get called until they do.
> > + * @queue_sync_state: Similar to the ->sync_state() callback, but called to
> > + * allow syncing device state to software state in a more fine
> > + * grained way. It is called when there is an updated state that
> > + * may be worth to consider for any of the consumers linked to
> > + * this device. If implemented, the ->sync_state() callback is
> > + * required too.
>
> What happens if this is not the case? Maybe worth to check and warn about this
> in driver_register().
Good point!
I believe I should also add a check in dev_set_drv_queue_sync_state()
that is added in patch2.
>
> > * @remove: Called when the device is removed from the system to
> > * unbind a device from this driver.
> > * @shutdown: Called at shut-down time to quiesce the device.
> > @@ -110,6 +116,7 @@ struct device_driver {
> >
> > int (*probe) (struct device *dev);
> > void (*sync_state)(struct device *dev);
> > + void (*queue_sync_state)(struct device *dev);
> > int (*remove) (struct device *dev);
> > void (*shutdown) (struct device *dev);
> > int (*suspend) (struct device *dev, pm_message_t state);
> > --
> > 2.43.0
>
Thanks for reviewing!
Kind regards
Uffe
^ permalink raw reply
* [PATCH v2 2/4] KVM: arm64: timer: Kill the per-timer level cache
From: Marc Zyngier @ 2026-04-22 10:02 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel
Cc: Deepanshu Kartikey, Joey Gouly, Suzuki K Poulose, Oliver Upton,
Zenghui Yu
In-Reply-To: <20260422100210.3008156-1-maz@kernel.org>
The timer code makes use of a per-timer irq level cache, which
looks like a very minor optimisation to avoid taking a lock upon
updating the GIC view of the interrupt when it is unchanged from
the previous state.
This is coming in the way of more important correctness issues,
so get rid of the cache, which simplifies a couple of minor things.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kvm/arch_timer.c | 20 +++++++++-----------
include/kvm/arm_arch_timer.h | 5 -----
2 files changed, 9 insertions(+), 16 deletions(-)
diff --git a/arch/arm64/kvm/arch_timer.c b/arch/arm64/kvm/arch_timer.c
index 22e79ecb34bc4..5cfe223da2996 100644
--- a/arch/arm64/kvm/arch_timer.c
+++ b/arch/arm64/kvm/arch_timer.c
@@ -445,9 +445,8 @@ static void kvm_timer_update_irq(struct kvm_vcpu *vcpu, bool new_level,
{
kvm_timer_update_status(timer_ctx, new_level);
- timer_ctx->irq.level = new_level;
trace_kvm_timer_update_irq(vcpu->vcpu_id, timer_irq(timer_ctx),
- timer_ctx->irq.level);
+ new_level);
if (userspace_irqchip(vcpu->kvm))
return;
@@ -465,7 +464,7 @@ static void kvm_timer_update_irq(struct kvm_vcpu *vcpu, bool new_level,
kvm_vgic_inject_irq(vcpu->kvm, vcpu,
timer_irq(timer_ctx),
- timer_ctx->irq.level,
+ new_level,
timer_ctx);
}
@@ -476,10 +475,7 @@ static void timer_emulate(struct arch_timer_context *ctx)
trace_kvm_timer_emulate(ctx, pending);
- if (pending != ctx->irq.level)
- kvm_timer_update_irq(timer_context_to_vcpu(ctx), pending, ctx);
-
- kvm_timer_update_status(ctx, pending);
+ kvm_timer_update_irq(timer_context_to_vcpu(ctx), pending, ctx);
/*
* If the timer can fire now, we don't need to have a soft timer
@@ -676,6 +672,7 @@ static inline void set_timer_irq_phys_active(struct arch_timer_context *ctx, boo
static void kvm_timer_vcpu_load_gic(struct arch_timer_context *ctx)
{
struct kvm_vcpu *vcpu = timer_context_to_vcpu(ctx);
+ bool pending = kvm_timer_pending(ctx);
bool phys_active = false;
/*
@@ -684,12 +681,12 @@ static void kvm_timer_vcpu_load_gic(struct arch_timer_context *ctx)
* this point and the register restoration, we'll take the
* interrupt anyway.
*/
- kvm_timer_update_irq(vcpu, kvm_timer_pending(ctx), ctx);
+ kvm_timer_update_irq(vcpu, pending, ctx);
if (irqchip_in_kernel(vcpu->kvm))
phys_active = kvm_vgic_map_is_active(vcpu, timer_irq(ctx));
- phys_active |= ctx->irq.level;
+ phys_active |= pending;
phys_active |= vgic_is_v5(vcpu->kvm);
set_timer_irq_phys_active(ctx, phys_active);
@@ -698,6 +695,7 @@ static void kvm_timer_vcpu_load_gic(struct arch_timer_context *ctx)
static void kvm_timer_vcpu_load_nogic(struct kvm_vcpu *vcpu)
{
struct arch_timer_context *vtimer = vcpu_vtimer(vcpu);
+ bool pending = kvm_timer_pending(vtimer);
/*
* Update the timer output so that it is likely to match the
@@ -705,7 +703,7 @@ static void kvm_timer_vcpu_load_nogic(struct kvm_vcpu *vcpu)
* this point and the register restoration, we'll take the
* interrupt anyway.
*/
- kvm_timer_update_irq(vcpu, kvm_timer_pending(vtimer), vtimer);
+ kvm_timer_update_irq(vcpu, pending, vtimer);
/*
* When using a userspace irqchip with the architected timers and a
@@ -717,7 +715,7 @@ static void kvm_timer_vcpu_load_nogic(struct kvm_vcpu *vcpu)
* being de-asserted, we unmask the interrupt again so that we exit
* from the guest when the timer fires.
*/
- if (vtimer->irq.level)
+ if (pending)
disable_percpu_irq(host_vtimer_irq);
else
enable_percpu_irq(host_vtimer_irq, host_vtimer_irq_flags);
diff --git a/include/kvm/arm_arch_timer.h b/include/kvm/arm_arch_timer.h
index bf8cc9589bd09..2c26d457c3510 100644
--- a/include/kvm/arm_arch_timer.h
+++ b/include/kvm/arm_arch_timer.h
@@ -66,11 +66,6 @@ struct arch_timer_context {
*/
bool loaded;
- /* Output level of the timer IRQ */
- struct {
- bool level;
- } irq;
-
/* Who am I? */
enum kvm_arch_timers timer_id;
--
2.47.3
^ permalink raw reply related
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