* Re: [PATCH v12 1/1] rust: interop: Add list module for C linked list interface
From: Miguel Ojeda @ 2026-03-12 19:16 UTC (permalink / raw)
To: Joel Fernandes
Cc: linux-kernel, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Alex Gaynor, Danilo Krummrich, Dave Airlie,
David Airlie, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Simona Vetter, Daniel Almeida, Koen Koning, Nikola Djukic,
Alexandre Courbot, Philipp Stanner, Elle Rhumsaa, 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, John Hubbard, Alistair Popple, Timur Tabi,
Edwin Peer, Andrea Righi, Andy Ritger, Zhi Wang, Balbir Singh,
alexeyi, Eliot Courtney, dri-devel, nouveau, rust-for-linux,
linux-doc, amd-gfx, intel-gfx, intel-xe, linux-fbdev
In-Reply-To: <20260306203648.1136554-2-joelagnelf@nvidia.com>
On Fri, Mar 6, 2026 at 9:37 PM Joel Fernandes <joelagnelf@nvidia.com> wrote:
>
> Acked-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Acked-by: Miguel Ojeda <ojeda@kernel.org>
> +//! # // SAFETY: head and all the items are test objects allocated in this scope.
`head`
> +//! // Rust wrapper for the C struct.
Empty newline comment between these:
//! //
Actually, should this be `//! ///`?
> +//! // The list item struct in this example is defined in C code as:
> +//! // struct SampleItemC {
> +//! // int value;
> +//! // struct list_head link;
> +//! // };
> +//! //
Let's try to use the usual style, i.e. no empty newline at the end of
docs for an item.
And the example should be in a proper code block with a C tag, so all
together something like:
//! /// Rust wrapper for the C struct.
//! ///
//! /// The list item struct in this example is defined in C code as:
//! ///
//! /// ```c
//! /// struct SampleItemC {
//! /// int value;
//! /// struct list_head link;
//! /// };
//! /// ```
> +//! // SAFETY: [`Item`] has same layout as [`SampleItemC`].
No need for intra-doc links in comments (for now at least).
> +//! // Create typed [`CList`] from sentinel head.
Empty newline comment.
> +//! // SAFETY: head is valid and initialized, items are `SampleItemC` with
`head`
However, this is giving me a Clippy issue (please see the other email).
> +/// `next`/`prev` pointers are valid and non-NULL.
We started using `NULL` recently as a convention for the null pointer.
> + // - [`CListHead`] has same layout as `list_head`.
Intra-doc link not needed.
> + // - `ptr` is valid and unmodified for 'a per caller guarantees.
`'a`
> + // SAFETY: self.as_raw() is valid per type invariants.
`self.as_raw()`
> +/// perform conversion of returned [`CListHead`] to an item (using `container_of` macro or similar).
Intra-doc link to `container_of`?
> + // - [`CList`] has same layout as [`CListHead`] due to repr(transparent).
Intra-doc link not needed.
> + // Convert to item using OFFSET.
`OFFSET`
Newline comment after this one.
> +/// Create a C doubly-circular linked list interface `CList` from a raw `list_head` pointer.
[`CList`]
> +/// pointing to a list that is not concurrently modified for the lifetime of the `CList`.
[`CList`]
> +/// Refer to the examples in this module's documentation.
Perhaps we could have an intra-doc link here to the module.
> + // Compile-time check that field path is a list_head.
`list_head`
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH v12 1/1] rust: interop: Add list module for C linked list interface
From: Miguel Ojeda @ 2026-03-12 19:20 UTC (permalink / raw)
To: Joel Fernandes
Cc: linux-kernel, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Alex Gaynor, Danilo Krummrich, Dave Airlie,
David Airlie, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Simona Vetter, Daniel Almeida, Koen Koning, Nikola Djukic,
Alexandre Courbot, Philipp Stanner, Elle Rhumsaa, 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, John Hubbard, Alistair Popple, Timur Tabi,
Edwin Peer, Andrea Righi, Andy Ritger, Zhi Wang, Balbir Singh,
alexeyi, Eliot Courtney, dri-devel, nouveau, rust-for-linux,
linux-doc, amd-gfx, intel-gfx, intel-xe, linux-fbdev
In-Reply-To: <20260306203648.1136554-2-joelagnelf@nvidia.com>
On Fri, Mar 6, 2026 at 9:37 PM Joel Fernandes <joelagnelf@nvidia.com> wrote:
>
> +//! // Create typed [`CList`] from sentinel head.
> +//! // SAFETY: head is valid and initialized, items are `SampleItemC` with
> +//! // embedded `link` field, and `Item` is `#[repr(transparent)]` over `SampleItemC`.
> +//! let list = clist_create!(unsafe { head, Item, SampleItemC, link });
Was the patch tested with Clippy? It has several issues.
The worst news is that it seems the "supposed to be `unsafe` block"
does not count as one for Clippy, i.e.:
let list = clist_create!(unsafe { head, Item, SampleItemC, link });
So we get:
error: statement has unnecessary safety comment
--> rust/doctests_kernel_generated.rs:7416:1
|
7416 | let list = clist_create!(unsafe { head, Item, SampleItemC, link });
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
help: consider removing the safety comment
--> rust/doctests_kernel_generated.rs:7414:4
|
7414 | // SAFETY: head is valid and initialized, items are
`SampleItemC` with
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
= help: for further information visit
https://rust-lang.github.io/rust-clippy/rust-1.94.0/index.html#unnecessary_safety_comment
= note: `-D clippy::unnecessary-safety-comment` implied by
`-D warnings`
= help: to override `-D warnings` add
`#[allow(clippy::unnecessary_safety_comment)]`
For this, we could write them as a `// SAFETY*: ` comment or similar,
to make progress for now, but it would best to request upstream Clippy
to detect this or to rework the macro to force the `unsafe` block
outside.
In addition:
error: unsafe block missing a safety comment
--> rust/kernel/interop/list.rs:357:17
|
112 | let _list = clist_create!(unsafe { head, Item,
SampleItemC, link });
|
--------------------------------------------------------- in this
macro invocation
...
357 | |p| unsafe { &raw const (*p).$($field).+ };
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= help: consider adding a safety comment on the preceding line
= help: for further information visit
https://rust-lang.github.io/rust-clippy/rust-1.94.0/index.html#undocumented_unsafe_blocks
= note: `-D clippy::undocumented-unsafe-blocks` implied by `-D warnings`
= help: to override `-D warnings` add
`#[allow(clippy::undocumented_unsafe_blocks)]`
= note: this error originates in the macro `clist_create` (in
Nightly builds, run with -Z macro-backtrace for more info)
So this needs a `// SAFETY:` comment on top of the closure.
error: this macro expands metavariables in an unsafe block
--> rust/kernel/interop/list.rs:362:9
|
362 | unsafe { $crate::interop::list::CList::<$rust_type,
OFFSET>::from_raw($head) }
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: this allows the user of the macro to write unsafe code
outside of an unsafe block
= help: consider expanding any metavariables outside of this
block, e.g. by storing them in a variable
= help: ... or also expand referenced metavariables in a safe
context to require an unsafe block at callsite
= help: for further information visit
https://rust-lang.github.io/rust-clippy/rust-1.94.0/index.html#macro_metavars_in_unsafe
= note: `-D clippy::macro-metavars-in-unsafe` implied by `-D warnings`
= help: to override `-D warnings` add
`#[allow(clippy::macro_metavars_in_unsafe)]`
For this one, to begin with, do we expect to have actual expressions
for `$head`, or could we constrain it for now to an identifier for
instance?
With an identifier there is no issue then -- the example currently has
just an identifier anyway.
I hope that helps.
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH v3] fbdev/hga: Request memory region before ioremap
From: Helge Deller @ 2026-03-12 19:47 UTC (permalink / raw)
To: Thomas Zimmermann, Hardik Phalet, Ferenc Bakonyi
Cc: Shuah Khan, Brigham Campbell, linux-nvidia, linux-fbdev,
dri-devel, linux-kernel
In-Reply-To: <afd8b00d-42fa-4eb7-b18e-302d3f7cadf7@suse.de>
On 3/12/26 16:10, Thomas Zimmermann wrote:
> Am 12.03.26 um 16:04 schrieb Hardik Phalet:
>> On Tue Mar 10, 2026 at 6:38 PM IST, Thomas Zimmermann wrote:
>>> Hi,
>>>
>>> thanks for the patch. Let's hope there are no conflicts with other
>>> hardware. IDK if anyone still uses this driver.
>> Hi Thomas,
>>
>> Thanks for reviewing this.
>>
>> Since I currently do not have access to the hardware needed to test the
>> change properly, I will drop this patch for now. I may revisit it once I
>> can validate the behavior on real hardware.
>
> Good luck. That's the Hercules framebuffer driver. Finding such
> ancient hardware that can run modern Linux is nigh impossible.
>
> But we can merge the patch. If it breaks anyone's setup, they will send a bug report.
>
> Helge will pick up the fix if he's ok with it.
No, I don't want to merge such patches any longer without any testing
on real hardware. There is no actual problem (else someone would have reported),
as such I don't see a benefit to apply it. Applying it just brings the risk
that we break it for someone.
So, NAK.
I believe I wrote about my opinion already in another patch?
I think we should rephrase that specific TODO item (which mentions the memory
region allocation) that only patches which have been tested are accepted.
Helge
^ permalink raw reply
* Re: [PATCH v12 1/1] rust: interop: Add list module for C linked list interface
From: Danilo Krummrich @ 2026-03-12 19:50 UTC (permalink / raw)
To: Miguel Ojeda, Joel Fernandes
Cc: linux-kernel, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Alex Gaynor, Dave Airlie, David Airlie,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Simona Vetter, Daniel Almeida, Koen Koning, Nikola Djukic,
Alexandre Courbot, Philipp Stanner, Elle Rhumsaa, 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, John Hubbard, Alistair Popple, Timur Tabi,
Edwin Peer, Andrea Righi, Andy Ritger, Zhi Wang, Balbir Singh,
alexeyi, Eliot Courtney, dri-devel, nouveau, rust-for-linux,
linux-doc, amd-gfx, intel-gfx, intel-xe, linux-fbdev
In-Reply-To: <CANiq72kEnDyUpnWMZmheJytjioeiJUK_C-yQJk77dPid89LExw@mail.gmail.com>
On Thu Mar 12, 2026 at 8:20 PM CET, Miguel Ojeda wrote:
> On Fri, Mar 6, 2026 at 9:37 PM Joel Fernandes <joelagnelf@nvidia.com> wrote:
>>
>> +//! // Create typed [`CList`] from sentinel head.
>> +//! // SAFETY: head is valid and initialized, items are `SampleItemC` with
>> +//! // embedded `link` field, and `Item` is `#[repr(transparent)]` over `SampleItemC`.
>> +//! let list = clist_create!(unsafe { head, Item, SampleItemC, link });
>
> Was the patch tested with Clippy? It has several issues.
I did not give it a shot yet, but given this and the other nits, this is beyond
what I want to fix up when applying the patch.
@Joel, can you please resend?
Thanks,
Danilo
^ permalink raw reply
* fbdev: update outdated help text for CONFIG_FB_NVIDIA
From: robgithub @ 2026-03-12 20:55 UTC (permalink / raw)
To: Helge Deller, Thomas Zimmermann, linux-fbdev
Cc: robgithub, Prasanna Kumar T S M, Wei Liu, Michael Kelley,
Sukrut Heroorkar, Randy Dunlap, Mukesh Rathor,
Uwe Kleine-König, dri-devel, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 254 bytes --]
The help text for CONFIG_FB_NVIDIA refers to obsolete hardware and
incorrect default behaviour. This patch updates the description to
reflect the current state of the driver and supported devices.
Signed-off-by: robgithub <rob.github@jumpstation.co.uk>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-fbdev-update-outdated-help-text-for-CONFIG_FB_NVIDIA.patch --]
[-- Type: text/x-patch, Size: 1403 bytes --]
From 688a061ba0db71fc2d5facd8344db7a4d5b1575a Mon Sep 17 00:00:00 2001
From: robgithub <rob.github@jumpstation.co.uk>
Date: Wed, 11 Mar 2026 22:14:43 +0000
Subject: [PATCH] fbdev: update outdated help text for CONFIG_FB_NVIDIA
The help text for CONFIG_FB_NVIDIA refers to obsolete hardware and
incorrect default behaviour. This patch updates the description to
reflect the current state of the driver and supported devices.
Signed-off-by: robgithub <rob.github@jumpstation.co.uk>
---
drivers/video/fbdev/Kconfig | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index ac9ac4287c6a..d8e331427443 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -668,10 +668,10 @@ config FB_NVIDIA
select BITREVERSE
select VGASTATE
help
- This driver supports graphics boards with the nVidia chips, TNT
- and newer. For very old chipsets, such as the RIVA128, then use
- the rivafb.
- Say Y if you have such a graphics board.
+ Supports NVIDIA GPUs from TNT through early GeForce generations
+ (NV4–NV2x: Twintor, Twintor2, Celsius, Kelvin).
+ Later architectures (Rankine and newer) are not reliably supported.
+ If unsure, say N.
To compile this driver as a module, choose M here: the
module will be called nvidiafb.
--
2.52.0
^ permalink raw reply related
* Re: fbdev: update outdated help text for CONFIG_FB_NVIDIA
From: Randy Dunlap @ 2026-03-12 21:02 UTC (permalink / raw)
To: robgithub, Helge Deller, Thomas Zimmermann, linux-fbdev
Cc: Prasanna Kumar T S M, Wei Liu, Michael Kelley, Sukrut Heroorkar,
Mukesh Rathor, Uwe Kleine-König, dri-devel, linux-kernel
In-Reply-To: <20260312205507.70b9013b@hexa5>
Hi,
On 3/12/26 1:55 PM, robgithub wrote:
> The help text for CONFIG_FB_NVIDIA refers to obsolete hardware and
> incorrect default behaviour. This patch updates the description to
> reflect the current state of the driver and supported devices.
>
> Signed-off-by: robgithub <rob.github@jumpstation.co.uk>
Inline patches are preferred over attachments.
I thought that Claws mail could send inline patches successfully. (?)
Documentation/process/email-clients.rst says that it works (after a little
configuration setting).
I don't know anything about which products are supported, so I have no
comment on that.
In the patch, the indentation is incorrect. Kconfig help text should be
indented with one tab + 2 spaces, not with 4 spaces.
thanks.
--
~Randy
^ permalink raw reply
* [PATCH] backlight: cgbc_bl: fix kernel-doc comment for struct cgbc_bl_data
From: John S @ 2026-03-12 21:42 UTC (permalink / raw)
To: lee, danielt, jingoohan1; +Cc: deller, dri-devel, linux-fbdev, linux-kernel
Add the required 'struct cgbc_bl_data -' prefix to the kernel-doc
comment so it is properly recognized as struct documentation.
This fixes the following warning:
drivers/video/backlight/cgbc_bl.c:29: This comment starts with
'/**', but isn't a kernel-doc comment
Signed-off-by: Kit Dallege <xaum.io@gmail.com>
---
drivers/video/backlight/cgbc_bl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/backlight/cgbc_bl.c
b/drivers/video/backlight/cgbc_bl.c
index 9212c498e6e3..0964205ef1ab 100644
--- a/drivers/video/backlight/cgbc_bl.c
+++ b/drivers/video/backlight/cgbc_bl.c
@@ -26,7 +26,7 @@
#define CGBC_BL_MAX_BRIGHTNESS 100
/**
- * CGBC backlight driver data
+ * struct cgbc_bl_data - CGBC backlight driver data
* @dev: Pointer to the platform device
* @cgbc: Pointer to the parent CGBC device data
* @current_brightness: Current brightness level (0-100)
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v9 04/23] gpu: nova-core: gsp: Extract usable FB region from GSP
From: Eliot Courtney @ 2026-03-13 6:58 UTC (permalink / raw)
To: Joel Fernandes, linux-kernel
Cc: Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Dave Airlie, Daniel Almeida, Koen Koning,
dri-devel, nouveau, rust-for-linux, Nikola Djukic,
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, Alex Gaynor,
Boqun Feng, John Hubbard, Alistair Popple, Timur Tabi, Edwin Peer,
Alexandre Courbot, Andrea Righi, Andy Ritger, Zhi Wang,
Balbir Singh, Philipp Stanner, Elle Rhumsaa, alexeyi,
Eliot Courtney, joel, linux-doc, amd-gfx, intel-gfx, intel-xe,
linux-fbdev, dri-devel
In-Reply-To: <20260311004008.2208806-5-joelagnelf@nvidia.com>
On Wed Mar 11, 2026 at 9:39 AM JST, Joel Fernandes wrote:
> Add first_usable_fb_region() to GspStaticConfigInfo to extract the first
> usable FB region from GSP's fbRegionInfoParams. Usable regions are those
> that are not reserved or protected.
>
> The extracted region is stored in GetGspStaticInfoReply and exposed via
> usable_fb_region() API for use by the memory subsystem.
>
> Cc: Nikola Djukic <ndjukic@nvidia.com>
> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
> ---
> drivers/gpu/nova-core/gsp/commands.rs | 11 ++++++--
> drivers/gpu/nova-core/gsp/fw/commands.rs | 32 ++++++++++++++++++++++++
> 2 files changed, 41 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/nova-core/gsp/commands.rs b/drivers/gpu/nova-core/gsp/commands.rs
> index 8f270eca33be..8d5780d9cace 100644
> --- a/drivers/gpu/nova-core/gsp/commands.rs
> +++ b/drivers/gpu/nova-core/gsp/commands.rs
> @@ -4,6 +4,7 @@
> array,
> convert::Infallible,
> ffi::FromBytesUntilNulError,
> + ops::Range,
> str::Utf8Error, //
> };
>
> @@ -186,22 +187,28 @@ fn init(&self) -> impl Init<Self::Command, Self::InitError> {
> }
> }
>
> -/// The reply from the GSP to the [`GetGspInfo`] command.
> +/// The reply from the GSP to the [`GetGspStaticInfo`] command.
> pub(crate) struct GetGspStaticInfoReply {
> gpu_name: [u8; 64],
> + /// Usable FB (VRAM) region for driver memory allocation.
> + #[expect(dead_code)]
> + pub(crate) usable_fb_region: Range<u64>,
> }
>
> impl MessageFromGsp for GetGspStaticInfoReply {
> const FUNCTION: MsgFunction = MsgFunction::GetGspStaticInfo;
> type Message = GspStaticConfigInfo;
> - type InitError = Infallible;
> + type InitError = Error;
>
> fn read(
> msg: &Self::Message,
> _sbuffer: &mut SBufferIter<array::IntoIter<&[u8], 2>>,
> ) -> Result<Self, Self::InitError> {
> + let (base, size) = msg.first_usable_fb_region().ok_or(ENODEV)?;
> +
> Ok(GetGspStaticInfoReply {
> gpu_name: msg.gpu_name_str(),
> + usable_fb_region: base..base.saturating_add(size),
We already return a Result here, so why not use checked_add?:
`base..base.checked_add(size).ok_or(EOVERFLOW)?`
> })
> }
> }
> diff --git a/drivers/gpu/nova-core/gsp/fw/commands.rs b/drivers/gpu/nova-core/gsp/fw/commands.rs
> index 67f44421fcc3..cef86cab8a12 100644
> --- a/drivers/gpu/nova-core/gsp/fw/commands.rs
> +++ b/drivers/gpu/nova-core/gsp/fw/commands.rs
> @@ -5,6 +5,7 @@
> use kernel::{device, pci};
>
> use crate::gsp::GSP_PAGE_SIZE;
> +use crate::num::IntoSafeCast;
>
> use super::bindings;
>
> @@ -115,6 +116,37 @@ impl GspStaticConfigInfo {
> pub(crate) fn gpu_name_str(&self) -> [u8; 64] {
> self.0.gpuNameString
> }
> +
> + /// Extract the first usable FB region from GSP firmware data.
> + ///
> + /// Returns the first region suitable for driver memory allocation as a `(base, size)` tuple.
> + /// Usable regions are those that:
> + /// - Are not reserved for firmware internal use.
> + /// - Are not protected (hardware-enforced access restrictions).
> + /// - Support compression (can use GPU memory compression for bandwidth).
> + /// - Support ISO (isochronous memory for display requiring guaranteed bandwidth).
Are the above conditions all required (AND) or any required (OR)?
Might be worth clarifying in the doc.
> + pub(crate) fn first_usable_fb_region(&self) -> Option<(u64, u64)> {
> + let fb_info = &self.0.fbRegionInfoParams;
> + for i in 0..fb_info.numFBRegions.into_safe_cast() {
> + if let Some(reg) = fb_info.fbRegion.get(i) {
> + // Skip malformed regions where limit < base.
Is it normal that it returns a bunch of broken regions?
> + if reg.limit < reg.base {
> + continue;
> + }
> +
> + // Filter: not reserved, not protected, supports compression and ISO.
> + if reg.reserved == 0
> + && reg.bProtected == 0
> + && reg.supportCompressed != 0
> + && reg.supportISO != 0
> + {
> + let size = reg.limit - reg.base + 1;
> + return Some((reg.base, size));
This is identifying a range, so how about returning Option<Range<u64>>
instead? It gets immediately converted into a range anyway.
> + }
> + }
> + }
> + None
> + }
> }
>
> // SAFETY: Padding is explicit and will not contain uninitialized data.
^ permalink raw reply
* Re: [PATCH v3] fbdev/hga: Request memory region before ioremap
From: Thomas Zimmermann @ 2026-03-13 8:05 UTC (permalink / raw)
To: Helge Deller, Hardik Phalet, Ferenc Bakonyi
Cc: Shuah Khan, Brigham Campbell, linux-nvidia, linux-fbdev,
dri-devel, linux-kernel
In-Reply-To: <100ea3bc-d7a2-45c5-982f-5dc5fd27163b@gmx.de>
Hi
Am 12.03.26 um 20:47 schrieb Helge Deller:
> On 3/12/26 16:10, Thomas Zimmermann wrote:
>> Am 12.03.26 um 16:04 schrieb Hardik Phalet:
>>> On Tue Mar 10, 2026 at 6:38 PM IST, Thomas Zimmermann wrote:
>>>> Hi,
>>>>
>>>> thanks for the patch. Let's hope there are no conflicts with other
>>>> hardware. IDK if anyone still uses this driver.
>>> Hi Thomas,
>>>
>>> Thanks for reviewing this.
>>>
>>> Since I currently do not have access to the hardware needed to test the
>>> change properly, I will drop this patch for now. I may revisit it
>>> once I
>>> can validate the behavior on real hardware.
>>
>> Good luck. That's the Hercules framebuffer driver. Finding such
>> ancient hardware that can run modern Linux is nigh impossible.
>>
>> But we can merge the patch. If it breaks anyone's setup, they will
>> send a bug report.
>>
>> Helge will pick up the fix if he's ok with it.
>
> No, I don't want to merge such patches any longer without any testing
> on real hardware. There is no actual problem (else someone would have
> reported),
> as such I don't see a benefit to apply it. Applying it just brings the
> risk
> that we break it for someone.
> So, NAK.
>
> I believe I wrote about my opinion already in another patch?
Sorry, I wasn't aware.
> I think we should rephrase that specific TODO item (which mentions the
> memory
> region allocation) that only patches which have been tested are accepted.
There will likely no one show up here for testing unless it breaks there
system. Which you won't know until you merge the patch.
If only pre-tested patches can go in, we should make a serious effort to
remove drivers from fbdev. Because otherwise the driver code just sits
around as liability.
Aggressively moving fbdev drivers into staging would be a good start IMHO.
Best regards
Thomas
>
> Helge
--
--
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)
^ permalink raw reply
* Re: [PATCH v3] fbdev/hga: Request memory region before ioremap
From: Helge Deller @ 2026-03-13 12:50 UTC (permalink / raw)
To: Thomas Zimmermann, Hardik Phalet, Ferenc Bakonyi
Cc: Shuah Khan, Brigham Campbell, linux-nvidia, linux-fbdev,
dri-devel, linux-kernel
In-Reply-To: <4f06f63c-7ab6-42b7-9789-13c929c64db3@suse.de>
Hi Thomas,
On 3/13/26 09:05, Thomas Zimmermann wrote:
> Am 12.03.26 um 20:47 schrieb Helge Deller:
>> On 3/12/26 16:10, Thomas Zimmermann wrote:
>>> Am 12.03.26 um 16:04 schrieb Hardik Phalet:
>>>> On Tue Mar 10, 2026 at 6:38 PM IST, Thomas Zimmermann wrote:
>>>>> Hi,
>>>>>
>>>>> thanks for the patch. Let's hope there are no conflicts with other
>>>>> hardware. IDK if anyone still uses this driver.
>>>> Hi Thomas,
>>>>
>>>> Thanks for reviewing this.
>>>>
>>>> Since I currently do not have access to the hardware needed to test the
>>>> change properly, I will drop this patch for now. I may revisit it once I
>>>> can validate the behavior on real hardware.
>>>
>>> Good luck. That's the Hercules framebuffer driver. Finding such
>>> ancient hardware that can run modern Linux is nigh impossible.
>>>
>>> But we can merge the patch. If it breaks anyone's setup, they will send a bug report.
>>>
>>> Helge will pick up the fix if he's ok with it.
>>
>> No, I don't want to merge such patches any longer without any testing
>> on real hardware. There is no actual problem (else someone would have reported),
>> as such I don't see a benefit to apply it. Applying it just brings the risk
>> that we break it for someone.
>> So, NAK.
>>
>> I believe I wrote about my opinion already in another patch?
>
> Sorry, I wasn't aware.
>
>> I think we should rephrase that specific TODO item (which mentions the memory
>> region allocation) that only patches which have been tested are accepted.
>
> There will likely no one show up here for testing unless it breaks
> there system. Which you won't know until you merge the patch.
No-one likes to merge unnecessary patches which highly potentially
introduce malfunctioning and haven't been tested at all.
> If only pre-tested patches can go in,
You misunderstand.
I'm still happy to take *any* patches for fbdev.
Even untested ones if they
a) seem necessary (e.g. bugfix), or
b) seem beneficial (code cleanup)
as long as they don't break the driver. This patch may break the driver.
Helge
^ permalink raw reply
* Re: [PATCH] staging: sm750fb: fix static const char * warning
From: kernel test robot @ 2026-03-13 14:47 UTC (permalink / raw)
To: sluisr, sudipm.mukherjee, teddy.wang
Cc: oe-kbuild-all, gregkh, linux-fbdev, linux-staging, linux-kernel,
sluisr
In-Reply-To: <20260309002809.15746-1-contact@sluisr.com>
Hi sluisr,
kernel test robot noticed the following build errors:
[auto build test ERROR on staging/staging-testing]
url: https://github.com/intel-lab-lkp/linux/commits/sluisr/staging-sm750fb-fix-static-const-char-warning/20260309-082839
base: staging/staging-testing
patch link: https://lore.kernel.org/r/20260309002809.15746-1-contact%40sluisr.com
patch subject: [PATCH] staging: sm750fb: fix static const char * warning
config: x86_64-randconfig-001-20250530 (https://download.01.org/0day-ci/archive/20260313/202603132236.wia7pRpY-lkp@intel.com/config)
compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260313/202603132236.wia7pRpY-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202603132236.wia7pRpY-lkp@intel.com/
All errors (new ones prefixed by >>):
drivers/staging/sm750fb/sm750.c: In function 'lynxfb_set_fbinfo':
>> drivers/staging/sm750fb/sm750.c:782:33: error: assignment of read-only location 'g_fbmode[index]'
782 | g_fbmode[index] = g_def_fbmode;
| ^
drivers/staging/sm750fb/sm750.c:784:41: error: assignment of read-only location 'g_fbmode[index]'
784 | g_fbmode[index] = g_fbmode[0];
| ^
drivers/staging/sm750fb/sm750.c: In function 'sm750fb_setup':
>> drivers/staging/sm750fb/sm750.c:893:45: error: assignment of read-only location 'g_fbmode[0]'
893 | g_fbmode[0] = opt;
| ^
drivers/staging/sm750fb/sm750.c:897:45: error: assignment of read-only location 'g_fbmode[1]'
897 | g_fbmode[1] = opt;
| ^
vim +782 drivers/staging/sm750fb/sm750.c
81dee67e215b23 Sudip Mukherjee 2015-03-03 716
81dee67e215b23 Sudip Mukherjee 2015-03-03 717 static int lynxfb_set_fbinfo(struct fb_info *info, int index)
81dee67e215b23 Sudip Mukherjee 2015-03-03 718 {
81dee67e215b23 Sudip Mukherjee 2015-03-03 719 int i;
81dee67e215b23 Sudip Mukherjee 2015-03-03 720 struct lynxfb_par *par;
e359b6a863e19f Mike Rapoport 2015-10-26 721 struct sm750_dev *sm750_dev;
81dee67e215b23 Sudip Mukherjee 2015-03-03 722 struct lynxfb_crtc *crtc;
81dee67e215b23 Sudip Mukherjee 2015-03-03 723 struct lynxfb_output *output;
81dee67e215b23 Sudip Mukherjee 2015-03-03 724 struct fb_var_screeninfo *var;
81dee67e215b23 Sudip Mukherjee 2015-03-03 725 struct fb_fix_screeninfo *fix;
81dee67e215b23 Sudip Mukherjee 2015-03-03 726
81dee67e215b23 Sudip Mukherjee 2015-03-03 727 const struct fb_videomode *pdb[] = {
81dee67e215b23 Sudip Mukherjee 2015-03-03 728 lynx750_ext, NULL, vesa_modes,
81dee67e215b23 Sudip Mukherjee 2015-03-03 729 };
81dee67e215b23 Sudip Mukherjee 2015-03-03 730 int cdb[] = {ARRAY_SIZE(lynx750_ext), 0, VESA_MODEDB_SIZE};
8c475735085a7d Tim Wassink 2025-12-21 731 static const char *fix_id[2] = {
81dee67e215b23 Sudip Mukherjee 2015-03-03 732 "sm750_fb1", "sm750_fb2",
81dee67e215b23 Sudip Mukherjee 2015-03-03 733 };
81dee67e215b23 Sudip Mukherjee 2015-03-03 734
81dee67e215b23 Sudip Mukherjee 2015-03-03 735 int ret, line_length;
81dee67e215b23 Sudip Mukherjee 2015-03-03 736
81dee67e215b23 Sudip Mukherjee 2015-03-03 737 ret = 0;
81dee67e215b23 Sudip Mukherjee 2015-03-03 738 par = (struct lynxfb_par *)info->par;
e359b6a863e19f Mike Rapoport 2015-10-26 739 sm750_dev = par->dev;
81dee67e215b23 Sudip Mukherjee 2015-03-03 740 crtc = &par->crtc;
81dee67e215b23 Sudip Mukherjee 2015-03-03 741 output = &par->output;
81dee67e215b23 Sudip Mukherjee 2015-03-03 742 var = &info->var;
81dee67e215b23 Sudip Mukherjee 2015-03-03 743 fix = &info->fix;
81dee67e215b23 Sudip Mukherjee 2015-03-03 744
81dee67e215b23 Sudip Mukherjee 2015-03-03 745 /* set index */
81dee67e215b23 Sudip Mukherjee 2015-03-03 746 par->index = index;
81dee67e215b23 Sudip Mukherjee 2015-03-03 747 output->channel = &crtc->channel;
81dee67e215b23 Sudip Mukherjee 2015-03-03 748 sm750fb_set_drv(par);
81dee67e215b23 Sudip Mukherjee 2015-03-03 749
d11ac7cbcc266c Sudip Mukherjee 2015-08-07 750 /*
d11ac7cbcc266c Sudip Mukherjee 2015-08-07 751 * set current cursor variable and proc pointer,
d11ac7cbcc266c Sudip Mukherjee 2015-08-07 752 * must be set after crtc member initialized
d11ac7cbcc266c Sudip Mukherjee 2015-08-07 753 */
fdc234d85210d9 Benjamin Philip 2021-07-28 754 crtc->cursor.offset = crtc->o_screen + crtc->vidmem_size - 1024;
e359b6a863e19f Mike Rapoport 2015-10-26 755 crtc->cursor.mmio = sm750_dev->pvReg +
e359b6a863e19f Mike Rapoport 2015-10-26 756 0x800f0 + (int)crtc->channel * 0x140;
81dee67e215b23 Sudip Mukherjee 2015-03-03 757
cd33da26036ea5 Christopher Carbone 2022-08-23 758 crtc->cursor.max_h = 64;
cd33da26036ea5 Christopher Carbone 2022-08-23 759 crtc->cursor.max_w = 64;
39f9137268ee3d Benjamin Philip 2021-07-26 760 crtc->cursor.size = crtc->cursor.max_h * crtc->cursor.max_w * 2 / 8;
e359b6a863e19f Mike Rapoport 2015-10-26 761 crtc->cursor.vstart = sm750_dev->pvMem + crtc->cursor.offset;
81dee67e215b23 Sudip Mukherjee 2015-03-03 762
3de08a2d14ff8c Lorenzo Stoakes 2015-03-20 763 memset_io(crtc->cursor.vstart, 0, crtc->cursor.size);
f7c8a046577e09 Thomas Zimmermann 2023-11-27 764 if (!g_hwcursor)
52d0744d751d8f Arnd Bergmann 2016-11-09 765 sm750_hw_cursor_disable(&crtc->cursor);
81dee67e215b23 Sudip Mukherjee 2015-03-03 766
81dee67e215b23 Sudip Mukherjee 2015-03-03 767 /* set info->fbops, must be set before fb_find_mode */
e359b6a863e19f Mike Rapoport 2015-10-26 768 if (!sm750_dev->accel_off) {
81dee67e215b23 Sudip Mukherjee 2015-03-03 769 /* use 2d acceleration */
f7c8a046577e09 Thomas Zimmermann 2023-11-27 770 if (!g_hwcursor)
f7c8a046577e09 Thomas Zimmermann 2023-11-27 771 info->fbops = &lynxfb_ops_accel;
f7c8a046577e09 Thomas Zimmermann 2023-11-27 772 else
f7c8a046577e09 Thomas Zimmermann 2023-11-27 773 info->fbops = &lynxfb_ops_accel_with_cursor;
f7c8a046577e09 Thomas Zimmermann 2023-11-27 774 } else {
f7c8a046577e09 Thomas Zimmermann 2023-11-27 775 if (!g_hwcursor)
81dee67e215b23 Sudip Mukherjee 2015-03-03 776 info->fbops = &lynxfb_ops;
f7c8a046577e09 Thomas Zimmermann 2023-11-27 777 else
f7c8a046577e09 Thomas Zimmermann 2023-11-27 778 info->fbops = &lynxfb_ops_with_cursor;
f7c8a046577e09 Thomas Zimmermann 2023-11-27 779 }
81dee67e215b23 Sudip Mukherjee 2015-03-03 780
81dee67e215b23 Sudip Mukherjee 2015-03-03 781 if (!g_fbmode[index]) {
81dee67e215b23 Sudip Mukherjee 2015-03-03 @782 g_fbmode[index] = g_def_fbmode;
81dee67e215b23 Sudip Mukherjee 2015-03-03 783 if (index)
81dee67e215b23 Sudip Mukherjee 2015-03-03 784 g_fbmode[index] = g_fbmode[0];
81dee67e215b23 Sudip Mukherjee 2015-03-03 785 }
81dee67e215b23 Sudip Mukherjee 2015-03-03 786
81dee67e215b23 Sudip Mukherjee 2015-03-03 787 for (i = 0; i < 3; i++) {
81dee67e215b23 Sudip Mukherjee 2015-03-03 788 ret = fb_find_mode(var, info, g_fbmode[index],
81dee67e215b23 Sudip Mukherjee 2015-03-03 789 pdb[i], cdb[i], NULL, 8);
81dee67e215b23 Sudip Mukherjee 2015-03-03 790
db7fb3588ab492 Artem Lytkin 2026-02-23 791 if (ret == 1 || ret == 2)
81dee67e215b23 Sudip Mukherjee 2015-03-03 792 break;
81dee67e215b23 Sudip Mukherjee 2015-03-03 793 }
81dee67e215b23 Sudip Mukherjee 2015-03-03 794
81dee67e215b23 Sudip Mukherjee 2015-03-03 795 /* set par */
81dee67e215b23 Sudip Mukherjee 2015-03-03 796 par->info = info;
81dee67e215b23 Sudip Mukherjee 2015-03-03 797
81dee67e215b23 Sudip Mukherjee 2015-03-03 798 /* set info */
e3a3f9f5123683 Mike Rapoport 2015-10-26 799 line_length = ALIGN((var->xres_virtual * var->bits_per_pixel / 8),
e3a3f9f5123683 Mike Rapoport 2015-10-26 800 crtc->line_pad);
81dee67e215b23 Sudip Mukherjee 2015-03-03 801
81dee67e215b23 Sudip Mukherjee 2015-03-03 802 info->pseudo_palette = &par->pseudo_palette[0];
cc59bde1c920ab Benjamin Philip 2021-07-28 803 info->screen_base = crtc->v_screen;
81dee67e215b23 Sudip Mukherjee 2015-03-03 804 info->screen_size = line_length * var->yres_virtual;
81dee67e215b23 Sudip Mukherjee 2015-03-03 805
81dee67e215b23 Sudip Mukherjee 2015-03-03 806 /* set info->fix */
81dee67e215b23 Sudip Mukherjee 2015-03-03 807 fix->type = FB_TYPE_PACKED_PIXELS;
81dee67e215b23 Sudip Mukherjee 2015-03-03 808 fix->type_aux = 0;
81dee67e215b23 Sudip Mukherjee 2015-03-03 809 fix->xpanstep = crtc->xpanstep;
81dee67e215b23 Sudip Mukherjee 2015-03-03 810 fix->ypanstep = crtc->ypanstep;
81dee67e215b23 Sudip Mukherjee 2015-03-03 811 fix->ywrapstep = crtc->ywrapstep;
81dee67e215b23 Sudip Mukherjee 2015-03-03 812 fix->accel = FB_ACCEL_SMI;
81dee67e215b23 Sudip Mukherjee 2015-03-03 813
8c475735085a7d Tim Wassink 2025-12-21 814 strscpy(fix->id, fix_id[index], sizeof(fix->id));
81dee67e215b23 Sudip Mukherjee 2015-03-03 815
fdc234d85210d9 Benjamin Philip 2021-07-28 816 fix->smem_start = crtc->o_screen + sm750_dev->vidmem_start;
d11ac7cbcc266c Sudip Mukherjee 2015-08-07 817 /*
d11ac7cbcc266c Sudip Mukherjee 2015-08-07 818 * according to mmap experiment from user space application,
81dee67e215b23 Sudip Mukherjee 2015-03-03 819 * fix->mmio_len should not larger than virtual size
81dee67e215b23 Sudip Mukherjee 2015-03-03 820 * (xres_virtual x yres_virtual x ByPP)
81dee67e215b23 Sudip Mukherjee 2015-03-03 821 * Below line maybe buggy when user mmap fb dev node and write
81dee67e215b23 Sudip Mukherjee 2015-03-03 822 * data into the bound over virtual size
d11ac7cbcc266c Sudip Mukherjee 2015-08-07 823 */
81dee67e215b23 Sudip Mukherjee 2015-03-03 824 fix->smem_len = crtc->vidmem_size;
81dee67e215b23 Sudip Mukherjee 2015-03-03 825 info->screen_size = fix->smem_len;
81dee67e215b23 Sudip Mukherjee 2015-03-03 826 fix->line_length = line_length;
e359b6a863e19f Mike Rapoport 2015-10-26 827 fix->mmio_start = sm750_dev->vidreg_start;
e359b6a863e19f Mike Rapoport 2015-10-26 828 fix->mmio_len = sm750_dev->vidreg_size;
b610e1193a917f Matej Dujava 2020-04-30 829
b610e1193a917f Matej Dujava 2020-04-30 830 lynxfb_set_visual_mode(info);
81dee67e215b23 Sudip Mukherjee 2015-03-03 831
81dee67e215b23 Sudip Mukherjee 2015-03-03 832 /* set var */
81dee67e215b23 Sudip Mukherjee 2015-03-03 833 var->activate = FB_ACTIVATE_NOW;
81dee67e215b23 Sudip Mukherjee 2015-03-03 834 var->accel_flags = 0;
81dee67e215b23 Sudip Mukherjee 2015-03-03 835 var->vmode = FB_VMODE_NONINTERLACED;
81dee67e215b23 Sudip Mukherjee 2015-03-03 836
61c507cf652da1 Michel von Czettritz 2015-03-26 837 ret = fb_alloc_cmap(&info->cmap, 256, 0);
61c507cf652da1 Michel von Czettritz 2015-03-26 838 if (ret < 0) {
fbab250eb51d6d Artem Lytkin 2026-02-07 839 dev_err(info->device, "Could not allocate memory for cmap.\n");
81dee67e215b23 Sudip Mukherjee 2015-03-03 840 goto exit;
81dee67e215b23 Sudip Mukherjee 2015-03-03 841 }
81dee67e215b23 Sudip Mukherjee 2015-03-03 842
81dee67e215b23 Sudip Mukherjee 2015-03-03 843 exit:
81dee67e215b23 Sudip Mukherjee 2015-03-03 844 lynxfb_ops_check_var(var, info);
81dee67e215b23 Sudip Mukherjee 2015-03-03 845 return ret;
81dee67e215b23 Sudip Mukherjee 2015-03-03 846 }
81dee67e215b23 Sudip Mukherjee 2015-03-03 847
81dee67e215b23 Sudip Mukherjee 2015-03-03 848 /* chip specific g_option configuration routine */
700591a9adc8b1 Mike Rapoport 2015-10-26 849 static void sm750fb_setup(struct sm750_dev *sm750_dev, char *src)
81dee67e215b23 Sudip Mukherjee 2015-03-03 850 {
81dee67e215b23 Sudip Mukherjee 2015-03-03 851 char *opt;
81dee67e215b23 Sudip Mukherjee 2015-03-03 852 int swap;
81dee67e215b23 Sudip Mukherjee 2015-03-03 853
81dee67e215b23 Sudip Mukherjee 2015-03-03 854 swap = 0;
81dee67e215b23 Sudip Mukherjee 2015-03-03 855
cc34db609ff98c Madhumitha Sundar 2026-01-27 856 sm750_dev->init_parm.chip_clk = 0;
cc34db609ff98c Madhumitha Sundar 2026-01-27 857 sm750_dev->init_parm.mem_clk = 0;
cc34db609ff98c Madhumitha Sundar 2026-01-27 858 sm750_dev->init_parm.master_clk = 0;
cc34db609ff98c Madhumitha Sundar 2026-01-27 859 sm750_dev->init_parm.powerMode = 0;
cc34db609ff98c Madhumitha Sundar 2026-01-27 860 sm750_dev->init_parm.setAllEngOff = 0;
cc34db609ff98c Madhumitha Sundar 2026-01-27 861 sm750_dev->init_parm.resetMemory = 1;
81dee67e215b23 Sudip Mukherjee 2015-03-03 862
81dee67e215b23 Sudip Mukherjee 2015-03-03 863 /* defaultly turn g_hwcursor on for both view */
81dee67e215b23 Sudip Mukherjee 2015-03-03 864 g_hwcursor = 3;
81dee67e215b23 Sudip Mukherjee 2015-03-03 865
81dee67e215b23 Sudip Mukherjee 2015-03-03 866 if (!src || !*src) {
c56de0967a658c Elise Lennion 2016-10-31 867 dev_warn(&sm750_dev->pdev->dev, "no specific g_option.\n");
81dee67e215b23 Sudip Mukherjee 2015-03-03 868 goto NO_PARAM;
81dee67e215b23 Sudip Mukherjee 2015-03-03 869 }
81dee67e215b23 Sudip Mukherjee 2015-03-03 870
0fa96e39279988 Sudip Mukherjee 2015-03-10 871 while ((opt = strsep(&src, ":")) != NULL && *opt != 0) {
c56de0967a658c Elise Lennion 2016-10-31 872 dev_info(&sm750_dev->pdev->dev, "opt=%s\n", opt);
c56de0967a658c Elise Lennion 2016-10-31 873 dev_info(&sm750_dev->pdev->dev, "src=%s\n", src);
81dee67e215b23 Sudip Mukherjee 2015-03-03 874
144634a6b42146 Katie Dunne 2017-02-19 875 if (!strncmp(opt, "swap", strlen("swap"))) {
81dee67e215b23 Sudip Mukherjee 2015-03-03 876 swap = 1;
144634a6b42146 Katie Dunne 2017-02-19 877 } else if (!strncmp(opt, "nocrt", strlen("nocrt"))) {
1757d106a9ce8c Mike Rapoport 2015-10-26 878 sm750_dev->nocrt = 1;
144634a6b42146 Katie Dunne 2017-02-19 879 } else if (!strncmp(opt, "36bit", strlen("36bit"))) {
1757d106a9ce8c Mike Rapoport 2015-10-26 880 sm750_dev->pnltype = sm750_doubleTFT;
144634a6b42146 Katie Dunne 2017-02-19 881 } else if (!strncmp(opt, "18bit", strlen("18bit"))) {
1757d106a9ce8c Mike Rapoport 2015-10-26 882 sm750_dev->pnltype = sm750_dualTFT;
144634a6b42146 Katie Dunne 2017-02-19 883 } else if (!strncmp(opt, "24bit", strlen("24bit"))) {
1757d106a9ce8c Mike Rapoport 2015-10-26 884 sm750_dev->pnltype = sm750_24TFT;
144634a6b42146 Katie Dunne 2017-02-19 885 } else if (!strncmp(opt, "nohwc0", strlen("nohwc0"))) {
81dee67e215b23 Sudip Mukherjee 2015-03-03 886 g_hwcursor &= ~0x1;
144634a6b42146 Katie Dunne 2017-02-19 887 } else if (!strncmp(opt, "nohwc1", strlen("nohwc1"))) {
81dee67e215b23 Sudip Mukherjee 2015-03-03 888 g_hwcursor &= ~0x2;
144634a6b42146 Katie Dunne 2017-02-19 889 } else if (!strncmp(opt, "nohwc", strlen("nohwc"))) {
81dee67e215b23 Sudip Mukherjee 2015-03-03 890 g_hwcursor = 0;
144634a6b42146 Katie Dunne 2017-02-19 891 } else {
81dee67e215b23 Sudip Mukherjee 2015-03-03 892 if (!g_fbmode[0]) {
81dee67e215b23 Sudip Mukherjee 2015-03-03 @893 g_fbmode[0] = opt;
cee9ba1c30d051 Abdul Rauf 2017-01-08 894 dev_info(&sm750_dev->pdev->dev,
cee9ba1c30d051 Abdul Rauf 2017-01-08 895 "find fbmode0 : %s\n", g_fbmode[0]);
81dee67e215b23 Sudip Mukherjee 2015-03-03 896 } else if (!g_fbmode[1]) {
81dee67e215b23 Sudip Mukherjee 2015-03-03 897 g_fbmode[1] = opt;
cee9ba1c30d051 Abdul Rauf 2017-01-08 898 dev_info(&sm750_dev->pdev->dev,
cee9ba1c30d051 Abdul Rauf 2017-01-08 899 "find fbmode1 : %s\n", g_fbmode[1]);
81dee67e215b23 Sudip Mukherjee 2015-03-03 900 } else {
c56de0967a658c Elise Lennion 2016-10-31 901 dev_warn(&sm750_dev->pdev->dev, "How many view you wann set?\n");
81dee67e215b23 Sudip Mukherjee 2015-03-03 902 }
81dee67e215b23 Sudip Mukherjee 2015-03-03 903 }
81dee67e215b23 Sudip Mukherjee 2015-03-03 904 }
81dee67e215b23 Sudip Mukherjee 2015-03-03 905
81dee67e215b23 Sudip Mukherjee 2015-03-03 906 NO_PARAM:
e359b6a863e19f Mike Rapoport 2015-10-26 907 if (sm750_dev->revid != SM750LE_REVISION_ID) {
a3f92cc94c6126 Mike Rapoport 2016-01-17 908 if (sm750_dev->fb_count > 1) {
81dee67e215b23 Sudip Mukherjee 2015-03-03 909 if (swap)
1757d106a9ce8c Mike Rapoport 2015-10-26 910 sm750_dev->dataflow = sm750_dual_swap;
81dee67e215b23 Sudip Mukherjee 2015-03-03 911 else
1757d106a9ce8c Mike Rapoport 2015-10-26 912 sm750_dev->dataflow = sm750_dual_normal;
81dee67e215b23 Sudip Mukherjee 2015-03-03 913 } else {
81dee67e215b23 Sudip Mukherjee 2015-03-03 914 if (swap)
1757d106a9ce8c Mike Rapoport 2015-10-26 915 sm750_dev->dataflow = sm750_simul_sec;
81dee67e215b23 Sudip Mukherjee 2015-03-03 916 else
1757d106a9ce8c Mike Rapoport 2015-10-26 917 sm750_dev->dataflow = sm750_simul_pri;
81dee67e215b23 Sudip Mukherjee 2015-03-03 918 }
81dee67e215b23 Sudip Mukherjee 2015-03-03 919 } else {
81dee67e215b23 Sudip Mukherjee 2015-03-03 920 /* SM750LE only have one crt channel */
1757d106a9ce8c Mike Rapoport 2015-10-26 921 sm750_dev->dataflow = sm750_simul_sec;
81dee67e215b23 Sudip Mukherjee 2015-03-03 922 /* sm750le do not have complex attributes */
1757d106a9ce8c Mike Rapoport 2015-10-26 923 sm750_dev->nocrt = 0;
81dee67e215b23 Sudip Mukherjee 2015-03-03 924 }
81dee67e215b23 Sudip Mukherjee 2015-03-03 925 }
81dee67e215b23 Sudip Mukherjee 2015-03-03 926
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: fbdev: update outdated help text for CONFIG_FB_NVIDIA
From: robgithub @ 2026-03-13 20:35 UTC (permalink / raw)
To: Randy Dunlap
Cc: robgithub, Helge Deller, Thomas Zimmermann, linux-fbdev,
Prasanna Kumar T S M, Wei Liu, Michael Kelley, Sukrut Heroorkar,
Mukesh Rathor, Uwe Kleine-König, dri-devel, linux-kernel
In-Reply-To: <034989df-cf86-4136-8522-6c48e5523645@infradead.org>
From 688a061ba0db71fc2d5facd8344db7a4d5b1575a Mon Sep 17 00:00:00 2001
From: robgithub <rob.github@jumpstation.co.uk>
Date: Wed, 11 Mar 2026 22:14:43 +0000
Subject: [PATCH] fbdev: update outdated help text for CONFIG_FB_NVIDIA
The help text for CONFIG_FB_NVIDIA refers to obsolete hardware and
incorrect default behaviour. This patch updates the description to
reflect the current state of the driver and supported devices.
Signed-off-by: robgithub <rob.github@jumpstation.co.uk>
---
drivers/video/fbdev/Kconfig | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index ac9ac4287c6a..d8e331427443 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -668,10 +668,10 @@ config FB_NVIDIA
select BITREVERSE
select VGASTATE
help
- This driver supports graphics boards with the nVidia chips, TNT
- and newer. For very old chipsets, such as the RIVA128, then use
- the rivafb.
- Say Y if you have such a graphics board.
+ Supports NVIDIA GPUs from TNT through early GeForce generations
+ (NV4–NV2x: Twintor, Twintor2, Celsius, Kelvin).
+ Later architectures (Rankine and newer) are not reliably supported.
+ If unsure, say N.
To compile this driver as a module, choose M here: the
module will be called nvidiafb.
--
2.52.0
Thanks, this my first time submitting a patch.
I have fixed the invisible whitespace inconsistency, wonder why I missed that :)
I really wanted to stop future users reading the "and newer" and enabling it on an unsupported card. It stopped my kernel booting with no errors.
The references I used to confirm the Nvidia devices affected are
List of devices documented in the code between lines 1228-1277
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/video/fbdev/nvidia/nvidia.c?h=v6.19.6
with more human readable extraction available at
https://cateee.net/lkddb/web-lkddb/FB_NVIDIA.html
and the code names for all Nvidia cards are here
https://nouveau.freedesktop.org/CodeNames.html
Regards
Rob
On Thu, 12 Mar 2026 14:02:18 -0700
Randy Dunlap <rdunlap@infradead.org> wrote:
> Hi,
>
> On 3/12/26 1:55 PM, robgithub wrote:
> > The help text for CONFIG_FB_NVIDIA refers to obsolete hardware and
> > incorrect default behaviour. This patch updates the description to
> > reflect the current state of the driver and supported devices.
> >
> > Signed-off-by: robgithub <rob.github@jumpstation.co.uk>
>
> Inline patches are preferred over attachments.
>
> I thought that Claws mail could send inline patches successfully. (?)
>
> Documentation/process/email-clients.rst says that it works (after a little
> configuration setting).
>
> I don't know anything about which products are supported, so I have no
> comment on that.
>
> In the patch, the indentation is incorrect. Kconfig help text should be
> indented with one tab + 2 spaces, not with 4 spaces.
>
> thanks.
^ permalink raw reply related
* [PATCH 1/3] staging: sm750fb: Rename enum sm750_pnltype values to snake_case
From: Shubham Chakraborty @ 2026-03-14 8:09 UTC (permalink / raw)
To: Sudip Mukherjee, Teddy Wang, Greg Kroah-Hartman, linux-fbdev,
linux-staging, linux-kernel
Cc: Shubham Chakraborty
This patch renames the CamelCase enum values in sm750_pnltype to follow the Linux kernel coding style.
Signed-off-by: Shubham Chakraborty <chakrabortyshubham66@gmail.com>
---
drivers/staging/sm750fb/sm750.c | 6 +++---
drivers/staging/sm750fb/sm750.h | 6 +++---
drivers/staging/sm750fb/sm750_hw.c | 6 +++---
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
index dec1f6b88a7d..729c34372a1e 100644
--- a/drivers/staging/sm750fb/sm750.c
+++ b/drivers/staging/sm750fb/sm750.c
@@ -942,11 +942,11 @@ static void sm750fb_setup(struct sm750_dev *sm750_dev, char *src)
} else if (!strncmp(opt, "nocrt", strlen("nocrt"))) {
sm750_dev->nocrt = 1;
} else if (!strncmp(opt, "36bit", strlen("36bit"))) {
- sm750_dev->pnltype = sm750_doubleTFT;
+ sm750_dev->pnltype = SM750_DOUBLE_TFT;
} else if (!strncmp(opt, "18bit", strlen("18bit"))) {
- sm750_dev->pnltype = sm750_dualTFT;
+ sm750_dev->pnltype = SM750_DUAL_TFT;
} else if (!strncmp(opt, "24bit", strlen("24bit"))) {
- sm750_dev->pnltype = sm750_24TFT;
+ sm750_dev->pnltype = SM750_24TFT;
} else if (!strncmp(opt, "nohwc0", strlen("nohwc0"))) {
g_hwcursor &= ~0x1;
} else if (!strncmp(opt, "nohwc1", strlen("nohwc1"))) {
diff --git a/drivers/staging/sm750fb/sm750.h b/drivers/staging/sm750fb/sm750.h
index 67b9bfa23f41..49a79d0a8a2e 100644
--- a/drivers/staging/sm750fb/sm750.h
+++ b/drivers/staging/sm750fb/sm750.h
@@ -13,9 +13,9 @@
#endif
enum sm750_pnltype {
- sm750_24TFT = 0, /* 24bit tft */
- sm750_dualTFT = 2, /* dual 18 bit tft */
- sm750_doubleTFT = 1, /* 36 bit double pixel tft */
+ SM750_24TFT = 0, /* 24bit tft */
+ SM750_DUAL_TFT = 2, /* dual 18 bit tft */
+ SM750_DOUBLE_TFT = 1, /* 36 bit double pixel tft */
};
/* vga channel is not concerned */
diff --git a/drivers/staging/sm750fb/sm750_hw.c b/drivers/staging/sm750fb/sm750_hw.c
index a29faee91c78..0e594734a8b9 100644
--- a/drivers/staging/sm750fb/sm750_hw.c
+++ b/drivers/staging/sm750fb/sm750_hw.c
@@ -134,12 +134,12 @@ int hw_sm750_inithw(struct sm750_dev *sm750_dev, struct pci_dev *pdev)
~(PANEL_DISPLAY_CTRL_DUAL_DISPLAY |
PANEL_DISPLAY_CTRL_DOUBLE_PIXEL);
switch (sm750_dev->pnltype) {
- case sm750_24TFT:
+ case SM750_24TFT:
break;
- case sm750_doubleTFT:
+ case SM750_DOUBLE_TFT:
val |= PANEL_DISPLAY_CTRL_DOUBLE_PIXEL;
break;
- case sm750_dualTFT:
+ case SM750_DUAL_TFT:
val |= PANEL_DISPLAY_CTRL_DUAL_DISPLAY;
break;
}
--
2.53.0
^ permalink raw reply related
* [PATCH 2/3] staging: sm750fb: Rename struct init_status members to snake_case
From: Shubham Chakraborty @ 2026-03-14 8:09 UTC (permalink / raw)
To: Sudip Mukherjee, Teddy Wang, Greg Kroah-Hartman, linux-fbdev,
linux-staging, linux-kernel
Cc: Shubham Chakraborty
In-Reply-To: <20260314080934.135457-1-chakrabortyshubham66@gmail.com>
Rename CamelCase members powerMode, setAllEngOff, and resetMemory to follow the Linux kernel coding style.
Signed-off-by: Shubham Chakraborty <chakrabortyshubham66@gmail.com>
---
drivers/staging/sm750fb/sm750.c | 6 +++---
drivers/staging/sm750fb/sm750.h | 6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
index 729c34372a1e..c30ffab8a5f3 100644
--- a/drivers/staging/sm750fb/sm750.c
+++ b/drivers/staging/sm750fb/sm750.c
@@ -921,9 +921,9 @@ static void sm750fb_setup(struct sm750_dev *sm750_dev, char *src)
sm750_dev->init_parm.chip_clk = 0;
sm750_dev->init_parm.mem_clk = 0;
sm750_dev->init_parm.master_clk = 0;
- sm750_dev->init_parm.powerMode = 0;
- sm750_dev->init_parm.setAllEngOff = 0;
- sm750_dev->init_parm.resetMemory = 1;
+ sm750_dev->init_parm.power_mode = 0;
+ sm750_dev->init_parm.set_all_eng_off = 0;
+ sm750_dev->init_parm.reset_memory = 1;
/* defaultly turn g_hwcursor on for both view */
g_hwcursor = 3;
diff --git a/drivers/staging/sm750fb/sm750.h b/drivers/staging/sm750fb/sm750.h
index 49a79d0a8a2e..b683a82af349 100644
--- a/drivers/staging/sm750fb/sm750.h
+++ b/drivers/staging/sm750fb/sm750.h
@@ -39,13 +39,13 @@ enum sm750_path {
};
struct init_status {
- ushort powerMode;
+ ushort power_mode;
/* below three clocks are in unit of MHZ*/
ushort chip_clk;
ushort mem_clk;
ushort master_clk;
- ushort setAllEngOff;
- ushort resetMemory;
+ ushort set_all_eng_off;
+ ushort reset_memory;
};
struct lynx_accel {
--
2.53.0
^ permalink raw reply related
* [PATCH 3/3] staging: sm750fb: Rename struct sm750_dev members to snake_case
From: Shubham Chakraborty @ 2026-03-14 8:09 UTC (permalink / raw)
To: Sudip Mukherjee, Teddy Wang, Greg Kroah-Hartman, linux-fbdev,
linux-staging, linux-kernel
Cc: Shubham Chakraborty
In-Reply-To: <20260314080934.135457-1-chakrabortyshubham66@gmail.com>
Rename CamelCase members pvReg and pvMem to follow the Linux kernel coding style.
Signed-off-by: Shubham Chakraborty <chakrabortyshubham66@gmail.com>
---
drivers/staging/sm750fb/sm750.c | 22 +++++++++++-----------
drivers/staging/sm750fb/sm750.h | 4 ++--
drivers/staging/sm750fb/sm750_hw.c | 20 ++++++++++----------
3 files changed, 23 insertions(+), 23 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
index c30ffab8a5f3..1c60ba056719 100644
--- a/drivers/staging/sm750fb/sm750.c
+++ b/drivers/staging/sm750fb/sm750.c
@@ -624,27 +624,27 @@ static int sm750fb_set_drv(struct lynxfb_par *par)
output->paths = sm750_pnc;
crtc->channel = sm750_primary;
crtc->o_screen = 0;
- crtc->v_screen = sm750_dev->pvMem;
+ crtc->v_screen = sm750_dev->pv_mem;
pr_info("use simul primary mode\n");
break;
case sm750_simul_sec:
output->paths = sm750_pnc;
crtc->channel = sm750_secondary;
crtc->o_screen = 0;
- crtc->v_screen = sm750_dev->pvMem;
+ crtc->v_screen = sm750_dev->pv_mem;
break;
case sm750_dual_normal:
if (par->index == 0) {
output->paths = sm750_panel;
crtc->channel = sm750_primary;
crtc->o_screen = 0;
- crtc->v_screen = sm750_dev->pvMem;
+ crtc->v_screen = sm750_dev->pv_mem;
} else {
output->paths = sm750_crt;
crtc->channel = sm750_secondary;
/* not consider of padding stuffs for o_screen,need fix */
crtc->o_screen = sm750_dev->vidmem_size >> 1;
- crtc->v_screen = sm750_dev->pvMem + crtc->o_screen;
+ crtc->v_screen = sm750_dev->pv_mem + crtc->o_screen;
}
break;
case sm750_dual_swap:
@@ -652,7 +652,7 @@ static int sm750fb_set_drv(struct lynxfb_par *par)
output->paths = sm750_panel;
crtc->channel = sm750_secondary;
crtc->o_screen = 0;
- crtc->v_screen = sm750_dev->pvMem;
+ crtc->v_screen = sm750_dev->pv_mem;
} else {
output->paths = sm750_crt;
crtc->channel = sm750_primary;
@@ -660,7 +660,7 @@ static int sm750fb_set_drv(struct lynxfb_par *par)
* need fix
*/
crtc->o_screen = sm750_dev->vidmem_size >> 1;
- crtc->v_screen = sm750_dev->pvMem + crtc->o_screen;
+ crtc->v_screen = sm750_dev->pv_mem + crtc->o_screen;
}
break;
default:
@@ -764,14 +764,14 @@ static int lynxfb_set_fbinfo(struct fb_info *info, int index)
* must be set after crtc member initialized
*/
crtc->cursor.offset = crtc->o_screen + crtc->vidmem_size - 1024;
- crtc->cursor.mmio = sm750_dev->pvReg +
+ crtc->cursor.mmio = sm750_dev->pv_reg +
0x800f0 + (int)crtc->channel * 0x140;
pr_info("crtc->cursor.mmio = %p\n", crtc->cursor.mmio);
crtc->cursor.max_h = 64;
crtc->cursor.max_w = 64;
crtc->cursor.size = crtc->cursor.max_h * crtc->cursor.max_w * 2 / 8;
- crtc->cursor.vstart = sm750_dev->pvMem + crtc->cursor.offset;
+ crtc->cursor.vstart = sm750_dev->pv_mem + crtc->cursor.offset;
memset_io(crtc->cursor.vstart, 0, crtc->cursor.size);
if (!g_hwcursor)
@@ -1090,7 +1090,7 @@ static int lynxfb_pci_probe(struct pci_dev *pdev,
sm750_dev->mtrr.vram = arch_phys_wc_add(sm750_dev->vidmem_start,
sm750_dev->vidmem_size);
- memset_io(sm750_dev->pvMem, 0, sm750_dev->vidmem_size);
+ memset_io(sm750_dev->pv_mem, 0, sm750_dev->vidmem_size);
pci_set_drvdata(pdev, sm750_dev);
@@ -1121,8 +1121,8 @@ static void lynxfb_pci_remove(struct pci_dev *pdev)
sm750fb_framebuffer_release(sm750_dev);
arch_phys_wc_del(sm750_dev->mtrr.vram);
- iounmap(sm750_dev->pvReg);
- iounmap(sm750_dev->pvMem);
+ iounmap(sm750_dev->pv_reg);
+ iounmap(sm750_dev->pv_mem);
kfree(g_settings);
}
diff --git a/drivers/staging/sm750fb/sm750.h b/drivers/staging/sm750fb/sm750.h
index b683a82af349..3f6570fc8f08 100644
--- a/drivers/staging/sm750fb/sm750.h
+++ b/drivers/staging/sm750fb/sm750.h
@@ -97,8 +97,8 @@ struct sm750_dev {
unsigned long vidreg_start;
__u32 vidmem_size;
__u32 vidreg_size;
- void __iomem *pvReg;
- unsigned char __iomem *pvMem;
+ void __iomem *pv_reg;
+ unsigned char __iomem *pv_mem;
/* locks*/
spinlock_t slock;
diff --git a/drivers/staging/sm750fb/sm750_hw.c b/drivers/staging/sm750fb/sm750_hw.c
index 0e594734a8b9..32b3813d0d8b 100644
--- a/drivers/staging/sm750fb/sm750_hw.c
+++ b/drivers/staging/sm750fb/sm750_hw.c
@@ -49,19 +49,19 @@ int hw_sm750_map(struct sm750_dev *sm750_dev, struct pci_dev *pdev)
}
/* now map mmio and vidmem */
- sm750_dev->pvReg =
+ sm750_dev->pv_reg =
ioremap(sm750_dev->vidreg_start, sm750_dev->vidreg_size);
- if (!sm750_dev->pvReg) {
+ if (!sm750_dev->pv_reg) {
pr_err("mmio failed\n");
ret = -EFAULT;
goto exit;
}
- pr_info("mmio virtual addr = %p\n", sm750_dev->pvReg);
+ pr_info("mmio virtual addr = %p\n", sm750_dev->pv_reg);
- sm750_dev->accel.dpr_base = sm750_dev->pvReg + DE_BASE_ADDR_TYPE1;
- sm750_dev->accel.dp_port_base = sm750_dev->pvReg + DE_PORT_ADDR_TYPE1;
+ sm750_dev->accel.dpr_base = sm750_dev->pv_reg + DE_BASE_ADDR_TYPE1;
+ sm750_dev->accel.dp_port_base = sm750_dev->pv_reg + DE_PORT_ADDR_TYPE1;
- mmio750 = sm750_dev->pvReg;
+ mmio750 = sm750_dev->pv_reg;
sm750_set_chip_type(sm750_dev->devid, sm750_dev->revid);
sm750_dev->vidmem_start = pci_resource_start(pdev, 0);
@@ -76,15 +76,15 @@ int hw_sm750_map(struct sm750_dev *sm750_dev, struct pci_dev *pdev)
sm750_dev->vidmem_start, sm750_dev->vidmem_size);
/* reserve the vidmem space of smi adaptor */
- sm750_dev->pvMem =
+ sm750_dev->pv_mem =
ioremap_wc(sm750_dev->vidmem_start, sm750_dev->vidmem_size);
- if (!sm750_dev->pvMem) {
- iounmap(sm750_dev->pvReg);
+ if (!sm750_dev->pv_mem) {
+ iounmap(sm750_dev->pv_reg);
pr_err("Map video memory failed\n");
ret = -EFAULT;
goto exit;
}
- pr_info("video memory vaddr = %p\n", sm750_dev->pvMem);
+ pr_info("video memory vaddr = %p\n", sm750_dev->pv_mem);
exit:
return ret;
}
--
2.53.0
^ permalink raw reply related
* [PATCH v1] backlight: apple_bl: Convert to a platform driver
From: Rafael J. Wysocki @ 2026-03-14 11:50 UTC (permalink / raw)
To: Lee Jones
Cc: LKML, Linux ACPI, Daniel Thompson, Jingoo Han, Helge Deller,
dri-devel, linux-fbdev
From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
In all cases in which a struct acpi_driver is used for binding a driver
to an ACPI device object, a corresponding platform device is created by
the ACPI core and that device is regarded as a proper representation of
underlying hardware. Accordingly, a struct platform_driver should be
used by driver code to bind to that device. There are multiple reasons
why drivers should not bind directly to ACPI device objects [1].
Overall, it is better to bind drivers to platform devices than to their
ACPI companions, so convert the Apple Backlight ACPI driver to a
platform one.
While this is not expected to alter functionality, it changes sysfs
layout and so it will be visible to user space.
Link: https://lore.kernel.org/all/2396510.ElGaqSPkdT@rafael.j.wysocki/ [1]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
drivers/video/backlight/apple_bl.c | 21 +++++++++++----------
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/video/backlight/apple_bl.c b/drivers/video/backlight/apple_bl.c
index aaa824437a2a..423513d68b5b 100644
--- a/drivers/video/backlight/apple_bl.c
+++ b/drivers/video/backlight/apple_bl.c
@@ -24,6 +24,7 @@
#include <linux/pci.h>
#include <linux/acpi.h>
#include <linux/atomic.h>
+#include <linux/platform_device.h>
#include <acpi/video.h>
static struct backlight_device *apple_backlight_device;
@@ -134,7 +135,7 @@ static const struct hw_data nvidia_chipset_data = {
.set_brightness = nvidia_chipset_set_brightness,
};
-static int apple_bl_add(struct acpi_device *dev)
+static int apple_bl_probe(struct platform_device *pdev)
{
struct backlight_properties props;
struct pci_dev *host;
@@ -193,7 +194,7 @@ static int apple_bl_add(struct acpi_device *dev)
return 0;
}
-static void apple_bl_remove(struct acpi_device *dev)
+static void apple_bl_remove(struct platform_device *pdev)
{
backlight_device_unregister(apple_backlight_device);
@@ -206,12 +207,12 @@ static const struct acpi_device_id apple_bl_ids[] = {
{"", 0},
};
-static struct acpi_driver apple_bl_driver = {
- .name = "Apple backlight",
- .ids = apple_bl_ids,
- .ops = {
- .add = apple_bl_add,
- .remove = apple_bl_remove,
+static struct platform_driver apple_bl_driver = {
+ .probe = apple_bl_probe,
+ .remove = apple_bl_remove,
+ .driver = {
+ .name = "Apple backlight",
+ .acpi_match_table = apple_bl_ids,
},
};
@@ -224,12 +225,12 @@ static int __init apple_bl_init(void)
if (acpi_video_get_backlight_type() != acpi_backlight_vendor)
return -ENODEV;
- return acpi_bus_register_driver(&apple_bl_driver);
+ return platform_driver_register(&apple_bl_driver);
}
static void __exit apple_bl_exit(void)
{
- acpi_bus_unregister_driver(&apple_bl_driver);
+ platform_driver_unregister(&apple_bl_driver);
}
module_init(apple_bl_init);
--
2.51.0
^ permalink raw reply related
* [PATCH 4/5] backlight: cgbc_bl: fix kernel-doc comment for struct cgbc_bl_data
From: Kit Dallege @ 2026-03-15 14:58 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, Jingoo Han
Cc: dri-devel, linux-fbdev, linux-kernel, Kit Dallege
Add the required 'struct cgbc_bl_data -' prefix to the kernel-doc
comment so it is properly recognized as struct documentation.
This fixes the following warning:
drivers/video/backlight/cgbc_bl.c:29: This comment starts with '/**', but isn't a kernel-doc comment
Signed-off-by: Kit Dallege <xaum.io@gmail.com>
Signed-off-by: kovan <xaum.io@gmail.com>
---
drivers/video/backlight/cgbc_bl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/backlight/cgbc_bl.c b/drivers/video/backlight/cgbc_bl.c
index ab27e14338a8..6b70cd2f0ddd 100644
--- a/drivers/video/backlight/cgbc_bl.c
+++ b/drivers/video/backlight/cgbc_bl.c
@@ -27,7 +27,7 @@
#define CGBC_BL_MAX_BRIGHTNESS 100
/**
- * CGBC backlight driver data
+ * struct cgbc_bl_data - CGBC backlight driver data
* @dev: Pointer to the platform device
* @cgbc: Pointer to the parent CGBC device data
* @current_brightness: Current brightness level (0-100)
--
2.53.0
^ permalink raw reply related
* [PATCH] staging: sm750fb: Replace busy-wait loop with udelay()
From: OaroraEtimis @ 2026-03-15 15:05 UTC (permalink / raw)
To: sudipm.mukherjee, teddy.wang, gregkh
Cc: linux-fbdev, linux-staging, linux-kernel, OaroraEtimis
The empty for-loop in sw_i2c_wait() triggers a -Wunused-but-set-variable
warning and can be optimized away by modern compilers.
Fix this by replacing the unreliable loop with a standard udelay(2).
This also cleans up the unused 'tmp' variable and outdated comments.
Include <linux/delay.h> to resolve the implicit function declaration.
Signed-off-by: OaroraEtimis <OaroraEtimis@gmail.com>
---
drivers/staging/sm750fb/ddk750_swi2c.c | 20 ++------------------
1 file changed, 2 insertions(+), 18 deletions(-)
diff --git a/drivers/staging/sm750fb/ddk750_swi2c.c b/drivers/staging/sm750fb/ddk750_swi2c.c
index 0ef8d4ff2ef9..d0aeb917be92 100644
--- a/drivers/staging/sm750fb/ddk750_swi2c.c
+++ b/drivers/staging/sm750fb/ddk750_swi2c.c
@@ -11,6 +11,7 @@
#include "ddk750_reg.h"
#include "ddk750_swi2c.h"
#include "ddk750_power.h"
+#include <linux/delay.h>
/*
* I2C Software Master Driver:
@@ -80,24 +81,7 @@ static unsigned long sw_i2c_data_gpio_data_dir_reg = GPIO_DATA_DIRECTION;
*/
static void sw_i2c_wait(void)
{
- /* find a bug:
- * peekIO method works well before suspend/resume
- * but after suspend, peekIO(0x3ce,0x61) & 0x10
- * always be non-zero,which makes the while loop
- * never finish.
- * use non-ultimate for loop below is safe
- */
-
- /* Change wait algorithm to use PCI bus clock,
- * it's more reliable than counter loop ..
- * write 0x61 to 0x3ce and read from 0x3cf
- */
- int i, tmp;
-
- for (i = 0; i < 600; i++) {
- tmp = i;
- tmp += i;
- }
+ udelay(2);
}
/*
--
2.47.3
^ permalink raw reply related
* [PATCH v2 1/2] staging: sm750fb: Replace busy-wait loop with udelay()
From: Oarora Etimis @ 2026-03-15 23:20 UTC (permalink / raw)
To: sudipm.mukherjee, teddy.wang, gregkh
Cc: linux-fbdev, linux-staging, linux-kernel, OaroraEtimis
From: OaroraEtimis <OaroraEtimis@gmail.com>
The empty for-loop in sw_i2c_wait() triggers a -Wunused-but-set-variable
warning and can be optimized away by modern compilers.
Fix this by replacing the unreliable loop with a standard udelay(2).
This also cleans up the unused 'tmp' variable and outdated comments.
Include <linux/delay.h> to resolve the implicit function declaration.
Signed-off-by: OaroraEtimis <OaroraEtimis@gmail.com>
---
Changes in v2:
- Rebased onto the latest staging-next branch to resolve merge conflicts.
- No logical code changes.
drivers/staging/sm750fb/ddk750_swi2c.c | 20 ++------------------
1 file changed, 2 insertions(+), 18 deletions(-)
diff --git a/drivers/staging/sm750fb/ddk750_swi2c.c b/drivers/staging/sm750fb/ddk750_swi2c.c
index e63f3b00ec4c..d579cb9da79e 100644
--- a/drivers/staging/sm750fb/ddk750_swi2c.c
+++ b/drivers/staging/sm750fb/ddk750_swi2c.c
@@ -11,6 +11,7 @@
#include "ddk750_reg.h"
#include "ddk750_swi2c.h"
#include "ddk750_power.h"
+#include <linux/delay.h>
/*
* I2C Software Master Driver:
@@ -80,24 +81,7 @@ static unsigned long sw_i2c_data_gpio_data_dir_reg = GPIO_DATA_DIRECTION;
*/
static void sw_i2c_wait(void)
{
- /* find a bug:
- * peekIO method works well before suspend/resume
- * but after suspend, peekIO(0x3ce,0x61) & 0x10
- * always be non-zero,which makes the while loop
- * never finish.
- * use non-ultimate for loop below is safe
- */
-
- /* Change wait algorithm to use PCI bus clock,
- * it's more reliable than counter loop ..
- * write 0x61 to 0x3ce and read from 0x3cf
- */
- int i, tmp;
-
- for (i = 0; i < 600; i++) {
- tmp = i;
- tmp += i;
- }
+ udelay(2);
}
/*
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v12 1/1] rust: interop: Add list module for C linked list interface
From: Alexandre Courbot @ 2026-03-16 4:34 UTC (permalink / raw)
To: Joel Fernandes
Cc: linux-kernel, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Alex Gaynor, Danilo Krummrich, Dave Airlie,
David Airlie, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Simona Vetter, Daniel Almeida, Koen Koning, Nikola Djukic,
Philipp Stanner, Elle Rhumsaa, 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,
John Hubbard, Alistair Popple, Timur Tabi, Edwin Peer,
Andrea Righi, Andy Ritger, Zhi Wang, Balbir Singh, alexeyi,
Eliot Courtney, dri-devel, nouveau, rust-for-linux, linux-doc,
amd-gfx, intel-gfx, intel-xe, linux-fbdev, Miguel Ojeda
In-Reply-To: <20260306203648.1136554-2-joelagnelf@nvidia.com>
On Sat Mar 7, 2026 at 5:36 AM JST, Joel Fernandes wrote:
> Add a new module `kernel::interop::list` 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.
>
> Cc: Nikola Djukic <ndjukic@nvidia.com>
> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
> Acked-by: Alexandre Courbot <acourbot@nvidia.com>
> Acked-by: Gary Guo <gary@garyguo.net>
> Acked-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
> ---
> MAINTAINERS | 8 +
> rust/helpers/helpers.c | 1 +
> rust/helpers/list.c | 17 ++
> rust/kernel/interop/list.rs | 338 ++++++++++++++++++++++++++++++++++++
> rust/kernel/interop/mod.rs | 9 +
I think I have mentioned that in another context, but the standard seems
to be to use `interop.rs` instead of `interop/mod.rs` (Miguel please
correct me if I'm wrong).
Also, and once again, please, please build with CLIPPY=1 before sending.
The buddy series also has clippy warnings. Fixing them before I can
review is tedious.
^ permalink raw reply
* Re: [PATCH v2 1/2] staging: sm750fb: Replace busy-wait loop with udelay()
From: Greg KH @ 2026-03-16 6:11 UTC (permalink / raw)
To: Oarora Etimis
Cc: sudipm.mukherjee, teddy.wang, linux-fbdev, linux-staging,
linux-kernel
In-Reply-To: <20260315232042.231620-1-OaroraEtimis@gmail.com>
On Mon, Mar 16, 2026 at 07:20:42AM +0800, Oarora Etimis wrote:
> From: OaroraEtimis <OaroraEtimis@gmail.com>
>
> The empty for-loop in sw_i2c_wait() triggers a -Wunused-but-set-variable
> warning and can be optimized away by modern compilers.
>
> Fix this by replacing the unreliable loop with a standard udelay(2).
> This also cleans up the unused 'tmp' variable and outdated comments.
> Include <linux/delay.h> to resolve the implicit function declaration.
>
> Signed-off-by: OaroraEtimis <OaroraEtimis@gmail.com>
> ---
> Changes in v2:
> - Rebased onto the latest staging-next branch to resolve merge conflicts.
> - No logical code changes.
>
> drivers/staging/sm750fb/ddk750_swi2c.c | 20 ++------------------
> 1 file changed, 2 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/staging/sm750fb/ddk750_swi2c.c b/drivers/staging/sm750fb/ddk750_swi2c.c
> index e63f3b00ec4c..d579cb9da79e 100644
> --- a/drivers/staging/sm750fb/ddk750_swi2c.c
> +++ b/drivers/staging/sm750fb/ddk750_swi2c.c
> @@ -11,6 +11,7 @@
> #include "ddk750_reg.h"
> #include "ddk750_swi2c.h"
> #include "ddk750_power.h"
> +#include <linux/delay.h>
>
> /*
> * I2C Software Master Driver:
> @@ -80,24 +81,7 @@ static unsigned long sw_i2c_data_gpio_data_dir_reg = GPIO_DATA_DIRECTION;
> */
> static void sw_i2c_wait(void)
> {
> - /* find a bug:
> - * peekIO method works well before suspend/resume
> - * but after suspend, peekIO(0x3ce,0x61) & 0x10
> - * always be non-zero,which makes the while loop
> - * never finish.
> - * use non-ultimate for loop below is safe
> - */
> -
> - /* Change wait algorithm to use PCI bus clock,
> - * it's more reliable than counter loop ..
> - * write 0x61 to 0x3ce and read from 0x3cf
> - */
> - int i, tmp;
> -
> - for (i = 0; i < 600; i++) {
> - tmp = i;
> - tmp += i;
> - }
> + udelay(2);
How is "2" the same as this busy loop?
And why not fix this properly, as the comment states? You just removed
that information so no one knows how to do this in the future :(
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v2 1/2] staging: sm750fb: Replace busy-wait loop with udelay()
From: OaroraEtimis @ 2026-03-16 7:42 UTC (permalink / raw)
To: gregkh
Cc: sudipm.mukherjee, teddy.wang, linux-fbdev, linux-staging,
linux-kernel
In-Reply-To: <2026031626-semisoft-attic-8b37@gregkh>
Hi Greg,
Thanks for the review. Sorry for dropping the historical comment in v2.
My only goal was to fix the -Wunused-but-set-variable warning and
prevent the loop from being optimized away by the compiler.
I will definitely restore the comment.
On Mon, Mar 16, 2026 at 14:11, Greg KH wrote:
> How is "2" the same as this busy loop?
It was a rough estimation. A 600-iteration empty loop on older CPUs
(~500MHz) took about 2 to 3 microseconds.
> And why not fix this properly, as the comment states?
The comment suggests writing to VGA ports (0x3ce/0x3cf) to force a
delay. I didn't implement this because I don't have the specific
hardware or datasheets to test it.
I was afraid that introducing direct VGA I/O just to fix a compiler
warning might cause unexpected hardware regressions *or compatibility
issues across different platforms.*
Given that I can't test hardware I/O, how would you prefer I handle this
in v3?
1. Keep the original loop but add cpu_relax() inside to prevent compiler
optimization. (Safest for the hardware)
2. Use udelay(2) (or ndelay) and restore the historical comment.
3. Migrate the driver to the standard i2c-algo-bit framework (a much
heavier refactoring).
I'd appreciate your guidance on the best path forward for this staging
driver.
Thanks,
Oarora
^ permalink raw reply
* Re: [PATCH v3] fbdev/hga: Request memory region before ioremap
From: Thomas Zimmermann @ 2026-03-16 8:13 UTC (permalink / raw)
To: Helge Deller, Hardik Phalet, Ferenc Bakonyi
Cc: Shuah Khan, Brigham Campbell, linux-nvidia, linux-fbdev,
dri-devel, linux-kernel
In-Reply-To: <e9580f2e-19e2-4e82-b041-afe4cf9fb301@gmx.de>
Hi
Am 13.03.26 um 13:50 schrieb Helge Deller:
> Hi Thomas,
>
> On 3/13/26 09:05, Thomas Zimmermann wrote:
>> Am 12.03.26 um 20:47 schrieb Helge Deller:
>>> On 3/12/26 16:10, Thomas Zimmermann wrote:
>>>> Am 12.03.26 um 16:04 schrieb Hardik Phalet:
>>>>> On Tue Mar 10, 2026 at 6:38 PM IST, Thomas Zimmermann wrote:
>>>>>> Hi,
>>>>>>
>>>>>> thanks for the patch. Let's hope there are no conflicts with other
>>>>>> hardware. IDK if anyone still uses this driver.
>>>>> Hi Thomas,
>>>>>
>>>>> Thanks for reviewing this.
>>>>>
>>>>> Since I currently do not have access to the hardware needed to
>>>>> test the
>>>>> change properly, I will drop this patch for now. I may revisit it
>>>>> once I
>>>>> can validate the behavior on real hardware.
>>>>
>>>> Good luck. That's the Hercules framebuffer driver. Finding such
>>>> ancient hardware that can run modern Linux is nigh impossible.
>>>>
>>>> But we can merge the patch. If it breaks anyone's setup, they will
>>>> send a bug report.
>>>>
>>>> Helge will pick up the fix if he's ok with it.
>>>
>>> No, I don't want to merge such patches any longer without any testing
>>> on real hardware. There is no actual problem (else someone would
>>> have reported),
>>> as such I don't see a benefit to apply it. Applying it just brings
>>> the risk
>>> that we break it for someone.
>>> So, NAK.
>>>
>>> I believe I wrote about my opinion already in another patch?
>>
>> Sorry, I wasn't aware.
>>
>>> I think we should rephrase that specific TODO item (which mentions
>>> the memory
>>> region allocation) that only patches which have been tested are
>>> accepted.
>>
>> There will likely no one show up here for testing unless it breaks
>> there system. Which you won't know until you merge the patch.
>
> No-one likes to merge unnecessary patches which highly potentially
> introduce malfunctioning and haven't been tested at all.
>
>> If only pre-tested patches can go in,
>
> You misunderstand.
> I'm still happy to take *any* patches for fbdev.
> Even untested ones if they
> a) seem necessary (e.g. bugfix), or
> b) seem beneficial (code cleanup)
> as long as they don't break the driver. This patch may break the driver.
Any patch falling under a) or b) may break a driver. The patch at hand
isn't even particularly fragile. People keep posting clean-up patches
for some of the fbdev drivers and I doubt that most of them have seen
any testing.
My point here is that if a patch breaks the driver then someone will
show up and report the regression. If you operate under the (implicit)
assumption that the driver breaks without anyone reporting the
regression, the corollary is that the driver is unused. And so should
be removed. I suspect this is the case for a lot of fbdev drivers. Hence
we should make a push to get drivers removed.
Best regards
Thomas
>
> Helge
--
--
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)
^ permalink raw reply
* Re: [PATCH v2 1/2] staging: sm750fb: Replace busy-wait loop with udelay()
From: Greg KH @ 2026-03-16 8:16 UTC (permalink / raw)
To: OaroraEtimis
Cc: sudipm.mukherjee, teddy.wang, linux-fbdev, linux-staging,
linux-kernel
In-Reply-To: <495a2eb6-619e-4ad8-b550-678f7334819e@gmail.com>
On Mon, Mar 16, 2026 at 03:42:04PM +0800, OaroraEtimis wrote:
> Hi Greg,
>
> Thanks for the review. Sorry for dropping the historical comment in v2. My
> only goal was to fix the -Wunused-but-set-variable warning and prevent the
> loop from being optimized away by the compiler.
>
> I will definitely restore the comment.
>
>
> On Mon, Mar 16, 2026 at 14:11, Greg KH wrote:
>
> > How is "2" the same as this busy loop?
>
> It was a rough estimation. A 600-iteration empty loop on older CPUs
> (~500MHz) took about 2 to 3 microseconds.
>
>
> > And why not fix this properly, as the comment states?
>
> The comment suggests writing to VGA ports (0x3ce/0x3cf) to force a delay. I
> didn't implement this because I don't have the specific hardware or
> datasheets to test it.
>
> I was afraid that introducing direct VGA I/O just to fix a compiler warning
> might cause unexpected hardware regressions *or compatibility issues across
> different platforms.*
>
> Given that I can't test hardware I/O, how would you prefer I handle this in
> v3?
Don't do any logical change that testing without hardware can not be
verified (i.e. whitespace changes).
> 1. Keep the original loop but add cpu_relax() inside to prevent compiler
> optimization. (Safest for the hardware)
Are you sure? Can you sleep at that point in time? What does the
performance of the device then look like?
> 2. Use udelay(2) (or ndelay) and restore the historical comment.
> 3. Migrate the driver to the standard i2c-algo-bit framework (a much heavier
> refactoring).
Number 3 is the best way.
good luck!
greg k-h
^ permalink raw reply
* Re: [PATCH] staging: sm750fb: Replace busy-wait loop with udelay()
From: Dan Carpenter @ 2026-03-16 8:55 UTC (permalink / raw)
To: OaroraEtimis, Sudip Mukherjee
Cc: sudipm.mukherjee, teddy.wang, gregkh, linux-fbdev, linux-staging,
linux-kernel
In-Reply-To: <20260315150532.87280-1-OaroraEtimis@gmail.com>
Hi Sudip,
What the status on a replacement for the sm750fb driver?
On Sun, Mar 15, 2026 at 11:05:32PM +0800, OaroraEtimis wrote:
> The empty for-loop in sw_i2c_wait() triggers a -Wunused-but-set-variable
> warning and can be optimized away by modern compilers.
>
> Fix this by replacing the unreliable loop with a standard udelay(2).
> This also cleans up the unused 'tmp' variable and outdated comments.
> Include <linux/delay.h> to resolve the implicit function declaration.
>
> Signed-off-by: OaroraEtimis <OaroraEtimis@gmail.com>
> ---
> drivers/staging/sm750fb/ddk750_swi2c.c | 20 ++------------------
> 1 file changed, 2 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/staging/sm750fb/ddk750_swi2c.c b/drivers/staging/sm750fb/ddk750_swi2c.c
> index 0ef8d4ff2ef9..d0aeb917be92 100644
> --- a/drivers/staging/sm750fb/ddk750_swi2c.c
> +++ b/drivers/staging/sm750fb/ddk750_swi2c.c
> @@ -11,6 +11,7 @@
> #include "ddk750_reg.h"
> #include "ddk750_swi2c.h"
> #include "ddk750_power.h"
> +#include <linux/delay.h>
>
> /*
> * I2C Software Master Driver:
> @@ -80,24 +81,7 @@ static unsigned long sw_i2c_data_gpio_data_dir_reg = GPIO_DATA_DIRECTION;
> */
> static void sw_i2c_wait(void)
> {
> - /* find a bug:
> - * peekIO method works well before suspend/resume
> - * but after suspend, peekIO(0x3ce,0x61) & 0x10
> - * always be non-zero,which makes the while loop
> - * never finish.
> - * use non-ultimate for loop below is safe
> - */
> -
> - /* Change wait algorithm to use PCI bus clock,
> - * it's more reliable than counter loop ..
> - * write 0x61 to 0x3ce and read from 0x3cf
> - */
> - int i, tmp;
> -
> - for (i = 0; i < 600; i++) {
> - tmp = i;
> - tmp += i;
> - }
> + udelay(2);
What an interesting thing... This function has always been nonsense
since it was first merged. The comment talks about the old code which
did:
while (peekIO(0x3ce, 0x61) & 0x10)
;
Which apparently "works well" except that after suspend it becomes
a forever loop so instead of that they have this bonkers "count to 600"
loop.
Your patch looks reasonable, but generally we don't merge that sort
of patch without anyone to test it. The problem with merging your code
is that it looks so reasonable, that people might assume it's correct.
Meanwhile if we just leave it as-is, everyone can see it's totally buggy
so when people report bugs we'll know exactly where to look.
Sudip was working on a replacement for this driver. Let's ask him for
advice.
regards,
dan carpenter
^ 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