* Re: [PATCH 07/14] KVM: arm64: Restrict host access to the ITS tables
From: Sebastian Ene @ 2026-04-10 13:52 UTC (permalink / raw)
To: Fuad Tabba
Cc: alexandru.elisei, kvmarm, linux-arm-kernel, linux-kernel,
android-kvm, catalin.marinas, joey.gouly, kees, mark.rutland, maz,
oupton, perlarsen, qperret, rananta, smostafa, suzuki.poulose,
tglx, vdonnefort, bgrzesik, will, yuzenghui
In-Reply-To: <CA+EHjTxUbLBnyBGg58wsJQvTXPN0FTbj53H5r3sC9_TizpjvdQ@mail.gmail.com>
On Mon, Mar 16, 2026 at 04:13:59PM +0000, Fuad Tabba wrote:
Hello Fuad,
> Hi Sebastian,
>
> On Tue, 10 Mar 2026 at 12:49, Sebastian Ene <sebastianene@google.com> wrote:
> >
> > Setup shadow structures for ITS indirect tables held in
> > the GITS_BASER<n> registers.
> > Make the last level of the Device Table and vPE Table
> > inacessible to the host.
>
> inacessible -> inaccessible
Applied fix, thanks.
> > In a direct layout configuration, donate the table to
> > the hypervisor since the software is not expected to
> > program them directly.
>
> This commit message is too brief and doesn't fully explain the
> problem, the impact, and the mechanism of the solution. It also
> appears to contradict the actual code changes.
>
> For example, could you elaborate why must the last level of indirect
> tables be inaccessible?
For device table, a malicious host can write the ITT address that points
to hyp memory and then use MAPTI to write over that memory.
>
> Can you also please explain the mechanism? You are parsing
> GITS_BASER_INDIRECT to determine if a shadow Level 1 table must be
> shared with the host, while unconditionally donating the original
> physical tables. You also explicitly exclude Collection tables. The
> msg should briefly justify why Collection tables are safe to leave
> accessible to the host.
>
> There is also a contradiction in the message. You state "In a direct
> layout configuration, donate the table...". However, your code donates
> the original hardware table unconditionally on every iteration of the
> loop, regardless of whether GITS_BASER_INDIRECT is set. Please ensure
> the commit log accurately reflects the code implementation.
>
I see no contradition, I only need to shadow the first layer of the
indirect tables. Shadowing implies donation and sharing:
because we are donating the original tables from host -> hyp and we sharing the
host view of the tables with the hypervisor (which is a copy).
> Maybe you could say that the problem is Host DMA attacks via ITS table
> manipulation. Whereas the mechanism is to unconditionally donate
This has nothing to do with Host DMA attacks, it is just the AP that can
write to memory.
> hardware tables to EL2. For indirect Device/vPE tables, share a L1
> shadow table with the host and strictly donate the L2 pages to prevent
> the host from writing malicious L2 pointers.
>
> >
> > Signed-off-by: Sebastian Ene <sebastianene@google.com>
> > ---
> > arch/arm64/kvm/hyp/nvhe/its_emulate.c | 143 ++++++++++++++++++++++++++
> > 1 file changed, 143 insertions(+)
> >
> > diff --git a/arch/arm64/kvm/hyp/nvhe/its_emulate.c b/arch/arm64/kvm/hyp/nvhe/its_emulate.c
> > index 4a3ccc90a1a9..865a5d6353ed 100644
> > --- a/arch/arm64/kvm/hyp/nvhe/its_emulate.c
> > +++ b/arch/arm64/kvm/hyp/nvhe/its_emulate.c
> > @@ -141,6 +141,145 @@ static struct pkvm_protected_reg *get_region(phys_addr_t dev_addr)
> > return NULL;
> > }
> >
> > +static int pkvm_host_unmap_last_level(void *shadow, size_t num_pages, u32 psz)
> > +{
> > + u64 *table = shadow;
> > + int ret, i, end = (num_pages << PAGE_SHIFT) / sizeof(table);
> > + phys_addr_t table_addr;
>
> RCT, mixing initialized variables and uninitialized variables, plus
> variables of conceptually different "types" in the same declaration.
>
> Please use sizeof(*table): sizeof(table) evaluates to the size of the
> pointer (8 bytes), NOT the size of the array element. In this case,
> this happens to be the same, but it's still wrong.
>
> Maybe the following is clearer:
> + int end = num_pages * (PAGE_SIZE / sizeof(*table));
>
>
Will use the suggestion and do the same for the
pkvm_host_map_last_level.
> > +
> > + for (i = 0; i < end; i++) {
> > + if (!(table[i] & GITS_BASER_VALID))
> > + continue;
> > +
> > + table_addr = table[i] & PHYS_MASK;
> > + ret = __pkvm_host_donate_hyp(hyp_phys_to_pfn(table_addr), psz >> PAGE_SHIFT);
>
> The ITS-configured page size and the host page size could be
> different, but the number of pages to donate for Level 2 tables is
> calculated based on psz (the ITS).
>
> If the ITS hardware is configured for 4KB pages, but the host kernel
> is using (e.g.,) 64KB pages, psz >> PAGE_SHIFT evaluates to 0.
I need to revisit this, thanks for pointing out.
>
> You need to account for mismatched page sizes, perhaps by using
> DIV_ROUND_UP(psz, PAGE_SIZE) (or something similar) to ensure the
> containing host page is donated.
>
> > + if (ret)
> > + goto err_donate;
> > + }
> > +
> > + return 0;
> > +err_donate:
> > + for (i = i - 1; i >= 0; i--) {
>
> Please use the while (i--) idiom for rollback loops.
>
>
> > + if (!(table[i] & GITS_BASER_VALID))
> > + continue;
> > +
> > + table_addr = table[i] & PHYS_MASK;
> > + __pkvm_hyp_donate_host(hyp_phys_to_pfn(table_addr), psz >> PAGE_SHIFT);
>
> Please wrap this in WARN_ON(...). If donating back to the host fails
> during a rollback, we have a fatal page leak that needs to be loudly
> flagged, similar to how you handle it in pkvm_unshare_shadow_table.
>
>
> > + }
> > + return ret;
> > +}
> > +
> > +static int pkvm_share_shadow_table(void *shadow, u64 nr_pages)
> > +{
> > + u64 i, ret, start_pfn = hyp_virt_to_pfn(shadow);
>
> Same comment as before with RCT and the mixing of declarations.
>
>
> > +
> > + for (i = 0; i < nr_pages; i++) {
> > + ret = __pkvm_host_share_hyp(start_pfn + i);
> > + if (ret)
> > + goto unshare;
> > + }
> > +
> > + ret = hyp_pin_shared_mem(shadow, shadow + (nr_pages << PAGE_SHIFT));
> > + if (ret)
> > + goto unshare;
> > +
> > + return ret;
> > +unshare:
>
> Please use the while (i--) idiom for rollback loops.
>
> Also, please use consistent naming conventions for the labels. Here
> you call it unshare, and earlier it was err_donate.
>
>
> > + for (i = i - 1; i >= 0; i--)
> > + __pkvm_host_unshare_hyp(start_pfn + i);
> > + return ret;
> > +}
> > +
> > +static void pkvm_unshare_shadow_table(void *shadow, u64 nr_pages)
> > +{
> > + u64 i, start_pfn = hyp_virt_to_pfn(shadow);
> > +
> > + hyp_unpin_shared_mem(shadow, shadow + (nr_pages << PAGE_SHIFT));
> > +
> > + for (i = 0; i < nr_pages; i++)
> > + WARN_ON(__pkvm_host_unshare_hyp(start_pfn + i));
> > +}
> > +
> > +static void pkvm_host_map_last_level(void *shadow, size_t num_pages, u32 psz)
> > +{
> > + u64 *table;
>
> RCT, and you forgot to initialize table:
> + u64 *table = shadow;
Fixed this, thanks. I never ended up on this code path during testing,
maybe I should create a test for it to trigger it.
>
> > + int i, end = (num_pages << PAGE_SHIFT) / sizeof(table);
>
> Same sizeof(table) pointer-size bug as above.
>
>
> > + phys_addr_t table_addr;
> > +
> > + for (i = 0; i < end; i++) {
> > + if (!(table[i] & GITS_BASER_VALID))
> > + continue;
> > +
> > + table_addr = table[i] & ~GITS_BASER_VALID;
>
> Inconsistent masking logic, since in pkvm_host_unmap_last_level you
> correctly used PHYS_MASK to extract the address, but here in the
> rollback path you use ~GITS_BASER_VALID.
>
> While both currently work because the upper bits and lower bits (below
> the page size) are defined as RES0 in the GIC spec, ~GITS_BASER_VALID
> is architecturally fragile. If a future hardware revision repurposes
> the upper RES0 bits [62:52] for new attributes (e.g., memory
> encryption flags), ~GITS_BASER_VALID will leak those attribute bits
> into the physical address calculation.
>
> Since PHYS_MASK correctly handles the address extraction across all
> page sizes (relying on the lower bits being RES0) and safely masks off
> future upper attribute bits, please standardize on using table_addr =
> table[i] & PHYS_MASK; for both functions.
>
>
Fixed the inconsistency and used PHYS_MASK everywhere.
> > + WARN_ON(__pkvm_hyp_donate_host(hyp_phys_to_pfn(table_addr), psz >> PAGE_SHIFT));
> > + }
> > +}
> > +
> > +static int pkvm_setup_its_shadow_baser(struct its_shadow_tables *shadow)
> > +{
> > + int i, ret;
> > + u64 baser_val, num_pages, type;
> > + void *base, *host_base;
> > +
> > + for (i = 0; i < GITS_BASER_NR_REGS; i++) {
> > + baser_val = shadow->tables[i].val;
> > + if (!(baser_val & GITS_BASER_VALID))
> > + continue;
> > +
> > + base = kern_hyp_va(shadow->tables[i].base);
> > + num_pages = (1 << shadow->tables[i].order);
> > +
> > + ret = __pkvm_host_donate_hyp(hyp_virt_to_pfn(base), num_pages);
> > + if (ret)
> > + goto err_donate;
> > +
> > + if (baser_val & GITS_BASER_INDIRECT) {
> > + host_base = kern_hyp_va(shadow->tables[i].shadow);
> > + ret = pkvm_share_shadow_table(host_base, num_pages);
> > + if (ret)
> > + goto err_with_donation;
> > +
> > + type = GITS_BASER_TYPE(baser_val);
> > + if (type == GITS_BASER_TYPE_COLLECTION)
> > + continue;
> > +
> > + ret = pkvm_host_unmap_last_level(base, num_pages,
> > + shadow->tables[i].psz);
> > + if (ret)
> > + goto err_with_share;
> > + }
> > + }
> > +
> > + return 0;
> > +err_with_share:
> > + pkvm_unshare_shadow_table(host_base, num_pages);
> > +err_with_donation:
> > + __pkvm_hyp_donate_host(hyp_virt_to_pfn(base), num_pages);
> > +err_donate:
> > + for (i = i - 1; i >= 0; i--) {
>
> Please use the while (i--) idiom for rollback loops.
>
>
> > + baser_val = shadow->tables[i].val;
> > + if (!(baser_val & GITS_BASER_VALID))
> > + continue;
> > +
> > + base = kern_hyp_va(shadow->tables[i].base);
> > + num_pages = (1 << shadow->tables[i].order);
> > +
> > + WARN_ON(__pkvm_hyp_donate_host(hyp_virt_to_pfn(base), num_pages));
>
> The sequence of rollback operations here creates a TOCTOU vulnerability.
>
There is a different problem here related to functionality rather than
this: donating the base to the host first and then iterating over it
will make the hypervisor explode. I fixed this.
> - First, you donate base (the Level 1 indirect table) back to the host.
> - Then, you pass base into pkvm_host_map_last_level().
> - Finally, pkvm_host_map_last_level() reads table[i] out of base to
> determine which Level 2 pages to donate back to the host.
>
> Because the host regains ownership of base _first_, it can be running
> concurrently on another CPU. A malicious host can overwrite the Level
> 1 table with pointers to arbitrary hypervisor-owned memory. The
> hypervisor will then read those malicious pointers and dutifully grant
> the host access to its own secure memory.
>
> The order of operations needs to be reversed: you must read base to
> roll back the L2 pages, unshare the shadow table, and *only then*
> donate base back to the host.
>
> Also, num_pages = (1 << shadow->tables[i].order); calculates a 32-bit
> signed integer because the literal 1 is a signed 32-bit int. If order
> is 31, this evaluates to a negative number. If order is 32 or higher,
> this is undefined behavior. Because num_pages is declared as a u64,
> you should use the standard kernel macro BIT_ULL().
>
> Here's my suggested fix (not tested). Reorder the operations to safely
> rollback L2 before donating L1, use the standard `while (i--)` loop,
> and fix the page calculation:
>
> + while (i--) {
> + baser_val = shadow->tables[i].val;
> + if (!(baser_val & GITS_BASER_VALID))
> + continue;
> +
> + base = kern_hyp_va(shadow->tables[i].base);
> + num_pages = BIT_ULL(shadow->tables[i].order);
> +
> + if (baser_val & GITS_BASER_INDIRECT) {
> + host_base = kern_hyp_va(shadow->tables[i].shadow);
> +
> + type = GITS_BASER_TYPE(baser_val);
> + if (type != GITS_BASER_TYPE_COLLECTION)
> + pkvm_host_map_last_level(base, num_pages,
> + shadow->tables[i].psz);
> +
> + pkvm_unshare_shadow_table(host_base, num_pages);
> + }
> +
> + WARN_ON(__pkvm_hyp_donate_host(hyp_virt_to_pfn(base), num_pages));
> + }
>
>
>
> > + if (baser_val & GITS_BASER_INDIRECT) {
> > + host_base = kern_hyp_va(shadow->tables[i].shadow);
> > + pkvm_unshare_shadow_table(host_base, num_pages);
> > +
> > + type = GITS_BASER_TYPE(baser_val);
> > + if (type == GITS_BASER_TYPE_COLLECTION)
> > + continue;
> > +
> > + pkvm_host_map_last_level(base, num_pages, shadow->tables[i].psz);
> > + }
> > + }
>
> You have duplicated the entire table decoding logic (calculating base,
> num_pages, checking INDIRECT...) down here in the rollback path.
> Consider abstracting "setup one table" and "teardown one table" into
> helper functions to make pkvm_setup_its_shadow_baser more readable and
> less prone to copy-pasta errors.
>
> Cheers,
> /fuad
>
Thanks,
Sebastian
>
> > +
> > + return ret;
> > +}
> > +
> > static int pkvm_setup_its_shadow_cmdq(struct its_shadow_tables *shadow)
> > {
> > int ret, i, num_pages;
> > @@ -205,6 +344,10 @@ int pkvm_init_gic_its_emulation(phys_addr_t dev_addr, void *host_priv_state,
> > if (ret)
> > goto err_with_shadow;
> >
> > + ret = pkvm_setup_its_shadow_baser(shadow);
> > + if (ret)
> > + goto err_with_shadow;
> > +
> > its_reg->priv = priv_state;
> >
> > hyp_spin_lock_init(&priv_state->its_lock);
> > --
> > 2.53.0.473.g4a7958ca14-goog
> >
^ permalink raw reply
* Re: [PATCH v3 0/4] mm: improve large folio readahead and alignment for exec memory
From: Lorenzo Stoakes @ 2026-04-10 13:50 UTC (permalink / raw)
To: Vlastimil Babka (SUSE)
Cc: Usama Arif, Andrew Morton, david, willy, ryan.roberts, linux-mm,
r, jack, ajd, apopple, baohua, baolin.wang, brauner,
catalin.marinas, dev.jain, kees, kevin.brodsky, lance.yang,
Liam.Howlett, linux-arm-kernel, linux-fsdevel, linux-kernel,
mhocko, npache, pasha.tatashin, rmclure, rppt, surenb, Al Viro,
ziy, hannes, kas, shakeel.butt, leitao, kernel-team
In-Reply-To: <40f31e5a-7161-4b17-af03-52b3a28a113e@kernel.org>
On Fri, Apr 10, 2026 at 03:29:12PM +0200, Vlastimil Babka (SUSE) wrote:
> On 4/10/26 14:24, Lorenzo Stoakes wrote:
> > On Fri, Apr 10, 2026 at 01:19:08PM +0100, Usama Arif wrote:
> >> >> Thanks, Lorenzo
> >> >
> >> > (Note that we're in a 'quiet period' from here until -rc1 of next cycle and
> >> > won't be taking anything new until then. We plan to do this from around rc5 or
> >> > rc6 of each cycle in future).
> >>
> >> Thanks! Just wanted to check, as I am always confused about this. Is it ok
> >> to send patches for review for next release at this time? So that they
> >> are in a good state when rc1 comes. I wanted to send PMD swap entries
> >> for review after I am finished testing, but I want them for review for
> >> next release.
> >
> > I think different people have different views on that :)
> >
> > I mean it's debateable whether having a glut of new material on day one of -rc1
> > is preferable to having a bunch come in that might or might not get lost along
> > the way :)
> >
> > I personally feel it'd be better to send during the cycle window rather than
> > before but I suspect others disagree with that!
> >
> > So from your point of view, feel free to do what you like, but maybe David +
> > others would want to chime in with their opinions?
>
> For me the more important part of the quiet period is that patches can't be
> merged, so there's less urgency to review them immediately. So I think it's
> fine to still send patches, but not having expectations about quick
> response, as people might be taking time off.
>
> On the other hand it would be better if new series could mature in this
> quiet period, so there would be less work after rc1. But the key to making
> that possible I think is to feel less urgency/being overwhelmed also in the
> non-quiet period (rc1-rc5/6). Then it's should be less necessary to take
> time off during the quiet period. So hopefully we'll get there through
> involving more reviewers, and by having more submaintainers agency.
Yeah I sympathise with that.
But until we for-sure have <you know what :))> signoff, I worry about the risk
of series 'just being taken' at -rc1 because it maybe seems easier to do that,
and then we have a series from 5 weeks ago you forgot about suddenly crop up.
So I guess the more nuanced take I have is:
Once we have a robust set up end-to-end _that can handle_ having series that are
deferred to next cycle without risk of things getting mixed up - then that makes
sense, yes.
But while there's still a bit of uncertainty around that, then I'd rather not.
But I think if people DO just resend their stuff in -rc1 then we're OK and it
addresses my concerns.
One thing we could do here is to tag series appropriately like:
[PATCH v7.2] 00/42
To make it clear where it's intended to head to.
P.S. Having the 'quiet period' REALLY REALLY helps. So thanks for that Andrew!
>
> Vlastimil
Thanks, Lorenzo
^ permalink raw reply
* Re: [patch 09/38] iommu/vt-d: Use sched_clock() instead of get_cycles()
From: Baolu Lu @ 2026-04-10 13:45 UTC (permalink / raw)
To: Thomas Gleixner, LKML
Cc: baolu.lu, x86, iommu, Arnd Bergmann, Michael Grzeschik, netdev,
linux-wireless, Herbert Xu, linux-crypto, Vlastimil Babka,
linux-mm, David Woodhouse, Bernie Thompson, linux-fbdev,
Theodore Tso, linux-ext4, Andrew Morton, Uladzislau Rezki,
Marco Elver, Dmitry Vyukov, kasan-dev, Andrey Ryabinin,
Thomas Sailer, linux-hams, Jason A. Donenfeld, Richard Henderson,
linux-alpha, Russell King, linux-arm-kernel, Catalin Marinas,
Huacai Chen, loongarch, Geert Uytterhoeven, linux-m68k,
Dinh Nguyen, Jonas Bonn, linux-openrisc, Helge Deller,
linux-parisc, Michael Ellerman, linuxppc-dev, Paul Walmsley,
linux-riscv, Heiko Carstens, linux-s390, David S. Miller,
sparclinux
In-Reply-To: <20260410120318.187521447@kernel.org>
On 4/10/2026 8:19 PM, Thomas Gleixner wrote:
> Calculating the timeout from get_cycles() is a historical leftover without
> any functional requirement.
>
> Use ktime_get() instead.
The subject line says "Use sched_clock() ...", but the implementation
actually uses ktime_get(). Is it a typo or anything I misunderstood?
Other parts look good to me,
Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
>
> Signed-off-by: Thomas Gleixner<tglx@kernel.org>
> Cc:x86@kernel.org
> Cc: Lu Baolu<baolu.lu@linux.intel.com>
> Cc:iommu@lists.linux.dev
> ---
> arch/x86/include/asm/iommu.h | 3 ---
> drivers/iommu/intel/dmar.c | 4 ++--
> drivers/iommu/intel/iommu.h | 8 ++++++--
> 3 files changed, 8 insertions(+), 7 deletions(-)
Thanks,
baolu
^ permalink raw reply
* Re: [PATCH v3 4/7] arm64: dts: ti: k3-am62a7-sk: Split r5f memory region
From: Markus Schneider-Pargmann @ 2026-04-10 13:42 UTC (permalink / raw)
To: Vignesh Raghavendra, Markus Schneider-Pargmann (TI),
Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Suman Anna, Nishanth Menon,
Tero Kristo
Cc: Vishal Mahaveer, Kevin Hilman, Dhruva Gole, Sebin Francis,
Kendall Willis, Akashdeep Kaur, linux-remoteproc, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <8673745d-aad2-49d3-b3af-556de7037b69@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1864 bytes --]
Hi Vignesh,
On Fri Apr 10, 2026 at 6:30 AM CEST, Vignesh Raghavendra wrote:
> Hi Markus
>
> On 18/03/26 20:43, Markus Schneider-Pargmann (TI) wrote:
>> Split the firmware memory region in more specific parts so it is better
>> described where to find which information. Specifically the LPM metadata
>> region is important as bootloader software like U-Boot has to know where
>> that data is to be able to read that data.
>>
>> Signed-off-by: Markus Schneider-Pargmann (TI) <msp@baylibre.com>
>> ---
>> arch/arm64/boot/dts/ti/k3-am62a7-sk.dts | 40 +++++++++++++++++++++++++++++++--
>> 1 file changed, 38 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
>> index e99bdbc2e0cbdf858f1631096f9c2a086191bab3..c381cc33064ec427751a9ac5bcdff745a9559a89 100644
>> --- a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
>> +++ b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
>> @@ -59,9 +59,33 @@ wkup_r5fss0_core0_dma_memory_region: memory@9c800000 {
>> no-map;
>> };
>>
>> - wkup_r5fss0_core0_memory_region: memory@9c900000 {
>> + wkup_r5fss0_core0_ipc_region: memory@9c900000 {
>
> There are still references to wkup_r5fss0_core0_memory_region in
> k3-am62a-ti-ipc-firmware.dtsi (same comment applies to next 2 patches as
> well)
>
> Dont those need to be updated too?
I only updated the sk boards as these are the only ones that have IO+DDR
support that I know works and need the new memory region layout. But
thinking about this, updating the memory region structure shouldn't be a
problem for the other boards either, of course I can't tell if IO+DDR
would work on them, but the new memory region layout shouldn't break
anything.
I can respin the series or do a followup series with modifications for
all boards if you like.
Best
Markus
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 289 bytes --]
^ permalink raw reply
* Re: [patch 19/38] kcsan: Replace get_cycles() usage
From: Marco Elver @ 2026-04-10 13:39 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, Dmitry Vyukov, kasan-dev, Arnd Bergmann, x86, Lu Baolu,
iommu, Michael Grzeschik, netdev, linux-wireless, Herbert Xu,
linux-crypto, Vlastimil Babka, linux-mm, David Woodhouse,
Bernie Thompson, linux-fbdev, Theodore Tso, linux-ext4,
Andrew Morton, Uladzislau Rezki, Andrey Ryabinin, Thomas Sailer,
linux-hams, Jason A. Donenfeld, Richard Henderson, linux-alpha,
Russell King, linux-arm-kernel, Catalin Marinas, Huacai Chen,
loongarch, Geert Uytterhoeven, linux-m68k, Dinh Nguyen,
Jonas Bonn, linux-openrisc, Helge Deller, linux-parisc,
Michael Ellerman, linuxppc-dev, Paul Walmsley, linux-riscv,
Heiko Carstens, linux-s390, David S. Miller, sparclinux
In-Reply-To: <20260410120318.862164111@kernel.org>
On Fri, 10 Apr 2026 at 14:20, Thomas Gleixner <tglx@kernel.org> wrote:
>
> KCSAN uses get_cycles() for two purposes:
>
> 1) Seeding the random state with get_cycles() is a historical leftover.
>
> 2) The microbenchmark uses get_cycles(), which provides an unit less
> counter value and is not guaranteed to be functional on all
> systems/platforms.
>
> Use random_get_entropy() for seeding the random state and ktime_get() which
> is universaly functional and provides at least a comprehensible unit.
>
> This is part of a larger effort to remove get_cycles() usage from
> non-architecture code.
>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
> Cc: Marco Elver <elver@google.com>
> Cc: Dmitry Vyukov <dvyukov@google.com>
> Cc: kasan-dev@googlegroups.com
Reviewed-by: Marco Elver <elver@google.com>
> ---
> kernel/kcsan/core.c | 2 +-
> kernel/kcsan/debugfs.c | 8 ++++----
> 2 files changed, 5 insertions(+), 5 deletions(-)
>
> --- a/kernel/kcsan/core.c
> +++ b/kernel/kcsan/core.c
> @@ -798,7 +798,7 @@ void __init kcsan_init(void)
> BUG_ON(!in_task());
>
> for_each_possible_cpu(cpu)
> - per_cpu(kcsan_rand_state, cpu) = (u32)get_cycles();
> + per_cpu(kcsan_rand_state, cpu) = (u32)random_get_entropy();
>
> /*
> * We are in the init task, and no other tasks should be running;
> --- a/kernel/kcsan/debugfs.c
> +++ b/kernel/kcsan/debugfs.c
> @@ -58,7 +58,7 @@ static noinline void microbenchmark(unsi
> {
> const struct kcsan_ctx ctx_save = current->kcsan_ctx;
> const bool was_enabled = READ_ONCE(kcsan_enabled);
> - u64 cycles;
> + ktime_t nsecs;
>
> /* We may have been called from an atomic region; reset context. */
> memset(¤t->kcsan_ctx, 0, sizeof(current->kcsan_ctx));
> @@ -70,16 +70,16 @@ static noinline void microbenchmark(unsi
>
> pr_info("%s begin | iters: %lu\n", __func__, iters);
>
> - cycles = get_cycles();
> + nsecs = ktime_get();
> while (iters--) {
> unsigned long addr = iters & ((PAGE_SIZE << 8) - 1);
> int type = !(iters & 0x7f) ? KCSAN_ACCESS_ATOMIC :
> (!(iters & 0xf) ? KCSAN_ACCESS_WRITE : 0);
> __kcsan_check_access((void *)addr, sizeof(long), type);
> }
> - cycles = get_cycles() - cycles;
> + nsecs = ktime_get() - nsecs;
>
> - pr_info("%s end | cycles: %llu\n", __func__, cycles);
> + pr_info("%s end | nsecs: %llu\n", __func__, nsecs);
>
> WRITE_ONCE(kcsan_enabled, was_enabled);
> /* restore context */
>
^ permalink raw reply
* Re: [PATCH v3 0/4] mm: improve large folio readahead and alignment for exec memory
From: Vlastimil Babka (SUSE) @ 2026-04-10 13:29 UTC (permalink / raw)
To: Lorenzo Stoakes, Usama Arif
Cc: Andrew Morton, david, willy, ryan.roberts, linux-mm, r, jack, ajd,
apopple, baohua, baolin.wang, brauner, catalin.marinas, dev.jain,
kees, kevin.brodsky, lance.yang, Liam.Howlett, linux-arm-kernel,
linux-fsdevel, linux-kernel, mhocko, npache, pasha.tatashin,
rmclure, rppt, surenb, Al Viro, ziy, hannes, kas, shakeel.butt,
leitao, kernel-team
In-Reply-To: <adjrKwgiZwXR9epk@lucifer>
On 4/10/26 14:24, Lorenzo Stoakes wrote:
> On Fri, Apr 10, 2026 at 01:19:08PM +0100, Usama Arif wrote:
>> >> Thanks, Lorenzo
>> >
>> > (Note that we're in a 'quiet period' from here until -rc1 of next cycle and
>> > won't be taking anything new until then. We plan to do this from around rc5 or
>> > rc6 of each cycle in future).
>>
>> Thanks! Just wanted to check, as I am always confused about this. Is it ok
>> to send patches for review for next release at this time? So that they
>> are in a good state when rc1 comes. I wanted to send PMD swap entries
>> for review after I am finished testing, but I want them for review for
>> next release.
>
> I think different people have different views on that :)
>
> I mean it's debateable whether having a glut of new material on day one of -rc1
> is preferable to having a bunch come in that might or might not get lost along
> the way :)
>
> I personally feel it'd be better to send during the cycle window rather than
> before but I suspect others disagree with that!
>
> So from your point of view, feel free to do what you like, but maybe David +
> others would want to chime in with their opinions?
For me the more important part of the quiet period is that patches can't be
merged, so there's less urgency to review them immediately. So I think it's
fine to still send patches, but not having expectations about quick
response, as people might be taking time off.
On the other hand it would be better if new series could mature in this
quiet period, so there would be less work after rc1. But the key to making
that possible I think is to feel less urgency/being overwhelmed also in the
non-quiet period (rc1-rc5/6). Then it's should be less necessary to take
time off during the quiet period. So hopefully we'll get there through
involving more reviewers, and by having more submaintainers agency.
Vlastimil
^ permalink raw reply
* Re: [PATCH v5 4/4] arm64: errata: Work around early CME DVMSync acknowledgement
From: Will Deacon @ 2026-04-10 13:26 UTC (permalink / raw)
To: Catalin Marinas; +Cc: linux-arm-kernel, James Morse, Mark Rutland, Mark Brown
In-Reply-To: <adjzVTjEOz7DGmW4@arm.com>
On Fri, Apr 10, 2026 at 01:55:49PM +0100, Catalin Marinas wrote:
> On Fri, Apr 10, 2026 at 01:09:41PM +0100, Will Deacon wrote:
> > On Tue, Apr 07, 2026 at 11:28:44AM +0100, Catalin Marinas wrote:
> > > diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
> > > index 489554931231..4c328b7c79ba 100644
> > > --- a/arch/arm64/kernel/process.c
> > > +++ b/arch/arm64/kernel/process.c
> > > @@ -26,6 +26,7 @@
> > > #include <linux/reboot.h>
> > > #include <linux/interrupt.h>
> > > #include <linux/init.h>
> > > +#include <linux/cpumask.h>
> > > #include <linux/cpu.h>
> > > #include <linux/elfcore.h>
> > > #include <linux/pm.h>
> > > @@ -339,8 +340,41 @@ void flush_thread(void)
> > > flush_gcs();
> > > }
> > >
> > > +#ifdef CONFIG_ARM64_ERRATUM_4193714
> > > +
> > > +static void arch_dup_tlbbatch_mask(struct task_struct *dst)
> > > +{
> > > + /*
> > > + * Clear the inherited cpumask with memset() to cover both cases where
> > > + * cpumask_var_t is a pointer or an array. It will be allocated lazily
> > > + * in sme_dvmsync_add_pending() if CPUMASK_OFFSTACK=y.
> > > + */
> > > + if (alternative_has_cap_unlikely(ARM64_WORKAROUND_4193714))
> > > + memset(&dst->tlb_ubc.arch.cpumask, 0,
> > > + sizeof(dst->tlb_ubc.arch.cpumask));
> >
> > nit: use cpumask_clear() instead?
>
> I tried to explain in the comment above. The memset() is on purpose to
> avoid #ifdef CPUMASK_OFFSTACK. When enabled, cpumask_var_t is a pointer
> and we want it set to NULL (for later lazy allocation) rather than
> clearing the parent's cpumask. I had the diff below initially but it
> looked uglier. Or we make the erratum dependent on !CPUMASK_OFFSTACK but
> it won't get compile coverage with defconfig.
Sorry, my mistake. I was focussing on the mm_cpumask() changes since v3
(which always seem to be embedded as part of the 'mm_struct' allocation)
and didn't realise that this memset() is operating on the TLB batch
cpumask.
So it looks like v5 is the charm :)
Will
^ permalink raw reply
* [GIT PULL] ARM: mvebu: dt64 for v7.1 (#1)
From: Gregory CLEMENT @ 2026-04-10 13:25 UTC (permalink / raw)
To: Arnd Bergmann, arm, soc
Cc: Andrew Lunn, Sebastian Hesselbarth, linux-arm-kernel
Hi,
Here is the first pull request for dt64 for mvebu for v7.1.
Gregory
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu.git tags/mvebu-dt64-7.1-1
for you to fetch changes up to 00e6d608fe80b0f68c325cb46862f78e9a8ec768:
arm64: dts: marvell: armada-37xx: swap PHYs' order in USB3 controller node (2026-04-09 10:14:40 +0200)
----------------------------------------------------------------
mvebu dt64 for 7.1 (part 1)
- Armada 37xx/3720 device tree fixes:
- Reorder USB PHYs, standardize names, drop undocumented
properties, fix schema alignment
- Add Marvell 7k COMe board bindings and uDPU ethernet aliases
- Cleanup: drop unused .dtsi files
----------------------------------------------------------------
Elad Nachman (2):
arm64: dts: a7k: use phy handle
dt-bindings: arm64: add Marvell 7k COMe boards
Gabor Juhos (6):
arm64: dts: marvell: armada-3720: drop 'marvell,xenon-emmc' properties
arm64: dts: marvell: armada-37xx: align 'phy-names' of EHCI node with DT schema
arm64: dts: marvell: armada-37xx: drop redundant status property
arm64: dts: marvell: armada-37xx: drop 'marvell,usb-misc-reg' from USB host nodes
arm64: dts: marvell: armada-37xx: use 'usb2-phy' in USB3 controller's phy-names
arm64: dts: marvell: armada-37xx: swap PHYs' order in USB3 controller node
Rob Herring (Arm) (1):
arm/arm64: dts: marvell: Drop unused .dtsi
Robert Marko (1):
arm64: dts: marvell: uDPU: add ethernet aliases
.../bindings/arm/marvell/armada-7k-8k.yaml | 11 ++
arch/arm/boot/dts/marvell/armada-380.dtsi | 148 ---------------------
.../boot/dts/marvell/armada-3720-atlas-v5.dts | 1 -
.../boot/dts/marvell/armada-3720-espressobin.dtsi | 1 -
arch/arm64/boot/dts/marvell/armada-3720-uDPU.dtsi | 7 +-
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 9 +-
.../boot/dts/marvell/armada-7020-comexpress.dtsi | 2 +-
arch/arm64/boot/dts/marvell/armada-8020.dtsi | 20 ---
.../boot/dts/marvell/cn9130-db-comexpress.dtsi | 96 -------------
9 files changed, 21 insertions(+), 274 deletions(-)
delete mode 100644 arch/arm/boot/dts/marvell/armada-380.dtsi
delete mode 100644 arch/arm64/boot/dts/marvell/armada-8020.dtsi
delete mode 100644 arch/arm64/boot/dts/marvell/cn9130-db-comexpress.dtsi
--
Grégory CLEMENT, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH net-next v3 01/12] dt-bindings: net: airoha: Add EN7581 ethernet-ports properties
From: Lorenzo Bianconi @ 2026-04-10 13:14 UTC (permalink / raw)
To: Jakub Kicinski
Cc: andrew+netdev, davem, edumazet, pabeni, robh, krzk+dt, conor+dt,
ansuelsmth, benjamin.larsson, linux-arm-kernel, linux-mediatek,
netdev, devicetree
In-Reply-To: <20260410025717.1809904-1-kuba@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 2119 bytes --]
> This is an AI-generated review of your patch. The human sending this
> email says "For your consideration."
> ---
> dt-bindings: net: airoha: Add EN7581 ethernet-ports properties
>
> This commit introduces the ethernet-port property to model a net_device
> connected via an external arbiter to the GDM3 or GDM4 ports on EN7581
> and AN7583 SoCs.
>
> > diff --git a/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml b/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml
> > index fbe2ddcdd909c..ebbd433e9c9fb 100644
> > --- a/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml
> > +++ b/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml
> > @@ -130,6 +130,30 @@ patternProperties:
> > maximum: 4
> > description: GMAC port identifier
> >
> > + '#address-cells':
> > + const: 1
> > + '#size-cells':
> > + const: 0
> > +
> > + patternProperties:
> > + "^ethernet-port@[0-5]$":
>
> The commit message states that GDM1 and GDM2 do not support connection
> with the external arbiter. However, since this pattern property appears to
> be placed inside the generic ^ethernet@[1-4]$ block, does this allow a
> device tree to incorrectly configure ethernet-port subnodes on ethernet@1
> or ethernet@2 and still pass schema validation?
ack, I will fix it in v4
>
> Could this be restricted to GDM3 and GDM4, perhaps by splitting the
> patternProperties or using an if/then block based on the reg property?
>
> > + type: object
> > + unevaluatedProperties: false
> > + $ref: ethernet-controller.yaml#
>
> Does referencing ethernet-controller.yaml cause a validation conflict here?
>
> The ethernet-controller.yaml schema enforces a strict nodename pattern
> of ^ethernet(@.*)?$. Since these new nodes use the -port suffix and are
> named ethernet-port@X, will they unconditionally fail the node name
> validation enforced by the referenced schema during dt_binding_check?
ack, I will fix it in v4
Regards,
Lorenzo
>
> [ ... ]
> --
> pw-bot: cr
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH net-next] net: stmmac: enable RPS and RBU interrupts
From: Russell King (Oracle) @ 2026-04-10 13:07 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, linux-arm-kernel, linux-stm32, netdev,
Paolo Abeni, Sam Edwards
Enable receive process stopped and receive buffer unavailable
interrupts, so that the statistic counters can be updated.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
Since we are seeing receive buffer exhaustion on several platforms,
let's enable the interrupts so the statistics we publish via ethtool -S
actually work to aid diagnosis. I've been in two minds about whether
to send this patch, but given the problems with stmmac at the moment,
I think it should be merged.
drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.h b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.h
index af6580332d49..43b036d4e95b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.h
@@ -99,6 +99,8 @@ static inline u32 dma_chanx_base_addr(const struct dwmac4_addrs *addrs,
#define DMA_CHAN_INTR_ENA_NIE_4_10 BIT(15)
#define DMA_CHAN_INTR_ENA_AIE_4_10 BIT(14)
#define DMA_CHAN_INTR_ENA_FBE BIT(12)
+#define DMA_CHAN_INTR_ENA_RPS BIT(8)
+#define DMA_CHAN_INTR_ENA_RBU BIT(7)
#define DMA_CHAN_INTR_ENA_RIE BIT(6)
#define DMA_CHAN_INTR_ENA_TIE BIT(0)
@@ -107,6 +109,8 @@ static inline u32 dma_chanx_base_addr(const struct dwmac4_addrs *addrs,
DMA_CHAN_INTR_ENA_TIE)
#define DMA_CHAN_INTR_ABNORMAL (DMA_CHAN_INTR_ENA_AIE | \
+ DMA_CHAN_INTR_ENA_RPS | \
+ DMA_CHAN_INTR_ENA_RBU | \
DMA_CHAN_INTR_ENA_FBE)
/* DMA default interrupt mask for 4.00 */
#define DMA_CHAN_INTR_DEFAULT_MASK (DMA_CHAN_INTR_NORMAL | \
@@ -117,6 +121,8 @@ static inline u32 dma_chanx_base_addr(const struct dwmac4_addrs *addrs,
DMA_CHAN_INTR_ENA_TIE)
#define DMA_CHAN_INTR_ABNORMAL_4_10 (DMA_CHAN_INTR_ENA_AIE_4_10 | \
+ DMA_CHAN_INTR_ENA_RPS | \
+ DMA_CHAN_INTR_ENA_RBU | \
DMA_CHAN_INTR_ENA_FBE)
/* DMA default interrupt mask for 4.10a */
#define DMA_CHAN_INTR_DEFAULT_MASK_4_10 (DMA_CHAN_INTR_NORMAL_4_10 | \
--
2.47.3
^ permalink raw reply related
* [PATCH 3/4] pinctrl: vt8500: Enable compile testing
From: Krzysztof Kozlowski @ 2026-04-10 13:04 UTC (permalink / raw)
To: Linus Walleij, Andreas Färber
Cc: linux-gpio, linux-kernel, Andrew Jeffery, linux-aspeed, openbmc,
linux-arm-kernel, Joel Stanley, linux-realtek-soc, James Tai,
Yu-Chun Lin, Krzysztof Kozlowski
In-Reply-To: <20260410-pinctrl-testing-v1-0-6f708c855867@oss.qualcomm.com>
Enable compile testing for Realtek pin controller drivers for increased
build and static checkers coverage. PINCTRL_WMT uses
gpiochip_get_data(), thus needs GPIOLIB.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
drivers/pinctrl/Makefile | 2 +-
drivers/pinctrl/vt8500/Kconfig | 13 +++++++------
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index 9320ffae5f31..78135ee963db 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -97,4 +97,4 @@ obj-y += tegra/
obj-y += ti/
obj-$(CONFIG_PINCTRL_UNIPHIER) += uniphier/
obj-$(CONFIG_PINCTRL_VISCONTI) += visconti/
-obj-$(CONFIG_ARCH_VT8500) += vt8500/
+obj-$(CONFIG_PINCTRL_WMT) += vt8500/
diff --git a/drivers/pinctrl/vt8500/Kconfig b/drivers/pinctrl/vt8500/Kconfig
index 2ca00b54b7a8..1a40c153a82a 100644
--- a/drivers/pinctrl/vt8500/Kconfig
+++ b/drivers/pinctrl/vt8500/Kconfig
@@ -3,16 +3,17 @@
# VIA/Wondermedia PINCTRL drivers
#
-if ARCH_VT8500
+if ARCH_VT8500 || COMPILE_TEST
config PINCTRL_WMT
bool
select PINMUX
select GENERIC_PINCONF
+ select GPIOLIB
config PINCTRL_VT8500
bool "VIA VT8500 pin controller driver"
- depends on ARCH_WM8505
+ depends on ARCH_WM8505 || COMPILE_TEST
select PINCTRL_WMT
help
Say yes here to support the gpio/pin control module on
@@ -20,7 +21,7 @@ config PINCTRL_VT8500
config PINCTRL_WM8505
bool "Wondermedia WM8505 pin controller driver"
- depends on ARCH_WM8505
+ depends on ARCH_WM8505 || COMPILE_TEST
select PINCTRL_WMT
help
Say yes here to support the gpio/pin control module on
@@ -28,7 +29,7 @@ config PINCTRL_WM8505
config PINCTRL_WM8650
bool "Wondermedia WM8650 pin controller driver"
- depends on ARCH_WM8505
+ depends on ARCH_WM8505 || COMPILE_TEST
select PINCTRL_WMT
help
Say yes here to support the gpio/pin control module on
@@ -36,7 +37,7 @@ config PINCTRL_WM8650
config PINCTRL_WM8750
bool "Wondermedia WM8750 pin controller driver"
- depends on ARCH_WM8750
+ depends on ARCH_WM8750 || COMPILE_TEST
select PINCTRL_WMT
help
Say yes here to support the gpio/pin control module on
@@ -44,7 +45,7 @@ config PINCTRL_WM8750
config PINCTRL_WM8850
bool "Wondermedia WM8850 pin controller driver"
- depends on ARCH_WM8850
+ depends on ARCH_WM8850 || COMPILE_TEST
select PINCTRL_WMT
help
Say yes here to support the gpio/pin control module on
--
2.51.0
^ permalink raw reply related
* [PATCH 4/4] ARM: realtek: MAINTAINERS: Include pin controller drivers
From: Krzysztof Kozlowski @ 2026-04-10 13:04 UTC (permalink / raw)
To: Linus Walleij, Andreas Färber
Cc: linux-gpio, linux-kernel, Andrew Jeffery, linux-aspeed, openbmc,
linux-arm-kernel, Joel Stanley, linux-realtek-soc, James Tai,
Yu-Chun Lin, Krzysztof Kozlowski
In-Reply-To: <20260410-pinctrl-testing-v1-0-6f708c855867@oss.qualcomm.com>
No dedicated maintainers are shown for Realtek SoC pin controllers,
except pinctrl subsystem maintainer, which means reduced review and
impression of abandoned drivers. Pin controller drivers are essential
part of an SoC, so in case of lack of dedicated entry at least cover it
by the SoC platform maintainers.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
This patch should go via Realtek SoC maintainers, not pinctrl.
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 10d12b51b1f6..374ce55e4fb6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3373,6 +3373,7 @@ F: Documentation/devicetree/bindings/arm/realtek.yaml
F: arch/arm/boot/dts/realtek/
F: arch/arm/mach-realtek/
F: arch/arm64/boot/dts/realtek/
+F: drivers/pinctrl/realtek/
ARM/RISC-V/RENESAS ARCHITECTURE
M: Geert Uytterhoeven <geert+renesas@glider.be>
--
2.51.0
^ permalink raw reply related
* [PATCH 2/4] pinctrl: aspeed: Enable compile testing outside of ARCH_ASPEED
From: Krzysztof Kozlowski @ 2026-04-10 13:04 UTC (permalink / raw)
To: Linus Walleij, Andreas Färber
Cc: linux-gpio, linux-kernel, Andrew Jeffery, linux-aspeed, openbmc,
linux-arm-kernel, Joel Stanley, linux-realtek-soc, James Tai,
Yu-Chun Lin, Krzysztof Kozlowski
In-Reply-To: <20260410-pinctrl-testing-v1-0-6f708c855867@oss.qualcomm.com>
Since inception in commit 4d3d0e4272d8 ("pinctrl: Add core support for
Aspeed SoCs"), the Aspeed pin controller drivers cannot be compile
tested, unless ARCH_ASPEED is selected. . That partially defeats the
purpose of compile testing, since ARCH_ASPEED is pulled when building
platform kernels.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
drivers/pinctrl/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index b054cfb99348..9320ffae5f31 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -66,7 +66,7 @@ obj-$(CONFIG_PINCTRL_ZYNQMP) += pinctrl-zynqmp.o
obj-$(CONFIG_PINCTRL_ZYNQ) += pinctrl-zynq.o
obj-y += actions/
-obj-$(CONFIG_ARCH_ASPEED) += aspeed/
+obj-$(CONFIG_PINCTRL_ASPEED) += aspeed/
obj-y += bcm/
obj-$(CONFIG_PINCTRL_BERLIN) += berlin/
obj-y += cirrus/
--
2.51.0
^ permalink raw reply related
* [PATCH 1/4] pinctrl: realtek: Enable compile testing
From: Krzysztof Kozlowski @ 2026-04-10 13:04 UTC (permalink / raw)
To: Linus Walleij, Andreas Färber
Cc: linux-gpio, linux-kernel, Andrew Jeffery, linux-aspeed, openbmc,
linux-arm-kernel, Joel Stanley, linux-realtek-soc, James Tai,
Yu-Chun Lin, Krzysztof Kozlowski
In-Reply-To: <20260410-pinctrl-testing-v1-0-6f708c855867@oss.qualcomm.com>
Enable compile testing for Realtek pin controller drivers for increased
build and static checkers coverage. PINCTRL_RTD uses
pinconf_generic_dt_node_to_map(), thus needs OF.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
drivers/pinctrl/Makefile | 2 +-
drivers/pinctrl/realtek/Kconfig | 12 ++++++------
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index 9d33fa28a096..b054cfb99348 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -82,7 +82,7 @@ obj-y += nuvoton/
obj-y += nxp/
obj-$(CONFIG_PINCTRL_PXA) += pxa/
obj-y += qcom/
-obj-$(CONFIG_ARCH_REALTEK) += realtek/
+obj-$(CONFIG_PINCTRL_RTD) += realtek/
obj-$(CONFIG_PINCTRL_RENESAS) += renesas/
obj-$(CONFIG_PINCTRL_SAMSUNG) += samsung/
obj-y += sophgo/
diff --git a/drivers/pinctrl/realtek/Kconfig b/drivers/pinctrl/realtek/Kconfig
index 054e85db99e7..a156c4ef556e 100644
--- a/drivers/pinctrl/realtek/Kconfig
+++ b/drivers/pinctrl/realtek/Kconfig
@@ -2,8 +2,8 @@
config PINCTRL_RTD
tristate "Realtek DHC core pin controller driver"
- depends on ARCH_REALTEK
- default y
+ depends on ARCH_REALTEK || (COMPILE_TEST && OF)
+ default ARCH_REALTEK
select PINMUX
select GENERIC_PINCONF
select REGMAP_MMIO
@@ -11,22 +11,22 @@ config PINCTRL_RTD
config PINCTRL_RTD1619B
tristate "Realtek DHC 1619B pin controller driver"
depends on PINCTRL_RTD
- default y
+ default ARCH_REALTEK
config PINCTRL_RTD1319D
tristate "Realtek DHC 1319D pin controller driver"
depends on PINCTRL_RTD
- default y
+ default ARCH_REALTEK
config PINCTRL_RTD1315E
tristate "Realtek DHC 1315E pin controller driver"
depends on PINCTRL_RTD
- default y
+ default ARCH_REALTEK
config PINCTRL_RTD1625
tristate "Realtek DHC 1625 pin controller driver"
depends on PINCTRL_RTD
- default y
+ default ARCH_REALTEK
help
This driver enables support for the pin controller on the Realtek
RTD1625 SoCs.
--
2.51.0
^ permalink raw reply related
* [PATCH 0/4] pinctrl: More compile testing
From: Krzysztof Kozlowski @ 2026-04-10 13:04 UTC (permalink / raw)
To: Linus Walleij, Andreas Färber
Cc: linux-gpio, linux-kernel, Andrew Jeffery, linux-aspeed, openbmc,
linux-arm-kernel, Joel Stanley, linux-realtek-soc, James Tai,
Yu-Chun Lin, Krzysztof Kozlowski
Follows https://lore.kernel.org/r/20260410103005.163128-2-krzysztof.kozlowski@oss.qualcomm.com/
but should not depend on it anyhow.
More compile testing means better bot coverage. Plus having ||
COMPILE_TEST and obj-CONFIG_ARCH_FOO is kind of pointless.
I built these on arm, arm64, i386, x86_64, sparc, m68k, s390, riscv and
powerpc. Branch is pushed also to LKP, so more build tests will follow.
Best regards,
Krzysztof
---
Krzysztof Kozlowski (4):
pinctrl: realtek: Enable compile testing
pinctrl: aspeed: Enable compile testing outside of ARCH_ASPEED
pinctrl: vt8500: Enable compile testing
ARM: realtek: MAINTAINERS: Include pin controller drivers
MAINTAINERS | 1 +
drivers/pinctrl/Makefile | 6 +++---
drivers/pinctrl/realtek/Kconfig | 12 ++++++------
drivers/pinctrl/vt8500/Kconfig | 13 +++++++------
4 files changed, 17 insertions(+), 15 deletions(-)
---
base-commit: a53c56fc5daedea57de51c02ede0b48f055fd8b3
change-id: 20260410-pinctrl-testing-10edae894600
Best regards,
--
Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v5 4/4] arm64: errata: Work around early CME DVMSync acknowledgement
From: Catalin Marinas @ 2026-04-10 12:55 UTC (permalink / raw)
To: Will Deacon; +Cc: linux-arm-kernel, James Morse, Mark Rutland, Mark Brown
In-Reply-To: <adjohQBfrHVc1HIh@willie-the-truck>
On Fri, Apr 10, 2026 at 01:09:41PM +0100, Will Deacon wrote:
> On Tue, Apr 07, 2026 at 11:28:44AM +0100, Catalin Marinas wrote:
> > diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
> > index 489554931231..4c328b7c79ba 100644
> > --- a/arch/arm64/kernel/process.c
> > +++ b/arch/arm64/kernel/process.c
> > @@ -26,6 +26,7 @@
> > #include <linux/reboot.h>
> > #include <linux/interrupt.h>
> > #include <linux/init.h>
> > +#include <linux/cpumask.h>
> > #include <linux/cpu.h>
> > #include <linux/elfcore.h>
> > #include <linux/pm.h>
> > @@ -339,8 +340,41 @@ void flush_thread(void)
> > flush_gcs();
> > }
> >
> > +#ifdef CONFIG_ARM64_ERRATUM_4193714
> > +
> > +static void arch_dup_tlbbatch_mask(struct task_struct *dst)
> > +{
> > + /*
> > + * Clear the inherited cpumask with memset() to cover both cases where
> > + * cpumask_var_t is a pointer or an array. It will be allocated lazily
> > + * in sme_dvmsync_add_pending() if CPUMASK_OFFSTACK=y.
> > + */
> > + if (alternative_has_cap_unlikely(ARM64_WORKAROUND_4193714))
> > + memset(&dst->tlb_ubc.arch.cpumask, 0,
> > + sizeof(dst->tlb_ubc.arch.cpumask));
>
> nit: use cpumask_clear() instead?
I tried to explain in the comment above. The memset() is on purpose to
avoid #ifdef CPUMASK_OFFSTACK. When enabled, cpumask_var_t is a pointer
and we want it set to NULL (for later lazy allocation) rather than
clearing the parent's cpumask. I had the diff below initially but it
looked uglier. Or we make the erratum dependent on !CPUMASK_OFFSTACK but
it won't get compile coverage with defconfig.
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index 4c328b7c79ba..9294cbd35cce 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -345,13 +345,18 @@ void flush_thread(void)
static void arch_dup_tlbbatch_mask(struct task_struct *dst)
{
/*
- * Clear the inherited cpumask with memset() to cover both cases where
- * cpumask_var_t is a pointer or an array. It will be allocated lazily
- * in sme_dvmsync_add_pending() if CPUMASK_OFFSTACK=y.
+ * Don't inherit the parent's tlbbatch cpumask.
+ *
+ * With CPUMASK_OFFSTACK=y, cpumask_var_t is a pointer. Reset it so
+ * that it will be allocated lazily in sme_dvmsync_add_pending().
*/
- if (alternative_has_cap_unlikely(ARM64_WORKAROUND_4193714))
- memset(&dst->tlb_ubc.arch.cpumask, 0,
- sizeof(dst->tlb_ubc.arch.cpumask));
+ if (alternative_has_cap_unlikely(ARM64_WORKAROUND_4193714)) {
+#ifdef CONFIG_CPUMASK_OFFSTACK
+ dst->tlb_ubc.arch.cpumask = NULL;
+#else
+ cpumask_clear(dst->tlb_ubc.arch.cpumask);
+#endif
+ }
}
static void arch_release_tlbbatch_mask(struct task_struct *tsk)
--
Catalin
^ permalink raw reply related
* Re: [PATCH net-next v3 02/12] net: airoha: Set PPE cpu port for GDM2 if loopback is enabled
From: Lorenzo Bianconi @ 2026-04-10 12:52 UTC (permalink / raw)
To: Jakub Kicinski
Cc: andrew+netdev, davem, edumazet, pabeni, robh, krzk+dt, conor+dt,
ansuelsmth, benjamin.larsson, linux-arm-kernel, linux-mediatek,
netdev, devicetree
In-Reply-To: <20260410025720.1809934-1-kuba@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 3218 bytes --]
> This is an AI-generated review of your patch. The human sending this
> email says "For your consideration."
> ---
> net: airoha: Move airoha_qdma pointer in airoha_gdm_dev struct
>
> This commit moves the airoha_qdma pointer from the airoha_gdm_port struct
> to the airoha_gdm_dev struct. This ensures the QDMA block used depends on
> the specific net_device WAN/LAN configuration.
>
> [ ... ]
>
> > --- a/drivers/net/ethernet/airoha/airoha_eth.c
> > +++ b/drivers/net/ethernet/airoha/airoha_eth.c
>
> [ ... ]
>
> > @@ -1497,9 +1498,10 @@ static void airoha_qdma_stop_napi(struct airoha_qdma *qdma)
> > }
> > }
> >
> > -static void airoha_update_hw_stats(struct airoha_gdm_port *port)
> > +static void airoha_update_hw_stats(struct airoha_gdm_dev *dev)
> > {
> > - struct airoha_eth *eth = port->qdma->eth;
> > + struct airoha_gdm_port *port = dev->port;
> > + struct airoha_eth *eth = dev->eth;
> > u32 val, i = 0;
> >
> > spin_lock(&port->stats.lock);
>
> This isn't a bug introduced by this patch, but does this spin_lock()
> carry a deadlock risk?
>
> Because ndo_get_stats64() can be called from atomic context (e.g., from a
> softirq), if a process context caller holds port->stats.lock and is
> interrupted by a softirq on the same CPU that also triggers dev_get_stats(),
> the softirq could spin forever waiting for the lock.
>
> Should this be upgraded to spin_lock_bh() to ensure local softirqs are
> disabled during the critical section?
I was not able to spot any point in the networking stack where
ndo_get_stats64 callback is run from a softirq. Moreover,
airoha_update_hw_stats() is never executed in any napi in airoha_eth
driver. It seems to me spin_lock() is enough here. Am I missing something?
>
> [ ... ]
>
> > --- a/drivers/net/ethernet/airoha/airoha_eth.h
> > +++ b/drivers/net/ethernet/airoha/airoha_eth.h
> > @@ -534,12 +534,12 @@ struct airoha_qdma {
> >
> > struct airoha_gdm_dev {
> > struct airoha_gdm_port *port;
> > + struct airoha_qdma *qdma;
> > struct net_device *dev;
> > struct airoha_eth *eth;
> > };
> >
> > struct airoha_gdm_port {
> > - struct airoha_qdma *qdma;
> > struct airoha_gdm_dev *dev;
> > int id;
>
> This isn't a bug introduced by this patch, but since the qdma pointer
> is being moved to better align with the hardware structure, should
> qos_sq_bmap, cpu_tx_packets, and fwd_tx_packets be moved to
> struct airoha_qdma as well?
>
> Because QDMA1 is shared by all WAN ports (GDM 2, 3, 4) and qos_sq_bmap
> is currently tracked per-port instead of per-QDMA, each WAN port
> independently allocates QDMA1 channels starting from index 0. Does this
> cause different ports to overwrite each other's hardware QoS configurations
> in the shared QDMA1 block?
>
> Furthermore, cpu_tx_packets and fwd_tx_packets cache per-channel ETS
> hardware counters but are single u64 scalar variables in the port structure.
> When querying stats for multiple channels, do these scalar caches get
> overwritten with values from completely different channels, resulting in
> incorrect delta calculations?
ack, I will fix it in v4.
Regards,
Lorenzo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH] mailbox: prefix new constants with MBOX_
From: Wolfram Sang @ 2026-04-10 12:49 UTC (permalink / raw)
To: linux-renesas-soc, Jassi Brar
Cc: Wolfram Sang, Peter Chen, Fugang Duan,
CIX Linux Kernel Upstream Group, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Matthias Brugger,
AngeloGioacchino Del Regno, Thierry Reding, Jonathan Hunter,
linux-arm-kernel, imx, linux-mediatek, linux-tegra
Commit 89e5d7d61600 ("mailbox: remove superfluous internal header")
moved some constants to a public header but forgot to add a mailbox
specific prefix. Add this now to prevent future collisions on a too
generic naming.
Link: https://sashiko.dev/#/patchset/20260327151112.5202-2-wsa%2Brenesas%40sang-engineering.com
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
This patch improves the above mentioned commit which already sits in
-next. It is not really a fix but it probably is still a good idea to
apply it before rc1 to avoid confusion.
drivers/mailbox/cix-mailbox.c | 2 +-
drivers/mailbox/imx-mailbox.c | 2 +-
drivers/mailbox/mailbox.c | 22 +++++++++++-----------
drivers/mailbox/mtk-cmdq-mailbox.c | 2 +-
drivers/mailbox/omap-mailbox.c | 2 +-
drivers/mailbox/tegra-hsp.c | 2 +-
include/linux/mailbox_controller.h | 6 +++---
7 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/mailbox/cix-mailbox.c b/drivers/mailbox/cix-mailbox.c
index 8cfaa91b75bd..43c76cdab24a 100644
--- a/drivers/mailbox/cix-mailbox.c
+++ b/drivers/mailbox/cix-mailbox.c
@@ -413,7 +413,7 @@ static int cix_mbox_startup(struct mbox_chan *chan)
switch (cp->type) {
case CIX_MBOX_TYPE_DB:
/* Overwrite txdone_method for DB channel */
- chan->txdone_method = TXDONE_BY_ACK;
+ chan->txdone_method = MBOX_TXDONE_BY_ACK;
fallthrough;
case CIX_MBOX_TYPE_REG:
if (priv->dir == CIX_MBOX_TX) {
diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
index 22331b579489..246a9a9e3952 100644
--- a/drivers/mailbox/imx-mailbox.c
+++ b/drivers/mailbox/imx-mailbox.c
@@ -732,7 +732,7 @@ static struct mbox_chan * imx_mu_xlate(struct mbox_controller *mbox,
p_chan = &mbox->chans[chan];
if (type == IMX_MU_TYPE_TXDB_V2)
- p_chan->txdone_method = TXDONE_BY_ACK;
+ p_chan->txdone_method = MBOX_TXDONE_BY_ACK;
return p_chan;
}
diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c
index 138ffbcd4fde..30eafdf3a91e 100644
--- a/drivers/mailbox/mailbox.c
+++ b/drivers/mailbox/mailbox.c
@@ -72,7 +72,7 @@ static void msg_submit(struct mbox_chan *chan)
}
}
- if (!err && (chan->txdone_method & TXDONE_BY_POLL)) {
+ if (!err && (chan->txdone_method & MBOX_TXDONE_BY_POLL)) {
/* kick start the timer immediately to avoid delays */
scoped_guard(spinlock_irqsave, &chan->mbox->poll_hrt_lock)
hrtimer_start(&chan->mbox->poll_hrt, 0, HRTIMER_MODE_REL);
@@ -162,7 +162,7 @@ EXPORT_SYMBOL_GPL(mbox_chan_received_data);
*/
void mbox_chan_txdone(struct mbox_chan *chan, int r)
{
- if (unlikely(!(chan->txdone_method & TXDONE_BY_IRQ))) {
+ if (unlikely(!(chan->txdone_method & MBOX_TXDONE_BY_IRQ))) {
dev_err(chan->mbox->dev,
"Controller can't run the TX ticker\n");
return;
@@ -183,7 +183,7 @@ EXPORT_SYMBOL_GPL(mbox_chan_txdone);
*/
void mbox_client_txdone(struct mbox_chan *chan, int r)
{
- if (unlikely(!(chan->txdone_method & TXDONE_BY_ACK))) {
+ if (unlikely(!(chan->txdone_method & MBOX_TXDONE_BY_ACK))) {
dev_err(chan->mbox->dev, "Client can't run the TX ticker\n");
return;
}
@@ -344,8 +344,8 @@ static int __mbox_bind_client(struct mbox_chan *chan, struct mbox_client *cl)
chan->cl = cl;
init_completion(&chan->tx_complete);
- if (chan->txdone_method == TXDONE_BY_POLL && cl->knows_txdone)
- chan->txdone_method = TXDONE_BY_ACK;
+ if (chan->txdone_method == MBOX_TXDONE_BY_POLL && cl->knows_txdone)
+ chan->txdone_method = MBOX_TXDONE_BY_ACK;
}
if (chan->mbox->ops->startup) {
@@ -499,8 +499,8 @@ void mbox_free_channel(struct mbox_chan *chan)
scoped_guard(spinlock_irqsave, &chan->lock) {
chan->cl = NULL;
chan->active_req = MBOX_NO_MSG;
- if (chan->txdone_method == TXDONE_BY_ACK)
- chan->txdone_method = TXDONE_BY_POLL;
+ if (chan->txdone_method == MBOX_TXDONE_BY_ACK)
+ chan->txdone_method = MBOX_TXDONE_BY_POLL;
}
module_put(chan->mbox->dev->driver->owner);
@@ -531,13 +531,13 @@ int mbox_controller_register(struct mbox_controller *mbox)
return -EINVAL;
if (mbox->txdone_irq)
- txdone = TXDONE_BY_IRQ;
+ txdone = MBOX_TXDONE_BY_IRQ;
else if (mbox->txdone_poll)
- txdone = TXDONE_BY_POLL;
+ txdone = MBOX_TXDONE_BY_POLL;
else /* It has to be ACK then */
- txdone = TXDONE_BY_ACK;
+ txdone = MBOX_TXDONE_BY_ACK;
- if (txdone == TXDONE_BY_POLL) {
+ if (txdone == MBOX_TXDONE_BY_POLL) {
if (!mbox->ops->last_tx_done) {
dev_err(mbox->dev, "last_tx_done method is absent\n");
diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c b/drivers/mailbox/mtk-cmdq-mailbox.c
index 547a10a8fad3..e523c84b4808 100644
--- a/drivers/mailbox/mtk-cmdq-mailbox.c
+++ b/drivers/mailbox/mtk-cmdq-mailbox.c
@@ -728,7 +728,7 @@ static int cmdq_probe(struct platform_device *pdev)
cmdq->mbox.ops = &cmdq_mbox_chan_ops;
cmdq->mbox.of_xlate = cmdq_xlate;
- /* make use of TXDONE_BY_ACK */
+ /* make use of MBOX_TXDONE_BY_ACK */
cmdq->mbox.txdone_irq = false;
cmdq->mbox.txdone_poll = false;
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index 5772c6b9886a..535ca8020877 100644
--- a/drivers/mailbox/omap-mailbox.c
+++ b/drivers/mailbox/omap-mailbox.c
@@ -238,7 +238,7 @@ static int omap_mbox_startup(struct omap_mbox *mbox)
}
if (mbox->send_no_irq)
- mbox->chan->txdone_method = TXDONE_BY_ACK;
+ mbox->chan->txdone_method = MBOX_TXDONE_BY_ACK;
omap_mbox_enable_irq(mbox, IRQ_RX);
diff --git a/drivers/mailbox/tegra-hsp.c b/drivers/mailbox/tegra-hsp.c
index 7b1e1b83ea29..500fa77c7d53 100644
--- a/drivers/mailbox/tegra-hsp.c
+++ b/drivers/mailbox/tegra-hsp.c
@@ -514,7 +514,7 @@ static int tegra_hsp_mailbox_startup(struct mbox_chan *chan)
struct tegra_hsp *hsp = mb->channel.hsp;
unsigned long flags;
- chan->txdone_method = TXDONE_BY_IRQ;
+ chan->txdone_method = MBOX_TXDONE_BY_IRQ;
/*
* Shared mailboxes start out as consumers by default. FULL and EMPTY
diff --git a/include/linux/mailbox_controller.h b/include/linux/mailbox_controller.h
index e3896b08f22e..a49ee687d4cf 100644
--- a/include/linux/mailbox_controller.h
+++ b/include/linux/mailbox_controller.h
@@ -15,9 +15,9 @@ struct mbox_chan;
/* Sentinel value distinguishing "no active request" from "NULL message data" */
#define MBOX_NO_MSG ((void *)-1)
-#define TXDONE_BY_IRQ BIT(0) /* controller has remote RTR irq */
-#define TXDONE_BY_POLL BIT(1) /* controller can read status of last TX */
-#define TXDONE_BY_ACK BIT(2) /* S/W ACK received by Client ticks the TX */
+#define MBOX_TXDONE_BY_IRQ BIT(0) /* controller has remote RTR irq */
+#define MBOX_TXDONE_BY_POLL BIT(1) /* controller can read status of last TX */
+#define MBOX_TXDONE_BY_ACK BIT(2) /* S/W ACK received by Client ticks the TX */
/**
* struct mbox_chan_ops - methods to control mailbox channels
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v3 0/4] mm: improve large folio readahead and alignment for exec memory
From: Lorenzo Stoakes @ 2026-04-10 12:24 UTC (permalink / raw)
To: Usama Arif
Cc: Andrew Morton, david, willy, ryan.roberts, linux-mm, r, jack, ajd,
apopple, baohua, baolin.wang, brauner, catalin.marinas, dev.jain,
kees, kevin.brodsky, lance.yang, Liam.Howlett, linux-arm-kernel,
linux-fsdevel, linux-kernel, mhocko, npache, pasha.tatashin,
rmclure, rppt, surenb, vbabka, Al Viro, ziy, hannes, kas,
shakeel.butt, leitao, kernel-team
In-Reply-To: <5f99b289-629c-47c4-bef0-966d6678a2a8@linux.dev>
On Fri, Apr 10, 2026 at 01:19:08PM +0100, Usama Arif wrote:
>
>
> On 10/04/2026 12:57, Lorenzo Stoakes wrote:
> > On Fri, Apr 10, 2026 at 12:55:42PM +0100, Lorenzo Stoakes wrote:
> >> On Fri, Apr 10, 2026 at 12:03:03PM +0100, Usama Arif wrote:
> >>>
> >>>
> >>> On 02/04/2026 19:08, Usama Arif wrote:
> >>>> v2 -> v3: https://lore.kernel.org/all/20260320140315.979307-1-usama.arif@linux.dev/
> >>>> - Take into account READ_ONLY_THP_FOR_FS for elf alignment by aligning
> >>>> to HPAGE_PMD_SIZE limited to 2M (Rui)
> >>>> - Reviewed-by tags for patch 1 from Kiryl and Jan
> >>>> - Remove preferred_exec_order() (Jan)
> >>>> - Change ra->order to HPAGE_PMD_ORDER if vma_pages(vma) >= HPAGE_PMD_NR
> >>>> otherwise use exec_folio_order() with gfp &= ~__GFP_RECLAIM for
> >>>> do_sync_mmap_readahead().
> >>>> - Change exec_folio_order() to return 2M (cont-pte size) for 64K base
> >>>> page size for arm64.
> >>>> - remove bprm->file NULL check (Matthew)
> >>>> - Change filp to file (Matthew)
> >>>> - Improve checking of p_vaddr and p_vaddr (Rui and Matthew)
> >>>>
> >>>
> >>> Hello!
> >>>
> >>> Just wanted to check if there was any feedback/review on the latest
> >>> revision?
> >>
> >> It's -rc7, this is definitely something for next cycle :)
> >>
> >> On my part, my upstream bandwidth has drastically reduced, and review is
> >> probably going to have to be a hobbyist thing at least for now.
> >>
> >> Also, not to be mean but:
> >>
> >> $ git log -E -i --grep "(Reviewed|Acked)-by: Usama Arif" --oneline | wc -l
> >> 21
> >>
> >> So... :)
> >>
> >> Review in mm is very lop-sided, let's try to balance it out a bit!
> >>
> >>>
> >>> Thanks!
> >>>
> >>
> >> Thanks, Lorenzo
> >
> > (Note that we're in a 'quiet period' from here until -rc1 of next cycle and
> > won't be taking anything new until then. We plan to do this from around rc5 or
> > rc6 of each cycle in future).
>
> Thanks! Just wanted to check, as I am always confused about this. Is it ok
> to send patches for review for next release at this time? So that they
> are in a good state when rc1 comes. I wanted to send PMD swap entries
> for review after I am finished testing, but I want them for review for
> next release.
I think different people have different views on that :)
I mean it's debateable whether having a glut of new material on day one of -rc1
is preferable to having a bunch come in that might or might not get lost along
the way :)
I personally feel it'd be better to send during the cycle window rather than
before but I suspect others disagree with that!
So from your point of view, feel free to do what you like, but maybe David +
others would want to chime in with their opinions?
Thanks, Lorenzo
^ permalink raw reply
* Re: [PATCH net v4 0/2] stmmac crash/stall fixes when under memory pressure
From: Russell King (Oracle) @ 2026-04-10 12:23 UTC (permalink / raw)
To: Sam Edwards
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Maxime Coquelin, Alexandre Torgue, Maxime Chevallier,
Ovidiu Panait, Vladimir Oltean, Baruch Siach, Serge Semin,
Giuseppe Cavallaro, netdev, linux-stm32, linux-arm-kernel,
linux-kernel
In-Reply-To: <CAH5Ym4g3pbU_bWzMwJMdhEFv4K2sp3pty3g04=0=9Z80_LzW1w@mail.gmail.com>
On Thu, Apr 02, 2026 at 10:39:32AM -0700, Sam Edwards wrote:
> On Thu, Apr 2, 2026 at 10:16 AM Russell King (Oracle)
> <linux@armlinux.org.uk> wrote:
> > I've tested this on my Jetson Xavier platform. One of the issues I've
> > had is that running iperf3 results in the receive side stalling because
> > it runs out of descriptors. However, despite the receive ring
> > eventually being re-filled and the hardware appropriately prodded, it
> > steadfastly refuses to restart, despite the descriptors having been
> > updated.
>
> Hi Russell,
>
> Just to make sure I understand correctly: before my patches, you've
> been observing this problem on Xavier for a while (no interrupts, ring
> goes dry); with my patches, the ring is refilled, but the dwmac5
> doesn't resume DMA. (Ah, just saw your follow-up email.)
>
> > Any ideas?
>
> Off the top of my head, my hypothesis is that dwmac5 has an additional
> tripwire when the receive DMA is exhausted, and the
> stmmac_set_rx_tail_ptr()/stmmac_enable_dma_reception() at the end of
> stmmac_rx_refill() aren't sufficient to wake it back up.
>
> I think this is new to dwmac5, because my RK3588 (dwmac4.20 iirc)
> happily resumes after the same condition.
>
> You gave a lot of info; thanks! I'll try to scrape up some
> documentation on dwmac5 to see if there's something more
> stmmac_rx_refill() ought to be doing. I think I have a Xavier NX
> around here somewhere, I'll see if I can repro the problem.
I've added dma_rmb() into dwmac4_wrback_get_tx_status() and
dwmac4_wrback_get_rx_status(), and with that I've had an iperf3
instance finally complete... but only once:
root@tegra-ubuntu:~# iperf3 -c 192.168.248.1 -R
Connecting to host 192.168.248.1, port 5201
Reverse mode, remote host 192.168.248.1 is sending
[ 5] local 192.168.248.174 port 42232 connected to 192.168.248.1 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 50.8 MBytes 426 Mbits/sec
[ 5] 1.00-2.00 sec 54.9 MBytes 460 Mbits/sec
[ 5] 2.00-3.00 sec 54.0 MBytes 453 Mbits/sec
[ 5] 3.00-4.00 sec 53.8 MBytes 452 Mbits/sec
[ 5] 4.00-5.00 sec 52.4 MBytes 438 Mbits/sec
[ 5] 5.00-6.00 sec 54.3 MBytes 455 Mbits/sec
[ 5] 6.00-7.00 sec 53.7 MBytes 452 Mbits/sec
[ 5] 7.00-8.00 sec 52.8 MBytes 443 Mbits/sec
[ 5] 8.00-9.00 sec 53.7 MBytes 451 Mbits/sec
[ 5] 9.00-10.00 sec 54.3 MBytes 455 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.01 sec 537 MBytes 450 Mbits/sec 13 sender
[ 5] 0.00-10.00 sec 535 MBytes 448 Mbits/sec receiver
iperf Done.
So, it seems better, but not completely solved.
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
index 2994df41ec2c..119f31c94b61 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
@@ -17,10 +17,12 @@ static int dwmac4_wrback_get_tx_status(struct stmmac_extra_stats *x,
struct dma_desc *p,
void __iomem *ioaddr)
{
- u32 tdes3 = le32_to_cpu(p->des3);
+ u32 tdes3;
int ret = tx_done;
/* Get tx owner first */
+ dma_rmb();
+ tdes3 = le32_to_cpu(p->des3);
if (unlikely(tdes3 & TDES3_OWN))
return tx_dma_own;
@@ -70,12 +72,12 @@ static int dwmac4_wrback_get_tx_status(struct stmmac_extra_stats *x,
static int dwmac4_wrback_get_rx_status(struct stmmac_extra_stats *x,
struct dma_desc *p)
{
- u32 rdes1 = le32_to_cpu(p->des1);
- u32 rdes2 = le32_to_cpu(p->des2);
- u32 rdes3 = le32_to_cpu(p->des3);
+ u32 rdes1, rdes2, rdes3;
int message_type;
int ret = good_frame;
+ dma_rmb();
+ rdes3 = le32_to_cpu(p->des3);
if (unlikely(rdes3 & RDES3_OWN))
return dma_own;
@@ -107,6 +109,7 @@ static int dwmac4_wrback_get_rx_status(struct stmmac_extra_stats *x,
message_type = FIELD_GET(RDES1_PTP_MSG_TYPE_MASK, rdes1);
+ rdes1 = le32_to_cpu(p->des1);
if (rdes1 & RDES1_IP_HDR_ERROR) {
x->ip_hdr_err++;
ret |= csum_none;
@@ -152,6 +155,7 @@ static int dwmac4_wrback_get_rx_status(struct stmmac_extra_stats *x,
if (rdes1 & RDES1_TIMESTAMP_DROPPED)
x->timestamp_dropped++;
+ rdes2 = le32_to_cpu(p->des2);
if (unlikely(rdes2 & RDES2_SA_FILTER_FAIL)) {
x->sa_rx_filter_fail++;
ret = discard_frame;
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply related
* [patch 38/38] treewide: Remove asm/timex.h includes from generic code
From: Thomas Gleixner @ 2026-04-10 12:21 UTC (permalink / raw)
To: LKML
Cc: Arnd Bergmann, x86, Lu Baolu, iommu, Michael Grzeschik, netdev,
linux-wireless, Herbert Xu, linux-crypto, Vlastimil Babka,
linux-mm, David Woodhouse, Bernie Thompson, linux-fbdev,
Theodore Tso, linux-ext4, Andrew Morton, Uladzislau Rezki,
Marco Elver, Dmitry Vyukov, kasan-dev, Andrey Ryabinin,
Thomas Sailer, linux-hams, Jason A. Donenfeld, Richard Henderson,
linux-alpha, Russell King, linux-arm-kernel, Catalin Marinas,
Huacai Chen, loongarch, Geert Uytterhoeven, linux-m68k,
Dinh Nguyen, Jonas Bonn, linux-openrisc, Helge Deller,
linux-parisc, Michael Ellerman, linuxppc-dev, Paul Walmsley,
linux-riscv, Heiko Carstens, linux-s390, David S. Miller,
sparclinux
In-Reply-To: <20260410120044.031381086@kernel.org>
asm/timex.h does not provide any functionality for non-architecture code
anymore.
Remove the asm-generic fallback and all references in include and source
files along with the random_get_entropy() #ifdeffery in timex.h.
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
---
include/asm-generic/Kbuild | 1 -
include/asm-generic/timex.h | 15 ---------------
include/linux/random.h | 3 +++
include/linux/timex.h | 26 --------------------------
kernel/time/timer.c | 1 -
lib/interval_tree_test.c | 1 -
lib/rbtree_test.c | 1 -
7 files changed, 3 insertions(+), 45 deletions(-)
--- a/include/asm-generic/Kbuild
+++ b/include/asm-generic/Kbuild
@@ -56,7 +56,6 @@ mandatory-y += shmparam.h
mandatory-y += simd.h
mandatory-y += softirq_stack.h
mandatory-y += switch_to.h
-mandatory-y += timex.h
mandatory-y += tlbflush.h
mandatory-y += topology.h
mandatory-y += trace_clock.h
--- a/include/asm-generic/timex.h
+++ /dev/null
@@ -1,15 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-#ifndef __ASM_GENERIC_TIMEX_H
-#define __ASM_GENERIC_TIMEX_H
-
-/*
- * If you have a cycle counter, return the value here.
- */
-#ifndef get_cycles
-static inline cycles_t get_cycles(void)
-{
- return 0;
-}
-#endif
-
-#endif /* __ASM_GENERIC_TIMEX_H */
--- a/include/linux/random.h
+++ b/include/linux/random.h
@@ -1,3 +1,4 @@
+
/* SPDX-License-Identifier: GPL-2.0 */
#ifndef _LINUX_RANDOM_H
@@ -152,6 +153,8 @@ unsigned long random_get_entropy_fallbac
*/
#ifdef CONFIG_ARCH_HAS_RANDOM_ENTROPY
#include <asm/random.h>
+#else
+#define random_get_entropy() random_get_entropy_fallback()
#endif
#endif /* _LINUX_RANDOM_H */
--- a/include/linux/timex.h
+++ b/include/linux/timex.h
@@ -62,32 +62,6 @@
#include <linux/types.h>
#include <linux/param.h>
-unsigned long random_get_entropy_fallback(void);
-
-#include <asm/timex.h>
-
-#ifndef CONFIG_ARCH_HAS_RANDOM_ENTROPY
-#ifndef random_get_entropy
-/*
- * The random_get_entropy() function is used by the /dev/random driver
- * in order to extract entropy via the relative unpredictability of
- * when an interrupt takes places versus a high speed, fine-grained
- * timing source or cycle counter. Since it will be occurred on every
- * single interrupt, it must have a very low cost/overhead.
- *
- * By default we use get_cycles() for this purpose, but individual
- * architectures may override this in their asm/timex.h header file.
- * If a given arch does not have get_cycles(), then we fallback to
- * using random_get_entropy_fallback().
- */
-#ifdef get_cycles
-#define random_get_entropy() ((unsigned long)get_cycles())
-#else
-#define random_get_entropy() random_get_entropy_fallback()
-#endif
-#endif
-#endif
-
/*
* SHIFT_PLL is used as a dampening factor to define how much we
* adjust the frequency correction for a given offset in PLL mode.
--- a/kernel/time/timer.c
+++ b/kernel/time/timer.c
@@ -48,7 +48,6 @@
#include <linux/uaccess.h>
#include <asm/unistd.h>
#include <asm/div64.h>
-#include <asm/timex.h>
#include <asm/io.h>
#include "tick-internal.h"
--- a/lib/interval_tree_test.c
+++ b/lib/interval_tree_test.c
@@ -4,7 +4,6 @@
#include <linux/interval_tree.h>
#include <linux/prandom.h>
#include <linux/slab.h>
-#include <asm/timex.h>
#include <linux/bitmap.h>
#include <linux/maple_tree.h>
--- a/lib/rbtree_test.c
+++ b/lib/rbtree_test.c
@@ -4,7 +4,6 @@
#include <linux/rbtree_augmented.h>
#include <linux/prandom.h>
#include <linux/slab.h>
-#include <asm/timex.h>
#define __param(type, name, init, msg) \
static type name = init; \
^ permalink raw reply
* [patch 37/38] x86: Select ARCH_HAS_RANDOM_ENTROPY
From: Thomas Gleixner @ 2026-04-10 12:21 UTC (permalink / raw)
To: LKML
Cc: x86, Arnd Bergmann, Lu Baolu, iommu, Michael Grzeschik, netdev,
linux-wireless, Herbert Xu, linux-crypto, Vlastimil Babka,
linux-mm, David Woodhouse, Bernie Thompson, linux-fbdev,
Theodore Tso, linux-ext4, Andrew Morton, Uladzislau Rezki,
Marco Elver, Dmitry Vyukov, kasan-dev, Andrey Ryabinin,
Thomas Sailer, linux-hams, Jason A. Donenfeld, Richard Henderson,
linux-alpha, Russell King, linux-arm-kernel, Catalin Marinas,
Huacai Chen, loongarch, Geert Uytterhoeven, linux-m68k,
Dinh Nguyen, Jonas Bonn, linux-openrisc, Helge Deller,
linux-parisc, Michael Ellerman, linuxppc-dev, Paul Walmsley,
linux-riscv, Heiko Carstens, linux-s390, David S. Miller,
sparclinux
In-Reply-To: <20260410120044.031381086@kernel.org>
The only remaining usage of get_cycles() is to provide random_get_entropy().
Switch x86 over to the new scheme of selecting ARCH_HAS_RANDOM_ENTROPY and
providing random_get_entropy() in asm/random.h.
Remove asm/timex.h as it has no functionality anymore.
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Cc: x86@kernel.org
---
arch/x86/Kconfig | 1 +
arch/x86/include/asm/random.h | 16 ++++++++++++++++
arch/x86/include/asm/timex.h | 17 -----------------
arch/x86/include/asm/tsc.h | 9 ---------
4 files changed, 17 insertions(+), 26 deletions(-)
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -101,6 +101,7 @@ config X86
select ARCH_HAS_PREEMPT_LAZY
select ARCH_HAS_PTDUMP
select ARCH_HAS_PTE_SPECIAL
+ select ARCH_HAS_RANDOM_ENTROPY
select ARCH_HAS_HW_PTE_YOUNG
select ARCH_HAS_NONLEAF_PMD_YOUNG if PGTABLE_LEVELS > 2
select ARCH_HAS_UACCESS_FLUSHCACHE if X86_64
--- /dev/null
+++ b/arch/x86/include/asm/random.h
@@ -0,0 +1,16 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_X86_RANDOM_H
+#define _ASM_X86_RANDOM_H
+
+#include <asm/processor.h>
+#include <asm/tsc.h>
+
+static inline unsigned long random_get_entropy(void)
+{
+ if (!IS_ENABLED(CONFIG_X86_TSC) &&
+ !cpu_feature_enabled(X86_FEATURE_TSC))
+ return random_get_entropy_fallback();
+ return rdtsc();
+}
+
+#endif /* _ASM_X86_RANDOM_H */
--- a/arch/x86/include/asm/timex.h
+++ /dev/null
@@ -1,17 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-#ifndef _ASM_X86_TIMEX_H
-#define _ASM_X86_TIMEX_H
-
-#include <asm/processor.h>
-#include <asm/tsc.h>
-
-static inline unsigned long random_get_entropy(void)
-{
- if (!IS_ENABLED(CONFIG_X86_TSC) &&
- !cpu_feature_enabled(X86_FEATURE_TSC))
- return random_get_entropy_fallback();
- return rdtsc();
-}
-#define random_get_entropy random_get_entropy
-
-#endif /* _ASM_X86_TIMEX_H */
--- a/arch/x86/include/asm/tsc.h
+++ b/arch/x86/include/asm/tsc.h
@@ -72,15 +72,6 @@ extern unsigned int tsc_khz;
extern void disable_TSC(void);
-static inline cycles_t get_cycles(void)
-{
- if (!IS_ENABLED(CONFIG_X86_TSC) &&
- !cpu_feature_enabled(X86_FEATURE_TSC))
- return 0;
- return rdtsc();
-}
-#define get_cycles get_cycles
-
extern void tsc_early_init(void);
extern void tsc_init(void);
extern void mark_tsc_unstable(char *reason);
^ permalink raw reply
* [patch 35/38] s390: Select ARCH_HAS_RANDOM_ENTROPY
From: Thomas Gleixner @ 2026-04-10 12:21 UTC (permalink / raw)
To: LKML
Cc: Heiko Carstens, linux-s390, Arnd Bergmann, x86, Lu Baolu, iommu,
Michael Grzeschik, netdev, linux-wireless, Herbert Xu,
linux-crypto, Vlastimil Babka, linux-mm, David Woodhouse,
Bernie Thompson, linux-fbdev, Theodore Tso, linux-ext4,
Andrew Morton, Uladzislau Rezki, Marco Elver, Dmitry Vyukov,
kasan-dev, Andrey Ryabinin, Thomas Sailer, linux-hams,
Jason A. Donenfeld, Richard Henderson, linux-alpha, Russell King,
linux-arm-kernel, Catalin Marinas, Huacai Chen, loongarch,
Geert Uytterhoeven, linux-m68k, Dinh Nguyen, Jonas Bonn,
linux-openrisc, Helge Deller, linux-parisc, Michael Ellerman,
linuxppc-dev, Paul Walmsley, linux-riscv, David S. Miller,
sparclinux
In-Reply-To: <20260410120044.031381086@kernel.org>
The only remaining non-architecture usage of get_cycles() is to provide
random_get_entropy().
Switch s390 over to the new scheme of selecting ARCH_HAS_RANDOM_ENTROPY and
providing random_get_entropy() in asm/random.h.
Add 'asm/timex.h' includes to the relevant files, so the global include can
be removed once all architectures are converted over.
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: linux-s390@vger.kernel.org
---
arch/s390/Kconfig | 1 +
arch/s390/include/asm/random.h | 12 ++++++++++++
arch/s390/include/asm/timex.h | 6 ------
arch/s390/kernel/time.c | 1 +
arch/s390/kernel/vtime.c | 1 +
5 files changed, 15 insertions(+), 6 deletions(-)
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -108,6 +108,7 @@ config S390
select ARCH_HAS_PREEMPT_LAZY
select ARCH_HAS_PTDUMP
select ARCH_HAS_PTE_SPECIAL
+ select ARCH_HAS_RANDOM_ENTROPY
select ARCH_HAS_SCALED_CPUTIME
select ARCH_HAS_SET_DIRECT_MAP
select ARCH_HAS_SET_MEMORY
--- /dev/null
+++ b/arch/s390/include/asm/random.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_S390_RANDOM_H
+#define _ASM_S390_RANDOM_H
+
+#include <asm/timex.h>
+
+static inline unsigned long random_get_entropy(void)
+{
+ return (unsigned long)get_tod_clock_monotonic() >> 2;
+}
+
+#endif
--- a/arch/s390/include/asm/timex.h
+++ b/arch/s390/include/asm/timex.h
@@ -219,12 +219,6 @@ static inline unsigned long get_tod_cloc
return tod;
}
-static inline cycles_t get_cycles(void)
-{
- return (cycles_t)get_tod_clock_monotonic() >> 2;
-}
-#define get_cycles get_cycles
-
/**
* tod_to_ns - convert a TOD format value to nanoseconds
* @todval: to be converted TOD format value
--- a/arch/s390/kernel/time.c
+++ b/arch/s390/kernel/time.c
@@ -50,6 +50,7 @@
#include <asm/irq_regs.h>
#include <asm/vtimer.h>
#include <asm/stp.h>
+#include <asm/timex.h>
#include <asm/cio.h>
#include "entry.h"
--- a/arch/s390/kernel/vtime.c
+++ b/arch/s390/kernel/vtime.c
@@ -14,6 +14,7 @@
#include <linux/time.h>
#include <asm/alternative.h>
#include <asm/cputime.h>
+#include <asm/timex.h>
#include <asm/vtimer.h>
#include <asm/vtime.h>
#include <asm/cpu_mf.h>
^ permalink raw reply
* [patch 36/38] sparc: Select ARCH_HAS_RANDOM_ENTROPY for SPARC64
From: Thomas Gleixner @ 2026-04-10 12:21 UTC (permalink / raw)
To: LKML
Cc: David S. Miller, sparclinux, Arnd Bergmann, x86, Lu Baolu, iommu,
Michael Grzeschik, netdev, linux-wireless, Herbert Xu,
linux-crypto, Vlastimil Babka, linux-mm, David Woodhouse,
Bernie Thompson, linux-fbdev, Theodore Tso, linux-ext4,
Andrew Morton, Uladzislau Rezki, Marco Elver, Dmitry Vyukov,
kasan-dev, Andrey Ryabinin, Thomas Sailer, linux-hams,
Jason A. Donenfeld, Richard Henderson, linux-alpha, Russell King,
linux-arm-kernel, Catalin Marinas, Huacai Chen, loongarch,
Geert Uytterhoeven, linux-m68k, Dinh Nguyen, Jonas Bonn,
linux-openrisc, Helge Deller, linux-parisc, Michael Ellerman,
linuxppc-dev, Paul Walmsley, linux-riscv, Heiko Carstens,
linux-s390
In-Reply-To: <20260410120044.031381086@kernel.org>
The only remaining usage of get_cycles() is to provide random_get_entropy().
Switch sparc over to the new scheme of selecting ARCH_HAS_RANDOM_ENTROPY
and providing random_get_entropy() in asm/random.h.
Remove asm/timex*.h as it has no functionality anymore.
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: sparclinux@vger.kernel.org
---
arch/sparc/Kconfig | 1 +
arch/sparc/include/asm/random.h | 15 +++++++++++++++
arch/sparc/include/asm/timex.h | 9 ---------
arch/sparc/include/asm/timex_64.h | 15 ---------------
arch/sparc/kernel/pcic.c | 1 -
arch/sparc/kernel/time_32.c | 1 -
arch/sparc/vdso/vclock_gettime.c | 1 -
7 files changed, 16 insertions(+), 27 deletions(-)
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -71,6 +71,7 @@ config SPARC64
def_bool 64BIT
select ALTERNATE_USER_ADDRESS_SPACE
select ARCH_HAS_DELAY_TIMER
+ select ARCH_HAS_RANDOM_ENTROPY
select HAVE_FUNCTION_TRACER
select HAVE_FUNCTION_GRAPH_TRACER
select HAVE_KRETPROBES
--- /dev/null
+++ b/arch/sparc/include/asm/random.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef _ASMsparc_RANDOM_H
+#define _ASMsparc_RANDOM_H
+
+#if defined(__sparc__) && defined(__arch64__)
+
+#include <asm/timer.h>
+
+static inline unsigned long random_get_entropy(void)
+{
+ return tick_ops->get_tick();
+}
+
+#endif
+#endif
--- a/arch/sparc/include/asm/timex.h
+++ /dev/null
@@ -1,9 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-#ifndef ___ASM_SPARC_TIMEX_H
-#define ___ASM_SPARC_TIMEX_H
-#if defined(__sparc__) && defined(__arch64__)
-#include <asm/timex_64.h>
-#else
-#include <asm-generic/timex.h>
-#endif
-#endif
--- a/arch/sparc/include/asm/timex_64.h
+++ b/arch/sparc/include/asm/timex_64.h
@@ -1,15 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-/*
- * linux/include/asm/timex.h
- *
- * sparc64 architecture timex specifications
- */
-#ifndef _ASMsparc64_TIMEX_H
-#define _ASMsparc64_TIMEX_H
-
-#include <asm/timer.h>
-
-/* Getting on the cycle counter on sparc64. */
-#define get_cycles() tick_ops->get_tick()
-
-#endif
--- a/arch/sparc/kernel/pcic.c
+++ b/arch/sparc/kernel/pcic.c
@@ -33,7 +33,6 @@
#include <asm/oplib.h>
#include <asm/prom.h>
#include <asm/pcic.h>
-#include <asm/timex.h>
#include <asm/timer.h>
#include <linux/uaccess.h>
#include <asm/irq_regs.h>
--- a/arch/sparc/kernel/time_32.c
+++ b/arch/sparc/kernel/time_32.c
@@ -37,7 +37,6 @@
#include <asm/mc146818rtc.h>
#include <asm/oplib.h>
-#include <asm/timex.h>
#include <asm/timer.h>
#include <asm/irq.h>
#include <asm/io.h>
--- a/arch/sparc/vdso/vclock_gettime.c
+++ b/arch/sparc/vdso/vclock_gettime.c
@@ -17,7 +17,6 @@
#include <linux/string.h>
#include <asm/io.h>
#include <asm/unistd.h>
-#include <asm/timex.h>
#include <asm/clocksource.h>
#include <asm/vvar.h>
^ permalink raw reply
* [patch 34/38] riscv: Select ARCH_HAS_RANDOM_ENTROPY
From: Thomas Gleixner @ 2026-04-10 12:21 UTC (permalink / raw)
To: LKML
Cc: Paul Walmsley, linux-riscv, Arnd Bergmann, x86, Lu Baolu, iommu,
Michael Grzeschik, netdev, linux-wireless, Herbert Xu,
linux-crypto, Vlastimil Babka, linux-mm, David Woodhouse,
Bernie Thompson, linux-fbdev, Theodore Tso, linux-ext4,
Andrew Morton, Uladzislau Rezki, Marco Elver, Dmitry Vyukov,
kasan-dev, Andrey Ryabinin, Thomas Sailer, linux-hams,
Jason A. Donenfeld, Richard Henderson, linux-alpha, Russell King,
linux-arm-kernel, Catalin Marinas, Huacai Chen, loongarch,
Geert Uytterhoeven, linux-m68k, Dinh Nguyen, Jonas Bonn,
linux-openrisc, Helge Deller, linux-parisc, Michael Ellerman,
linuxppc-dev, Heiko Carstens, linux-s390, David S. Miller,
sparclinux
In-Reply-To: <20260410120044.031381086@kernel.org>
The only remaining non-architecture usage of get_cycles() is to provide
random_get_entropy().
Switch riscv over to the new scheme of selecting ARCH_HAS_RANDOM_ENTROPY
and providing random_get_entropy() in asm/random.h.
Add 'asm/timex.h' includes to the relevant files, so the global include can
be removed once all architectures are converted over.
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Cc: Paul Walmsley <pjw@kernel.org>
Cc: linux-riscv@lists.infradead.org
---
arch/riscv/Kconfig | 1 +
arch/riscv/include/asm/random.h | 25 +++++++++++++++++++++++++
arch/riscv/include/asm/timex.h | 13 -------------
arch/riscv/kernel/unaligned_access_speed.c | 1 +
arch/riscv/kvm/vcpu_timer.c | 1 +
arch/riscv/lib/delay.c | 1 +
6 files changed, 29 insertions(+), 13 deletions(-)
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -47,6 +47,7 @@ config RISCV
select ARCH_HAS_PREPARE_SYNC_CORE_CMD
select ARCH_HAS_PTDUMP if MMU
select ARCH_HAS_PTE_SPECIAL
+ select ARCH_HAS_RANDOM_ENTROPY
select ARCH_HAS_SET_DIRECT_MAP if MMU
select ARCH_HAS_SET_MEMORY if MMU
select ARCH_HAS_STRICT_KERNEL_RWX if MMU && !XIP_KERNEL
--- /dev/null
+++ b/arch/riscv/include/asm/random.h
@@ -0,0 +1,25 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef _ASM_RISCV_RANDOM_H
+#define _ASM_RISCV_RANDOM_H
+
+#include <asm/timex.h>
+
+#ifdef CONFIG_RISCV_M_MODE
+/*
+ * Much like MIPS, we may not have a viable counter to use at an early point
+ * in the boot process. Unfortunately we don't have a fallback, so instead
+ * invoke the fallback function.
+ */
+static inline unsigned long random_get_entropy(void)
+{
+ if (unlikely(clint_time_val == NULL))
+ return random_get_entropy_fallback();
+ return get_cycles();
+}
+#else /* !CONFIG_RISCV_M_MODE */
+static inline unsigned long random_get_entropy(void)
+{
+ return get_cycles();
+}
+#endif /* CONFIG_RISCV_M_MODE */
+#endif /* _ASM_RISCV_RANDOM_H */
--- a/arch/riscv/include/asm/timex.h
+++ b/arch/riscv/include/asm/timex.h
@@ -31,19 +31,6 @@ static inline u32 get_cycles_hi(void)
#define get_cycles_hi get_cycles_hi
#endif /* CONFIG_64BIT */
-/*
- * Much like MIPS, we may not have a viable counter to use at an early point
- * in the boot process. Unfortunately we don't have a fallback, so instead
- * we just return 0.
- */
-static inline unsigned long random_get_entropy(void)
-{
- if (unlikely(clint_time_val == NULL))
- return random_get_entropy_fallback();
- return get_cycles();
-}
-#define random_get_entropy() random_get_entropy()
-
#else /* CONFIG_RISCV_M_MODE */
static inline cycles_t get_cycles(void)
--- a/arch/riscv/kernel/unaligned_access_speed.c
+++ b/arch/riscv/kernel/unaligned_access_speed.c
@@ -12,6 +12,7 @@
#include <linux/types.h>
#include <asm/cpufeature.h>
#include <asm/hwprobe.h>
+#include <asm/timex.h>
#include <asm/vector.h>
#include "copy-unaligned.h"
--- a/arch/riscv/kvm/vcpu_timer.c
+++ b/arch/riscv/kvm/vcpu_timer.c
@@ -14,6 +14,7 @@
#include <asm/delay.h>
#include <asm/kvm_nacl.h>
#include <asm/kvm_vcpu_timer.h>
+#include <asm/timex.h>
static u64 kvm_riscv_current_cycles(struct kvm_guest_timer *gt)
{
--- a/arch/riscv/lib/delay.c
+++ b/arch/riscv/lib/delay.c
@@ -10,6 +10,7 @@
#include <linux/export.h>
#include <asm/processor.h>
+#include <asm/timex.h>
/*
* This is copies from arch/arm/include/asm/delay.h
^ 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