* Re: [PATCH] fbdev/ffb: fix corrupted video output on FFB1
From: René Rebe @ 2026-02-06 10:40 UTC (permalink / raw)
To: Helge Deller; +Cc: linux-fbdev
In-Reply-To: <CC6760AE-15B4-45FC-B796-577AAE728ADD@exactco.de>
Hello again,
> On 6. Feb 2026, at 11:30, René Rebe <rene@exactco.de> wrote:
>
> Hi,
>
>> On 6. Feb 2026, at 11:12, Helge Deller <deller@gmx.de> wrote:
>>
>> Hello Rene,
>>
>> On 2/5/26 16:49, René Rebe wrote:
>>> Fix Sun FFB1 corrupted video out [1] by disabling overlay and
>>> initializing window mode to a known state. The issue never appeared on
>>> my FFB2+/vertical nor Elite3D/M6. It could also depend on the PROM
>>> version.
>>> /SUNW,ffb@1e,0: FFB at 000001fc00000000, type 11, DAC pnum[236c] rev[10] manuf_rev[4]
>>> X (II) /dev/fb0: Detected FFB1, Z-buffer, Single-buffered.
>>> X (II) /dev/fb0: BT9068 (PAC1) ramdac detected (with normal cursor control)
>>> X (II) /dev/fb0: Detected Creator/Creator3D
>>> [1] https://www.instagram.com/p/DUTcSmSjSem/
>>
>> The patch itself seems ok.
>> But could you please link to a freely accessible website instead of Instagram?
>> I and many others don't have (and don't want) an instagram account, so
>> the link is not very useful.
>
> Well it is more free than accessing Linux Foundation training material ;-)
> It was only for illustration purposes if someone wanted to see or follow random
> daily development fun and not that important. Should I resend it w/o it?
While I try to influence next gen to get into OpenSource and low level programming,
how about Mastodon links?
https://chaos.social/@ReneRebe/116023241660154102
Do you want to edit the patch or should I send a V2?
René
> Thanks!
> René
>
>> Helge
>>
>>> Signed-off-by: René Rebe <rene@exactco.de>
>>> Cc: stable@kernel.org
>>> ---
>>> Tested on Sun Ultra 2 w/ FFB1 BT9068 (PAC1) ramdac running T2/Linux.
>>> Defines re-used from xf86-video-sunffb.
>>> ---
>>> diff --git a/drivers/video/fbdev/ffb.c b/drivers/video/fbdev/ffb.c
>>> index 34b6abff9493..8d77f102dd82 100644
>>> --- a/drivers/video/fbdev/ffb.c
>>> +++ b/drivers/video/fbdev/ffb.c
>>> @@ -335,6 +335,9 @@ struct ffb_dac {
>>> };
>>> #define FFB_DAC_UCTRL 0x1001 /* User Control */
>>> +#define FFB_DAC_UCTRL_OVENAB 0x00000008 /* Overlay Enable */
>>> +#define FFB_DAC_UCTRL_WMODE 0x00000030 /* Window Mode */
>>> +#define FFB_DAC_UCTRL_WM_COMB 0x00000000 /* Window Mode = Combined */
>>> #define FFB_DAC_UCTRL_MANREV 0x00000f00 /* 4-bit Manufacturing Revision */
>>> #define FFB_DAC_UCTRL_MANREV_SHIFT 8
>>> #define FFB_DAC_TGEN 0x6000 /* Timing Generator */
>>> @@ -425,7 +428,7 @@ static void ffb_switch_from_graph(struct ffb_par *par)
>>> {
>>> struct ffb_fbc __iomem *fbc = par->fbc;
>>> struct ffb_dac __iomem *dac = par->dac;
>>> - unsigned long flags;
>>> + unsigned long flags, uctrl;
>>> spin_lock_irqsave(&par->lock, flags);
>>> FFBWait(par);
>>> @@ -442,7 +445,7 @@ static void ffb_switch_from_graph(struct ffb_par *par)
>>> upa_writel(par->bg_cache, &fbc->bg);
>>> FFBWait(par);
>>> - /* Disable cursor. */
>>> + /* Disable cursor. */
>>> upa_writel(FFB_DAC_CUR_CTRL, &dac->type2);
>>> if (par->flags & FFB_FLAG_INVCURSOR)
>>> upa_writel(0, &dac->value2);
>>> @@ -450,6 +453,15 @@ static void ffb_switch_from_graph(struct ffb_par *par)
>>> upa_writel((FFB_DAC_CUR_CTRL_P0 |
>>> FFB_DAC_CUR_CTRL_P1), &dac->value2);
>>> + /* Disable overlay and window modes. */
>>> + upa_writel(FFB_DAC_UCTRL, &dac->type);
>>> + uctrl = upa_readl(&dac->value);
>>> + uctrl &= ~FFB_DAC_UCTRL_WMODE;
>>> + uctrl |= FFB_DAC_UCTRL_WM_COMB;
>>> + uctrl &= ~FFB_DAC_UCTRL_OVENAB;
>>> + upa_writel(FFB_DAC_UCTRL, &dac->type);
>>> + upa_writel(uctrl, &dac->value);
>>> +
>>> spin_unlock_irqrestore(&par->lock, flags);
>>> }
>>>
>>
>
> --
> https://exactco.de • https://t2linux.com • https://patreon.com/renerebe
>
--
https://exactco.de • https://t2linux.com • https://patreon.com/renerebe
^ permalink raw reply
* Re: [PATCH] fbdev/ffb: fix corrupted video output on FFB1
From: Helge Deller @ 2026-02-06 10:41 UTC (permalink / raw)
To: René Rebe; +Cc: linux-fbdev
In-Reply-To: <CC6760AE-15B4-45FC-B796-577AAE728ADD@exactco.de>
On 2/6/26 11:30, René Rebe wrote:
>> On 6. Feb 2026, at 11:12, Helge Deller <deller@gmx.de> wrote:
>>
>> Hello Rene,
>>
>> On 2/5/26 16:49, René Rebe wrote:
>>> Fix Sun FFB1 corrupted video out [1] by disabling overlay and
>>> initializing window mode to a known state. The issue never appeared on
>>> my FFB2+/vertical nor Elite3D/M6. It could also depend on the PROM
>>> version.
>>> /SUNW,ffb@1e,0: FFB at 000001fc00000000, type 11, DAC pnum[236c] rev[10] manuf_rev[4]
>>> X (II) /dev/fb0: Detected FFB1, Z-buffer, Single-buffered.
>>> X (II) /dev/fb0: BT9068 (PAC1) ramdac detected (with normal cursor control)
>>> X (II) /dev/fb0: Detected Creator/Creator3D
>>> [1] https://www.instagram.com/p/DUTcSmSjSem/
>>
>> The patch itself seems ok.
>> But could you please link to a freely accessible website instead of Instagram?
>> I and many others don't have (and don't want) an instagram account, so
>> the link is not very useful.
>
> Well it is more free than accessing Linux Foundation training material ;-)
> It was only for illustration purposes if someone wanted to see or follow random
> daily development fun and not that important. Should I resend it w/o it?
No need to resend.
I asked, because I don't know what's visible there, and maybe you
had another link which could have been used instead.
It seems that's not the case, so I'll take the patch as-is.
applied to fbdev git tree.
Thanks!
Helge
^ permalink raw reply
* Re: [PATCH v5] fbtft: limit dirty rows based on damage range
From: Nam Cao @ 2026-02-06 10:51 UTC (permalink / raw)
To: Andy Shevchenko
Cc: ChanSoo Shin, andy, gregkh, dri-devel, linux-fbdev, linux-staging
In-Reply-To: <aYXEHajVeKvIMmL7@smile.fi.intel.com>
Andy Shevchenko <andriy.shevchenko@intel.com> writes:
> Do you have an actual HW to test? If not, won't be applied either.
Yes, a pair with SPI interface.
Nam
^ permalink raw reply
* Re: [PATCH] video: of_display_timing: Fix device node reference leak in of_get_display_timings()
From: Helge Deller @ 2026-02-06 10:52 UTC (permalink / raw)
To: Felix Gu, Thierry Reding, Laurent Pinchart, Philipp Zabel,
Stephen Warren, Steffen Trumtrar
Cc: linux-fbdev, dri-devel, linux-kernel
In-Reply-To: <20260131-of_display_timging-v1-1-f4f8d9f87c3c@gmail.com>
On 1/31/26 13:48, Felix Gu wrote:
> Use for_each_child_of_node_scoped instead of for_each_child_of_node
> to ensure automatic of_node_put on early exit paths, preventing
> device node reference leak.
>
> Fixes: cc3f414cf2e4 ("video: add of helper for display timings/videomode")
> Signed-off-by: Felix Gu <ustc.gu@gmail.com>
> ---
> drivers/video/of_display_timing.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
applied.
Thanks!
Helge
^ permalink raw reply
* Re: [PATCH v1 1/3] fbdev: au1100fb: Mark several local functions as static
From: Helge Deller @ 2026-02-06 11:06 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: Chen Ni, linux-fbdev, dri-devel
In-Reply-To: <ceb08e29f6a07075b5ca63e4ed30c5051fddcdfd.1770196161.git.u.kleine-koenig@baylibre.com>
Hi Uwe,
On 2/4/26 10:15, Uwe Kleine-König wrote:
> This fixes several (fatal) compiler warnings à la
>
> drivers/video/fbdev/au1100fb.c:530:6: error: no previous prototype for ‘au1100fb_drv_remove’ [-Werror=missing-prototypes]
> 523 | void au1100fb_drv_remove(struct platform_device *dev)
> | ^~~~~~~~~~~~~~~~~~~
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
I've applied patches #1 and #3 of this series to the fbdev git tree.
Patch #2 needs fixing, as it breaks build on s390x.
Helge
^ permalink raw reply
* Re: [PATCH v1 1/3] fbdev: au1100fb: Mark several local functions as static
From: Helge Deller @ 2026-02-06 11:22 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: Chen Ni, linux-fbdev, dri-devel
In-Reply-To: <cf0433eb-e22d-498b-93a2-04b461aaa6e2@gmx.de>
On 2/6/26 12:06, Helge Deller wrote:
> Hi Uwe,
>
> On 2/4/26 10:15, Uwe Kleine-König wrote:
>> This fixes several (fatal) compiler warnings à la
>>
>> drivers/video/fbdev/au1100fb.c:530:6: error: no previous prototype for ‘au1100fb_drv_remove’ [-Werror=missing-prototypes]
>> 523 | void au1100fb_drv_remove(struct platform_device *dev)
>> | ^~~~~~~~~~~~~~~~~~~
>>
>> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
>
> I've applied patches #1 and #3 of this series to the fbdev git tree.
>
> Patch #2 needs fixing, as it breaks build on s390x.
I fixed up patch #2 manually for now by excluding s390x as test platform.
If you have a better patch, I'm happy to take it.
Thanks!
Helge
^ permalink raw reply
* Re: [PATCH v5] fbtft: limit dirty rows based on damage range
From: Andy Shevchenko @ 2026-02-06 11:35 UTC (permalink / raw)
To: Nam Cao; +Cc: ChanSoo Shin, andy, gregkh, dri-devel, linux-fbdev, linux-staging
In-Reply-To: <87ms1mb0vy.fsf@yellow.woof>
On Fri, Feb 06, 2026 at 05:51:45PM +0700, Nam Cao wrote:
> Andy Shevchenko <andriy.shevchenko@intel.com> writes:
> > Do you have an actual HW to test? If not, won't be applied either.
>
> Yes, a pair with SPI interface.
Cool! Would be nice to have tested contribution, indeed.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v1 1/3] fbdev: au1100fb: Mark several local functions as static
From: Uwe Kleine-König @ 2026-02-06 14:15 UTC (permalink / raw)
To: Helge Deller; +Cc: Chen Ni, linux-fbdev, dri-devel
In-Reply-To: <28affc45-7f41-40a5-82bf-308a6e34d956@gmx.de>
[-- Attachment #1: Type: text/plain, Size: 1028 bytes --]
Hello Helge,
On Fri, Feb 06, 2026 at 12:22:39PM +0100, Helge Deller wrote:
> On 2/6/26 12:06, Helge Deller wrote:
> > On 2/4/26 10:15, Uwe Kleine-König wrote:
> > > This fixes several (fatal) compiler warnings à la
> > >
> > > drivers/video/fbdev/au1100fb.c:530:6: error: no previous prototype for ‘au1100fb_drv_remove’ [-Werror=missing-prototypes]
> > > 523 | void au1100fb_drv_remove(struct platform_device *dev)
> > > | ^~~~~~~~~~~~~~~~~~~
> > >
> > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
> >
> > I've applied patches #1 and #3 of this series to the fbdev git tree.
> >
> > Patch #2 needs fixing, as it breaks build on s390x.
>
> I fixed up patch #2 manually for now by excluding s390x as test platform.
> If you have a better patch, I'm happy to take it.
I didn't look at that yet, but I suspect that the failure isn't s390x
specific and I think it's better to not relax the dependencies yet.
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH -next v7 1/2] rust: clist: Add support to interface with C linked lists
From: Gary Guo @ 2026-02-06 15:25 UTC (permalink / raw)
To: Joel Fernandes, linux-kernel
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Jonathan Corbet, Alex Deucher,
Christian König, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Huang Rui, Matthew Auld, Matthew Brost,
Lucas De Marchi, Thomas Hellström, Helge Deller,
Danilo Krummrich, Alice Ryhl, Miguel Ojeda, Alex Gaynor,
Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Andreas Hindborg, Trevor Gross, John Hubbard, Alistair Popple,
Timur Tabi, Edwin Peer, Alexandre Courbot, Andrea Righi,
Andy Ritger, Zhi Wang, Balbir Singh, Philipp Stanner,
Elle Rhumsaa, Daniel Almeida, joel, nouveau, dri-devel,
rust-for-linux, linux-doc, amd-gfx, intel-gfx, intel-xe,
linux-fbdev
In-Reply-To: <20260206004110.1914814-2-joelagnelf@nvidia.com>
On Fri Feb 6, 2026 at 12:41 AM GMT, Joel Fernandes wrote:
> Add a new module `clist` for working with C's doubly circular linked
> lists. Provide low-level iteration over list nodes.
>
> Typed iteration over actual items is provided with a `clist_create`
> macro to assist in creation of the `CList` type.
>
> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
> ---
> MAINTAINERS | 7 +
> drivers/gpu/Kconfig | 7 +
> rust/helpers/helpers.c | 1 +
> rust/helpers/list.c | 21 +++
> rust/kernel/clist.rs | 315 +++++++++++++++++++++++++++++++++++++++++
> rust/kernel/lib.rs | 2 +
> 6 files changed, 353 insertions(+)
> create mode 100644 rust/helpers/list.c
> create mode 100644 rust/kernel/clist.rs
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 900fc00b73e6..310bb479260c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -23204,6 +23204,13 @@ S: Maintained
> T: git https://github.com/Rust-for-Linux/linux.git rust-analyzer-next
> F: scripts/generate_rust_analyzer.py
>
> +RUST TO C LIST INTERFACES
> +M: Joel Fernandes <joelagnelf@nvidia.com>
> +M: Alexandre Courbot <acourbot@nvidia.com>
> +L: rust-for-linux@vger.kernel.org
> +S: Maintained
> +F: rust/kernel/clist.rs
I still think we should try to work on a more powerful list infra that works for
both C and Rust, but I reckon that is a longer term effort, and shouldn't
prevent a simpler version from getting in and be used by abstractions that need
it. So
Acked-by: Gary Guo <gary@garyguo.net>
Some nits below:
> +
> RXRPC SOCKETS (AF_RXRPC)
> M: David Howells <dhowells@redhat.com>
> M: Marc Dionne <marc.dionne@auristor.com>
> diff --git a/drivers/gpu/Kconfig b/drivers/gpu/Kconfig
> index 22dd29cd50b5..2c3dec070645 100644
> --- a/drivers/gpu/Kconfig
> +++ b/drivers/gpu/Kconfig
> @@ -1,7 +1,14 @@
> # SPDX-License-Identifier: GPL-2.0
>
> +config RUST_CLIST
> + bool
> + depends on RUST
> + help
> + Rust abstraction for interfacing with C linked lists.
I am not sure if we need extra config entry. This is fully generic so shouldn't
generate any code unless there is an user.
> +
> config GPU_BUDDY
> bool
> + select RUST_CLIST if RUST
> help
> A page based buddy allocator for GPU memory.
>
> diff --git a/rust/helpers/helpers.c b/rust/helpers/helpers.c
> index a3c42e51f00a..724fcb8240ac 100644
> --- a/rust/helpers/helpers.c
> +++ b/rust/helpers/helpers.c
> @@ -35,6 +35,7 @@
> #include "io.c"
> #include "jump_label.c"
> #include "kunit.c"
> +#include "list.c"
> #include "maple_tree.c"
> #include "mm.c"
> #include "mutex.c"
> diff --git a/rust/helpers/list.c b/rust/helpers/list.c
> new file mode 100644
> index 000000000000..3390b154fa36
> --- /dev/null
> +++ b/rust/helpers/list.c
> @@ -0,0 +1,21 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +/*
> + * Helpers for C Circular doubly linked list implementation.
> + */
> +
> +#include <linux/list.h>
> +
> +#ifndef __rust_helper
> +#define __rust_helper
> +#endif
This shouldn't be needed.
> +
> +__rust_helper void rust_helper_INIT_LIST_HEAD(struct list_head *list)
> +{
> + INIT_LIST_HEAD(list);
> +}
> +
> +__rust_helper void rust_helper_list_add_tail(struct list_head *new, struct list_head *head)
> +{
> + list_add_tail(new, head);
> +}
> diff --git a/rust/kernel/clist.rs b/rust/kernel/clist.rs
> new file mode 100644
> index 000000000000..1f6d4db13c1d
> --- /dev/null
> +++ b/rust/kernel/clist.rs
> @@ -0,0 +1,315 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +//! A C doubly circular intrusive linked list interface for rust code.
> +//!
> +//! # Examples
> +//!
> +//! ```
> +//! use kernel::{
> +//! bindings,
> +//! clist_create,
> +//! types::Opaque, //
> +//! };
> +//! # // Create test list with values (0, 10, 20) - normally done by C code but it is
> +//! # // emulated here for doctests using the C bindings.
> +//! # use core::mem::MaybeUninit;
> +//! #
> +//! # /// C struct with embedded `list_head` (typically will be allocated by C code).
> +//! # #[repr(C)]
> +//! # pub(crate) struct SampleItemC {
> +//! # pub value: i32,
> +//! # pub link: bindings::list_head,
> +//! # }
> +//! #
> +//! # let mut head = MaybeUninit::<bindings::list_head>::uninit();
> +//! #
> +//! # let head = head.as_mut_ptr();
> +//! # // SAFETY: head and all the items are test objects allocated in this scope.
> +//! # unsafe { bindings::INIT_LIST_HEAD(head) };
> +//! #
> +//! # let mut items = [
> +//! # MaybeUninit::<SampleItemC>::uninit(),
> +//! # MaybeUninit::<SampleItemC>::uninit(),
> +//! # MaybeUninit::<SampleItemC>::uninit(),
> +//! # ];
> +//! #
> +//! # for (i, item) in items.iter_mut().enumerate() {
> +//! # let ptr = item.as_mut_ptr();
> +//! # // SAFETY: pointers are to allocated test objects with a list_head field.
> +//! # unsafe {
> +//! # (*ptr).value = i as i32 * 10;
> +//! # // addr_of_mut!() computes address of link directly as link is uninitialized.
> +//! # bindings::INIT_LIST_HEAD(core::ptr::addr_of_mut!((*ptr).link));
> +//! # bindings::list_add_tail(&mut (*ptr).link, head);
> +//! # }
> +//! # }
> +//!
> +//! // Rust wrapper for the C struct.
> +//! // The list item struct in this example is defined in C code as:
> +//! // struct SampleItemC {
> +//! // int value;
> +//! // struct list_head link;
> +//! // };
> +//! //
> +//! #[repr(transparent)]
> +//! pub(crate) struct Item(Opaque<SampleItemC>);
> +//!
> +//! impl Item {
> +//! pub(crate) fn value(&self) -> i32 {
> +//! // SAFETY: [`Item`] has same layout as [`SampleItemC`].
> +//! unsafe { (*self.0.get()).value }
> +//! }
> +//! }
> +//!
> +//! // Create typed [`CList`] from sentinel head.
> +//! // SAFETY: head is valid, items are [`SampleItemC`] with embedded `link` field.
> +//! let list = unsafe { clist_create!(head, Item, SampleItemC, link) };
> +//!
> +//! // Iterate directly over typed items.
> +//! let mut found_0 = false;
> +//! let mut found_10 = false;
> +//! let mut found_20 = false;
> +//!
> +//! for item in list.iter() {
> +//! let val = item.value();
> +//! if val == 0 { found_0 = true; }
> +//! if val == 10 { found_10 = true; }
> +//! if val == 20 { found_20 = true; }
> +//! }
> +//!
> +//! assert!(found_0 && found_10 && found_20);
> +//! ```
> +
> +use core::{
> + iter::FusedIterator,
> + marker::PhantomData, //
> +};
> +
> +use crate::{
> + bindings,
> + types::Opaque, //
> +};
> +
> +use pin_init::PinInit;
> +
> +/// Wraps a `list_head` object for use in intrusive linked lists.
> +///
> +/// # Invariants
> +///
> +/// - [`CListHead`] represents an allocated and valid `list_head` structure.
> +/// - Once a [`CListHead`] is created in Rust, it will not be modified by non-Rust code.
> +/// - All `list_head` for individual items are not modified for the lifetime of [`CListHead`].
> +#[repr(transparent)]
> +pub(crate) struct CListHead(Opaque<bindings::list_head>);
> +
> +impl CListHead {
> + /// Create a `&CListHead` reference from a raw `list_head` pointer.
> + ///
> + /// # Safety
> + ///
> + /// - `ptr` must be a valid pointer to an allocated and initialized `list_head` structure.
> + /// - `ptr` must remain valid and unmodified for the lifetime `'a`.
> + #[inline]
> + pub(crate) unsafe fn from_raw<'a>(ptr: *mut bindings::list_head) -> &'a Self {
> + // SAFETY:
> + // - [`CListHead`] has same layout as `list_head`.
> + // - `ptr` is valid and unmodified for 'a.
> + unsafe { &*ptr.cast() }
> + }
> +
> + /// Get the raw `list_head` pointer.
> + #[inline]
> + pub(crate) fn as_raw(&self) -> *mut bindings::list_head {
> + self.0.get()
> + }
> +
> + /// Get the next [`CListHead`] in the list.
> + #[inline]
> + pub(crate) fn next(&self) -> &Self {
> + let raw = self.as_raw();
> + // SAFETY:
> + // - `self.as_raw()` is valid per type invariants.
> + // - The `next` pointer is guaranteed to be non-NULL.
> + unsafe { Self::from_raw((*raw).next) }
> + }
> +
> + /// Check if this node is linked in a list (not isolated).
> + #[inline]
> + pub(crate) fn is_linked(&self) -> bool {
> + let raw = self.as_raw();
> + // SAFETY: self.as_raw() is valid per type invariants.
> + unsafe { (*raw).next != raw && (*raw).prev != raw }
> + }
> +
> + /// Pin-initializer that initializes the list head.
> + pub(crate) fn new() -> impl PinInit<Self> {
> + // SAFETY: `INIT_LIST_HEAD` initializes `slot` to a valid empty list.
> + unsafe {
> + pin_init::pin_init_from_closure(move |slot: *mut Self| {
pin_init::ffi_init should be used for this.
> + bindings::INIT_LIST_HEAD(slot.cast());
> + Ok(())
> + })
> + }
> + }
> +}
> +
> +// SAFETY: [`CListHead`] can be sent to any thread.
> +unsafe impl Send for CListHead {}
> +
> +// SAFETY: [`CListHead`] can be shared among threads as it is not modified
> +// by non-Rust code per type invariants.
> +unsafe impl Sync for CListHead {}
> +
> +impl PartialEq for CListHead {
#[inline]
> + fn eq(&self, other: &Self) -> bool {
> + core::ptr::eq(self, other)
> + }
> +}
> +
> +impl Eq for CListHead {}
^ permalink raw reply
* Re: [PATCH -next v7 1/2] rust: clist: Add support to interface with C linked lists
From: Danilo Krummrich @ 2026-02-06 15:53 UTC (permalink / raw)
To: Gary Guo
Cc: Joel Fernandes, linux-kernel, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Jonathan Corbet,
Alex Deucher, Christian König, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Huang Rui, Matthew Auld,
Matthew Brost, Lucas De Marchi, Thomas Hellström,
Helge Deller, Alice Ryhl, Miguel Ojeda, Alex Gaynor, Boqun Feng,
Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross, John Hubbard, Alistair Popple, Timur Tabi,
Edwin Peer, Alexandre Courbot, Andrea Righi, Andy Ritger,
Zhi Wang, Balbir Singh, Philipp Stanner, Elle Rhumsaa,
Daniel Almeida, joel, nouveau, dri-devel, rust-for-linux,
linux-doc, amd-gfx, intel-gfx, intel-xe, linux-fbdev
In-Reply-To: <DG7ZF1UT98RQ.3F42J3ULGV2OC@garyguo.net>
On Fri Feb 6, 2026 at 4:25 PM CET, Gary Guo wrote:
> On Fri Feb 6, 2026 at 12:41 AM GMT, Joel Fernandes wrote:
>> diff --git a/drivers/gpu/Kconfig b/drivers/gpu/Kconfig
>> index 22dd29cd50b5..2c3dec070645 100644
>> --- a/drivers/gpu/Kconfig
>> +++ b/drivers/gpu/Kconfig
>> @@ -1,7 +1,14 @@
>> # SPDX-License-Identifier: GPL-2.0
>>
>> +config RUST_CLIST
>> + bool
>> + depends on RUST
>> + help
>> + Rust abstraction for interfacing with C linked lists.
>
> I am not sure if we need extra config entry. This is fully generic so shouldn't
> generate any code unless there is an user.
I also don't think we need a Kconfig for this.
In any case, it shouln't be in drivers/gpu/Kconfig.
>> +
>> config GPU_BUDDY
>> bool
>> + select RUST_CLIST if RUST
If we will have a Kconfig for this, this belongs in the GPU buddy patch.
>> help
>> A page based buddy allocator for GPU memory.
^ permalink raw reply
* Re: [PATCH -next v7 1/2] rust: clist: Add support to interface with C linked lists
From: Joel Fernandes @ 2026-02-06 16:05 UTC (permalink / raw)
To: Danilo Krummrich, Gary Guo
Cc: linux-kernel, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, Jonathan Corbet, Alex Deucher,
Christian König, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Huang Rui, Matthew Auld, Matthew Brost,
Lucas De Marchi, Thomas Hellström, Helge Deller, Alice Ryhl,
Miguel Ojeda, Alex Gaynor, Boqun Feng, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Trevor Gross, John Hubbard,
Alistair Popple, Timur Tabi, Edwin Peer, Alexandre Courbot,
Andrea Righi, Andy Ritger, Zhi Wang, Balbir Singh,
Philipp Stanner, Elle Rhumsaa, Daniel Almeida, joel, nouveau,
dri-devel, rust-for-linux, linux-doc, amd-gfx, intel-gfx,
intel-xe, linux-fbdev
In-Reply-To: <DG800TDA6OXQ.275PMMS19F1EX@kernel.org>
On 2/6/2026 10:53 AM, Danilo Krummrich wrote:
> On Fri Feb 6, 2026 at 4:25 PM CET, Gary Guo wrote:
>> On Fri Feb 6, 2026 at 12:41 AM GMT, Joel Fernandes wrote:
>>> diff --git a/drivers/gpu/Kconfig b/drivers/gpu/Kconfig
>>> index 22dd29cd50b5..2c3dec070645 100644
>>> --- a/drivers/gpu/Kconfig
>>> +++ b/drivers/gpu/Kconfig
>>> @@ -1,7 +1,14 @@
>>> # SPDX-License-Identifier: GPL-2.0
>>>
>>> +config RUST_CLIST
>>> + bool
>>> + depends on RUST
>>> + help
>>> + Rust abstraction for interfacing with C linked lists.
>>
>> I am not sure if we need extra config entry. This is fully generic so shouldn't
>> generate any code unless there is an user.
>
> I also don't think we need a Kconfig for this.
>
> In any case, it shouln't be in drivers/gpu/Kconfig.
Fair point, I believe I was having trouble compiling this into the kernel crate
without warnings (I believe if !GPU_BUDDY). I'll try to drop it and see if we
can get rid of it.
>
>>> +
>>> config GPU_BUDDY
>>> bool
>>> + select RUST_CLIST if RUST
>
> If we will have a Kconfig for this, this belongs in the GPU buddy patch.
You mean, in the GPU buddy bindings patch right? If so, yes, I will move it there.
Thanks.
--
Joel Fernandes
^ permalink raw reply
* Re: [PATCH -next v7 1/2] rust: clist: Add support to interface with C linked lists
From: Gary Guo @ 2026-02-06 16:13 UTC (permalink / raw)
To: Joel Fernandes, Danilo Krummrich, Gary Guo
Cc: linux-kernel, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, Jonathan Corbet, Alex Deucher,
Christian König, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Huang Rui, Matthew Auld, Matthew Brost,
Lucas De Marchi, Thomas Hellström, Helge Deller, Alice Ryhl,
Miguel Ojeda, Alex Gaynor, Boqun Feng, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Trevor Gross, John Hubbard,
Alistair Popple, Timur Tabi, Edwin Peer, Alexandre Courbot,
Andrea Righi, Andy Ritger, Zhi Wang, Balbir Singh,
Philipp Stanner, Elle Rhumsaa, Daniel Almeida, joel, nouveau,
dri-devel, rust-for-linux, linux-doc, amd-gfx, intel-gfx,
intel-xe, linux-fbdev
In-Reply-To: <77ac3274-a962-469d-a2f6-6ccc0670988a@nvidia.com>
On Fri Feb 6, 2026 at 4:05 PM GMT, Joel Fernandes wrote:
>
>
> On 2/6/2026 10:53 AM, Danilo Krummrich wrote:
>> On Fri Feb 6, 2026 at 4:25 PM CET, Gary Guo wrote:
>>> On Fri Feb 6, 2026 at 12:41 AM GMT, Joel Fernandes wrote:
>>>> diff --git a/drivers/gpu/Kconfig b/drivers/gpu/Kconfig
>>>> index 22dd29cd50b5..2c3dec070645 100644
>>>> --- a/drivers/gpu/Kconfig
>>>> +++ b/drivers/gpu/Kconfig
>>>> @@ -1,7 +1,14 @@
>>>> # SPDX-License-Identifier: GPL-2.0
>>>>
>>>> +config RUST_CLIST
>>>> + bool
>>>> + depends on RUST
>>>> + help
>>>> + Rust abstraction for interfacing with C linked lists.
>>>
>>> I am not sure if we need extra config entry. This is fully generic so shouldn't
>>> generate any code unless there is an user.
>>
>> I also don't think we need a Kconfig for this.
>>
>> In any case, it shouln't be in drivers/gpu/Kconfig.
>
> Fair point, I believe I was having trouble compiling this into the kernel crate
> without warnings (I believe if !GPU_BUDDY). I'll try to drop it and see if we
> can get rid of it.
If you run into dead code warnings, I think it is fine to just
#[allow(dead_code, reason = "all users might be cfg-ed out")]
the overhead of just let rustc type-checking this module isn't worth the extra
Kconfig plumbing, I think.
Best,
Gary
>
>>
>>>> +
>>>> config GPU_BUDDY
>>>> bool
>>>> + select RUST_CLIST if RUST
>>
>> If we will have a Kconfig for this, this belongs in the GPU buddy patch.
>
> You mean, in the GPU buddy bindings patch right? If so, yes, I will move it there.
>
> Thanks.
^ permalink raw reply
* Re: [PATCH -next v7 1/2] rust: clist: Add support to interface with C linked lists
From: Danilo Krummrich @ 2026-02-06 17:13 UTC (permalink / raw)
To: Gary Guo
Cc: Joel Fernandes, linux-kernel, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Jonathan Corbet,
Alex Deucher, Christian König, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Huang Rui, Matthew Auld,
Matthew Brost, Lucas De Marchi, Thomas Hellström,
Helge Deller, Alice Ryhl, Miguel Ojeda, Alex Gaynor, Boqun Feng,
Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross, John Hubbard, Alistair Popple, Timur Tabi,
Edwin Peer, Alexandre Courbot, Andrea Righi, Andy Ritger,
Zhi Wang, Balbir Singh, Philipp Stanner, Elle Rhumsaa,
Daniel Almeida, joel, nouveau, dri-devel, rust-for-linux,
linux-doc, amd-gfx, intel-gfx, intel-xe, linux-fbdev
In-Reply-To: <DG80FV3VTT6P.2ZP18EM8605GT@garyguo.net>
On Fri Feb 6, 2026 at 5:13 PM CET, Gary Guo wrote:
> On Fri Feb 6, 2026 at 4:05 PM GMT, Joel Fernandes wrote:
>>
>>
>> On 2/6/2026 10:53 AM, Danilo Krummrich wrote:
>>> On Fri Feb 6, 2026 at 4:25 PM CET, Gary Guo wrote:
>>>> On Fri Feb 6, 2026 at 12:41 AM GMT, Joel Fernandes wrote:
>>>>> diff --git a/drivers/gpu/Kconfig b/drivers/gpu/Kconfig
>>>>> index 22dd29cd50b5..2c3dec070645 100644
>>>>> --- a/drivers/gpu/Kconfig
>>>>> +++ b/drivers/gpu/Kconfig
>>>>> @@ -1,7 +1,14 @@
>>>>> # SPDX-License-Identifier: GPL-2.0
>>>>>
>>>>> +config RUST_CLIST
>>>>> + bool
>>>>> + depends on RUST
>>>>> + help
>>>>> + Rust abstraction for interfacing with C linked lists.
>>>>
>>>> I am not sure if we need extra config entry. This is fully generic so shouldn't
>>>> generate any code unless there is an user.
>>>
>>> I also don't think we need a Kconfig for this.
>>>
>>> In any case, it shouln't be in drivers/gpu/Kconfig.
>>
>> Fair point, I believe I was having trouble compiling this into the kernel crate
>> without warnings (I believe if !GPU_BUDDY). I'll try to drop it and see if we
>> can get rid of it.
>
> If you run into dead code warnings, I think it is fine to just
>
> #[allow(dead_code, reason = "all users might be cfg-ed out")]
>
> the overhead of just let rustc type-checking this module isn't worth the extra
> Kconfig plumbing, I think.
You mean because there are pub(crate) in clist.rs? I don't think the Kconfig
would help with that, nothing prevents people from enabling RUST_CLIST, but none
of the users.
Besides that, once we have the new build system, the users of CList are likely
in other crates anyways, so I think we should just change things to pub.
^ permalink raw reply
* Re: [PATCH -next v7 1/2] rust: clist: Add support to interface with C linked lists
From: Gary Guo @ 2026-02-06 17:20 UTC (permalink / raw)
To: Danilo Krummrich, Gary Guo
Cc: Joel Fernandes, linux-kernel, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Jonathan Corbet,
Alex Deucher, Christian König, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Huang Rui, Matthew Auld,
Matthew Brost, Lucas De Marchi, Thomas Hellström,
Helge Deller, Alice Ryhl, Miguel Ojeda, Alex Gaynor, Boqun Feng,
Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross, John Hubbard, Alistair Popple, Timur Tabi,
Edwin Peer, Alexandre Courbot, Andrea Righi, Andy Ritger,
Zhi Wang, Balbir Singh, Philipp Stanner, Elle Rhumsaa,
Daniel Almeida, joel, nouveau, dri-devel, rust-for-linux,
linux-doc, amd-gfx, intel-gfx, intel-xe, linux-fbdev
In-Reply-To: <DG81PJ9QD8FC.2NF6VEKDD3F2Q@kernel.org>
On Fri Feb 6, 2026 at 5:13 PM GMT, Danilo Krummrich wrote:
> On Fri Feb 6, 2026 at 5:13 PM CET, Gary Guo wrote:
>> On Fri Feb 6, 2026 at 4:05 PM GMT, Joel Fernandes wrote:
>>>
>>>
>>> On 2/6/2026 10:53 AM, Danilo Krummrich wrote:
>>>> On Fri Feb 6, 2026 at 4:25 PM CET, Gary Guo wrote:
>>>>> On Fri Feb 6, 2026 at 12:41 AM GMT, Joel Fernandes wrote:
>>>>>> diff --git a/drivers/gpu/Kconfig b/drivers/gpu/Kconfig
>>>>>> index 22dd29cd50b5..2c3dec070645 100644
>>>>>> --- a/drivers/gpu/Kconfig
>>>>>> +++ b/drivers/gpu/Kconfig
>>>>>> @@ -1,7 +1,14 @@
>>>>>> # SPDX-License-Identifier: GPL-2.0
>>>>>>
>>>>>> +config RUST_CLIST
>>>>>> + bool
>>>>>> + depends on RUST
>>>>>> + help
>>>>>> + Rust abstraction for interfacing with C linked lists.
>>>>>
>>>>> I am not sure if we need extra config entry. This is fully generic so shouldn't
>>>>> generate any code unless there is an user.
>>>>
>>>> I also don't think we need a Kconfig for this.
>>>>
>>>> In any case, it shouln't be in drivers/gpu/Kconfig.
>>>
>>> Fair point, I believe I was having trouble compiling this into the kernel crate
>>> without warnings (I believe if !GPU_BUDDY). I'll try to drop it and see if we
>>> can get rid of it.
>>
>> If you run into dead code warnings, I think it is fine to just
>>
>> #[allow(dead_code, reason = "all users might be cfg-ed out")]
>>
>> the overhead of just let rustc type-checking this module isn't worth the extra
>> Kconfig plumbing, I think.
>
> You mean because there are pub(crate) in clist.rs? I don't think the Kconfig
> would help with that, nothing prevents people from enabling RUST_CLIST, but none
> of the users.
>
> Besides that, once we have the new build system, the users of CList are likely
> in other crates anyways, so I think we should just change things to pub.
I asked for this to be changed to `pub(crate)` because I think this isn't
something that should be used by drivers.
As you said, tt might be tricky to enforce that with new build system when
subsystems are inside different crates. But until then I think it's better to
limit visibility.
Best,
Gary
^ permalink raw reply
* Re: [PATCH -next v7 1/2] rust: clist: Add support to interface with C linked lists
From: Danilo Krummrich @ 2026-02-06 17:27 UTC (permalink / raw)
To: Gary Guo
Cc: Joel Fernandes, linux-kernel, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Jonathan Corbet,
Alex Deucher, Christian König, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Huang Rui, Matthew Auld,
Matthew Brost, Lucas De Marchi, Thomas Hellström,
Helge Deller, Alice Ryhl, Miguel Ojeda, Alex Gaynor, Boqun Feng,
Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross, John Hubbard, Alistair Popple, Timur Tabi,
Edwin Peer, Alexandre Courbot, Andrea Righi, Andy Ritger,
Zhi Wang, Balbir Singh, Philipp Stanner, Elle Rhumsaa,
Daniel Almeida, joel, nouveau, dri-devel, rust-for-linux,
linux-doc, amd-gfx, intel-gfx, intel-xe, linux-fbdev
In-Reply-To: <DG81V8NG5RC7.38EYLHQZXKTTO@garyguo.net>
On Fri Feb 6, 2026 at 6:20 PM CET, Gary Guo wrote:
> I asked for this to be changed to `pub(crate)` because I think this isn't
> something that should be used by drivers.
>
> As you said, tt might be tricky to enforce that with new build system when
> subsystems are inside different crates. But until then I think it's better to
> limit visibility.
It should *usually* not be used by drivers, but there are exceptions. For
instance, it is perfectly valid to be used by Rust drivers that interact with C
drivers.
Besides that, my take on this is that we know that the new build system will
come and that pub(crate) won't work in the long term, so why bother. I'd only
use it in cases where you want to keep things local to the subsystem.
^ permalink raw reply
* Re: [PATCH -next v7 1/2] rust: clist: Add support to interface with C linked lists
From: Daniel Almeida @ 2026-02-06 17:49 UTC (permalink / raw)
To: Joel Fernandes
Cc: linux-kernel, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, Jonathan Corbet, Alex Deucher,
Christian König, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Huang Rui, Matthew Auld, Matthew Brost,
Lucas De Marchi, Thomas Hellström, Helge Deller,
Danilo Krummrich, Alice Ryhl, Miguel Ojeda, Alex Gaynor,
Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Andreas Hindborg, Trevor Gross, John Hubbard, Alistair Popple,
Timur Tabi, Edwin Peer, Alexandre Courbot, Andrea Righi,
Andy Ritger, Zhi Wang, Balbir Singh, Philipp Stanner,
Elle Rhumsaa, joel, nouveau, dri-devel, rust-for-linux, linux-doc,
amd-gfx, intel-gfx, intel-xe, linux-fbdev
In-Reply-To: <20260206004110.1914814-2-joelagnelf@nvidia.com>
Hi Joel,
> On 5 Feb 2026, at 21:41, Joel Fernandes <joelagnelf@nvidia.com> wrote:
>
> Add a new module `clist` for working with C's doubly circular linked
> lists. Provide low-level iteration over list nodes.
>
> Typed iteration over actual items is provided with a `clist_create`
> macro to assist in creation of the `CList` type.
>
> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
> ---
> MAINTAINERS | 7 +
> drivers/gpu/Kconfig | 7 +
> rust/helpers/helpers.c | 1 +
> rust/helpers/list.c | 21 +++
> rust/kernel/clist.rs | 315 +++++++++++++++++++++++++++++++++++++++++
> rust/kernel/lib.rs | 2 +
> 6 files changed, 353 insertions(+)
> create mode 100644 rust/helpers/list.c
> create mode 100644 rust/kernel/clist.rs
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 900fc00b73e6..310bb479260c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -23204,6 +23204,13 @@ S: Maintained
> T: git https://github.com/Rust-for-Linux/linux.git rust-analyzer-next
> F: scripts/generate_rust_analyzer.py
>
> +RUST TO C LIST INTERFACES
> +M: Joel Fernandes <joelagnelf@nvidia.com>
> +M: Alexandre Courbot <acourbot@nvidia.com>
> +L: rust-for-linux@vger.kernel.org
> +S: Maintained
> +F: rust/kernel/clist.rs
> +
> RXRPC SOCKETS (AF_RXRPC)
> M: David Howells <dhowells@redhat.com>
> M: Marc Dionne <marc.dionne@auristor.com>
> diff --git a/drivers/gpu/Kconfig b/drivers/gpu/Kconfig
> index 22dd29cd50b5..2c3dec070645 100644
> --- a/drivers/gpu/Kconfig
> +++ b/drivers/gpu/Kconfig
> @@ -1,7 +1,14 @@
> # SPDX-License-Identifier: GPL-2.0
>
> +config RUST_CLIST
> + bool
> + depends on RUST
> + help
> + Rust abstraction for interfacing with C linked lists.
> +
> config GPU_BUDDY
> bool
> + select RUST_CLIST if RUST
> help
> A page based buddy allocator for GPU memory.
>
> diff --git a/rust/helpers/helpers.c b/rust/helpers/helpers.c
> index a3c42e51f00a..724fcb8240ac 100644
> --- a/rust/helpers/helpers.c
> +++ b/rust/helpers/helpers.c
> @@ -35,6 +35,7 @@
> #include "io.c"
> #include "jump_label.c"
> #include "kunit.c"
> +#include "list.c"
> #include "maple_tree.c"
> #include "mm.c"
> #include "mutex.c"
> diff --git a/rust/helpers/list.c b/rust/helpers/list.c
> new file mode 100644
> index 000000000000..3390b154fa36
> --- /dev/null
> +++ b/rust/helpers/list.c
> @@ -0,0 +1,21 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +/*
> + * Helpers for C Circular doubly linked list implementation.
> + */
> +
> +#include <linux/list.h>
> +
> +#ifndef __rust_helper
> +#define __rust_helper
> +#endif
> +
> +__rust_helper void rust_helper_INIT_LIST_HEAD(struct list_head *list)
> +{
> + INIT_LIST_HEAD(list);
> +}
> +
> +__rust_helper void rust_helper_list_add_tail(struct list_head *new, struct list_head *head)
> +{
> + list_add_tail(new, head);
> +}
> diff --git a/rust/kernel/clist.rs b/rust/kernel/clist.rs
> new file mode 100644
> index 000000000000..1f6d4db13c1d
> --- /dev/null
> +++ b/rust/kernel/clist.rs
> @@ -0,0 +1,315 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +//! A C doubly circular intrusive linked list interface for rust code.
> +//!
> +//! # Examples
> +//!
> +//! ```
> +//! use kernel::{
> +//! bindings,
> +//! clist_create,
> +//! types::Opaque, //
> +//! };
> +//! # // Create test list with values (0, 10, 20) - normally done by C code but it is
> +//! # // emulated here for doctests using the C bindings.
> +//! # use core::mem::MaybeUninit;
> +//! #
> +//! # /// C struct with embedded `list_head` (typically will be allocated by C code).
> +//! # #[repr(C)]
> +//! # pub(crate) struct SampleItemC {
> +//! # pub value: i32,
> +//! # pub link: bindings::list_head,
> +//! # }
> +//! #
> +//! # let mut head = MaybeUninit::<bindings::list_head>::uninit();
> +//! #
> +//! # let head = head.as_mut_ptr();
> +//! # // SAFETY: head and all the items are test objects allocated in this scope.
> +//! # unsafe { bindings::INIT_LIST_HEAD(head) };
> +//! #
> +//! # let mut items = [
> +//! # MaybeUninit::<SampleItemC>::uninit(),
> +//! # MaybeUninit::<SampleItemC>::uninit(),
> +//! # MaybeUninit::<SampleItemC>::uninit(),
> +//! # ];
> +//! #
> +//! # for (i, item) in items.iter_mut().enumerate() {
> +//! # let ptr = item.as_mut_ptr();
> +//! # // SAFETY: pointers are to allocated test objects with a list_head field.
> +//! # unsafe {
> +//! # (*ptr).value = i as i32 * 10;
> +//! # // addr_of_mut!() computes address of link directly as link is uninitialized.
> +//! # bindings::INIT_LIST_HEAD(core::ptr::addr_of_mut!((*ptr).link));
Shoudn’t this be &raw mut?
> +//! # bindings::list_add_tail(&mut (*ptr).link, head);
> +//! # }
> +//! # }
> +//!
> +//! // Rust wrapper for the C struct.
> +//! // The list item struct in this example is defined in C code as:
> +//! // struct SampleItemC {
> +//! // int value;
> +//! // struct list_head link;
> +//! // };
> +//! //
> +//! #[repr(transparent)]
> +//! pub(crate) struct Item(Opaque<SampleItemC>);
> +//!
> +//! impl Item {
> +//! pub(crate) fn value(&self) -> i32 {
> +//! // SAFETY: [`Item`] has same layout as [`SampleItemC`].
> +//! unsafe { (*self.0.get()).value }
> +//! }
> +//! }
> +//!
> +//! // Create typed [`CList`] from sentinel head.
> +//! // SAFETY: head is valid, items are [`SampleItemC`] with embedded `link` field.
> +//! let list = unsafe { clist_create!(head, Item, SampleItemC, link) };
> +//!
> +//! // Iterate directly over typed items.
> +//! let mut found_0 = false;
> +//! let mut found_10 = false;
> +//! let mut found_20 = false;
> +//!
> +//! for item in list.iter() {
> +//! let val = item.value();
> +//! if val == 0 { found_0 = true; }
> +//! if val == 10 { found_10 = true; }
> +//! if val == 20 { found_20 = true; }
> +//! }
> +//!
> +//! assert!(found_0 && found_10 && found_20);
> +//! ```
> +
> +use core::{
> + iter::FusedIterator,
> + marker::PhantomData, //
> +};
> +
> +use crate::{
> + bindings,
> + types::Opaque, //
> +};
> +
> +use pin_init::PinInit;
> +
> +/// Wraps a `list_head` object for use in intrusive linked lists.
> +///
> +/// # Invariants
> +///
> +/// - [`CListHead`] represents an allocated and valid `list_head` structure.
> +/// - Once a [`CListHead`] is created in Rust, it will not be modified by non-Rust code.
> +/// - All `list_head` for individual items are not modified for the lifetime of [`CListHead`].
Can you expand on the two points above?
> +#[repr(transparent)]
> +pub(crate) struct CListHead(Opaque<bindings::list_head>);
> +
> +impl CListHead {
> + /// Create a `&CListHead` reference from a raw `list_head` pointer.
> + ///
> + /// # Safety
> + ///
> + /// - `ptr` must be a valid pointer to an allocated and initialized `list_head` structure.
> + /// - `ptr` must remain valid and unmodified for the lifetime `'a`.
> + #[inline]
> + pub(crate) unsafe fn from_raw<'a>(ptr: *mut bindings::list_head) -> &'a Self {
> + // SAFETY:
> + // - [`CListHead`] has same layout as `list_head`.
> + // - `ptr` is valid and unmodified for 'a.
> + unsafe { &*ptr.cast() }
> + }
> +
> + /// Get the raw `list_head` pointer.
> + #[inline]
> + pub(crate) fn as_raw(&self) -> *mut bindings::list_head {
> + self.0.get()
> + }
> +
> + /// Get the next [`CListHead`] in the list.
> + #[inline]
> + pub(crate) fn next(&self) -> &Self {
> + let raw = self.as_raw();
> + // SAFETY:
> + // - `self.as_raw()` is valid per type invariants.
> + // - The `next` pointer is guaranteed to be non-NULL.
> + unsafe { Self::from_raw((*raw).next) }
> + }
> +
> + /// Check if this node is linked in a list (not isolated).
> + #[inline]
> + pub(crate) fn is_linked(&self) -> bool {
> + let raw = self.as_raw();
> + // SAFETY: self.as_raw() is valid per type invariants.
> + unsafe { (*raw).next != raw && (*raw).prev != raw }
I wonder if this is duplicating some C helper?
> + }
> +
> + /// Pin-initializer that initializes the list head.
> + pub(crate) fn new() -> impl PinInit<Self> {
> + // SAFETY: `INIT_LIST_HEAD` initializes `slot` to a valid empty list.
> + unsafe {
> + pin_init::pin_init_from_closure(move |slot: *mut Self| {
> + bindings::INIT_LIST_HEAD(slot.cast());
> + Ok(())
> + })
> + }
> + }
> +}
> +
> +// SAFETY: [`CListHead`] can be sent to any thread.
> +unsafe impl Send for CListHead {}
> +
> +// SAFETY: [`CListHead`] can be shared among threads as it is not modified
> +// by non-Rust code per type invariants.
> +unsafe impl Sync for CListHead {}
> +
> +impl PartialEq for CListHead {
> + fn eq(&self, other: &Self) -> bool {
> + core::ptr::eq(self, other)
> + }
> +}
> +
> +impl Eq for CListHead {}
> +
> +/// Low-level iterator over `list_head` nodes.
> +///
> +/// An iterator used to iterate over a C intrusive linked list (`list_head`). Caller has to
> +/// perform conversion of returned [`CListHead`] to an item (using `container_of` macro or similar).
> +///
> +/// # Invariants
> +///
> +/// [`CListHeadIter`] is iterating over an allocated, initialized and valid list.
> +struct CListHeadIter<'a> {
> + /// Current position in the list.
> + current: &'a CListHead,
> + /// The sentinel head (used to detect end of iteration).
> + sentinel: &'a CListHead,
> +}
> +
> +impl<'a> Iterator for CListHeadIter<'a> {
> + type Item = &'a CListHead;
> +
> + #[inline]
> + fn next(&mut self) -> Option<Self::Item> {
> + // Check if we've reached the sentinel (end of list).
> + if core::ptr::eq(self.current, self.sentinel) {
> + return None;
> + }
I was under the impression that CListHeads implemented PartialEq/Eq?
> +
> + let item = self.current;
> + self.current = item.next();
> + Some(item)
> + }
> +}
> +
> +impl<'a> FusedIterator for CListHeadIter<'a> {}
> +
> +/// A typed C linked list with a sentinel head.
> +///
> +/// A sentinel head represents the entire linked list and can be used for
> +/// iteration over items of type `T`, it is not associated with a specific item.
> +///
> +/// The const generic `OFFSET` specifies the byte offset of the `list_head` field within
> +/// the struct that `T` wraps.
> +///
> +/// # Invariants
> +///
> +/// - The [`CListHead`] is an allocated and valid sentinel C `list_head` structure.
> +/// - `OFFSET` is the byte offset of the `list_head` field within the struct that `T` wraps.
> +/// - All the list's `list_head` nodes are allocated and have valid next/prev pointers.
> +#[repr(transparent)]
> +pub(crate) struct CList<T, const OFFSET: usize>(CListHead, PhantomData<T>);
> +
> +impl<T, const OFFSET: usize> CList<T, OFFSET> {
> + /// Create a typed [`CList`] reference from a raw sentinel `list_head` pointer.
> + ///
> + /// # Safety
> + ///
> + /// - `ptr` must be a valid pointer to an allocated and initialized `list_head` structure
> + /// representing a list sentinel.
> + /// - `ptr` must remain valid and unmodified for the lifetime `'a`.
> + /// - The list must contain items where the `list_head` field is at byte offset `OFFSET`.
> + /// - `T` must be `#[repr(transparent)]` over the C struct.
> + #[inline]
> + pub(crate) unsafe fn from_raw<'a>(ptr: *mut bindings::list_head) -> &'a Self {
> + // SAFETY:
> + // - [`CList`] has same layout as [`CListHead`] due to repr(transparent).
> + // - Caller guarantees `ptr` is a valid, sentinel `list_head` object.
> + unsafe { &*ptr.cast() }
> + }
> +
> + /// Check if the list is empty.
> + #[inline]
> + #[expect(dead_code)]
> + pub(crate) fn is_empty(&self) -> bool {
Why can’t this be pub?
> + !self.0.is_linked()
> + }
> +
> + /// Create an iterator over typed items.
> + #[inline]
> + pub(crate) fn iter(&self) -> CListIter<'_, T, OFFSET> {
> + let head = &self.0;
> + CListIter {
> + head_iter: CListHeadIter {
> + current: head.next(),
> + sentinel: head,
> + },
> + _phantom: PhantomData,
> + }
> + }
> +}
> +
> +/// High-level iterator over typed list items.
> +pub(crate) struct CListIter<'a, T, const OFFSET: usize> {
> + head_iter: CListHeadIter<'a>,
> + _phantom: PhantomData<&'a T>,
> +}
> +
> +impl<'a, T, const OFFSET: usize> Iterator for CListIter<'a, T, OFFSET> {
> + type Item = &'a T;
> +
> + fn next(&mut self) -> Option<Self::Item> {
> + let head = self.head_iter.next()?;
> +
> + // Convert to item using OFFSET.
> + // SAFETY: `item_ptr` calculation from `OFFSET` (calculated using offset_of!)
> + // is valid per invariants.
> + Some(unsafe { &*head.as_raw().byte_sub(OFFSET).cast::<T>() })
> + }
> +}
> +
> +impl<'a, T, const OFFSET: usize> FusedIterator for CListIter<'a, T, OFFSET> {}
> +
> +/// Create a C doubly-circular linked list interface `CList` from a raw `list_head` pointer.
> +///
> +/// This macro creates a `CList<T, OFFSET>` that can iterate over items of type `$rust_type`
> +/// linked via the `$field` field in the underlying C struct `$c_type`.
> +///
> +/// # Arguments
> +///
> +/// - `$head`: Raw pointer to the sentinel `list_head` object (`*mut bindings::list_head`).
> +/// - `$rust_type`: Each item's rust wrapper type.
> +/// - `$c_type`: Each item's C struct type that contains the embedded `list_head`.
> +/// - `$field`: The name of the `list_head` field within the C struct.
> +///
> +/// # Safety
> +///
> +/// This is an unsafe macro. The caller must ensure:
> +///
> +/// - `$head` is a valid, initialized sentinel `list_head` pointing to a list that remains
> +/// unmodified for the lifetime of the rust `CList`.
> +/// - The list contains items of type `$c_type` linked via an embedded `$field`.
> +/// - `$rust_type` is `#[repr(transparent)]` over `$c_type` or has compatible layout.
> +///
> +/// # Examples
> +///
> +/// Refer to the examples in this module's documentation.
> +#[macro_export]
> +macro_rules! clist_create {
> + ($head:expr, $rust_type:ty, $c_type:ty, $($field:tt).+) => {{
> + // Compile-time check that field path is a list_head.
> + let _: fn(*const $c_type) -> *const $crate::bindings::list_head =
> + |p| &raw const (*p).$($field).+;
> +
> + // Calculate offset and create `CList`.
> + const OFFSET: usize = ::core::mem::offset_of!($c_type, $($field).+);
> + $crate::clist::CList::<$rust_type, OFFSET>::from_raw($head)
> + }};
> +}
> diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
> index 3da92f18f4ee..8439c30f40b5 100644
> --- a/rust/kernel/lib.rs
> +++ b/rust/kernel/lib.rs
> @@ -75,6 +75,8 @@
> pub mod bug;
> #[doc(hidden)]
> pub mod build_assert;
> +#[cfg(CONFIG_RUST_CLIST)]
> +pub(crate) mod clist;
> pub mod clk;
> #[cfg(CONFIG_CONFIGFS_FS)]
> pub mod configfs;
> --
> 2.34.1
>
>
^ permalink raw reply
* Re: [PATCH] fbdev: au1200fb: Fix a memory leak in au1200fb_drv_probe()
From: Helge Deller @ 2026-02-06 19:32 UTC (permalink / raw)
To: Felix Gu, Zhang Shurong; +Cc: linux-fbdev, dri-devel, linux-kernel
In-Reply-To: <20260203-au1200fb-v1-1-7889c4061337@gmail.com>
On 2/3/26 13:14, Felix Gu wrote:
> In au1200fb_drv_probe(), when platform_get_irq fails(), it directly
> returns from the function with an error code, which causes a memory
> leak.
>
> Replace it with a goto label to ensure proper cleanup.
>
> Fixes: 4e88761f5f8c ("fbdev: au1200fb: Fix missing IRQ check in au1200fb_drv_probe")
> Signed-off-by: Felix Gu <ustc.gu@gmail.com>
> ---
> drivers/video/fbdev/au1200fb.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
applied.
Thanks!
Helge
^ permalink raw reply
* Re: [PATCH -next v7 1/2] rust: clist: Add support to interface with C linked lists
From: Joel Fernandes @ 2026-02-06 20:44 UTC (permalink / raw)
To: Danilo Krummrich, Gary Guo
Cc: linux-kernel, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, Jonathan Corbet, Alex Deucher,
Christian König, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Huang Rui, Matthew Auld, Matthew Brost,
Lucas De Marchi, Thomas Hellström, Helge Deller, Alice Ryhl,
Miguel Ojeda, Alex Gaynor, Boqun Feng, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Trevor Gross, John Hubbard,
Alistair Popple, Timur Tabi, Edwin Peer, Alexandre Courbot,
Andrea Righi, Andy Ritger, Zhi Wang, Balbir Singh,
Philipp Stanner, Elle Rhumsaa, Daniel Almeida, joel, nouveau,
dri-devel, rust-for-linux, linux-doc, amd-gfx, intel-gfx,
intel-xe, linux-fbdev
In-Reply-To: <DG81PJ9QD8FC.2NF6VEKDD3F2Q@kernel.org>
On 2/6/2026 12:13 PM, Danilo Krummrich wrote:
> On Fri Feb 6, 2026 at 5:13 PM CET, Gary Guo wrote:
>> On Fri Feb 6, 2026 at 4:05 PM GMT, Joel Fernandes wrote:
>>>
>>>
>>> On 2/6/2026 10:53 AM, Danilo Krummrich wrote:
>>>> On Fri Feb 6, 2026 at 4:25 PM CET, Gary Guo wrote:
>>>>> On Fri Feb 6, 2026 at 12:41 AM GMT, Joel Fernandes wrote:
>>>>>> diff --git a/drivers/gpu/Kconfig b/drivers/gpu/Kconfig
>>>>>> index 22dd29cd50b5..2c3dec070645 100644
>>>>>> --- a/drivers/gpu/Kconfig
>>>>>> +++ b/drivers/gpu/Kconfig
>>>>>> @@ -1,7 +1,14 @@
>>>>>> # SPDX-License-Identifier: GPL-2.0
>>>>>>
>>>>>> +config RUST_CLIST
>>>>>> + bool
>>>>>> + depends on RUST
>>>>>> + help
>>>>>> + Rust abstraction for interfacing with C linked lists.
>>>>>
>>>>> I am not sure if we need extra config entry. This is fully generic so shouldn't
>>>>> generate any code unless there is an user.
>>>>
>>>> I also don't think we need a Kconfig for this.
>>>>
>>>> In any case, it shouln't be in drivers/gpu/Kconfig.
>>>
>>> Fair point, I believe I was having trouble compiling this into the kernel crate
>>> without warnings (I believe if !GPU_BUDDY). I'll try to drop it and see if we
>>> can get rid of it.
>>
>> If you run into dead code warnings, I think it is fine to just
>>
>> #[allow(dead_code, reason = "all users might be cfg-ed out")]
>>
>> the overhead of just let rustc type-checking this module isn't worth the extra
>> Kconfig plumbing, I think.
>
> You mean because there are pub(crate) in clist.rs? I don't think the Kconfig
> would help with that, nothing prevents people from enabling RUST_CLIST, but none
> of the users.
I think he means add the alloc annotation to suppress deadcode warnings and get
rid of the Kconfig?
> Besides that, once we have the new build system, the users of CList are likely
> in other crates anyways, so I think we should just change things to pub.
I agree with both approaches. Perhaps changing to pub is better to avoid churn
in the future when other crates use it.
--
Joel Fernandes
^ permalink raw reply
* Re: [PATCH -next v7 1/2] rust: clist: Add support to interface with C linked lists
From: Joel Fernandes @ 2026-02-06 20:46 UTC (permalink / raw)
To: Daniel Almeida
Cc: linux-kernel, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, Jonathan Corbet, Alex Deucher,
Christian König, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Huang Rui, Matthew Auld, Matthew Brost,
Lucas De Marchi, Thomas Hellström, Helge Deller,
Danilo Krummrich, Alice Ryhl, Miguel Ojeda, Alex Gaynor,
Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Andreas Hindborg, Trevor Gross, John Hubbard, Alistair Popple,
Timur Tabi, Edwin Peer, Alexandre Courbot, Andrea Righi,
Andy Ritger, Zhi Wang, Balbir Singh, Philipp Stanner,
Elle Rhumsaa, joel, nouveau, dri-devel, rust-for-linux, linux-doc,
amd-gfx, intel-gfx, intel-xe, linux-fbdev
In-Reply-To: <73B64D35-6574-4776-962D-865465C40226@collabora.com>
On 2/6/2026 12:49 PM, Daniel Almeida wrote:
>> +#[repr(transparent)]
>> +pub(crate) struct CList<T, const OFFSET: usize>(CListHead, PhantomData<T>);
>> +
>> +impl<T, const OFFSET: usize> CList<T, OFFSET> {
>> + /// Create a typed [`CList`] reference from a raw sentinel `list_head` pointer.
>> + ///
>> + /// # Safety
>> + ///
>> + /// - `ptr` must be a valid pointer to an allocated and initialized `list_head` structure
>> + /// representing a list sentinel.
>> + /// - `ptr` must remain valid and unmodified for the lifetime `'a`.
>> + /// - The list must contain items where the `list_head` field is at byte offset `OFFSET`.
>> + /// - `T` must be `#[repr(transparent)]` over the C struct.
>> + #[inline]
>> + pub(crate) unsafe fn from_raw<'a>(ptr: *mut bindings::list_head) -> &'a Self {
>> + // SAFETY:
>> + // - [`CList`] has same layout as [`CListHead`] due to repr(transparent).
>> + // - Caller guarantees `ptr` is a valid, sentinel `list_head` object.
>> + unsafe { &*ptr.cast() }
>> + }
>> +
>> + /// Check if the list is empty.
>> + #[inline]
>> + #[expect(dead_code)]
>> + pub(crate) fn is_empty(&self) -> bool {
>
> Why can’t this be pub?
I believe this was suggested by Gary. See the other thread where we are
discussing it (with Gary and Danilo) and let us discuss there.
--
Joel Fernandes
^ permalink raw reply
* Re: [PATCH -next v7 1/2] rust: clist: Add support to interface with C linked lists
From: Gary Guo @ 2026-02-06 20:51 UTC (permalink / raw)
To: Joel Fernandes, Daniel Almeida
Cc: linux-kernel, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, Jonathan Corbet, Alex Deucher,
Christian König, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Huang Rui, Matthew Auld, Matthew Brost,
Lucas De Marchi, Thomas Hellström, Helge Deller,
Danilo Krummrich, Alice Ryhl, Miguel Ojeda, Alex Gaynor,
Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Andreas Hindborg, Trevor Gross, John Hubbard, Alistair Popple,
Timur Tabi, Edwin Peer, Alexandre Courbot, Andrea Righi,
Andy Ritger, Zhi Wang, Balbir Singh, Philipp Stanner,
Elle Rhumsaa, joel, nouveau, dri-devel, rust-for-linux, linux-doc,
amd-gfx, intel-gfx, intel-xe, linux-fbdev
In-Reply-To: <8dde5b79-29d6-4840-be9a-31bc4af27cf9@nvidia.com>
On Fri Feb 6, 2026 at 8:46 PM GMT, Joel Fernandes wrote:
> On 2/6/2026 12:49 PM, Daniel Almeida wrote:
>>> +#[repr(transparent)]
>>> +pub(crate) struct CList<T, const OFFSET: usize>(CListHead, PhantomData<T>);
>>> +
>>> +impl<T, const OFFSET: usize> CList<T, OFFSET> {
>>> + /// Create a typed [`CList`] reference from a raw sentinel `list_head` pointer.
>>> + ///
>>> + /// # Safety
>>> + ///
>>> + /// - `ptr` must be a valid pointer to an allocated and initialized `list_head` structure
>>> + /// representing a list sentinel.
>>> + /// - `ptr` must remain valid and unmodified for the lifetime `'a`.
>>> + /// - The list must contain items where the `list_head` field is at byte offset `OFFSET`.
>>> + /// - `T` must be `#[repr(transparent)]` over the C struct.
>>> + #[inline]
>>> + pub(crate) unsafe fn from_raw<'a>(ptr: *mut bindings::list_head) -> &'a Self {
>>> + // SAFETY:
>>> + // - [`CList`] has same layout as [`CListHead`] due to repr(transparent).
>>> + // - Caller guarantees `ptr` is a valid, sentinel `list_head` object.
>>> + unsafe { &*ptr.cast() }
>>> + }
>>> +
>>> + /// Check if the list is empty.
>>> + #[inline]
>>> + #[expect(dead_code)]
>>> + pub(crate) fn is_empty(&self) -> bool {
>>
>> Why can’t this be pub?
>
> I believe this was suggested by Gary. See the other thread where we are
> discussing it (with Gary and Danilo) and let us discuss there.
I suggested the module to be `pub(crate)`. For the individual item it is not
necessary if the module itself already have limited visibility.
Best,
Gary
^ permalink raw reply
* Re: [PATCH -next v7 1/2] rust: clist: Add support to interface with C linked lists
From: Joel Fernandes @ 2026-02-06 20:51 UTC (permalink / raw)
To: Daniel Almeida
Cc: linux-kernel, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, Jonathan Corbet, Alex Deucher,
Christian König, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Huang Rui, Matthew Auld, Matthew Brost,
Lucas De Marchi, Thomas Hellström, Helge Deller,
Danilo Krummrich, Alice Ryhl, Miguel Ojeda, Alex Gaynor,
Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Andreas Hindborg, Trevor Gross, John Hubbard, Alistair Popple,
Timur Tabi, Edwin Peer, Alexandre Courbot, Andrea Righi,
Andy Ritger, Zhi Wang, Balbir Singh, Philipp Stanner,
Elle Rhumsaa, joel, nouveau, dri-devel, rust-for-linux, linux-doc,
amd-gfx, intel-gfx, intel-xe, linux-fbdev
In-Reply-To: <73B64D35-6574-4776-962D-865465C40226@collabora.com>
Hi Daniel,
Hope you do not mind me replying piecemeal as I can reply more quickly. Thank
you for all the comments.
On 2/6/2026 12:49 PM, Daniel Almeida wrote:
>> +use crate::{
>> + bindings,
>> + types::Opaque, //
>> +};
>> +
>> +use pin_init::PinInit;
>> +
>> +/// Wraps a `list_head` object for use in intrusive linked lists.
>> +///
>> +/// # Invariants
>> +///
>> +/// - [`CListHead`] represents an allocated and valid `list_head` structure.
>> +/// - Once a [`CListHead`] is created in Rust, it will not be modified by non-Rust code.
>> +/// - All `list_head` for individual items are not modified for the lifetime of [`CListHead`].
>
> Can you expand on the two points above?
This is basically saying that a C `list_head` that is wrapped by a `CListHead`
is read-only for the lifetime of `ClistHead`. modifying the pointers anymore.
That is the invariant.
Or did I miss something?
--
Joel Fernandes
^ permalink raw reply
* Re: [PATCH -next v7 1/2] rust: clist: Add support to interface with C linked lists
From: Joel Fernandes @ 2026-02-06 21:12 UTC (permalink / raw)
To: Gary Guo, Daniel Almeida
Cc: linux-kernel, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, Jonathan Corbet, Alex Deucher,
Christian König, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Huang Rui, Matthew Auld, Matthew Brost,
Lucas De Marchi, Thomas Hellström, Helge Deller,
Danilo Krummrich, Alice Ryhl, Miguel Ojeda, Alex Gaynor,
Boqun Feng, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross, John Hubbard, Alistair Popple, Timur Tabi,
Edwin Peer, Alexandre Courbot, Andrea Righi, Andy Ritger,
Zhi Wang, Balbir Singh, Philipp Stanner, Elle Rhumsaa, joel,
nouveau, dri-devel, rust-for-linux, linux-doc, amd-gfx, intel-gfx,
intel-xe, linux-fbdev
In-Reply-To: <DG86CJXCM7DB.1A4F4JTMSS9ZZ@garyguo.net>
On 2/6/2026 3:51 PM, Gary Guo wrote:
> On Fri Feb 6, 2026 at 8:46 PM GMT, Joel Fernandes wrote:
>> On 2/6/2026 12:49 PM, Daniel Almeida wrote:
>>>> +#[repr(transparent)]
>>>> +pub(crate) struct CList<T, const OFFSET: usize>(CListHead, PhantomData<T>);
>>>> +
>>>> +impl<T, const OFFSET: usize> CList<T, OFFSET> {
>>>> + /// Create a typed [`CList`] reference from a raw sentinel `list_head` pointer.
>>>> + ///
>>>> + /// # Safety
>>>> + ///
>>>> + /// - `ptr` must be a valid pointer to an allocated and initialized `list_head` structure
>>>> + /// representing a list sentinel.
>>>> + /// - `ptr` must remain valid and unmodified for the lifetime `'a`.
>>>> + /// - The list must contain items where the `list_head` field is at byte offset `OFFSET`.
>>>> + /// - `T` must be `#[repr(transparent)]` over the C struct.
>>>> + #[inline]
>>>> + pub(crate) unsafe fn from_raw<'a>(ptr: *mut bindings::list_head) -> &'a Self {
>>>> + // SAFETY:
>>>> + // - [`CList`] has same layout as [`CListHead`] due to repr(transparent).
>>>> + // - Caller guarantees `ptr` is a valid, sentinel `list_head` object.
>>>> + unsafe { &*ptr.cast() }
>>>> + }
>>>> +
>>>> + /// Check if the list is empty.
>>>> + #[inline]
>>>> + #[expect(dead_code)]
>>>> + pub(crate) fn is_empty(&self) -> bool {
>>>
>>> Why can’t this be pub?
>>
>> I believe this was suggested by Gary. See the other thread where we are
>> discussing it (with Gary and Danilo) and let us discuss there.
>
> I suggested the module to be `pub(crate)`. For the individual item it is not
> necessary if the module itself already have limited visibility.
>
Sure, I can change it to module-level pub then, and drop the pub(crate) if
everyone agrees.
--
Joel Fernandes
^ permalink raw reply
* Re: [PATCH -next v7 1/2] rust: clist: Add support to interface with C linked lists
From: Daniel Almeida @ 2026-02-06 21:21 UTC (permalink / raw)
To: Joel Fernandes
Cc: linux-kernel, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, Jonathan Corbet, Alex Deucher,
Christian König, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Huang Rui, Matthew Auld, Matthew Brost,
Lucas De Marchi, Thomas Hellström, Helge Deller,
Danilo Krummrich, Alice Ryhl, Miguel Ojeda, Alex Gaynor,
Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Andreas Hindborg, Trevor Gross, John Hubbard, Alistair Popple,
Timur Tabi, Edwin Peer, Alexandre Courbot, Andrea Righi,
Andy Ritger, Zhi Wang, Balbir Singh, Philipp Stanner,
Elle Rhumsaa, joel, nouveau, dri-devel, rust-for-linux, linux-doc,
amd-gfx, intel-gfx, intel-xe, linux-fbdev
In-Reply-To: <7ed85eca-2a5e-4e8f-8356-e7fbbf7d3a8f@nvidia.com>
> On 6 Feb 2026, at 17:51, Joel Fernandes <joelagnelf@nvidia.com> wrote:
>
> Hi Daniel,
> Hope you do not mind me replying piecemeal as I can reply more quickly. Thank
> you for all the comments.
>
> On 2/6/2026 12:49 PM, Daniel Almeida wrote:
>>> +use crate::{
>>> + bindings,
>>> + types::Opaque, //
>>> +};
>>> +
>>> +use pin_init::PinInit;
>>> +
>>> +/// Wraps a `list_head` object for use in intrusive linked lists.
>>> +///
>>> +/// # Invariants
>>> +///
>>> +/// - [`CListHead`] represents an allocated and valid `list_head` structure.
>>> +/// - Once a [`CListHead`] is created in Rust, it will not be modified by non-Rust code.
>>> +/// - All `list_head` for individual items are not modified for the lifetime of [`CListHead`].
>>
>> Can you expand on the two points above?
>
> This is basically saying that a C `list_head` that is wrapped by a `CListHead`
> is read-only for the lifetime of `ClistHead`. modifying the pointers anymore.
> That is the invariant.
>
> Or did I miss something?
>
> --
> Joel Fernandes
>
>
Yeah, but my point being: is there a reason why the underlying list has to
remain read-only? Is this a safety requirement or an invariant that is established
by the code above?
— Daniel
^ permalink raw reply
* Re: [PATCH -next v7 1/2] rust: clist: Add support to interface with C linked lists
From: Joel Fernandes @ 2026-02-06 21:26 UTC (permalink / raw)
To: Daniel Almeida
Cc: linux-kernel, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, Jonathan Corbet, Alex Deucher,
Christian König, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Huang Rui, Matthew Auld, Matthew Brost,
Lucas De Marchi, Thomas Hellström, Helge Deller,
Danilo Krummrich, Alice Ryhl, Miguel Ojeda, Alex Gaynor,
Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Andreas Hindborg, Trevor Gross, John Hubbard, Alistair Popple,
Timur Tabi, Edwin Peer, Alexandre Courbot, Andrea Righi,
Andy Ritger, Zhi Wang, Balbir Singh, Philipp Stanner,
Elle Rhumsaa, joel, nouveau, dri-devel, rust-for-linux, linux-doc,
amd-gfx, intel-gfx, intel-xe, linux-fbdev
In-Reply-To: <E846F3BB-DE64-4E6B-ACA3-00F965038478@collabora.com>
On 2/6/2026 4:21 PM, Daniel Almeida wrote:
>
>
>> On 6 Feb 2026, at 17:51, Joel Fernandes <joelagnelf@nvidia.com> wrote:
>>
>> Hi Daniel,
>> Hope you do not mind me replying piecemeal as I can reply more quickly. Thank
>> you for all the comments.
>>
>> On 2/6/2026 12:49 PM, Daniel Almeida wrote:
>>>> +use crate::{
>>>> + bindings,
>>>> + types::Opaque, //
>>>> +};
>>>> +
>>>> +use pin_init::PinInit;
>>>> +
>>>> +/// Wraps a `list_head` object for use in intrusive linked lists.
>>>> +///
>>>> +/// # Invariants
>>>> +///
>>>> +/// - [`CListHead`] represents an allocated and valid `list_head` structure.
>>>> +/// - Once a [`CListHead`] is created in Rust, it will not be modified by non-Rust code.
>>>> +/// - All `list_head` for individual items are not modified for the lifetime of [`CListHead`].
>>>
>>> Can you expand on the two points above?
>>
>> This is basically saying that a C `list_head` that is wrapped by a `CListHead`
>> is read-only for the lifetime of `ClistHead`. modifying the pointers anymore.
>> That is the invariant.
>>
>> Or did I miss something?
>>
>> --
>> Joel Fernandes
>>
>>
>
>
> Yeah, but my point being: is there a reason why the underlying list has to
> remain read-only? Is this a safety requirement or an invariant that is established
> by the code above?
I'm not fully sure if it's an invariant or a safety requirement, but anyone
creating a C list head on the rust side must guarantee that it is not modified.
Since rust has no visibility on the C side, I believe it is a Rust invariant
here that the existence of CListHead assumes that the list cannot be modified
once Rust has access over it. That is up to the creator (user) of the CListHead
to guarantee. In the DRM buddy case, once the list is allocated and accessible
from Rust, C code will not modify it while the Rust object exists.
Does that make sense, or is there a better way to document this?
--
Joel Fernandes
^ permalink raw reply
* Re: [PATCH -next v7 1/2] rust: clist: Add support to interface with C linked lists
From: Daniel Almeida @ 2026-02-06 21:30 UTC (permalink / raw)
To: Danilo Krummrich
Cc: Gary Guo, Joel Fernandes, linux-kernel, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Alex Deucher, Christian König, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin, Huang Rui,
Matthew Auld, Matthew Brost, Lucas De Marchi,
Thomas Hellström, Helge Deller, Alice Ryhl, Miguel Ojeda,
Alex Gaynor, Boqun Feng, Björn Roy Baron, Benno Lossin,
Andreas Hindborg, Trevor Gross, John Hubbard, Alistair Popple,
Timur Tabi, Edwin Peer, Alexandre Courbot, Andrea Righi,
Andy Ritger, Zhi Wang, Balbir Singh, Philipp Stanner,
Elle Rhumsaa, joel, nouveau, dri-devel, rust-for-linux, linux-doc,
amd-gfx, intel-gfx, intel-xe, linux-fbdev
In-Reply-To: <DG820GM5YHJS.11E92OR824CWM@kernel.org>
> On 6 Feb 2026, at 14:27, Danilo Krummrich <dakr@kernel.org> wrote:
>
> On Fri Feb 6, 2026 at 6:20 PM CET, Gary Guo wrote:
>> I asked for this to be changed to `pub(crate)` because I think this isn't
>> something that should be used by drivers.
>>
>> As you said, tt might be tricky to enforce that with new build system when
>> subsystems are inside different crates. But until then I think it's better to
>> limit visibility.
>
> It should *usually* not be used by drivers, but there are exceptions. For
> instance, it is perfectly valid to be used by Rust drivers that interact with C
> drivers.
I agree with what Danilo said here.
I don’t see a reason to forbid drivers from using this. If the reason is
the unsafe bits, then isn’t it the same pattern used by impl_has_work!()
anyways? i.e.: a macro that implements an unsafe trait so long as the driver
gives it the right Work field. Seems equivalent in spirit to the clist_create macro
introduced by this patch.
— Daniel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox