* Re: [PATCH] staging: fbtft: fb_tinylcd: replace udelay() with usleep_range()
From: Greg KH @ 2026-03-11 14:56 UTC (permalink / raw)
To: Anas Iqbal; +Cc: andy, linux-staging, dri-devel, linux-fbdev, linux-kernel
In-Reply-To: <20260311142407.35403-1-mohd.abd.6602@gmail.com>
On Wed, Mar 11, 2026 at 02:24:07PM +0000, Anas Iqbal wrote:
> Replace udelay() with usleep_range() for a 250 microsecond delay
> as recommended by checkpatch.pl. usleep_range() avoids busy
> waiting and allows the scheduler to schedule other tasks.
>
> Signed-off-by: Anas Iqbal <mohd.abd.6602@gmail.com>
> ---
> drivers/staging/fbtft/fb_tinylcd.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/fbtft/fb_tinylcd.c b/drivers/staging/fbtft/fb_tinylcd.c
> index 9469248f2c50..51e6493b050f 100644
> --- a/drivers/staging/fbtft/fb_tinylcd.c
> +++ b/drivers/staging/fbtft/fb_tinylcd.c
> @@ -38,10 +38,10 @@ static int init_display(struct fbtft_par *par)
> write_reg(par, 0xE5, 0x00);
> write_reg(par, 0xF0, 0x36, 0xA5, 0x53);
> write_reg(par, 0xE0, 0x00, 0x35, 0x33, 0x00, 0x00, 0x00,
> - 0x00, 0x35, 0x33, 0x00, 0x00, 0x00);
> + 0x00, 0x35, 0x33, 0x00, 0x00, 0x00);
Don't you think the original formatting makes more sense? And you did
not describe this change in the changelog :(
> write_reg(par, MIPI_DCS_SET_PIXEL_FORMAT, 0x55);
> write_reg(par, MIPI_DCS_EXIT_SLEEP_MODE);
> - udelay(250);
> + usleep_range(250, 500);
This is a totally different change than above. And also one that keeps
getting rejected, please see the mailing list archives for details.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] staging: fbtft: fb_ra8875: replace udelay() with usleep_range()
From: Andy Shevchenko @ 2026-03-11 15:57 UTC (permalink / raw)
To: Anas Iqbal
Cc: andy, gregkh, linux-staging, dri-devel, linux-fbdev, linux-kernel
In-Reply-To: <20260311135245.32730-1-mohd.abd.6602@gmail.com>
On Wed, Mar 11, 2026 at 01:52:45PM +0000, Anas Iqbal wrote:
> Replace udelay() with usleep_range() for 100 microsecond delays as
> recommended by checkpatch.pl. usleep_range() avoids busy waiting and
> allows the scheduler to run other tasks.
fsleep().
Now, read README here:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/staging/fbtft/README
and act accordingly.
If you have been mentored on this, show the above link to your mentors.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] staging: fbtft: fb_tinylcd: replace udelay() with usleep_range()
From: Andy Shevchenko @ 2026-03-11 16:01 UTC (permalink / raw)
To: Anas Iqbal
Cc: andy, gregkh, linux-staging, dri-devel, linux-fbdev, linux-kernel
In-Reply-To: <20260311142407.35403-1-mohd.abd.6602@gmail.com>
On Wed, Mar 11, 2026 at 02:24:07PM +0000, Anas Iqbal wrote:
> Replace udelay() with usleep_range() for a 250 microsecond delay
> as recommended by checkpatch.pl. usleep_range() avoids busy
> waiting and allows the scheduler to schedule other tasks.
Now, read README here:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/staging/fbtft/README
and act accordingly.
If you have been mentored on this, show the above link to your mentors.
...
> write_reg(par, 0xE0, 0x00, 0x35, 0x33, 0x00, 0x00, 0x00,
> - 0x00, 0x35, 0x33, 0x00, 0x00, 0x00);
> + 0x00, 0x35, 0x33, 0x00, 0x00, 0x00);
Use the common sense here. This change won't be accepted.
...
> - udelay(250);
> + usleep_range(250, 500);
No.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v9 01/23] gpu: nova-core: Select GPU_BUDDY for VRAM allocation
From: Eliot Courtney @ 2026-03-12 6:34 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-2-joelagnelf@nvidia.com>
On Wed Mar 11, 2026 at 9:39 AM JST, Joel Fernandes wrote:
> nova-core will use the GPU buddy allocator for physical VRAM management.
> Enable it in Kconfig.
>
> Cc: Nikola Djukic <ndjukic@nvidia.com>
> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
> ---
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
^ permalink raw reply
* Re: [PATCH v9 02/23] gpu: nova-core: Kconfig: Sort select statements alphabetically
From: Eliot Courtney @ 2026-03-12 6:35 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-3-joelagnelf@nvidia.com>
On Wed Mar 11, 2026 at 9:39 AM JST, Joel Fernandes wrote:
> Reorder the select statements in NOVA_CORE Kconfig to be in
> alphabetical order.
>
> Suggested-by: Danilo Krummrich <dakr@kernel.org>
> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
> ---
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
^ permalink raw reply
* Re: [PATCH v9 03/23] gpu: nova-core: gsp: Return GspStaticInfo from boot()
From: Eliot Courtney @ 2026-03-12 6:37 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-4-joelagnelf@nvidia.com>
On Wed Mar 11, 2026 at 9:39 AM JST, Joel Fernandes wrote:
> Refactor the GSP boot function to return only the GspStaticInfo,
> removing the FbLayout from the return tuple.
I think the commit message may need updating - `boot` doesn't return
FbLayout. And it returns `GetGspStaticInfoReply`, not `GspStaticInfo`.
Other than that,
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
>
> @@ -126,7 +129,8 @@ fn run_fwsec_frts(
> /// user-space, patching them with signatures, and building firmware-specific intricate data
> /// structures that the GSP will use at runtime.
> ///
> - /// Upon return, the GSP is up and running, and its runtime object given as return value.
> + /// Upon return, the GSP is up and running, and static GPU information is returned.
> + ///
> pub(crate) fn boot(
> mut self: Pin<&mut Self>,
> pdev: &pci::Device<device::Bound>,
> @@ -134,7 +138,7 @@ pub(crate) fn boot(
> chipset: Chipset,
> gsp_falcon: &Falcon<Gsp>,
> sec2_falcon: &Falcon<Sec2>,
> - ) -> Result {
> + ) -> Result<GetGspStaticInfoReply> {
> let dev = pdev.as_ref();
>
> let bios = Vbios::new(dev, bar)?;
> @@ -225,6 +229,6 @@ pub(crate) fn boot(
> Err(e) => dev_warn!(pdev, "GPU name unavailable: {:?}\n", e),
> }
>
> - Ok(())
> + Ok(info)
> }
> }
^ permalink raw reply
* [PATCH] staging: fbtft: avoid empty macro argument in define_fbtft_write_reg
From: Zile Xiong @ 2026-03-12 11:18 UTC (permalink / raw)
To: andy, gregkh
Cc: deller, abdun.nihaal, dan.carpenter, chintanlike, niejianglei2021,
dri-devel, linux-fbdev, linux-staging, linux-kernel, Zile Xiong
Replace the empty modifier argument with a simple identity macro.
This fixes the error reported by scripts/checkpatch.pl while keeping
the original semantics unchanged.
The generated code is equivalent and builds successfully.
Signed-off-by: Zile Xiong <xiongzile99@gmail.com>
---
drivers/staging/fbtft/fbtft-bus.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/fbtft/fbtft-bus.c b/drivers/staging/fbtft/fbtft-bus.c
index 30e436ff19e4..380dd374a566 100644
--- a/drivers/staging/fbtft/fbtft-bus.c
+++ b/drivers/staging/fbtft/fbtft-bus.c
@@ -61,10 +61,10 @@ out: \
va_end(args); \
} \
EXPORT_SYMBOL(func);
-
-define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8, )
+#define fbtft_identity(x) (x)
+define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8, fbtft_identity)
define_fbtft_write_reg(fbtft_write_reg16_bus8, __be16, u16, cpu_to_be16)
-define_fbtft_write_reg(fbtft_write_reg16_bus16, u16, u16, )
+define_fbtft_write_reg(fbtft_write_reg16_bus16, u16, u16, fbtft_identity)
void fbtft_write_reg8_bus9(struct fbtft_par *par, int len, ...)
{
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] staging: fbtft: avoid empty macro argument in define_fbtft_write_reg
From: Dan Carpenter @ 2026-03-12 13:56 UTC (permalink / raw)
To: Zile Xiong
Cc: andy, gregkh, deller, abdun.nihaal, chintanlike, niejianglei2021,
dri-devel, linux-fbdev, linux-staging, linux-kernel
In-Reply-To: <20260312111807.96789-1-xiongzile99@gmail.com>
On Thu, Mar 12, 2026 at 07:18:07PM +0800, Zile Xiong wrote:
> Replace the empty modifier argument with a simple identity macro.
> This fixes the error reported by scripts/checkpatch.pl while keeping
> the original semantics unchanged.
>
> The generated code is equivalent and builds successfully.
>
> Signed-off-by: Zile Xiong <xiongzile99@gmail.com>
> ---
> drivers/staging/fbtft/fbtft-bus.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/fbtft/fbtft-bus.c b/drivers/staging/fbtft/fbtft-bus.c
> index 30e436ff19e4..380dd374a566 100644
> --- a/drivers/staging/fbtft/fbtft-bus.c
> +++ b/drivers/staging/fbtft/fbtft-bus.c
> @@ -61,10 +61,10 @@ out: \
> va_end(args); \
> } \
> EXPORT_SYMBOL(func);
> -
> -define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8, )
> +#define fbtft_identity(x) (x)
Someone sent this exact same patch before. Same name and everything.
https://lore.kernel.org/all/aYECoy7Apjwgzr9r@stanley.mountain/
A better sollution is to learn to just ignore checkpatch when it is
wrong. My previous email was longer.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH v3] fbdev/hga: Request memory region before ioremap
From: Hardik Phalet @ 2026-03-12 15:04 UTC (permalink / raw)
To: Thomas Zimmermann, Hardik Phalet, Ferenc Bakonyi, Helge Deller
Cc: Shuah Khan, Brigham Campbell, linux-nvidia, linux-fbdev,
dri-devel, linux-kernel
In-Reply-To: <3d58e520-0308-44c7-a43a-e438548e9c40@suse.de>
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.
Thanks again for your feedback.
Best regards,
Hardik
>
> Am 10.03.26 um 13:30 schrieb Hardik Phalet:
>> The driver calls ioremap() on the HGA video memory at 0xb0000 without
>> first reserving the physical address range. This leaves the kernel
>> resource tree incomplete and can cause silent conflicts with other
>> drivers claiming the same range.
>>
>> Add a devm_request_mem_region() call before ioremap() in
>> hga_card_detect() to reserve the memory region.
>>
>> Signed-off-by: Hardik Phalet <hardik.phalet@pm.me>
>
> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
>
> Best regards
> Thomas
>
>> ---
>> Changes in v3:
>> - Used dev_err() to log memory region request, based on another review
>> comment by Thomas [2].
>> Changes in v2:
>> - Used devm_request_mem_region instead of request_mem_region, based on a
>> review comment by Thomas [1].
>>
>> v1: https://lore.kernel.org/all/20260310064124.602848-1-hardik.phalet@pm.me/
>> v2: https://lore.kernel.org/all/20260310113810.789575-1-hardik.phalet@pm.me/
>> [1]: https://lore.kernel.org/all/5f9749ba-18a8-4b6b-a6e7-a011a3871bfb@suse.de/
>> [2]: https://lore.kernel.org/all/ec635591-c861-4aa8-a259-718690ddaa4e@suse.de/
>>
>> drivers/video/fbdev/hgafb.c | 9 +++++++--
>> 1 file changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/video/fbdev/hgafb.c b/drivers/video/fbdev/hgafb.c
>> index 14418aa3791a..d32fd1c5217c 100644
>> --- a/drivers/video/fbdev/hgafb.c
>> +++ b/drivers/video/fbdev/hgafb.c
>> @@ -276,7 +276,7 @@ static void hga_blank(int blank_mode)
>> spin_unlock_irqrestore(&hga_reg_lock, flags);
>> }
>>
>> -static int hga_card_detect(void)
>> +static int hga_card_detect(struct platform_device *pdev)
>> {
>> int count = 0;
>> void __iomem *p, *q;
>> @@ -284,6 +284,11 @@ static int hga_card_detect(void)
>>
>> hga_vram_len = 0x08000;
>>
>> + if (!devm_request_mem_region(&pdev->dev, 0xb0000, hga_vram_len, "hgafb")) {
>> + dev_err(&pdev->dev, "cannot reserve video memory at 0xb0000\n");
>> + return -EBUSY;
>> + }
>> +
>> hga_vram = ioremap(0xb0000, hga_vram_len);
>> if (!hga_vram)
>> return -ENOMEM;
>> @@ -568,7 +573,7 @@ static int hgafb_probe(struct platform_device *pdev)
>> struct fb_info *info;
>> int ret;
>>
>> - ret = hga_card_detect();
>> + ret = hga_card_detect(pdev);
>> if (ret)
>> return ret;
>>
>
> --
> --
> 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: Thomas Zimmermann @ 2026-03-12 15:10 UTC (permalink / raw)
To: Hardik Phalet, Ferenc Bakonyi, Helge Deller
Cc: Shuah Khan, Brigham Campbell, linux-nvidia, linux-fbdev,
dri-devel, linux-kernel
In-Reply-To: <DH0W99FBZJEX.30MPSPJVGV4ZF@pm.me>
Hi
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.
Best regards
Thomas
>
> Thanks again for your feedback.
>
> Best regards,
> Hardik
>> Am 10.03.26 um 13:30 schrieb Hardik Phalet:
>>> The driver calls ioremap() on the HGA video memory at 0xb0000 without
>>> first reserving the physical address range. This leaves the kernel
>>> resource tree incomplete and can cause silent conflicts with other
>>> drivers claiming the same range.
>>>
>>> Add a devm_request_mem_region() call before ioremap() in
>>> hga_card_detect() to reserve the memory region.
>>>
>>> Signed-off-by: Hardik Phalet <hardik.phalet@pm.me>
>> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
>>
>> Best regards
>> Thomas
>>
>>> ---
>>> Changes in v3:
>>> - Used dev_err() to log memory region request, based on another review
>>> comment by Thomas [2].
>>> Changes in v2:
>>> - Used devm_request_mem_region instead of request_mem_region, based on a
>>> review comment by Thomas [1].
>>>
>>> v1: https://lore.kernel.org/all/20260310064124.602848-1-hardik.phalet@pm.me/
>>> v2: https://lore.kernel.org/all/20260310113810.789575-1-hardik.phalet@pm.me/
>>> [1]: https://lore.kernel.org/all/5f9749ba-18a8-4b6b-a6e7-a011a3871bfb@suse.de/
>>> [2]: https://lore.kernel.org/all/ec635591-c861-4aa8-a259-718690ddaa4e@suse.de/
>>>
>>> drivers/video/fbdev/hgafb.c | 9 +++++++--
>>> 1 file changed, 7 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/video/fbdev/hgafb.c b/drivers/video/fbdev/hgafb.c
>>> index 14418aa3791a..d32fd1c5217c 100644
>>> --- a/drivers/video/fbdev/hgafb.c
>>> +++ b/drivers/video/fbdev/hgafb.c
>>> @@ -276,7 +276,7 @@ static void hga_blank(int blank_mode)
>>> spin_unlock_irqrestore(&hga_reg_lock, flags);
>>> }
>>>
>>> -static int hga_card_detect(void)
>>> +static int hga_card_detect(struct platform_device *pdev)
>>> {
>>> int count = 0;
>>> void __iomem *p, *q;
>>> @@ -284,6 +284,11 @@ static int hga_card_detect(void)
>>>
>>> hga_vram_len = 0x08000;
>>>
>>> + if (!devm_request_mem_region(&pdev->dev, 0xb0000, hga_vram_len, "hgafb")) {
>>> + dev_err(&pdev->dev, "cannot reserve video memory at 0xb0000\n");
>>> + return -EBUSY;
>>> + }
>>> +
>>> hga_vram = ioremap(0xb0000, hga_vram_len);
>>> if (!hga_vram)
>>> return -ENOMEM;
>>> @@ -568,7 +573,7 @@ static int hgafb_probe(struct platform_device *pdev)
>>> struct fb_info *info;
>>> int ret;
>>>
>>> - ret = hga_card_detect();
>>> + ret = hga_card_detect(pdev);
>>> if (ret)
>>> return ret;
>>>
>> --
>> --
>> 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)
>
>
--
--
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 v12 1/1] rust: interop: Add list module for C linked list interface
From: Danilo Krummrich @ 2026-03-12 17:42 UTC (permalink / raw)
To: Joel Fernandes, Miguel Ojeda
Cc: linux-kernel, 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, Miguel Ojeda
In-Reply-To: <20260306203648.1136554-2-joelagnelf@nvidia.com>
On Fri Mar 6, 2026 at 9:36 PM CET, 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>
Was this given off-list? I can't find a corresponding reply from Miguel.
> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
I'm asking since I'm looking forward to pick this up as a dependency for
GPU buddy.
Thanks,
Danilo
^ permalink raw reply
* Re: [PATCH v12.1 1/1] rust: gpu: Add GPU buddy allocator bindings
From: Danilo Krummrich @ 2026-03-12 17:45 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, 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
In-Reply-To: <20260309135338.3919996-2-joelagnelf@nvidia.com>
On Mon Mar 9, 2026 at 2:53 PM CET, Joel Fernandes wrote:
> Add safe Rust abstractions over the Linux kernel's GPU buddy
> allocator for physical memory management. The GPU buddy allocator
> implements a binary buddy system useful for GPU physical memory
> allocation. nova-core will use it for physical memory allocation.
>
> Christian Koenig mentioned he'd like to step down from reviewer role for
> GPU buddy so updated accordingly. Arun/Matthew agree on the modified entry.
>
> Cc: Nikola Djukic <ndjukic@nvidia.com>
> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
> ---
> MAINTAINERS | 6 +-
> rust/bindings/bindings_helper.h | 11 +
> rust/helpers/gpu.c | 23 ++
> rust/helpers/helpers.c | 1 +
> rust/kernel/gpu/buddy.rs | 611 ++++++++++++++++++++++++++++++++
> rust/kernel/gpu/mod.rs | 5 +
> rust/kernel/lib.rs | 2 +
> 7 files changed, 658 insertions(+), 1 deletion(-)
> create mode 100644 rust/helpers/gpu.c
> create mode 100644 rust/kernel/gpu/buddy.rs
> create mode 100644 rust/kernel/gpu/mod.rs
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 4c66f8261ff2..b2600dd05fc2 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -8513,7 +8513,9 @@ T: git https://gitlab.freedesktop.org/drm/rust/kernel.git
> F: drivers/gpu/drm/nova/
> F: drivers/gpu/drm/tyr/
> F: drivers/gpu/nova-core/
> +F: rust/helpers/gpu.c
> F: rust/kernel/drm/
> +F: rust/kernel/gpu/
>
> DRM DRIVERS FOR ALLWINNER A10
> M: Chen-Yu Tsai <wens@kernel.org>
> @@ -8926,7 +8928,7 @@ F: include/drm/ttm/
> GPU BUDDY ALLOCATOR
> M: Matthew Auld <matthew.auld@intel.com>
> M: Arun Pravin <arunpravin.paneerselvam@amd.com>
> -R: Christian Koenig <christian.koenig@amd.com>
This should really be a separate patch as it is unrelated to the addition of the
Rust GPU buddy code.
> +R: Joel Fernandes <joelagnelf@nvidia.com>
> L: dri-devel@lists.freedesktop.org
> S: Maintained
> T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
> @@ -8935,6 +8937,8 @@ F: drivers/gpu/buddy.c
> F: drivers/gpu/tests/gpu_buddy_test.c
> F: include/linux/gpu_buddy.h
> F: include/drm/drm_buddy.h
> +F: rust/helpers/gpu.c
> +F: rust/kernel/gpu/
^ 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:15 UTC (permalink / raw)
To: Danilo Krummrich
Cc: Joel Fernandes, Miguel Ojeda, linux-kernel, 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: <DH0ZMJKN6OE6.243UPT928HIIX@kernel.org>
On Thu, Mar 12, 2026 at 6:42 PM Danilo Krummrich <dakr@kernel.org> wrote:
>
> Was this given off-list? I can't find a corresponding reply from Miguel.
Thanks for double-checking that -- it is fine.
I am sending some nits and Clippy issues independently though.
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: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
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