This patch series adds Rust bindings and safe abstractions for the Linux
framebuffer subsystem, enabling framebuffer drivers to be implemented in Rust.

The series consists of 4 patches:

1. rust: io: mem: add ioremap_wc support
   Adds write-combining memory mapping support to the Rust iomem abstraction,
   which is essential for framebuffer memory regions that benefit from
   write-combining semantics.

2. rust: device: add platdata accessors
   Implements generic accessors for platform data, enabling drivers to access
   platform-provided configuration. This is needed for framebuffer drivers
   that use platform data for configuration.

3. rust: fb: add framebuffer driver support
   Adds the core framebuffer framework abstraction, including:
   - Device abstraction (`fb::Device`) with reference counting via `AlwaysRefCounted`
   - Driver and Operations traits (`fb::Driver`, `fb::Operations`)
   - Screen information wrappers (`fb::FixScreenInfo`, `fb::VarScreenInfo`)
   - I/O operation helpers (`fb_io_read`, `fb_io_write`, `fb_io_mmap`)
   - Blit operation helpers (`cfb_fillrect`, `cfb_copyarea`, `cfb_imageblit`)

4. rust: fb: add simplefb test driver
   Adds a test driver that validates the framebuffer framework by porting
   the C simplefb driver to Rust. This driver serves as both a validation
   tool and a reference implementation for future Rust framebuffer drivers.

The implementation follows the same patterns established in the DRM subsystem
and maintains full compatibility with the existing C framebuffer subsystem.
All C callbacks are properly bridged to Rust trait methods via the `Operations`
trait, memory safety is ensured through proper use of `Opaque<fb_info>`, `ARef`,
and `AlwaysRefCounted` for reference counting, type invariants are documented
and enforced through the type system, and resource cleanup is handled via RAII
with proper cleanup order.

Testing:
--------
This series has been tested on:
- ARM64 platforms with various display configurations
- AMD RX550 graphics card
- Moore Threads S30 graphics card
- Multiple other graphics cards

All tested configurations show normal display functionality with proper
framebuffer initialization, rendering operations (including I/O, color register
management, and blitting), memory mapping, and resource cleanup. The simplefb
test driver successfully demonstrates the usage of all framebuffer framework
APIs and validates the abstraction's correctness.

The simplefb test driver serves as both a validation tool and a reference
implementation for future Rust framebuffer drivers.


pengfuyuan (4):
  rust: io: mem: add ioremap_wc support
  rust: device: add platdata accessors
  rust: fb: add framebuffer driver support
  rust: fb: add simplefb test driver

 drivers/video/fbdev/Kconfig          |  21 +
 drivers/video/fbdev/Makefile         |   1 +
 drivers/video/fbdev/simplefb_rust.rs | 653 +++++++++++++++++++++++++++
 rust/bindings/bindings_helper.h      |   2 +
 rust/helpers/device.c                |   5 +
 rust/helpers/io.c                    |   5 +
 rust/kernel/device.rs                |  31 ++
 rust/kernel/fb/blit.rs               | 106 +++++
 rust/kernel/fb/device.rs             | 463 +++++++++++++++++++
 rust/kernel/fb/driver.rs             | 169 +++++++
 rust/kernel/fb/io.rs                 |  76 ++++
 rust/kernel/fb/mod.rs                |  23 +
 rust/kernel/fb/screeninfo.rs         | 318 +++++++++++++
 rust/kernel/io/mem.rs                |  71 +++
 rust/kernel/lib.rs                   |   2 +
 15 files changed, 1946 insertions(+)
 create mode 100644 drivers/video/fbdev/simplefb_rust.rs
 create mode 100644 rust/kernel/fb/blit.rs
 create mode 100644 rust/kernel/fb/device.rs
 create mode 100644 rust/kernel/fb/driver.rs
 create mode 100644 rust/kernel/fb/io.rs
 create mode 100644 rust/kernel/fb/mod.rs
 create mode 100644 rust/kernel/fb/screeninfo.rs

-- 
2.25.1

On Mon, Jan 26, 2026 at 04:17:40PM +0800, pengfuyuan wrote:
> This series has been tested on:
> - ARM64 platforms with various display configurations
> - AMD RX550 graphics card
> - Moore Threads S30 graphics card
> - Multiple other graphics cards

How?  If there is no rust framebuffer drivers for those hardware
platforms, how exactly were these new codepaths tested?

> All tested configurations show normal display functionality with proper
> framebuffer initialization, rendering operations (including I/O, color register
> management, and blitting), memory mapping, and resource cleanup. The simplefb
> test driver successfully demonstrates the usage of all framebuffer framework
> APIs and validates the abstraction's correctness.

Really?  Where are the drivers for this?  Or did simplefb really work
for all of them?

confused,

greg k-h

Hi

Am 26.01.26 um 09:17 schrieb pengfuyuan:
> This patch series adds Rust bindings and safe abstractions for the Linux
> framebuffer subsystem, enabling framebuffer drivers to be implemented in Rust.

The framebuffer subsystem is obsolete and has been deprecated for a 
decade. No new drivers accepted. Anything that really wants fbdev 
already has a driver. Can we please let it die?

Best regards
Thomas

>
> The series consists of 4 patches:
>
> 1. rust: io: mem: add ioremap_wc support
>     Adds write-combining memory mapping support to the Rust iomem abstraction,
>     which is essential for framebuffer memory regions that benefit from
>     write-combining semantics.
>
> 2. rust: device: add platdata accessors
>     Implements generic accessors for platform data, enabling drivers to access
>     platform-provided configuration. This is needed for framebuffer drivers
>     that use platform data for configuration.
>
> 3. rust: fb: add framebuffer driver support
>     Adds the core framebuffer framework abstraction, including:
>     - Device abstraction (`fb::Device`) with reference counting via `AlwaysRefCounted`
>     - Driver and Operations traits (`fb::Driver`, `fb::Operations`)
>     - Screen information wrappers (`fb::FixScreenInfo`, `fb::VarScreenInfo`)
>     - I/O operation helpers (`fb_io_read`, `fb_io_write`, `fb_io_mmap`)
>     - Blit operation helpers (`cfb_fillrect`, `cfb_copyarea`, `cfb_imageblit`)
>
> 4. rust: fb: add simplefb test driver
>     Adds a test driver that validates the framebuffer framework by porting
>     the C simplefb driver to Rust. This driver serves as both a validation
>     tool and a reference implementation for future Rust framebuffer drivers.
>
> The implementation follows the same patterns established in the DRM subsystem
> and maintains full compatibility with the existing C framebuffer subsystem.
> All C callbacks are properly bridged to Rust trait methods via the `Operations`
> trait, memory safety is ensured through proper use of `Opaque<fb_info>`, `ARef`,
> and `AlwaysRefCounted` for reference counting, type invariants are documented
> and enforced through the type system, and resource cleanup is handled via RAII
> with proper cleanup order.
>
> Testing:
> --------
> This series has been tested on:
> - ARM64 platforms with various display configurations
> - AMD RX550 graphics card
> - Moore Threads S30 graphics card
> - Multiple other graphics cards
>
> All tested configurations show normal display functionality with proper
> framebuffer initialization, rendering operations (including I/O, color register
> management, and blitting), memory mapping, and resource cleanup. The simplefb
> test driver successfully demonstrates the usage of all framebuffer framework
> APIs and validates the abstraction's correctness.
>
> The simplefb test driver serves as both a validation tool and a reference
> implementation for future Rust framebuffer drivers.
>
>
> pengfuyuan (4):
>    rust: io: mem: add ioremap_wc support
>    rust: device: add platdata accessors
>    rust: fb: add framebuffer driver support
>    rust: fb: add simplefb test driver
>
>   drivers/video/fbdev/Kconfig          |  21 +
>   drivers/video/fbdev/Makefile         |   1 +
>   drivers/video/fbdev/simplefb_rust.rs | 653 +++++++++++++++++++++++++++
>   rust/bindings/bindings_helper.h      |   2 +
>   rust/helpers/device.c                |   5 +
>   rust/helpers/io.c                    |   5 +
>   rust/kernel/device.rs                |  31 ++
>   rust/kernel/fb/blit.rs               | 106 +++++
>   rust/kernel/fb/device.rs             | 463 +++++++++++++++++++
>   rust/kernel/fb/driver.rs             | 169 +++++++
>   rust/kernel/fb/io.rs                 |  76 ++++
>   rust/kernel/fb/mod.rs                |  23 +
>   rust/kernel/fb/screeninfo.rs         | 318 +++++++++++++
>   rust/kernel/io/mem.rs                |  71 +++
>   rust/kernel/lib.rs                   |   2 +
>   15 files changed, 1946 insertions(+)
>   create mode 100644 drivers/video/fbdev/simplefb_rust.rs
>   create mode 100644 rust/kernel/fb/blit.rs
>   create mode 100644 rust/kernel/fb/device.rs
>   create mode 100644 rust/kernel/fb/driver.rs
>   create mode 100644 rust/kernel/fb/io.rs
>   create mode 100644 rust/kernel/fb/mod.rs
>   create mode 100644 rust/kernel/fb/screeninfo.rs
>

-- 
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)

On 1/26/26 11:01, Thomas Zimmermann wrote:
> Am 26.01.26 um 09:17 schrieb pengfuyuan:
>> This patch series adds Rust bindings and safe abstractions for the Linux
>> framebuffer subsystem, enabling framebuffer drivers to be implemented in Rust.
> 
> The framebuffer subsystem is obsolete and has been deprecated for a
> decade. No new drivers accepted. Anything that really wants fbdev
> already has a driver. Can we please let it die?

Agreed. Adding rust bindings for fbdev doesn't make sense. Existing fbdev
drivers are often used on architectures, where rust isn't even available
(alpha, hppa, m68k, sh4, ..), so even the idea to "port" existing drivers
to rust is useless.

Helge

On Mon Jan 26, 2026 at 7:01 PM JST, Thomas Zimmermann wrote:
> Hi
>
> Am 26.01.26 um 09:17 schrieb pengfuyuan:
>> This patch series adds Rust bindings and safe abstractions for the Linux
>> framebuffer subsystem, enabling framebuffer drivers to be implemented in Rust.
>
> The framebuffer subsystem is obsolete and has been deprecated for a 
> decade. No new drivers accepted. Anything that really wants fbdev 
> already has a driver. Can we please let it die?

This, and the patchset is also obviously AI-generated.

On Mon, Jan 26, 2026 at 07:28:21PM +0900, Alexandre Courbot wrote:
> On Mon Jan 26, 2026 at 7:01 PM JST, Thomas Zimmermann wrote:
> > Hi
> >
> > Am 26.01.26 um 09:17 schrieb pengfuyuan:
> >> This patch series adds Rust bindings and safe abstractions for the Linux
> >> framebuffer subsystem, enabling framebuffer drivers to be implemented in Rust.
> >
> > The framebuffer subsystem is obsolete and has been deprecated for a 
> > decade. No new drivers accepted. Anything that really wants fbdev 
> > already has a driver. Can we please let it die?
> 
> This, and the patchset is also obviously AI-generated.

Hi,
Thank you for the feedback.
I’d like to be clear about how I used AI in this work:

1.Cover letter – Yes, I used AI to help summarize and phrase the cover letter.
2.Comments in the code – Some comments were written or refined with AI assistance.
3.Learning the codebase – When reading and understanding existing Rust-for-Linux code (including DRM and other abstractions), I used AI as a helper to analyze and explain structure and patterns.
4.Writing the code – The implementation was not fully generated by AI.  I wrote the code myself and used AI mainly to look up existing abstractions, traits, and APIs (e.g. “how does X work? ”, “what’s the right trait for Y?”)  while I was coding.

So: AI was used for summaries, comments, learning, and looking things up;  the logic and structure of the code are mine, and I take responsibility for them.
If you have concerns about specific parts (e.g. wording, style, or design), I’m happy to rework those patches or to adjust how I describe tool use in future submissions.

Thanks,
pengfuyuan

On Tue Jan 27, 2026 at 5:04 PM JST, pengfuyuan wrote:
> On Mon, Jan 26, 2026 at 07:28:21PM +0900, Alexandre Courbot wrote:
>> On Mon Jan 26, 2026 at 7:01 PM JST, Thomas Zimmermann wrote:
>> > Hi
>> >
>> > Am 26.01.26 um 09:17 schrieb pengfuyuan:
>> >> This patch series adds Rust bindings and safe abstractions for the Linux
>> >> framebuffer subsystem, enabling framebuffer drivers to be implemented in Rust.
>> >
>> > The framebuffer subsystem is obsolete and has been deprecated for a 
>> > decade. No new drivers accepted. Anything that really wants fbdev 
>> > already has a driver. Can we please let it die?
>> 
>> This, and the patchset is also obviously AI-generated.
>
> Hi,
> Thank you for the feedback.
> I’d like to be clear about how I used AI in this work:
>
> 1.Cover letter – Yes, I used AI to help summarize and phrase the cover letter.
> 2.Comments in the code – Some comments were written or refined with AI assistance.
> 3.Learning the codebase – When reading and understanding existing Rust-for-Linux code (including DRM and other abstractions), I used AI as a helper to analyze and explain structure and patterns.
> 4.Writing the code – The implementation was not fully generated by AI.  I wrote the code myself and used AI mainly to look up existing abstractions, traits, and APIs (e.g. “how does X work? ”, “what’s the right trait for Y?”)  while I was coding.
>
> So: AI was used for summaries, comments, learning, and looking things up;  the logic and structure of the code are mine, and I take responsibility for them.
> If you have concerns about specific parts (e.g. wording, style, or design), I’m happy to rework those patches or to adjust how I describe tool use in future submissions.

Appreciate the clarification. One piece of feedback if I may.

The cover letter is the first thing reviewers see of your patchset. If
it reads like impersonal, mechanically exhaustive generic AI slop full
of bullet points that doesn't follow kernel conventions, reviewers will
assume the rest of the patchset is of the same caliber and discard it as
something entirely generated by a bot.

A patch is not only the code. Comments and commit logs are as important
and should be given the same care. This patchset is a great illustration
of how AI completely misses the point: it will write 5 dreadful
paragraphs explaining *what* it did, but what reviewers want is one
sentence that explains *why*.

If your use of AI for the commit logs and comments is motivated by a
lack of confidence in your English, how about this: write them in your
native language and ask AI to translate it for you. That's something
LLMs actually shine at (that, and using them to learn about a codebase),
and the translated result will still carry the flow you intended, as
well as your own touch.

In other words, make sure that the AI assists you, as opposed to you
assisting the AI.

Hope this helps. Looking forward to your future submissions.

On 1/27/26 09:04, pengfuyuan wrote:
> On Mon, Jan 26, 2026 at 07:28:21PM +0900, Alexandre Courbot wrote:
>> On Mon Jan 26, 2026 at 7:01 PM JST, Thomas Zimmermann wrote:
>>> Hi
>>>
>>> Am 26.01.26 um 09:17 schrieb pengfuyuan:
>>>> This patch series adds Rust bindings and safe abstractions for the Linux
>>>> framebuffer subsystem, enabling framebuffer drivers to be implemented in Rust.
>>>
>>> The framebuffer subsystem is obsolete and has been deprecated for a
>>> decade. No new drivers accepted. Anything that really wants fbdev
>>> already has a driver. Can we please let it die?
>>
>> This, and the patchset is also obviously AI-generated.
> 
> Hi,
> Thank you for the feedback.
> I’d like to be clear about how I used AI in this work:
> 
> 1.Cover letter – Yes, I used AI to help summarize and phrase the cover letter.
> 2.Comments in the code – Some comments were written or refined with AI assistance.
> 3.Learning the codebase – When reading and understanding existing Rust-for-Linux code (including DRM and other abstractions), I used AI as a helper to analyze and explain structure and patterns.
> 4.Writing the code – The implementation was not fully generated by AI.  I wrote the code myself and used AI mainly to look up existing abstractions, traits, and APIs (e.g. “how does X work? ”, “what’s the right trait for Y?”)  while I was coding.
> 
> So: AI was used for summaries, comments, learning, and looking
> things up;  the logic and structure of the code are mine, and I take
> responsibility for them.
> If you have concerns about specific parts (e.g. wording, style, or
> design), I’m happy to rework those patches or to adjust how I
> describe tool use in future submissions.

No.
Please don't resend any patches for the fbdev layer.
There is no need to provide rust bindings for fbdev, as new
graphics drivers should use DRM.

Helge

On Tue, Jan 27, 2026 at 09:16:35AM +0100, Helge Deller wrote:
> On 1/27/26 09:04, pengfuyuan wrote:
> > On Mon, Jan 26, 2026 at 07:28:21PM +0900, Alexandre Courbot wrote:
> > > On Mon Jan 26, 2026 at 7:01 PM JST, Thomas Zimmermann wrote:
> > > > Hi
> > > > 
> > > > Am 26.01.26 um 09:17 schrieb pengfuyuan:
> > > > > This patch series adds Rust bindings and safe abstractions for the Linux
> > > > > framebuffer subsystem, enabling framebuffer drivers to be implemented in Rust.
> > > > 
> > > > The framebuffer subsystem is obsolete and has been deprecated for a
> > > > decade. No new drivers accepted. Anything that really wants fbdev
> > > > already has a driver. Can we please let it die?
> > > 
> > > This, and the patchset is also obviously AI-generated.
> > 
> > Hi,
> > Thank you for the feedback.
> > I’d like to be clear about how I used AI in this work:
> > 
> > 1.Cover letter – Yes, I used AI to help summarize and phrase the cover letter.
> > 2.Comments in the code – Some comments were written or refined with AI assistance.
> > 3.Learning the codebase – When reading and understanding existing Rust-for-Linux code (including DRM and other abstractions), I used AI as a helper to analyze and explain structure and patterns.
> > 4.Writing the code – The implementation was not fully generated by AI.  I wrote the code myself and used AI mainly to look up existing abstractions, traits, and APIs (e.g. “how does X work? ”, “what’s the right trait for Y?”)  while I was coding.
> > 
> > So: AI was used for summaries, comments, learning, and looking
> > things up;  the logic and structure of the code are mine, and I take
> > responsibility for them.
> > If you have concerns about specific parts (e.g. wording, style, or
> > design), I’m happy to rework those patches or to adjust how I
> > describe tool use in future submissions.
> 
> No.
> Please don't resend any patches for the fbdev layer.
> There is no need to provide rust bindings for fbdev, as new
> graphics drivers should use DRM.
> 
> Helge

Hi Helge,

Thank you for the clarification, I understand. I will not resend any fbdev
patches.

Just to give some background on why I started with Rust framebuffer bindings:
our company has a new graphics card, and the plan is to gradually implement
the display controller (DC) driver using the Rust-for-Linux DRM framework.
My goal is to bring up the display step by step on an ARM64 system with this
new GPU.

Since it looks like the current Rust DRM support does not yet include KMS
abstractions (CRTC/plane/connector etc.), my initial idea was to first use a
simple framebuffer-based approach to light up the display, and then later
migrate the DC driver to DRM and eventually to KMS abstractions in Rust.

Given your feedback, I will drop the fbdev approach and focus on DRM instead.

I would like to ask about the current status and plans for Rust DRM KMS
support:

- Is there any active work or a design for KMS abstractions in Rust?
- Is there a WIP tree or an RFC that I could look at?
- Are there specific areas where I could help (e.g. prototyping KMS bindings,
  writing tests, or working on smaller pieces under guidance)?

My goal is to eventually run the DC driver for this new GPU using the Rust
DRM stack on that ARM64 system, so I would be happy to help where it is most
useful for the project.

Thank you again for your time and guidance.

Best regards,
pengfuyuan

On 1/27/26 09:58, pengfuyuan wrote:
> On Tue, Jan 27, 2026 at 09:16:35AM +0100, Helge Deller wrote:
>> On 1/27/26 09:04, pengfuyuan wrote:
>>> On Mon, Jan 26, 2026 at 07:28:21PM +0900, Alexandre Courbot wrote:
>>>> On Mon Jan 26, 2026 at 7:01 PM JST, Thomas Zimmermann wrote:
>>>>> Hi
>>>>>
>>>>> Am 26.01.26 um 09:17 schrieb pengfuyuan:
>>>>>> This patch series adds Rust bindings and safe abstractions for the Linux
>>>>>> framebuffer subsystem, enabling framebuffer drivers to be implemented in Rust.
>>>>>
>>>>> The framebuffer subsystem is obsolete and has been deprecated for a
>>>>> decade. No new drivers accepted. Anything that really wants fbdev
>>>>> already has a driver. Can we please let it die?
>>>>
>>>> This, and the patchset is also obviously AI-generated.
>>>
>>> Hi,
>>> Thank you for the feedback.
>>> I’d like to be clear about how I used AI in this work:
>>>
>>> 1.Cover letter – Yes, I used AI to help summarize and phrase the cover letter.
>>> 2.Comments in the code – Some comments were written or refined with AI assistance.
>>> 3.Learning the codebase – When reading and understanding existing Rust-for-Linux code (including DRM and other abstractions), I used AI as a helper to analyze and explain structure and patterns.
>>> 4.Writing the code – The implementation was not fully generated by AI.  I wrote the code myself and used AI mainly to look up existing abstractions, traits, and APIs (e.g. “how does X work? ”, “what’s the right trait for Y?”)  while I was coding.
>>>
>>> So: AI was used for summaries, comments, learning, and looking
>>> things up;  the logic and structure of the code are mine, and I take
>>> responsibility for them.
>>> If you have concerns about specific parts (e.g. wording, style, or
>>> design), I’m happy to rework those patches or to adjust how I
>>> describe tool use in future submissions.
>>
>> No.
>> Please don't resend any patches for the fbdev layer.
>> There is no need to provide rust bindings for fbdev, as new
>> graphics drivers should use DRM.
>>
>> Helge
> 
> Hi Helge,
> 
> Thank you for the clarification, I understand. I will not resend any fbdev
> patches.
> 
> Just to give some background on why I started with Rust framebuffer bindings:
> our company has a new graphics card, and the plan is to gradually implement
> the display controller (DC) driver using the Rust-for-Linux DRM framework.
> My goal is to bring up the display step by step on an ARM64 system with this
> new GPU.
> 
> Since it looks like the current Rust DRM support does not yet include KMS
> abstractions (CRTC/plane/connector etc.), my initial idea was to first use a
> simple framebuffer-based approach to light up the display, and then later
> migrate the DC driver to DRM and eventually to KMS abstractions in Rust.
> 
> Given your feedback, I will drop the fbdev approach and focus on DRM instead.
> 
> I would like to ask about the current status and plans for Rust DRM KMS
> support:
> 
> - Is there any active work or a design for KMS abstractions in Rust?
> - Is there a WIP tree or an RFC that I could look at?
> - Are there specific areas where I could help (e.g. prototyping KMS bindings,
>    writing tests, or working on smaller pieces under guidance)?
> 
> My goal is to eventually run the DC driver for this new GPU using the Rust
> DRM stack on that ARM64 system, so I would be happy to help where it is most
> useful for the project.
> 
> Thank you again for your time and guidance.

Since you asked me directly, here is my very personal opinion:
Rust might be the best and most secure programming language on earth.
Nevertheless, *I* would write a standard DRM driver in C, based on
existing C APIs and drivers, as this seems to be the most fastest and
easiest way to get a functional driver that behaves as existing drivers.

I'm sure someone here on this list will provide you with
better answers to your Rust and DRM questions above.

Helge

On Tue, Jan 27, 2026 at 04:58:26PM +0800, pengfuyuan wrote:
> I would like to ask about the current status and plans for Rust DRM KMS
> support:
> 
> - Is there any active work or a design for KMS abstractions in Rust?

Very much so, look at the patches on the rust mailing list for them!

> - Is there a WIP tree or an RFC that I could look at?

Again, look at the list, there are loads of patches there.

> - Are there specific areas where I could help (e.g. prototyping KMS bindings,
>   writing tests, or working on smaller pieces under guidance)?

Build on the patches that have been submitted and work from there?

thanks,

greg k-h

On Mon, Jan 26, 2026 at 11:28 AM Alexandre Courbot <acourbot@nvidia.com> wrote:
>
> This, and the patchset is also obviously AI-generated.

pengfuyuan: the generated content guidelines I mentioned earlier this
month in another of your patches have been merged now, please read:

    https://docs.kernel.org/next/process/generated-content.html

Thanks!

Cheers,
Miguel

On Mon, Jan 26, 2026 at 12:46:41PM +0100, Miguel Ojeda wrote:
> On Mon, Jan 26, 2026 at 11:28 AM Alexandre Courbot <acourbot@nvidia.com> wrote:
> >
> > This, and the patchset is also obviously AI-generated.
> 
> pengfuyuan: the generated content guidelines I mentioned earlier this
> month in another of your patches have been merged now, please read:
> 
>     https://docs.kernel.org/next/process/generated-content.html
> 
> Thanks!
> 
> Cheers,
> Miguel

Hi Miguel,

Thank you for the pointer. I've read the generated content guidelines at
https://docs.kernel.org/next/process/generated-content.html and will follow
them.

For transparency, here is the disclosure for my contribution:

Tools used:
- Cursor (IDE) with Claude Sonnet 4.5

Parts affected by tool use:
- Cover letter: The cover letter text was summarized/written with AI assistance.
- Code comments: Comments in the code were written with AI assistance.
- Learning and development: I used AI to help analyze existing Rust for Linux
  framework code (e.g. rust/kernel/drm and similar abstractions) and to look
  up existing traits/abstractions while writing the code. The code itself was
  not fully AI-generated; I wrote it with AI used as an aid for querying
  existing abstractions and patterns.

Testing:
- I tested on a real ARM64 machine, manually swapping six different
  graphics cards to verify the changes.

I understand and can explain the code I submit, and I'm prepared to respond
to review comments.

Thanks,
pengfuyuan

On Mon, Jan 26, 2026 at 9:18 AM pengfuyuan <pengfuyuan@kylinos.cn> wrote:
>
>   rust: io: mem: add ioremap_wc support
>   rust: device: add platdata accessors

For future reference / others, these are essentially the same as:

    https://lore.kernel.org/rust-for-linux/tencent_63DD850B43CC086844717B73C574B8358F05@qq.com/
    https://lore.kernel.org/rust-for-linux/20260109080528.478731-2-pengfuyuan@kylinos.cn/

In general, please try to mention if a patch was already somewhere
else and add a changelog to understand if feedback was addressed.
Otherwise, others will have to do a manual comparison.

For instance, I may guess you sent this as a sample user due to what
Greg said back then. But that is just a guess, since you didn't reply
to the feedback nor mention it here.

Cheers,
Miguel