* Re: [PATCH] irqchip/exynos-combiner: switch to raw_spinlock
From: Marek Szyprowski @ 2026-05-21 11:26 UTC (permalink / raw)
To: Thomas Gleixner, linux-arm-kernel, linux-samsung-soc,
linux-rt-devel
Cc: Krzysztof Kozlowski, Alim Akhtar, Sebastian Andrzej Siewior,
Clark Williams, Steven Rostedt
In-Reply-To: <87ecj5w2qf.ffs@tglx>
On 21.05.2026 11:06, Thomas Gleixner wrote:
> On Thu, May 21 2026 at 00:04, Marek Szyprowski wrote:
>> The exynos-combiner driver uses a regular spinlock to protect access to
>> the combiner interrupt status register in combiner_handle_cascade_irq(),
>> which is invoked in hard IRQ context as a chained interrupt handler.
>>
>> When PREEMPT_RT is enabled on ARM, regular spinlock is converted to a
>> sleeping lock (mutex-based), which must not be used in atomic context
>> such as hard interrupt handlers. Switch the irq_controller_lock to
>> raw_spinlock, which remains a true non-sleeping spinlock even under
>> PREEMPT_RT.
> Mechanically this makes sense, but out of curiosity I have to ask:
>
>> -static DEFINE_SPINLOCK(irq_controller_lock);
>> +static DEFINE_RAW_SPINLOCK(irq_controller_lock);
>>
>> struct combiner_chip_data {
>> unsigned int hwirq_offset;
>> @@ -72,9 +72,9 @@ static void combiner_handle_cascade_irq(struct irq_desc *desc)
>>
>> chained_irq_enter(chip, desc);
>>
>> - spin_lock(&irq_controller_lock);
>> + raw_spin_lock(&irq_controller_lock);
>> status = readl_relaxed(chip_data->base + COMBINER_INT_STATUS);
>> - spin_unlock(&irq_controller_lock);
>> + raw_spin_unlock(&irq_controller_lock);
> What is this lock actually protecting?
>
> Each combiner has it's own @base address, so there is no concurrency
> problem between two cascade interrupts being handled at the same time.
>
> That means the only possible problem would be that the same cascade
> interrupt is handled on two CPUs concurrently. Is that even possible?
Frankly speaking I did this conversion mechanically, late in the evening to fix
the bug warning I've spotted. Indeed this spinlock looks like a copy&paste or
development leftover. The only side-effect of it I see is a memory barrier,
which might affect how the register access happens, but this should not affect
cascade operation imho. Do You want me to send a patch removing it completely?
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* Re: [PATCH] [RFC] arm64: mmu: use range based TLB flushing when hot unplugging memory
From: Ryan Roberts @ 2026-05-21 11:24 UTC (permalink / raw)
To: Balbir Singh
Cc: Alistair Popple, linux-arm-kernel, linux-kernel, linux-mm,
catalin.marinas, will, david, anshuman.khandual, dev.jain,
jhubbard
In-Reply-To: <ag7fy4Q9foBBlUcd@parvat>
On 21/05/2026 11:46, Balbir Singh wrote:
> On Thu, May 21, 2026 at 09:50:04AM +0100, Ryan Roberts wrote:
>> On 21/05/2026 05:24, Alistair Popple wrote:
>>> Hot unplugging memory on ARM64 requires a TLB invalidate after unmapping
>>> the page to be hot unplugged from the direct map. Currently that happens
>>> one page at a time, meaning range based invalidates cannot be used. The
>>> result of this is that removing large amounts of memory takes a long
>>> time and in some cases can trigger an RCU stall warning.
>>>
>>> For example on one system hot unplugging 480GB of memory takes ~1
>>> minute. With this change the same operation took ~1 second, a 60x
>>> improvement.
>>>
>>> Signed-off-by: Alistair Popple <apopple@nvidia.com>
>>>
>>> ---
>>>
>>> This is an RFC, because I'm not sure the change is correct as it frees
>>> the PTE page before flushing the TLB. I'm not familiar enough with ARM64
>>> architecture to be sure this is safe, for example I don't know if HW
>>> can update PTE bits such as access/dirty in the page through a stale
>>> TLB entry.
>>>
>>> If so this would open a window during which the page is free but could
>>> still be written to. Likely the safe option would be to collect all the
>>> pages to be free on a list and free them after doing the range based TLB
>>> flush, but wanted to get feedback on the approach before implementing it
>>> which is the goal of this RFC.
>>
>> Hi Alistair,
>>
>> This patch doesn't apply on v7.1-rc4 because it conflicts with this patch:
>>
>> Commit 48478b9f79137 ("arm64/mm: Enable batched TLB flush in unmap_hotplug_range()")
>>
>> which has a very similar performance improvement, so hopefully it solves your
>> problem?
>>
>> There are two paths which use this logic; unmapping the linear map and unmapping
>> the corresponding vmemmap. In the latter case, the memory is also freed, so we
>> can't safely do the range optimizaiton there since the TLB needs to be flushed
>> before freeing the memory. But the linear map is the big, slow bit so hopefully
>> it's sufficent for you?
>>
>
> I assume vmemmap path is for tearing down the struct pages corresponding
> to the physical memory and vmemmap teardowns taking a flush should be
> OK. It is worth checking if the issue is already fixed.
Yes, exactly. Assuming you're using 64K pages, I think vmemmap is mapped using
base pages. So you'd get 1024 struct pages on a page, so 1 TLBI per 64M of
memory that is being unplugged on the vmemmap path.
On the linear map path, it's a single range tlbi operation to over the entire range.
Alistair's patch is doing it per 512M in both cases, but is unsafe for vmemmap
as currently written.
>
> Balbir
> <snip>
^ permalink raw reply
* Re: [PATCH 2/2] kselftest/arm64: Add test for atomic futex uaccess with POE
From: Mark Brown @ 2026-05-21 11:22 UTC (permalink / raw)
To: Kevin Brodsky
Cc: linux-arm-kernel, Catalin Marinas, Joey Gouly, Shuah Khan,
Will Deacon, linux-kernel, linux-kselftest
In-Reply-To: <20260521-poe_futex-v1-2-1da286b8f9b2@arm.com>
[-- Attachment #1: Type: text/plain, Size: 405 bytes --]
On Thu, May 21, 2026 at 10:42:31AM +0100, Kevin Brodsky wrote:
> Add a new test to ensure that atomic futex uaccess succeeds on
> memory mapped with a non-default POIndex/pkey.
> + ptr = mmap(NULL, size, PROT_READ | PROT_WRITE,
> + MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
> + ASSERT_NE(ptr, MAP_FAILED);
Doesn't matter while there's only one test but we should probably
munmap() this when we're done.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 2/2] arm64: mm: add SMCCC-backed cache invalidate provider
From: Jonathan Cameron @ 2026-05-21 11:18 UTC (permalink / raw)
To: Srirangan Madhavan
Cc: catalin.marinas, will, mark.rutland, lpieralisi, sudeep.holla,
conor, linux-arm-kernel, linux-kernel, vsethi, jevans,
raghupathyk, srikars, nbenech, alwilliamson, Dan Williams
In-Reply-To: <20260521073047.320614-3-smadhavan@nvidia.com>
On Thu, 21 May 2026 07:30:47 +0000
Srirangan Madhavan <smadhavan@nvidia.com> wrote:
> Add an arm64 cache maintenance backend that discovers SMCCC cache
> clean+invalidate support, queries attributes, handles transient BUSY and
> RATE_LIMITED responses with bounded retries, and registers with the generic
> cache coherency framework.
>
> Signed-off-by: Srirangan Madhavan <smadhavan@nvidia.com>
Hi Srirangan,
Other than the file location and Kconfig option comments, everything else
is really trivial. + some musings about maybe being worth more clever
fusing of ops in the future if it turns out to be useful.
Thanks,
Jonathan
> ---
> MAINTAINERS | 1 +
> arch/arm64/mm/Makefile | 1 +
> arch/arm64/mm/cache_maint.c | 180 ++++++++++++++++++++++++++++++++++++
File location wise, this is a driver for a subsystem, be it one closely
coupled to arm. Arm maintainers, do you want it in there or in drivers/cache ?
My personal preference is always to keep drivers with subsystems but I don't
care that much.
> 3 files changed, 182 insertions(+)
> create mode 100644 arch/arm64/mm/cache_maint.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 2fb1c75afd16..33c35f8e6e40 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -25383,6 +25383,7 @@ M: Jonathan Cameron <jic23@kernel.org>
> S: Maintained
> T: git https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux.git/
> F: Documentation/devicetree/bindings/cache/
> +F: arch/arm64/mm/cache_maint.c
I wonder if this should just have a separate maintainers entry?
We did that for the hisi driver.
If not maybe add yourself as at least a Reviewer so that you get +CC'd
on relevant changes.
Conor, what do you think makes sense here.
> F: drivers/cache
> F: include/linux/cache_coherency.h
> F: lib/cache_maint.c
> diff --git a/arch/arm64/mm/Makefile b/arch/arm64/mm/Makefile
> index c26489cf96cd..b247dc5dfd45 100644
> --- a/arch/arm64/mm/Makefile
> +++ b/arch/arm64/mm/Makefile
> @@ -12,6 +12,7 @@ obj-$(CONFIG_TRANS_TABLE) += trans_pgd-asm.o
> obj-$(CONFIG_DEBUG_VIRTUAL) += physaddr.o
> obj-$(CONFIG_ARM64_MTE) += mteswap.o
> obj-$(CONFIG_ARM64_GCS) += gcs.o
> +obj-$(CONFIG_ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION) += cache_maint.o
I think this should have a separate CONFIG because it is only one option
for how to do it on arm64. The Hisi driver being the other one already
upstream. That will be easier if this is in drivers/cache as can go
in the existing menu.
> KASAN_SANITIZE_physaddr.o += n
>
> obj-$(CONFIG_KASAN) += kasan_init.o
> diff --git a/arch/arm64/mm/cache_maint.c b/arch/arm64/mm/cache_maint.c
> new file mode 100644
> index 000000000000..ea7dd30d5dfa
> --- /dev/null
> +++ b/arch/arm64/mm/cache_maint.c
> @@ -0,0 +1,180 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2026 NVIDIA Corporation
> + *
> + * Arm64 cache maintenance provider using SMCCC cache clean+invalidate calls.
> + */
> +
> +#include <linux/arm-smccc.h>
> +#include <linux/cache_coherency.h>
> +#include <linux/cleanup.h>
> +#include <linux/delay.h>
> +#include <linux/errno.h>
> +#include <linux/init.h>
> +#include <linux/kernel.h>
> +#include <linux/mutex.h>
> +#include <linux/nmi.h>
> +
> +#define SMCCC_CACHE_MAX_RETRIES 5
> +#define SMCCC_CACHE_MAX_DELAY_US 20000
> +
> +/* DEN0028 v1.7: bit[0] == 1 means implementation flushes all caches globally */
> +#define SMCCC_CACHE_ATTR_GLOBAL_OP BIT(0)
> +
> +struct arm64_smccc_cache {
> + /* Must be first member */
> + struct cache_coherency_ops_inst cci;
> + struct mutex lock; /* Serializes SMCCC cache maintenance calls. */
> + u32 latency_us;
> + u32 rate_limit;
> + bool global_op;
> + u64 global_flush_gen;
> +};
> +
> +static struct arm64_smccc_cache *arm64_smccc_cache;
Whilst it is harmless, why do we need the global? I don't think anything outside
of init() ever uses it. Given there is no exit() anyway, might as well just leak
the pointer.
> +
> +static int smccc_cache_status_to_errno(s32 status)
> +{
> + switch (status) {
> + case SMCCC_RET_SUCCESS:
> + return 0;
> + case SMCCC_RET_NOT_SUPPORTED:
> + case SMCCC_RET_NOT_REQUIRED:
I'm not seeing this in the list of possible errors and
I'm far from sure what it would mean in this case if we got it!
Maybe it would indicate that the cache was known not dirty for
some reason. I'd left default deal with this one probably.
> + return -EOPNOTSUPP;
> + case SMCCC_RET_INVALID_PARAMETER:
> + return -EINVAL;
> + case SMCCC_RET_RATE_LIMITED:
> + return -EAGAIN;
> + case SMCCC_RET_BUSY:
> + return -EBUSY;
> + default:
> + return -EIO;
> + }
> +}
> +
> +static int smccc_cache_delay_us(const struct arm64_smccc_cache *cache)
> +{
> + u64 delay_us = 0;
> +
> + if (cache->rate_limit)
> + delay_us = DIV_ROUND_UP_ULL(USEC_PER_SEC, cache->rate_limit);
> +
> + if (cache->latency_us)
> + delay_us = max_t(u64, delay_us, cache->latency_us);
max() should be fine here I think.
> +
> + if (!delay_us)
> + delay_us = 1000;
Why? Needs a comment I think.
> +
> + return min_t(u64, delay_us, SMCCC_CACHE_MAX_DELAY_US);
The type forcing needed? I might be missing why min() isn't fine here.
Doesn't seem to be in the list in the minmax.h docs for when you can't
just use min().
> +}
> +
> +static int arm64_smccc_cache_wbinv(struct cache_coherency_ops_inst *cci,
> + struct cc_inval_params *invp)
> +{
> + struct arm64_smccc_cache *cache =
> + container_of(cci, struct arm64_smccc_cache, cci);
> + struct arm_smccc_res res = {};
> + int delay_us = smccc_cache_delay_us(cache);
> + u64 gen = 0;
> + s32 status;
> + int ret;
> + int i;
> +
> + if (!invp->size)
> + return -EINVAL;
> +
> + if (cache->global_op)
> + gen = READ_ONCE(cache->global_flush_gen);
> +
> + guard(mutex)(&cache->lock);
> +
> + /*
> + * If firmware reports a global operation type, a successful operation
> + * covers every request that was already waiting behind it. Skip if the
> + * generation advanced while this request was waiting to enter the
> + * serialized firmware call path.
Perhaps call out that the serialization is on the lock. I read this as
there being another level of serialization going on and got confused ;)
Can see there might be further improvements to the non global case
using same principle you have here. I guess leave those until we have
any info on whether they are useful.
> + */
> + if (cache->global_op && gen != READ_ONCE(cache->global_flush_gen))
> + return 0;
> +
> + for (i = 0; i < SMCCC_CACHE_MAX_RETRIES; i++) {
Can drag the int i in here, maybe make it unsigned too.
for (unsigned int i = 0; i <...
This is becoming widely accepted in kernel code these days.
> + /* Long firmware operations can trigger watchdog checks. */
> + touch_nmi_watchdog();
> +
> + arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_CLEAN_INV_MEMREGION,
> + invp->addr, invp->size, 0UL, &res);
> + status = (s32)res.a0;
> + ret = smccc_cache_status_to_errno(status);
Given status isn't used for anything else - tiny bit neater perhaps as
ret = smccc_cache_status_to_errno((s32)res.a0);
> + if (!ret) {
> + if (cache->global_op) {
> + WRITE_ONCE(cache->global_flush_gen,
> + cache->global_flush_gen + 1);
> + }
> + return 0;
> + }
> +
> + if (ret != -EBUSY && ret != -EAGAIN)
> + return ret;
> +
> + usleep_range(delay_us, delay_us + 100);
fsleep() for this sort of thing in modern code.
> + }
> +
> + return -EBUSY;
> +}
> +
> +static int __init arm64_smccc_cache_init(void)
> +{
> + struct arm_smccc_res res = {};
> + s32 status;
> + int ret;
> +
> + if (arm_smccc_get_version() < ARM_SMCCC_VERSION_1_1)
> + return -ENODEV;
> +
> + if (arm_smccc_1_1_get_conduit() == SMCCC_CONDUIT_NONE)
> + return -ENODEV;
> +
> + arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
> + ARM_SMCCC_ARCH_CLEAN_INV_MEMREGION, &res);
> + status = (s32)res.a0;
> + if (status < 0)
> + return -ENODEV;
Maybe there is convention for this, but feels a bit odd to return -ENODEV
for a feature check on a 'device' we are talking to. Maybe -EOPNOTSUPP?
Anyhow, that's a question for SMCCC folk. The only error that could
be returned is NOT_SUPPORTED and you do that above for the returns from
actual calls.
> +
> + arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
> + ARM_SMCCC_ARCH_CLEAN_INV_MEMREGION_ATTRIBUTES, &res);
> + status = (s32)res.a0;
> + if (status < 0)
> + return -ENODEV;
> +
> + arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_CLEAN_INV_MEMREGION_ATTRIBUTES, &res);
> + status = (s32)res.a0;
> + if (status)
> + return -ENODEV;
> +
> + arm64_smccc_cache =
> + cache_coherency_ops_instance_alloc(&arm64_smccc_cache_ops,
> + struct arm64_smccc_cache,
> + cci);
I'd go long on that just for readability but not important.
> + if (!arm64_smccc_cache)
> + return -ENOMEM;
> +
> + mutex_init(&arm64_smccc_cache->lock);
> + arm64_smccc_cache->latency_us = lower_32_bits(res.a2);
> + arm64_smccc_cache->rate_limit = lower_32_bits(res.a3);
> + arm64_smccc_cache->global_op = !!(res.a1 & SMCCC_CACHE_ATTR_GLOBAL_OP);
> +
> + ret = cache_coherency_ops_instance_register(&arm64_smccc_cache->cci);
> + if (ret) {
> + cache_coherency_ops_instance_put(&arm64_smccc_cache->cci);
> + arm64_smccc_cache = NULL;
> + return ret;
> + }
> +
> + pr_info("SMCCC cache clean+invalidate provider registered\n")
Trivial: blank line here. Just helps the error path stand out vs the
print.
> + return 0;
> +}
> +arch_initcall(arm64_smccc_cache_init);
^ permalink raw reply
* Re: [PATCH v3] i2c: imx: mark I2C adapter when hardware is powered down
From: Mukesh Savaliya @ 2026-05-21 11:14 UTC (permalink / raw)
To: Carlos Song (OSS), Mukesh Savaliya, o.rempel@pengutronix.de,
kernel@pengutronix.de, andi.shyti@kernel.org, Frank Li,
s.hauer@pengutronix.de, festevam@gmail.com, Carlos Song,
Bough Chen
Cc: linux-i2c@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
In-Reply-To: <AM0PR04MB6802FE8B0E0BEF8CDA6DAD5EE80E2@AM0PR04MB6802.eurprd04.prod.outlook.com>
On 5/21/2026 4:21 PM, Carlos Song (OSS) wrote:
[...]
>>>> -----Original Message-----
>>>> From: Mukesh Savaliya <mukesh.savaliya@oss.qualcomm.com>
>>>> Sent: Thursday, May 21, 2026 3:40 PM
>>>> To: Carlos Song (OSS) <carlos.song@oss.nxp.com>;
>>>> o.rempel@pengutronix.de; kernel@pengutronix.de;
>>>> andi.shyti@kernel.org; Frank Li <frank.li@nxp.com>;
>>>> s.hauer@pengutronix.de; festevam@gmail.com; Carlos Song
>>>> <carlos.song@nxp.com>; Bough Chen <haibo.chen@nxp.com>
>>>> Cc: linux-i2c@vger.kernel.org; imx@lists.linux.dev;
>>>> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
>>>> stable@vger.kernel.org
>>>> Subject: Re: [PATCH v3] i2c: imx: mark I2C adapter when hardware is
>>>> powered down
>>>>
>>>> Hi Carlos,
>>>>
>>>> On 5/20/2026 3:45 PM, Carlos Song (OSS) wrote:
>>>>> From: Carlos Song <carlos.song@nxp.com>
>>>>>
>>>>> Mark the I2C adapter as suspended during system suspend to block
>>>>> further transfers, and resume it on system resume. This prevents
>>>>> potential hangs when the hardware is powered down but clients still
>>>>> attempt
>>>> I2C transfers.
>>>>>
>> what was the reason of this hang ? I was thinking you don't have interrupts
>> working when client requested transfer but adapter was suspended. Please
>> correct me if wrong.
>>
>> And it would be good to mention the actual problem and why/how it occurred.
>>>> Code changes looks fine to me but have comment on commit log.
>>>>
>>>> It seems, you are adding support of _noirq() callbacks to allow
>>>> transfers during suspend/resume noirq phase of PM.
>>>>
>>>> Would it make sense if you can write "Replace system PM callbacks
>>>> with noirq PM callbacks" OR "Allow transfers during _noirq phase of
>>>> the PM ops" instead of "mark I2C adapter when hardware is powered
>> down" ?
>>>>
>>>
>>> Hi,
>>>
>>> Thank you for your comments!
>>>
>>> But this patch is added is not for support noirq PM callback or transfer in noirq
>> phase.
>>>
>> Okay, may be actual problem description can help me.
>>> In fact, this fix is to mark the I2C adapter as suspended during
>>> system noirq suspend to block further transfers, and resume it on
>>> system noirq resume. This is to prohibit I2C device calling the I2C
>>> controller after the system noirq suspend and before noirq resume, because at
>> this time the I2C instance is powered off or the clock is disabled ... So I want to
>> keep current commit. How do you think?
>> completely Makes sense. Please help add how this problem occurred and why ?
>> So the change/fix will be good to understand against it.
>
> Hi,
>
> In some I.MX platform, some I2C devices will keep a work queue all time, the work queue will
> trigger I2C xfer every once in a while, but the work queue shouldn't be free in system suspend.
>
work queue has transfers queued even if system is suspended ? IMO, the
client i2c devices should not let system go to suspend.
> Within a very short time window, possibly from noirq_suspend to the system actually being suspended,
> or possibly from the system starting to resume to before noirq_resume, this work queue will trigger an
> I2C transfer, and at this time the I2C controller's clk and pinctrl have not yet been restored, reading and
Right, this kind of explains the problem to me. I think you are trying
to serve i2c transfers when your resources(clk, pinctrl) are not turned
ON and also interrupt remains disabled. And that's why you need to add
_noir() PM callbacks supports along with IRQF_NO_SUSPEND |
IRQF_EARLY_RESUME flags.
> writing I2C registers causes the system to hang. This patch make all I2C operations are performed in a safe
> hardware state.
>
> Is it better if I add these comment to patch commit log?
>>>
if my latest comments makes sense against the issue, you may write
accordingly. if i am wrong, then your explanation makes sense. Cause of
the hang needs to be clearly mention int the commit log in your next patch.
>>> Carlos Song
>>
>
^ permalink raw reply
* Re: [PATCH v8 net-next 00/15] Add preliminary NETC switch support for i.MX94
From: patchwork-bot+netdevbpf @ 2026-05-21 11:10 UTC (permalink / raw)
To: Wei Fang
Cc: claudiu.manoil, vladimir.oltean, xiaoning.wang, andrew+netdev,
davem, edumazet, kuba, pabeni, robh, krzk+dt, conor+dt,
f.fainelli, frank.li, chleroy, horms, linux, maxime.chevallier,
andrew, olteanv, netdev, linux-kernel, devicetree, linuxppc-dev,
linux-arm-kernel, imx
In-Reply-To: <20260518082506.1318236-1-wei.fang@nxp.com>
Hello:
This series was applied to netdev/net-next.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Mon, 18 May 2026 16:24:51 +0800 you wrote:
> i.MX94 NETC (v4.3) integrates 802.1Q Ethernet switch functionality, the
> switch provides advanced QoS with 8 traffic classes and a full range of
> TSN standards capabilities. It has 3 user ports and 1 CPU port, and the
> CPU port is connected to an internal ENETC through the pseduo link, so
> instead of a back-to-back MAC, the lightweight "pseudo MAC" is used at
> both ends of the pseudo link to transfer Ethernet frames. The pseudo
> link provides a zero-copy interface (no serialization delay) and lower
> power (less logic and memory).
>
> [...]
Here is the summary with links:
- [v8,net-next,01/15] dt-bindings: net: dsa: update the description of 'dsa,member' property
https://git.kernel.org/netdev/net-next/c/0c89a779c373
- [v8,net-next,02/15] dt-bindings: net: dsa: add NETC switch
https://git.kernel.org/netdev/net-next/c/6d019124be60
- [v8,net-next,03/15] net: enetc: add pre-boot initialization for i.MX94 switch
https://git.kernel.org/netdev/net-next/c/f059d55fd8a0
- [v8,net-next,04/15] net: enetc: add basic operations to the FDB table
https://git.kernel.org/netdev/net-next/c/4566269803ff
- [v8,net-next,05/15] net: enetc: add support for the "Add" operation to VLAN filter table
https://git.kernel.org/netdev/net-next/c/d0ac4d4bd299
- [v8,net-next,06/15] net: enetc: add support for the "Update" operation to buffer pool table
https://git.kernel.org/netdev/net-next/c/cb4d95d79d85
- [v8,net-next,07/15] net: enetc: add support for "Add" and "Delete" operations to IPFT
https://git.kernel.org/netdev/net-next/c/123db6a27511
- [v8,net-next,08/15] net: enetc: add multiple command BD rings support
https://git.kernel.org/netdev/net-next/c/c5aed83ddc53
- [v8,net-next,09/15] net: dsa: add NETC switch tag support
https://git.kernel.org/netdev/net-next/c/0850005c26d2
- [v8,net-next,10/15] net: dsa: netc: introduce NXP NETC switch driver for i.MX94
https://git.kernel.org/netdev/net-next/c/187fbae024c8
- [v8,net-next,11/15] net: dsa: netc: add phylink MAC operations
https://git.kernel.org/netdev/net-next/c/bbe97e347219
- [v8,net-next,12/15] net: dsa: netc: add FDB, STP, MTU, port setup and host flooding support
https://git.kernel.org/netdev/net-next/c/46d6407692c8
- [v8,net-next,13/15] net: dsa: netc: initialize buffer pool table and implement flow-control
https://git.kernel.org/netdev/net-next/c/a5ccb7f5e067
- [v8,net-next,14/15] net: dsa: netc: add support for the standardized counters
https://git.kernel.org/netdev/net-next/c/25049d8b6e6b
- [v8,net-next,15/15] net: dsa: netc: add support for ethtool private statistics
https://git.kernel.org/netdev/net-next/c/beb0e54f3806
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* RE: [PATCH v3] i2c: imx: mark I2C adapter when hardware is powered down
From: Carlos Song (OSS) @ 2026-05-21 10:51 UTC (permalink / raw)
To: Mukesh Savaliya, Carlos Song (OSS), o.rempel@pengutronix.de,
kernel@pengutronix.de, andi.shyti@kernel.org, Frank Li,
s.hauer@pengutronix.de, festevam@gmail.com, Carlos Song,
Bough Chen
Cc: linux-i2c@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
In-Reply-To: <22af0378-a3c9-4403-a0ee-da794847f41d@oss.qualcomm.com>
> -----Original Message-----
> From: Mukesh Savaliya <mukesh.savaliya@oss.qualcomm.com>
> Sent: Thursday, May 21, 2026 6:17 PM
> To: Carlos Song (OSS) <carlos.song@oss.nxp.com>; Mukesh Savaliya
> <mukesh.savaliya@oss.qualcomm.com>; o.rempel@pengutronix.de;
> kernel@pengutronix.de; andi.shyti@kernel.org; Frank Li <frank.li@nxp.com>;
> s.hauer@pengutronix.de; festevam@gmail.com; Carlos Song
> <carlos.song@nxp.com>; Bough Chen <haibo.chen@nxp.com>
> Cc: linux-i2c@vger.kernel.org; imx@lists.linux.dev;
> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
> stable@vger.kernel.org
> Subject: Re: [PATCH v3] i2c: imx: mark I2C adapter when hardware is powered
> down
>
> [You don't often get email from mukesh.savaliya@oss.qualcomm.com. Learn
> why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> Thanks Carlos !
>
> On 5/21/2026 1:57 PM, Carlos Song (OSS) wrote:
> >
> >
> >> -----Original Message-----
> >> From: Mukesh Savaliya <mukesh.savaliya@oss.qualcomm.com>
> >> Sent: Thursday, May 21, 2026 3:40 PM
> >> To: Carlos Song (OSS) <carlos.song@oss.nxp.com>;
> >> o.rempel@pengutronix.de; kernel@pengutronix.de;
> >> andi.shyti@kernel.org; Frank Li <frank.li@nxp.com>;
> >> s.hauer@pengutronix.de; festevam@gmail.com; Carlos Song
> >> <carlos.song@nxp.com>; Bough Chen <haibo.chen@nxp.com>
> >> Cc: linux-i2c@vger.kernel.org; imx@lists.linux.dev;
> >> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
> >> stable@vger.kernel.org
> >> Subject: Re: [PATCH v3] i2c: imx: mark I2C adapter when hardware is
> >> powered down
> >>
> >> [You don't often get email from mukesh.savaliya@oss.qualcomm.com.
> >> Learn why this is important at
> >> https://aka.ms/LearnAboutSenderIdentification ]
> >>
> >> Hi Carlos,
> >>
> >> On 5/20/2026 3:45 PM, Carlos Song (OSS) wrote:
> >>> From: Carlos Song <carlos.song@nxp.com>
> >>>
> >>> Mark the I2C adapter as suspended during system suspend to block
> >>> further transfers, and resume it on system resume. This prevents
> >>> potential hangs when the hardware is powered down but clients still
> >>> attempt
> >> I2C transfers.
> >>>
> what was the reason of this hang ? I was thinking you don't have interrupts
> working when client requested transfer but adapter was suspended. Please
> correct me if wrong.
>
> And it would be good to mention the actual problem and why/how it occurred.
> >> Code changes looks fine to me but have comment on commit log.
> >>
> >> It seems, you are adding support of _noirq() callbacks to allow
> >> transfers during suspend/resume noirq phase of PM.
> >>
> >> Would it make sense if you can write "Replace system PM callbacks
> >> with noirq PM callbacks" OR "Allow transfers during _noirq phase of
> >> the PM ops" instead of "mark I2C adapter when hardware is powered
> down" ?
> >>
> >
> > Hi,
> >
> > Thank you for your comments!
> >
> > But this patch is added is not for support noirq PM callback or transfer in noirq
> phase.
> >
> Okay, may be actual problem description can help me.
> > In fact, this fix is to mark the I2C adapter as suspended during
> > system noirq suspend to block further transfers, and resume it on
> > system noirq resume. This is to prohibit I2C device calling the I2C
> > controller after the system noirq suspend and before noirq resume, because at
> this time the I2C instance is powered off or the clock is disabled ... So I want to
> keep current commit. How do you think?
> completely Makes sense. Please help add how this problem occurred and why ?
> So the change/fix will be good to understand against it.
Hi,
In some I.MX platform, some I2C devices will keep a work queue all time, the work queue will
trigger I2C xfer every once in a while, but the work queue shouldn't be free in system suspend.
Within a very short time window, possibly from noirq_suspend to the system actually being suspended,
or possibly from the system starting to resume to before noirq_resume, this work queue will trigger an
I2C transfer, and at this time the I2C controller's clk and pinctrl have not yet been restored, reading and
writing I2C registers causes the system to hang. This patch make all I2C operations are performed in a safe
hardware state.
Is it better if I add these comment to patch commit log?
> >
> > Carlos Song
>
^ permalink raw reply
* Re: [PATCH] [RFC] arm64: mmu: use range based TLB flushing when hot unplugging memory
From: Balbir Singh @ 2026-05-21 10:46 UTC (permalink / raw)
To: Ryan Roberts
Cc: Alistair Popple, linux-arm-kernel, linux-kernel, linux-mm,
catalin.marinas, will, david, anshuman.khandual, dev.jain,
jhubbard
In-Reply-To: <bc96d822-bb68-4945-9f74-68f77e389ac6@arm.com>
On Thu, May 21, 2026 at 09:50:04AM +0100, Ryan Roberts wrote:
> On 21/05/2026 05:24, Alistair Popple wrote:
> > Hot unplugging memory on ARM64 requires a TLB invalidate after unmapping
> > the page to be hot unplugged from the direct map. Currently that happens
> > one page at a time, meaning range based invalidates cannot be used. The
> > result of this is that removing large amounts of memory takes a long
> > time and in some cases can trigger an RCU stall warning.
> >
> > For example on one system hot unplugging 480GB of memory takes ~1
> > minute. With this change the same operation took ~1 second, a 60x
> > improvement.
> >
> > Signed-off-by: Alistair Popple <apopple@nvidia.com>
> >
> > ---
> >
> > This is an RFC, because I'm not sure the change is correct as it frees
> > the PTE page before flushing the TLB. I'm not familiar enough with ARM64
> > architecture to be sure this is safe, for example I don't know if HW
> > can update PTE bits such as access/dirty in the page through a stale
> > TLB entry.
> >
> > If so this would open a window during which the page is free but could
> > still be written to. Likely the safe option would be to collect all the
> > pages to be free on a list and free them after doing the range based TLB
> > flush, but wanted to get feedback on the approach before implementing it
> > which is the goal of this RFC.
>
> Hi Alistair,
>
> This patch doesn't apply on v7.1-rc4 because it conflicts with this patch:
>
> Commit 48478b9f79137 ("arm64/mm: Enable batched TLB flush in unmap_hotplug_range()")
>
> which has a very similar performance improvement, so hopefully it solves your
> problem?
>
> There are two paths which use this logic; unmapping the linear map and unmapping
> the corresponding vmemmap. In the latter case, the memory is also freed, so we
> can't safely do the range optimizaiton there since the TLB needs to be flushed
> before freeing the memory. But the linear map is the big, slow bit so hopefully
> it's sufficent for you?
>
I assume vmemmap path is for tearing down the struct pages corresponding
to the physical memory and vmemmap teardowns taking a flush should be
OK. It is worth checking if the issue is already fixed.
Balbir
<snip>
^ permalink raw reply
* Re: [PATCH v4 4/5] KVM: arm64: Fix bounds checking in do_ffa_mem_reclaim()
From: Mostafa Saleh @ 2026-05-21 10:43 UTC (permalink / raw)
To: Marc Zyngier
Cc: op-tee, linux-kernel, kvmarm, linux-arm-kernel, oupton,
joey.gouly, suzuki.poulose, catalin.marinas, jens.wiklander,
sumit.garg, sebastianene, vdonnefort, sudeep.holla
In-Reply-To: <ag7eq3bfBOxfaZ59@google.com>
On Thu, May 21, 2026 at 11:30 AM Mostafa Saleh <smostafa@google.com> wrote:
>
> Hi Marc,
>
> On Thu, May 21, 2026 at 09:28:46AM +0100, Marc Zyngier wrote:
> > On Wed, 20 May 2026 21:49:47 +0100,
> > Mostafa Saleh <smostafa@google.com> wrote:
> > >
> > > Sashiko (locally) reports out of bound write possiblity if SPMD
> > > returns an invalid data.
> > >
> > > While SPMD is considered trusted, pKVM does some basic checks,
> > > for offset to be less than or equal len.
> > >
> > > However, that is incorrect as even if the offset is smaller than
> > > len pKVM can still access out of bound memory in the next
> > > ffa_host_unshare_ranges().
> > >
> > > Split this check into 2:
> > > 1- Check that the fixed portion of the descriptor fits.
> > > 2- After getting reg, check the variable array size addr_range_cnt
> > > fits.
> > >
> > > Signed-off-by: Mostafa Saleh <smostafa@google.com>
> > > ---
> > > arch/arm64/kvm/hyp/nvhe/ffa.c | 7 ++++++-
> > > 1 file changed, 6 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> > > index 1af722771178..e6aa2bfa63b1 100644
> > > --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> > > +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
> > > @@ -607,7 +607,7 @@ static void do_ffa_mem_reclaim(struct arm_smccc_1_2_regs *res,
> > > * check that we end up with something that doesn't look _completely_
> > > * bogus.
> > > */
> > > - if (WARN_ON(offset > len ||
> > > + if (WARN_ON(offset + CONSTITUENTS_OFFSET(0) > len ||
> > > fraglen > KVM_FFA_MBOX_NR_PAGES * PAGE_SIZE)) {
> >
> > Do you really want to keep this a WARN_ON(), given that this results
> > in a panic in most pKVM configurations?
>
> Which kind of configuration will that check fail on?
> Does that mean at the moment pKVM does out-of-bound access for
> the header?
>
I might have misunderstood the point. I thought you meant the new
change would cause a panic on most configurations, or were you
suggesting just removing the WARN_ON?
I can do that, I just updated the current faulty check and left the
WARN_ON as is.
Thanks,
Mostafa
> Thanks,
> Mostafa
>
> >
> > Thanks,
> >
> > M.
> >
> > --
> > Without deviation from the norm, progress is not possible.
^ permalink raw reply
* [soc:xz/dt] BUILD SUCCESS 7d1f68e87b7302d0bd22c001e6c0511d0e827875
From: kernel test robot @ 2026-05-21 10:43 UTC (permalink / raw)
To: Stefan Dösinger ; +Cc: linux-arm-kernel, arm
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git xz/dt
branch HEAD: 7d1f68e87b7302d0bd22c001e6c0511d0e827875 ARM: dts: zte: Add D-Link DWR-932M support
elapsed time: 829m
configs tested: 197
configs skipped: 3
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-23
arc defconfig gcc-15.2.0
arc randconfig-001-20260521 gcc-8.5.0
arc randconfig-002-20260521 gcc-8.5.0
arm allnoconfig clang-23
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm defconfig gcc-15.2.0
arm footbridge_defconfig clang-17
arm randconfig-001-20260521 gcc-8.5.0
arm randconfig-002-20260521 gcc-8.5.0
arm randconfig-003-20260521 gcc-8.5.0
arm randconfig-004-20260521 gcc-8.5.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260521 gcc-8.5.0
arm64 randconfig-002-20260521 gcc-8.5.0
arm64 randconfig-003-20260521 gcc-8.5.0
arm64 randconfig-004-20260521 gcc-8.5.0
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260521 gcc-8.5.0
csky randconfig-002-20260521 gcc-8.5.0
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig clang-23
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260521 gcc-11.5.0
hexagon randconfig-002-20260521 gcc-11.5.0
i386 allmodconfig clang-20
i386 allmodconfig gcc-14
i386 allnoconfig gcc-14
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 buildonly-randconfig-001-20260521 clang-20
i386 buildonly-randconfig-002-20260521 clang-20
i386 buildonly-randconfig-003-20260521 clang-20
i386 buildonly-randconfig-004-20260521 clang-20
i386 buildonly-randconfig-005-20260521 clang-20
i386 buildonly-randconfig-006-20260521 clang-20
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260521 clang-20
i386 randconfig-002-20260521 clang-20
i386 randconfig-003-20260521 clang-20
i386 randconfig-004-20260521 clang-20
i386 randconfig-005-20260521 clang-20
i386 randconfig-006-20260521 clang-20
i386 randconfig-007-20260521 clang-20
i386 randconfig-011-20260521 gcc-14
i386 randconfig-012-20260521 gcc-14
i386 randconfig-013-20260521 gcc-14
i386 randconfig-014-20260521 gcc-14
i386 randconfig-015-20260521 gcc-14
i386 randconfig-016-20260521 gcc-14
i386 randconfig-017-20260521 gcc-14
loongarch allmodconfig clang-23
loongarch allnoconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260521 gcc-11.5.0
loongarch randconfig-002-20260521 gcc-11.5.0
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k defconfig clang-19
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
mips cavium_octeon_defconfig gcc-15.2.0
mips rt305x_defconfig clang-23
nios2 10m50_defconfig gcc-11.5.0
nios2 allmodconfig clang-23
nios2 allnoconfig clang-23
nios2 defconfig clang-19
nios2 randconfig-001-20260521 gcc-11.5.0
nios2 randconfig-002-20260521 gcc-11.5.0
openrisc allmodconfig clang-23
openrisc allnoconfig clang-23
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allyesconfig clang-19
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260521 gcc-12.5.0
parisc randconfig-002-20260521 gcc-12.5.0
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc mgcoge_defconfig clang-23
powerpc mpc837x_rdb_defconfig gcc-15.2.0
powerpc randconfig-001-20260521 gcc-12.5.0
powerpc randconfig-002-20260521 gcc-12.5.0
powerpc sam440ep_defconfig gcc-15.2.0
powerpc64 randconfig-001-20260521 gcc-12.5.0
powerpc64 randconfig-002-20260521 gcc-12.5.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001 gcc-15.2.0
riscv randconfig-001-20260521 gcc-15.2.0
riscv randconfig-002 gcc-15.2.0
riscv randconfig-002-20260521 gcc-15.2.0
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001 gcc-15.2.0
s390 randconfig-001-20260521 gcc-15.2.0
s390 randconfig-002 gcc-15.2.0
s390 randconfig-002-20260521 gcc-15.2.0
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allyesconfig clang-19
sh defconfig gcc-14
sh randconfig-001 gcc-15.2.0
sh randconfig-001-20260521 gcc-15.2.0
sh randconfig-002 gcc-15.2.0
sh randconfig-002-20260521 gcc-15.2.0
sparc allnoconfig clang-23
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260521 gcc-8.5.0
sparc randconfig-002-20260521 gcc-8.5.0
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260521 gcc-8.5.0
sparc64 randconfig-002-20260521 gcc-8.5.0
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260521 gcc-8.5.0
um randconfig-002-20260521 gcc-8.5.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260521 clang-20
x86_64 buildonly-randconfig-002-20260521 clang-20
x86_64 buildonly-randconfig-003-20260521 clang-20
x86_64 buildonly-randconfig-004-20260521 clang-20
x86_64 buildonly-randconfig-005-20260521 clang-20
x86_64 buildonly-randconfig-006-20260521 clang-20
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20260521 clang-20
x86_64 randconfig-002-20260521 clang-20
x86_64 randconfig-003-20260521 clang-20
x86_64 randconfig-004-20260521 clang-20
x86_64 randconfig-005-20260521 clang-20
x86_64 randconfig-006-20260521 clang-20
x86_64 randconfig-011 gcc-14
x86_64 randconfig-011-20260521 gcc-14
x86_64 randconfig-012 gcc-14
x86_64 randconfig-012-20260521 gcc-14
x86_64 randconfig-013 gcc-14
x86_64 randconfig-013-20260521 gcc-14
x86_64 randconfig-014 gcc-14
x86_64 randconfig-014-20260521 gcc-14
x86_64 randconfig-015 gcc-14
x86_64 randconfig-015-20260521 gcc-14
x86_64 randconfig-016 gcc-14
x86_64 randconfig-016-20260521 gcc-14
x86_64 randconfig-071 clang-20
x86_64 randconfig-071-20260521 clang-20
x86_64 randconfig-072 clang-20
x86_64 randconfig-072-20260521 clang-20
x86_64 randconfig-073 clang-20
x86_64 randconfig-073-20260521 clang-20
x86_64 randconfig-074 clang-20
x86_64 randconfig-074-20260521 clang-20
x86_64 randconfig-075 clang-20
x86_64 randconfig-075-20260521 clang-20
x86_64 randconfig-076 clang-20
x86_64 randconfig-076-20260521 clang-20
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-23
xtensa allyesconfig clang-23
xtensa randconfig-001-20260521 gcc-8.5.0
xtensa randconfig-002-20260521 gcc-8.5.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: (subset) [PATCH 0/4] power: sys-off: fix Pixel C shutdown via MAX77620
From: Lee Jones @ 2026-05-21 10:41 UTC (permalink / raw)
To: Diogo Ivo
Cc: Mark Rutland, Lorenzo Pieralisi, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Thierry Reding, Jonathan Hunter, linux-arm-kernel,
linux-kernel, devicetree, linux-tegra
In-Reply-To: <31ef61bd-6672-440a-a52e-eedb950d3d03@tecnico.ulisboa.pt>
On Thu, 21 May 2026, Diogo Ivo wrote:
> Hi Lee,
>
> On 5/20/26 18:25, Lee Jones wrote:
> > On Thu, 14 May 2026 16:47:18 +0200, Diogo Ivo wrote:
> > > This series migrates PSCI and MAX77620 poweroff handling to the
> > > sys-off framework and fixes shutdown on the Pixel C (Smaug).
> > >
> > > The first two patches replace legacy pm_power_off usage in the PSCI
> > > and MAX77620 drivers with sys-off handlers. Besides aligning both
> > > drivers with the modern poweroff infrastructure, this removes the
> > > global callback dependency and allows multiple handlers to coexist
> > > with explicit priorities.
> > >
> > > [...]
> >
> > Applied, thanks!
>
> Thanks for applying the patches! Just a question and an observation:
>
> - I'm assuming you were ok with merging [2/4] despite the possible
> deadlock since this risk is already present in mainline in the same
> form so we're not actually making things worse, is that so?
Did you see the text below?
Both patches 2 and 3 are applied.
> - The observation is that the comment about overriding PSCI is only
> true after (and if) a reworked [1/4] is actually merged.
> If it isn't then patch [3/4] is actually working around another handler
> in soc/tegra/pmc.c where a handler that only does work for the Nexus
> 7 is actually registered at FIRMWARE level for all platforms that
> probe that driver (I will send out a patch shortly to only register
> the handler on the Nexus 7).
I assume the other patches will be applied soon.
If this causes some kind of issue - let me know later on in the cycle
and I'll remove whatever patches you ask me to.
--
Lee Jones
^ permalink raw reply
* [PATCH v3] i2c: imx-lpi2c: reset controller in probe stage
From: Carlos Song (OSS) @ 2026-05-21 10:35 UTC (permalink / raw)
To: aisheng.dong, andi.shyti, Frank.Li, s.hauer, kernel, festevam
Cc: linux-i2c, imx, linux-arm-kernel, linux-kernel, Carlos Song
From: Carlos Song <carlos.song@nxp.com>
Reset I2C controller in probe stage to avoid unexpected LPI2C controller
state left from previous stages and hang system boot.
Per the LPI2C reference manual, section 7.1.4 "Controller Control (MCR)"
and 7.1.20 Target Control (SCR), the RST bit (bit 1) description states:
"The reset takes effect immediately and remains asserted until negated
by software. There is no minimum delay required before clearing the
software reset."
Therefore, it is safe to write 0 to MCR and SCR immediately after
asserting the RST bit without any additional delay.
Signed-off-by: Carlos Song <carlos.song@nxp.com>
---
Change for v3:
- Reset the Target logic via LPI2C_SCR.
- Replacing pm_runtime_put_sync() with pm_runtime_disable() +
pm_runtime_set_suspended() + pm_runtime_put_noidle() to avoid
triggering the suspend callback, and explicitly calling
clk_bulk_disable_unprepare() for clock cleanup.
- Add new error path free_irq and clk_disable to cover more
complete error recovery.
- Remake commit log adding SCR RST section.
Change for v2:
- Jump to rpm_disable instread of returning directly if the IRQ request
fails
---
drivers/i2c/busses/i2c-imx-lpi2c.c | 52 +++++++++++++++++++++---------
1 file changed, 37 insertions(+), 15 deletions(-)
diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c b/drivers/i2c/busses/i2c-imx-lpi2c.c
index e6c24a9d934d..4929f85ab485 100644
--- a/drivers/i2c/busses/i2c-imx-lpi2c.c
+++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
@@ -1510,11 +1510,6 @@ static int lpi2c_imx_probe(struct platform_device *pdev)
if (ret)
lpi2c_imx->bitrate = I2C_MAX_STANDARD_MODE_FREQ;
- ret = devm_request_irq(&pdev->dev, lpi2c_imx->irq, lpi2c_imx_isr, IRQF_NO_SUSPEND,
- pdev->name, lpi2c_imx);
- if (ret)
- return dev_err_probe(&pdev->dev, ret, "can't claim irq %d\n", lpi2c_imx->irq);
-
i2c_set_adapdata(&lpi2c_imx->adapter, lpi2c_imx);
platform_set_drvdata(pdev, lpi2c_imx);
@@ -1527,14 +1522,18 @@ static int lpi2c_imx_probe(struct platform_device *pdev)
* each transfer
*/
ret = devm_clk_rate_exclusive_get(&pdev->dev, lpi2c_imx->clks[0].clk);
- if (ret)
- return dev_err_probe(&pdev->dev, ret,
- "can't lock I2C peripheral clock rate\n");
+ if (ret) {
+ dev_err_probe(&pdev->dev, ret,
+ "can't lock I2C peripheral clock rate\n");
+ goto clk_disable;
+ }
lpi2c_imx->rate_per = clk_get_rate(lpi2c_imx->clks[0].clk);
- if (!lpi2c_imx->rate_per)
- return dev_err_probe(&pdev->dev, -EINVAL,
- "can't get I2C peripheral clock rate\n");
+ if (!lpi2c_imx->rate_per) {
+ ret = dev_err_probe(&pdev->dev, -EINVAL,
+ "can't get I2C peripheral clock rate\n");
+ goto clk_disable;
+ }
if (lpi2c_imx->hwdata->need_prepare_unprepare_clk)
pm_runtime_set_autosuspend_delay(&pdev->dev, I2C_PM_LONG_TIMEOUT_MS);
@@ -1546,27 +1545,43 @@ static int lpi2c_imx_probe(struct platform_device *pdev)
pm_runtime_set_active(&pdev->dev);
pm_runtime_enable(&pdev->dev);
+ /*
+ * Reset all internal controller logic and registers to avoid effects of previous status
+ * Reset both Master and Target logic to prevent interrupt storms
+ */
+ writel(MCR_RST, lpi2c_imx->base + LPI2C_MCR);
+ writel(SCR_RST, lpi2c_imx->base + LPI2C_SCR);
+ writel(0, lpi2c_imx->base + LPI2C_MCR);
+ writel(0, lpi2c_imx->base + LPI2C_SCR);
+
temp = readl(lpi2c_imx->base + LPI2C_PARAM);
lpi2c_imx->txfifosize = 1 << (temp & 0x0f);
lpi2c_imx->rxfifosize = 1 << ((temp >> 8) & 0x0f);
+ ret = devm_request_irq(&pdev->dev, lpi2c_imx->irq, lpi2c_imx_isr, IRQF_NO_SUSPEND,
+ pdev->name, lpi2c_imx);
+ if (ret) {
+ dev_err_probe(&pdev->dev, ret, "can't claim irq %d\n", lpi2c_imx->irq);
+ goto rpm_disable;
+ }
+
/* Init optional bus recovery function */
ret = lpi2c_imx_init_recovery_info(lpi2c_imx, pdev);
/* Give it another chance if pinctrl used is not ready yet */
if (ret == -EPROBE_DEFER)
- goto rpm_disable;
+ goto free_irq;
/* Init DMA */
ret = lpi2c_dma_init(&pdev->dev, phy_addr);
if (ret) {
if (ret == -EPROBE_DEFER)
- goto rpm_disable;
+ goto free_irq;
dev_info(&pdev->dev, "use pio mode\n");
}
ret = i2c_add_adapter(&lpi2c_imx->adapter);
if (ret)
- goto rpm_disable;
+ goto free_irq;
pm_runtime_put_autosuspend(&pdev->dev);
@@ -1574,10 +1589,17 @@ static int lpi2c_imx_probe(struct platform_device *pdev)
return 0;
+free_irq:
+ devm_free_irq(&pdev->dev, lpi2c_imx->irq, lpi2c_imx);
+
rpm_disable:
pm_runtime_dont_use_autosuspend(&pdev->dev);
- pm_runtime_put_sync(&pdev->dev);
pm_runtime_disable(&pdev->dev);
+ pm_runtime_set_suspended(&pdev->dev);
+ pm_runtime_put_noidle(&pdev->dev);
+
+clk_disable:
+ clk_bulk_disable_unprepare(lpi2c_imx->num_clks, lpi2c_imx->clks);
return ret;
}
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v4 4/5] KVM: arm64: Fix bounds checking in do_ffa_mem_reclaim()
From: Mostafa Saleh @ 2026-05-21 10:30 UTC (permalink / raw)
To: Marc Zyngier
Cc: op-tee, linux-kernel, kvmarm, linux-arm-kernel, oupton,
joey.gouly, suzuki.poulose, catalin.marinas, jens.wiklander,
sumit.garg, sebastianene, vdonnefort, sudeep.holla
In-Reply-To: <86ldddw4ht.wl-maz@kernel.org>
Hi Marc,
On Thu, May 21, 2026 at 09:28:46AM +0100, Marc Zyngier wrote:
> On Wed, 20 May 2026 21:49:47 +0100,
> Mostafa Saleh <smostafa@google.com> wrote:
> >
> > Sashiko (locally) reports out of bound write possiblity if SPMD
> > returns an invalid data.
> >
> > While SPMD is considered trusted, pKVM does some basic checks,
> > for offset to be less than or equal len.
> >
> > However, that is incorrect as even if the offset is smaller than
> > len pKVM can still access out of bound memory in the next
> > ffa_host_unshare_ranges().
> >
> > Split this check into 2:
> > 1- Check that the fixed portion of the descriptor fits.
> > 2- After getting reg, check the variable array size addr_range_cnt
> > fits.
> >
> > Signed-off-by: Mostafa Saleh <smostafa@google.com>
> > ---
> > arch/arm64/kvm/hyp/nvhe/ffa.c | 7 ++++++-
> > 1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> > index 1af722771178..e6aa2bfa63b1 100644
> > --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> > +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
> > @@ -607,7 +607,7 @@ static void do_ffa_mem_reclaim(struct arm_smccc_1_2_regs *res,
> > * check that we end up with something that doesn't look _completely_
> > * bogus.
> > */
> > - if (WARN_ON(offset > len ||
> > + if (WARN_ON(offset + CONSTITUENTS_OFFSET(0) > len ||
> > fraglen > KVM_FFA_MBOX_NR_PAGES * PAGE_SIZE)) {
>
> Do you really want to keep this a WARN_ON(), given that this results
> in a panic in most pKVM configurations?
Which kind of configuration will that check fail on?
Does that mean at the moment pKVM does out-of-bound access for
the header?
Thanks,
Mostafa
>
> Thanks,
>
> M.
>
> --
> Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v14 02/44] kvm: arm64: Avoid including linux/kvm_host.h in kvm_pgtable.h
From: Marc Zyngier @ 2026-05-21 10:26 UTC (permalink / raw)
To: Steven Price
Cc: kvm, kvmarm, Catalin Marinas, Will Deacon, James Morse,
Oliver Upton, Suzuki K Poulose, Zenghui Yu, linux-arm-kernel,
linux-kernel, Joey Gouly, Alexandru Elisei, Christoffer Dall,
Fuad Tabba, linux-coco, Ganapatrao Kulkarni, Gavin Shan,
Shanker Donthineni, Alper Gun, Aneesh Kumar K . V, Emi Kisanuki,
Vishal Annapurve, WeiLin.Chang, Lorenzo.Pieralisi2
In-Reply-To: <20260513131757.116630-3-steven.price@arm.com>
On Wed, 13 May 2026 14:17:10 +0100,
Steven Price <steven.price@arm.com> wrote:
>
> To avoid future include cycles, drop the linux/kvm_host.h include in
> kvm_pgtable.h and include two _types.h headers for the types that are
> actually used. Additionally provide a forward declaration for struct
> kvm_s2_mmu as it's only used as a pointer in this file.
>
> Both pgtable.c and kvm_pkvm.h relied on the indirect inclusion of
> kvm_host.h, so make that explicit.
>
> Signed-off-by: Steven Price <steven.price@arm.com>
> ---
> New patch in v13
> ---
> arch/arm64/include/asm/kvm_pgtable.h | 5 ++++-
> arch/arm64/include/asm/kvm_pkvm.h | 2 +-
> arch/arm64/kvm/hyp/pgtable.c | 1 +
> 3 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/include/asm/kvm_pgtable.h b/arch/arm64/include/asm/kvm_pgtable.h
> index 41a8687938eb..e4770ce2ccf6 100644
> --- a/arch/arm64/include/asm/kvm_pgtable.h
> +++ b/arch/arm64/include/asm/kvm_pgtable.h
> @@ -8,9 +8,12 @@
> #define __ARM64_KVM_PGTABLE_H__
>
> #include <linux/bits.h>
> -#include <linux/kvm_host.h>
> +#include <linux/kvm_types.h>
> +#include <linux/rbtree_types.h>
I'm surprised by this. Where is the rbtree_type.h requirement coming
from?
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* [PATCH v2 1/3] KVM: arm64: Reset page order in pKVM hyp_pool_init
From: Vincent Donnefort @ 2026-05-21 10:21 UTC (permalink / raw)
To: maz, oliver.upton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will
Cc: linux-arm-kernel, kvmarm, kernel-team, qperret, tabba,
Vincent Donnefort, Sashiko
In-Reply-To: <20260521102149.804874-1-vdonnefort@google.com>
When a VM fails to initialise after its stage-2 hyp_pool has been
initialised, that stage-2 must be torn down entirely. This requires
resetting both the refcount and the order of its pages back to 0.
Currently, reclaim_pgtable_pages() implicitly resets the page order by
allocating the entire pool with order-0 granularity. However, in the VM
initialisation error path, the addresses of the donated memory (the PGD)
are already known, making it unnecessary to iterate over all pages in
the pool.
Since the vmemmap page order is a hyp_pool-specific field, leaving a
non-zero order on hyp_pool destruction is harmless until another pool
attempts to admit the page. Instead of resetting this field during
destruction, reset it during pool initialization in hyp_pool_init().
Note that pages added to the pool outside of the initial pool range
(e.g., via guest_s2_zalloc_page()) must still have their order managed
manually.
While at it, add a WARN_ON() in the hyp_pool attach path to catch
unexpected page orders that exceed the pool's max_order.
Fixes: 256b4668cd89 ("KVM: arm64: Introduce separate hypercalls for pKVM VM reservation and initialization")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
diff --git a/arch/arm64/kvm/hyp/nvhe/mem_protect.c b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
index 25f04629014e..89eb20d4fee4 100644
--- a/arch/arm64/kvm/hyp/nvhe/mem_protect.c
+++ b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
@@ -322,7 +322,6 @@ void reclaim_pgtable_pages(struct pkvm_hyp_vm *vm, struct kvm_hyp_memcache *mc)
while (addr) {
page = hyp_virt_to_page(addr);
page->refcount = 0;
- page->order = 0;
push_hyp_memcache(mc, addr, hyp_virt_to_phys);
WARN_ON(__pkvm_hyp_donate_host(hyp_virt_to_pfn(addr), 1));
addr = hyp_alloc_pages(&vm->pool, 0);
diff --git a/arch/arm64/kvm/hyp/nvhe/page_alloc.c b/arch/arm64/kvm/hyp/nvhe/page_alloc.c
index a1eb27a1a747..c3b3dc5a8ea7 100644
--- a/arch/arm64/kvm/hyp/nvhe/page_alloc.c
+++ b/arch/arm64/kvm/hyp/nvhe/page_alloc.c
@@ -97,6 +97,8 @@ static void __hyp_attach_page(struct hyp_pool *pool,
u8 order = p->order;
struct hyp_page *buddy;
+ WARN_ON(p->order > pool->max_order);
+
memset(hyp_page_to_virt(p), 0, PAGE_SIZE << p->order);
/* Skip coalescing for 'external' pages being freed into the pool. */
@@ -237,8 +239,10 @@ int hyp_pool_init(struct hyp_pool *pool, u64 pfn, unsigned int nr_pages,
/* Init the vmemmap portion */
p = hyp_phys_to_page(phys);
- for (i = 0; i < nr_pages; i++)
+ for (i = 0; i < nr_pages; i++) {
hyp_set_page_refcounted(&p[i]);
+ p[i].order = 0;
+ }
/* Attach the unused pages to the buddy tree */
for (i = reserved_pages; i < nr_pages; i++)
--
2.54.0.746.g67dd491aae-goog
^ permalink raw reply related
* [PATCH v2 3/3] KVM: arm64: Add fail-safe for refcounted pages in __pkvm_hyp_donate_host
From: Vincent Donnefort @ 2026-05-21 10:21 UTC (permalink / raw)
To: maz, oliver.upton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will
Cc: linux-arm-kernel, kvmarm, kernel-team, qperret, tabba,
Vincent Donnefort
In-Reply-To: <20260521102149.804874-1-vdonnefort@google.com>
A previous bug in __pkvm_init_vm error path showed that the hypervisor
could leak refcounted pages, (i.e. losing access to a page while its
refcount is still elevated). This poses a threat to the pKVM state
machine.
Address this by introducing a fail-safe in n __pkvm_hyp_donate_host.
Transitions are not a hot path so added security is worth the extra
check.
Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
diff --git a/arch/arm64/kvm/hyp/nvhe/mem_protect.c b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
index 42b0b648f32f..bb97d05b9b25 100644
--- a/arch/arm64/kvm/hyp/nvhe/mem_protect.c
+++ b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
@@ -855,6 +855,16 @@ static int __hyp_check_page_state_range(phys_addr_t phys, u64 size, enum pkvm_pa
return 0;
}
+static int __hyp_check_page_count_range(phys_addr_t phys, u64 size)
+{
+ for_each_hyp_page(page, phys, size) {
+ if (page->refcount)
+ return -EBUSY;
+ }
+
+ return 0;
+}
+
static bool guest_pte_is_poisoned(kvm_pte_t pte)
{
if (kvm_pte_valid(pte))
@@ -1053,7 +1063,6 @@ int __pkvm_guest_unshare_host(struct pkvm_hyp_vcpu *vcpu, u64 gfn)
int __pkvm_host_unshare_hyp(u64 pfn)
{
u64 phys = hyp_pfn_to_phys(pfn);
- u64 virt = (u64)__hyp_va(phys);
u64 size = PAGE_SIZE;
int ret;
@@ -1066,10 +1075,9 @@ int __pkvm_host_unshare_hyp(u64 pfn)
ret = __hyp_check_page_state_range(phys, size, PKVM_PAGE_SHARED_BORROWED);
if (ret)
goto unlock;
- if (hyp_page_count((void *)virt)) {
- ret = -EBUSY;
+ ret = __hyp_check_page_count_range(phys, size);
+ if (ret)
goto unlock;
- }
__hyp_set_page_state_range(phys, size, PKVM_NOPAGE);
WARN_ON(__host_set_page_state_range(phys, size, PKVM_PAGE_OWNED));
@@ -1132,6 +1140,10 @@ int __pkvm_hyp_donate_host(u64 pfn, u64 nr_pages)
if (ret)
goto unlock;
+ ret = __hyp_check_page_count_range(phys, size);
+ if (ret)
+ goto unlock;
+
__hyp_set_page_state_range(phys, size, PKVM_NOPAGE);
WARN_ON(kvm_pgtable_hyp_unmap(&pkvm_pgtable, virt, size) != size);
WARN_ON(host_stage2_set_owner_locked(phys, size, PKVM_ID_HOST));
--
2.54.0.746.g67dd491aae-goog
^ permalink raw reply related
* [PATCH v2 2/3] KVM: arm64: Fix __pkvm_init_vm error path
From: Vincent Donnefort @ 2026-05-21 10:21 UTC (permalink / raw)
To: maz, oliver.upton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will
Cc: linux-arm-kernel, kvmarm, kernel-team, qperret, tabba,
Vincent Donnefort, Sashiko
In-Reply-To: <20260521102149.804874-1-vdonnefort@google.com>
In the unlikely case where insert_vm_table_entry fails, __pkvm_init_vm
release the memory donated by the host for the PGD, but as the stage-2
is still set-up the hypervisor keeps a refcount on those pages,
effectively leaking the references.
Fix the rollback with the newly added kvm_guest_destroy_stage2().
Fixes: 256b4668cd89 ("KVM: arm64: Introduce separate hypercalls for pKVM VM reservation and initialization")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
diff --git a/arch/arm64/kvm/hyp/include/nvhe/mem_protect.h b/arch/arm64/kvm/hyp/include/nvhe/mem_protect.h
index 3cbfae0e3dda..4f2b871199cb 100644
--- a/arch/arm64/kvm/hyp/include/nvhe/mem_protect.h
+++ b/arch/arm64/kvm/hyp/include/nvhe/mem_protect.h
@@ -56,6 +56,7 @@ int host_stage2_idmap_locked(phys_addr_t addr, u64 size, enum kvm_pgtable_prot p
int host_stage2_set_owner_locked(phys_addr_t addr, u64 size, u8 owner_id);
int kvm_host_prepare_stage2(void *pgt_pool_base);
int kvm_guest_prepare_stage2(struct pkvm_hyp_vm *vm, void *pgd);
+void kvm_guest_destroy_stage2(struct pkvm_hyp_vm *vm);
void handle_host_mem_abort(struct kvm_cpu_context *host_ctxt);
int hyp_pin_shared_mem(void *from, void *to);
diff --git a/arch/arm64/kvm/hyp/nvhe/mem_protect.c b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
index 89eb20d4fee4..42b0b648f32f 100644
--- a/arch/arm64/kvm/hyp/nvhe/mem_protect.c
+++ b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
@@ -306,16 +306,21 @@ int kvm_guest_prepare_stage2(struct pkvm_hyp_vm *vm, void *pgd)
return 0;
}
+void kvm_guest_destroy_stage2(struct pkvm_hyp_vm *vm)
+{
+ guest_lock_component(vm);
+ kvm_pgtable_stage2_destroy(&vm->pgt);
+ vm->kvm.arch.mmu.pgd_phys = 0ULL;
+ guest_unlock_component(vm);
+}
+
void reclaim_pgtable_pages(struct pkvm_hyp_vm *vm, struct kvm_hyp_memcache *mc)
{
struct hyp_page *page;
void *addr;
/* Dump all pgtable pages in the hyp_pool */
- guest_lock_component(vm);
- kvm_pgtable_stage2_destroy(&vm->pgt);
- vm->kvm.arch.mmu.pgd_phys = 0ULL;
- guest_unlock_component(vm);
+ kvm_guest_destroy_stage2(vm);
/* Drain the hyp_pool into the memcache */
addr = hyp_alloc_pages(&vm->pool, 0);
diff --git a/arch/arm64/kvm/hyp/nvhe/pkvm.c b/arch/arm64/kvm/hyp/nvhe/pkvm.c
index eb1c10120f9f..3b2c4fbc34d8 100644
--- a/arch/arm64/kvm/hyp/nvhe/pkvm.c
+++ b/arch/arm64/kvm/hyp/nvhe/pkvm.c
@@ -853,10 +853,12 @@ int __pkvm_init_vm(struct kvm *host_kvm, unsigned long vm_hva,
/* Must be called last since this publishes the VM. */
ret = insert_vm_table_entry(handle, hyp_vm);
if (ret)
- goto err_remove_mappings;
+ goto err_destroy_stage2;
return 0;
+err_destroy_stage2:
+ kvm_guest_destroy_stage2(hyp_vm);
err_remove_mappings:
unmap_donated_memory(hyp_vm, vm_size);
unmap_donated_memory(pgd, pgd_size);
--
2.54.0.746.g67dd491aae-goog
^ permalink raw reply related
* [PATCH v2 0/3] Fix __pkvm_init_vm error path
From: Vincent Donnefort @ 2026-05-21 10:21 UTC (permalink / raw)
To: maz, oliver.upton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will
Cc: linux-arm-kernel, kvmarm, kernel-team, qperret, tabba,
Vincent Donnefort
Sashiko reported a potential refcount leak in the unlikely case where
insert_vm_table_entry fails.
While at it, I have added a fail-safe to __pkvm_hyp_donate_host to ensure this
function doesn't allow leaking refcounted pages.
Changes since v2:
* Proactively init hyp_page order field in hyp_pool_init
v1 (https://lore.kernel.org/all/20260521081250.655226-1-vdonnefort@google.com/)
*** BLURB HERE ***
Vincent Donnefort (3):
KVM: arm64: Reset page order in pKVM hyp_pool_init
KVM: arm64: Fix __pkvm_init_vm error path
KVM: arm64: Add fail-safe for refcounted pages in
__pkvm_hyp_donate_host
arch/arm64/kvm/hyp/include/nvhe/mem_protect.h | 1 +
arch/arm64/kvm/hyp/nvhe/mem_protect.c | 34 ++++++++++++++-----
arch/arm64/kvm/hyp/nvhe/page_alloc.c | 6 +++-
arch/arm64/kvm/hyp/nvhe/pkvm.c | 4 ++-
4 files changed, 34 insertions(+), 11 deletions(-)
base-commit: 5200f5f493f79f14bbdc349e402a40dfb32f23c8
--
2.54.0.746.g67dd491aae-goog
^ permalink raw reply
* [soc:zx/soc] BUILD SUCCESS 220ae5d36dba278003d265aabd080ffa78553f5a
From: kernel test robot @ 2026-05-21 10:21 UTC (permalink / raw)
To: Stefan Dösinger ; +Cc: linux-arm-kernel, arm
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git zx/soc
branch HEAD: 220ae5d36dba278003d265aabd080ffa78553f5a ARM: zte: Add zx297520v3 platform support
elapsed time: 807m
configs tested: 201
configs skipped: 3
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-23
arc defconfig gcc-15.2.0
arc randconfig-001-20260521 gcc-8.5.0
arc randconfig-002-20260521 gcc-8.5.0
arm allnoconfig clang-23
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm defconfig gcc-15.2.0
arm footbridge_defconfig clang-17
arm randconfig-001-20260521 gcc-8.5.0
arm randconfig-002-20260521 gcc-8.5.0
arm randconfig-003-20260521 gcc-8.5.0
arm randconfig-004-20260521 gcc-8.5.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260521 gcc-8.5.0
arm64 randconfig-002-20260521 gcc-8.5.0
arm64 randconfig-003-20260521 gcc-8.5.0
arm64 randconfig-004-20260521 gcc-8.5.0
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260521 gcc-8.5.0
csky randconfig-002-20260521 gcc-8.5.0
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig clang-23
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260521 gcc-11.5.0
hexagon randconfig-002-20260521 gcc-11.5.0
i386 allmodconfig clang-20
i386 allmodconfig gcc-14
i386 allnoconfig gcc-14
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 allyesconfig gcc-14
i386 buildonly-randconfig-001-20260521 clang-20
i386 buildonly-randconfig-002-20260521 clang-20
i386 buildonly-randconfig-003-20260521 clang-20
i386 buildonly-randconfig-004-20260521 clang-20
i386 buildonly-randconfig-005-20260521 clang-20
i386 buildonly-randconfig-006-20260521 clang-20
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260521 clang-20
i386 randconfig-002-20260521 clang-20
i386 randconfig-003-20260521 clang-20
i386 randconfig-004-20260521 clang-20
i386 randconfig-005-20260521 clang-20
i386 randconfig-006-20260521 clang-20
i386 randconfig-007-20260521 clang-20
i386 randconfig-011-20260521 gcc-14
i386 randconfig-012-20260521 gcc-14
i386 randconfig-013-20260521 gcc-14
i386 randconfig-014-20260521 gcc-14
i386 randconfig-015-20260521 gcc-14
i386 randconfig-016-20260521 gcc-14
i386 randconfig-017-20260521 gcc-14
loongarch allmodconfig clang-23
loongarch allnoconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260521 gcc-11.5.0
loongarch randconfig-002-20260521 gcc-11.5.0
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k defconfig clang-19
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
mips cavium_octeon_defconfig gcc-15.2.0
mips rt305x_defconfig clang-23
nios2 10m50_defconfig gcc-11.5.0
nios2 allmodconfig clang-23
nios2 allnoconfig clang-23
nios2 defconfig clang-19
nios2 randconfig-001-20260521 gcc-11.5.0
nios2 randconfig-002-20260521 gcc-11.5.0
openrisc allmodconfig clang-23
openrisc allnoconfig clang-23
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allyesconfig clang-19
parisc allyesconfig gcc-15.2.0
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260521 gcc-12.5.0
parisc randconfig-002-20260521 gcc-12.5.0
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc mgcoge_defconfig clang-23
powerpc mpc837x_rdb_defconfig gcc-15.2.0
powerpc randconfig-001-20260521 gcc-12.5.0
powerpc randconfig-002-20260521 gcc-12.5.0
powerpc sam440ep_defconfig gcc-15.2.0
powerpc64 randconfig-001-20260521 gcc-12.5.0
powerpc64 randconfig-002-20260521 gcc-12.5.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001 gcc-15.2.0
riscv randconfig-001-20260521 gcc-15.2.0
riscv randconfig-002 gcc-15.2.0
riscv randconfig-002-20260521 gcc-15.2.0
s390 allmodconfig clang-18
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001 gcc-15.2.0
s390 randconfig-001-20260521 gcc-15.2.0
s390 randconfig-002 gcc-15.2.0
s390 randconfig-002-20260521 gcc-15.2.0
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allyesconfig clang-19
sh allyesconfig gcc-15.2.0
sh defconfig gcc-14
sh randconfig-001 gcc-15.2.0
sh randconfig-001-20260521 gcc-15.2.0
sh randconfig-002 gcc-15.2.0
sh randconfig-002-20260521 gcc-15.2.0
sparc allnoconfig clang-23
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260521 gcc-8.5.0
sparc randconfig-002-20260521 gcc-8.5.0
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260521 gcc-8.5.0
sparc64 randconfig-002-20260521 gcc-8.5.0
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260521 gcc-8.5.0
um randconfig-002-20260521 gcc-8.5.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260521 clang-20
x86_64 buildonly-randconfig-002-20260521 clang-20
x86_64 buildonly-randconfig-003-20260521 clang-20
x86_64 buildonly-randconfig-004-20260521 clang-20
x86_64 buildonly-randconfig-005-20260521 clang-20
x86_64 buildonly-randconfig-006-20260521 clang-20
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20260521 clang-20
x86_64 randconfig-002-20260521 clang-20
x86_64 randconfig-003-20260521 clang-20
x86_64 randconfig-004-20260521 clang-20
x86_64 randconfig-005-20260521 clang-20
x86_64 randconfig-006-20260521 clang-20
x86_64 randconfig-011 gcc-14
x86_64 randconfig-011-20260521 gcc-14
x86_64 randconfig-012 gcc-14
x86_64 randconfig-012-20260521 gcc-14
x86_64 randconfig-013 gcc-14
x86_64 randconfig-013-20260521 gcc-14
x86_64 randconfig-014 gcc-14
x86_64 randconfig-014-20260521 gcc-14
x86_64 randconfig-015 gcc-14
x86_64 randconfig-015-20260521 gcc-14
x86_64 randconfig-016 gcc-14
x86_64 randconfig-016-20260521 gcc-14
x86_64 randconfig-071 clang-20
x86_64 randconfig-071-20260521 clang-20
x86_64 randconfig-072 clang-20
x86_64 randconfig-072-20260521 clang-20
x86_64 randconfig-073 clang-20
x86_64 randconfig-073-20260521 clang-20
x86_64 randconfig-074 clang-20
x86_64 randconfig-074-20260521 clang-20
x86_64 randconfig-075 clang-20
x86_64 randconfig-075-20260521 clang-20
x86_64 randconfig-076 clang-20
x86_64 randconfig-076-20260521 clang-20
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-23
xtensa allyesconfig clang-23
xtensa randconfig-001-20260521 gcc-8.5.0
xtensa randconfig-002-20260521 gcc-8.5.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v14 01/44] kvm: arm64: Include kvm_emulate.h in kvm/arm_psci.h
From: Marc Zyngier @ 2026-05-21 10:19 UTC (permalink / raw)
To: Steven Price
Cc: kvm, kvmarm, Suzuki K Poulose, Catalin Marinas, Will Deacon,
James Morse, Oliver Upton, Zenghui Yu, linux-arm-kernel,
linux-kernel, Joey Gouly, Alexandru Elisei, Christoffer Dall,
Fuad Tabba, linux-coco, Ganapatrao Kulkarni, Gavin Shan,
Shanker Donthineni, Alper Gun, Aneesh Kumar K . V, Emi Kisanuki,
Vishal Annapurve, WeiLin.Chang, Lorenzo.Pieralisi2
In-Reply-To: <20260513131757.116630-2-steven.price@arm.com>
On Wed, 13 May 2026 14:17:09 +0100,
Steven Price <steven.price@arm.com> wrote:
>
> From: Suzuki K Poulose <suzuki.poulose@arm.com>
>
> Fix a potential build error (like below, when asm/kvm_emulate.h gets
> included after the kvm/arm_psci.h) by including the missing header file
> in kvm/arm_psci.h:
>
> ./include/kvm/arm_psci.h: In function ‘kvm_psci_version’:
> ./include/kvm/arm_psci.h:29:13: error: implicit declaration of function
> ‘vcpu_has_feature’; did you mean ‘cpu_have_feature’? [-Werror=implicit-function-declaration]
> 29 | if (vcpu_has_feature(vcpu, KVM_ARM_VCPU_PSCI_0_2)) {
> | ^~~~~~~~~~~~~~~~
> | cpu_have_feature
>
> Reviewed-by: Gavin Shan <gshan@redhat.com>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> Signed-off-by: Steven Price <steven.price@arm.com>
Unrelated to this patch, but really easy to fix: the standard prefix
for patches targeting KVM/arm64 is:
"KVM: arm64: [opt subsys:] Something starting with a capital letter"
where "opt subsys" could be "CCA" where applicable.
It'd be good to have some consistency.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v3 11/12] crypto: atmel-sha204a - fix heap info leak on I2C transfer failure
From: Krzysztof Kozlowski @ 2026-05-21 10:17 UTC (permalink / raw)
To: Lothar Rubusch, thorsten.blum, herbert, davem, nicolas.ferre,
alexandre.belloni, claudiu.beznea, tudor.ambarus, ardb, linusw
Cc: linux-crypto, linux-arm-kernel, linux-kernel
In-Reply-To: <20260520155703.23018-12-l.rubusch@gmail.com>
On 20/05/2026 17:57, Lothar Rubusch wrote:
> When a non-blocking read operation is requested, the driver dynamically
> allocates memory to track asynchronous transfer status. If the underlying
> I2C transmission fails, atmel_sha204a_rng_done() logs a rate-limited
> warning but incorrectly proceeds to cache the pointer to this uninitialized
> buffer inside the rng->priv data field anyway.
>
> On subsequent execution passes, atmel_sha204a_rng_read_nonblocking()
> detects the stale rng->priv value, skips executing a hardware data read,
> and copies up to 32 bytes of uninitialized kernel heap data from this
> garbage memory pool straight back into the system's hwrng data stream.
>
> Fix this information disclosure vector by immediately releasing the
> allocated asynchronous work data buffer and explicitly clearing the
> tracking pointer context whenever an I2C transaction returns a non-zero
> error status.
>
> Additionally, duplicate the tfm counter decrement within the new error
> path to ensure the reference counter is properly released before executing
> the early return, maintaining the driver's availability for subsequent
> requests.
>
> Fixes: da001fb651b0 ("crypto: atmel-i2c - add support for SHA204A random number generator")
This and other fixes should be first in the patchset. Or even separate
patchset.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3] i2c: imx: mark I2C adapter when hardware is powered down
From: Mukesh Savaliya @ 2026-05-21 10:16 UTC (permalink / raw)
To: Carlos Song (OSS), Mukesh Savaliya, o.rempel@pengutronix.de,
kernel@pengutronix.de, andi.shyti@kernel.org, Frank Li,
s.hauer@pengutronix.de, festevam@gmail.com, Carlos Song,
Bough Chen
Cc: linux-i2c@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
In-Reply-To: <AM0PR04MB68027798D1B07FD63AEC5F23E80E2@AM0PR04MB6802.eurprd04.prod.outlook.com>
Thanks Carlos !
On 5/21/2026 1:57 PM, Carlos Song (OSS) wrote:
>
>
>> -----Original Message-----
>> From: Mukesh Savaliya <mukesh.savaliya@oss.qualcomm.com>
>> Sent: Thursday, May 21, 2026 3:40 PM
>> To: Carlos Song (OSS) <carlos.song@oss.nxp.com>; o.rempel@pengutronix.de;
>> kernel@pengutronix.de; andi.shyti@kernel.org; Frank Li <frank.li@nxp.com>;
>> s.hauer@pengutronix.de; festevam@gmail.com; Carlos Song
>> <carlos.song@nxp.com>; Bough Chen <haibo.chen@nxp.com>
>> Cc: linux-i2c@vger.kernel.org; imx@lists.linux.dev;
>> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
>> stable@vger.kernel.org
>> Subject: Re: [PATCH v3] i2c: imx: mark I2C adapter when hardware is powered
>> down
>>
>> [You don't often get email from mukesh.savaliya@oss.qualcomm.com. Learn
>> why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>>
>> Hi Carlos,
>>
>> On 5/20/2026 3:45 PM, Carlos Song (OSS) wrote:
>>> From: Carlos Song <carlos.song@nxp.com>
>>>
>>> Mark the I2C adapter as suspended during system suspend to block
>>> further transfers, and resume it on system resume. This prevents
>>> potential hangs when the hardware is powered down but clients still attempt
>> I2C transfers.
>>>
what was the reason of this hang ? I was thinking you don't have
interrupts working when client requested transfer but adapter was
suspended. Please correct me if wrong.
And it would be good to mention the actual problem and why/how it occurred.
>> Code changes looks fine to me but have comment on commit log.
>>
>> It seems, you are adding support of _noirq() callbacks to allow transfers during
>> suspend/resume noirq phase of PM.
>>
>> Would it make sense if you can write "Replace system PM callbacks with noirq
>> PM callbacks" OR "Allow transfers during _noirq phase of the PM ops" instead of
>> "mark I2C adapter when hardware is powered down" ?
>>
>
> Hi,
>
> Thank you for your comments!
>
> But this patch is added is not for support noirq PM callback or transfer in noirq phase.
>
Okay, may be actual problem description can help me.
> In fact, this fix is to mark the I2C adapter as suspended during system noirq suspend to block further
> transfers, and resume it on system noirq resume. This is to prohibit I2C device calling the I2C controller
> after the system noirq suspend and before noirq resume, because at this time the I2C instance is powered
> off or the clock is disabled ... So I want to keep current commit. How do you think?
completely Makes sense. Please help add how this problem occurred and
why ? So the change/fix will be good to understand against it.
>
> Carlos Song
^ permalink raw reply
* Re: [PATCH v3 02/12] crypto: atmel-ecc - fix use after free situation
From: Krzysztof Kozlowski @ 2026-05-21 10:16 UTC (permalink / raw)
To: Lothar Rubusch, thorsten.blum, herbert, davem, nicolas.ferre,
alexandre.belloni, claudiu.beznea, tudor.ambarus, ardb, linusw
Cc: linux-crypto, linux-arm-kernel, linux-kernel
In-Reply-To: <20260520155703.23018-3-l.rubusch@gmail.com>
On 20/05/2026 17:56, Lothar Rubusch wrote:
> Fixes the very likely race condition, having multiple of such devices
> attached (identified by sashiko feedback).
>
> The Scenario:
> Thread A (Device 1 Probe): Successfully adds i2c_priv to the global
> list (Line 324). The lock is released.
> Thread B (An active crypto request): Concurrently calls
> atmel_ecc_i2c_client_alloc(). It scans the global list, sees
> Device 1, and assigns a crypto job to it.
> Thread A: Moves to line 332. crypto_register_kpp() fails (e.g., out of
> memory or name clash).
> Thread A: Enters the error path. It removes Device 1 from the list and
> frees the i2c_priv memory.
> Thread B: Is still actively trying to talk to the I2C hardware using
> the i2c_priv pointer it grabbed in Step 2. The memory is now
> gone. Result: Kernel crash (Use-After-Free).
>
> Fixes: 11105693fa05 ("crypto: atmel-ecc - introduce Microchip / Atmel ECC driver")
Please add Cc-stable
> Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
> ---
And fixes must be before any code refactorings, so your rename patch
should be after.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH net-next v4 1/6] dt-bindings: net: Add support for Airoha AN8801R GbE PHY
From: Rob Herring (Arm) @ 2026-05-21 10:15 UTC (permalink / raw)
To: Louis-Alexis Eyraud
Cc: linux-arm-kernel, Andrew Lunn, linux-mediatek, Russell King,
kevin-kw.huang, matthias.bgg, Andrew Lunn, Jakub Kicinski,
David S. Miller, devicetree, Krzysztof Kozlowski, Heiner Kallweit,
netdev, linux-kernel, AngeloGioacchino Del Regno, Paolo Abeni,
Conor Dooley, kernel, Eric Dumazet, macpaul.lin
In-Reply-To: <20260521-add-airoha-an8801-support-v4-1-1e4837d30ef4@collabora.com>
On Thu, 21 May 2026 10:21:54 +0200, Louis-Alexis Eyraud wrote:
> From: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
>
> Add a new binding to support the Airoha AN8801R Series Gigabit
> Ethernet PHY.
>
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
> Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
> ---
> .../devicetree/bindings/net/airoha,an8801.yaml | 116 +++++++++++++++++++++
> 1 file changed, 116 insertions(+)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/airoha,an8801.yaml: ^led@[0-2]$: Missing additionalProperties/unevaluatedProperties constraint
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260521-add-airoha-an8801-support-v4-1-1e4837d30ef4@collabora.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH v8 4/5] phy: move and rename Airoha PCIe PHY driver to dedicated directory
From: Lorenzo Bianconi @ 2026-05-21 10:13 UTC (permalink / raw)
To: Christian Marangi
Cc: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Vinod Koul, Neil Armstrong,
Felix Fietkau, linux-clk, devicetree, linux-kernel,
linux-arm-kernel, linux-phy
In-Reply-To: <20260520150912.11614-5-ansuelsmth@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 6921 bytes --]
> To keep the generic PHY directory tidy, move the PCIe PHY driver for
> Airoha AN7581 SoC to a dedicated directory.
>
> Also rename the driver and add the relevant SoC name to the .c and .h
> file in preparation for support of PCIe and USB PHY driver for Airoha
> AN7583 SoC that use a completely different implementation and
> calibration for PHYs and will have their own dedicated drivers.
>
> The rename permits to better identify the specific usage of the driver
> in the future once the airoha PHY directory will have multiple driver
> for multiple SoC.
>
> The config is changed from PHY_AIROHA_PCIE to PHY_AIROHA_AN7581_PCIE.
>
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> MAINTAINERS | 4 ++--
> drivers/phy/Kconfig | 11 +----------
> drivers/phy/Makefile | 4 ++--
> drivers/phy/airoha/Kconfig | 13 +++++++++++++
> drivers/phy/airoha/Makefile | 3 +++
> .../phy-an7581-pcie-regs.h} | 2 +-
> .../{phy-airoha-pcie.c => airoha/phy-an7581-pcie.c} | 6 +++---
> 7 files changed, 25 insertions(+), 18 deletions(-)
> create mode 100644 drivers/phy/airoha/Kconfig
> create mode 100644 drivers/phy/airoha/Makefile
> rename drivers/phy/{phy-airoha-pcie-regs.h => airoha/phy-an7581-pcie-regs.h} (99%)
> rename drivers/phy/{phy-airoha-pcie.c => airoha/phy-an7581-pcie.c} (99%)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 932044785a39..7bea8c620da8 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -759,8 +759,8 @@ M: Lorenzo Bianconi <lorenzo@kernel.org>
> L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
> S: Maintained
> F: Documentation/devicetree/bindings/phy/airoha,en7581-pcie-phy.yaml
> -F: drivers/phy/phy-airoha-pcie-regs.h
> -F: drivers/phy/phy-airoha-pcie.c
> +F: drivers/phy/airoha/phy-an7581-pcie-regs.h
> +F: drivers/phy/airoha/phy-an7581-pcie.c
>
> AIROHA SPI SNFI DRIVER
> M: Lorenzo Bianconi <lorenzo@kernel.org>
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 227b9a4c612e..f9cd765a3ccc 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -46,16 +46,6 @@ config GENERIC_PHY_MIPI_DPHY
> Provides a number of helpers a core functions for MIPI D-PHY
> drivers to us.
>
> -config PHY_AIROHA_PCIE
> - tristate "Airoha PCIe-PHY Driver"
> - depends on ARCH_AIROHA || COMPILE_TEST
> - depends on OF
> - select GENERIC_PHY
> - help
> - Say Y here to add support for Airoha PCIe PHY driver.
> - This driver create the basic PHY instance and provides initialize
> - callback for PCIe GEN3 port.
> -
> config PHY_CAN_TRANSCEIVER
> tristate "CAN transceiver PHY"
> select GENERIC_PHY
> @@ -133,6 +123,7 @@ config PHY_XGENE
> help
> This option enables support for APM X-Gene SoC multi-purpose PHY.
>
> +source "drivers/phy/airoha/Kconfig"
> source "drivers/phy/allwinner/Kconfig"
> source "drivers/phy/amlogic/Kconfig"
> source "drivers/phy/apple/Kconfig"
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index f49d83f00a3d..84062279fa63 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -7,7 +7,6 @@ obj-$(CONFIG_PHY_COMMON_PROPS) += phy-common-props.o
> obj-$(CONFIG_PHY_COMMON_PROPS_TEST) += phy-common-props-test.o
> obj-$(CONFIG_GENERIC_PHY) += phy-core.o
> obj-$(CONFIG_GENERIC_PHY_MIPI_DPHY) += phy-core-mipi-dphy.o
> -obj-$(CONFIG_PHY_AIROHA_PCIE) += phy-airoha-pcie.o
> obj-$(CONFIG_PHY_CAN_TRANSCEIVER) += phy-can-transceiver.o
> obj-$(CONFIG_PHY_GOOGLE_USB) += phy-google-usb.o
> obj-$(CONFIG_USB_LGM_PHY) += phy-lgm-usb.o
> @@ -17,7 +16,8 @@ obj-$(CONFIG_PHY_PISTACHIO_USB) += phy-pistachio-usb.o
> obj-$(CONFIG_PHY_SNPS_EUSB2) += phy-snps-eusb2.o
> obj-$(CONFIG_PHY_XGENE) += phy-xgene.o
>
> -obj-$(CONFIG_GENERIC_PHY) += allwinner/ \
> +obj-$(CONFIG_GENERIC_PHY) += airoha/ \
> + allwinner/ \
> amlogic/ \
> apple/ \
> broadcom/ \
> diff --git a/drivers/phy/airoha/Kconfig b/drivers/phy/airoha/Kconfig
> new file mode 100644
> index 000000000000..9a1b625a7701
> --- /dev/null
> +++ b/drivers/phy/airoha/Kconfig
> @@ -0,0 +1,13 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +#
> +# Phy drivers for Airoha devices
> +#
> +config PHY_AIROHA_AN7581_PCIE
> + tristate "Airoha AN7581 PCIe-PHY Driver"
> + depends on ARCH_AIROHA || COMPILE_TEST
> + depends on OF
> + select GENERIC_PHY
> + help
> + Say Y here to add support for Airoha AN7581 PCIe PHY driver.
> + This driver create the basic PHY instance and provides initialize
> + callback for PCIe GEN3 port.
> diff --git a/drivers/phy/airoha/Makefile b/drivers/phy/airoha/Makefile
> new file mode 100644
> index 000000000000..912f3e11a061
> --- /dev/null
> +++ b/drivers/phy/airoha/Makefile
> @@ -0,0 +1,3 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +obj-$(CONFIG_PHY_AIROHA_AN7581_PCIE) += phy-an7581-pcie.o
> diff --git a/drivers/phy/phy-airoha-pcie-regs.h b/drivers/phy/airoha/phy-an7581-pcie-regs.h
> similarity index 99%
> rename from drivers/phy/phy-airoha-pcie-regs.h
> rename to drivers/phy/airoha/phy-an7581-pcie-regs.h
> index 58572c793722..b938a7b468fe 100644
> --- a/drivers/phy/phy-airoha-pcie-regs.h
> +++ b/drivers/phy/airoha/phy-an7581-pcie-regs.h
> @@ -1,4 +1,4 @@
> -/* SPDX-License-Identifier: GPL-2.0-only */
> +// SPDX-License-Identifier: GPL-2.0-only
> /*
> * Copyright (c) 2024 AIROHA Inc
> * Author: Lorenzo Bianconi <lorenzo@kernel.org>
> diff --git a/drivers/phy/phy-airoha-pcie.c b/drivers/phy/airoha/phy-an7581-pcie.c
> similarity index 99%
> rename from drivers/phy/phy-airoha-pcie.c
> rename to drivers/phy/airoha/phy-an7581-pcie.c
> index 56e9ade8a9fd..81ddf0e7638b 100644
> --- a/drivers/phy/phy-airoha-pcie.c
> +++ b/drivers/phy/airoha/phy-an7581-pcie.c
> @@ -13,7 +13,7 @@
> #include <linux/platform_device.h>
> #include <linux/slab.h>
>
> -#include "phy-airoha-pcie-regs.h"
> +#include "phy-an7581-pcie-regs.h"
>
> #define LEQ_LEN_CTRL_MAX_VAL 7
> #define FREQ_LOCK_MAX_ATTEMPT 10
> @@ -1279,12 +1279,12 @@ MODULE_DEVICE_TABLE(of, airoha_pcie_phy_of_match);
> static struct platform_driver airoha_pcie_phy_driver = {
> .probe = airoha_pcie_phy_probe,
> .driver = {
> - .name = "airoha-pcie-phy",
> + .name = "airoha-an7581-pcie-phy",
> .of_match_table = airoha_pcie_phy_of_match,
> },
> };
> module_platform_driver(airoha_pcie_phy_driver);
>
> -MODULE_DESCRIPTION("Airoha PCIe PHY driver");
> +MODULE_DESCRIPTION("Airoha AN7581 PCIe PHY driver");
> MODULE_AUTHOR("Lorenzo Bianconi <lorenzo@kernel.org>");
> MODULE_LICENSE("GPL");
> --
> 2.53.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox