* Re: [PATCH 0/3] fbdev: Request memory regions in platform drivers
From: Geert Uytterhoeven @ 2026-04-23 7:22 UTC (permalink / raw)
To: Amit Barzilai; +Cc: deller, thomas.zimmermann, linux-fbdev, dri-devel
In-Reply-To: <20260420134424.77494-1-amit.barzilai22@gmail.com>
Hi Amit,
On Mon, 20 Apr 2026 at 17:23, Amit Barzilai <amit.barzilai22@gmail.com> wrote:
> Several fbdev platform drivers call ioremap() on their hardware MMIO
> without first claiming the range via request_mem_region(). This leaves
> the kernel resource tree (/proc/iomem) with no record of the mapping,
> allowing another driver to silently map the same registers.
>
> This series fixes three platform_device drivers by switching to helpers
> that combine resource claiming and ioremap in a single managed call.
> cobalt_lcdfb and clps711x-fb are converted to
> devm_platform_get_and_ioremap_resource(); goldfishfb is converted to
> devm_ioremap_resource(), which also lets us drop the manual iounmap()
> calls from the error path and remove function.
>
> For clps711x-fb, resource 1 (the framebuffer range) already used
> devm_platform_get_and_ioremap_resource() correctly; this series makes
> resource 0 (the MMIO control registers) consistent with it.
>
> This is part of the ongoing effort described in
> Documentation/drm/todo.rst ("Request memory regions in all fbdev
> drivers").
This file does not seem to exist?
Was it hallucinated by Claude:claude-sonnet-4-6?
> Amit Barzilai (3):
> fbdev: cobalt_lcdfb: Request memory region
> fbdev: clps711x-fb: Request memory region for MMIO
> fbdev: goldfishfb: Request memory region
Thanks for your series, which is now commit d2386d9e3eb4c12f ("fbdev:
cobalt_lcdfb: Request memory region") and a40c0e815962b1f6 ("fbdev:
clps711x-fb: Request memory region for MMIO") in fbdev/for-next.
Have you tested this series? I have to ask, because adding
seemingly-innocent request_mem_region() calls without testing the
result is a recurring source of broken drivers.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 0/3] fbdev: Request memory regions in platform drivers
From: Amit Barzilai @ 2026-04-23 13:42 UTC (permalink / raw)
To: geert; +Cc: amit.barzilai22, deller, dri-devel, linux-fbdev,
thomas.zimmermann
In-Reply-To: <CAMuHMdWhpD5vjfzsYieVOrio0chQAU=s0z5rX8AKTon3S=v-OA@mail.gmail.com>
Hi Geert,
> This file does not seem to exist?
> Was it hallucinated by Claude:claude-sonnet-4-6?
You are right, I apologize. The correct path is Documentation/gpu/todo.rst.
I will double-check all references before submitting next time.
> Have you tested this series? I have to ask, because adding
> seemingly-innocent request_mem_region() calls without testing the
> result is a recurring source of broken drivers.
I cross-compiled cobalt_lcdfb against cobalt_defconfig (MIPS) and
clps711x-fb against clps711x_defconfig (ARM). Neither platform has a
QEMU machine available, so I was not able to do runtime testing.
I understand that is not ideal. The changes replace ioremap() with
devm_platform_get_and_ioremap_resource(), which is already widely used
across the tree and handles failure cleanly, but I can understand that
compile-only testing is not a substitute for hardware validation on
resource-sensitive paths.
I have not been able to find a suitable runtime environment for either
platform. If you know of one, I have no problem validating these changes
properly before they go further.
Thanks,
Amit
^ permalink raw reply
* [PATCH] drm/todo: Drop todo item to request memory regions in all fbdev drivers
From: Helge Deller @ 2026-04-23 20:55 UTC (permalink / raw)
To: linux-fbdev, dri-devel
This item is tagged for beginners, so often people not familiar with
the fbdev drivers think this is an easy task, start up their AI tools
and blindly send in the generated code as patches.
The problem:
- Those patches often introduce bugs, so
- ideally want the code tested, since ressource misconfigurations
often lead to failing drivers
- The patches are often unnecessary, since in the old machines with the
old graphic cards resource conflicts usually don't happen as only one
graphic card can be used at a time anyway.
- and today most relevant drivers have necessary patches already
implemented.
So, let's get rid of this todo item and silence the steady stream of
stupid patches.
Signed-off-by: Helge Deller <deller@gmx.de>
---
Documentation/gpu/todo.rst | 16 ----------------
1 file changed, 16 deletions(-)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index bc9f14c8a2ec..b4dd64a8cc06 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -448,22 +448,6 @@ Contact: Thomas Zimmermann <tzimmermann@suse.de>
Level: Intermediate
-Request memory regions in all fbdev drivers
---------------------------------------------
-
-Old/ancient fbdev drivers do not request their memory properly.
-Go through these drivers and add code to request the memory regions
-that the driver uses. This requires adding calls to request_mem_region(),
-pci_request_region() or similar functions. Use helpers for managed cleanup
-where possible. Problematic areas include hardware that has exclusive ranges
-like VGA. VGA16fb does not request the range as it is expected.
-Drivers are pretty bad at doing this and there used to be conflicts among
-DRM and fbdev drivers. Still, it's the correct thing to do.
-
-Contact: Thomas Zimmermann <tzimmermann@suse.de>
-
-Level: Starter
-
Remove driver dependencies on FB_DEVICE
---------------------------------------
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] drm/todo: Drop todo item to request memory regions in all fbdev drivers
From: Geert Uytterhoeven @ 2026-04-24 6:43 UTC (permalink / raw)
To: Helge Deller; +Cc: linux-fbdev, dri-devel, Thomas Zimmermann
In-Reply-To: <20260423205531.49971-1-deller@gmx.de>
Hi Helge,
On Thu, 23 Apr 2026 at 23:04, Helge Deller <deller@gmx.de> wrote:
> This item is tagged for beginners, so often people not familiar with
> the fbdev drivers think this is an easy task, start up their AI tools
> and blindly send in the generated code as patches.
>
> The problem:
> - Those patches often introduce bugs, so
> - ideally want the code tested, since ressource misconfigurations
resource
> often lead to failing drivers
> - The patches are often unnecessary, since in the old machines with the
> old graphic cards resource conflicts usually don't happen as only one
> graphic card can be used at a time anyway.
> - and today most relevant drivers have necessary patches already
> implemented.
>
> So, let's get rid of this todo item and silence the steady stream of
> stupid patches.
>
> Signed-off-by: Helge Deller <deller@gmx.de>
Thanks for your patch!
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -448,22 +448,6 @@ Contact: Thomas Zimmermann <tzimmermann@suse.de>
>
> Level: Intermediate
>
> -Request memory regions in all fbdev drivers
> ---------------------------------------------
> -
> -Old/ancient fbdev drivers do not request their memory properly.
> -Go through these drivers and add code to request the memory regions
> -that the driver uses. This requires adding calls to request_mem_region(),
> -pci_request_region() or similar functions. Use helpers for managed cleanup
> -where possible. Problematic areas include hardware that has exclusive ranges
> -like VGA. VGA16fb does not request the range as it is expected.
> -Drivers are pretty bad at doing this and there used to be conflicts among
> -DRM and fbdev drivers. Still, it's the correct thing to do.
> -
> -Contact: Thomas Zimmermann <tzimmermann@suse.de>
> -
> -Level: Starter
I am not really against keeping this item. But as the related changes
are not pure refactorings, and cause a change in behavior, they _must_
be tested on actual hardware. I guess making that explicit would be a
bit silly (heck, all changes should be tested). And bumping the level
to intermediate might send the wrong message, too (starters don't need
to test? Doh...)
Thomas: do we still any hardware for which there exist both DRM and
fbdev drivers, and the resource management is missing in the fbdev
drivers?
> -
> Remove driver dependencies on FB_DEVICE
> ---------------------------------------
>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] drm/todo: Drop todo item to request memory regions in all fbdev drivers
From: Thomas Zimmermann @ 2026-04-24 6:57 UTC (permalink / raw)
To: Helge Deller, linux-fbdev, dri-devel
In-Reply-To: <20260423205531.49971-1-deller@gmx.de>
Hi
Am 23.04.26 um 22:55 schrieb Helge Deller:
> This item is tagged for beginners, so often people not familiar with
> the fbdev drivers think this is an easy task, start up their AI tools
> and blindly send in the generated code as patches.
>
> The problem:
> - Those patches often introduce bugs, so
> - ideally want the code tested, since ressource misconfigurations
> often lead to failing drivers
> - The patches are often unnecessary, since in the old machines with the
> old graphic cards resource conflicts usually don't happen as only one
> graphic card can be used at a time anyway.
> - and today most relevant drivers have necessary patches already
> implemented.
>
> So, let's get rid of this todo item and silence the steady stream of
> stupid patches.
I see that AI patches can be problematic, but reserving these regions is
still the correct thing to do. Removing the TODO item will not change that.
Some background on why this item exists: we currently use aperture
helpers [1] to manage ownership of the framebuffer memory during boot
up. This is necessary to switch from the system-framebuffer driver
(i..e, simplefb, simpledrm, etc) to the hardware's native driver. But
this is all ad-hoc because Linux' resource management doesn't do this
for us. Before we can integrate any such functionality, we have to fix
all drivers to reserve their resources correctly.
If we remove the TODO item, we'd likely still want to move forward with
improving resource management. If that breaks unfixed fbdev drivers,
users would then also send bug reports.
And the other point is (again) that if there are no means of testing a
driver and no information whether a driver is actually in used by
anyone, it's maybe time to remove the driver.
[1]
https://elixir.bootlin.com/linux/v7.0.1/source/drivers/video/aperture.c#L17
Best regards
Thomas
>
> Signed-off-by: Helge Deller <deller@gmx.de>
> ---
> Documentation/gpu/todo.rst | 16 ----------------
> 1 file changed, 16 deletions(-)
>
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index bc9f14c8a2ec..b4dd64a8cc06 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -448,22 +448,6 @@ Contact: Thomas Zimmermann <tzimmermann@suse.de>
>
> Level: Intermediate
>
> -Request memory regions in all fbdev drivers
> ---------------------------------------------
> -
> -Old/ancient fbdev drivers do not request their memory properly.
> -Go through these drivers and add code to request the memory regions
> -that the driver uses. This requires adding calls to request_mem_region(),
> -pci_request_region() or similar functions. Use helpers for managed cleanup
> -where possible. Problematic areas include hardware that has exclusive ranges
> -like VGA. VGA16fb does not request the range as it is expected.
> -Drivers are pretty bad at doing this and there used to be conflicts among
> -DRM and fbdev drivers. Still, it's the correct thing to do.
> -
> -Contact: Thomas Zimmermann <tzimmermann@suse.de>
> -
> -Level: Starter
> -
> Remove driver dependencies on FB_DEVICE
> ---------------------------------------
>
--
--
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] drm/todo: Drop todo item to request memory regions in all fbdev drivers
From: Thomas Zimmermann @ 2026-04-24 7:01 UTC (permalink / raw)
To: Geert Uytterhoeven, Helge Deller; +Cc: linux-fbdev, dri-devel
In-Reply-To: <CAMuHMdVOk3ejrM5EkOBRjc0rQsSGU7TP+Kgd4=DzYuiF8m8Mzw@mail.gmail.com>
Hi
>> -Contact: Thomas Zimmermann <tzimmermann@suse.de>
>> -
>> -Level: Starter
> I am not really against keeping this item. But as the related changes
> are not pure refactorings, and cause a change in behavior, they _must_
> be tested on actual hardware. I guess making that explicit would be a
> bit silly (heck, all changes should be tested). And bumping the level
> to intermediate might send the wrong message, too (starters don't need
> to test? Doh...)
>
> Thomas: do we still any hardware for which there exist both DRM and
> fbdev drivers, and the resource management is missing in the fbdev
> drivers?
See my other reply on why this item exists. It's also about hand-over
during boot up, which could affect any/most driver.
We can remove the item now, if that helps, but it might lead to other
bug reports later on.
Best regards
Thomas
>
>> -
>> Remove driver dependencies on FB_DEVICE
>> ---------------------------------------
>>
> Gr{oetje,eeting}s,
>
> Geert
>
--
--
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] drm/todo: Drop todo item to request memory regions in all fbdev drivers
From: Helge Deller @ 2026-04-24 8:36 UTC (permalink / raw)
To: Thomas Zimmermann, Geert Uytterhoeven; +Cc: linux-fbdev, dri-devel
In-Reply-To: <39ecf9f1-fd8d-4946-bb09-1041150d99eb@suse.de>
On 4/24/26 09:01, Thomas Zimmermann wrote:
> Hi
>
>>> -Contact: Thomas Zimmermann <tzimmermann@suse.de>
>>> -
>>> -Level: Starter
>> I am not really against keeping this item. But as the related changes
>> are not pure refactorings, and cause a change in behavior, they _must_
>> be tested on actual hardware. I guess making that explicit would be a
>> bit silly (heck, all changes should be tested). And bumping the level
>> to intermediate might send the wrong message, too (starters don't need
>> to test? Doh...)
>>
>> Thomas: do we still any hardware for which there exist both DRM and
>> fbdev drivers, and the resource management is missing in the fbdev
>> drivers?
>
> See my other reply on why this item exists. It's also about hand-
> over during boot up, which could affect any/most driver.
>
> We can remove the item now, if that helps, but it might lead to other bug reports later on.
Thanks, I'll remove the item now.
In case we run into reports later on, I'm happy to work with you on them then.
Can I add an Acked-by from you?
Helge
^ permalink raw reply
* Re: [PATCH] drm/todo: Drop todo item to request memory regions in all fbdev drivers
From: Helge Deller @ 2026-04-24 8:39 UTC (permalink / raw)
To: Thomas Zimmermann, linux-fbdev, dri-devel
In-Reply-To: <3fe83b69-b868-45a8-9862-50c6f0fdeb95@suse.de>
On 4/24/26 08:57, Thomas Zimmermann wrote:
> Hi
>
> Am 23.04.26 um 22:55 schrieb Helge Deller:
>> This item is tagged for beginners, so often people not familiar with
>> the fbdev drivers think this is an easy task, start up their AI tools
>> and blindly send in the generated code as patches.
>>
>> The problem:
>> - Those patches often introduce bugs, so
>> - ideally want the code tested, since ressource misconfigurations
>> often lead to failing drivers
>> - The patches are often unnecessary, since in the old machines with the
>> old graphic cards resource conflicts usually don't happen as only one
>> graphic card can be used at a time anyway.
>> - and today most relevant drivers have necessary patches already
>> implemented.
>>
>> So, let's get rid of this todo item and silence the steady stream of
>> stupid patches.
>
> I see that AI patches can be problematic, but reserving these
> regions is still the correct thing to do. Removing the TODO item
> will not change that.
Sure.
> Some background on why this item exists: we currently use aperture
> helpers [1] to manage ownership of the framebuffer memory during
> boot up. This is necessary to switch from the system-framebuffer
> driver (i..e, simplefb, simpledrm, etc) to the hardware's native
> driver. But this is all ad-hoc because Linux' resource management
> doesn't do this for us. Before we can integrate any such
> functionality, we have to fix all drivers to reserve their resources
> correctly.
>
> If we remove the TODO item, we'd likely still want to move forward
> with improving resource management. If that breaks unfixed fbdev
> drivers, users would then also send bug reports.
Ok for me.
Helge
> And the other point is (again) that if there are no means of testing a driver and no information whether a driver is actually in used by anyone, it's maybe time to remove the driver.
>
> [1] https://elixir.bootlin.com/linux/v7.0.1/source/drivers/video/aperture.c#L17
>
> Best regards
> Thomas
>
>
>>
>> Signed-off-by: Helge Deller <deller@gmx.de>
>> ---
>> Documentation/gpu/todo.rst | 16 ----------------
>> 1 file changed, 16 deletions(-)
>>
>> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
>> index bc9f14c8a2ec..b4dd64a8cc06 100644
>> --- a/Documentation/gpu/todo.rst
>> +++ b/Documentation/gpu/todo.rst
>> @@ -448,22 +448,6 @@ Contact: Thomas Zimmermann <tzimmermann@suse.de>
>> Level: Intermediate
>> -Request memory regions in all fbdev drivers
>> ---------------------------------------------
>> -
>> -Old/ancient fbdev drivers do not request their memory properly.
>> -Go through these drivers and add code to request the memory regions
>> -that the driver uses. This requires adding calls to request_mem_region(),
>> -pci_request_region() or similar functions. Use helpers for managed cleanup
>> -where possible. Problematic areas include hardware that has exclusive ranges
>> -like VGA. VGA16fb does not request the range as it is expected.
>> -Drivers are pretty bad at doing this and there used to be conflicts among
>> -DRM and fbdev drivers. Still, it's the correct thing to do.
>> -
>> -Contact: Thomas Zimmermann <tzimmermann@suse.de>
>> -
>> -Level: Starter
>> -
>> Remove driver dependencies on FB_DEVICE
>> ---------------------------------------
>
^ permalink raw reply
* Re: [PATCH] drm/todo: Drop todo item to request memory regions in all fbdev drivers
From: Thomas Zimmermann @ 2026-04-24 8:52 UTC (permalink / raw)
To: Helge Deller, Geert Uytterhoeven; +Cc: linux-fbdev, dri-devel
In-Reply-To: <c5e49d34-f9b7-4d9e-a8ff-c2de3a3025fb@gmx.de>
Hi
Am 24.04.26 um 10:36 schrieb Helge Deller:
> On 4/24/26 09:01, Thomas Zimmermann wrote:
>> Hi
>>
>>>> -Contact: Thomas Zimmermann <tzimmermann@suse.de>
>>>> -
>>>> -Level: Starter
>>> I am not really against keeping this item. But as the related changes
>>> are not pure refactorings, and cause a change in behavior, they _must_
>>> be tested on actual hardware. I guess making that explicit would be a
>>> bit silly (heck, all changes should be tested). And bumping the level
>>> to intermediate might send the wrong message, too (starters don't need
>>> to test? Doh...)
>>>
>>> Thomas: do we still any hardware for which there exist both DRM and
>>> fbdev drivers, and the resource management is missing in the fbdev
>>> drivers?
>>
>> See my other reply on why this item exists. It's also about hand-
>> over during boot up, which could affect any/most driver.
>>
>> We can remove the item now, if that helps, but it might lead to other
>> bug reports later on.
>
> Thanks, I'll remove the item now.
> In case we run into reports later on, I'm happy to work with you on
> them then.
>
> Can I add an Acked-by from you?
No. I think I made my point clear why this item exists. We can talk
about how to handle these old drivers (staging, removal, fixing, etc),
but pretending it's all well will not solve any issues.
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] fbdev: dnfb: fix reference leak on failed device registration
From: Guangshuo Li @ 2026-04-24 8:57 UTC (permalink / raw)
To: Helge Deller, Guangshuo Li, linux-fbdev, dri-devel, linux-kernel; +Cc: stable
In-Reply-To: <20260415190738.3821974-1-lgs201920130244@gmail.com>
Hi,
Please disregard this patch.
On Thu, 16 Apr 2026 at 03:07, Guangshuo Li <lgs201920130244@gmail.com> wrote:
>
> When platform_device_register() fails in dnfb_init(), the embedded
> struct device in dnfb_device has already been initialized by
> device_initialize(), but the failure path only unregisters the platform
> driver and does not drop the device reference for the current platform
> device:
>
> dnfb_init()
> -> platform_device_register(&dnfb_device)
> -> device_initialize(&dnfb_device.dev)
> -> setup_pdev_dma_masks(&dnfb_device)
> -> platform_device_add(&dnfb_device)
>
> This leads to a reference leak when platform_device_register() fails.
> Fix this by calling platform_device_put() before unregistering the
> platform driver.
>
> The issue was identified by a static analysis tool I developed and
> confirmed by manual review.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
> ---
> drivers/video/fbdev/dnfb.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/dnfb.c b/drivers/video/fbdev/dnfb.c
> index c4d24540d9ef..72a9c47418f8 100644
> --- a/drivers/video/fbdev/dnfb.c
> +++ b/drivers/video/fbdev/dnfb.c
> @@ -296,8 +296,10 @@ static int __init dnfb_init(void)
>
> if (!ret) {
> ret = platform_device_register(&dnfb_device);
> - if (ret)
> + if (ret) {
> + platform_device_put(&dnfb_device);
> platform_driver_unregister(&dnfb_driver);
> + }
> }
> return ret;
> }
> --
> 2.43.0
>
After re-checking it, dnfb_device is a static platform_device and it does
not provide a dev.release callback. Therefore calling
platform_device_put() on the platform_device_register() failure path is
not appropriate here and can trigger the missing release callback
warning.
This falls into the same static platform_device pattern pointed out in
the other reviews, so I will drop this patch.
Sorry for the noise.
Best regards,
Guangshuo Li
^ permalink raw reply
* Re: [PATCH] fbdev: hitfb: fix reference leak on failed device registration
From: Guangshuo Li @ 2026-04-24 9:00 UTC (permalink / raw)
To: Helge Deller, Guangshuo Li, Andriy Skulysh, Paul Mundt,
linux-fbdev, dri-devel, linux-kernel
Cc: stable
In-Reply-To: <20260415191003.3829558-1-lgs201920130244@gmail.com>
Hi,
Please disregard this patch.
On Thu, 16 Apr 2026 at 03:10, Guangshuo Li <lgs201920130244@gmail.com> wrote:
>
> When platform_device_register() fails in hitfb_init(), the embedded
> struct device in hitfb_device has already been initialized by
> device_initialize(), but the failure path only unregisters the platform
> driver and does not drop the device reference for the current platform
> device:
>
> hitfb_init()
> -> platform_device_register(&hitfb_device)
> -> device_initialize(&hitfb_device.dev)
> -> setup_pdev_dma_masks(&hitfb_device)
> -> platform_device_add(&hitfb_device)
>
> This leads to a reference leak when platform_device_register() fails.
> Fix this by calling platform_device_put() before unregistering the
> platform driver.
>
> The issue was identified by a static analysis tool I developed and
> confirmed by manual review.
>
> Fixes: 048839dc548a5 ("video: hitfb suspend/resume and updates.")
> Cc: stable@vger.kernel.org
> Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
> ---
> drivers/video/fbdev/hitfb.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/hitfb.c b/drivers/video/fbdev/hitfb.c
> index 97db325df2b4..29708c2d506d 100644
> --- a/drivers/video/fbdev/hitfb.c
> +++ b/drivers/video/fbdev/hitfb.c
> @@ -495,8 +495,10 @@ static int __init hitfb_init(void)
> ret = platform_driver_register(&hitfb_driver);
> if (!ret) {
> ret = platform_device_register(&hitfb_device);
> - if (ret)
> + if (ret) {
> + platform_device_put(&hitfb_device);
> platform_driver_unregister(&hitfb_driver);
> + }
> }
> return ret;
> }
> --
> 2.43.0
>
After re-checking it, hitfb_device is a static platform_device and it does
not provide a dev.release callback. Therefore calling
platform_device_put() on the platform_device_register() failure path is
not appropriate here and can trigger the missing release callback
warning.
This falls into the same static platform_device pattern pointed out in
the other reviews, so I will drop this patch.
Sorry for the noise.
Best regards,
Guangshuo Li
^ permalink raw reply
* Re: [PATCH] fbdev: q40fb: fix reference leak on failed device registration
From: Guangshuo Li @ 2026-04-24 9:04 UTC (permalink / raw)
To: Helge Deller, Guangshuo Li, linux-fbdev, dri-devel, linux-kernel; +Cc: stable
In-Reply-To: <20260415191306.3837839-1-lgs201920130244@gmail.com>
Hi,
Please disregard this patch.
On Thu, 16 Apr 2026 at 03:13, Guangshuo Li <lgs201920130244@gmail.com> wrote:
>
> When platform_device_register() fails in q40fb_init(), the embedded
> struct device in q40fb_device has already been initialized by
> device_initialize(), but the failure path only unregisters the platform
> driver and does not drop the device reference for the current platform
> device:
>
> q40fb_init()
> -> platform_device_register(&q40fb_device)
> -> device_initialize(&q40fb_device.dev)
> -> setup_pdev_dma_masks(&q40fb_device)
> -> platform_device_add(&q40fb_device)
>
> This leads to a reference leak when platform_device_register() fails.
> Fix this by calling platform_device_put() before unregistering the
> platform driver.
>
> The issue was identified by a static analysis tool I developed and
> confirmed by manual review.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
> ---
> drivers/video/fbdev/q40fb.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/q40fb.c b/drivers/video/fbdev/q40fb.c
> index 1ff8fa176124..0151a41267b3 100644
> --- a/drivers/video/fbdev/q40fb.c
> +++ b/drivers/video/fbdev/q40fb.c
> @@ -141,8 +141,10 @@ static int __init q40fb_init(void)
>
> if (!ret) {
> ret = platform_device_register(&q40fb_device);
> - if (ret)
> + if (ret) {
> + platform_device_put(&q40fb_device);
> platform_driver_unregister(&q40fb_driver);
> + }
> }
> return ret;
> }
> --
> 2.43.0
>
After re-checking it, q40fb_device is a static platform_device and it does
not provide a dev.release callback. Therefore calling
platform_device_put() on the platform_device_register() failure path is
not appropriate here and can trigger the missing release callback
warning.
This falls into the same static platform_device pattern pointed out in
the other reviews, so I will drop this patch.
Sorry for the noise.
Best regards,
Guangshuo Li
^ permalink raw reply
* [PATCH] staging: fbtft: fbtft-bus: replace function-defining macro with concrete functions
From: Alexandru Hossu @ 2026-04-24 9:28 UTC (permalink / raw)
To: andy, gregkh
Cc: dri-devel, linux-fbdev, linux-staging, linux-kernel,
Alexandru Hossu
The define_fbtft_write_reg macro defines full function bodies including
a goto statement and a trailing semicolon on EXPORT_SYMBOL(), which
violates kernel coding style (checkpatch reports 2 ERRORs, 2 WARNINGs,
and 5 CHECKs).
Replace it with three concrete C functions that are semantically
identical to the macro expansions:
- fbtft_write_reg8_bus8 (u8 buffer, u8 data)
- fbtft_write_reg16_bus8 (__be16 buffer, u16 data, cpu_to_be16)
- fbtft_write_reg16_bus16 (u16 buffer, u16 data)
The function declarations in fbtft.h are already present and unchanged.
Signed-off-by: Alexandru Hossu <hossu.alexandru@gmail.com>
---
drivers/staging/fbtft/fbtft-bus.c | 191 +++++++++++++++++++++---------
1 file changed, 137 insertions(+), 54 deletions(-)
diff --git a/drivers/staging/fbtft/fbtft-bus.c b/drivers/staging/fbtft/fbtft-bus.c
index 30e436ff1..acd035203 100644
--- a/drivers/staging/fbtft/fbtft-bus.c
+++ b/drivers/staging/fbtft/fbtft-bus.c
@@ -11,60 +11,143 @@
*
*****************************************************************************/
-#define define_fbtft_write_reg(func, buffer_type, data_type, modifier) \
-void func(struct fbtft_par *par, int len, ...) \
-{ \
- va_list args; \
- int i, ret; \
- int offset = 0; \
- buffer_type *buf = (buffer_type *)par->buf; \
- \
- if (unlikely(par->debug & DEBUG_WRITE_REGISTER)) { \
- va_start(args, len); \
- for (i = 0; i < len; i++) { \
- buf[i] = modifier((data_type)va_arg(args, \
- unsigned int)); \
- } \
- va_end(args); \
- fbtft_par_dbg_hex(DEBUG_WRITE_REGISTER, par, \
- par->info->device, buffer_type, buf, len, \
- "%s: ", __func__); \
- } \
- \
- va_start(args, len); \
- \
- if (par->startbyte) { \
- *(u8 *)par->buf = par->startbyte; \
- buf = (buffer_type *)(par->buf + 1); \
- offset = 1; \
- } \
- \
- *buf = modifier((data_type)va_arg(args, unsigned int)); \
- ret = fbtft_write_buf_dc(par, par->buf, sizeof(data_type) + offset, \
- 0); \
- if (ret < 0) \
- goto out; \
- len--; \
- \
- if (par->startbyte) \
- *(u8 *)par->buf = par->startbyte | 0x2; \
- \
- if (len) { \
- i = len; \
- while (i--) \
- *buf++ = modifier((data_type)va_arg(args, \
- unsigned int)); \
- fbtft_write_buf_dc(par, par->buf, \
- len * (sizeof(data_type) + offset), 1); \
- } \
-out: \
- va_end(args); \
-} \
-EXPORT_SYMBOL(func);
-
-define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8, )
-define_fbtft_write_reg(fbtft_write_reg16_bus8, __be16, u16, cpu_to_be16)
-define_fbtft_write_reg(fbtft_write_reg16_bus16, u16, u16, )
+void fbtft_write_reg8_bus8(struct fbtft_par *par, int len, ...)
+{
+ va_list args;
+ int i, ret;
+ int offset = 0;
+ u8 *buf = (u8 *)par->buf;
+
+ if (unlikely(par->debug & DEBUG_WRITE_REGISTER)) {
+ va_start(args, len);
+ for (i = 0; i < len; i++)
+ buf[i] = (u8)va_arg(args, unsigned int);
+ va_end(args);
+ fbtft_par_dbg_hex(DEBUG_WRITE_REGISTER, par,
+ par->info->device, u8, buf, len,
+ "%s: ", __func__);
+ }
+
+ va_start(args, len);
+
+ if (par->startbyte) {
+ *(u8 *)par->buf = par->startbyte;
+ buf = (u8 *)(par->buf + 1);
+ offset = 1;
+ }
+
+ *buf = (u8)va_arg(args, unsigned int);
+ ret = fbtft_write_buf_dc(par, par->buf, sizeof(u8) + offset, 0);
+ if (ret < 0)
+ goto out;
+ len--;
+
+ if (par->startbyte)
+ *(u8 *)par->buf = par->startbyte | 0x2;
+
+ if (len) {
+ i = len;
+ while (i--)
+ *buf++ = (u8)va_arg(args, unsigned int);
+ fbtft_write_buf_dc(par, par->buf,
+ len * (sizeof(u8) + offset), 1);
+ }
+out:
+ va_end(args);
+}
+EXPORT_SYMBOL(fbtft_write_reg8_bus8);
+
+void fbtft_write_reg16_bus8(struct fbtft_par *par, int len, ...)
+{
+ va_list args;
+ int i, ret;
+ int offset = 0;
+ __be16 *buf = (__be16 *)par->buf;
+
+ if (unlikely(par->debug & DEBUG_WRITE_REGISTER)) {
+ va_start(args, len);
+ for (i = 0; i < len; i++)
+ buf[i] = cpu_to_be16((u16)va_arg(args, unsigned int));
+ va_end(args);
+ fbtft_par_dbg_hex(DEBUG_WRITE_REGISTER, par,
+ par->info->device, __be16, buf, len,
+ "%s: ", __func__);
+ }
+
+ va_start(args, len);
+
+ if (par->startbyte) {
+ *(u8 *)par->buf = par->startbyte;
+ buf = (__be16 *)(par->buf + 1);
+ offset = 1;
+ }
+
+ *buf = cpu_to_be16((u16)va_arg(args, unsigned int));
+ ret = fbtft_write_buf_dc(par, par->buf, sizeof(u16) + offset, 0);
+ if (ret < 0)
+ goto out;
+ len--;
+
+ if (par->startbyte)
+ *(u8 *)par->buf = par->startbyte | 0x2;
+
+ if (len) {
+ i = len;
+ while (i--)
+ *buf++ = cpu_to_be16((u16)va_arg(args, unsigned int));
+ fbtft_write_buf_dc(par, par->buf,
+ len * (sizeof(u16) + offset), 1);
+ }
+out:
+ va_end(args);
+}
+EXPORT_SYMBOL(fbtft_write_reg16_bus8);
+
+void fbtft_write_reg16_bus16(struct fbtft_par *par, int len, ...)
+{
+ va_list args;
+ int i, ret;
+ int offset = 0;
+ u16 *buf = (u16 *)par->buf;
+
+ if (unlikely(par->debug & DEBUG_WRITE_REGISTER)) {
+ va_start(args, len);
+ for (i = 0; i < len; i++)
+ buf[i] = (u16)va_arg(args, unsigned int);
+ va_end(args);
+ fbtft_par_dbg_hex(DEBUG_WRITE_REGISTER, par,
+ par->info->device, u16, buf, len,
+ "%s: ", __func__);
+ }
+
+ va_start(args, len);
+
+ if (par->startbyte) {
+ *(u8 *)par->buf = par->startbyte;
+ buf = (u16 *)(par->buf + 1);
+ offset = 1;
+ }
+
+ *buf = (u16)va_arg(args, unsigned int);
+ ret = fbtft_write_buf_dc(par, par->buf, sizeof(u16) + offset, 0);
+ if (ret < 0)
+ goto out;
+ len--;
+
+ if (par->startbyte)
+ *(u8 *)par->buf = par->startbyte | 0x2;
+
+ if (len) {
+ i = len;
+ while (i--)
+ *buf++ = (u16)va_arg(args, unsigned int);
+ fbtft_write_buf_dc(par, par->buf,
+ len * (sizeof(u16) + offset), 1);
+ }
+out:
+ va_end(args);
+}
+EXPORT_SYMBOL(fbtft_write_reg16_bus16);
void fbtft_write_reg8_bus9(struct fbtft_par *par, int len, ...)
{
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] staging: fbtft: fbtft-bus: replace function-defining macro with concrete functions
From: Andy Shevchenko @ 2026-04-24 9:38 UTC (permalink / raw)
To: Alexandru Hossu
Cc: andy, gregkh, dri-devel, linux-fbdev, linux-staging, linux-kernel
In-Reply-To: <20260424092818.3322248-1-hossu.alexandru@gmail.com>
On Fri, Apr 24, 2026 at 11:28:18AM +0200, Alexandru Hossu wrote:
> The define_fbtft_write_reg macro defines full function bodies including
> a goto statement and a trailing semicolon on EXPORT_SYMBOL(), which
> violates kernel coding style (checkpatch reports 2 ERRORs, 2 WARNINGs,
> and 5 CHECKs).
OK.
> Replace it with three concrete C functions that are semantically
> identical to the macro expansions:
> - fbtft_write_reg8_bus8 (u8 buffer, u8 data)
> - fbtft_write_reg16_bus8 (__be16 buffer, u16 data, cpu_to_be16)
> - fbtft_write_reg16_bus16 (u16 buffer, u16 data)
>
> The function declarations in fbtft.h are already present and unchanged.
I'm not sure this patch improves the code. What I see it's harder to follow.
NAK.
You can consider different approach(es), using _Generic() or so, but I forecast
that none of them will be better than the current code.
You also can address just a small chunk of that, exempli gratia, moving out
EXPORT_*() along with some wrappers leaving the main body of the macro
untouched. This might be a compromise. Dunno. If Greg has no objections, you
can try it out.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] staging: fbtft: fbtft-bus: replace function-defining macro with concrete functions
From: Alexandru Hossu @ 2026-04-24 9:40 UTC (permalink / raw)
To: Andy Shevchenko
Cc: andy, gregkh, dri-devel, linux-fbdev, linux-staging, linux-kernel
In-Reply-To: <aes6JY3Ht6p1VpFa@ashevche-desk.local>
On Fri, Apr 24, 2026 at 12:38:45PM +0300, Andy Shevchenko wrote:
> I'm not sure this patch improves the code. What I see it's harder to follow.
> NAK.
Fair point. Three near-identical functions hide the pattern the macro
makes explicit. I'll drop this approach.
If there's appetite for a minimal fix, I can send a v2 that moves
EXPORT_SYMBOL() outside the macro body only, leaving the function
definition untouched. Otherwise I'll leave it as-is and wait for
Greg's take.
Thanks for the quick review.
Alexandru
^ permalink raw reply
* Re: [PATCH] staging: fbtft: fbtft-bus: replace function-defining macro with concrete functions
From: Andy Shevchenko @ 2026-04-24 9:47 UTC (permalink / raw)
To: Alexandru Hossu
Cc: andy, gregkh, dri-devel, linux-fbdev, linux-staging, linux-kernel
In-Reply-To: <69eb3b01.5d0a0220.3c3ebd.f35b@mx.google.com>
On Fri, Apr 24, 2026 at 09:40:48AM -0000, Alexandru Hossu wrote:
> On Fri, Apr 24, 2026 at 12:38:45PM +0300, Andy Shevchenko wrote:
> > I'm not sure this patch improves the code. What I see it's harder to follow.
> > NAK.
>
> Fair point. Three near-identical functions hide the pattern the macro
> makes explicit. I'll drop this approach.
>
> If there's appetite for a minimal fix, I can send a v2 that moves
> EXPORT_SYMBOL() outside the macro body only, leaving the function
> definition untouched. Otherwise I'll leave it as-is and wait for
> Greg's take.
You can try that, as I said it would be a compromise because at least I agree
with the awkwardness of having EXPORT_*() be hidden by the macro.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] staging: fbtft: fbtft-bus: replace function-defining macro with concrete functions
From: Greg KH @ 2026-04-24 9:49 UTC (permalink / raw)
To: Alexandru Hossu
Cc: Andy Shevchenko, andy, dri-devel, linux-fbdev, linux-staging,
linux-kernel
In-Reply-To: <69eb3b01.5d0a0220.3c3ebd.f35b@mx.google.com>
On Fri, Apr 24, 2026 at 09:40:48AM -0000, Alexandru Hossu wrote:
> On Fri, Apr 24, 2026 at 12:38:45PM +0300, Andy Shevchenko wrote:
> > I'm not sure this patch improves the code. What I see it's harder to follow.
> > NAK.
>
> Fair point. Three near-identical functions hide the pattern the macro
> makes explicit. I'll drop this approach.
>
> If there's appetite for a minimal fix, I can send a v2 that moves
> EXPORT_SYMBOL() outside the macro body only, leaving the function
> definition untouched. Otherwise I'll leave it as-is and wait for
> Greg's take.
Please leave as-is, there's nothing wrong with the existing code here.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 3/8] firmware: sysfb: Make CONFIG_SYSFB a user-selectable option
From: Javier Martinez Canillas @ 2026-04-24 16:24 UTC (permalink / raw)
To: Thomas Zimmermann, Arnd Bergmann, Ard Biesheuvel,
Ilias Apalodimas, Huacai Chen, WANG Xuerui, Maarten Lankhorst,
Maxime Ripard, Dave Airlie, Simona Vetter, K. Y. Srinivasan,
Haiyang Zhang, Wei Liu, Dexuan Cui, longli, Helge Deller
Cc: linux-arm-kernel, loongarch, linux-efi, linux-riscv, dri-devel,
linux-hyperv, linux-fbdev
In-Reply-To: <0156562f-5fcf-47ce-8fea-03345f2c3fe6@suse.de>
Thomas Zimmermann <tzimmermann@suse.de> writes:
Hello,
[...]
>>>>>> On Thu, Apr 2, 2026, at 11:09, Thomas Zimmermann wrote:
>>>>>> I don't really like this part of the series and would prefer
>>>>>> to keep CONFIG_SYSFB hidden as much as possible as an x86
I tend to agree with Arnd here, I'm also not seeing that much value on
making this symbol user selectable. For now I would just keep it hidden.
[...]
>> Yes, I saw that as well and don't have an immediate idea for how
>> to best do it. I saw that you already abstracted the access to
>> the screen_info members in drm_sysfb_screen_info.c, which I think
>> is a step in that direction.
>>
>> I also noticed that efidrm is mostly a subset of vesadrm, so
>> in theory they could be merged back into an x86 drm driver
>> along with the drm_sysfb_screen_info helpers, and have a non-x86
>> driver that constructs a drm_sysfb_device directly from the
>> EFI structures.
>
> I would not want to have a unifed driver for all-things-screen_info. The
> code that can easily be shared is already in the sysfb helpers. But I
> don't mind adding a separate driver for EFI's Graphics Output Protocol.
I agree. It is much more maintainable if we have dedicated DRM drivers that
use shared helpers, than attempting to have a driver for different platforms.
As Thomas explained, the maintance effort is small on the DRM side and he has
done a lot of work to split simpledrm in efidrm, vesadrm and ofdrm.
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply
* [PATCH 01/35] fbdev: matroxfb: Use safer strscpy() instead of strcpy()
From: Ai Chao @ 2026-04-25 6:58 UTC (permalink / raw)
To: deller, nicolas.ferre, alexandre.belloni, claudiu.beznea, linux,
dilinger, adaplas, James.Bottomley, FlorianSchandinat, alchark,
krzk, kees, rene, tzimmermann, rongqianfeng, thorsten.blum,
chelsyratnawat2001, soci, gregkh, daniel, linmq006,
fourier.thomas
Cc: linux-fbdev, dri-devel, linux-kernel, linux-arm-kernel,
linux-geode, linux-parisc, Ai Chao
In-Reply-To: <20260425065926.1091168-1-aichao@kylinos.cn>
Use a safer function strscpy() instead of strcpy() for copying to arrays.
Only idiomatic code replacement, and no functional changes.
Signed-off-by: Ai Chao <aichao@kylinos.cn>
---
drivers/video/fbdev/matrox/matroxfb_base.c | 6 +++---
drivers/video/fbdev/matrox/matroxfb_crtc2.c | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/video/fbdev/matrox/matroxfb_base.c b/drivers/video/fbdev/matrox/matroxfb_base.c
index e1a4bc7c2318..bd786543478c 100644
--- a/drivers/video/fbdev/matrox/matroxfb_base.c
+++ b/drivers/video/fbdev/matrox/matroxfb_base.c
@@ -709,7 +709,7 @@ static void matroxfb_init_fix(struct matrox_fb_info *minfo)
struct fb_fix_screeninfo *fix = &minfo->fbcon.fix;
DBG(__func__)
- strcpy(fix->id,"MATROX");
+ strscpy(fix->id, "MATROX");
fix->xpanstep = 8; /* 8 for 8bpp, 4 for 16bpp, 2 for 32bpp */
fix->ypanstep = 1;
@@ -1091,8 +1091,8 @@ static int matroxfb_ioctl(struct fb_info *info,
struct v4l2_capability r;
memset(&r, 0, sizeof(r));
- strcpy(r.driver, "matroxfb");
- strcpy(r.card, "Matrox");
+ strscpy(r.driver, "matroxfb");
+ strscpy(r.card, "Matrox");
sprintf(r.bus_info, "PCI:%s", pci_name(minfo->pcidev));
r.version = KERNEL_VERSION(1,0,0);
r.capabilities = V4L2_CAP_VIDEO_OUTPUT;
diff --git a/drivers/video/fbdev/matrox/matroxfb_crtc2.c b/drivers/video/fbdev/matrox/matroxfb_crtc2.c
index 8de882b09a24..c20dd06c5fcd 100644
--- a/drivers/video/fbdev/matrox/matroxfb_crtc2.c
+++ b/drivers/video/fbdev/matrox/matroxfb_crtc2.c
@@ -299,7 +299,7 @@ static void matroxfb_dh_init_fix(struct matroxfb_dh_fb_info *m2info)
{
struct fb_fix_screeninfo *fix = &m2info->fbcon.fix;
- strcpy(fix->id, "MATROX DH");
+ strscpy(fix->id, "MATROX DH");
fix->smem_start = m2info->video.base;
fix->smem_len = m2info->video.len_usable;
--
2.34.1
^ permalink raw reply related
* [PATCH 02/35] fbdev: i810: Use safer strscpy() instead of strcpy()
From: Ai Chao @ 2026-04-25 6:58 UTC (permalink / raw)
To: deller, nicolas.ferre, alexandre.belloni, claudiu.beznea, linux,
dilinger, adaplas, James.Bottomley, FlorianSchandinat, alchark,
krzk, kees, rene, tzimmermann, rongqianfeng, thorsten.blum,
chelsyratnawat2001, soci, gregkh, daniel, linmq006,
fourier.thomas
Cc: linux-fbdev, dri-devel, linux-kernel, linux-arm-kernel,
linux-geode, linux-parisc, Ai Chao
In-Reply-To: <20260425065926.1091168-1-aichao@kylinos.cn>
Use a safer function strscpy() instead of strcpy() for copying to arrays.
Only idiomatic code replacement, and no functional changes.
Signed-off-by: Ai Chao <aichao@kylinos.cn>
---
drivers/video/fbdev/i810/i810-i2c.c | 2 +-
drivers/video/fbdev/i810/i810_main.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/i810/i810-i2c.c b/drivers/video/fbdev/i810/i810-i2c.c
index 7db17d0d8a8c..6141e9d2fff4 100644
--- a/drivers/video/fbdev/i810/i810-i2c.c
+++ b/drivers/video/fbdev/i810/i810-i2c.c
@@ -91,7 +91,7 @@ static int i810_setup_i2c_bus(struct i810fb_i2c_chan *chan, const char *name)
{
int rc;
- strcpy(chan->adapter.name, name);
+ strscpy(chan->adapter.name, name);
chan->adapter.owner = THIS_MODULE;
chan->adapter.algo_data = &chan->algo;
chan->adapter.dev.parent = &chan->par->dev->dev;
diff --git a/drivers/video/fbdev/i810/i810_main.c b/drivers/video/fbdev/i810/i810_main.c
index 10b914a24114..0499058a3ea8 100644
--- a/drivers/video/fbdev/i810/i810_main.c
+++ b/drivers/video/fbdev/i810/i810_main.c
@@ -1091,7 +1091,7 @@ static int encode_fix(struct fb_fix_screeninfo *fix, struct fb_info *info)
memset(fix, 0, sizeof(struct fb_fix_screeninfo));
- strcpy(fix->id, "I810");
+ strscpy(fix->id, "I810");
mutex_lock(&info->mm_lock);
fix->smem_start = par->fb.physical;
fix->smem_len = par->fb.size;
--
2.34.1
^ permalink raw reply related
* [PATCH 04/35] fbdev: geode: Use safer strscpy() instead of strcpy()
From: Ai Chao @ 2026-04-25 6:58 UTC (permalink / raw)
To: deller, nicolas.ferre, alexandre.belloni, claudiu.beznea, linux,
dilinger, adaplas, James.Bottomley, FlorianSchandinat, alchark,
krzk, kees, rene, tzimmermann, rongqianfeng, thorsten.blum,
chelsyratnawat2001, soci, gregkh, daniel, linmq006,
fourier.thomas
Cc: linux-fbdev, dri-devel, linux-kernel, linux-arm-kernel,
linux-geode, linux-parisc, Ai Chao
In-Reply-To: <20260425065926.1091168-1-aichao@kylinos.cn>
Use a safer function strscpy() instead of strcpy() for copying to arrays.
Only idiomatic code replacement, and no functional changes.
Signed-off-by: Ai Chao <aichao@kylinos.cn>
---
drivers/video/fbdev/geode/gx1fb_core.c | 2 +-
drivers/video/fbdev/geode/gxfb_core.c | 2 +-
drivers/video/fbdev/geode/lxfb_core.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/geode/gx1fb_core.c b/drivers/video/fbdev/geode/gx1fb_core.c
index a1919c1934ac..c5a6e3038b98 100644
--- a/drivers/video/fbdev/geode/gx1fb_core.c
+++ b/drivers/video/fbdev/geode/gx1fb_core.c
@@ -274,7 +274,7 @@ static struct fb_info *gx1fb_init_fbinfo(struct device *dev)
par = info->par;
- strcpy(info->fix.id, "GX1");
+ strscpy(info->fix.id, "GX1");
info->fix.type = FB_TYPE_PACKED_PIXELS;
info->fix.type_aux = 0;
diff --git a/drivers/video/fbdev/geode/gxfb_core.c b/drivers/video/fbdev/geode/gxfb_core.c
index 8d69be7c9d31..fe987829315b 100644
--- a/drivers/video/fbdev/geode/gxfb_core.c
+++ b/drivers/video/fbdev/geode/gxfb_core.c
@@ -289,7 +289,7 @@ static struct fb_info *gxfb_init_fbinfo(struct device *dev)
par = info->par;
- strcpy(info->fix.id, "Geode GX");
+ strscpy(info->fix.id, "Geode GX");
info->fix.type = FB_TYPE_PACKED_PIXELS;
info->fix.type_aux = 0;
diff --git a/drivers/video/fbdev/geode/lxfb_core.c b/drivers/video/fbdev/geode/lxfb_core.c
index cad99f5b7fe8..3ae37ec9f151 100644
--- a/drivers/video/fbdev/geode/lxfb_core.c
+++ b/drivers/video/fbdev/geode/lxfb_core.c
@@ -412,7 +412,7 @@ static struct fb_info *lxfb_init_fbinfo(struct device *dev)
par = info->par;
- strcpy(info->fix.id, "Geode LX");
+ strscpy(info->fix.id, "Geode LX");
info->fix.type = FB_TYPE_PACKED_PIXELS;
info->fix.type_aux = 0;
--
2.34.1
^ permalink raw reply related
* [PATCH 03/35] fbdev: sisfb: Use safer strscpy() instead of strcpy()
From: Ai Chao @ 2026-04-25 6:58 UTC (permalink / raw)
To: deller, nicolas.ferre, alexandre.belloni, claudiu.beznea, linux,
dilinger, adaplas, James.Bottomley, FlorianSchandinat, alchark,
krzk, kees, rene, tzimmermann, rongqianfeng, thorsten.blum,
chelsyratnawat2001, soci, gregkh, daniel, linmq006,
fourier.thomas
Cc: linux-fbdev, dri-devel, linux-kernel, linux-arm-kernel,
linux-geode, linux-parisc, Ai Chao
In-Reply-To: <20260425065926.1091168-1-aichao@kylinos.cn>
Use a safer function strscpy() instead of strcpy() for copying to arrays.
Only idiomatic code replacement, and no functional changes.
Signed-off-by: Ai Chao <aichao@kylinos.cn>
---
drivers/video/fbdev/sis/sis_main.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/video/fbdev/sis/sis_main.c b/drivers/video/fbdev/sis/sis_main.c
index 84567d67f71d..e87fa261f76c 100644
--- a/drivers/video/fbdev/sis/sis_main.c
+++ b/drivers/video/fbdev/sis/sis_main.c
@@ -205,7 +205,7 @@ static void sisfb_search_mode(char *name, bool quiet)
}
if(strlen(name) <= 19) {
- strcpy(strbuf1, name);
+ strscpy(strbuf1, name);
for(i = 0; i < strlen(strbuf1); i++) {
if(strbuf1[i] < '0' || strbuf1[i] > '9') strbuf1[i] = ' ';
}
@@ -5947,33 +5947,33 @@ static int sisfb_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
#ifdef CONFIG_FB_SIS_300
case PCI_DEVICE_ID_SI_730:
ivideo->chip = SIS_730;
- strcpy(ivideo->myid, "SiS 730");
+ strscpy(ivideo->myid, "SiS 730");
break;
#endif
#ifdef CONFIG_FB_SIS_315
case PCI_DEVICE_ID_SI_651:
/* ivideo->chip is ok */
- strcpy(ivideo->myid, "SiS 651");
+ strscpy(ivideo->myid, "SiS 651");
break;
case PCI_DEVICE_ID_SI_740:
ivideo->chip = SIS_740;
- strcpy(ivideo->myid, "SiS 740");
+ strscpy(ivideo->myid, "SiS 740");
break;
case PCI_DEVICE_ID_SI_661:
ivideo->chip = SIS_661;
- strcpy(ivideo->myid, "SiS 661");
+ strscpy(ivideo->myid, "SiS 661");
break;
case PCI_DEVICE_ID_SI_741:
ivideo->chip = SIS_741;
- strcpy(ivideo->myid, "SiS 741");
+ strscpy(ivideo->myid, "SiS 741");
break;
case PCI_DEVICE_ID_SI_760:
ivideo->chip = SIS_760;
- strcpy(ivideo->myid, "SiS 760");
+ strscpy(ivideo->myid, "SiS 760");
break;
case PCI_DEVICE_ID_SI_761:
ivideo->chip = SIS_761;
- strcpy(ivideo->myid, "SiS 761");
+ strscpy(ivideo->myid, "SiS 761");
break;
#endif
default:
--
2.34.1
^ permalink raw reply related
* [PATCH 05/35] fbdev: atafb: Use safer strscpy() instead of strcpy()
From: Ai Chao @ 2026-04-25 6:58 UTC (permalink / raw)
To: deller, nicolas.ferre, alexandre.belloni, claudiu.beznea, linux,
dilinger, adaplas, James.Bottomley, FlorianSchandinat, alchark,
krzk, kees, rene, tzimmermann, rongqianfeng, thorsten.blum,
chelsyratnawat2001, soci, gregkh, daniel, linmq006,
fourier.thomas
Cc: linux-fbdev, dri-devel, linux-kernel, linux-arm-kernel,
linux-geode, linux-parisc, Ai Chao
In-Reply-To: <20260425065926.1091168-1-aichao@kylinos.cn>
Use a safer function strscpy() instead of strcpy() for copying to arrays.
Only idiomatic code replacement, and no functional changes.
Signed-off-by: Ai Chao <aichao@kylinos.cn>
---
drivers/video/fbdev/atafb.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/video/fbdev/atafb.c b/drivers/video/fbdev/atafb.c
index b8ed1c537293..5f2d50919718 100644
--- a/drivers/video/fbdev/atafb.c
+++ b/drivers/video/fbdev/atafb.c
@@ -555,7 +555,7 @@ static int tt_encode_fix(struct fb_fix_screeninfo *fix, struct atafb_par *par)
{
int mode;
- strcpy(fix->id, "Atari Builtin");
+ strscpy(fix->id, "Atari Builtin");
fix->smem_start = phys_screen_base;
fix->smem_len = screen_len;
fix->type = FB_TYPE_INTERLEAVED_PLANES;
@@ -851,7 +851,7 @@ static inline int hxx_prescale(struct falcon_hw *hw)
static int falcon_encode_fix(struct fb_fix_screeninfo *fix,
struct atafb_par *par)
{
- strcpy(fix->id, "Atari Builtin");
+ strscpy(fix->id, "Atari Builtin");
fix->smem_start = phys_screen_base;
fix->smem_len = screen_len;
fix->type = FB_TYPE_INTERLEAVED_PLANES;
@@ -1770,7 +1770,7 @@ static int stste_encode_fix(struct fb_fix_screeninfo *fix,
{
int mode;
- strcpy(fix->id, "Atari Builtin");
+ strscpy(fix->id, "Atari Builtin");
fix->smem_start = phys_screen_base;
fix->smem_len = screen_len;
fix->type = FB_TYPE_INTERLEAVED_PLANES;
@@ -2069,7 +2069,7 @@ static void st_ovsc_switch(void)
static int ext_encode_fix(struct fb_fix_screeninfo *fix, struct atafb_par *par)
{
- strcpy(fix->id, "Unknown Extern");
+ strscpy(fix->id, "Unknown Extern");
fix->smem_start = external_addr;
fix->smem_len = PAGE_ALIGN(external_len);
if (external_depth == 1) {
@@ -3100,7 +3100,7 @@ static int __init atafb_probe(struct platform_device *pdev)
}
#endif /* ATAFB_EXT */
-// strcpy(fb_info.mode->name, "Atari Builtin ");
+// strscpy(fb_info.mode->name, "Atari Builtin ");
fb_info.fbops = &atafb_ops;
// try to set default (detected; requested) var
do_fb_set_var(&atafb_predefined[default_par - 1], 1);
--
2.34.1
^ permalink raw reply related
* [PATCH 06/35] fbdev: tdfxfb: Use safer strscpy() instead of strcpy()
From: Ai Chao @ 2026-04-25 6:58 UTC (permalink / raw)
To: deller, nicolas.ferre, alexandre.belloni, claudiu.beznea, linux,
dilinger, adaplas, James.Bottomley, FlorianSchandinat, alchark,
krzk, kees, rene, tzimmermann, rongqianfeng, thorsten.blum,
chelsyratnawat2001, soci, gregkh, daniel, linmq006,
fourier.thomas
Cc: linux-fbdev, dri-devel, linux-kernel, linux-arm-kernel,
linux-geode, linux-parisc, Ai Chao
In-Reply-To: <20260425065926.1091168-1-aichao@kylinos.cn>
Use a safer function strscpy() instead of strcpy() for copying to arrays.
Only idiomatic code replacement, and no functional changes.
Signed-off-by: Ai Chao <aichao@kylinos.cn>
---
drivers/video/fbdev/tdfxfb.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/tdfxfb.c b/drivers/video/fbdev/tdfxfb.c
index 4c4e53aaea3a..b7cc2b1012eb 100644
--- a/drivers/video/fbdev/tdfxfb.c
+++ b/drivers/video/fbdev/tdfxfb.c
@@ -1401,15 +1401,15 @@ static int tdfxfb_probe(struct pci_dev *pdev, const struct pci_device_id *id)
/* Configure the default fb_fix_screeninfo first */
switch (pdev->device) {
case PCI_DEVICE_ID_3DFX_BANSHEE:
- strcpy(info->fix.id, "3Dfx Banshee");
+ strscpy(info->fix.id, "3Dfx Banshee");
default_par->max_pixclock = BANSHEE_MAX_PIXCLOCK;
break;
case PCI_DEVICE_ID_3DFX_VOODOO3:
- strcpy(info->fix.id, "3Dfx Voodoo3");
+ strscpy(info->fix.id, "3Dfx Voodoo3");
default_par->max_pixclock = VOODOO3_MAX_PIXCLOCK;
break;
case PCI_DEVICE_ID_3DFX_VOODOO5:
- strcpy(info->fix.id, "3Dfx Voodoo5");
+ strscpy(info->fix.id, "3Dfx Voodoo5");
default_par->max_pixclock = VOODOO5_MAX_PIXCLOCK;
break;
}
--
2.34.1
^ permalink raw reply related
* [PATCH 07/35] fbdev: pm2fb: Use safer strscpy() instead of strcpy()
From: Ai Chao @ 2026-04-25 6:58 UTC (permalink / raw)
To: deller, nicolas.ferre, alexandre.belloni, claudiu.beznea, linux,
dilinger, adaplas, James.Bottomley, FlorianSchandinat, alchark,
krzk, kees, rene, tzimmermann, rongqianfeng, thorsten.blum,
chelsyratnawat2001, soci, gregkh, daniel, linmq006,
fourier.thomas
Cc: linux-fbdev, dri-devel, linux-kernel, linux-arm-kernel,
linux-geode, linux-parisc, Ai Chao
In-Reply-To: <20260425065926.1091168-1-aichao@kylinos.cn>
Use a safer function strscpy() instead of strcpy() for copying to arrays.
Only idiomatic code replacement, and no functional changes.
Signed-off-by: Ai Chao <aichao@kylinos.cn>
---
drivers/video/fbdev/pm2fb.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/pm2fb.c b/drivers/video/fbdev/pm2fb.c
index f34429829b7d..ad1e4bc5fe6f 100644
--- a/drivers/video/fbdev/pm2fb.c
+++ b/drivers/video/fbdev/pm2fb.c
@@ -1543,15 +1543,15 @@ static int pm2fb_probe(struct pci_dev *pdev, const struct pci_device_id *id)
switch (pdev->device) {
case PCI_DEVICE_ID_TI_TVP4020:
- strcpy(pm2fb_fix.id, "TVP4020");
+ strscpy(pm2fb_fix.id, "TVP4020");
default_par->type = PM2_TYPE_PERMEDIA2;
break;
case PCI_DEVICE_ID_3DLABS_PERMEDIA2:
- strcpy(pm2fb_fix.id, "Permedia2");
+ strscpy(pm2fb_fix.id, "Permedia2");
default_par->type = PM2_TYPE_PERMEDIA2;
break;
case PCI_DEVICE_ID_3DLABS_PERMEDIA2V:
- strcpy(pm2fb_fix.id, "Permedia2v");
+ strscpy(pm2fb_fix.id, "Permedia2v");
default_par->type = PM2_TYPE_PERMEDIA2V;
break;
}
--
2.34.1
^ 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