* Re: [PATCH v2 3/3] arm64: dts: imx8dxl: Add SolidRun SoM and HummingBoard
From: Andrew Lunn @ 2026-04-30 14:06 UTC (permalink / raw)
To: Josua Mayer
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Vladimir Oltean, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Yazan Shhady, Mikhail Anikin, Alexander Dahl,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
Vladimir Oltean, Conor Dooley, Krzysztof Kozlowski,
netdev@vger.kernel.org
In-Reply-To: <bd2e73c5-2e61-4ea1-ab3b-42a6573b31f8@solid-run.com>
> > Reviewed-by: Andrew Lunn <andrew@lunn.ch>
> >
> > Andrew
>
> Thanks!
>
> I don't know how to keep this partial review for v3, so I will send it without.
You can add my Reviewed-by. It is on record in the archive that it
only applies to a subset.
And in general, nobody can know the whole kernel, all the different
subsystems, and the details for all the DT bindings. So i would allow
some fuzziness for Reviewed-by: for a DT patch.
Interesting, an Acked-by: might actually be more appropriate.
Acked-by: does not necessarily indicate acknowledgement of the
entire patch. For example, if a patch affects multiple subsystems
and has an Acked-by: from one subsystem maintainer then this
usually indicates acknowledgement of just the part which affects
that maintainer’s code. Judgement should be used here.
So how about:
Acked-by: Andrew Lunn <andrew@lunn.ch>
and you can take your pick :-)
Andrew
^ permalink raw reply
* Re: [PATCH] remoteproc: imx: use device node name as processor name
From: Daniel Baluta @ 2026-04-30 14:17 UTC (permalink / raw)
To: Jiafei Pan, andersson, mathieu.poirier, Frank.Li, s.hauer, kernel,
festevam, linux-remoteproc, imx, linux-arm-kernel, linux-kernel,
peng.fan
Cc: daniel.baluta
In-Reply-To: <20260430061701.27270-1-Jiafei.Pan@nxp.com>
On 4/30/26 09:17, Jiafei Pan wrote:
> As currently there are maybe multiple remote processors, so change from
> using fixed name to using device node name as remote processor name in
> order to make them can be distinguished by through of name in sys
> filesystem.
>
> Signed-off-by: Jiafei Pan <Jiafei.Pan@nxp.com>
Please use git log --oneline drivers/remoteproc/imx_rproc.c and check the prefix
subject for commit messges related to imx_rproc files.
9b2451658afa9 remoteproc: imx_rproc: Use devm_add_action_or_reset() for scu cleanup
65af722aa86fc remoteproc: imx_rproc: Use devm_clk_get_enabled() and simplify cleanup
b0106defc0ff6 remoteproc: imx_rproc: Use devm_add_action_or_reset() for mailbox cleanup
Thanks,
Daniel.
^ permalink raw reply
* Re: [PATCH v4 3/3 omap] ARM: dts: omap2: add stlc4560 spi-wireless node
From: Bartosz Golaszewski @ 2026-04-30 14:19 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Arnd Bergmann, Aaro Koskinen, Andreas Kemnade,
Bartosz Golaszewski, Benoît Cousson, David S. Miller,
Dmitry Torokhov, Eric Dumazet, Felipe Balbi, Jakub Kicinski,
Johannes Berg, Kevin Hilman, Krzysztof Kozlowski, Linus Walleij,
Paolo Abeni, Rob Herring, Roger Quadros, Tony Lindgren,
linux-wireless, devicetree, linux-kernel, linux-arm-kernel,
linux-gpio, linux-omap, Krzysztof Kozlowski, netdev
In-Reply-To: <20260430081242.3686993-4-arnd@kernel.org>
On Thu, 30 Apr 2026 10:12:42 +0200, Arnd Bergmann <arnd@kernel.org> said:
> From: Arnd Bergmann <arnd@arndb.de>
>
> Converted from the platform_device creation in board-n8x0.c.
>
> Link: https://lore.kernel.org/all/20230314163201.955689-1-arnd@kernel.org/
> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* [PATCH v2] media: cedrus: clean up media device on probe failure
From: 박명훈 @ 2026-04-30 14:25 UTC (permalink / raw)
To: Maxime Ripard, Paul Kocialkowski, Mauro Carvalho Chehab,
Greg Kroah-Hartman, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland
Cc: Myeonghun Pak, linux-media, linux-staging, linux-arm-kernel,
linux-sunxi, linux-kernel, stable, Ijae Kim
From: Myeonghun Pak <mhun512@gmail.com>
cedrus_probe() initializes the media device before registering the video
device, the media controller, and the media device. If any of those later
steps fails, probe returns without calling media_device_cleanup(), so the
media device internals initialized by media_device_init() are left behind.
Add a media-device cleanup label to the probe unwind path and route video
registration failures through it as well.
Fixes: 50e761516f2b8c ("media: platform: Add Cedrus VPU decoder driver")
Cc: stable@vger.kernel.org
Co-developed-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
---
Changes in v2:
- Drop the now-unused err_m2m label.
drivers/staging/media/sunxi/cedrus/cedrus.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c b/drivers/staging/media/sunxi/cedrus/cedrus.c
index 6600245dff..2c25654640 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
@@ -507,7 +507,7 @@ static int cedrus_probe(struct platform_device *pdev)
ret = video_register_device(vfd, VFL_TYPE_VIDEO, 0);
if (ret) {
v4l2_err(&dev->v4l2_dev, "Failed to register video device\n");
- goto err_m2m;
+ goto err_media_cleanup;
}
v4l2_info(&dev->v4l2_dev,
@@ -533,6 +533,7 @@ static int cedrus_probe(struct platform_device *pdev)
v4l2_m2m_unregister_media_controller(dev->m2m_dev);
err_video:
video_unregister_device(&dev->vfd);
-err_m2m:
+err_media_cleanup:
+ media_device_cleanup(&dev->mdev);
v4l2_m2m_release(dev->m2m_dev);
err_v4l2:
--
2.50.1
^ permalink raw reply related
* [PATCH v3] arm64: Kconfig: drop unneeded dependency on OF_GPIO for ARCH_MVEBU
From: Bartosz Golaszewski @ 2026-04-30 14:32 UTC (permalink / raw)
To: Linus Walleij, Arnd Bergmann, Catalin Marinas, Will Deacon
Cc: linux-arm-kernel, linux-kernel, brgl, Bartosz Golaszewski
OF_GPIO is selected automatically on all OF systems. Any symbols it
controls also provide stubs so there's really no reason to select it
explicitly. ARCH_MVEBU already selects GPIOLIB, drop the redundant
OF_GPIO dependency.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
Changes in v3:
- Send the arm64 patch separately so that it can be picked up for v7.2
- Link to v2: https://patch.msgid.link/20260316-gpio-of-kconfig-v2-0-de2f4b00a0e4@oss.qualcomm.com
Changes in v2:
- Make gpio-watchdog depend on OF && GPIOLIB
- Drop picked up patches
- Link to v1: https://patch.msgid.link/20260304-gpio-of-kconfig-v1-0-d597916e79e7@oss.qualcomm.com
arch/arm64/Kconfig.platforms | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 72c812e76b0b1..dc995a7321174 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -243,7 +243,6 @@ config ARCH_MVEBU
select MVEBU_ODMI
select MVEBU_PIC
select MVEBU_SEI
- select OF_GPIO
select PINCTRL
select PINCTRL_ARMADA_37XX
select PINCTRL_ARMADA_AP806
--
2.47.3
^ permalink raw reply related
* Re: [PATCH] KVM: arm64: Handle permission faults with guest_memfd
From: Fuad Tabba @ 2026-04-30 14:48 UTC (permalink / raw)
To: Alexandru Elisei
Cc: maz, oupton, joey.gouly, suzuki.poulose, yuzenghui,
linux-arm-kernel, kvmarm, mark.rutland
In-Reply-To: <20260430132351.280766-1-alexandru.elisei@arm.com>
Hi Alexandru,
On Thu, 30 Apr 2026 at 14:24, Alexandru Elisei <alexandru.elisei@arm.com> wrote:
>
> gmem_abort() calls kvm_pgtable_stage2_map() to make changes to stage 2. It
> does this for both relaxing permissions on an existing mapping and to
> install a missing mapping.
>
> kvm_pgtable_stage2_map() doesn't make changes to stage 2 if there is an
> existing, valid entry and the new entry modifies only the permissions.
> This is checked in:
>
> kvm_pgtable_stage2_map()
> stage2_map_walk_leaf()
> stage2_map_walker_try_leaf()
> stage2_pte_needs_update()
>
> and if only the permissions differ, kvm_pgtable_stage2_map() returns
> -EAGAIN and KVM returns to the guest to replay the instruction. The
> assumption is that a concurrent fault on a different VCPU already mapped
> the faulting IPA, and replaying the instruction will either succeed, or
> cause a permission fault, which should be handled with
> kvm_pgtable_stage2_relax_perms().
>
> gmem_abort(), on a read or write fault on a system without DIC (instruction
> cache invalidation required for data to instruction coherence), installs a
> valid entry with read and write permissions, but without executable
> permissions. On an execution fault on the same page, gmem_abort() attempts
> to relax the permissions to allow execution, but calls
> kvm_pgtable_stage2_map() to change the existing, valid, entry.
> kvm_pgtable_stage2_map() returns -EAGAIN and KVM resumes execution from the
> faulting instruction, which leads to an infinite loop of permission faults
> on the same instruction.
>
> Allow the guest to make progress by using kvm_pgtable_stage2_relax_perms()
> to relax permissions.
>
> Fixes: a7b57e099592 ("KVM: arm64: Handle guest_memfd-backed guest page faults")
> Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
> ---
>
> Lightly tested on an Orion O6 board, without pkvm, and without nested
> virtualisation.
>
> Doesn't apply cleanly on top of a7b57e099592, I can send a patch for that if
> needed.
>
> arch/arm64/kvm/mmu.c | 24 +++++++++++++++++-------
> 1 file changed, 17 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index d089c107d9b7..dff58de7703b 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -1576,6 +1576,7 @@ struct kvm_s2_fault_desc {
> static int gmem_abort(const struct kvm_s2_fault_desc *s2fd)
> {
> bool write_fault, exec_fault;
> + bool perm_fault = kvm_vcpu_trap_is_permission_fault(s2fd->vcpu);
> enum kvm_pgtable_walk_flags flags = KVM_PGTABLE_WALK_SHARED;
> enum kvm_pgtable_prot prot = KVM_PGTABLE_PROT_R;
> struct kvm_pgtable *pgt = s2fd->vcpu->arch.hw_mmu->pgt;
> @@ -1587,10 +1588,12 @@ static int gmem_abort(const struct kvm_s2_fault_desc *s2fd)
> gfn_t gfn;
> int ret;
>
> - memcache = get_mmu_memcache(s2fd->vcpu);
> - ret = topup_mmu_memcache(s2fd->vcpu, memcache);
> - if (ret)
> - return ret;
> + if (!perm_fault) {
> + memcache = get_mmu_memcache(s2fd->vcpu);
> + ret = topup_mmu_memcache(s2fd->vcpu, memcache);
> + if (ret)
> + return ret;
> + }
memcache is now uninitialized when perm_fault, and only read in the
!perm_fault branch below. It's safe today, but initializing it to NULL
would silence any defensive analyzer and keep things robust against
future churn.
>
> if (s2fd->nested)
> gfn = kvm_s2_trans_output(s2fd->nested) >> PAGE_SHIFT;
> @@ -1631,9 +1634,16 @@ static int gmem_abort(const struct kvm_s2_fault_desc *s2fd)
> goto out_unlock;
> }
>
> - ret = KVM_PGT_FN(kvm_pgtable_stage2_map)(pgt, s2fd->fault_ipa, PAGE_SIZE,
> - __pfn_to_phys(pfn), prot,
> - memcache, flags);
> + if (perm_fault) {
> + /* Preserve the software bits from the existing table entry. */
> + prot &= ~KVM_NV_GUEST_MAP_SZ;
Can you please phrase it the same way as the existing comment in
user_mem_abort, as that phrasing more precisely describes the
rationale? i.e.,
/*
* Drop the SW bits in favour of those stored in the
* PTE, which will be preserved.
*/
> + ret = KVM_PGT_FN(kvm_pgtable_stage2_relax_perms(pgt, s2fd->fault_ipa,
> + prot, flags));
nit: args wrapped inside KVM_PGT_FN() is inconsistent with the rest of
the file (and with the else-branch immediately below). Every other
call site uses name-only inside the macro. Both expand the same way,
but it's better to stick to the convention.
> + } else {
> + ret = KVM_PGT_FN(kvm_pgtable_stage2_map)(pgt, s2fd->fault_ipa, PAGE_SIZE,
> + __pfn_to_phys(pfn), prot,
> + memcache, flags);
> + }
>
> out_unlock:
> kvm_release_faultin_page(kvm, page, !!ret, prot & KVM_PGTABLE_PROT_W);
With these fixed:
Reviewed-by: Fuad Tabba <tabba@google.com>
Cheers,
/fuad
>
> base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
> --
> 2.54.0
>
^ permalink raw reply
* Re: [PATCH v1 00/12] KVM Dirty-bit cleaning accelerator (HACDBS)
From: Marc Zyngier @ 2026-04-30 14:51 UTC (permalink / raw)
To: Leonardo Bras
Cc: Catalin Marinas, Will Deacon, Oliver Upton, Joey Gouly,
Suzuki K Poulose, Zenghui Yu, Rafael J. Wysocki, Len Brown,
Saket Dumbre, Paolo Bonzini, Chengwen Feng, Jonathan Cameron,
Kees Cook, Mikołaj Lenczewski, Ryan Roberts, Yang Shi,
Thomas Huth, mrigendrachaubey, Yeoreum Yun, Mark Brown,
Kevin Brodsky, James Clark, Ard Biesheuvel, Fuad Tabba,
Raghavendra Rao Ananta, Nathan Chancellor, Vincent Donnefort,
Lorenzo Pieralisi, Sascha Bischoff, Anshuman Khandual, Tian Zheng,
Wei-Lin Chang, linux-kernel, linux-arm-kernel, kvmarm, linux-acpi,
acpica-devel, kvm
In-Reply-To: <afNZQKIiKmHPD5My@devkitleo>
On Thu, 30 Apr 2026 14:29:37 +0100,
Leonardo Bras <leo.bras@arm.com> wrote:
>
> On Thu, Apr 30, 2026 at 02:14:22PM +0100, Marc Zyngier wrote:
> > On Thu, 30 Apr 2026 12:14:04 +0100,
> > Leonardo Bras <leo.bras@arm.com> wrote:
> >
> > > d - In __kvm_arch_dirty_log_clear() there is no way to predict how long
> > > should be the buffer, so I used 1x PAGE_SIZE, and when it gets full
> > > it's cleaned and reused. Should I let users configure that over a
> > > parameter, or is it overthinking?
> >
> > How long is a piece of string? We can't know that. A single page feels
> > very small in the 4kB case, and letting userspace define the size of
> > that buffer seems a likely requirement.
> >
>
> Ok, as a KVM parameter, or as a compile-time option?
Noticed the "userspace" word in there? It *has* to be controlled by
userspace one way or another. So not as a kernel parameter, and
*never* as a compile option.
> > > Kernel v7.0.0 + this patchset builds properly, passing both kvm selftests
> > > for dirty-bit tracking[2], on HW HACDBS enabled or disabled.
> >
> > I have absolutely no trust in these tests.
> >
> > Have you enabled a VMM to make use of these APIs, and actively
> > migrated running guests? That's the level of testing I'd like to see,
> > as the selftests are not what people run in production...
> >
>
> There is no enablement needed on VMM side.
> Yes, I have created a VM on upstream qemu with --enable-kvm and migrated it
> on the same host. (Inside a model)
>
> That was the first test I used, but then I found out that kvm selftests
> stress up multiple scenarios in an easier way.
Except when they don't. In my experience, the selftests are only there
to give the CI people the fuzzy feeling that they are doing something
useful. I have a collection of examples indicating that what these
things test is not representative of the bugs we have in KVM.
> Do you prefer me to test on any specific scenario, or does whatever qemu
> uses as a default parameter work well enough?
I want to hear about testing at a scale that make sense for production
VMs, including live migrating between hosts while under memory
pressure (swapping out).
I'm also interested in efficiency: how much better is HACDBS compared
to the current page faulting? Just having patches for a feature is not
enough to decide adoption of that feature. Show me the benefits in a
quantitative way (within the limits of the model, of course).
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH] firmware: smccc: Fix Arm SMCCC SOC_ID name call
From: Andre Przywara @ 2026-04-30 14:59 UTC (permalink / raw)
To: Sudeep Holla, Paul Benoit
Cc: Mark Rutland, Lorenzo Pieralisi, linux-arm-kernel, linux-kernel
In-Reply-To: <20250904-powerful-futuristic-tench-bcebd4@sudeepholla>
Hi Paul,
is there any update on this?
One more thought below ...
On 9/4/25 16:29, Sudeep Holla wrote:
> On Wed, Sep 03, 2025 at 05:38:44PM -0400, Paul Benoit wrote:
>> On 9/3/2025 10:49 AM, Sudeep Holla wrote:
>>> On Wed, Sep 03, 2025 at 03:23:58PM +0100, Sudeep Holla wrote:
>>>> On Tue, Sep 02, 2025 at 06:20:53PM +0100, Andre Przywara wrote:
>>>>> Commit 5f9c23abc477 ("firmware: smccc: Support optional Arm SMCCC SOC_ID
>>>>> name") introduced the SOC_ID name string call, which reports a human
>>>>> readable string describing the SoC, as returned by firmware.
>>>>> The SMCCC spec v1.6 describes this feature as AArch64 only, since we rely
>>>>> on 8 characters to be transmitted per register. Consequently the SMCCC
>>>>> call must use the AArch64 calling convention, which requires bit 30 of
>>>>> the FID to be set. The spec is a bit confusing here, since it mentions
>>>>> that in the parameter description ("2: SoC name (optionally implemented for
>>>>> SMC64 calls, ..."), but still prints the FID explicitly as 0x80000002.
>>>>> But as this FID is using the SMC32 calling convention (correct for the
>>>>> other two calls), it will not match what mainline TF-A is expecting, so
>>>>> any call would return NOT_SUPPORTED.
>>>>>
>>>>
>>>> Good catch and I must admit I completely missed it inspite of discussing
>>>> 32b vs 64b FID around the same time this was introduced.
>>>>
>>>>> Add a 64-bit version of the ARCH_SOC_ID FID macro, and use that for the
>>>>> SoC name version of the call.
>>>>>
>>>>> Fixes: 5f9c23abc477 ("firmware: smccc: Support optional Arm SMCCC SOC_ID name")
>>>>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>>>>> ---
>>>>> Hi,
>>>>>
>>>>> as somewhat expected, this now fails on an Ampere machine, which
>>>>> reported a string in /sys/devices/soc0/machine before, but is now missing
>>>>> this file.
>>>>> Any idea what's the best way to handle this? Let the code try the 32-bit
>>>>> FID, when the 64-bit one fails? Or handle this as some kind of erratum?
>>>>>
>>>>
>>>> Not sure about it yet. Erratum seems good option so that we can avoid
>>>> others getting it wrong too as they might just run the kernel and be happy
>>>> if the machine sysfs shows up as we decided to do fallback to 32b FID.
>>>>
>>>> I will start a discussion to get the spec updated and pushed out and see
>>>> how that goes.
>>>>
>>>> The change itself looks good and happy to get it merged once we know
>>>> what is the best approach(erratum vs fallback).
>>>>
>>>
>>> Looking at the SMCCC spec(DEN0028 v1.6 G Edition) ->
>>> Section 7.4.6 Implementation responsibilities
>>>
>>> If implemented, the firmware:
>>> ...
>>> • must not implement SoC_ID_type == 2 for SMC32.
>>> • can optionally implement SoC_ID_type == 2 for SMC64 (Function ID 0xC000_0002),
>>> ...
>>>
>>> So Ampere is not spec conformant here and hence I prefer to handle it as
>>> erratum. Hopefully we can use SOC_ID version and revision to keep the scope
>>> of erratum confined to smallest set of platforms.
>>>
>>> Paul,
>>>
>>> Thoughts ?
>>>
>>
>> Am I correctly understanding that, if the SMC64 SOC_ID Name call fails,
>> rather than an unconditional fallback to the SMC32 call, the SMC32
>> fallback would only be occurring under the proposed erratum?
>>
>
> Correct, if we have unconditional fallback to the SMC32 call, then there
> is a chance that this issue gets carried into newer Ampere systems as f/w
> gets copied as well as other vendors will also not notice the issue if
> they make similar mistake as the kernel silent makes a SMC32 call.
>
> We do need details of the SoC revision and version for which we need to
> apply this workaround/erratum.
So this looks more like a firmware erratum than a SoC specific one,
right? So I wonder if any SoC specific IDs are really appropriate here.
Is there some firmware version we can read via DMI or so to identify
affected systems?
Or shall we use a probably much easier SoC or even MIDR check anyway,
since it's just a fallback? As in: try smc64, if that fails and if it's
a core that ever shipped with that affected firmware, try smc32? I think
there is not much harm in trying those FIDs, so we just limit the scope
to Ampere cores - even though that's technically not the right method by
the book?
Cheers,
Andre
>
>> I brought this issue up at a weekly team meeting today, and I'll also be
>> communicating with the Ampere Computing firmware team regarding this
>> issue.
>
> Thanks!
>
^ permalink raw reply
* Re: [PATCH rc v4 1/5] iommu/arm-smmu-v3: Add arm_smmu_kdump_adopt_strtab() for kdump
From: Nicolin Chen @ 2026-04-30 15:24 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: will, robin.murphy, kevin.tian, joro, praan, kees, baolu.lu,
miko.lenczewski, smostafa, linux-arm-kernel, iommu, linux-kernel,
stable, jamien
In-Reply-To: <20260430115513.GG3225388@nvidia.com>
On Thu, Apr 30, 2026 at 08:55:13AM -0300, Jason Gunthorpe wrote:
> On Wed, Apr 29, 2026 at 02:37:50PM -0700, Nicolin Chen wrote:
> > On Wed, Apr 29, 2026 at 12:20:49AM -0700, Nicolin Chen wrote:
> >
> > > +static int arm_smmu_kdump_adopt_strtab_2lvl(struct arm_smmu_device *smmu,
> > > + u32 cfg_reg, dma_addr_t dma)
> > [...]
> > > + for (i = 0; i < num_l1_ents; i++) {
> > > + u64 l2ptr = le64_to_cpu(cfg->l2.l1tab[i].l2ptr);
> >
> > Sashiko pointed out a missing READ_ON here.
>
> ??
>
> There is no concurrency at this point?
You are right. I got confused. I was thinking of an RID-sharing
case where some race might happen and adding READ_ONCE could be
defensive.
A kdump kernel has a very limited use. So, this isn't necessary.
Thanks
Nicolin
^ permalink raw reply
* [PATCH 0/7] pinctrl: Fix types in .pin_config_group_get() callbacks
From: Geert Uytterhoeven @ 2026-04-30 15:33 UTC (permalink / raw)
To: Linus Walleij, Lorenzo Bianconi, Sean Wang, Paul Cercueil,
Tony Lindgren, Haojian Zhuang, Matthias Brugger,
AngeloGioacchino Del Regno, Lad Prabhakar
Cc: linux-gpio, linux-mediatek, linux-kernel, linux-mips,
linux-arm-kernel, linux-omap, linux-renesas-soc,
Geert Uytterhoeven
Hi all,
On 64-bit platforms, "unsigned long" is 64-bit. However, when checking
if all "unsigned long" configuration values passed to the
.pin_config_group_get() callback are equal, several drivers use a 32-bit
temporary. Fortunately this works, as currently all configuration
values fit in 32-bit.
This series makes the code cleaner and more future-proof by changing the
types of all temporaries to unsigned long.
I intend to queue patches 5 and 6 in renesas-pinctrl for v7.2.
Thanks for your comments!
Geert Uytterhoeven (7):
pinctrl: airoha: Fix type in .pin_config_group_get() callback
pinctrl: equilibrium: Fix type in .pin_config_group_get() callback
pinctrl: ingenic: Fix type in .pin_config_group_get() callback
pinctrl: mediatek: moore: Fix type in .pin_config_group_get() callback
pinctrl: renesas: rzg2l: Fix type in .pin_config_group_get() callback
pinctrl: renesas: rzv2m: Fix type in .pin_config_group_get() callback
pinctrl: single: Fix type in .pin_config_group_get() callback
drivers/pinctrl/mediatek/pinctrl-airoha.c | 2 +-
drivers/pinctrl/mediatek/pinctrl-moore.c | 3 ++-
drivers/pinctrl/pinctrl-equilibrium.c | 3 ++-
drivers/pinctrl/pinctrl-ingenic.c | 3 ++-
drivers/pinctrl/pinctrl-single.c | 3 ++-
drivers/pinctrl/renesas/pinctrl-rzg2l.c | 3 ++-
drivers/pinctrl/renesas/pinctrl-rzv2m.c | 3 ++-
7 files changed, 13 insertions(+), 7 deletions(-)
--
2.43.0
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH 1/7] pinctrl: airoha: Fix type in .pin_config_group_get() callback
From: Geert Uytterhoeven @ 2026-04-30 15:33 UTC (permalink / raw)
To: Linus Walleij, Lorenzo Bianconi, Sean Wang, Paul Cercueil,
Tony Lindgren, Haojian Zhuang, Matthias Brugger,
AngeloGioacchino Del Regno, Lad Prabhakar
Cc: linux-gpio, linux-mediatek, linux-kernel, linux-mips,
linux-arm-kernel, linux-omap, linux-renesas-soc,
Geert Uytterhoeven
In-Reply-To: <cover.1777562725.git.geert+renesas@glider.be>
On 64-bit platforms, "unsigned long" is 64-bit. Hence checking if all
"unsigned long" configuration values are equal should be done using an
"unsigned long" temporary.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
drivers/pinctrl/mediatek/pinctrl-airoha.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/mediatek/pinctrl-airoha.c b/drivers/pinctrl/mediatek/pinctrl-airoha.c
index 995ba6175c9504ba..e5a6a60fb3c660cb 100644
--- a/drivers/pinctrl/mediatek/pinctrl-airoha.c
+++ b/drivers/pinctrl/mediatek/pinctrl-airoha.c
@@ -2811,7 +2811,7 @@ static int airoha_pinconf_group_get(struct pinctrl_dev *pctrl_dev,
unsigned int group, unsigned long *config)
{
struct airoha_pinctrl *pinctrl = pinctrl_dev_get_drvdata(pctrl_dev);
- u32 cur_config = 0;
+ unsigned long cur_config = 0;
int i;
for (i = 0; i < pinctrl->grps[group].npins; i++) {
--
2.43.0
^ permalink raw reply related
* [PATCH 2/7] pinctrl: equilibrium: Fix type in .pin_config_group_get() callback
From: Geert Uytterhoeven @ 2026-04-30 15:33 UTC (permalink / raw)
To: Linus Walleij, Lorenzo Bianconi, Sean Wang, Paul Cercueil,
Tony Lindgren, Haojian Zhuang, Matthias Brugger,
AngeloGioacchino Del Regno, Lad Prabhakar
Cc: linux-gpio, linux-mediatek, linux-kernel, linux-mips,
linux-arm-kernel, linux-omap, linux-renesas-soc,
Geert Uytterhoeven
In-Reply-To: <cover.1777562725.git.geert+renesas@glider.be>
On 64-bit platforms, "unsigned long" is 64-bit. Hence checking if all
"unsigned long" configuration values are equal should be done using an
"unsigned long" temporary.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
drivers/pinctrl/pinctrl-equilibrium.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/pinctrl-equilibrium.c b/drivers/pinctrl/pinctrl-equilibrium.c
index ba1c867b7b891abb..349eb944b4ac880e 100644
--- a/drivers/pinctrl/pinctrl-equilibrium.c
+++ b/drivers/pinctrl/pinctrl-equilibrium.c
@@ -532,8 +532,9 @@ static int eqbr_pinconf_set(struct pinctrl_dev *pctldev, unsigned int pin,
static int eqbr_pinconf_group_get(struct pinctrl_dev *pctldev,
unsigned int group, unsigned long *config)
{
- unsigned int i, npins, old = 0;
const unsigned int *pins;
+ unsigned int i, npins;
+ unsigned long old = 0;
int ret;
ret = pinctrl_generic_get_group_pins(pctldev, group, &pins, &npins);
--
2.43.0
^ permalink raw reply related
* [PATCH 3/7] pinctrl: ingenic: Fix type in .pin_config_group_get() callback
From: Geert Uytterhoeven @ 2026-04-30 15:33 UTC (permalink / raw)
To: Linus Walleij, Lorenzo Bianconi, Sean Wang, Paul Cercueil,
Tony Lindgren, Haojian Zhuang, Matthias Brugger,
AngeloGioacchino Del Regno, Lad Prabhakar
Cc: linux-gpio, linux-mediatek, linux-kernel, linux-mips,
linux-arm-kernel, linux-omap, linux-renesas-soc,
Geert Uytterhoeven
In-Reply-To: <cover.1777562725.git.geert+renesas@glider.be>
On 64-bit platforms, "unsigned long" is 64-bit. Hence checking if all
"unsigned long" configuration values are equal should be done using an
"unsigned long" temporary.
While Ingenic is a 32-bit platform, it is still better to use the
correct type, to serve as an example.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
drivers/pinctrl/pinctrl-ingenic.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/pinctrl-ingenic.c b/drivers/pinctrl/pinctrl-ingenic.c
index c7f14546de0528de..29d7f4e54bc7b126 100644
--- a/drivers/pinctrl/pinctrl-ingenic.c
+++ b/drivers/pinctrl/pinctrl-ingenic.c
@@ -4334,7 +4334,8 @@ static int ingenic_pinconf_group_get(struct pinctrl_dev *pctldev,
unsigned int group, unsigned long *config)
{
const unsigned int *pins;
- unsigned int i, npins, old = 0;
+ unsigned int i, npins;
+ unsigned long old = 0;
int ret;
ret = pinctrl_generic_get_group_pins(pctldev, group, &pins, &npins);
--
2.43.0
^ permalink raw reply related
* [PATCH 4/7] pinctrl: mediatek: moore: Fix type in .pin_config_group_get() callback
From: Geert Uytterhoeven @ 2026-04-30 15:33 UTC (permalink / raw)
To: Linus Walleij, Lorenzo Bianconi, Sean Wang, Paul Cercueil,
Tony Lindgren, Haojian Zhuang, Matthias Brugger,
AngeloGioacchino Del Regno, Lad Prabhakar
Cc: linux-gpio, linux-mediatek, linux-kernel, linux-mips,
linux-arm-kernel, linux-omap, linux-renesas-soc,
Geert Uytterhoeven
In-Reply-To: <cover.1777562725.git.geert+renesas@glider.be>
On 64-bit platforms, "unsigned long" is 64-bit. Hence checking if all
"unsigned long" configuration values are equal should be done using an
"unsigned long" temporary.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
drivers/pinctrl/mediatek/pinctrl-moore.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/mediatek/pinctrl-moore.c b/drivers/pinctrl/mediatek/pinctrl-moore.c
index 071ba849e5322396..17e30f83dc1972c0 100644
--- a/drivers/pinctrl/mediatek/pinctrl-moore.c
+++ b/drivers/pinctrl/mediatek/pinctrl-moore.c
@@ -402,7 +402,8 @@ static int mtk_pinconf_group_get(struct pinctrl_dev *pctldev,
unsigned int group, unsigned long *config)
{
const unsigned int *pins;
- unsigned int i, npins, old = 0;
+ unsigned int i, npins;
+ unsigned long old = 0;
int ret;
ret = pinctrl_generic_get_group_pins(pctldev, group, &pins, &npins);
--
2.43.0
^ permalink raw reply related
* [PATCH 5/7] pinctrl: renesas: rzg2l: Fix type in .pin_config_group_get() callback
From: Geert Uytterhoeven @ 2026-04-30 15:33 UTC (permalink / raw)
To: Linus Walleij, Lorenzo Bianconi, Sean Wang, Paul Cercueil,
Tony Lindgren, Haojian Zhuang, Matthias Brugger,
AngeloGioacchino Del Regno, Lad Prabhakar
Cc: linux-gpio, linux-mediatek, linux-kernel, linux-mips,
linux-arm-kernel, linux-omap, linux-renesas-soc,
Geert Uytterhoeven
In-Reply-To: <cover.1777562725.git.geert+renesas@glider.be>
On 64-bit platforms, "unsigned long" is 64-bit. Hence checking if all
"unsigned long" configuration values are equal should be done using an
"unsigned long" temporary.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
drivers/pinctrl/renesas/pinctrl-rzg2l.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/renesas/pinctrl-rzg2l.c b/drivers/pinctrl/renesas/pinctrl-rzg2l.c
index bc2154b695149809..5b0f23af5a6cc9de 100644
--- a/drivers/pinctrl/renesas/pinctrl-rzg2l.c
+++ b/drivers/pinctrl/renesas/pinctrl-rzg2l.c
@@ -1647,8 +1647,9 @@ static int rzg2l_pinctrl_pinconf_group_get(struct pinctrl_dev *pctldev,
unsigned int group,
unsigned long *config)
{
+ unsigned long prev_config = 0;
const unsigned int *pins;
- unsigned int i, npins, prev_config = 0;
+ unsigned int i, npins;
int ret;
ret = pinctrl_generic_get_group_pins(pctldev, group, &pins, &npins);
--
2.43.0
^ permalink raw reply related
* [PATCH 7/7] pinctrl: single: Fix type in .pin_config_group_get() callback
From: Geert Uytterhoeven @ 2026-04-30 15:33 UTC (permalink / raw)
To: Linus Walleij, Lorenzo Bianconi, Sean Wang, Paul Cercueil,
Tony Lindgren, Haojian Zhuang, Matthias Brugger,
AngeloGioacchino Del Regno, Lad Prabhakar
Cc: linux-gpio, linux-mediatek, linux-kernel, linux-mips,
linux-arm-kernel, linux-omap, linux-renesas-soc,
Geert Uytterhoeven
In-Reply-To: <cover.1777562725.git.geert+renesas@glider.be>
On 64-bit platforms, "unsigned long" is 64-bit. Hence checking if all
"unsigned long" configuration values are equal should be done using an
"unsigned long" temporary.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
drivers/pinctrl/pinctrl-single.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index 7e022a46ee422dc1..4d5f85b7e6bbe2b0 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -619,8 +619,9 @@ static int pcs_pinconf_set(struct pinctrl_dev *pctldev,
static int pcs_pinconf_group_get(struct pinctrl_dev *pctldev,
unsigned group, unsigned long *config)
{
+ unsigned long old = 0;
const unsigned *pins;
- unsigned npins, old = 0;
+ unsigned npins;
int i, ret;
ret = pinctrl_generic_get_group_pins(pctldev, group, &pins, &npins);
--
2.43.0
^ permalink raw reply related
* [PATCH 6/7] pinctrl: renesas: rzv2m: Fix type in .pin_config_group_get() callback
From: Geert Uytterhoeven @ 2026-04-30 15:33 UTC (permalink / raw)
To: Linus Walleij, Lorenzo Bianconi, Sean Wang, Paul Cercueil,
Tony Lindgren, Haojian Zhuang, Matthias Brugger,
AngeloGioacchino Del Regno, Lad Prabhakar
Cc: linux-gpio, linux-mediatek, linux-kernel, linux-mips,
linux-arm-kernel, linux-omap, linux-renesas-soc,
Geert Uytterhoeven
In-Reply-To: <cover.1777562725.git.geert+renesas@glider.be>
On 64-bit platforms, "unsigned long" is 64-bit. Hence checking if all
"unsigned long" configuration values are equal should be done using an
"unsigned long" temporary.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
drivers/pinctrl/renesas/pinctrl-rzv2m.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/renesas/pinctrl-rzv2m.c b/drivers/pinctrl/renesas/pinctrl-rzv2m.c
index 495e7f5d41280dc9..827b3e91a6cc2622 100644
--- a/drivers/pinctrl/renesas/pinctrl-rzv2m.c
+++ b/drivers/pinctrl/renesas/pinctrl-rzv2m.c
@@ -695,8 +695,9 @@ static int rzv2m_pinctrl_pinconf_group_get(struct pinctrl_dev *pctldev,
unsigned int group,
unsigned long *config)
{
+ unsigned long prev_config = 0;
const unsigned int *pins;
- unsigned int i, npins, prev_config = 0;
+ unsigned int i, npins;
int ret;
ret = pinctrl_generic_get_group_pins(pctldev, group, &pins, &npins);
--
2.43.0
^ permalink raw reply related
* [PATCH 0/3] irqchip/gic-v5: Tidy up LPI allocation
From: Sascha Bischoff @ 2026-04-30 15:33 UTC (permalink / raw)
To: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: nd, Lorenzo Pieralisi, Marc Zyngier, Thomas Gleixner
LPIs are owned by the LPI domain, so allocating and freeing them from
the ITS MSI and IPI domains was always a bit backwards. Those domains
should only ask their parent for interrupts, and never need to
know how the parent picks or releases the underlying LPIs (or do it on
behalf of said parent, as was the case).
This series moves LPI allocation into the LPI domain itself and
removes the exported wrappers that allowed LPI allocation from elsewhere.
With that done, the LPI domain can also be slightly reworked to
support allocating and freeing more than one LPI at a time. This
rework is extended to the IPI allocation, too. The last patch makes
the ITS MSI domain request its parent interrupts as a single range,
matching the IPI cleanup from the previous patch.
As a side effect of these changes, the IPI path now unwinds earlier
parent allocations correctly if a later allocation fails.
Thanks,
Sascha
Sascha Bischoff (3):
irqchip/gic-v5: Move LPI alloc/free into LPI domain
irqchip/gic-v5: Allow for nr_irqs > 1 for LPI alloc and teardown
irqchip/gic-v5: Allocate ITS parent LPIs as a range
drivers/irqchip/irq-gic-v5-its.c | 34 +++--------
drivers/irqchip/irq-gic-v5.c | 90 ++++++++++++++++--------------
include/linux/irqchip/arm-gic-v5.h | 3 -
3 files changed, 56 insertions(+), 71 deletions(-)
--
2.34.1
^ permalink raw reply
* [PATCH 1/3] irqchip/gic-v5: Move LPI alloc/free into LPI domain
From: Sascha Bischoff @ 2026-04-30 15:34 UTC (permalink / raw)
To: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: nd, Lorenzo Pieralisi, Marc Zyngier, Thomas Gleixner
In-Reply-To: <20260430153352.3654325-1-sascha.bischoff@arm.com>
Rather than relying on the domains built on top of GICv5's LPI domain
to manage LPI allocations and frees, move that into the LPI domain
itself. This, rightly, ensures that domains other than the LPI itself
have no knowledge of LPI allocations themselves. This not only cleans
up the LPI domain itself, but also the IPI and ITS MSI domains which
build upon it.
While we're at it, drop the helpers wrapping the helpers -
gicv5_alloc_lpi() and gicv5_free_lpi() - and directly use alloc_lpi()
and release_lpi() instead.
Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com>
---
drivers/irqchip/irq-gic-v5-its.c | 14 ++------
drivers/irqchip/irq-gic-v5.c | 54 +++++++++++++++---------------
include/linux/irqchip/arm-gic-v5.h | 3 --
3 files changed, 29 insertions(+), 42 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v5-its.c b/drivers/irqchip/irq-gic-v5-its.c
index 36a8d1368f0e4..36d03f82ef684 100644
--- a/drivers/irqchip/irq-gic-v5-its.c
+++ b/drivers/irqchip/irq-gic-v5-its.c
@@ -929,8 +929,8 @@ static void gicv5_its_free_eventid(struct gicv5_its_dev *its_dev, u32 event_id_b
static int gicv5_its_irq_domain_alloc(struct irq_domain *domain, unsigned int virq,
unsigned int nr_irqs, void *arg)
{
- u32 device_id, event_id_base, lpi;
struct gicv5_its_dev *its_dev;
+ u32 device_id, event_id_base;
msi_alloc_info_t *info = arg;
irq_hw_number_t hwirq;
struct irq_data *irqd;
@@ -949,16 +949,8 @@ static int gicv5_its_irq_domain_alloc(struct irq_domain *domain, unsigned int vi
device_id = its_dev->device_id;
for (i = 0; i < nr_irqs; i++) {
- ret = gicv5_alloc_lpi();
- if (ret < 0) {
- pr_debug("Failed to find free LPI!\n");
- goto out_free_irqs;
- }
- lpi = ret;
-
- ret = irq_domain_alloc_irqs_parent(domain, virq + i, 1, &lpi);
+ ret = irq_domain_alloc_irqs_parent(domain, virq + i, 1, NULL);
if (ret) {
- gicv5_free_lpi(lpi);
goto out_free_irqs;
}
@@ -983,7 +975,6 @@ static int gicv5_its_irq_domain_alloc(struct irq_domain *domain, unsigned int vi
out_free_irqs:
while (--i >= 0) {
irqd = irq_domain_get_irq_data(domain, virq + i);
- gicv5_free_lpi(irqd->parent_data->hwirq);
irq_domain_reset_irq_data(irqd);
irq_domain_free_irqs_parent(domain, virq + i, 1);
}
@@ -1013,7 +1004,6 @@ static void gicv5_its_irq_domain_free(struct irq_domain *domain, unsigned int vi
for (i = 0; i < nr_irqs; i++) {
d = irq_domain_get_irq_data(domain, virq + i);
- gicv5_free_lpi(d->parent_data->hwirq);
irq_domain_reset_irq_data(d);
irq_domain_free_irqs_parent(domain, virq + i, 1);
}
diff --git a/drivers/irqchip/irq-gic-v5.c b/drivers/irqchip/irq-gic-v5.c
index 6b0903be8ebfd..a3c9eaa8ff486 100644
--- a/drivers/irqchip/irq-gic-v5.c
+++ b/drivers/irqchip/irq-gic-v5.c
@@ -59,16 +59,6 @@ static void release_lpi(u32 lpi)
ida_free(&lpi_ida, lpi);
}
-int gicv5_alloc_lpi(void)
-{
- return alloc_lpi();
-}
-
-void gicv5_free_lpi(u32 lpi)
-{
- release_lpi(lpi);
-}
-
static void gicv5_ppi_priority_init(void)
{
write_sysreg_s(REPEAT_BYTE(GICV5_IRQ_PRI_MI), SYS_ICC_PPI_PRIORITYR0_EL1);
@@ -806,18 +796,37 @@ static void gicv5_lpi_config_reset(struct irq_data *d)
gicv5_lpi_irq_write_pending_state(d, false);
}
+static void gicv5_irq_lpi_domain_free(struct irq_domain *domain, unsigned int virq,
+ unsigned int nr_irqs)
+{
+ struct irq_data *d;
+
+ if (WARN_ON_ONCE(nr_irqs != 1))
+ return;
+
+ d = irq_domain_get_irq_data(domain, virq);
+
+
+ release_lpi(d->hwirq);
+
+ irq_set_handler(virq, NULL);
+ irq_domain_reset_irq_data(d);
+}
+
static int gicv5_irq_lpi_domain_alloc(struct irq_domain *domain, unsigned int virq,
unsigned int nr_irqs, void *arg)
{
irq_hw_number_t hwirq;
struct irq_data *irqd;
- u32 *lpi = arg;
int ret;
if (WARN_ON_ONCE(nr_irqs != 1))
return -EINVAL;
- hwirq = *lpi;
+ ret = alloc_lpi();
+ if (ret < 0)
+ return ret;
+ hwirq = ret;
irqd = irq_domain_get_irq_data(domain, virq);
@@ -826,8 +835,10 @@ static int gicv5_irq_lpi_domain_alloc(struct irq_domain *domain, unsigned int vi
irqd_set_single_target(irqd);
ret = gicv5_irs_iste_alloc(hwirq);
- if (ret < 0)
+ if (ret < 0) {
+ release_lpi(hwirq);
return ret;
+ }
gicv5_hwirq_init(hwirq, GICV5_IRQ_PRI_MI, GICV5_HWIRQ_TYPE_LPI);
gicv5_lpi_config_reset(irqd);
@@ -837,7 +848,7 @@ static int gicv5_irq_lpi_domain_alloc(struct irq_domain *domain, unsigned int vi
static const struct irq_domain_ops gicv5_irq_lpi_domain_ops = {
.alloc = gicv5_irq_lpi_domain_alloc,
- .free = gicv5_irq_domain_free,
+ .free = gicv5_irq_lpi_domain_free,
};
void __init gicv5_init_lpi_domain(void)
@@ -859,21 +870,12 @@ static int gicv5_irq_ipi_domain_alloc(struct irq_domain *domain, unsigned int vi
{
struct irq_data *irqd;
int ret, i;
- u32 lpi;
for (i = 0; i < nr_irqs; i++) {
- ret = gicv5_alloc_lpi();
- if (ret < 0)
+ ret = irq_domain_alloc_irqs_parent(domain, virq + i, 1, NULL);
+ if (ret)
return ret;
- lpi = ret;
-
- ret = irq_domain_alloc_irqs_parent(domain, virq + i, 1, &lpi);
- if (ret) {
- gicv5_free_lpi(lpi);
- return ret;
- }
-
irqd = irq_domain_get_irq_data(domain, virq + i);
irq_domain_set_hwirq_and_chip(domain, virq + i, i,
@@ -899,8 +901,6 @@ static void gicv5_irq_ipi_domain_free(struct irq_domain *domain, unsigned int vi
if (!d)
return;
- gicv5_free_lpi(d->parent_data->hwirq);
-
irq_set_handler(virq + i, NULL);
irq_domain_reset_irq_data(d);
irq_domain_free_irqs_parent(domain, virq + i, 1);
diff --git a/include/linux/irqchip/arm-gic-v5.h b/include/linux/irqchip/arm-gic-v5.h
index 40d2fce682940..f78787e654f4c 100644
--- a/include/linux/irqchip/arm-gic-v5.h
+++ b/include/linux/irqchip/arm-gic-v5.h
@@ -425,9 +425,6 @@ struct gicv5_its_itt_cfg {
void gicv5_init_lpis(u32 max);
void gicv5_deinit_lpis(void);
-int gicv5_alloc_lpi(void);
-void gicv5_free_lpi(u32 lpi);
-
void __init gicv5_its_of_probe(struct device_node *parent);
void __init gicv5_its_acpi_probe(void);
#endif
--
2.34.1
^ permalink raw reply related
* [PATCH 2/3] irqchip/gic-v5: Allow for nr_irqs > 1 for LPI alloc and teardown
From: Sascha Bischoff @ 2026-04-30 15:34 UTC (permalink / raw)
To: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: nd, Lorenzo Pieralisi, Marc Zyngier, Thomas Gleixner
In-Reply-To: <20260430153352.3654325-1-sascha.bischoff@arm.com>
Formerly the LPI allocaion and freeing was handled by the domains
built on top of the LPI domain, and hence the LPI to use was passed in
from the child domain. This mandadated that LPI allocation and freeing
was done one at a time, rather than for a range of interrupts in one
go.
Now that the underlying restriction has been removed and all LPI
tracking happens within the LPI domain itself, drop the requirement to
allocate and free LPIs one-by-one. While we're at it, clean up the
IPI allocation to request all LPIs in one go, rather than requesting
them one at a time.
Incidentally, this fixes a unwind bug for IPIs where previously
allocated entries were not unwound on a failed parent allocation.
Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com>
---
drivers/irqchip/irq-gic-v5.c | 70 +++++++++++++++++++-----------------
1 file changed, 38 insertions(+), 32 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v5.c b/drivers/irqchip/irq-gic-v5.c
index a3c9eaa8ff486..61a70fe48bc32 100644
--- a/drivers/irqchip/irq-gic-v5.c
+++ b/drivers/irqchip/irq-gic-v5.c
@@ -800,17 +800,16 @@ static void gicv5_irq_lpi_domain_free(struct irq_domain *domain, unsigned int vi
unsigned int nr_irqs)
{
struct irq_data *d;
+ int i;
- if (WARN_ON_ONCE(nr_irqs != 1))
- return;
-
- d = irq_domain_get_irq_data(domain, virq);
-
+ for (i = 0; i < nr_irqs; i++) {
+ d = irq_domain_get_irq_data(domain, virq + i);
- release_lpi(d->hwirq);
+ release_lpi(d->hwirq);
- irq_set_handler(virq, NULL);
- irq_domain_reset_irq_data(d);
+ irq_set_handler(virq + i, NULL);
+ irq_domain_reset_irq_data(d);
+ }
}
static int gicv5_irq_lpi_domain_alloc(struct irq_domain *domain, unsigned int virq,
@@ -818,32 +817,38 @@ static int gicv5_irq_lpi_domain_alloc(struct irq_domain *domain, unsigned int vi
{
irq_hw_number_t hwirq;
struct irq_data *irqd;
- int ret;
-
- if (WARN_ON_ONCE(nr_irqs != 1))
- return -EINVAL;
+ int ret, i;
- ret = alloc_lpi();
- if (ret < 0)
- return ret;
- hwirq = ret;
+ for (i = 0; i < nr_irqs; i++) {
+ ret = alloc_lpi();
+ if (ret < 0)
+ goto out_free_lpis;
+ hwirq = ret;
+
+ ret = gicv5_irs_iste_alloc(hwirq);
+ if (ret < 0) {
+ /* Undo partial state first, then clean up the rest */
+ release_lpi(hwirq);
+ goto out_free_lpis;
+ }
- irqd = irq_domain_get_irq_data(domain, virq);
+ irqd = irq_domain_get_irq_data(domain, virq + i);
- irq_domain_set_info(domain, virq, hwirq, &gicv5_lpi_irq_chip, NULL,
- handle_fasteoi_irq, NULL, NULL);
- irqd_set_single_target(irqd);
+ irq_domain_set_info(domain, virq + i, hwirq, &gicv5_lpi_irq_chip,
+ NULL, handle_fasteoi_irq, NULL, NULL);
+ irqd_set_single_target(irqd);
- ret = gicv5_irs_iste_alloc(hwirq);
- if (ret < 0) {
- release_lpi(hwirq);
- return ret;
+ gicv5_hwirq_init(hwirq, GICV5_IRQ_PRI_MI, GICV5_HWIRQ_TYPE_LPI);
+ gicv5_lpi_config_reset(irqd);
}
- gicv5_hwirq_init(hwirq, GICV5_IRQ_PRI_MI, GICV5_HWIRQ_TYPE_LPI);
- gicv5_lpi_config_reset(irqd);
-
return 0;
+
+out_free_lpis:
+ if (i)
+ gicv5_irq_lpi_domain_free(domain, virq, i);
+
+ return ret;
}
static const struct irq_domain_ops gicv5_irq_lpi_domain_ops = {
@@ -871,11 +876,11 @@ static int gicv5_irq_ipi_domain_alloc(struct irq_domain *domain, unsigned int vi
struct irq_data *irqd;
int ret, i;
- for (i = 0; i < nr_irqs; i++) {
- ret = irq_domain_alloc_irqs_parent(domain, virq + i, 1, NULL);
- if (ret)
- return ret;
+ ret = irq_domain_alloc_irqs_parent(domain, virq, nr_irqs, arg);
+ if (ret)
+ return ret;
+ for (i = 0; i < nr_irqs; i++) {
irqd = irq_domain_get_irq_data(domain, virq + i);
irq_domain_set_hwirq_and_chip(domain, virq + i, i,
@@ -903,8 +908,9 @@ static void gicv5_irq_ipi_domain_free(struct irq_domain *domain, unsigned int vi
irq_set_handler(virq + i, NULL);
irq_domain_reset_irq_data(d);
- irq_domain_free_irqs_parent(domain, virq + i, 1);
}
+
+ irq_domain_free_irqs_parent(domain, virq, nr_irqs);
}
static const struct irq_domain_ops gicv5_irq_ipi_domain_ops = {
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v1 00/12] KVM Dirty-bit cleaning accelerator (HACDBS)
From: Leonardo Bras @ 2026-04-30 15:35 UTC (permalink / raw)
To: Marc Zyngier
Cc: Leonardo Bras, Catalin Marinas, Will Deacon, Oliver Upton,
Joey Gouly, Suzuki K Poulose, Zenghui Yu, Rafael J. Wysocki,
Len Brown, Saket Dumbre, Paolo Bonzini, Chengwen Feng,
Jonathan Cameron, Kees Cook, Mikołaj Lenczewski,
Ryan Roberts, Yang Shi, Thomas Huth, mrigendrachaubey,
Yeoreum Yun, Mark Brown, Kevin Brodsky, James Clark,
Ard Biesheuvel, Fuad Tabba, Raghavendra Rao Ananta,
Nathan Chancellor, Vincent Donnefort, Lorenzo Pieralisi,
Sascha Bischoff, Anshuman Khandual, Tian Zheng, Wei-Lin Chang,
linux-kernel, linux-arm-kernel, kvmarm, linux-acpi, acpica-devel,
kvm
In-Reply-To: <86a4ukzel3.wl-maz@kernel.org>
On Thu, Apr 30, 2026 at 03:51:20PM +0100, Marc Zyngier wrote:
> On Thu, 30 Apr 2026 14:29:37 +0100,
> Leonardo Bras <leo.bras@arm.com> wrote:
> >
> > On Thu, Apr 30, 2026 at 02:14:22PM +0100, Marc Zyngier wrote:
> > > On Thu, 30 Apr 2026 12:14:04 +0100,
> > > Leonardo Bras <leo.bras@arm.com> wrote:
> > >
> > > > d - In __kvm_arch_dirty_log_clear() there is no way to predict how long
> > > > should be the buffer, so I used 1x PAGE_SIZE, and when it gets full
> > > > it's cleaned and reused. Should I let users configure that over a
> > > > parameter, or is it overthinking?
> > >
> > > How long is a piece of string? We can't know that. A single page feels
> > > very small in the 4kB case, and letting userspace define the size of
> > > that buffer seems a likely requirement.
> > >
> >
> > Ok, as a KVM parameter, or as a compile-time option?
>
> Noticed the "userspace" word in there? It *has* to be controlled by
> userspace one way or another. So not as a kernel parameter, and
> *never* as a compile option.
Okay, I would suggest that a module parameter could be set by userspace,
but I remember now that it is usually built in the kernel instead. Also, it
could be bad having this set for the whole system, instead of per-VM.
How do you suggest letting userspace control that?
(All I could think was using an ioctl / API of any sorts, which would
require changing the VMMs as well.)
>
> > > > Kernel v7.0.0 + this patchset builds properly, passing both kvm selftests
> > > > for dirty-bit tracking[2], on HW HACDBS enabled or disabled.
> > >
> > > I have absolutely no trust in these tests.
> > >
> > > Have you enabled a VMM to make use of these APIs, and actively
> > > migrated running guests? That's the level of testing I'd like to see,
> > > as the selftests are not what people run in production...
> > >
> >
> > There is no enablement needed on VMM side.
> > Yes, I have created a VM on upstream qemu with --enable-kvm and migrated it
> > on the same host. (Inside a model)
> >
> > That was the first test I used, but then I found out that kvm selftests
> > stress up multiple scenarios in an easier way.
>
> Except when they don't. In my experience, the selftests are only there
> to give the CI people the fuzzy feeling that they are doing something
> useful.
LOL
> I have a collection of examples indicating that what these
> things test is not representative of the bugs we have in KVM.
>
Fair enough... it was tested in qemu live migration, and it works properly
(migrated from 2 instances of qemu in the same host, emulated by model).
> > Do you prefer me to test on any specific scenario, or does whatever qemu
> > uses as a default parameter work well enough?
>
> I want to hear about testing at a scale that make sense for production
> VMs, including live migrating between hosts while under memory
> pressure (swapping out).
I agree that's a more interesting test.
>
> I'm also interested in efficiency: how much better is HACDBS compared
> to the current page faulting?
The terms are indeed confusing, but HACDBS is just the cleaning accelerator
for dirty-bit. It means it will only affect how long it takes to transverse
the page table making pages in the array writable-dirty -> writable-clean.
That being said, it regards to efficiency:
Well, as I only have the model to test that, I am limmited to those
results, which may not reflect reality.
As an example, on dirty_log_perf_test, the cleaning process took much
longer (8x) compared to software cleaning, even when faced with no error,
and entries that fit the array (4k page above). If it took that long even
in this ideal scenario, it means the HACDBS mechanism implemented in the
model takes much longer than software, which is counter-intuitive.
> Just having patches for a feature is not
> enough to decide adoption of that feature. Show me the benefits in a
> quantitative way (within the limits of the model, of course).
Sure, I will try measuring migration between 2 instances of the model, and
see how qemu live migration time is affected, then post the results in this
thread for us to compare.
Thanks!
Leo
^ permalink raw reply
* [PATCH 3/3] irqchip/gic-v5: Allocate ITS parent LPIs as a range
From: Sascha Bischoff @ 2026-04-30 15:34 UTC (permalink / raw)
To: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: nd, Lorenzo Pieralisi, Marc Zyngier, Thomas Gleixner
In-Reply-To: <20260430153352.3654325-1-sascha.bischoff@arm.com>
The ITS MSI domain no longer manages LPI allocation directly. LPIs are
allocated and freed by the parent LPI domain, which can now handle a
full range of interrupts and unwind partial allocations internally.
Make the ITS domain request and release the parent IRQs as a single
range instead of iterating over each interrupt. The ITS allocation
path then only needs to reserve EventIDs, allocate the parent range,
and fill in the ITS irq_data for each MSI. Since no operation in the
per-MSI loop can fail, the partial parent-free unwind becomes
unnecessary.
On teardown, reset the ITS irq_data for the range and then release the
parent range in one call, leaving LPI teardown to the LPI domain.
Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com>
---
drivers/irqchip/irq-gic-v5-its.c | 22 +++++++---------------
1 file changed, 7 insertions(+), 15 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v5-its.c b/drivers/irqchip/irq-gic-v5-its.c
index 36d03f82ef684..28e39b065de0e 100644
--- a/drivers/irqchip/irq-gic-v5-its.c
+++ b/drivers/irqchip/irq-gic-v5-its.c
@@ -937,6 +937,7 @@ static int gicv5_its_irq_domain_alloc(struct irq_domain *domain, unsigned int vi
int ret, i;
its_dev = info->scratchpad[0].ptr;
+ device_id = its_dev->device_id;
ret = gicv5_its_alloc_eventid(its_dev, info, nr_irqs, &event_id_base);
if (ret)
@@ -946,14 +947,11 @@ static int gicv5_its_irq_domain_alloc(struct irq_domain *domain, unsigned int vi
if (ret)
goto out_eventid;
- device_id = its_dev->device_id;
+ ret = irq_domain_alloc_irqs_parent(domain, virq, nr_irqs, NULL);
+ if (ret)
+ goto out_eventid;
for (i = 0; i < nr_irqs; i++) {
- ret = irq_domain_alloc_irqs_parent(domain, virq + i, 1, NULL);
- if (ret) {
- goto out_free_irqs;
- }
-
/*
* Store eventid and deviceid into the hwirq for later use.
*
@@ -972,12 +970,6 @@ static int gicv5_its_irq_domain_alloc(struct irq_domain *domain, unsigned int vi
return 0;
-out_free_irqs:
- while (--i >= 0) {
- irqd = irq_domain_get_irq_data(domain, virq + i);
- irq_domain_reset_irq_data(irqd);
- irq_domain_free_irqs_parent(domain, virq + i, 1);
- }
out_eventid:
gicv5_its_free_eventid(its_dev, event_id_base, nr_irqs);
return ret;
@@ -1000,14 +992,14 @@ static void gicv5_its_irq_domain_free(struct irq_domain *domain, unsigned int vi
bitmap_release_region(its_dev->event_map, event_id_base,
get_count_order(nr_irqs));
- /* Hierarchically free irq data */
for (i = 0; i < nr_irqs; i++) {
d = irq_domain_get_irq_data(domain, virq + i);
-
irq_domain_reset_irq_data(d);
- irq_domain_free_irqs_parent(domain, virq + i, 1);
}
+ /* Hierarchically free irq data */
+ irq_domain_free_irqs_parent(domain, virq, nr_irqs);
+
gicv5_its_syncr(its, its_dev);
gicv5_irs_syncr();
}
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] arm64: dts: exynos850: Add SRAM node
From: Alexey Klimov @ 2026-04-30 15:37 UTC (permalink / raw)
To: Krzysztof Kozlowski, Rob Herring, Krzysztof Kozlowski
Cc: linux-samsung-soc, linux-arm-kernel, devicetree, linux-kernel,
Sam Protsenko, Conor Dooley, Alim Akhtar
In-Reply-To: <4c6a92e0-15a1-4f82-afc9-542f5ad9d2df@kernel.org>
On Tue Apr 14, 2026 at 10:08 AM BST, Krzysztof Kozlowski wrote:
> On 14/04/2026 11:00, Alexey Klimov wrote:
>> On Mon Apr 13, 2026 at 4:23 PM BST, Krzysztof Kozlowski wrote:
>>> On 13/04/2026 16:52, Alexey Klimov wrote:
>>>> SRAM is used by the ACPM protocol to retrieve the ACPM channels
>>>> information and configuration data. Add the SRAM node.
>>>>
>>>> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
>>>> ---
>>>> arch/arm64/boot/dts/exynos/exynos850.dtsi | 8 ++++++++
>>>> 1 file changed, 8 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/exynos/exynos850.dtsi b/arch/arm64/boot/dts/exynos/exynos850.dtsi
>>>> index cb55015c8dce..cf4a6168846c 100644
>>>> --- a/arch/arm64/boot/dts/exynos/exynos850.dtsi
>>>> +++ b/arch/arm64/boot/dts/exynos/exynos850.dtsi
>>>> @@ -910,6 +910,14 @@ spi_2: spi@11d20000 {
>>>> };
>>>> };
>>>> };
>>>> +
>>>> + apm_sram: sram@2039000 {
>>>> + compatible = "mmio-sram";
>>>> + reg = <0x0 0x2039000 0x40000>;
>>>> + #address-cells = <1>;
>>>> + #size-cells = <1>;
>>>> + ranges = <0x0 0x0 0x2039000 0x40000>;
>>>
>>> You miss here children.
>>
>> Thank you! I guess I should convert it to smth like this:
>>
>> apm_sram: sram@2039000 {
>> compatible = "mmio-sram";
>> reg = <0x0 0x2039000 0x40000>;
>> ranges = <0x0 0x0 0x2039000 0x40000>;
>> #address-cells = <1>;
>> #size-cells = <1>;
>>
>> acpm_sram_region: sram-section@0 {
>> reg = <0x0 0x40000>;
>
> This covers entire block, so feels pointless. Maybe requirement of
> children should be dropped. What's the point of having children? Why
> does the driver need them?
Thinking further about this. I was looking at the schema file and
different commits and it the right approach could be:
- add separate compatible for mmio-sram region for this case. Similar
to scmi and scpi, i'd say it should be "exynos,acpm-sram" or
"samsung,acpm-sram";
- update schema sram.yaml to exclude requirement for having child nodes
and properties like ranges, address and size cells
Similar like in commit, for instance, git show d0fe6491ddd22
(or git show 2d4a22e79a5fd).
- then this addition becomes:
apm_sram: sram@2039000 {
compatible = "exynos,acpm-sram";
reg = <0x0 0x2039000 0x40000>;
};
and will be consumed as a whole region (also as Tudor mentioned in the
other email).
And then we should update gs101 dts as well. Thoughts?
I honestly don't know why be default schema requires child nodes unless
it is specifically excluded. Could be a good question to Rob?
Or maybe we should really drop a requirement for having children from
schema.
>> And then later reference shmem = &acpm_sram_region from acpm node.
>>
>>> Also, 'ranges' should be after 'reg'.
>>
>> Thanks, will fix this.
>>
>> FWIW this commit is a copy of commit 48e7821b26904
>> https://lore.kernel.org/r/20250207-gs101-acpm-dt-v4-1-230ba8663a2d@linaro.org
>
>
> Huh, we should fix that one as well.
Best regardss,
Alexey
^ permalink raw reply
* [PATCH 05/10] spi: nxp-xspi: Use FIELD_MODIFY()
From: Hans Zhang @ 2026-04-30 15:54 UTC (permalink / raw)
To: broonie, sunny.luo, xianwei.zhao, neil.armstrong, khilman, han.xu,
haibo.chen, mcoquelin.stm32, alexandre.torgue, lhjeff911,
hayashi.kunihiko, mhiramat, jbrunet, martin.blumenstingl
Cc: linux-spi, linux-kernel, linux-amlogic, linux-arm-kernel, imx,
linux-stm32, Hans Zhang
In-Reply-To: <20260430155456.36998-1-18255117159@163.com>
Use FIELD_MODIFY() to remove open-coded bit manipulation.
No functional change intended.
Signed-off-by: Hans Zhang <18255117159@163.com>
---
drivers/spi/spi-nxp-xspi.c | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/spi/spi-nxp-xspi.c b/drivers/spi/spi-nxp-xspi.c
index 385302a6e62f..037eac24e6fd 100644
--- a/drivers/spi/spi-nxp-xspi.c
+++ b/drivers/spi/spi-nxp-xspi.c
@@ -493,9 +493,8 @@ static void nxp_xspi_disable_ddr(struct nxp_xspi *xspi)
writel(reg, base + XSPI_MCR);
reg &= ~XSPI_MCR_DDR_EN;
- reg &= ~XSPI_MCR_DQS_FA_SEL_MASK;
/* Use dummy pad loopback mode to sample data */
- reg |= FIELD_PREP(XSPI_MCR_DQS_FA_SEL_MASK, 0x01);
+ FIELD_MODIFY(XSPI_MCR_DQS_FA_SEL_MASK, ®, 0x01);
writel(reg, base + XSPI_MCR);
xspi->support_max_rate = 133000000;
@@ -524,15 +523,13 @@ static void nxp_xspi_enable_ddr(struct nxp_xspi *xspi)
writel(reg, base + XSPI_MCR);
reg |= XSPI_MCR_DDR_EN;
- reg &= ~XSPI_MCR_DQS_FA_SEL_MASK;
/* Use external dqs to sample data */
- reg |= FIELD_PREP(XSPI_MCR_DQS_FA_SEL_MASK, 0x03);
+ FIELD_MODIFY(XSPI_MCR_DQS_FA_SEL_MASK, ®, 0x03);
writel(reg, base + XSPI_MCR);
xspi->support_max_rate = 200000000;
reg = readl(base + XSPI_FLSHCR);
- reg &= ~XSPI_FLSHCR_TDH_MASK;
- reg |= FIELD_PREP(XSPI_FLSHCR_TDH_MASK, 0x01);
+ FIELD_MODIFY(XSPI_FLSHCR_TDH_MASK, ®, 0x01);
writel(reg, base + XSPI_FLSHCR);
reg = FIELD_PREP(XSPI_SMPR_DLLFSMPFA_MASK, 0x04);
@@ -1096,8 +1093,7 @@ static int nxp_xspi_default_setup(struct nxp_xspi *xspi)
/* Give read/write access right to EENV0 */
reg = readl(base + XSPI_FRAD0_WORD2);
- reg &= ~XSPI_FRAD0_WORD2_MD0ACP_MASK;
- reg |= FIELD_PREP(XSPI_FRAD0_WORD2_MD0ACP_MASK, 0x03);
+ FIELD_MODIFY(XSPI_FRAD0_WORD2_MD0ACP_MASK, ®, 0x03);
writel(reg, base + XSPI_FRAD0_WORD2);
/* Enable the FRAD check for EENV0 */
--
2.34.1
^ permalink raw reply related
* [PATCH 02/10] spi: amlogic-spisg: Use FIELD_MODIFY()
From: Hans Zhang @ 2026-04-30 15:54 UTC (permalink / raw)
To: broonie, sunny.luo, xianwei.zhao, neil.armstrong, khilman, han.xu,
haibo.chen, mcoquelin.stm32, alexandre.torgue, lhjeff911,
hayashi.kunihiko, mhiramat, jbrunet, martin.blumenstingl
Cc: linux-spi, linux-kernel, linux-amlogic, linux-arm-kernel, imx,
linux-stm32, Hans Zhang
In-Reply-To: <20260430155456.36998-1-18255117159@163.com>
Use FIELD_MODIFY() to remove open-coded bit manipulation.
No functional change intended.
Signed-off-by: Hans Zhang <18255117159@163.com>
---
drivers/spi/spi-amlogic-spisg.c | 13 +++++--------
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/spi/spi-amlogic-spisg.c b/drivers/spi/spi-amlogic-spisg.c
index 19c5eba412ef..4c9f4088cb37 100644
--- a/drivers/spi/spi-amlogic-spisg.c
+++ b/drivers/spi/spi-amlogic-spisg.c
@@ -601,14 +601,11 @@ static int aml_spisg_prepare_message(struct spi_controller *ctlr,
spisg->bytes_per_word = spi->bits_per_word >> 3;
- spisg->cfg_spi &= ~CFG_SLAVE_SELECT;
- spisg->cfg_spi |= FIELD_PREP(CFG_SLAVE_SELECT, spi_get_chipselect(spi, 0));
-
- spisg->cfg_bus &= ~(CFG_CPOL | CFG_CPHA | CFG_B_L_ENDIAN | CFG_HALF_DUPLEX);
- spisg->cfg_bus |= FIELD_PREP(CFG_CPOL, !!(spi->mode & SPI_CPOL)) |
- FIELD_PREP(CFG_CPHA, !!(spi->mode & SPI_CPHA)) |
- FIELD_PREP(CFG_B_L_ENDIAN, !!(spi->mode & SPI_LSB_FIRST)) |
- FIELD_PREP(CFG_HALF_DUPLEX, !!(spi->mode & SPI_3WIRE));
+ FIELD_MODIFY(CFG_SLAVE_SELECT, &spisg->cfg_spi, spi_get_chipselect(spi, 0));
+ FIELD_MODIFY(CFG_CPOL, &spisg->cfg_bus, !!(spi->mode & SPI_CPOL));
+ FIELD_MODIFY(CFG_CPHA, &spisg->cfg_bus, !!(spi->mode & SPI_CPHA));
+ FIELD_MODIFY(CFG_B_L_ENDIAN, &spisg->cfg_bus, !!(spi->mode & SPI_LSB_FIRST));
+ FIELD_MODIFY(CFG_HALF_DUPLEX, &spisg->cfg_bus, !!(spi->mode & SPI_3WIRE));
return 0;
}
--
2.34.1
^ 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