* Re: [LTP] [PATCH] set_mempolicy05: require CONFIG_NUMA
From: Andrea Cervesato via ltp @ 2026-06-25 7:01 UTC (permalink / raw)
To: Avinesh Kumar; +Cc: Linux Test Project
In-Reply-To: <e082e001-88b9-47be-952d-642e293dd229@suse.com>
> But I also think that we should add
> CONFIG_NUMA=y check in all these tests. Please confirm, I will send
> revised version.
Yes please, let's fix them all already.
Thanks,
--
Andrea Cervesato
SUSE QE Automation Engineer Linux
andrea.cervesato@suse.com
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply
* Re: [f2fs-dev] [PATCH 10/16] fs/buffer: Remove fs-layer decryption code
From: Christian Brauner via Linux-f2fs-devel @ 2026-06-25 7:01 UTC (permalink / raw)
To: Eric Biggers
Cc: Ritesh Harjani, Theodore Ts'o, Zhang Yi, linux-f2fs-devel,
linux-block, linux-fscrypt, Andreas Dilger, Ojaswin Mujoo,
Baokun Li, Jaegeuk Kim, linux-fsdevel, Jan Kara, linux-ext4,
Christoph Hellwig
In-Reply-To: <20260624050334.124606-11-ebiggers@kernel.org>
On 2026-06-23 22:03 -0700, Eric Biggers wrote:
> Now that fscrypt's file contents en/decryption is always implemented
> using blk-crypto when the filesystem is block-based, the fs-layer
> decryption code in fs/buffer.c is unused code. Remove it.
>
> Signed-off-by: Eric Biggers <ebiggers@kernel.org>
> ---
Reviewed-by: Christian Brauner (Amutable) <brauner@kernel.org>
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply
* Re: [PATCH 10/16] fs/buffer: Remove fs-layer decryption code
From: Christian Brauner @ 2026-06-25 7:01 UTC (permalink / raw)
To: Eric Biggers
Cc: linux-fscrypt, linux-fsdevel, linux-ext4, linux-f2fs-devel,
linux-block, Christoph Hellwig, Theodore Ts'o, Andreas Dilger,
Baokun Li, Jan Kara, Ojaswin Mujoo, Ritesh Harjani, Zhang Yi,
Jaegeuk Kim, Chao Yu
In-Reply-To: <20260624050334.124606-11-ebiggers@kernel.org>
On 2026-06-23 22:03 -0700, Eric Biggers wrote:
> Now that fscrypt's file contents en/decryption is always implemented
> using blk-crypto when the filesystem is block-based, the fs-layer
> decryption code in fs/buffer.c is unused code. Remove it.
>
> Signed-off-by: Eric Biggers <ebiggers@kernel.org>
> ---
Reviewed-by: Christian Brauner (Amutable) <brauner@kernel.org>
^ permalink raw reply
* Re: [OE-core] [PATCH] sanity.bbclass: warn on .cargo/config.toml outside the build tree
From: Hemanth Kumar M D @ 2026-06-25 7:01 UTC (permalink / raw)
To: Paul Barker, openembedded-core; +Cc: Randy.MacLeod, Sundeep.Kokkonda
In-Reply-To: <f9be9a387e024dc86312a45e2a4b029e5cbf2ec2.camel@pbarker.dev>
On 24-06-2026 01:11 pm, Paul Barker wrote:
> On Tue, 2026-06-23 at 23:42 -0700, Hemanth Kumar M D via
> lists.openembedded.org wrote:
>> From: Hemanth Kumar M D <Hemanth.KumarMD@windriver.com>
>>
>> Cargo walks from CWD up to the filesystem root merging every
>> .cargo/config.toml it finds. Any such file above TOPDIR is silently
>> picked up and can override Yocto's linker, registry or compiler
>> settings, leading to build failures.
>>
>> Until cargo provides a proper fix upstream, add a warning so users
>> get a clear diagnostic instead of a build error.
>>
>> Upstream meta-issue: https://github.com/rust-lang/cargo/issues/9769
>>
>> [YOCTO #15637]
>>
>> Signed-off-by: Hemanth Kumar M D <Hemanth.KumarMD@windriver.com>
>> ---
>> meta/classes-global/sanity.bbclass | 33 ++++++++++++++++++++++++++++++
>> 1 file changed, 33 insertions(+)
>>
>> diff --git a/meta/classes-global/sanity.bbclass b/meta/classes-global/sanity.bbclass
>> index bdfa7f059d..c67c7b8f03 100644
>> --- a/meta/classes-global/sanity.bbclass
>> +++ b/meta/classes-global/sanity.bbclass
>> @@ -854,6 +854,38 @@ def sanity_check_locale(d):
>> except locale.Error:
>> raise_sanity_error("Your system needs to support the en_US.UTF-8 locale.", d)
>>
>> +def check_cargo_config(d):
>> + # Cargo merges .cargo/config.toml from every directory between CWD and
>> + # the filesystem root. Warn for anything found in ancestor directories
>> + # above TOPDIR that Cargo would pick up silently.
>> + import os
>> +
>> + topdir = d.getVar('TOPDIR')
Hi Paul,
Thanks for the review!
please find the v2 -
https://lists.openembedded.org/g/openembedded-core/topic/patch_v2_sanity_bbclass/119970000
> TMPDIR and each package's WORKDIR are under TOPDIR by default, but this
> can be overridden. Perhaps we should be checking ancestors of
> BASE_WORKDIR instead.
Agreed, updated to use BASE_WORKDIR in v2.
>> + ancestor = os.path.dirname(topdir)
>> + found = []
>> + last_ancestor = None
>> + while True:
>> + for name in ('config.toml', 'config'):
>> + cfg = os.path.join(ancestor, '.cargo', name)
>> + if os.path.exists(cfg):
>> + found.append(cfg)
>> + last_ancestor = ancestor
>> + break
> This `break` should be dropped so that we tell the user about all
> offending Cargo config files.
Keeping the `break` ,
Cargo docs say if both 'config' and 'config.toml'
exist in the same directory, only 'config' is read. So only one file per
directory is ever active. I've also fixed the probe order to check
'config'
before 'config.toml' to match this.
Ref: https://doc.rust-lang.org/cargo/reference/config.html
> The rest of this patch LGTM, thanks!
>
> Best regards,
>
--
Regards,
Hemanth Kumar M D
^ permalink raw reply
* Re: [PATCH v2 06/17] x86/virt/tdx: Re-initialize the extensions on runtime TDX module update
From: Xu Yilun @ 2026-06-25 7:01 UTC (permalink / raw)
To: sashiko-reviews; +Cc: kvm
In-Reply-To: <20260618085835.98A041F000E9@smtp.kernel.org>
> > + return tdx_ext_init();
>
> [Severity: Critical]
> Could this result in an infinite loop during a runtime update?
>
> The tdx_module_run_update() function runs under stop_machine(), meaning
> local interrupts are explicitly disabled. When this calls tdx_ext_init(),
> it executes the following polling loop:
>
> do {
> r = seamcall(TDH_EXT_INIT, &args);
> } while (r == TDX_INTERRUPTED_RESUMABLE);
>
> If an external hardware interrupt becomes pending during the update, the TDX
> module exits to the host and returns TDX_INTERRUPTED_RESUMABLE. Because the
> host CPU has interrupts disabled, it cannot service the interrupt and simply
> continues execution.
>
> Does this mean the loop condition evaluates to true, immediately re-executing
> the seamcall, and permanently deadlocking the system?
No, According to TDX module SPEC [1], 5.4.1. SEAMCALL Instruction (Common),
RAX[bit 24] == 0 shows "Pending interrupts are detected only if the host
VMM’s RFLAGS.IF is 1." Linux now doesn't set this bit for any SEAMCALL.
That means SEAMCALLs will keep on executing if host disabled interrupts
so will not deadlock the system.
[1] https://cdrdv2.intel.com/v1/dl/getContent/795381
^ permalink raw reply
* Re: [PATCH 0/3] iio: light: al3xxx: add missing REGMAP_I2C to Kconfig entries
From: Andy Shevchenko @ 2026-06-25 7:01 UTC (permalink / raw)
To: Joshua Crofts
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Svyatoslav Ryhel, David Heidelberg, linux-iio, linux-kernel
In-Reply-To: <20260625085329.00007959@gmail.com>
On Thu, Jun 25, 2026 at 08:53:29AM +0200, Joshua Crofts wrote:
> On Thu, 25 Jun 2026 09:41:31 +0300
> Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> > On Thu, Jun 25, 2026 at 07:20:42AM +0200, Joshua Crofts wrote:
> > > This series adds REGMAP_I2C support to three AL3xxx ambient light
> > > sensors that were previously missing this dependency, causing build
> > > failures.
> >
> > There are two problems with the commit message:
> > - SELECT versus select (see the comment against patch 1)
> > - you mentioned build failures but haven't provided any evidence, please
> > provide a reasonable lines of build output to prove that
> Sure, I could elaborate a bit more.
>
> Just run `make allnoconfig` and `make menuconfig` in which you select
> IIO, I2C and any AL3xxx sensor and `make .` will fail with errors such as
>
> drivers/iio/light/al3010.c: In function ‘al3010_probe’:
> drivers/iio/light/al3010.c:185:24: error: implicit declaration of function ‘devm_regmap_init_i2c’ [-Wimplicit-function-declaration]
> 185 | data->regmap = devm_regmap_init_i2c(client, &al3010_regmap_config);
> | ^~~~~~~~~~~~~~~~~~~~
> drivers/iio/light/al3010.c:185:22: error: assignment to ‘struct regmap *’ from ‘int’ makes pointer from integer without a cast [-Wint-conversion]
> 185 | data->regmap = devm_regmap_init_i2c(client, &al3010_regmap_config);
> | ^
> drivers/iio/light/al3010.c: At top level:
> drivers/iio/light/al3010.c:48:35: error: storage size of ‘al3010_regmap_config’ isn’t known
> 48 | static const struct regmap_config al3010_regmap_config = {
> | ^~~~~~~~~~~~~~~~~~~~
>
> Hopefully this is enough.
Yes, put it into the cover letter of the v2.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v8 34/46] KVM: selftests: Test conversion before allocation
From: Fuad Tabba @ 2026-06-25 7:00 UTC (permalink / raw)
To: ackerleytng
Cc: aik, andrew.jones, binbin.wu, brauner, chao.p.peng, david,
jmattson, jthoughton, michael.roth, oupton, pankaj.gupta, qperret,
rick.p.edgecombe, rientjes, shivankg, steven.price, willy, wyihan,
yan.y.zhao, forkloop, pratyush, suzuki.poulose, aneesh.kumar,
liam, Paolo Bonzini, Sean Christopherson, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Jonathan Corbet, Shuah Khan, Shuah Khan, Vishal Annapurve,
Andrew Morton, Chris Li, Kairui Song, Kemeng Shi, Nhat Pham,
Barry Song, Axel Rasmussen, Yuanchu Xie, Wei Xu, Youngjun Park,
Qi Zheng, Shakeel Butt, Kiryl Shutsemau, Baoquan He,
Jason Gunthorpe, Vlastimil Babka, kvm, linux-kernel,
linux-trace-kernel, linux-doc, linux-kselftest, linux-mm,
linux-coco
In-Reply-To: <20260618-gmem-inplace-conversion-v8-34-9d2959357853@google.com>
On Fri, 19 Jun 2026 at 01:32, Ackerley Tng via B4 Relay
<devnull+ackerleytng.google.com@kernel.org> wrote:
>
> From: Ackerley Tng <ackerleytng@google.com>
>
> Add two test cases to the guest_memfd conversions selftest to cover
> the scenario where a conversion is requested before any memory has been
> allocated in the guest_memfd region.
>
> The KVM_SET_MEMORY_ATTRIBUTES2 ioctl can be called on a memory region at
> any time. If the guest had not yet faulted in any pages for that region,
> the kernel must record the conversion request and apply the requested state
> when the pages are eventually allocated.
>
> The new tests cover both conversion directions.
>
> Signed-off-by: Ackerley Tng <ackerleytng@google.com>
> Co-developed-by: Sean Christopherson <seanjc@google.com>
> Signed-off-by: Sean Christopherson <seanjc@google.com>
Reviewed-by: Fuad Tabba <tabba@google.com>
Cheers,
/fuad
> ---
> .../selftests/kvm/x86/guest_memfd_conversions_test.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/tools/testing/selftests/kvm/x86/guest_memfd_conversions_test.c b/tools/testing/selftests/kvm/x86/guest_memfd_conversions_test.c
> index 8e17d5c08aeb8..b43ac196330f1 100644
> --- a/tools/testing/selftests/kvm/x86/guest_memfd_conversions_test.c
> +++ b/tools/testing/selftests/kvm/x86/guest_memfd_conversions_test.c
> @@ -265,6 +265,20 @@ GMEM_CONVERSION_MULTIPAGE_TEST_INIT_SHARED(indexing, 4)
> #undef combine
> }
>
> +/*
> + * Test that even if there are no folios yet, conversion requests are recorded
> + * in guest_memfd.
> + */
> +GMEM_CONVERSION_TEST_INIT_SHARED(before_allocation_shared)
> +{
> + test_convert_to_private(t, 0, 0, 'A');
> +}
> +
> +GMEM_CONVERSION_TEST_INIT_PRIVATE(before_allocation_private)
> +{
> + test_convert_to_shared(t, 0, 0, 'A', 'B');
> +}
> +
> int main(int argc, char *argv[])
> {
> TEST_REQUIRE(kvm_check_cap(KVM_CAP_VM_TYPES) & BIT(KVM_X86_SW_PROTECTED_VM));
>
> --
> 2.55.0.rc0.738.g0c8ab3ebcc-goog
>
>
^ permalink raw reply
* Re: [PATCH] mm/rmap: use huge_ptep_get() in try_to_unmap_one()
From: Dev Jain @ 2026-06-25 6:59 UTC (permalink / raw)
To: kernel test robot, akpm, david, ljs
Cc: llvm, oe-kbuild-all, riel, liam, vbabka, harry, jannh, kas,
linux-mm, linux-kernel, ryan.roberts, anshuman.khandual, stable
In-Reply-To: <202606251341.jfIr1D7m-lkp@intel.com>
On 25/06/26 11:15 am, kernel test robot wrote:
> Hi Dev,
>
> kernel test robot noticed the following build errors:
>
> [auto build test ERROR on akpm-mm/mm-everything]
>
> url: https://github.com/intel-lab-lkp/linux/commits/Dev-Jain/mm-rmap-use-huge_ptep_get-in-try_to_unmap_one/20260625-123050
> base: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-everything
> patch link: https://lore.kernel.org/r/20260625042853.2752898-1-dev.jain%40arm.com
> patch subject: [PATCH] mm/rmap: use huge_ptep_get() in try_to_unmap_one()
> config: hexagon-allnoconfig (https://download.01.org/0day-ci/archive/20260625/202606251341.jfIr1D7m-lkp@intel.com/config)
> compiler: clang version 23.0.0git (https://github.com/llvm/llvm-project 6cc609bb250b21b47fc7d394b4019101e9983597)
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260625/202606251341.jfIr1D7m-lkp@intel.com/reproduce)
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp@intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202606251341.jfIr1D7m-lkp@intel.com/
>
> All errors (new ones prefixed by >>):
>
>>> mm/rmap.c:2100:13: error: call to undeclared function 'huge_ptep_get'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
> 2100 | pteval = huge_ptep_get(mm, address, pvmw.pte);
> | ^
>>> mm/rmap.c:2100:11: error: assigning to 'pte_t' from incompatible type 'int'
> 2100 | pteval = huge_ptep_get(mm, address, pvmw.pte);
> | ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 2 errors generated.
Weird that I need a stub. This should do:
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 2abaf99321e90..4661f88eee55b 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -1261,6 +1261,16 @@ static inline void hugetlb_count_sub(long l, struct mm_struct *mm)
{
}
+static inline pte_t huge_ptep_get(struct mm_struct *mm, unsigned long addr,
+ pte_t *ptep)
+{
+#ifdef CONFIG_MMU
+ return ptep_get(ptep);
+#else
+ return *ptep;
+#endif
+}
+
static inline pte_t huge_ptep_clear_flush(struct vm_area_struct *vma,
unsigned long addr, pte_t *ptep)
{
diff --git a/mm/rmap.c b/mm/rmap.c
index 1c77d5dc06e9f..aa8a254efaecc 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -2095,11 +2095,16 @@ static bool try_to_unmap_one(struct folio *folio, struct vm_area_struct *vma,
/* Unexpected PMD-mapped THP? */
VM_BUG_ON_FOLIO(!pvmw.pte, folio);
- /*
- * Handle PFN swap PTEs, such as device-exclusive ones, that
- * actually map pages.
- */
- pteval = ptep_get(pvmw.pte);
+ address = pvmw.address;
+ if (folio_test_hugetlb(folio)) {
+ pteval = huge_ptep_get(mm, address, pvmw.pte);
+ } else {
+ /*
+ * Handle PFN swap PTEs, such as device-exclusive ones,
+ * that actually map pages.
+ */
+ pteval = ptep_get(pvmw.pte);
+ }
if (likely(pte_present(pteval))) {
pfn = pte_pfn(pteval);
} else {
@@ -2110,7 +2115,6 @@ static bool try_to_unmap_one(struct folio *folio, struct vm_area_struct *vma,
}
subpage = folio_page(folio, pfn - folio_pfn(folio));
- address = pvmw.address;
anon_exclusive = folio_test_anon(folio) &&
PageAnonExclusive(subpage);
^ permalink raw reply related
* [PATCH v2 net 3/3] net: udp_tunnel: use atomic bitops for missed bitmap
From: Eric Dumazet @ 2026-06-25 6:59 UTC (permalink / raw)
To: David S . Miller, Jakub Kicinski, Paolo Abeni
Cc: Simon Horman, Yue Sun, Stanislav Fomichev, netdev, eric.dumazet,
Eric Dumazet
In-Reply-To: <20260625065938.654652-1-edumazet@google.com>
The 'missed' bitmap in struct udp_tunnel_nic can be accessed
concurrently:
- Writes (__set_bit) happen in the port add path (add_port), which
holds the RTNL lock.
- Reads (checking if missed is non-zero) happen in the reset path
(reset_ntf) via __udp_tunnel_nic_device_sync(), which holds
utn->lock but does not hold RTNL after the blamed commit.
This setup creates a data race between concurrent writes and reads
on different CPUs. Fix this by using atomic set_bit() for writes,
READ_ONCE() for the fast-path read, and WRITE_ONCE() for clearing
the bitmap.
Fixes: 1ead7501094c ("udp_tunnel: remove rtnl_lock dependency")
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/ipv4/udp_tunnel_nic.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/udp_tunnel_nic.c b/net/ipv4/udp_tunnel_nic.c
index 840be5d79fc0ac3142049dcb9f1105a5844da9ae..9a567a87635caaf76f5b88029a7f28a65c795efc 100644
--- a/net/ipv4/udp_tunnel_nic.c
+++ b/net/ipv4/udp_tunnel_nic.c
@@ -147,7 +147,7 @@ udp_tunnel_nic_should_replay(struct net_device *dev, struct udp_tunnel_nic *utn)
const struct udp_tunnel_nic_table_info *table;
unsigned int i, j;
- if (!utn->missed)
+ if (!READ_ONCE(utn->missed))
return false;
for (i = 0; i < utn->n_tables; i++) {
@@ -353,7 +353,7 @@ udp_tunnel_nic_has_collision(struct net_device *dev, struct udp_tunnel_nic *utn,
if (!udp_tunnel_nic_entry_is_free(entry) &&
entry->port == ti->port &&
entry->type != ti->type) {
- __set_bit(i, &utn->missed);
+ set_bit(i, &utn->missed);
return true;
}
}
@@ -488,7 +488,7 @@ udp_tunnel_nic_add_new(struct net_device *dev, struct udp_tunnel_nic *utn,
* are no devices currently which have multiple tables accepting
* the same tunnel type, and false positives are okay.
*/
- __set_bit(i, &utn->missed);
+ set_bit(i, &utn->missed);
}
return false;
@@ -718,7 +718,7 @@ udp_tunnel_nic_replay(struct net_device *dev, struct udp_tunnel_nic *utn)
for (i = 0; i < utn->n_tables; i++)
for (j = 0; j < info->tables[i].n_entries; j++)
udp_tunnel_nic_entry_freeze_used(&utn->entries[i][j]);
- utn->missed = 0;
+ WRITE_ONCE(utn->missed, 0);
clear_bit(UDP_TUNNEL_NIC_NEED_REPLAY, &utn->flags);
if (!info->shared) {
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply related
* [PATCH v2 net 2/3] net: udp_tunnel: convert state flags to atomic bitops
From: Eric Dumazet @ 2026-06-25 6:59 UTC (permalink / raw)
To: David S . Miller, Jakub Kicinski, Paolo Abeni
Cc: Simon Horman, Yue Sun, Stanislav Fomichev, netdev, eric.dumazet,
Eric Dumazet
In-Reply-To: <20260625065938.654652-1-edumazet@google.com>
The state flags of struct udp_tunnel_nic (need_sync, need_replay,
work_pending) are currently bitfields sharing a single byte.
These flags can be modified concurrently from different contexts:
- RTNL-locked paths (like add_port/del_port) write to need_sync and
work_pending.
- The RTNL-less reset path (reset_ntf, used by netdevsim) writes to
need_sync and need_replay under utn->lock.
Since they share a byte, concurrent writes are compiled into non-atomic
Read-Modify-Write (RMW) operations that can corrupt each other. For
example, a write to need_replay in reset_ntf can overwrite and clear
work_pending, defeating the double-queueing prevention and causing UAF.
Fix this by converting these state flags to atomic bitops, ensuring
safe concurrent writes across RTNL-locked and RTNL-less paths.
Fixes: 1ead7501094c ("udp_tunnel: remove rtnl_lock dependency")
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/ipv4/udp_tunnel_nic.c | 43 ++++++++++++++++++++++-----------------
1 file changed, 24 insertions(+), 19 deletions(-)
diff --git a/net/ipv4/udp_tunnel_nic.c b/net/ipv4/udp_tunnel_nic.c
index 3b32a0afa9798d3c416d9ae570e6d529f70e6697..840be5d79fc0ac3142049dcb9f1105a5844da9ae 100644
--- a/net/ipv4/udp_tunnel_nic.c
+++ b/net/ipv4/udp_tunnel_nic.c
@@ -30,9 +30,7 @@ struct udp_tunnel_nic_table_entry {
* @work: async work for talking to hardware from process context
* @dev: netdev pointer
* @lock: protects all fields
- * @need_sync: at least one port start changed
- * @need_replay: space was freed, we need a replay of all ports
- * @work_pending: @work is currently scheduled
+ * @flags: sync, replay, pending flags
* @n_tables: number of tables under @entries
* @missed: bitmap of tables which overflown
* @entries: table of tables of ports currently offloaded
@@ -44,9 +42,10 @@ struct udp_tunnel_nic {
struct mutex lock;
- u8 need_sync:1;
- u8 need_replay:1;
- u8 work_pending:1;
+ unsigned long flags;
+#define UDP_TUNNEL_NIC_NEED_SYNC 0
+#define UDP_TUNNEL_NIC_NEED_REPLAY 1
+#define UDP_TUNNEL_NIC_WORK_PENDING 2
unsigned int n_tables;
unsigned long missed;
@@ -116,7 +115,7 @@ udp_tunnel_nic_entry_queue(struct udp_tunnel_nic *utn,
unsigned int flag)
{
entry->flags |= flag;
- utn->need_sync = 1;
+ set_bit(UDP_TUNNEL_NIC_NEED_SYNC, &utn->flags);
}
static void
@@ -283,7 +282,7 @@ udp_tunnel_nic_device_sync_by_table(struct net_device *dev,
static void
__udp_tunnel_nic_device_sync(struct net_device *dev, struct udp_tunnel_nic *utn)
{
- if (!utn->need_sync)
+ if (!test_bit(UDP_TUNNEL_NIC_NEED_SYNC, &utn->flags))
return;
if (dev->udp_tunnel_nic_info->sync_table)
@@ -291,21 +290,27 @@ __udp_tunnel_nic_device_sync(struct net_device *dev, struct udp_tunnel_nic *utn)
else
udp_tunnel_nic_device_sync_by_port(dev, utn);
- utn->need_sync = 0;
+ clear_bit(UDP_TUNNEL_NIC_NEED_SYNC, &utn->flags);
/* Can't replay directly here, in case we come from the tunnel driver's
* notification - trying to replay may deadlock inside tunnel driver.
*/
- utn->need_replay = udp_tunnel_nic_should_replay(dev, utn);
+ if (udp_tunnel_nic_should_replay(dev, utn))
+ set_bit(UDP_TUNNEL_NIC_NEED_REPLAY, &utn->flags);
+ else
+ clear_bit(UDP_TUNNEL_NIC_NEED_REPLAY, &utn->flags);
}
static void
udp_tunnel_nic_device_sync(struct net_device *dev, struct udp_tunnel_nic *utn)
{
- if (!utn->need_sync || utn->work_pending)
+ if (!test_bit(UDP_TUNNEL_NIC_NEED_SYNC, &utn->flags))
+ return;
+
+ if (test_bit(UDP_TUNNEL_NIC_WORK_PENDING, &utn->flags))
return;
queue_work(udp_tunnel_nic_workqueue, &utn->work);
- utn->work_pending = 1;
+ set_bit(UDP_TUNNEL_NIC_WORK_PENDING, &utn->flags);
}
static bool
@@ -552,7 +557,7 @@ static void __udp_tunnel_nic_reset_ntf(struct net_device *dev)
mutex_lock(&utn->lock);
- utn->need_sync = false;
+ clear_bit(UDP_TUNNEL_NIC_NEED_SYNC, &utn->flags);
for (i = 0; i < utn->n_tables; i++)
for (j = 0; j < info->tables[i].n_entries; j++) {
struct udp_tunnel_nic_table_entry *entry;
@@ -696,8 +701,8 @@ udp_tunnel_nic_flush(struct net_device *dev, struct udp_tunnel_nic *utn)
for (i = 0; i < utn->n_tables; i++)
memset(utn->entries[i], 0, array_size(info->tables[i].n_entries,
sizeof(**utn->entries)));
- WARN_ON(utn->need_sync);
- utn->need_replay = 0;
+ WARN_ON(test_bit(UDP_TUNNEL_NIC_NEED_SYNC, &utn->flags));
+ clear_bit(UDP_TUNNEL_NIC_NEED_REPLAY, &utn->flags);
}
static void
@@ -714,7 +719,7 @@ udp_tunnel_nic_replay(struct net_device *dev, struct udp_tunnel_nic *utn)
for (j = 0; j < info->tables[i].n_entries; j++)
udp_tunnel_nic_entry_freeze_used(&utn->entries[i][j]);
utn->missed = 0;
- utn->need_replay = 0;
+ clear_bit(UDP_TUNNEL_NIC_NEED_REPLAY, &utn->flags);
if (!info->shared) {
udp_tunnel_get_rx_info(dev);
@@ -736,10 +741,10 @@ static void udp_tunnel_nic_device_sync_work(struct work_struct *work)
rtnl_lock();
mutex_lock(&utn->lock);
- utn->work_pending = 0;
+ clear_bit(UDP_TUNNEL_NIC_WORK_PENDING, &utn->flags);
__udp_tunnel_nic_device_sync(utn->dev, utn);
- if (utn->need_replay)
+ if (test_bit(UDP_TUNNEL_NIC_NEED_REPLAY, &utn->flags))
udp_tunnel_nic_replay(utn->dev, utn);
mutex_unlock(&utn->lock);
@@ -904,7 +909,7 @@ udp_tunnel_nic_unregister(struct net_device *dev, struct udp_tunnel_nic *utn)
/* Wait for the work to be done using the state, netdev core will
* retry unregister until we give up our reference on this device.
*/
- if (utn->work_pending)
+ if (test_bit(UDP_TUNNEL_NIC_WORK_PENDING, &utn->flags))
return;
udp_tunnel_nic_free(utn);
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply related
* [PATCH v2 net 1/3] net: udp_tunnel: prevent double queueing in udp_tunnel_nic_device_sync
From: Eric Dumazet @ 2026-06-25 6:59 UTC (permalink / raw)
To: David S . Miller, Jakub Kicinski, Paolo Abeni
Cc: Simon Horman, Yue Sun, Stanislav Fomichev, netdev, eric.dumazet,
Eric Dumazet
In-Reply-To: <20260625065938.654652-1-edumazet@google.com>
Yue Sun reported a use-after-free and debugobjects warning in
udp_tunnel_nic_device_sync_work() during concurrent device operations.
The workqueue core clears the internal pending bit before invoking the
worker. At that point, a concurrent thread can queue the work again.
When the already running worker eventually clears the work_pending flag
to 0, it mistakenly clears the flag for the newly queued instance.
udp_tunnel_nic_unregister() then observes work_pending as 0 and frees
the structure while the second work item is still active in the queue,
leading to UAF.
Fix this by returning early in udp_tunnel_nic_device_sync() if
work_pending is already set, preventing redundant work queueing.
Fixes: cc4e3835eff4 ("udp_tunnel: add central NIC RX port offload infrastructure")
Reported-by: Yue Sun <samsun1006219@gmail.com>
Suggested-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/ipv4/udp_tunnel_nic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/udp_tunnel_nic.c b/net/ipv4/udp_tunnel_nic.c
index 9944ed923ddfd10f9adf6ad788c0740daeaf2adb..3b32a0afa9798d3c416d9ae570e6d529f70e6697 100644
--- a/net/ipv4/udp_tunnel_nic.c
+++ b/net/ipv4/udp_tunnel_nic.c
@@ -301,7 +301,7 @@ __udp_tunnel_nic_device_sync(struct net_device *dev, struct udp_tunnel_nic *utn)
static void
udp_tunnel_nic_device_sync(struct net_device *dev, struct udp_tunnel_nic *utn)
{
- if (!utn->need_sync)
+ if (!utn->need_sync || utn->work_pending)
return;
queue_work(udp_tunnel_nic_workqueue, &utn->work);
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply related
* [PATCH v2 net 0/3] net: udp_tunnel: fix races and use-after-free
From: Eric Dumazet @ 2026-06-25 6:59 UTC (permalink / raw)
To: David S . Miller, Jakub Kicinski, Paolo Abeni
Cc: Simon Horman, Yue Sun, Stanislav Fomichev, netdev, eric.dumazet,
Eric Dumazet
Yue Sun reported a use-after-free and debugobjects warning in
udp_tunnel_nic_device_sync_work() when concurrently creating and
destroying netdevsim and geneve devices.
This series resolves the UAF and the underlying data races that
make the fix vulnerable.
The core issue is a workqueue re-queue race combined with data races
introduced by the lock-splitting in commit 1ead7501094c ("udp_tunnel:
remove rtnl_lock dependency"). That commit allowed the device reset
path (reset_ntf) to run without holding the RTNL lock (using only
utn->lock), while the port addition paths (add_port) still run under
RTNL without acquiring utn->lock.
This series fixes these issues in three steps:
1. Patch 1 (Jakub's fix) addresses the UAF by preventing double-queueing
of the sync work. If work_pending is already set, we return early
in device_sync(), blocking a second work item from entering the
queue while the first is blocked on RTNL.
2. Patch 2 converts the state flags (need_sync, need_replay, work_pending)
from bitfields to atomic bitops. Because these flags share a single
byte, concurrent RMW writes from the RTNL-locked path and the RTNL-less
reset path corrupt the byte. This corruption could clear work_pending,
defeating the UAF fix.
3. Patch 3 fixes a similar data race on the 'missed' bitmap. Writes
(__set_bit) happen under RTNL, while reads (should_replay) happen
under utn->lock without RTNL. We convert this to use atomic set_bit(),
READ_ONCE() for the fast-path read, and WRITE_ONCE() for clearing.
Reported-by: Yue Sun <samsun1006219@gmail.com>
Eric Dumazet (3):
net: udp_tunnel: prevent double queueing in udp_tunnel_nic_device_sync
net: udp_tunnel: convert state flags to atomic bitops
net: udp_tunnel: use atomic bitops for missed bitmap
net/ipv4/udp_tunnel_nic.c | 51 +++++++++++++++++++++------------------
1 file changed, 28 insertions(+), 23 deletions(-)
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply
* Re: [PATCH v8 33/46] KVM: selftests: Test conversion precision in guest_memfd
From: Fuad Tabba @ 2026-06-25 6:57 UTC (permalink / raw)
To: ackerleytng
Cc: aik, andrew.jones, binbin.wu, brauner, chao.p.peng, david,
jmattson, jthoughton, michael.roth, oupton, pankaj.gupta, qperret,
rick.p.edgecombe, rientjes, shivankg, steven.price, willy, wyihan,
yan.y.zhao, forkloop, pratyush, suzuki.poulose, aneesh.kumar,
liam, Paolo Bonzini, Sean Christopherson, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Jonathan Corbet, Shuah Khan, Shuah Khan, Vishal Annapurve,
Andrew Morton, Chris Li, Kairui Song, Kemeng Shi, Nhat Pham,
Barry Song, Axel Rasmussen, Yuanchu Xie, Wei Xu, Youngjun Park,
Qi Zheng, Shakeel Butt, Kiryl Shutsemau, Baoquan He,
Jason Gunthorpe, Vlastimil Babka, kvm, linux-kernel,
linux-trace-kernel, linux-doc, linux-kselftest, linux-mm,
linux-coco
In-Reply-To: <20260618-gmem-inplace-conversion-v8-33-9d2959357853@google.com>
On Fri, 19 Jun 2026 at 01:32, Ackerley Tng via B4 Relay
<devnull+ackerleytng.google.com@kernel.org> wrote:
>
> From: Ackerley Tng <ackerleytng@google.com>
>
> The existing guest_memfd conversion tests only use single-page memory
> regions. This provides no coverage for multi-page guest_memfd objects,
> specifically whether KVM correctly handles the page index for conversion
> operations. An incorrect implementation could, for example, always operate
> on the first page regardless of the index provided.
>
> Add a new test case to verify that conversions between private and shared
> memory correctly target the specified page within a multi-page guest_memfd.
>
> This test also verifies the precision of memory conversions by converting a
> single page an then iterating through all other pages ensure they remain in
> their original state.
>
> To support this test, add a new GMEM_CONVERSION_MULTIPAGE_TEST_INIT_SHARED
> macro that handles setting up and tearing down the VM for each page
> iteration. The teardown logic is adjusted to prevent a double-free in this
> new scenario.
>
> Signed-off-by: Ackerley Tng <ackerleytng@google.com>
> Co-developed-by: Sean Christopherson <seanjc@google.com>
> Signed-off-by: Sean Christopherson <seanjc@google.com>
Reviewed-by: Fuad Tabba <tabba@google.com>
Cheers,
/fuad
> ---
> .../kvm/x86/guest_memfd_conversions_test.c | 66 ++++++++++++++++++++++
> 1 file changed, 66 insertions(+)
>
> diff --git a/tools/testing/selftests/kvm/x86/guest_memfd_conversions_test.c b/tools/testing/selftests/kvm/x86/guest_memfd_conversions_test.c
> index 5b070d3374eae..8e17d5c08aeb8 100644
> --- a/tools/testing/selftests/kvm/x86/guest_memfd_conversions_test.c
> +++ b/tools/testing/selftests/kvm/x86/guest_memfd_conversions_test.c
> @@ -61,8 +61,13 @@ static void gmem_conversions_do_setup(test_data_t *t, int nr_pages,
>
> static void gmem_conversions_do_teardown(test_data_t *t)
> {
> + /* Use NULL to avoid second free in FIXTURE_TEARDOWN (multipage tests). */
> + if (!t->vcpu)
> + return;
> +
> /* No need to close gmem_fd, it's owned by the VM structure. */
> kvm_vm_free(t->vcpu->vm);
> + t->vcpu = NULL;
> }
>
> FIXTURE_TEARDOWN(gmem_conversions)
> @@ -101,6 +106,29 @@ static void __gmem_conversions_##test(test_data_t *t, int nr_pages) \
> #define GMEM_CONVERSION_TEST_INIT_SHARED(test) \
> __GMEM_CONVERSION_TEST_INIT_SHARED(test, 1)
>
> +/*
> + * Repeats test over nr_pages in a guest_memfd of size nr_pages, providing each
> + * test iteration with test_page, the index of the page under test in
> + * guest_memfd. test_page takes values 0..(nr_pages - 1) inclusive.
> + */
> +#define GMEM_CONVERSION_MULTIPAGE_TEST_INIT_SHARED(test, __nr_pages) \
> +static void __gmem_conversions_multipage_##test(test_data_t *t, int nr_pages, \
> + const int test_page); \
> + \
> +TEST_F(gmem_conversions, test) \
> +{ \
> + const u64 flags = GUEST_MEMFD_FLAG_MMAP | GUEST_MEMFD_FLAG_INIT_SHARED; \
> + int i; \
> + \
> + for (i = 0; i < __nr_pages; ++i) { \
> + gmem_conversions_do_setup(self, __nr_pages, flags); \
> + __gmem_conversions_multipage_##test(self, __nr_pages, i); \
> + gmem_conversions_do_teardown(self); \
> + } \
> +} \
> +static void __gmem_conversions_multipage_##test(test_data_t *t, int nr_pages, \
> + const int test_page)
> +
> struct guest_check_data {
> void *mem;
> char expected_val;
> @@ -199,6 +227,44 @@ GMEM_CONVERSION_TEST_INIT_SHARED(init_shared)
> test_convert_to_shared(t, 0, 'C', 'D', 'E');
> }
>
> +GMEM_CONVERSION_MULTIPAGE_TEST_INIT_SHARED(indexing, 4)
> +{
> + int i;
> +
> + /* Get a char that varies with both i and n. */
> +#define combine(x, n) ((x << 4) + (n))
> +#define i_(n) (combine(i, n))
> +#define t_(n) (combine(test_page, n))
> +
> + /*
> + * Start with the highest index, to catch any errors when, perhaps, the
> + * first page is returned even for the last index.
> + */
> + for (i = nr_pages - 1; i >= 0; --i)
> + test_shared(t, i, 0, i_(0), i_(2));
> +
> + test_convert_to_private(t, test_page, t_(2), t_(3));
> +
> + for (i = 0; i < nr_pages; ++i) {
> + if (i == test_page)
> + test_private(t, test_page, t_(3), t_(4));
> + else
> + test_shared(t, i, i_(2), i_(3), i_(4));
> + }
> +
> + test_convert_to_shared(t, test_page, t_(4), t_(5), t_(6));
> +
> + for (i = 0; i < nr_pages; ++i) {
> + char expected = i == test_page ? t_(6) : i_(4);
> +
> + test_shared(t, i, expected, i_(7), i_(8));
> + }
> +
> +#undef t_
> +#undef i_
> +#undef combine
> +}
> +
> int main(int argc, char *argv[])
> {
> TEST_REQUIRE(kvm_check_cap(KVM_CAP_VM_TYPES) & BIT(KVM_X86_SW_PROTECTED_VM));
>
> --
> 2.55.0.rc0.738.g0c8ab3ebcc-goog
>
>
^ permalink raw reply
* Re: [PATCH v3 1/2] iio: imu: inv_icm42600: reorder includes for buffer module
From: Andy Shevchenko @ 2026-06-25 6:57 UTC (permalink / raw)
To: jean-baptiste.maneyrol
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
linux-iio, linux-kernel
In-Reply-To: <ajzQ_FUr--jTxYWr@ashevche-desk.local>
On Thu, Jun 25, 2026 at 09:56:01AM +0300, Andy Shevchenko wrote:
> On Thu, Jun 25, 2026 at 09:49:47AM +0300, Andy Shevchenko wrote:
> > On Wed, Jun 24, 2026 at 06:21:18PM +0200, Jean-Baptiste Maneyrol via B4 Relay wrote:
> >
> > > Reorder includes following rules and delete unneeded kernel.h.
> >
> > Actually it's needed as 'proxy' header. If you want to get rid of it, it should
> > be another patch to replace that with the used headers following IWYU
> > principle.
> >
> > Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
>
> Also for the consistency's sake this should be done in all files in that
> folder. I see the same issue(s) in the _gyro and _accel and I assume the rest
> *.c and *.h also might be updated.
For the simplicity, just sort the each group of headers in all files. The IWYU
can be applied later on as it's not in the scope of your series.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v2] firmware: sysfb: Mark CONFIG_SYSFB_SIMPLEFB as deprecated
From: Thomas Zimmermann @ 2026-06-25 6:57 UTC (permalink / raw)
To: javierm, julianbraha, sima, airlied
Cc: dri-devel, linux-fbdev, linux-kernel, sashiko-reviews,
Thomas Zimmermann
Mark CONFIG_SYSFB_SIMPLEFB as deprecated. Enabling it allows to
run simpledrm and simplefb on EFI/VESA framebuffers. Doing this
is discouraged in favor of using efidrm and vesadrm.
v2:
- resolve conflicting help texts (Sashiko)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
---
drivers/firmware/Kconfig | 32 ++++++++++----------------------
drivers/gpu/drm/sysfb/Kconfig | 7 ++-----
2 files changed, 12 insertions(+), 27 deletions(-)
diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index bbd2155d8483..637e3bb5549e 100644
--- a/drivers/firmware/Kconfig
+++ b/drivers/firmware/Kconfig
@@ -184,32 +184,20 @@ config SYSFB
select SCREEN_INFO
config SYSFB_SIMPLEFB
- bool "Mark VGA/VBE/EFI FB as generic system framebuffer"
+ bool "Mark VGA/VBE/EFI FB as generic system framebuffer (deprecated)"
depends on X86 || EFI
select SYSFB
help
- Firmwares often provide initial graphics framebuffers so the BIOS,
+ Firmware often provides initial graphics framebuffers so the BIOS,
bootloader or kernel can show basic video-output during boot for
- user-guidance and debugging. Historically, x86 used the VESA BIOS
- Extensions and EFI-framebuffers for this, which are mostly limited
- to x86 BIOS or EFI systems.
- This option, if enabled, marks VGA/VBE/EFI framebuffers as generic
- framebuffers so the new generic system-framebuffer drivers can be
- used instead. If the framebuffer is not compatible with the generic
- modes, it is advertised as fallback platform framebuffer so legacy
- drivers like efifb, vesafb and uvesafb can pick it up.
- If this option is not selected, all system framebuffers are always
- marked as fallback platform framebuffers as usual.
-
- Note: Legacy fbdev drivers, including vesafb, efifb, uvesafb, will
- not be able to pick up generic system framebuffers if this option
- is selected. You are highly encouraged to enable simplefb as
- replacement if you select this option. simplefb can correctly deal
- with generic system framebuffers. But you should still keep vesafb
- and others enabled as fallback if a system framebuffer is
- incompatible with simplefb.
-
- If unsure, say Y.
+ user-guidance and debugging.
+
+ This option, if enabled, marks VBE/EFI framebuffers as system
+ framebuffers so the generic simpledrm driver can be used.
+
+ This option is deprecated and will be removed in the near future. If
+ unsure, say N and select efidrm, vesadrm instead. The dedicated DRM
+ drivers provide the same functionality plus additional features.
config TH1520_AON_PROTOCOL
tristate "Always-On firmware protocol"
diff --git a/drivers/gpu/drm/sysfb/Kconfig b/drivers/gpu/drm/sysfb/Kconfig
index 2559ead6cf1f..f7e48178885e 100644
--- a/drivers/gpu/drm/sysfb/Kconfig
+++ b/drivers/gpu/drm/sysfb/Kconfig
@@ -67,11 +67,8 @@ config DRM_SIMPLEDRM
This driver assumes that the display hardware has been initialized
by the firmware or bootloader before the kernel boots. Scanout
- buffer, size, and display format must be provided via device tree,
- UEFI, VESA, etc.
-
- On x86 BIOS or UEFI systems, you should also select SYSFB_SIMPLEFB
- to use UEFI and VESA framebuffers.
+ buffer, size, and display format must be provided via device tree's
+ simple-framebuffer node.
config DRM_VESADRM
tristate "VESA framebuffer driver"
--
2.54.0
^ permalink raw reply related
* Re: [PATCH] gpu: nova-core: falcon: store bar and dev in falcon
From: Alexandre Courbot @ 2026-06-25 6:56 UTC (permalink / raw)
To: Tim Kovalenko
Cc: Danilo Krummrich, Alice Ryhl, David Airlie, Simona Vetter,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
nova-gpu, dri-devel, linux-kernel, linux-riscv
In-Reply-To: <20260624-drm-bar-refactor-v1-1-7062899163c5@proton.me>
Hi Tim, thanks for the patch!
On Thu Jun 25, 2026 at 12:51 AM JST, Tim Kovalenko wrote:
> Store the bound device and `BAR0` mapping in `Falcon` instead of passing
> them through every `Falcon` operation. This simplifies the `Falcon` API and
> removes repeated `dev`/`bar` plumbing from reset, load, boot, mailbox, DMA,
> and GSP/FSP-specific Falcon helpers.
>
> Add a named helper for configuring Falcon FBIF transaction slots for
> physical coherent system memory, avoiding direct `BAR0` access from the
> FWSEC bootloader path without exposing BAR0 publicly.
>
> Future work / questions:
Questions are not something we want to appear in the final git log, so
please move such comments to after the `---` mark. If you use b4, this
is where the cover letter text will be placed on single-patch series.
>
> - Focused only on the Falcon for this patch - more to follow.
>
> - Not sure about the FalconHal and if I should modify the Trait
> - Could be part of the next patch
> - But it could definitively be simplified
Every HAL method takes the `Falcon` as a parameter, so it is able
to access its `bar` and `dev`. I think it makes sense to remove the
parameters there as well when possible.
>
> - Also, how far should the refactor go and to what extend add new
> methods to avoid passing `bar` or `dev` but also not exposing them as
> pub. For `dev`, there's a lot of `dev_err` usage that requires us to
> pass it as a param.
> - I've created the `set_fbif_transcfg_phys_sysmem` method to
> address such issue and remove some code duplication but that
> method could be made a bit more generic.
If you add new methods, these should come as separate patches, and be
thoroughly thought - `set_fbif_transcfg_phys_sysmem` seems a bit too
ad-hoc to me. It looks like the proper fix for this access to
`NV_PFALCON_FBIF_TRANSCFG` is more something like moving it to
`Falcon::pio_load` or something, but this is a separate problem.
Let's keep the patch focused on `Falcon` itself, and keep the `bar`
argument of `FwsecFirmwareWithBl::run` until we figure out the right way
to address this. We don't need to clean up everything in one go.
>
> - Also, is there a reason why we are not passing the `GspBootContext`
> when we need stuff like `bar`, `dev` and both falcons?
`GspBootContext` was recently introduced, and yes we want to use it
more, but there are plans to make it generic and until we know what it
will look like I would like to limit its use. So for this patch, better
to keep things simple and mechanical.
>
> Reported-by: Alexandre Courbot <acourbot@nvidia.com>
This is not a bug, so `Suggested-by:` is more accurate I think.
> Closes: https://rust-for-linux.zulipchat.com/#narrow/channel/509436-Nova/topic/Storing.20driver-bound.20references.20into.20sub-devices/near/599137882
This can be `Link:`, as this patch by itself doesn't fix them all yet.
The patch itself clearly makes things more readable, and looks like what
I had in mind - modulo the addition of new methods that I would prefer
to see taken care of separately. If you can send a v2 that focuses
strictly on falcon and does not introduce new methods, I think that
would be perfect.
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply
* [PATCH] sched: set TIF_NEED_RESCHED before calling __trace_set_need_resched()
From: Sechang Lim @ 2026-06-25 6:54 UTC (permalink / raw)
To: linux-kernel
Cc: mingo, peterz, juri.lelli, vincent.guittot, dietmar.eggemann,
rostedt, bsegall, mgorman, vschneid, kprateek.nayak, gmonaco
set_tsk_need_resched() tests TIF_NEED_RESCHED, calls
__trace_set_need_resched() if the flag is clear, then sets it via
set_tsk_thread_flag(). A BPF raw_tp program attached to
sched_set_need_resched executes synchronously inside __bpf_trace_run().
On return, __bpf_trace_run() drops the RCU lock with
rcu_read_unlock_migrate(), which on the preempt-or-BH-disabled path
calls set_need_resched_current() -> set_tsk_need_resched() again.
set_tsk_thread_flag() follows the tracepoint call, so every re-entrant
frame sees TIF_NEED_RESCHED clear and calls __trace_set_need_resched()
again:
BUG: TASK stack guard page was hit at ffffc9001224ff98
Oops: stack guard page: 0000 [#1] SMP KASAN PTI
RIP: 0010:__bpf_trace_sched_set_need_resched_tp+0x1c/0x190
Call Trace:
trace_sched_set_need_resched_tp+0x110/0x130
set_tsk_need_resched include/linux/sched.h:2076
set_need_resched_current include/linux/sched.h:2094
rcu_read_unlock_special+0x43a/0x440
__rcu_read_unlock+0x9e/0x120
rcu_read_unlock_migrate+0xa9/0x240
__bpf_trace_run+0x131/0x180
bpf_trace_run3+0x333/0x430
__bpf_trace_sched_set_need_resched_tp+0x13a/0x190
trace_sched_set_need_resched_tp+0x110/0x130
set_tsk_need_resched include/linux/sched.h:2076
...
Replace the separate test_tsk_thread_flag() + set_tsk_thread_flag() pair
with test_and_set_tsk_thread_flag().
Fixes: adcc3bfa8806 ("sched: Adapt sched tracepoints for RV task model")
Signed-off-by: Sechang Lim <rhkrqnwk98@gmail.com>
---
include/linux/sched.h | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index ee06cba5c6f5..c9efd08dae92 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -2071,10 +2071,9 @@ static inline int test_tsk_thread_flag(struct task_struct *tsk, int flag)
static inline void set_tsk_need_resched(struct task_struct *tsk)
{
- if (tracepoint_enabled(sched_set_need_resched_tp) &&
- !test_tsk_thread_flag(tsk, TIF_NEED_RESCHED))
+ if (!test_and_set_tsk_thread_flag(tsk, TIF_NEED_RESCHED) &&
+ tracepoint_enabled(sched_set_need_resched_tp))
__trace_set_need_resched(tsk, TIF_NEED_RESCHED);
- set_tsk_thread_flag(tsk,TIF_NEED_RESCHED);
}
static inline void clear_tsk_need_resched(struct task_struct *tsk)
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] gpu: nova-core: falcon: store bar and dev in falcon
From: Alexandre Courbot @ 2026-06-25 6:56 UTC (permalink / raw)
To: Tim Kovalenko
Cc: Danilo Krummrich, Alice Ryhl, David Airlie, Simona Vetter,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
nova-gpu, dri-devel, linux-kernel, linux-riscv
In-Reply-To: <20260624-drm-bar-refactor-v1-1-7062899163c5@proton.me>
Hi Tim, thanks for the patch!
On Thu Jun 25, 2026 at 12:51 AM JST, Tim Kovalenko wrote:
> Store the bound device and `BAR0` mapping in `Falcon` instead of passing
> them through every `Falcon` operation. This simplifies the `Falcon` API and
> removes repeated `dev`/`bar` plumbing from reset, load, boot, mailbox, DMA,
> and GSP/FSP-specific Falcon helpers.
>
> Add a named helper for configuring Falcon FBIF transaction slots for
> physical coherent system memory, avoiding direct `BAR0` access from the
> FWSEC bootloader path without exposing BAR0 publicly.
>
> Future work / questions:
Questions are not something we want to appear in the final git log, so
please move such comments to after the `---` mark. If you use b4, this
is where the cover letter text will be placed on single-patch series.
>
> - Focused only on the Falcon for this patch - more to follow.
>
> - Not sure about the FalconHal and if I should modify the Trait
> - Could be part of the next patch
> - But it could definitively be simplified
Every HAL method takes the `Falcon` as a parameter, so it is able
to access its `bar` and `dev`. I think it makes sense to remove the
parameters there as well when possible.
>
> - Also, how far should the refactor go and to what extend add new
> methods to avoid passing `bar` or `dev` but also not exposing them as
> pub. For `dev`, there's a lot of `dev_err` usage that requires us to
> pass it as a param.
> - I've created the `set_fbif_transcfg_phys_sysmem` method to
> address such issue and remove some code duplication but that
> method could be made a bit more generic.
If you add new methods, these should come as separate patches, and be
thoroughly thought - `set_fbif_transcfg_phys_sysmem` seems a bit too
ad-hoc to me. It looks like the proper fix for this access to
`NV_PFALCON_FBIF_TRANSCFG` is more something like moving it to
`Falcon::pio_load` or something, but this is a separate problem.
Let's keep the patch focused on `Falcon` itself, and keep the `bar`
argument of `FwsecFirmwareWithBl::run` until we figure out the right way
to address this. We don't need to clean up everything in one go.
>
> - Also, is there a reason why we are not passing the `GspBootContext`
> when we need stuff like `bar`, `dev` and both falcons?
`GspBootContext` was recently introduced, and yes we want to use it
more, but there are plans to make it generic and until we know what it
will look like I would like to limit its use. So for this patch, better
to keep things simple and mechanical.
>
> Reported-by: Alexandre Courbot <acourbot@nvidia.com>
This is not a bug, so `Suggested-by:` is more accurate I think.
> Closes: https://rust-for-linux.zulipchat.com/#narrow/channel/509436-Nova/topic/Storing.20driver-bound.20references.20into.20sub-devices/near/599137882
This can be `Link:`, as this patch by itself doesn't fix them all yet.
The patch itself clearly makes things more readable, and looks like what
I had in mind - modulo the addition of new methods that I would prefer
to see taken care of separately. If you can send a v2 that focuses
strictly on falcon and does not introduce new methods, I think that
would be perfect.
^ permalink raw reply
* Re: [PATCH v3 1/2] iio: imu: inv_icm42600: reorder includes for buffer module
From: Andy Shevchenko @ 2026-06-25 6:55 UTC (permalink / raw)
To: jean-baptiste.maneyrol
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
linux-iio, linux-kernel
In-Reply-To: <ajzPhi3ymeIBYHRr@ashevche-desk.local>
On Thu, Jun 25, 2026 at 09:49:47AM +0300, Andy Shevchenko wrote:
> On Wed, Jun 24, 2026 at 06:21:18PM +0200, Jean-Baptiste Maneyrol via B4 Relay wrote:
>
> > Reorder includes following rules and delete unneeded kernel.h.
>
> Actually it's needed as 'proxy' header. If you want to get rid of it, it should
> be another patch to replace that with the used headers following IWYU
> principle.
>
> Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Also for the consistency's sake this should be done in all files in that
folder. I see the same issue(s) in the _gyro and _accel and I assume the rest
*.c and *.h also might be updated.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v3 0/2] doc: clarify review replies and reroll timing
From: Weijie Yuan @ 2026-06-25 6:54 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git, gitster
In-Reply-To: <ajvDuUiDsmyf5LnX@pks.im>
On Wed, Jun 24, 2026 at 01:47:05PM +0200, Patrick Steinhardt wrote:
> On Sun, Jun 21, 2026 at 04:04:36PM +0800, Weijie Yuan wrote:
> > Changes in v3:
> >
> > - Reworked the substantial-rework case. Instead of suggesting that
> > authors send a new version sooner, the text now advises authors not
> > to rush out an updated version before reviewing the larger changes
> > carefully. It recommends replying to the review that prompted the
> > rewrite, saying that a substantial rework is planned, and pointing
> > out which parts of the current series will become obsolete.
> >
> > - Dropped the advice that a topic close to being accepted may justify
> > a quicker reroll.
> >
> > - Removed "how close the topic is to being accepted" from the short
> > reroll-timing guidance in Documentation/SubmittingPatches.
> >
> > - Updated the commit message of patch 2 accordingly.
>
> I'm happy with this version, thanks!
>
> Patrick
Thank you very much for your review and guidance!
^ permalink raw reply
* Re: [PATCH v3 2/2] iio: imu: inv_icm42600: add buffer hwfifo watermark attributes
From: Andy Shevchenko @ 2026-06-25 6:54 UTC (permalink / raw)
To: jean-baptiste.maneyrol
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
linux-iio, linux-kernel
In-Reply-To: <20260624-inv-icm42600-add-buffer-hwfifo_attributes-v3-2-5d9a4c662f50@tdk.com>
On Wed, Jun 24, 2026 at 06:21:19PM +0200, Jean-Baptiste Maneyrol via B4 Relay wrote:
> Add hwfifo_watermark/min/max/enabled buffer attributes.
> Hardware FIFO is always enabled and used.
These attributes are already documented and being used by a few drivers.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 2/2] doc: advise batching patch rerolls
From: Weijie Yuan @ 2026-06-25 6:53 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: Junio C Hamano, git
In-Reply-To: <ajvDrjk-bTvYaQtU@pks.im>
On Wed, Jun 24, 2026 at 01:46:54PM +0200, Patrick Steinhardt wrote:
> > But here I think Patrick's original intention is: If your series is
> > *close* to be accepted, (while I'm not sure what the precise definition
> > of this "close to be accepted", does it means: commented by Junio with
> > "Looks good", or reviewed by the community/core contributors with "Makes
> > sense"?) and this time there happens to be a small issue, you can
> > re-roll quickly to make your series more "sturdy" to wait for
> > maintainer's final examination and further merges.
> >
> > So, I think the situation you are describing here is that this version
> > of the patch has already been declared by the *author* to be the final
> > version. (i.e. waiting for Junio to do the last exam)
>
> My "close to be accepted" feeling is when you've had multiple rounds of
> design discussions already, everyone is on the same page, and all you
> got on the last review round is a couple of typo fixes.
>
> But all of this is highly subjective, so it'll always depend and it
> won't be easy to codify all of that. Nor is that necessary, I guess. We
> really only want to provide some rough guidance.
Agreed, thanks!
> > Therefore, I do not think the two situations conflict with each other,
> > or are directly related. One concerns a patch that is already close to
> > receiving the maintainer's final verdict, where a minor issue is
> > discovered and the author quickly rerolls it. The other concerns an
> > author who, without realizing that some issues remain unresolved, rushes
> > to send what they believe to be the final version and then waits for the
> > maintainer to review it.
> >
> > For the latter case, I think it would be better to add a sentence along
> > the lines of: "Before sending a new version/the final version, check
> > once more whether there are any unresolved issues," if the existing
> > documentation does not already make this clear.
>
> I think that should mostly be clear with our documentation. And
> eventually, we should also expect people to have some common sense :)
Agreed.
> > That said, I am not familiar with how patch discussions have played out
> > in the past, so please directly point out any mistakes in my
> > understanding. I have to admit that, by this point in writing the
> > message, I have become a little tangled up in my own reasoning.
>
> I guess that's kind of expected, mostly because many of these things are
> highly subjective and will depend on the situation. The guidance does
> not have to be perfect, you'll probably be able to find counterexamples
> for many of the cases.
Yes, setting the rules too strictly may actually reduce flexibility of
our project.
Thanks!
^ permalink raw reply
* [PATCH v3 0/2] arm64: dts: socfpga: agilex72: Add initial device tree
From: muhammad.nazim.amirul.nazle.asmade @ 2026-06-25 6:53 UTC (permalink / raw)
To: dinguyen; +Cc: robh, krzk+dt, conor+dt, devicetree, linux-kernel
From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
This series introduces basic device tree support for the Intel/Altera
Agilex72 SoCFPGA platform, which is a new SoC featuring a heterogeneous
CPU cluster (Cortex-A520 and Cortex-A720 cores).
Patch 1 adds the new compatible strings for Agilex72 to the arm/altera
DT bindings documentation.
Patch 2 introduces the initial DTSI and board-level DTS for the Agilex72
SoCDK. The DTSI covers the core SoC nodes: CPUs, GIC-v3 interrupt
controller with ITS, ARM architectural timer, PSCI, SMMU-v3, OCRAM, and
two UART serial controllers backed by a fixed-clock placeholder. The clock
manager driver for this platform is not yet upstream, so a fixed-clock
at 125 MHz is used as an interim solution for the UART clock, matching
the hardware-confirmed LSP_SP_CLK frequency.
Changes in v3:
- Add UART serial console (uart0, uart1) with fixed-clock placeholder at 125 MHz
- Add aliases and chosen nodes in board DTS for serial console
Changes in v2:
- Applied relevant feedback from Shahsiko's review
- Re-add arm,armv8-timer node which is mandatory for kernel boot
- Rename platform from agilex7-gen2 to agilex72
Nazim Amirul (2):
dt-bindings: arm: altera: Add Agilex72 SoCFPGA compatible strings
arm64: dts: socfpga: agilex72: Add initial device tree
.../devicetree/bindings/arm/altera.yaml | 6 +
arch/arm64/boot/dts/intel/Makefile | 1 +
.../boot/dts/intel/socfpga_agilex72.dtsi | 156 ++++++++++++++++++
.../boot/dts/intel/socfpga_agilex72_socdk.dts | 27 +++
4 files changed, 190 insertions(+)
create mode 100644 arch/arm64/boot/dts/intel/socfpga_agilex72.dtsi
create mode 100644 arch/arm64/boot/dts/intel/socfpga_agilex72_socdk.dts
--
2.43.7
^ permalink raw reply
* [PATCH v3 1/2] dt-bindings: arm: altera: Add Agilex72 SoCFPGA compatible strings
From: muhammad.nazim.amirul.nazle.asmade @ 2026-06-25 6:53 UTC (permalink / raw)
To: dinguyen; +Cc: robh, krzk+dt, conor+dt, devicetree, linux-kernel
In-Reply-To: <20260625065329.20274-1-muhammad.nazim.amirul.nazle.asmade@altera.com>
From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
Add the SoC and board compatible strings for the Intel SoCFPGA
Agilex72 platform.
Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
---
Changes in v3:
- no changes
---
Documentation/devicetree/bindings/arm/altera.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/altera.yaml b/Documentation/devicetree/bindings/arm/altera.yaml
index 4b096e52243e..cc03fb437a9a 100644
--- a/Documentation/devicetree/bindings/arm/altera.yaml
+++ b/Documentation/devicetree/bindings/arm/altera.yaml
@@ -115,6 +115,12 @@ properties:
- intel,socfpga-agilex5-socdk-nand
- const: intel,socfpga-agilex5
+ - description: Agilex72 boards
+ items:
+ - enum:
+ - intel,socfpga-agilex72-socdk
+ - const: intel,socfpga-agilex72
+
- description: Agilex7m boards
items:
- enum:
--
2.43.7
^ permalink raw reply related
* [PATCH v3 2/2] arm64: dts: socfpga: agilex72: Add initial device tree
From: muhammad.nazim.amirul.nazle.asmade @ 2026-06-25 6:53 UTC (permalink / raw)
To: dinguyen; +Cc: robh, krzk+dt, conor+dt, devicetree, linux-kernel
In-Reply-To: <20260625065329.20274-1-muhammad.nazim.amirul.nazle.asmade@altera.com>
From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
Add initial device tree support for the Intel SoCFPGA Agilex72
platform. This introduces the SoC DTSI and the SoCDK board DTS as
the first upstream submission for this platform.
The Agilex72 SoC features a heterogeneous CPU cluster with
Cortex-A520 and Cortex-A720 cores, and includes an SMMU v3 for
memory management.
Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
---
Changes in v3:
- Add UART serial console (uart0, uart1) with fixed-clock placeholder at 125 MHz
- Add aliases and chosen nodes in board DTS for serial console
Changes in v2:
- Re-add arm,armv8-timer node which is mandatory for kernel boot
- Rename platform from agilex7-gen2 to agilex72
---
arch/arm64/boot/dts/intel/Makefile | 1 +
.../boot/dts/intel/socfpga_agilex72.dtsi | 156 ++++++++++++++++++
.../boot/dts/intel/socfpga_agilex72_socdk.dts | 27 +++
3 files changed, 184 insertions(+)
create mode 100644 arch/arm64/boot/dts/intel/socfpga_agilex72.dtsi
create mode 100644 arch/arm64/boot/dts/intel/socfpga_agilex72_socdk.dts
diff --git a/arch/arm64/boot/dts/intel/Makefile b/arch/arm64/boot/dts/intel/Makefile
index 088a03b89c99..270c70fdf084 100644
--- a/arch/arm64/boot/dts/intel/Makefile
+++ b/arch/arm64/boot/dts/intel/Makefile
@@ -8,6 +8,7 @@ dtb-$(CONFIG_ARCH_INTEL_SOCFPGA) += socfpga_agilex_n6000.dtb \
socfpga_agilex5_socdk_013b.dtb \
socfpga_agilex5_socdk_modular.dtb \
socfpga_agilex5_socdk_nand.dtb \
+ socfpga_agilex72_socdk.dtb \
socfpga_agilex7m_socdk.dtb \
socfpga_n5x_socdk.dtb
dtb-$(CONFIG_ARCH_KEEMBAY) += keembay-evm.dtb
diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex72.dtsi b/arch/arm64/boot/dts/intel/socfpga_agilex72.dtsi
new file mode 100644
index 000000000000..c29c2afcaab7
--- /dev/null
+++ b/arch/arm64/boot/dts/intel/socfpga_agilex72.dtsi
@@ -0,0 +1,156 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2026, Altera Corporation
+ */
+/dts-v1/;
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+
+/ {
+ compatible = "intel,socfpga-agilex72";
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ atf_reserved: atf@80000000 {
+ compatible = "shared-dma-pool";
+ reg = <0x0 0x80000000 0x0 0x100000>;
+ alignment = <0x1000>;
+ no-map;
+ };
+
+ service_reserved: svcbuffer@80100000 {
+ compatible = "shared-dma-pool";
+ reg = <0x0 0x80100000 0x0 0xf00000>;
+ alignment = <0x1000>;
+ no-map;
+ };
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ compatible = "arm,cortex-a520";
+ device_type = "cpu";
+ enable-method = "psci";
+ reg = <0x0>;
+ };
+
+ cpu1: cpu@100 {
+ compatible = "arm,cortex-a520";
+ device_type = "cpu";
+ enable-method = "psci";
+ reg = <0x100>;
+ };
+
+ cpu2: cpu@200 {
+ compatible = "arm,cortex-a720";
+ device_type = "cpu";
+ enable-method = "psci";
+ reg = <0x200>;
+ };
+
+ cpu3: cpu@300 {
+ compatible = "arm,cortex-a720";
+ device_type = "cpu";
+ enable-method = "psci";
+ reg = <0x300>;
+ };
+ };
+
+ clocks {
+ uart_clk: uart-clk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <125000000>;
+ };
+ };
+
+ psci {
+ compatible = "arm,psci-0.2";
+ method = "smc";
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupt-parent = <&intc>;
+ interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>;
+ };
+
+ intc: interrupt-controller@7000000 {
+ compatible = "arm,gic-v3";
+ reg = <0x0 0x7000000 0x0 0x10000>,
+ <0x0 0x7080000 0x0 0x100000>;
+ ranges;
+ #interrupt-cells = <3>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ interrupt-controller;
+ #redistributor-regions = <1>;
+ redistributor-stride = <0x0 0x40000>;
+
+ its: msi-controller@7040000 {
+ compatible = "arm,gic-v3-its";
+ reg = <0x0 0x7040000 0x0 0x20000>;
+ msi-controller;
+ #msi-cells = <1>;
+ };
+ };
+
+ soc: soc@0 {
+ compatible = "simple-bus";
+ ranges = <0 0 0 0xffffffff>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ device_type = "soc";
+ interrupt-parent = <&intc>;
+
+ smmu: iommu@c100000 {
+ compatible = "arm,smmu-v3";
+ reg = <0x0c100000 0x30000>;
+ interrupts = <GIC_SPI 134 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 129 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 132 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "eventq", "gerror", "priq";
+ dma-coherent;
+ #iommu-cells = <1>;
+ };
+
+ ocram: sram@0 {
+ compatible = "mmio-sram";
+ reg = <0x00000000 0x80000>;
+ ranges = <0 0 0x80000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+
+ uart0: serial@9038000 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x9038000 0x100>;
+ interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = <&uart_clk>;
+ status = "disabled";
+ };
+
+ uart1: serial@9039000 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x9039000 0x100>;
+ interrupts = <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = <&uart_clk>;
+ status = "disabled";
+ };
+ };
+};
diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex72_socdk.dts b/arch/arm64/boot/dts/intel/socfpga_agilex72_socdk.dts
new file mode 100644
index 000000000000..998f19f492b3
--- /dev/null
+++ b/arch/arm64/boot/dts/intel/socfpga_agilex72_socdk.dts
@@ -0,0 +1,27 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2026, Altera Corporation
+ */
+#include "socfpga_agilex72.dtsi"
+
+/ {
+ model = "Altera SoCFPGA Agilex72 SoCDK";
+ compatible = "intel,socfpga-agilex72-socdk", "intel,socfpga-agilex72";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory@80000000 {
+ device_type = "memory";
+ reg = <0x0 0x80000000 0x0 0x80000000>;
+ };
+};
+
+&uart0 {
+ status = "okay";
+};
--
2.43.7
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.