* Re: [PATCH] Documentation: watchdog: Fix typo "oncse" -> "once"
From: Randy Dunlap @ 2026-05-02 16:48 UTC (permalink / raw)
To: Wang Zihan, linux-watchdog
Cc: wim, linux, corbet, skhan, linux-doc, linux-kernel
In-Reply-To: <9a6393f4-6aec-4f64-b3ef-9566206c4ac7@infradead.org>
On 5/2/26 9:32 AM, Randy Dunlap wrote:
>
>
> On 5/2/26 4:19 AM, Wang Zihan wrote:
>> Fix a typo in mlx-wdt.rst documentation.
>>
>> Signed-off-by: Wang Zihan <3772548978@qq.com>
>> ---
>> Documentation/watchdog/mlx-wdt.rst | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/Documentation/watchdog/mlx-wdt.rst b/Documentation/watchdog/mlx-wdt.rst
>> index 35e690dea..3778f85d1 100644
>> --- a/Documentation/watchdog/mlx-wdt.rst
>> +++ b/Documentation/watchdog/mlx-wdt.rst
>> @@ -48,7 +48,7 @@ which is optional.
>> Watchdog can be started during a probe, in this case it will be
>> pinged by watchdog core before watchdog device will be opened by
>> user space application.
>> -Watchdog can be initialised in nowayout way, i.e. oncse started
>> +Watchdog can be initialised in nowayout way, i.e. once started
>> it can't be stopped.
>>
>> This mlx-wdt driver supports both HW watchdog implementations.
>
> This typo is also fixed in my 5-patch series (pending).
[PATCH 1/5] docs: watchdog: mlx-wdt: small fixes
https://lore.kernel.org/linux-watchdog/20260228010402.2389343-2-rdunlap@infradead.org/
--
~Randy
^ permalink raw reply
* Re: [PATCH v2] docs: Remove stale ISDN parameters
From: Randy Dunlap @ 2026-05-02 16:35 UTC (permalink / raw)
To: Costa Shulyupin, Jakub Kicinski, Jonathan Corbet, Shuah Khan,
linux-doc, linux-kernel
In-Reply-To: <20260502120206.1289126-1-costa.shul@redhat.com>
On 5/2/26 5:02 AM, Costa Shulyupin wrote:
> The icn= and pcbit= parameters referenced drivers removed in
> commit 02bbd9802da7 ("staging: i4l: delete the whole thing").
>
> Remove the stale parameter entries and the now-unused ISDN tag
> from the legend.
>
> Suggested-by: Randy Dunlap <rdunlap@infradead.org>
> Assisted-by: Claude:claude-opus-4-6
> ---
> v2: Remove pcbit= and ISDN too
> Address comments of Randy Dunlap
> V1: Remove icn=
>
> Signed-off-by: Costa Shulyupin <costa.shul@redhat.com>
> ---
Hi,
Your Signed-off-by: should be immediately after the
Assisted-by: line and before the first "---" line.
I'm curious: how and why did Claude assist you in this?
Anyway:
Acked-by: Randy Dunlap <rdunlap@infradead.org>
> Documentation/admin-guide/kernel-parameters.txt | 6 ------
> 1 file changed, 6 deletions(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index c13c354728bb..96c189e5f5bf 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -24,7 +24,6 @@
> IP_PNP IP DHCP, BOOTP, or RARP is enabled.
> IPV6 IPv6 support is enabled.
> ISAPNP ISA PnP code is enabled.
> - ISDN Appropriate ISDN support is enabled.
> ISOL CPU Isolation is enabled.
> JOY Appropriate joystick support is enabled.
> KGDB Kernel debugger support is enabled.
> @@ -2245,9 +2244,6 @@ Kernel parameters
> syscalls, essentially overriding IA32_EMULATION_DEFAULT_DISABLED at
> boot time. When false, unconditionally disables IA32 emulation.
>
> - icn= [HW,ISDN]
> - Format: <io>[,<membase>[,<icn_id>[,<icn_id2>]]]
> -
>
> idle= [X86,EARLY]
> Format: idle=poll, idle=halt, idle=nomwait
> @@ -5037,8 +5033,6 @@ Kernel parameters
> the specified number of seconds. This is to be used if
> your oopses keep scrolling off the screen.
>
> - pcbit= [HW,ISDN]
> -
> pci=option[,option...] [PCI,EARLY] various PCI subsystem options.
>
> Some options herein operate on a specific device
--
~Randy
^ permalink raw reply
* Re: [PATCH] Documentation: watchdog: Fix typo "oncse" -> "once"
From: Randy Dunlap @ 2026-05-02 16:32 UTC (permalink / raw)
To: Wang Zihan, linux-watchdog
Cc: wim, linux, corbet, skhan, linux-doc, linux-kernel
In-Reply-To: <tencent_61E8FB326F4582DB0074952B9FE4A239CE05@qq.com>
On 5/2/26 4:19 AM, Wang Zihan wrote:
> Fix a typo in mlx-wdt.rst documentation.
>
> Signed-off-by: Wang Zihan <3772548978@qq.com>
> ---
> Documentation/watchdog/mlx-wdt.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/watchdog/mlx-wdt.rst b/Documentation/watchdog/mlx-wdt.rst
> index 35e690dea..3778f85d1 100644
> --- a/Documentation/watchdog/mlx-wdt.rst
> +++ b/Documentation/watchdog/mlx-wdt.rst
> @@ -48,7 +48,7 @@ which is optional.
> Watchdog can be started during a probe, in this case it will be
> pinged by watchdog core before watchdog device will be opened by
> user space application.
> -Watchdog can be initialised in nowayout way, i.e. oncse started
> +Watchdog can be initialised in nowayout way, i.e. once started
> it can't be stopped.
>
> This mlx-wdt driver supports both HW watchdog implementations.
This typo is also fixed in my 5-patch series (pending).
--
~Randy
^ permalink raw reply
* Re: [PATCH v12 22/22] rust: maple_tree: implement Send and Sync for MapleTree
From: Alexandre Courbot @ 2026-05-02 15:42 UTC (permalink / raw)
To: Joel Fernandes
Cc: linux-kernel, Miguel Ojeda, Boqun Feng, Gary Guo, Bjorn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Dave Airlie, Daniel Almeida, dri-devel,
rust-for-linux, nova-gpu, Nikola Djukic, David Airlie, Boqun Feng,
John Hubbard, Alistair Popple, Timur Tabi, Edwin Peer,
Andrea Righi, Andy Ritger, Zhi Wang, Balbir Singh,
Philipp Stanner, alexeyi, Eliot Courtney, joel, linux-doc
In-Reply-To: <20260425211454.174696-23-joelagnelf@nvidia.com>
On Sun Apr 26, 2026 at 6:14 AM JST, Joel Fernandes wrote:
> The C maple_tree struct contains a *mut c_void, which prevents Rust from
> auto-deriving Send/Sync. Following is an example error message when using
> MapleTree in nova-core's Vmm.
>
> This propagates up through MapleTreeAlloc to Vmm, BarUser, Gpu, and NovaCore,
> causing NovaCore to fail the Send bound required by pci::Driver:
This patch is not at the right place - the last few patches of the
series won't build without it.
Besides you have sent it separately before this series, so just mention
it as a dependency in the cover letter, so reviewers can pick it up
before applying the series and not witness it breaking in the course of
reviewing it. The cover letter already mentions the bitfield series as a
dependency, so the same could have been done for this one.
^ permalink raw reply
* Re: [PATCH v12 21/22] gpu: nova-core: mm: pramin: drop useless as_ref() in run_self_test
From: Alexandre Courbot @ 2026-05-02 15:42 UTC (permalink / raw)
To: Joel Fernandes
Cc: linux-kernel, Miguel Ojeda, Boqun Feng, Gary Guo, Bjorn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Dave Airlie, Daniel Almeida, dri-devel,
rust-for-linux, nova-gpu, Nikola Djukic, David Airlie, Boqun Feng,
John Hubbard, Alistair Popple, Timur Tabi, Edwin Peer,
Andrea Righi, Andy Ritger, Zhi Wang, Balbir Singh,
Philipp Stanner, alexeyi, Eliot Courtney, joel, linux-doc
In-Reply-To: <20260425211454.174696-22-joelagnelf@nvidia.com>
On Sun Apr 26, 2026 at 6:14 AM JST, Joel Fernandes wrote:
> `pdev` is already `&device::Device<device::Bound>`, so calling `.as_ref()`
> on it just returns the same reference. Bind `dev` to `pdev` directly to
> silence the `clippy::useless_asref` warning.
Why is this a separate commit? It can, and should, be squashed into the
previous patch.
^ permalink raw reply
* Re: [PATCH v12 20/22] gpu: nova-core: mm: Add PRAMIN aperture self-tests
From: Alexandre Courbot @ 2026-05-02 15:42 UTC (permalink / raw)
To: Joel Fernandes
Cc: linux-kernel, Miguel Ojeda, Boqun Feng, Gary Guo, Bjorn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Dave Airlie, Daniel Almeida, dri-devel,
rust-for-linux, nova-gpu, Nikola Djukic, David Airlie, Boqun Feng,
John Hubbard, Alistair Popple, Timur Tabi, Edwin Peer,
Andrea Righi, Andy Ritger, Zhi Wang, Balbir Singh,
Philipp Stanner, alexeyi, Eliot Courtney, joel, linux-doc
In-Reply-To: <20260425211454.174696-21-joelagnelf@nvidia.com>
On Sun Apr 26, 2026 at 6:14 AM JST, Joel Fernandes wrote:
> Add self-tests for the PRAMIN aperture mechanism to verify correct
> operation during GPU probe. The tests validate various alignment
> requirements and corner cases.
>
> The tests are default disabled and behind CONFIG_NOVA_MM_SELFTESTS.
> When enabled, tests run after GSP boot during probe.
It makes sense for the PRAMIN self-test to be merged alongside PRAMIN
support (and also gives us a reason to merge PRAMIN as soon as it is
ready even if the rest of the series is still under review, as it
exercises the code).
Can you move this patch right after patch 4?
^ permalink raw reply
* Re: [PATCH v12 12/22] gpu: nova-core: mm: Add page table entry operation traits
From: Alexandre Courbot @ 2026-05-02 15:42 UTC (permalink / raw)
To: Joel Fernandes
Cc: linux-kernel, Miguel Ojeda, Boqun Feng, Gary Guo, Bjorn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Dave Airlie, Daniel Almeida, dri-devel,
rust-for-linux, nova-gpu, Nikola Djukic, David Airlie, Boqun Feng,
John Hubbard, Alistair Popple, Timur Tabi, Edwin Peer,
Andrea Righi, Andy Ritger, Zhi Wang, Balbir Singh,
Philipp Stanner, alexeyi, Eliot Courtney, joel, linux-doc
In-Reply-To: <20260425211454.174696-13-joelagnelf@nvidia.com>
On Sun Apr 26, 2026 at 6:14 AM JST, Joel Fernandes wrote:
> Introduce trait-based abstractions for GPU page table entries: PteOps,
> PdeOps, and DualPdeOps, along with the MmuConfig trait that ties them
> together with version-specific constants.
>
> Refactor the ver2 and ver3 page-table modules to implement these traits
> and expose the shared entry/PDE/PTE operations uniformly.
Please, no. We don't introduce code that gets refactored the very next
commit. This patch supersedes 270 lines of diff that reviewers will have
processed for nothing.
Please reorder things so they land, as much as possible, in their final
form. In this case this probably means defining the trait *before* the V2
and V3 page table definitions, so they can implement it from the get-go.
^ permalink raw reply
* Re: [PATCH v12 09/22] gpu: nova-core: mm: Add common types for all page table formats
From: Alexandre Courbot @ 2026-05-02 15:42 UTC (permalink / raw)
To: Joel Fernandes
Cc: linux-kernel, Miguel Ojeda, Boqun Feng, Gary Guo, Bjorn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Dave Airlie, Daniel Almeida, dri-devel,
rust-for-linux, nova-gpu, Nikola Djukic, David Airlie, Boqun Feng,
John Hubbard, Alistair Popple, Timur Tabi, Edwin Peer,
Andrea Righi, Andy Ritger, Zhi Wang, Balbir Singh,
Philipp Stanner, alexeyi, Eliot Courtney, joel, linux-doc
In-Reply-To: <20260425211454.174696-10-joelagnelf@nvidia.com>
On Sun Apr 26, 2026 at 6:14 AM JST, Joel Fernandes wrote:
> Add common page table types shared between MMU v2 and v3. These types
> are hardware-agnostic and used by both MMU versions.
>
> Cc: Nikola Djukic <ndjukic@nvidia.com>
> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
> ---
> drivers/gpu/nova-core/mm.rs | 1 +
> drivers/gpu/nova-core/mm/pagetable.rs | 157 ++++++++++++++++++++++++++
> 2 files changed, 158 insertions(+)
> create mode 100644 drivers/gpu/nova-core/mm/pagetable.rs
>
> diff --git a/drivers/gpu/nova-core/mm.rs b/drivers/gpu/nova-core/mm.rs
> index 8b8a86980bb6..045e35c92b78 100644
> --- a/drivers/gpu/nova-core/mm.rs
> +++ b/drivers/gpu/nova-core/mm.rs
> @@ -32,6 +32,7 @@ macro_rules! impl_pfn_bounded {
> };
> }
>
> +pub(super) mod pagetable;
> pub(crate) mod pramin;
> pub(super) mod tlb;
>
> diff --git a/drivers/gpu/nova-core/mm/pagetable.rs b/drivers/gpu/nova-core/mm/pagetable.rs
> new file mode 100644
> index 000000000000..637ff43ea83a
> --- /dev/null
> +++ b/drivers/gpu/nova-core/mm/pagetable.rs
> @@ -0,0 +1,157 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +//! Common page table types shared between MMU v2 and v3.
> +//!
> +//! This module provides foundational types used by both MMU versions:
> +//! - Page table level hierarchy
> +//! - Memory aperture types for PDEs and PTEs
> +
> +#![expect(dead_code)]
> +
> +use kernel::num::Bounded;
> +
> +use crate::gpu::Architecture;
> +
> +/// Extracts the page table index at a given level from a virtual address.
> +pub(super) trait VaLevelIndex {
> + /// Return the page table index at `level` for this virtual address.
> + fn level_index(&self, level: u64) -> u64;
> +}
> +
> +/// MMU version enumeration.
> +#[derive(Debug, Clone, Copy, PartialEq, Eq)]
> +pub(crate) enum MmuVersion {
> + /// MMU v2 for Turing/Ampere/Ada.
> + V2,
> + /// MMU v3 for Hopper and later.
> + V3,
> +}
> +
> +impl From<Architecture> for MmuVersion {
> + fn from(arch: Architecture) -> Self {
> + match arch {
> + Architecture::Turing | Architecture::Ampere | Architecture::Ada => Self::V2,
> + // In the future, uncomment the following to support V3.
> + // _ => Self::V3,
The architecture definitions for Blackwell are now in `drm-rust-next`,
so I think the next iteration can handle this.
Which reminds me: is V3 working? I remember some fixup by Eliot
wandering around, have you integrated it to the series?
^ permalink raw reply
* Re: [PATCH v12 08/22] gpu: nova-core: mm: Add GpuMm centralized memory manager
From: Alexandre Courbot @ 2026-05-02 15:42 UTC (permalink / raw)
To: Joel Fernandes
Cc: linux-kernel, Miguel Ojeda, Boqun Feng, Gary Guo, Bjorn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Dave Airlie, Daniel Almeida, dri-devel,
rust-for-linux, nova-gpu, Nikola Djukic, David Airlie, Boqun Feng,
John Hubbard, Alistair Popple, Timur Tabi, Edwin Peer,
Andrea Righi, Andy Ritger, Zhi Wang, Balbir Singh,
Philipp Stanner, alexeyi, Eliot Courtney, joel, linux-doc
In-Reply-To: <20260425211454.174696-9-joelagnelf@nvidia.com>
On Sun Apr 26, 2026 at 6:14 AM JST, Joel Fernandes wrote:
> Introduce GpuMm as the centralized GPU memory manager that owns:
> - Buddy allocator for VRAM allocation.
> - PRAMIN window for direct VRAM access.
> - TLB manager for translation buffer operations.
>
> This provides clean ownership model where GpuMm provides accessor
> methods for its components that can be used for memory management
> operations.
>
> Cc: Nikola Djukic <ndjukic@nvidia.com>
> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
> ---
> drivers/gpu/nova-core/Kconfig | 1 +
> drivers/gpu/nova-core/gpu.rs | 28 +++++++++++
> drivers/gpu/nova-core/gsp/commands.rs | 1 -
> drivers/gpu/nova-core/mm.rs | 69 ++++++++++++++++++++++++++-
> drivers/gpu/nova-core/mm/pramin.rs | 20 ++++----
Why does this need to edit `pramin.rs`? This is the first user, so can't
we give pramin its useful form from the start? These changes on
`pramin.rs` apply perfectly fine on top of patch 4, so there is no
reason not to squash them there.
Reviewers read patch 4, build a mental model of it and write feedback,
and this model is immediately altered without even being used. Please
don't do that.
^ permalink raw reply
* Re: [PATCH v12 07/22] gpu: nova-core: mm: Add TLB flush support
From: Alexandre Courbot @ 2026-05-02 15:42 UTC (permalink / raw)
To: Joel Fernandes
Cc: linux-kernel, Miguel Ojeda, Boqun Feng, Gary Guo, Bjorn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Dave Airlie, Daniel Almeida, dri-devel,
rust-for-linux, nova-gpu, Nikola Djukic, David Airlie, Boqun Feng,
John Hubbard, Alistair Popple, Timur Tabi, Edwin Peer,
Andrea Righi, Andy Ritger, Zhi Wang, Balbir Singh,
Philipp Stanner, alexeyi, Eliot Courtney, joel, linux-doc
In-Reply-To: <20260425211454.174696-8-joelagnelf@nvidia.com>
On Sun Apr 26, 2026 at 6:14 AM JST, Joel Fernandes wrote:
<snip>
> + /// TLB flush control register.
> + pub(crate) NV_TLB_FLUSH_CTRL(u32) @ 0x00b830b0 {
> + /// Invalidate every VA in the PDB selected by `NV_TLB_FLUSH_PDB_LO/HI`.
> + 0:0 all_va => bool;
> + /// Invalidate TLBs for all PDBs (ignores `NV_TLB_FLUSH_PDB_LO/HI`).
> + 1:1 all_pdb => bool;
> + /// Restrict the flush to the HUB MMU's TLBs; skip broadcasting to the
> + /// per-GPC L2 TLBs.
> + ///
> + /// The GPU MMU has a two-level TLB hierarchy:
> + /// 1. The *HUB MMU* sits at the top and serves memory requests from
> + /// "host-side" engines: the host/channel interface, copy engines,
> + /// display, and BAR1/BAR2 accesses.
> + /// 2. Each GPC (Graphics Processing Cluster — the block that houses
> + /// shader cores / SMs) has its own L2 TLB that serves requests from
> + /// the compute and graphics engines inside the cluster.
> + ///
> + /// When set, only the HUB TLBs are invalidated. This is a performance
> + /// optimization for flushes that only affect HUB-side mappings (e.g.
> + /// BAR1/BAR2 windows), where fanning the invalidation out to every
> + /// GPC's L2 TLB would be wasted work. Must be false when flushing
> + /// mappings that may be cached by compute/graphics engines.
> + 2:2 hubtlb_only => bool;
> + /// Invalidation acknowledgment scope. See [`TlbAckMode`] for details.
> + 8:7 ack ?=> TlbAckMode;
> + /// Write 1 to kick off the flush. Hardware clears this bit when the
> + /// flush completes; reads as 1 while the flush is in progress.
> + 31:31 trigger => bool;
> + }
> +}
Registers should be defined with their upper fields first (i.e. `31:31`
on top).
^ permalink raw reply
* Re: [PATCH v12 04/22] gpu: nova-core: mm: Add support to use PRAMIN windows to write to VRAM
From: Alexandre Courbot @ 2026-05-02 15:41 UTC (permalink / raw)
To: Joel Fernandes
Cc: linux-kernel, Miguel Ojeda, Boqun Feng, Gary Guo, Bjorn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Dave Airlie, Daniel Almeida, dri-devel,
rust-for-linux, nova-gpu, Nikola Djukic, David Airlie, Boqun Feng,
John Hubbard, Alistair Popple, Timur Tabi, Edwin Peer,
Andrea Righi, Andy Ritger, Zhi Wang, Balbir Singh,
Philipp Stanner, alexeyi, Eliot Courtney, joel, linux-doc
In-Reply-To: <20260425211454.174696-5-joelagnelf@nvidia.com>
On Sun Apr 26, 2026 at 6:14 AM JST, Joel Fernandes wrote:
<snip>
> PRAMIN apertures are a crucial mechanism to direct read/write to VRAM.
> Add support for the same.
>
> Cc: Nikola Djukic <ndjukic@nvidia.com>
> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
> ---
> drivers/gpu/nova-core/mm.rs | 5 +
> drivers/gpu/nova-core/mm/pramin.rs | 300 +++++++++++++++++++++++++++++
> drivers/gpu/nova-core/nova_core.rs | 1 +
> drivers/gpu/nova-core/regs.rs | 10 +
> 4 files changed, 316 insertions(+)
> create mode 100644 drivers/gpu/nova-core/mm.rs
> create mode 100644 drivers/gpu/nova-core/mm/pramin.rs
>
> diff --git a/drivers/gpu/nova-core/mm.rs b/drivers/gpu/nova-core/mm.rs
> new file mode 100644
> index 000000000000..7a5dd4220c67
> --- /dev/null
> +++ b/drivers/gpu/nova-core/mm.rs
> @@ -0,0 +1,5 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +//! Memory management subsystems for nova-core.
> +
> +pub(crate) mod pramin;
> diff --git a/drivers/gpu/nova-core/mm/pramin.rs b/drivers/gpu/nova-core/mm/pramin.rs
> new file mode 100644
> index 000000000000..57b560ae1e85
> --- /dev/null
> +++ b/drivers/gpu/nova-core/mm/pramin.rs
> @@ -0,0 +1,300 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +//! Direct VRAM access through the PRAMIN aperture.
> +//!
> +//! PRAMIN provides a 1MB sliding window into VRAM through BAR0, allowing the CPU to access
> +//! video memory directly. Access is managed through a two-level API:
> +//!
> +//! - [`Pramin`]: The parent object that owns the BAR0 reference and synchronization lock.
> +//! - [`PraminWindow`]: A guard object that holds exclusive PRAMIN access for its lifetime.
> +//!
> +//! The PRAMIN aperture is a 1MB region at a fixed offset from BAR0. The window base is
> +//! controlled by an architecture-specific register and is 64KB aligned.
> +//!
> +//! # Examples
> +//!
> +//! ## Basic read/write
> +//!
> +//! ```no_run
> +//! use crate::driver::Bar0;
> +//! use crate::gpu::Chipset;
> +//! use crate::mm::pramin;
> +//! use kernel::device;
> +//! use kernel::devres::Devres;
> +//! use kernel::prelude::*;
> +//! use kernel::sync::Arc;
> +//!
> +//! fn example(
> +//! devres_bar: Arc<Devres<Bar0>>,
> +//! dev: &device::Device<device::Bound>,
> +//! chipset: Chipset,
> +//! vram_region: core::ops::Range<u64>,
> +//! ) -> Result<()> {
> +//! let pramin = Arc::pin_init(
> +//! pramin::Pramin::new(devres_bar, dev, chipset, vram_region)?,
`Pramin::new` takes different arguments (also check the other examples).
> +//! GFP_KERNEL,
> +//! )?;
> +//! let mut window = pramin.get_window(dev)?;
> +//!
> +//! // Write and read back.
> +//! window.try_write32(0x100, 0xDEADBEEF)?;
> +//! let val = window.try_read32(0x100)?;
> +//! assert_eq!(val, 0xDEADBEEF);
> +//!
> +//! Ok(())
> +//! }
> +//! ```
> +//!
> +//! ## Auto-repositioning across VRAM regions
> +//!
> +//! ```no_run
> +//! use crate::driver::Bar0;
> +//! use crate::gpu::Chipset;
> +//! use crate::mm::pramin;
> +//! use kernel::device;
> +//! use kernel::devres::Devres;
> +//! use kernel::prelude::*;
> +//! use kernel::sync::Arc;
> +//!
> +//! fn example(
> +//! devres_bar: Arc<Devres<Bar0>>,
> +//! dev: &device::Device<device::Bound>,
> +//! chipset: Chipset,
> +//! vram_region: core::ops::Range<u64>,
> +//! ) -> Result<()> {
> +//! let pramin = Arc::pin_init(
> +//! pramin::Pramin::new(devres_bar, dev, chipset, vram_region)?,
> +//! GFP_KERNEL,
> +//! )?;
> +//! let mut window = pramin.get_window(dev)?;
> +//!
> +//! // Access first 1MB region.
> +//! window.try_write32(0x100, 0x11111111)?;
> +//!
> +//! // Access at 2MB - window auto-repositions.
> +//! window.try_write32(0x200000, 0x22222222)?;
> +//!
> +//! // Back to first region - window repositions again.
> +//! let val = window.try_read32(0x100)?;
> +//! assert_eq!(val, 0x11111111);
> +//!
> +//! Ok(())
> +//! }
> +//! ```
> +
> +#![expect(unused)]
> +
> +use core::ops::Range;
> +
> +use crate::{
> + bounded_enum,
> + driver::Bar0,
> + num::IntoSafeCast,
> + regs, //
> +};
> +
> +use kernel::{
> + devres::Devres,
> + io::Io,
> + new_mutex,
> + num::Bounded,
> + prelude::*,
> + revocable::RevocableGuard,
> + sizes::{
> + SZ_1M,
> + SZ_64K, //
> + },
> + sync::{
> + lock::mutex::MutexGuard,
> + Arc,
> + Mutex, //
> + },
> +};
> +
> +bounded_enum! {
> + /// Target memory type for the BAR0 window register.
> + ///
> + /// Only VRAM is supported; Hopper+ GPUs do not support other targets.
> + #[derive(Debug)]
> + pub(crate) enum Bar0WindowTarget with TryFrom<Bounded<u32, 2>> {
> + /// Video RAM (GPU framebuffer memory).
> + Vram = 0,
> + }
> +}
> +
> +/// PRAMIN aperture base offset in BAR0.
> +const PRAMIN_BASE: usize = 0x700000;
> +
> +/// PRAMIN aperture size (1MB).
> +const PRAMIN_SIZE: usize = SZ_1M;
> +
> +/// Generate a PRAMIN read accessor.
> +macro_rules! define_pramin_read {
> + ($name:ident, $ty:ty) => {
> + #[doc = concat!("Read a `", stringify!($ty), "` from VRAM at the given offset.")]
> + pub(crate) fn $name(&mut self, vram_offset: usize) -> Result<$ty> {
> + let (bar_offset, new_base) =
> + self.compute_window(vram_offset, ::core::mem::size_of::<$ty>())?;
> +
> + if let Some(base) = new_base {
> + Self::write_window_base(&self.bar, base)?;
> + *self.state = base;
> + }
> + self.bar.$name(bar_offset)
> + }
> + };
> +}
> +
> +/// Generate a PRAMIN write accessor.
> +macro_rules! define_pramin_write {
> + ($name:ident, $ty:ty) => {
> + #[doc = concat!("Write a `", stringify!($ty), "` to VRAM at the given offset.")]
> + pub(crate) fn $name(&mut self, vram_offset: usize, value: $ty) -> Result {
> + let (bar_offset, new_base) =
> + self.compute_window(vram_offset, ::core::mem::size_of::<$ty>())?;
> +
> + if let Some(base) = new_base {
> + Self::write_window_base(&self.bar, base)?;
> + *self.state = base;
> + }
> + self.bar.$name(value, bar_offset)
> + }
> + };
> +}
> +
> +/// PRAMIN aperture manager.
> +///
> +/// Call [`Pramin::get_window()`] to acquire exclusive PRAMIN access.
> +#[pin_data]
> +pub(crate) struct Pramin {
> + bar: Arc<Devres<Bar0>>,
The HRT series [1] will allow you to greatly simplify all this by
storing a `&'a Bar0` directly in this structure. It will most likely
land this cycle, so I think it's a good idea to proactively depend on
them. It should apply cleanly (modulo the Tyr patches IIRC, but you can
skip them if you don't build the driver) on top of `drm-rust-next` - on
top of which this should also be rebased anyway.
[1] https://lore.kernel.org/all/20260427221155.2144848-1-dakr@kernel.org/
> + /// Valid VRAM region. Accesses outside this range are rejected.
> + vram_region: Range<u64>,
I don't think that checking the range in this type is particularly
useful, because this abstraction cannot validate VRAM ownership
completely: VRAM can be sparse, reserved, or protected, and with the
current bound access to these invalid areas is not prevented.
PRAMIN should only model the hardware windowing mechanism; address
validity belongs to the higher layers that allocate or obtain those
addresses. IIUC nothing will explode if we try to read or write into
areas that are not VRAM.
> + /// PRAMIN aperture state, protected by a mutex.
> + ///
> + /// # Invariants
> + ///
> + /// This lock is acquired during the DMA fence signaling critical path.
> + /// It must NEVER be held across any reclaimable CPU memory / allocations
> + /// (`GFP_KERNEL`), because the memory reclaim path can call
> + /// `dma_fence_wait()`, which would deadlock with this lock held.
> + #[pin]
> + state: Mutex<u64>,
The problem with this lock is that it is buried, alongside its usage
guide, deep into this type, ensuring that users won't ever see it. It
will create deadlocks rather than preventing them.
And when you look closer at it, you realize it is actually acquired for
any use of `Pramin`, since the only method it exposes is `get_window`,
which acquires the lock, and returns a `PraminWindow` which has exactly
the same layout as `Pramin`, except that the lock is acquired.
So what's the point? Let's just make `get_window` require a `&mut self`
and let the owner of `Pramin` decide how to manage concurrent accesses.
At least the doccomment for the lock will be visible from a higher
layer.
Currently `Pramin` mixes elements of hardware access, memory management,
and synchronization into the same type, squashing what should be
different layers into a single one. Now that the `Io` trait is merged
and available in `drm-rust-next`, it is a good time to implement the
feedback I gave on v8. Roughly:
- `Pramin` should just be the owner and arbiter of the
`NV_PBUS_BAR0_WINDOW` register. Its `get_window(&mut self,
window_base: Bounded<u64, 24>)` method simply returns a window to the
1MB area starting from `base << 16`. It's the simplest possible
abstraction.
- The returned window implements `Io` and `IoKnownSize`. This will allow
users to do all the fancy stuff that comes with `Io`, including
projections.
This API will also be perfect for cases like e.g. setting a memory
page to zero: just give the start of the page to `get_window`, zap the
first 4K of the window, done.
- Random accesses to VRAM, which are needed for walking the page tables
and updating them, can be built on top of this simple API. Either by
adding read/write ops directly to `Pramin`, or by defining another
type that owns a `&mut Pramin` and moves the window automatically if
the next access is out of bounds. This should result in window
management code that is simpler than the current `compute_window`.
That's really all we need. Then `GpuMm` can manage concurrency similarly
to the current model by wrapping `Pramin` inside a `Mutex`, and is also
free to experiment with different locking strategies, something the
current design doesn't allow.
> +}
> +
> +impl Pramin {
> + /// Create a pin-initializer for PRAMIN.
> + ///
> + /// `vram_region` specifies the valid VRAM address range.
> + pub(crate) fn new(
> + bar: Arc<Devres<Bar0>>,
> + vram_region: Range<u64>,
> + ) -> Result<impl PinInit<Self>> {
> + let bar_access = bar.try_access().ok_or(ENODEV)?;
> + let current_base = Self::read_window_base(&bar_access);
> +
> + Ok(pin_init!(Self {
> + bar,
> + vram_region,
> + state <- new_mutex!(current_base, "pramin_state"),
> + }))
> + }
> +
> + /// Acquire exclusive PRAMIN access.
> + ///
> + /// Returns a [`PraminWindow`] guard that provides VRAM read/write accessors.
> + /// The [`PraminWindow`] is exclusive and only one can exist at a time.
> + pub(crate) fn get_window(&self) -> Result<PraminWindow<'_>> {
> + let bar = self.bar.try_access().ok_or(ENODEV)?;
> + let state = self.state.lock();
> + Ok(PraminWindow {
> + bar,
> + vram_region: self.vram_region.clone(),
> + state,
> + })
> + }
> +
> + /// Read the current window base from the BAR0_WINDOW register.
> + fn read_window_base(bar: &Bar0) -> u64 {
> + let reg = bar.read(regs::NV_PBUS_BAR0_WINDOW);
> +
> + // TODO: Convert to Bounded<u64, 40> when available.
It's available. :)
> + u64::from(reg.window_base()) << 16
> + }
I think this method (and `write_window_base`) should be methods of the
`NV_PBUS_BAR0_WINDOW` register (`window_base` and `set_window_base`)
> +}
> +
> +/// PRAMIN window guard for direct VRAM access.
> +///
> +/// This guard holds exclusive access to the PRAMIN aperture. The window auto-repositions
> +/// when accessing VRAM offsets outside the current 1MB range.
> +///
> +/// Only one [`PraminWindow`] can exist at a time per [`Pramin`] instance (enforced by the
> +/// internal `MutexGuard`).
> +pub(crate) struct PraminWindow<'a> {
> + bar: RevocableGuard<'a, Bar0>,
> + vram_region: Range<u64>,
> + state: MutexGuard<'a, u64>,
> +}
> +
> +impl PraminWindow<'_> {
> + /// Write a new window base to the BAR0_WINDOW register.
> + fn write_window_base(bar: &Bar0, base: u64) -> Result {
> + // CAST: After >> 16, a VRAM address fits in u32.
> + let window_base = (base >> 16) as u32;
> + bar.write_reg(
> + regs::NV_PBUS_BAR0_WINDOW::zeroed()
> + .with_target(Bar0WindowTarget::Vram)
> + .try_with_window_base(window_base)?,
> + );
> + Ok(())
> + }
> +
> + /// Compute window parameters for a VRAM access.
> + ///
> + /// Returns (`bar_offset`, `new_base`) where:
> + /// - `bar_offset`: The BAR0 offset to use for the access.
> + /// - `new_base`: `Some(base)` if window needs repositioning, `None` otherwise.
> + fn compute_window(
> + &self,
> + vram_offset: usize,
This should be a `u64`, since it is a VRAM address.
Actually, I noticed that you introduced a `VramAddress` type in a latter
patch. It might be worth introducing it earlier and using it everywhere
a VRAM address is involved, that way we cannot make any mistake - not
critical for now, but feel free to do it if you think it helps.
^ permalink raw reply
* Re: [PATCH v12 03/22] gpu: nova-core: gsp: Expose total physical VRAM end from FB region info
From: Alexandre Courbot @ 2026-05-02 15:41 UTC (permalink / raw)
To: Joel Fernandes
Cc: linux-kernel, Miguel Ojeda, Boqun Feng, Gary Guo, Bjorn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Dave Airlie, Daniel Almeida, dri-devel,
rust-for-linux, nova-gpu, Nikola Djukic, David Airlie, Boqun Feng,
John Hubbard, Alistair Popple, Timur Tabi, Edwin Peer,
Andrea Righi, Andy Ritger, Zhi Wang, Balbir Singh,
Philipp Stanner, alexeyi, Eliot Courtney, joel, linux-doc
In-Reply-To: <20260425211454.174696-4-joelagnelf@nvidia.com>
On Sun Apr 26, 2026 at 6:14 AM JST, Joel Fernandes wrote:
> Add `total_fb_end()` to `GspStaticConfigInfo` that computes the
> exclusive end address of the highest valid FB region covering both
> usable and GSP-reserved areas.
>
> This allows callers to know the full physical VRAM extent, not just
> the allocatable portion.
>
> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
> ---
> drivers/gpu/nova-core/gpu.rs | 12 +++++++++++-
> drivers/gpu/nova-core/gsp/commands.rs | 5 +++++
> drivers/gpu/nova-core/gsp/fw/commands.rs | 7 +++++++
> 3 files changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/nova-core/gpu.rs b/drivers/gpu/nova-core/gpu.rs
> index f2a8915a1ff4..675a0676f032 100644
> --- a/drivers/gpu/nova-core/gpu.rs
> +++ b/drivers/gpu/nova-core/gpu.rs
> @@ -273,7 +273,17 @@ pub(crate) fn new<'a>(
>
> gsp <- Gsp::new(pdev),
>
> - gsp_static_info: { gsp.boot(pdev, bar, spec.chipset, gsp_falcon, sec2_falcon)? },
> + gsp_static_info: {
> + let info = gsp.boot(pdev, bar, spec.chipset, gsp_falcon, sec2_falcon)?;
> +
> + dev_info!(
> + pdev.as_ref(),
> + "Total physical VRAM: {} MiB\n",
> + info.total_fb_end >> 20
`info.total_fb_end / u64::SZ_1M` (after importing `kernel::sizes::SizeConstants`) would carry the intent better.
> + );
> +
> + info
> + },
Let's use `inspect`:
gsp_static_info: gsp.boot(pdev, bar, spec.chipset, gsp_falcon, sec2_falcon)
.inspect(|info|
dev_info!(
pdev.as_ref(),
"Total physical VRAM: {} MiB\n",
info.total_fb_end / u64::SZ_1M
)
)?,
If we combine these 3 first patches with the series enabling calls from
nova-drm to nova-core, we should be able to implement a `TOTAL_VRAM`
argument to `GET_PARAM` that would be the first example of an actual
Nova ioctl using real information from the GSP (granted, with an
unstable interface). Looking forward to this.
^ permalink raw reply
* Re: [PATCH v12 02/22] gpu: nova-core: gsp: Extract usable FB region from GSP
From: Alexandre Courbot @ 2026-05-02 15:41 UTC (permalink / raw)
To: Joel Fernandes
Cc: linux-kernel, Miguel Ojeda, Boqun Feng, Gary Guo, Bjorn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Dave Airlie, Daniel Almeida, dri-devel,
rust-for-linux, nova-gpu, Nikola Djukic, David Airlie, Boqun Feng,
John Hubbard, Alistair Popple, Timur Tabi, Edwin Peer,
Andrea Righi, Andy Ritger, Zhi Wang, Balbir Singh,
Philipp Stanner, alexeyi, Eliot Courtney, joel, linux-doc
In-Reply-To: <20260425211454.174696-3-joelagnelf@nvidia.com>
On Sun Apr 26, 2026 at 6:14 AM JST, Joel Fernandes wrote:
> Add first_usable_fb_region() to GspStaticConfigInfo to extract the first
> usable FB region from GSP's fbRegionInfoParams. Usable regions are those
> that are not reserved or protected.
>
> The extracted region is stored in GetGspStaticInfoReply and exposed as
> usable_fb_region field for use by the memory subsystem.
>
> Cc: Nikola Djukic <ndjukic@nvidia.com>
> Reviewed-by: John Hubbard <jhubbard@nvidia.com>
> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
> ---
> drivers/gpu/nova-core/gsp/commands.rs | 11 ++++--
> drivers/gpu/nova-core/gsp/fw/commands.rs | 45 +++++++++++++++++++++++-
> 2 files changed, 52 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/nova-core/gsp/commands.rs b/drivers/gpu/nova-core/gsp/commands.rs
> index c89c7b57a751..d18abd8b5f04 100644
> --- a/drivers/gpu/nova-core/gsp/commands.rs
> +++ b/drivers/gpu/nova-core/gsp/commands.rs
> @@ -4,6 +4,7 @@
> array,
> convert::Infallible,
> ffi::FromBytesUntilNulError,
> + ops::Range,
> str::Utf8Error, //
> };
>
> @@ -189,15 +190,18 @@ fn init(&self) -> impl Init<Self::Command, Self::InitError> {
> }
> }
>
> -/// The reply from the GSP to the [`GetGspInfo`] command.
> +/// The reply from the GSP to the [`GetGspStaticInfo`] command.
> pub(crate) struct GetGspStaticInfoReply {
> gpu_name: [u8; 64],
> + /// Usable FB (VRAM) region for driver memory allocation.
> + #[expect(dead_code)]
> + pub(crate) usable_fb_region: Range<u64>,
> }
>
> impl MessageFromGsp for GetGspStaticInfoReply {
> const FUNCTION: MsgFunction = MsgFunction::GetGspStaticInfo;
> type Message = GspStaticConfigInfo;
> - type InitError = Infallible;
> + type InitError = Error;
>
> fn read(
> msg: &Self::Message,
> @@ -205,6 +209,7 @@ fn read(
> ) -> Result<Self, Self::InitError> {
> Ok(GetGspStaticInfoReply {
> gpu_name: msg.gpu_name_str(),
> + usable_fb_region: msg.first_usable_fb_region().ok_or(ENODEV)?,
> })
> }
> }
> @@ -233,7 +238,7 @@ pub(crate) fn gpu_name(&self) -> core::result::Result<&str, GpuNameError> {
> }
> }
>
> -/// Send the [`GetGspInfo`] command and awaits for its reply.
> +/// Send the [`GetGspStaticInfo`] command and awaits for its reply.
> pub(crate) fn get_gsp_info(cmdq: &Cmdq, bar: &Bar0) -> Result<GetGspStaticInfoReply> {
> cmdq.send_command(bar, GetGspStaticInfo)
> }
> diff --git a/drivers/gpu/nova-core/gsp/fw/commands.rs b/drivers/gpu/nova-core/gsp/fw/commands.rs
> index db46276430be..a34d29280430 100644
> --- a/drivers/gpu/nova-core/gsp/fw/commands.rs
> +++ b/drivers/gpu/nova-core/gsp/fw/commands.rs
> @@ -1,5 +1,7 @@
> // SPDX-License-Identifier: GPL-2.0
>
> +use core::ops::Range;
> +
> use kernel::{
> device,
> pci,
> @@ -10,7 +12,10 @@
> }, //
> };
>
> -use crate::gsp::GSP_PAGE_SIZE;
> +use crate::{
> + gsp::GSP_PAGE_SIZE,
> + num::IntoSafeCast, //
> +};
>
> use super::bindings;
>
> @@ -121,6 +126,44 @@ impl GspStaticConfigInfo {
> pub(crate) fn gpu_name_str(&self) -> [u8; 64] {
> self.0.gpuNameString
> }
> +
> + /// Returns an iterator over valid FB regions from GSP firmware data.
> + fn fb_regions(
> + &self,
> + ) -> impl Iterator<Item = &bindings::NV2080_CTRL_CMD_FB_GET_FB_REGION_FB_REGION_INFO> {
> + let fb_info = &self.0.fbRegionInfoParams;
> + fb_info
> + .fbRegion
> + .iter()
> + .take(fb_info.numFBRegions.into_safe_cast())
> + .filter(|reg| reg.limit >= reg.base)
> + }
> +
> + /// Extracts the first usable FB region from GSP firmware data.
> + ///
> + /// Returns the first region suitable for driver memory allocation as a [`Range<u64>`].
> + /// Usable regions are those that satisfy all the following properties:
> + /// - Are not reserved for firmware internal use.
> + /// - Are not protected (hardware-enforced access restrictions).
> + /// - Support compression (can use GPU memory compression for bandwidth).
"can use GPU memory compression for saving bandwidth" maybe?
> + /// - Support ISO (isochronous memory for display requiring guaranteed bandwidth).
> + ///
> + /// TODO: Multiple discontinuous usable regions of RAM are possible in
> + /// special cases. We need to support it.
> + pub(crate) fn first_usable_fb_region(&self) -> Option<Range<u64>> {
Let's be forward-thinking, and turn this method into
`usable_fb_regions_iter`, returning an iterator. It is trivial to do
(just turn `find_map` into `filter`), we will need it later, and for now
the caller can just do `next()` to get the first region.
^ permalink raw reply
* Re: [PATCH v12 01/22] gpu: nova-core: gsp: Return GspStaticInfo from boot()
From: Alexandre Courbot @ 2026-05-02 15:41 UTC (permalink / raw)
To: Joel Fernandes
Cc: linux-kernel, Miguel Ojeda, Boqun Feng, Gary Guo, Bjorn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Dave Airlie, Daniel Almeida, dri-devel,
rust-for-linux, nova-gpu, Nikola Djukic, David Airlie, Boqun Feng,
John Hubbard, Alistair Popple, Timur Tabi, Edwin Peer,
Andrea Righi, Andy Ritger, Zhi Wang, Balbir Singh,
Philipp Stanner, alexeyi, Eliot Courtney, joel, linux-doc
In-Reply-To: <20260425211454.174696-2-joelagnelf@nvidia.com>
On Sun Apr 26, 2026 at 6:14 AM JST, Joel Fernandes wrote:
> Refactor the GSP boot function to return GetGspStaticInfoReply.
>
> This enables access required for memory management initialization to:
> - bar1_pde_base: BAR1 page directory base.
> - bar2_pde_base: BAR2 page directory base.
> - usable memory regions in video memory.
>
> Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
> Reviewed-by: John Hubbard <jhubbard@nvidia.com>
> Cc: Nikola Djukic <ndjukic@nvidia.com>
> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
> ---
> drivers/gpu/nova-core/gpu.rs | 8 ++++++--
> drivers/gpu/nova-core/gsp/boot.rs | 12 ++++++++----
> 2 files changed, 14 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/nova-core/gpu.rs b/drivers/gpu/nova-core/gpu.rs
> index 0f6fe9a1b955..f2a8915a1ff4 100644
> --- a/drivers/gpu/nova-core/gpu.rs
> +++ b/drivers/gpu/nova-core/gpu.rs
> @@ -21,7 +21,10 @@
> },
> fb::SysmemFlush,
> gfw,
> - gsp::Gsp,
> + gsp::{
> + commands::GetGspStaticInfoReply,
> + Gsp, //
> + },
> regs,
> };
>
> @@ -238,6 +241,7 @@ pub(crate) struct Gpu {
> /// GSP runtime data. Temporarily an empty placeholder.
> #[pin]
> gsp: Gsp,
> + gsp_static_info: GetGspStaticInfoReply,
A short doccomment would be nice, but otherwise this looks good.
^ permalink raw reply
* Re: [PATCH] Documentation: watchdog: Fix typo "oncse" -> "once"
From: Guenter Roeck @ 2026-05-02 14:49 UTC (permalink / raw)
To: Wang Zihan, linux-watchdog; +Cc: wim, corbet, skhan, linux-doc, linux-kernel
In-Reply-To: <tencent_61E8FB326F4582DB0074952B9FE4A239CE05@qq.com>
On 5/2/26 04:19, Wang Zihan wrote:
> Fix a typo in mlx-wdt.rst documentation.
>
> Signed-off-by: Wang Zihan <3772548978@qq.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
^ permalink raw reply
* Re: [PATCH v2] net: switchdev: fix duplicate word in documentation
From: Jonas Gorski @ 2026-05-02 14:32 UTC (permalink / raw)
To: Andrew Lunn, Björn Persson; +Cc: Wang Zihan, netdev, linux-doc, kuba
In-Reply-To: <a5482c59-2a35-44ce-b112-9c07e8ca7892@lunn.ch>
On 02/05/2026 16:09, Andrew Lunn wrote:
> On Sat, May 02, 2026 at 01:24:46PM +0200, Björn Persson wrote:
>> Wang Zihan wrote:
>>> @@ -162,7 +162,7 @@ The switchdev driver can know a particular port's position in the topology by
>>> monitoring NETDEV_CHANGEUPPER notifications. For example, a port moved into a
>>> bond will see its upper master change. If that bond is moved into a bridge,
>>> the bond's upper master will change. And so on. The driver will track such
>>> -movements to know what position a port is in in the overall topology by
>>> +movements to know what position a port is in the overall topology by
>>> registering for netdevice events and acting on NETDEV_CHANGEUPPER.
>>>
>>> L2 Forwarding Offload
>>
>> This change claims that a port is a position. The preceding sentences,
>> talking about "a particular port's position" and a port being moved,
>> make it clear that a port is *in* a position *in* the topology. The
>> port is not itself a position.
>
> I assume this is a fix to make a bot happy, without actually checking
> if the bot is correct.
>
> Maybe to prevent a recurrence of the bot driver not validating the bot
> output, a ',' should be added?
I'm not a native speaker, but I think moving the first "in" would also
work:
"... to know in what position a port is in the overall topology ..."
Best regards,
Jonas
^ permalink raw reply
* Re: [PATCH] Documentation: Fix duplicated words
From: Andrew Lunn @ 2026-05-02 14:16 UTC (permalink / raw)
To: Wang Zihan
Cc: netdev, linux-doc, linux-media, linux-um, davem, edumazet, kuba,
pabeni, horms, corbet, skhan, mchehab, richard, anton.ivanov,
johannes, linux-kernel
In-Reply-To: <tencent_B1D6CBBF95486E31D04C2E1B92F5E605A307@qq.com>
On Sat, May 02, 2026 at 07:19:16PM +0800, Wang Zihan wrote:
> Remove duplicated words in three documentation files:
> - "in in" -> "in" (switchdev.rst)
> - "The the" -> "The" (dmx-reqbufs.rst)
> - "on on" -> "on" (user_mode_linux_howto_v2.rst)
https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
* don’t repost your patches within one 24h period
We have already told you one of the fixes is wrong, but you did not
wait 24 hours, so have not see our feedback.
Also, in general when using a tool, assume it is wrong, and convince
yourself it is correct, before making a change. "The the in this
sentence is the subject." What does the bot make of that? Can you
convince yourself the bot is correct?
Andrew
---
pw-bot: cr
^ permalink raw reply
* Re: [PATCH v2] net: switchdev: fix duplicate word in documentation
From: Andrew Lunn @ 2026-05-02 14:09 UTC (permalink / raw)
To: Björn Persson; +Cc: Wang Zihan, netdev, linux-doc, kuba
In-Reply-To: <20260502132446.5b2c51cf@tag.xn--rombobjrn-67a.se>
On Sat, May 02, 2026 at 01:24:46PM +0200, Björn Persson wrote:
> Wang Zihan wrote:
> > @@ -162,7 +162,7 @@ The switchdev driver can know a particular port's position in the topology by
> > monitoring NETDEV_CHANGEUPPER notifications. For example, a port moved into a
> > bond will see its upper master change. If that bond is moved into a bridge,
> > the bond's upper master will change. And so on. The driver will track such
> > -movements to know what position a port is in in the overall topology by
> > +movements to know what position a port is in the overall topology by
> > registering for netdevice events and acting on NETDEV_CHANGEUPPER.
> >
> > L2 Forwarding Offload
>
> This change claims that a port is a position. The preceding sentences,
> talking about "a particular port's position" and a port being moved,
> make it clear that a port is *in* a position *in* the topology. The
> port is not itself a position.
I assume this is a fix to make a bot happy, without actually checking
if the bot is correct.
Maybe to prevent a recurrence of the bot driver not validating the bot
output, a ',' should be added?
Andrew
---
pw-bot: cr
^ permalink raw reply
* [PATCH] doc/pstore: Fix parameter names in examples
From: Jörg Sommer @ 2026-05-02 12:52 UTC (permalink / raw)
To: keescook, corbet; +Cc: linux-doc
Signed-off-by: Jörg Sommer <joerg@jo-so.de>
---
Documentation/admin-guide/pstore-blk.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/pstore-blk.rst b/Documentation/admin-guide/pstore-blk.rst
index 1bb2a1c292aa..5c247c25e13a 100644
--- a/Documentation/admin-guide/pstore-blk.rst
+++ b/Documentation/admin-guide/pstore-blk.rst
@@ -35,7 +35,7 @@ module parameters have priority over Kconfig.
Here is an example for module parameters::
- pstore_blk.blkdev=/dev/mmcblk0p7 pstore_blk.kmsg_size=64 best_effort=y
+ pstore_blk.blkdev=/dev/mmcblk0p7 pstore_blk.kmsg_size=64 pstore_blk.best_effort=y
The detail of each configurations may be of interest to you.
--
2.53.0
^ permalink raw reply related
* [PATCH] Documentation: translations: Fix "Linux Torvalds" -> "Linus Torvalds"
From: Wang Zihan @ 2026-05-02 13:11 UTC (permalink / raw)
To: linux-doc
Cc: federico.vaga, corbet, skhan, carlos.bilbao, avadhut.naik,
linux-kernel, Wang Zihan
Fix the misspelling of Linus Torvalds' first name in Italian
and Spanish translations.
Also fix "Linus Torvald" -> "Linus Torvalds" (missing 's') in
Italian translations.
Found by Christian Marillat.
Signed-off-by: Wang Zihan <jiyu03@qq.com>
---
Documentation/translations/it_IT/process/2.Process.rst | 2 +-
Documentation/translations/it_IT/process/adding-syscalls.rst | 2 +-
Documentation/translations/it_IT/process/howto.rst | 2 +-
.../translations/it_IT/process/submitting-patches.rst | 2 +-
Documentation/translations/sp_SP/process/2.Process.rst | 4 ++--
5 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/translations/it_IT/process/2.Process.rst b/Documentation/translations/it_IT/process/2.Process.rst
index 6262c3908..38e1a154d 100644
--- a/Documentation/translations/it_IT/process/2.Process.rst
+++ b/Documentation/translations/it_IT/process/2.Process.rst
@@ -53,7 +53,7 @@ raccolti e, verificati in anticipo. Il funzionamento di tale procedimento
verrà descritto dettagliatamente più avanti).
La finestra di inclusione resta attiva approssimativamente per due settimane.
-Al termine di questo periodo, Linus Torvald dichiarerà che la finestra è
+Al termine di questo periodo, Linus Torvalds dichiarerà che la finestra è
chiusa e rilascerà il primo degli "rc" del kernel.
Per il kernel che è destinato ad essere 5.6, per esempio, il rilascio
che emerge al termine della finestra d'inclusione si chiamerà 5.6-rc1.
diff --git a/Documentation/translations/it_IT/process/adding-syscalls.rst b/Documentation/translations/it_IT/process/adding-syscalls.rst
index c4ed6dbf5..1361778ed 100644
--- a/Documentation/translations/it_IT/process/adding-syscalls.rst
+++ b/Documentation/translations/it_IT/process/adding-syscalls.rst
@@ -603,7 +603,7 @@ Riferimenti e fonti
- Requisiti specifici alle architetture sono discussi nella pagina man
:manpage:`syscall(2)` :
http://man7.org/linux/man-pages/man2/syscall.2.html#NOTES
- - Collezione di email di Linux Torvalds sui problemi relativi a ``ioctl()``:
+ - Collezione di email di Linus Torvalds sui problemi relativi a ``ioctl()``:
http://yarchive.net/comp/linux/ioctl.html
- "Come non inventare interfacce del kernel", Arnd Bergmann,
http://www.ukuug.org/events/linux2007/2007/papers/Bergmann.pdf
diff --git a/Documentation/translations/it_IT/process/howto.rst b/Documentation/translations/it_IT/process/howto.rst
index f51288602..c9120095c 100644
--- a/Documentation/translations/it_IT/process/howto.rst
+++ b/Documentation/translations/it_IT/process/howto.rst
@@ -249,7 +249,7 @@ e di molti altri rami per specifici sottosistemi. Questi rami sono:
I sorgenti kernel 4.x
~~~~~~~~~~~~~~~~~~~~~
-I kernel 4.x sono amministrati da Linus Torvald, e possono essere trovati
+I kernel 4.x sono amministrati da Linus Torvalds, e possono essere trovati
su https://kernel.org nella cartella pub/linux/kernel/v4.x/. Il processo
di sviluppo è il seguente:
diff --git a/Documentation/translations/it_IT/process/submitting-patches.rst b/Documentation/translations/it_IT/process/submitting-patches.rst
index 1cc480813..48ac4916d 100644
--- a/Documentation/translations/it_IT/process/submitting-patches.rst
+++ b/Documentation/translations/it_IT/process/submitting-patches.rst
@@ -280,7 +280,7 @@ https://subspace.kernel.org. Tuttavia, ci sono altre liste di discussione
ospitate altrove.
L'ultimo giudizio sull'integrazione delle modifiche accettate spetta a
-Linux Torvalds. Il suo indirizzo e-mail è <torvalds@linux-foundation.org>.
+Linus Torvalds. Il suo indirizzo e-mail è <torvalds@linux-foundation.org>.
Riceve moltissime e-mail, e, a questo punto, solo poche patch passano
direttamente attraverso il suo giudizio; quindi, dovreste fare del vostro
meglio per -evitare di- inviargli e-mail.
diff --git a/Documentation/translations/sp_SP/process/2.Process.rst b/Documentation/translations/sp_SP/process/2.Process.rst
index c21b0134c..9e26eb8c6 100644
--- a/Documentation/translations/sp_SP/process/2.Process.rst
+++ b/Documentation/translations/sp_SP/process/2.Process.rst
@@ -56,7 +56,7 @@ y montados con anticipación. Como funciona ese proceso se describirá en
detalle más adelante).
La ventana de fusión dura aproximadamente dos semanas. Al final de este
-tiempo, Linux Torvalds declarará que la ventana está cerrada y publicará
+tiempo, Linus Torvalds declarará que la ventana está cerrada y publicará
el primero de los kernels “rc”. Para el kernel destinado a ser 5.6, por
ejemplo, el lanzamiento al final de la ventana de fusión se llamará
5.6-rc1. El lanzamiento -rc1 señala que el tiempo para fusionar nuevas
@@ -202,7 +202,7 @@ Las etapas por las que pasa un parche son, generalmente:
para su revisión y fusión.
- Fusión en el mainline. Eventualmente, un parche exitoso se fusionará
- en el repositorio mainline administrado por Linux Torvalds. Mas
+ en el repositorio mainline administrado por Linus Torvalds. Mas
comentarios y/o problemas pueden surgir en este momento; es importante
que el desarrollador responda a estos y solucione cualquier problema
que surja.
--
2.54.0
^ permalink raw reply related
* [WITHDRAW] Documentation: Fix duplicated words - "in in" was not an error
From: Wang Zihan @ 2026-05-02 13:09 UTC (permalink / raw)
To: netdev, linux-doc, linux-media, linux-um
Cc: davem, kuba, corbet, mchehab, richard, linux-kernel, Wang Zihan
From: Wang Zihan <3772548978@qq.com>
I apologize for another incorrect patch. After review by Björn Persson,
I realized that "in in" in switchdev.rst was not an error:
Original: "what position a port is in in the overall topology"
This is correct English:
- "what position a port is in" = the position that a port occupies
- "in the overall topology" = within the overall topology
My change incorrectly altered the meaning to suggest that a port IS a position,
when in fact a port is IN a position IN the topology.
I am withdrawing the "in in" part of this patch:
- Message-ID: <20260502111916.145238-1-3772548978@qq.com>
The other parts ("The the" -> "The" and "on on" -> "on") were also incorrect
as previously acknowledged.
Thank you for the correction. I will be more careful in analyzing English
grammar before submitting patches.
Apologies for the noise.
Wang Zihan
^ permalink raw reply
* [WITHDRAW] Documentation: Fix typo "eXtention" -> "Extension" and duplicated words
From: Wang Zihan @ 2026-05-02 13:04 UTC (permalink / raw)
To: loongarch, netdev, linux-doc, linux-media, linux-um
Cc: chenhuacai, kernel, alexs, si.yanteng, corbet, davem, kuba,
mchehab, richard, linux-kernel, Wang Zihan
From: Wang Zihan <3772548978@qq.com>
I apologize for submitting incorrect patches. After review by Björn Persson,
I realized that my changes were not actually fixing errors:
1. Patch "Documentation: loongarch: Fix typo eXtention -> Extension"
The capitalization of 'X' in 'eXtention' was intentional to highlight
the letter, not a spelling mistake.
2. Patch "Documentation: Fix duplicated words" (the "later on on" part)
"Later on" is an established English expression. The original text
was not an error, just a stylistic choice.
I am withdrawing these patches:
- Message-ID: <20260502111912.143743-1-3772548978@qq.com>
- Message-ID: <20260502111916.145238-1-3772548978@qq.com>
Thank you for the correction and education. I will be more careful in the future.
Apologies for the noise.
Wang Zihan
^ permalink raw reply
* Re: [PATCH v2] iio: adxl313: fix typos in documentation
From: Wang Zihan @ 2026-05-02 12:53 UTC (permalink / raw)
To: joshua.crofts1; +Cc: jic23, linux-iio, linux-doc, Wang Zihan
Hi Joshua,
Thank you for the review!
I apologize for the quick v2. The v1 had an incorrect subject format
([PATCH 1/4] instead of [PATCH]) which could cause confusion. I sent
v2 to correct this formatting issue.
I will keep the 24-hour rule in mind for future submissions.
Best regards,
Wang Zihan
^ permalink raw reply
* Re: [PATCH v2] iio: adxl313: fix typos in documentation
From: Joshua Crofts @ 2026-05-02 12:45 UTC (permalink / raw)
To: Wang Zihan; +Cc: jic23, linux-iio, linux-doc
In-Reply-To: <tencent_EC262467CD5E46CA97CF2B2FDCBCA0565C08@qq.com>
On Sat, 2 May 2026 at 08:07, Wang Zihan <jiyu03@qq.com> wrote:
>
> Add missing space in "ADXL313is" and correct "a single types"
> to "a single type".
>
> Signed-off-by: Wang Zihan <jiyu03@qq.com>
> ---
> Documentation/iio/adxl313.rst | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/iio/adxl313.rst b/Documentation/iio/adxl313.rst
> index 966e72c01..3662153a6 100644
> --- a/Documentation/iio/adxl313.rst
> +++ b/Documentation/iio/adxl313.rst
> @@ -11,7 +11,7 @@ This driver supports Analog Device's ADXL313 on SPI/I2C bus.
>
> * `ADXL313 <https://www.analog.com/ADXL313>`_
>
> -The ADXL313is a low noise density, low power, 3-axis accelerometer with
> +The ADXL313 is a low noise density, low power, 3-axis accelerometer with
> selectable measurement ranges. The ADXL313 supports the ±0.5 g, ±1 g, ±2 g and
> ±4 g ranges.
>
> @@ -112,7 +112,7 @@ apply the following formula:
> Where _offset and _scale are device attributes. If no _offset attribute is
> present, simply assume its value is 0.
>
> -The ADXL313 driver offers data for a single types of channels, the table below
> +The ADXL313 driver offers data for a single type of channels, the table below
> shows the measurement units for the processed value, which are defined by the
> IIO framework:
>
> --
> 2.54.0
>
>
FYI, please wait 24 hours before sending a v2.
Reviewed-by: Joshua Crofts <joshua.crofts1@gmail.com>
--
Kind regards
CJD
^ permalink raw reply
* [PATCH v2] docs: Remove stale ISDN parameters
From: Costa Shulyupin @ 2026-05-02 12:02 UTC (permalink / raw)
To: Jakub Kicinski, Jonathan Corbet, Shuah Khan, Randy Dunlap,
linux-doc, linux-kernel
Cc: Costa Shulyupin
The icn= and pcbit= parameters referenced drivers removed in
commit 02bbd9802da7 ("staging: i4l: delete the whole thing").
Remove the stale parameter entries and the now-unused ISDN tag
from the legend.
Suggested-by: Randy Dunlap <rdunlap@infradead.org>
Assisted-by: Claude:claude-opus-4-6
---
v2: Remove pcbit= and ISDN too
Address comments of Randy Dunlap
V1: Remove icn=
Signed-off-by: Costa Shulyupin <costa.shul@redhat.com>
---
Documentation/admin-guide/kernel-parameters.txt | 6 ------
1 file changed, 6 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index c13c354728bb..96c189e5f5bf 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -24,7 +24,6 @@
IP_PNP IP DHCP, BOOTP, or RARP is enabled.
IPV6 IPv6 support is enabled.
ISAPNP ISA PnP code is enabled.
- ISDN Appropriate ISDN support is enabled.
ISOL CPU Isolation is enabled.
JOY Appropriate joystick support is enabled.
KGDB Kernel debugger support is enabled.
@@ -2245,9 +2244,6 @@ Kernel parameters
syscalls, essentially overriding IA32_EMULATION_DEFAULT_DISABLED at
boot time. When false, unconditionally disables IA32 emulation.
- icn= [HW,ISDN]
- Format: <io>[,<membase>[,<icn_id>[,<icn_id2>]]]
-
idle= [X86,EARLY]
Format: idle=poll, idle=halt, idle=nomwait
@@ -5037,8 +5033,6 @@ Kernel parameters
the specified number of seconds. This is to be used if
your oopses keep scrolling off the screen.
- pcbit= [HW,ISDN]
-
pci=option[,option...] [PCI,EARLY] various PCI subsystem options.
Some options herein operate on a specific device
--
2.53.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox