* Re: [PATCH v11 02/20] gpu: nova-core: gsp: Extract usable FB region from GSP
From: David Airlie @ 2026-04-21 20:05 UTC (permalink / raw)
To: Joel Fernandes
Cc: John Hubbard, linux-kernel, Miguel Ojeda, Boqun Feng, Gary Guo,
Bjorn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Daniel Almeida, Koen Koning,
dri-devel, rust-for-linux, Nikola Djukic, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Alex Deucher, Christian Koenig, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin, Huang Rui,
Matthew Auld, Lucas De Marchi, Thomas Hellstrom, Helge Deller,
Alex Gaynor, Boqun Feng, 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: <20260421145521.GA51176@joelbox2>
On Wed, Apr 22, 2026 at 12:55 AM Joel Fernandes <joelagnelf@nvidia.com> wrote:
>
> On Thu, Apr 16, 2026 at 04:26:48PM -0700, John Hubbard wrote:
> > On 4/15/26 2:05 PM, Joel Fernandes wrote:
> > ...
> >
> > Apologies, I found one more minor thing, while looking at a
> > subsequent patch in this series:
> >
> > > impl MessageFromGsp for GetGspStaticInfoReply {
> > > const FUNCTION: MsgFunction = MsgFunction::GetGspStaticInfo;
> > > type Message = GspStaticConfigInfo;
> > > - type InitError = Infallible;
> > > + type InitError = Error;
> > >
> > > fn read(
> > > msg: &Self::Message,
> > > @@ -205,6 +209,7 @@ fn read(
> > > ) -> Result<Self, Self::InitError> {
> > > Ok(GetGspStaticInfoReply {
> > > gpu_name: msg.gpu_name_str(),
> > > + usable_fb_region: msg.first_usable_fb_region().ok_or(ENODEV)?,
> >
> > OK, failing out is correct here. But in addition, we should also
> > log this at dev_err!() level. This is rare, surprising, and actionable,
> > so perfect for that level of logging.
>
> Sure, that works for me. Will add it in for v12.
Just fyi when we get to spark later this will not matter, we will have
no usable_fb_region, though maybe it could just return 0s in that
case.
Dave.
^ permalink raw reply
* Re: [PATCH v11 02/20] gpu: nova-core: gsp: Extract usable FB region from GSP
From: John Hubbard @ 2026-04-21 21:41 UTC (permalink / raw)
To: David Airlie, Joel Fernandes
Cc: linux-kernel, Miguel Ojeda, Boqun Feng, Gary Guo, Bjorn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Daniel Almeida, Koen Koning, dri-devel,
rust-for-linux, Nikola Djukic, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Jonathan Corbet,
Alex Deucher, Christian Koenig, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Huang Rui, Matthew Auld,
Lucas De Marchi, Thomas Hellstrom, Helge Deller, Alex Gaynor,
Boqun Feng, 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: <CAMwc25o2qmaYnfsh-cW4M4PEbmpYb_1x4qg1_2155P0orzCnOQ@mail.gmail.com>
On 4/21/26 1:05 PM, David Airlie wrote:
...
>>>> + usable_fb_region: msg.first_usable_fb_region().ok_or(ENODEV)?,
>>>
>>> OK, failing out is correct here. But in addition, we should also
>>> log this at dev_err!() level. This is rare, surprising, and actionable,
>>> so perfect for that level of logging.
>>
>> Sure, that works for me. Will add it in for v12.
>
> Just fyi when we get to spark later this will not matter, we will have
> no usable_fb_region, though maybe it could just return 0s in that
> case.
>
Hi Dave,
The "no FB on this SKU" is a separate case, at least as I recall from
specifically looking into that during the patch review. We already have
cases like that (in Open RM) and those are not error cases.
This one here is a real error, though: "expected an FB and got nothing
useful".
thanks,
--
John Hubbard
^ permalink raw reply
* Re: [PATCH] video: fbdev: aty: Fix spelling mistake "enfore" -> "enforce"
From: Helge Deller @ 2026-04-22 13:57 UTC (permalink / raw)
To: Ethan Carter Edwards
Cc: linux-fbdev, dri-devel, linux-kernel, kernel-janitors
In-Reply-To: <20260418-radeon-typo-v1-1-8e075365089b@ethancedwards.com>
On 4/19/26 02:45, Ethan Carter Edwards wrote:
> There is a spelling mistake in a comment. Fix it.
>
> Signed-off-by: Ethan Carter Edwards <ethan@ethancedwards.com>
> ---
> drivers/video/fbdev/aty/radeon_monitor.c | 2 +-
applied.
Thanks!
Helge
^ permalink raw reply
* Re: [PATCH] fbdev: omapfb: fix reference leak on failed device registration
From: Helge Deller @ 2026-04-22 14:30 UTC (permalink / raw)
To: Guangshuo Li, Thomas Zimmermann, Kees Cook, Dan Carpenter,
Tomi Valkeinen, linux-fbdev, linux-omap, dri-devel, linux-kernel
In-Reply-To: <20260415191747.3845525-1-lgs201920130244@gmail.com>
Hello Guanghshuo,
On 4/15/26 21:17, Guangshuo Li wrote:
> When platform_device_register() fails in omapfb_probe(), the embedded
> struct device in omapdss_device has already been initialized by
> device_initialize(), but the failure path only reports the error and
> returns without dropping the device reference for the current platform
> device:
>
> omapfb_probe()
> -> platform_device_register(&omapdss_device)
> -> device_initialize(&omapdss_device.dev)
> -> setup_pdev_dma_masks(&omapdss_device)
> -> platform_device_add(&omapdss_device)
>
> This leads to a reference leak when platform_device_register() fails.
> Fix this by calling platform_device_put() before returning the error.
I see you submitted quite some patches, all about the same issue.
I did not yet fully checked if there is really a reference leak, but even if
it would be, I think it's wrong that all the callers in the whole Linux kernel source
would now need to use platform_device_put(). To me it then seems as if everyone got it wrong.
IMHO if platform_device_register() fails it should put the device itself before
returning.
Just looking at generic code, see platform_add_devices() in drivers/base/platform.c
which seem to have it wrong too then...
Helge
> The issue was identified by a static analysis tool I developed and
> confirmed by manual review.
>
> Fixes: f778a12dd3320 ("OMAP: OMAPFB: fix clk_get for RFBI")
> Cc: stable@vger.kernel.org
> Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
> ---
> drivers/video/fbdev/omap/omapfb_main.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/video/fbdev/omap/omapfb_main.c b/drivers/video/fbdev/omap/omapfb_main.c
> index cafe859d6e5a..0d47a8aec5c5 100644
> --- a/drivers/video/fbdev/omap/omapfb_main.c
> +++ b/drivers/video/fbdev/omap/omapfb_main.c
> @@ -1768,6 +1768,7 @@ static int omapfb_probe(struct platform_device *pdev)
> r = platform_device_register(&omapdss_device);
> if (r) {
> dev_err(&pdev->dev, "can't register omapdss device\n");
> + platform_device_put(&omapdss_device);
> return r;
> }
>
^ permalink raw reply
* Re: [PATCH 3/3] fbdev: goldfishfb: Request memory region
From: Helge Deller @ 2026-04-22 14:43 UTC (permalink / raw)
To: Amit Barzilai; +Cc: thomas.zimmermann, linux-fbdev, dri-devel
In-Reply-To: <20260420134424.77494-4-amit.barzilai22@gmail.com>
On 4/20/26 15:44, Amit Barzilai wrote:
> Use devm_ioremap_resource() instead of plain ioremap(). The helper
> requests the memory region before mapping it, which registers the range
> in /proc/iomem and prevents another driver from mapping the same
> registers. As it is device-managed, remove the corresponding iounmap()
> calls from the error unwind path and the remove function.
>
> Assisted-by: Claude:claude-sonnet-4-6
> ---
> drivers/video/fbdev/goldfishfb.c | 8 +++-----
> 1 file changed, 3 insertions(+), 5 deletions(-)
It was alreads fixed by another patch upstream...
Helge
^ permalink raw reply
* Re: [PATCH 1/3] fbdev: cobalt_lcdfb: Request memory region
From: Helge Deller @ 2026-04-22 14:50 UTC (permalink / raw)
To: Amit Barzilai; +Cc: thomas.zimmermann, linux-fbdev, dri-devel
In-Reply-To: <20260420134424.77494-2-amit.barzilai22@gmail.com>
Hi Amit,
On 4/20/26 15:44, Amit Barzilai wrote:
> Use devm_platform_get_and_ioremap_resource() instead of open-coding
> platform_get_resource() and devm_ioremap() separately. The helper
> requests the memory region before mapping it, which registers the range
> in /proc/iomem and prevents another driver from mapping the same
> registers.
>
> Assisted-by: Claude:claude-sonnet-4-6
You missed your signed-off line, which I added while applying patches #1 and #2:
Signed-off-by: Amit Barzilai <amit.barzilai22@gmail.com>
Amit, please confirm that you wrote patches #2 and #3 and that you
are OK with the added Signed-off-by line, otherwise I need to drop the patches.
Helge
> ---
> drivers/video/fbdev/cobalt_lcdfb.c | 12 +++---------
> 1 file changed, 3 insertions(+), 9 deletions(-)
^ permalink raw reply
* Re: [PATCH 1/3] fbdev: cobalt_lcdfb: Request memory region
From: Amit Barzilai @ 2026-04-22 15:29 UTC (permalink / raw)
To: deller; +Cc: amit.barzilai22, dri-devel, linux-fbdev, thomas.zimmermann
In-Reply-To: <404ec984-0486-442e-a108-4c5bad700248@gmx.de>
Hi Helge,
Yes, I wrote all three patches and I am OK with the added Signed-off-by line.
Sorry for the oversight, I'll make sure to include it in future submissions.
Thanks,
Amit
^ permalink raw reply
* 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
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