* [PATCH v3 1/2] staging: fbtft: fix potential memory leak in fbtft_framebuffer_alloc()
From: Abdun Nihaal @ 2025-06-29 14:40 UTC (permalink / raw)
To: andy
Cc: Abdun Nihaal, dan.carpenter, gregkh, lorenzo.stoakes, tzimmermann,
riyandhiman14, willy, notro, thomas.petazzoni, dri-devel,
linux-fbdev, linux-staging, linux-kernel
In-Reply-To: <cover.1751207100.git.abdun.nihaal@gmail.com>
After commit 56c134f7f1b5 ("fbdev: Track deferred-I/O pages in pageref
struct"), fb_deferred_io_init() allocates memory for info->pagerefs as
well as return an error code on failure. However the error code is
ignored here and the memory allocated could leak because of not calling
fb_deferred_io_cleanup() on the error path.
Fix them by adding the cleanup function on the error path, and handling
the error code returned by fb_deferred_io_init().
Fixes: 56c134f7f1b5 ("fbdev: Track deferred-I/O pages in pageref struct")
Signed-off-by: Abdun Nihaal <abdun.nihaal@gmail.com>
---
v2->v3: No change
v1->v2:
- Handle the error code returned by fb_deferred_io_init correctly
- Update Fixes tag to point to the commit that introduced the memory
allocation which leads to the leak.
drivers/staging/fbtft/fbtft-core.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/fbtft/fbtft-core.c b/drivers/staging/fbtft/fbtft-core.c
index da9c64152a60..8538b6bab6a5 100644
--- a/drivers/staging/fbtft/fbtft-core.c
+++ b/drivers/staging/fbtft/fbtft-core.c
@@ -612,7 +612,8 @@ struct fb_info *fbtft_framebuffer_alloc(struct fbtft_display *display,
info->fix.line_length = width * bpp / 8;
info->fix.accel = FB_ACCEL_NONE;
info->fix.smem_len = vmem_size;
- fb_deferred_io_init(info);
+ if (fb_deferred_io_init(info))
+ goto release_framebuf;
info->var.rotate = pdata->rotate;
info->var.xres = width;
@@ -652,7 +653,7 @@ struct fb_info *fbtft_framebuffer_alloc(struct fbtft_display *display,
if (par->gamma.curves && gamma) {
if (fbtft_gamma_parse_str(par, par->gamma.curves, gamma,
strlen(gamma)))
- goto release_framebuf;
+ goto cleanup_deferred;
}
/* Transmit buffer */
@@ -669,7 +670,7 @@ struct fb_info *fbtft_framebuffer_alloc(struct fbtft_display *display,
if (txbuflen > 0) {
txbuf = devm_kzalloc(par->info->device, txbuflen, GFP_KERNEL);
if (!txbuf)
- goto release_framebuf;
+ goto cleanup_deferred;
par->txbuf.buf = txbuf;
par->txbuf.len = txbuflen;
}
@@ -691,6 +692,8 @@ struct fb_info *fbtft_framebuffer_alloc(struct fbtft_display *display,
return info;
+cleanup_deferred:
+ fb_deferred_io_cleanup(info);
release_framebuf:
framebuffer_release(info);
--
2.43.0
^ permalink raw reply related
* [PATCH v3 2/2] staging: fbtft: cleanup error handling in fbtft_framebuffer_alloc()
From: Abdun Nihaal @ 2025-06-29 14:40 UTC (permalink / raw)
To: andy
Cc: Abdun Nihaal, dan.carpenter, gregkh, lorenzo.stoakes, tzimmermann,
riyandhiman14, willy, notro, thomas.petazzoni, dri-devel,
linux-fbdev, linux-staging, linux-kernel, Andy Shevchenko
In-Reply-To: <cover.1751207100.git.abdun.nihaal@gmail.com>
The error handling in fbtft_framebuffer_alloc() mixes managed allocation
and plain allocation, and performs error handling in an order different
from the order in fbtft_framebuffer_release().
Fix them by moving vmem allocation closer to where it is used, and using
plain kzalloc() for txbuf allocation.
Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Suggested-by: Dan Carpenter <dan.carpenter@linaro.org>
Signed-off-by: Abdun Nihaal <abdun.nihaal@gmail.com>
---
v2->v3:
- Remove the if check before kfree of txbuf.buf, because it is zero
initialized on allocation, and kfree is NULL aware.
Newly added in v2
drivers/staging/fbtft/fbtft-core.c | 31 +++++++++++++++---------------
1 file changed, 16 insertions(+), 15 deletions(-)
diff --git a/drivers/staging/fbtft/fbtft-core.c b/drivers/staging/fbtft/fbtft-core.c
index 8538b6bab6a5..9e7b84071174 100644
--- a/drivers/staging/fbtft/fbtft-core.c
+++ b/drivers/staging/fbtft/fbtft-core.c
@@ -568,18 +568,13 @@ struct fb_info *fbtft_framebuffer_alloc(struct fbtft_display *display,
height = display->height;
}
- vmem_size = display->width * display->height * bpp / 8;
- vmem = vzalloc(vmem_size);
- if (!vmem)
- goto alloc_fail;
-
fbdefio = devm_kzalloc(dev, sizeof(struct fb_deferred_io), GFP_KERNEL);
if (!fbdefio)
- goto alloc_fail;
+ return NULL;
buf = devm_kzalloc(dev, 128, GFP_KERNEL);
if (!buf)
- goto alloc_fail;
+ return NULL;
if (display->gamma_num && display->gamma_len) {
gamma_curves = devm_kcalloc(dev,
@@ -588,12 +583,17 @@ struct fb_info *fbtft_framebuffer_alloc(struct fbtft_display *display,
sizeof(gamma_curves[0]),
GFP_KERNEL);
if (!gamma_curves)
- goto alloc_fail;
+ return NULL;
}
info = framebuffer_alloc(sizeof(struct fbtft_par), dev);
if (!info)
- goto alloc_fail;
+ return NULL;
+
+ vmem_size = display->width * display->height * bpp / 8;
+ vmem = vzalloc(vmem_size);
+ if (!vmem)
+ goto release_framebuf;
info->screen_buffer = vmem;
info->fbops = &fbtft_ops;
@@ -613,7 +613,7 @@ struct fb_info *fbtft_framebuffer_alloc(struct fbtft_display *display,
info->fix.accel = FB_ACCEL_NONE;
info->fix.smem_len = vmem_size;
if (fb_deferred_io_init(info))
- goto release_framebuf;
+ goto release_screen_buffer;
info->var.rotate = pdata->rotate;
info->var.xres = width;
@@ -668,7 +668,7 @@ struct fb_info *fbtft_framebuffer_alloc(struct fbtft_display *display,
#endif
if (txbuflen > 0) {
- txbuf = devm_kzalloc(par->info->device, txbuflen, GFP_KERNEL);
+ txbuf = kzalloc(txbuflen, GFP_KERNEL);
if (!txbuf)
goto cleanup_deferred;
par->txbuf.buf = txbuf;
@@ -694,12 +694,10 @@ struct fb_info *fbtft_framebuffer_alloc(struct fbtft_display *display,
cleanup_deferred:
fb_deferred_io_cleanup(info);
+release_screen_buffer:
+ vfree(info->screen_buffer);
release_framebuf:
framebuffer_release(info);
-
-alloc_fail:
- vfree(vmem);
-
return NULL;
}
EXPORT_SYMBOL(fbtft_framebuffer_alloc);
@@ -712,6 +710,9 @@ EXPORT_SYMBOL(fbtft_framebuffer_alloc);
*/
void fbtft_framebuffer_release(struct fb_info *info)
{
+ struct fbtft_par *par = info->par;
+
+ kfree(par->txbuf.buf);
fb_deferred_io_cleanup(info);
vfree(info->screen_buffer);
framebuffer_release(info);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2 1/5] dt-bindings: display: simple-framebuffer: Add interconnects property
From: Thomas Zimmermann @ 2025-06-30 6:26 UTC (permalink / raw)
To: Krzysztof Kozlowski, Luca Weiss
Cc: Hans de Goede, Maarten Lankhorst, Maxime Ripard, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Javier Martinez Canillas, Helge Deller, linux-fbdev, dri-devel,
devicetree, linux-kernel
In-Reply-To: <1129bc60-f9cb-40be-9869-8ffa3b3c9748@kernel.org>
Hi
Am 28.06.25 um 13:49 schrieb Krzysztof Kozlowski:
> On 27/06/2025 11:48, Luca Weiss wrote:
>> Hi Krzysztof,
>>
>> On Fri Jun 27, 2025 at 10:08 AM CEST, Krzysztof Kozlowski wrote:
>>> On Mon, Jun 23, 2025 at 08:44:45AM +0200, Luca Weiss wrote:
>>>> Document the interconnects property which is a list of interconnect
>>>> paths that is used by the framebuffer and therefore needs to be kept
>>>> alive when the framebuffer is being used.
>>>>
>>>> Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
>>>> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
>>>> ---
>>>> Documentation/devicetree/bindings/display/simple-framebuffer.yaml | 3 +++
>>>> 1 file changed, 3 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
>>>> index 296500f9da05e296dbbeec50ba5186b6b30aaffc..f0fa0ef23d91043dfb2b220c654b80e2e80850cd 100644
>>>> --- a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
>>>> +++ b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
>>>> @@ -79,6 +79,9 @@ properties:
>>>> power-domains:
>>>> description: List of power domains used by the framebuffer.
>>>>
>>>> + interconnects:
>>>> + description: List of interconnect paths used by the framebuffer.
>>>> +
>>> maxItems: 1, or this is not a simple FB anymore. Anything which needs
>>> some sort of resources in unknown way is not simple anymore. You need
>>> device specific bindings.
>> The bindings support an arbitrary number of clocks, regulators,
>> power-domains. Why should I artificially limit the interconnects to only
>> one?
> And IMO they should not. Bindings are not supposed to be generic.
>
>> The driver code also has that support added in this series.
> That's not the problem here.
Then could you please state the problem in clear terms? We're obviously
not all on the same page here.
Best regards
Thomas
>
>
> Best regards,
> Krzysztof
>
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
^ permalink raw reply
* Re: [PATCH v2 1/5] dt-bindings: display: simple-framebuffer: Add interconnects property
From: Thomas Zimmermann @ 2025-06-30 6:34 UTC (permalink / raw)
To: Krzysztof Kozlowski, Luca Weiss
Cc: Hans de Goede, Maarten Lankhorst, Maxime Ripard, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Javier Martinez Canillas, Helge Deller, linux-fbdev, dri-devel,
devicetree, linux-kernel
In-Reply-To: <b94b752c-d7f7-41d6-ac79-d21427f20964@kernel.org>
Hi
Am 28.06.25 um 13:50 schrieb Krzysztof Kozlowski:
> On 27/06/2025 13:34, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 27.06.25 um 10:08 schrieb Krzysztof Kozlowski:
>>> On Mon, Jun 23, 2025 at 08:44:45AM +0200, Luca Weiss wrote:
>>>> Document the interconnects property which is a list of interconnect
>>>> paths that is used by the framebuffer and therefore needs to be kept
>>>> alive when the framebuffer is being used.
>>>>
>>>> Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
>>>> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
>>>> ---
>>>> Documentation/devicetree/bindings/display/simple-framebuffer.yaml | 3 +++
>>>> 1 file changed, 3 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
>>>> index 296500f9da05e296dbbeec50ba5186b6b30aaffc..f0fa0ef23d91043dfb2b220c654b80e2e80850cd 100644
>>>> --- a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
>>>> +++ b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
>>>> @@ -79,6 +79,9 @@ properties:
>>>> power-domains:
>>>> description: List of power domains used by the framebuffer.
>>>>
>>>> + interconnects:
>>>> + description: List of interconnect paths used by the framebuffer.
>>>> +
>>> maxItems: 1, or this is not a simple FB anymore. Anything which needs
>>> some sort of resources in unknown way is not simple anymore. You need
>>> device specific bindings.
>> In this context, 'simple' means that this device cannot change display
>> modes or do graphics acceleration. The hardware itself is not
>> necessarily simple. As Javier pointed out, it's initialized by firmware
> If hardware is not simple, then it needs specific bindings.
>
>> on the actual hardware. Think of 'VGA-for-ARM'. We need these resources
>> to keep the display working.
> I don't claim you do not need these resources. I claim device is not
> simple thus does not suit rules for generic bindings. Generic bindings
> are in general not allowed and we have them only for very, very simple
> devices.
>
> You say this is not simple device, so there you go - specific binding
> for this complex (not-simple) device.
No, I didn't. I said that the device is simple. I did not say that the
device's hardware is simple. Sounds nonsensical, but makes sense here.
The simple-framebuffer is just the range of display memory that the
firmware configured for printing boot-up messages. We use it for the
kernel's output as well. Being generic and simple is the exact raison
d'etre for simple-framebuffer. (The display property points to the
actual hardware, but we don't need it.)
Best regards
Thomas
>
> Best regards,
> Krzysztof
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
^ permalink raw reply
* Re: [PATCH v2 1/5] dt-bindings: display: simple-framebuffer: Add interconnects property
From: Hans de Goede @ 2025-06-30 7:26 UTC (permalink / raw)
To: Thomas Zimmermann, Krzysztof Kozlowski, Luca Weiss
Cc: Maarten Lankhorst, Maxime Ripard, David Airlie, Simona Vetter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Javier Martinez Canillas, Helge Deller, linux-fbdev, dri-devel,
devicetree, linux-kernel
In-Reply-To: <f15a775d-d82f-4ac9-9d88-159ffcf7e81c@suse.de>
Hi,
On 30-Jun-25 8:34 AM, Thomas Zimmermann wrote:
> Hi
>
> Am 28.06.25 um 13:50 schrieb Krzysztof Kozlowski:
>> On 27/06/2025 13:34, Thomas Zimmermann wrote:
>>> Hi
>>>
>>> Am 27.06.25 um 10:08 schrieb Krzysztof Kozlowski:
>>>> On Mon, Jun 23, 2025 at 08:44:45AM +0200, Luca Weiss wrote:
>>>>> Document the interconnects property which is a list of interconnect
>>>>> paths that is used by the framebuffer and therefore needs to be kept
>>>>> alive when the framebuffer is being used.
>>>>>
>>>>> Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
>>>>> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
>>>>> ---
>>>>> Documentation/devicetree/bindings/display/simple-framebuffer.yaml | 3 +++
>>>>> 1 file changed, 3 insertions(+)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
>>>>> index 296500f9da05e296dbbeec50ba5186b6b30aaffc..f0fa0ef23d91043dfb2b220c654b80e2e80850cd 100644
>>>>> --- a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
>>>>> +++ b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
>>>>> @@ -79,6 +79,9 @@ properties:
>>>>> power-domains:
>>>>> description: List of power domains used by the framebuffer.
>>>>> + interconnects:
>>>>> + description: List of interconnect paths used by the framebuffer.
>>>>> +
>>>> maxItems: 1, or this is not a simple FB anymore. Anything which needs
>>>> some sort of resources in unknown way is not simple anymore. You need
>>>> device specific bindings.
>>> In this context, 'simple' means that this device cannot change display
>>> modes or do graphics acceleration. The hardware itself is not
>>> necessarily simple. As Javier pointed out, it's initialized by firmware
>> If hardware is not simple, then it needs specific bindings.
>>
>>> on the actual hardware. Think of 'VGA-for-ARM'. We need these resources
>>> to keep the display working.
>> I don't claim you do not need these resources. I claim device is not
>> simple thus does not suit rules for generic bindings. Generic bindings
>> are in general not allowed and we have them only for very, very simple
>> devices.
>>
>> You say this is not simple device, so there you go - specific binding
>> for this complex (not-simple) device.
>
> No, I didn't. I said that the device is simple. I did not say that the device's hardware is simple. Sounds nonsensical, but makes sense here. The simple-framebuffer is just the range of display memory that the firmware configured for printing boot-up messages. We use it for the kernel's output as well. Being generic and simple is the exact raison d'etre for simple-framebuffer. (The display property points to the actual hardware, but we don't need it.)
I believe part of the problem here is the simple part of the simplefb
name in hindsight that is a mistake and we should have called the thing
firmware-framebuffer since its goal is to pass along a firmware setup
framebuffer to the OS for displaying stuff.
As for the argument for having a firmware-framebuffer not being allowed
because framebuffers are to complex to have a generic binding, that
ship has long sailed since we already have the simplefb binding.
And since we already have the binding I do not find this not being
simple a valid technical argument. That is an argument to allow
having a generic binding at all or to not have it at all, but here
we already have the binding and this is just about evolving the binding
with changing hw needs.
And again this reminds me very much of the whole clocks / regulators
addition to simplefb discussion we had over a decade ago. Back then
we had a huge thread, almost a flamefest with in my memory over
a 100 emails and back then the only argument against adding them
was also "it is not simple", which IMHO really is a non argument for
an already existing binding. Certainly it is not a good technical
argument.
During the last decade, after clocks and regulators were added to
the binding. simplefb has been used successfully on millions (billions?)
handover the firmware framebuffer to the OS for bootsplash use,
replacing various vendor hacks for this. Disallowing the addition of
interconnect support to the simplefb binding will only result in
various vendor hacks appearing in vendor kernels for this, which
I believe is something which we should try to avoid.
So as the maintainer of the simplefb kernel driver for over a decade
I strongly advice the DT maintainers to accept this bindings patch
and from my my side this still is:
Reviewed-by: Hans de Goede <hansg@kernel.org>
Regards,
Hans
^ permalink raw reply
* Re: [PATCH v2 1/5] dt-bindings: display: simple-framebuffer: Add interconnects property
From: Thomas Zimmermann @ 2025-06-30 7:46 UTC (permalink / raw)
To: Hans de Goede, Krzysztof Kozlowski, Luca Weiss
Cc: Maarten Lankhorst, Maxime Ripard, David Airlie, Simona Vetter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Javier Martinez Canillas, Helge Deller, linux-fbdev, dri-devel,
devicetree, linux-kernel
In-Reply-To: <72aab355-263c-4f63-8818-3d76bd3f6826@redhat.com>
Hi
Am 30.06.25 um 09:26 schrieb Hans de Goede:
> Hi,
>
> On 30-Jun-25 8:34 AM, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 28.06.25 um 13:50 schrieb Krzysztof Kozlowski:
>>> On 27/06/2025 13:34, Thomas Zimmermann wrote:
>>>> Hi
>>>>
>>>> Am 27.06.25 um 10:08 schrieb Krzysztof Kozlowski:
>>>>> On Mon, Jun 23, 2025 at 08:44:45AM +0200, Luca Weiss wrote:
>>>>>> Document the interconnects property which is a list of interconnect
>>>>>> paths that is used by the framebuffer and therefore needs to be kept
>>>>>> alive when the framebuffer is being used.
>>>>>>
>>>>>> Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
>>>>>> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
>>>>>> ---
>>>>>> Documentation/devicetree/bindings/display/simple-framebuffer.yaml | 3 +++
>>>>>> 1 file changed, 3 insertions(+)
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
>>>>>> index 296500f9da05e296dbbeec50ba5186b6b30aaffc..f0fa0ef23d91043dfb2b220c654b80e2e80850cd 100644
>>>>>> --- a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
>>>>>> +++ b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
>>>>>> @@ -79,6 +79,9 @@ properties:
>>>>>> power-domains:
>>>>>> description: List of power domains used by the framebuffer.
>>>>>> + interconnects:
>>>>>> + description: List of interconnect paths used by the framebuffer.
>>>>>> +
>>>>> maxItems: 1, or this is not a simple FB anymore. Anything which needs
>>>>> some sort of resources in unknown way is not simple anymore. You need
>>>>> device specific bindings.
>>>> In this context, 'simple' means that this device cannot change display
>>>> modes or do graphics acceleration. The hardware itself is not
>>>> necessarily simple. As Javier pointed out, it's initialized by firmware
>>> If hardware is not simple, then it needs specific bindings.
>>>
>>>> on the actual hardware. Think of 'VGA-for-ARM'. We need these resources
>>>> to keep the display working.
>>> I don't claim you do not need these resources. I claim device is not
>>> simple thus does not suit rules for generic bindings. Generic bindings
>>> are in general not allowed and we have them only for very, very simple
>>> devices.
>>>
>>> You say this is not simple device, so there you go - specific binding
>>> for this complex (not-simple) device.
>> No, I didn't. I said that the device is simple. I did not say that the device's hardware is simple. Sounds nonsensical, but makes sense here. The simple-framebuffer is just the range of display memory that the firmware configured for printing boot-up messages. We use it for the kernel's output as well. Being generic and simple is the exact raison d'etre for simple-framebuffer. (The display property points to the actual hardware, but we don't need it.)
> I believe part of the problem here is the simple part of the simplefb
> name in hindsight that is a mistake and we should have called the thing
> firmware-framebuffer since its goal is to pass along a firmware setup
> framebuffer to the OS for displaying stuff.
I totally feel you. In DRM land, we've also been upset about the naming.
But well...
>
> As for the argument for having a firmware-framebuffer not being allowed
> because framebuffers are to complex to have a generic binding, that
> ship has long sailed since we already have the simplefb binding.
>
> And since we already have the binding I do not find this not being
> simple a valid technical argument. That is an argument to allow
> having a generic binding at all or to not have it at all, but here
> we already have the binding and this is just about evolving the binding
> with changing hw needs.
Exactly my point.
>
> And again this reminds me very much of the whole clocks / regulators
> addition to simplefb discussion we had over a decade ago. Back then
> we had a huge thread, almost a flamefest with in my memory over
> a 100 emails and back then the only argument against adding them
> was also "it is not simple", which IMHO really is a non argument for
> an already existing binding. Certainly it is not a good technical
> argument.
>
> During the last decade, after clocks and regulators were added to
> the binding. simplefb has been used successfully on millions (billions?)
> handover the firmware framebuffer to the OS for bootsplash use,
> replacing various vendor hacks for this. Disallowing the addition of
> interconnect support to the simplefb binding will only result in
> various vendor hacks appearing in vendor kernels for this, which
> I believe is something which we should try to avoid.
Exactly. And I'd also add that the current way of handling the situation
is the only feasible one. Simple-framebuffer needs to be generic and
compatible with existing and future hardware at minimal cost. The way of
doing so, is to have a few properties, such as clocks, regulators and
now interconnects, that the firmware clearly tells us about. If we go
with per-hardware/per-vendor nodes, simple-framebuffer loses its usefulness.
>
> So as the maintainer of the simplefb kernel driver for over a decade
> I strongly advice the DT maintainers to accept this bindings patch
As the maintainer of the simpledrm driver, I second this.
Best regards
Thomas
> and from my my side this still is:
>
> Reviewed-by: Hans de Goede <hansg@kernel.org>
>
> Regards,
>
> Hans
>
>
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
^ permalink raw reply
* Re: [PATCH v2 1/5] dt-bindings: display: simple-framebuffer: Add interconnects property
From: Krzysztof Kozlowski @ 2025-06-30 8:24 UTC (permalink / raw)
To: Hans de Goede, Luca Weiss
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Javier Martinez Canillas, Helge Deller, linux-fbdev, dri-devel,
devicetree, linux-kernel
In-Reply-To: <8a3ad930-bfb1-4531-9d34-fdf7d437f352@redhat.com>
On 29/06/2025 14:07, Hans de Goede wrote:
> Hi Krzysztof,
>
> On 28-Jun-25 1:49 PM, Krzysztof Kozlowski wrote:
>> On 27/06/2025 11:48, Luca Weiss wrote:
>>> Hi Krzysztof,
>>>
>>> On Fri Jun 27, 2025 at 10:08 AM CEST, Krzysztof Kozlowski wrote:
>>>> On Mon, Jun 23, 2025 at 08:44:45AM +0200, Luca Weiss wrote:
>>>>> Document the interconnects property which is a list of interconnect
>>>>> paths that is used by the framebuffer and therefore needs to be kept
>>>>> alive when the framebuffer is being used.
>>>>>
>>>>> Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
>>>>> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
>>>>> ---
>>>>> Documentation/devicetree/bindings/display/simple-framebuffer.yaml | 3 +++
>>>>> 1 file changed, 3 insertions(+)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
>>>>> index 296500f9da05e296dbbeec50ba5186b6b30aaffc..f0fa0ef23d91043dfb2b220c654b80e2e80850cd 100644
>>>>> --- a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
>>>>> +++ b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
>>>>> @@ -79,6 +79,9 @@ properties:
>>>>> power-domains:
>>>>> description: List of power domains used by the framebuffer.
>>>>>
>>>>> + interconnects:
>>>>> + description: List of interconnect paths used by the framebuffer.
>>>>> +
>>>>
>>>> maxItems: 1, or this is not a simple FB anymore. Anything which needs
>>>> some sort of resources in unknown way is not simple anymore. You need
>>>> device specific bindings.
>>>
>>> The bindings support an arbitrary number of clocks, regulators,
>>> power-domains. Why should I artificially limit the interconnects to only
>>> one?
>>
>> And IMO they should not. Bindings are not supposed to be generic.
>
> The simplefb binding is a binding to allow keeping the firmware, e.g.
> uboot setup framebuffer alive to e.g. show a boot splash until
> the native display-engine drive loads. Needing display-engine
> specific bindings totally contradicts the whole goal of
No, it does not. DT is well designed for that through expressing
compatibility. I did not say you cannot have generic fallback for simple
use case.
But this (and previous patchset) grows this into generic binding ONLY
and that is not correct.
>
> It is generic by nature and I really do not see how clocks and
> regulators are any different then interconnects here.
Yeah, they are also wrong. I already commented on this.
>
> Note that we had a huge discussion about adding clock
> and regulators to simplefb many years ago with pretty
> much the same arguments against doing so. In the end it was
> decided to add regulator and clocks support to the simplefb
> bindings and non of the feared problems with e.g. ordening
> of turning things on happened.
>
> A big part of this is that the claiming of clks / regulators /
> interconnects by the simplefb driver is there to keep things on,
> so it happens before the kernel starts tuning off unused resources
> IOW everything is already up and running and this really is about
> avoiding turning things off.
No one asks to drop them from the driver. I only want specific front
compatible which will list and constrain the properties. It is not
contradictory to your statements, U-boot support, driver support. I
really do not see ANY argument why this cannot follow standard DT rules.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/5] dt-bindings: display: simple-framebuffer: Add interconnects property
From: Maxime Ripard @ 2025-06-30 8:38 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Hans de Goede, Luca Weiss, Maarten Lankhorst, Thomas Zimmermann,
David Airlie, Simona Vetter, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Javier Martinez Canillas, Helge Deller, linux-fbdev,
dri-devel, devicetree, linux-kernel
In-Reply-To: <85521ded-734d-48e8-8f76-c57739102ded@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 3702 bytes --]
On Mon, Jun 30, 2025 at 10:24:06AM +0200, Krzysztof Kozlowski wrote:
> On 29/06/2025 14:07, Hans de Goede wrote:
> > Hi Krzysztof,
> >
> > On 28-Jun-25 1:49 PM, Krzysztof Kozlowski wrote:
> >> On 27/06/2025 11:48, Luca Weiss wrote:
> >>> Hi Krzysztof,
> >>>
> >>> On Fri Jun 27, 2025 at 10:08 AM CEST, Krzysztof Kozlowski wrote:
> >>>> On Mon, Jun 23, 2025 at 08:44:45AM +0200, Luca Weiss wrote:
> >>>>> Document the interconnects property which is a list of interconnect
> >>>>> paths that is used by the framebuffer and therefore needs to be kept
> >>>>> alive when the framebuffer is being used.
> >>>>>
> >>>>> Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
> >>>>> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> >>>>> ---
> >>>>> Documentation/devicetree/bindings/display/simple-framebuffer.yaml | 3 +++
> >>>>> 1 file changed, 3 insertions(+)
> >>>>>
> >>>>> diff --git a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
> >>>>> index 296500f9da05e296dbbeec50ba5186b6b30aaffc..f0fa0ef23d91043dfb2b220c654b80e2e80850cd 100644
> >>>>> --- a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
> >>>>> +++ b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
> >>>>> @@ -79,6 +79,9 @@ properties:
> >>>>> power-domains:
> >>>>> description: List of power domains used by the framebuffer.
> >>>>>
> >>>>> + interconnects:
> >>>>> + description: List of interconnect paths used by the framebuffer.
> >>>>> +
> >>>>
> >>>> maxItems: 1, or this is not a simple FB anymore. Anything which needs
> >>>> some sort of resources in unknown way is not simple anymore. You need
> >>>> device specific bindings.
> >>>
> >>> The bindings support an arbitrary number of clocks, regulators,
> >>> power-domains. Why should I artificially limit the interconnects to only
> >>> one?
> >>
> >> And IMO they should not. Bindings are not supposed to be generic.
> >
> > The simplefb binding is a binding to allow keeping the firmware, e.g.
> > uboot setup framebuffer alive to e.g. show a boot splash until
> > the native display-engine drive loads. Needing display-engine
> > specific bindings totally contradicts the whole goal of
>
> No, it does not. DT is well designed for that through expressing
> compatibility. I did not say you cannot have generic fallback for simple
> use case.
>
> But this (and previous patchset) grows this into generic binding ONLY
> and that is not correct.
Can we have a proper definition of what a correct device tree binding is
then?
It's a bit surprising to have *that* discussion over a binding that is
now well older than a decade now, and while there is definitely some
generic bindings in ePAPR/DT spec, like the CPU ones.
If you don't consider that spec to be correct DT bindings, please
provide a definition of what that is, and / or reasonable alternatives.
Also, no, a device specific binding isn't reasonable here, because we
*don't* have a device. From a technical standpoint, the firmware creates
the framebuffer, Linux just uses it. Just like you don't have a
device/platform specific compatible for PSCI, SCPI, et al.
And from a process standpoint, that driver is typically used years
before we even get to writing a driver for the actual display driver.
And since bindings are far from standard and actually pretty
opionionated, even if we submitted a binding to use a proper binding
without having a clear idea of what the hardware is, or what a driver
would want, we would end up with either a broken binding, or a broken
driver.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/5] dt-bindings: display: simple-framebuffer: Add interconnects property
From: Hans de Goede @ 2025-06-30 8:40 UTC (permalink / raw)
To: Krzysztof Kozlowski, Luca Weiss
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Javier Martinez Canillas, Helge Deller, linux-fbdev, dri-devel,
devicetree, linux-kernel
In-Reply-To: <85521ded-734d-48e8-8f76-c57739102ded@kernel.org>
Hi,
On 30-Jun-25 10:24 AM, Krzysztof Kozlowski wrote:
> On 29/06/2025 14:07, Hans de Goede wrote:
>> Hi Krzysztof,
>>
>> On 28-Jun-25 1:49 PM, Krzysztof Kozlowski wrote:
>>> On 27/06/2025 11:48, Luca Weiss wrote:
>>>> Hi Krzysztof,
>>>>
>>>> On Fri Jun 27, 2025 at 10:08 AM CEST, Krzysztof Kozlowski wrote:
>>>>> On Mon, Jun 23, 2025 at 08:44:45AM +0200, Luca Weiss wrote:
>>>>>> Document the interconnects property which is a list of interconnect
>>>>>> paths that is used by the framebuffer and therefore needs to be kept
>>>>>> alive when the framebuffer is being used.
>>>>>>
>>>>>> Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
>>>>>> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
>>>>>> ---
>>>>>> Documentation/devicetree/bindings/display/simple-framebuffer.yaml | 3 +++
>>>>>> 1 file changed, 3 insertions(+)
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
>>>>>> index 296500f9da05e296dbbeec50ba5186b6b30aaffc..f0fa0ef23d91043dfb2b220c654b80e2e80850cd 100644
>>>>>> --- a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
>>>>>> +++ b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
>>>>>> @@ -79,6 +79,9 @@ properties:
>>>>>> power-domains:
>>>>>> description: List of power domains used by the framebuffer.
>>>>>>
>>>>>> + interconnects:
>>>>>> + description: List of interconnect paths used by the framebuffer.
>>>>>> +
>>>>>
>>>>> maxItems: 1, or this is not a simple FB anymore. Anything which needs
>>>>> some sort of resources in unknown way is not simple anymore. You need
>>>>> device specific bindings.
>>>>
>>>> The bindings support an arbitrary number of clocks, regulators,
>>>> power-domains. Why should I artificially limit the interconnects to only
>>>> one?
>>>
>>> And IMO they should not. Bindings are not supposed to be generic.
>>
>> The simplefb binding is a binding to allow keeping the firmware, e.g.
>> uboot setup framebuffer alive to e.g. show a boot splash until
>> the native display-engine drive loads. Needing display-engine
>> specific bindings totally contradicts the whole goal of
>
> No, it does not. DT is well designed for that through expressing
> compatibility. I did not say you cannot have generic fallback for simple
> use case.
>
> But this (and previous patchset) grows this into generic binding ONLY
> and that is not correct.
I think that it is important here to notice that this is not
a generic fallback binding, this is not and will never be
intended to replace have a proper binding for
the display-engine.
This is just a way to give the kernel access to the firmware
setup framebuffer to e.g. show a bootsplash but also fatal
kernel errors until the real display-engine driver loads.
Note sometimes the whole framebuffer memory is not touched
at all and the sole reason for having a driver attach to
the simplefb node early on is just to keep the resources
needed to keep the panel lit up around (on) until the real
display-engine driver comes along to claim those resources.
This avoids the display going black if the display-engine
driver only binds after the kernel starts turning off
unused resources, this typically happens when the display-engine
driver is a module.
>> It is generic by nature and I really do not see how clocks and
>> regulators are any different then interconnects here.
>
> Yeah, they are also wrong. I already commented on this.
>
>>
>> Note that we had a huge discussion about adding clock
>> and regulators to simplefb many years ago with pretty
>> much the same arguments against doing so. In the end it was
>> decided to add regulator and clocks support to the simplefb
>> bindings and non of the feared problems with e.g. ordening
>> of turning things on happened.
>>
>> A big part of this is that the claiming of clks / regulators /
>> interconnects by the simplefb driver is there to keep things on,
>> so it happens before the kernel starts tuning off unused resources
>> IOW everything is already up and running and this really is about
>> avoiding turning things off.
>
> No one asks to drop them from the driver. I only want specific front
> compatible which will list and constrain the properties. It is not
> contradictory to your statements, U-boot support, driver support. I
> really do not see ANY argument why this cannot follow standard DT rules.
So what you are saying is that you want something like:
framebuffer0: framebuffer@1d385000 {
compatible = "qcom.simple-framebuffer-sm8650-mdss", "simple-framebuffer";
}
and that the binding for qcom.simple-framebuffer-sm8650-mdss
can then list interconnects ?
Regards,
Hans
^ permalink raw reply
* Re: [PATCH v2 1/5] dt-bindings: display: simple-framebuffer: Add interconnects property
From: Krzysztof Kozlowski @ 2025-06-30 9:36 UTC (permalink / raw)
To: Maxime Ripard
Cc: Hans de Goede, Luca Weiss, Maarten Lankhorst, Thomas Zimmermann,
David Airlie, Simona Vetter, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Javier Martinez Canillas, Helge Deller, linux-fbdev,
dri-devel, devicetree, linux-kernel
In-Reply-To: <20250630-stirring-kiwi-of-adventure-8f22ba@houat>
On 30/06/2025 10:38, Maxime Ripard wrote:
> On Mon, Jun 30, 2025 at 10:24:06AM +0200, Krzysztof Kozlowski wrote:
>> On 29/06/2025 14:07, Hans de Goede wrote:
>>> Hi Krzysztof,
>>>
>>> On 28-Jun-25 1:49 PM, Krzysztof Kozlowski wrote:
>>>> On 27/06/2025 11:48, Luca Weiss wrote:
>>>>> Hi Krzysztof,
>>>>>
>>>>> On Fri Jun 27, 2025 at 10:08 AM CEST, Krzysztof Kozlowski wrote:
>>>>>> On Mon, Jun 23, 2025 at 08:44:45AM +0200, Luca Weiss wrote:
>>>>>>> Document the interconnects property which is a list of interconnect
>>>>>>> paths that is used by the framebuffer and therefore needs to be kept
>>>>>>> alive when the framebuffer is being used.
>>>>>>>
>>>>>>> Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
>>>>>>> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
>>>>>>> ---
>>>>>>> Documentation/devicetree/bindings/display/simple-framebuffer.yaml | 3 +++
>>>>>>> 1 file changed, 3 insertions(+)
>>>>>>>
>>>>>>> diff --git a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
>>>>>>> index 296500f9da05e296dbbeec50ba5186b6b30aaffc..f0fa0ef23d91043dfb2b220c654b80e2e80850cd 100644
>>>>>>> --- a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
>>>>>>> +++ b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
>>>>>>> @@ -79,6 +79,9 @@ properties:
>>>>>>> power-domains:
>>>>>>> description: List of power domains used by the framebuffer.
>>>>>>>
>>>>>>> + interconnects:
>>>>>>> + description: List of interconnect paths used by the framebuffer.
>>>>>>> +
>>>>>>
>>>>>> maxItems: 1, or this is not a simple FB anymore. Anything which needs
>>>>>> some sort of resources in unknown way is not simple anymore. You need
>>>>>> device specific bindings.
>>>>>
>>>>> The bindings support an arbitrary number of clocks, regulators,
>>>>> power-domains. Why should I artificially limit the interconnects to only
>>>>> one?
>>>>
>>>> And IMO they should not. Bindings are not supposed to be generic.
>>>
>>> The simplefb binding is a binding to allow keeping the firmware, e.g.
>>> uboot setup framebuffer alive to e.g. show a boot splash until
>>> the native display-engine drive loads. Needing display-engine
>>> specific bindings totally contradicts the whole goal of
>>
>> No, it does not. DT is well designed for that through expressing
>> compatibility. I did not say you cannot have generic fallback for simple
>> use case.
>>
>> But this (and previous patchset) grows this into generic binding ONLY
>> and that is not correct.
>
> Can we have a proper definition of what a correct device tree binding is
> then?
>
> It's a bit surprising to have *that* discussion over a binding that is
> now well older than a decade now, and while there is definitely some
> generic bindings in ePAPR/DT spec, like the CPU ones.
Hm? In ARM world at least they are specific, e.g. they have specific
compatibles.
>
> If you don't consider that spec to be correct DT bindings, please
> provide a definition of what that is, and / or reasonable alternatives.
>
> Also, no, a device specific binding isn't reasonable here, because we
> *don't* have a device. From a technical standpoint, the firmware creates
You touch internal parts of the SoC and you list very specific SoC
parts. Interconnect is internal part of the SoC and only specific
devices are using it.
You define here generic SW construct for something which is opposite of
generic: the interconnect connecting two specific, unique components of
one, given SoC.
> the framebuffer, Linux just uses it. Just like you don't have a
> device/platform specific compatible for PSCI, SCPI, et al.
They follow some sort of spec and still they do not reference chosen
SoC-design-specific properties.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 0/2] staging: fbtft: cleanup fbtft_framebuffer_alloc()
From: Andy Shevchenko @ 2025-06-30 9:58 UTC (permalink / raw)
To: Abdun Nihaal
Cc: andy, dan.carpenter, gregkh, lorenzo.stoakes, tzimmermann,
riyandhiman14, willy, notro, thomas.petazzoni, dri-devel,
linux-fbdev, linux-staging, linux-kernel
In-Reply-To: <cover.1751207100.git.abdun.nihaal@gmail.com>
On Sun, Jun 29, 2025 at 08:10:09PM +0530, Abdun Nihaal wrote:
> Fix a potential memory leak and cleanup error handling in
> fbtft_framebuffer_alloc().
Both looks okay to me now.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 1/5] dt-bindings: display: simple-framebuffer: Add interconnects property
From: Hans de Goede @ 2025-06-30 10:10 UTC (permalink / raw)
To: Krzysztof Kozlowski, Maxime Ripard
Cc: Luca Weiss, Maarten Lankhorst, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Javier Martinez Canillas, Helge Deller, linux-fbdev, dri-devel,
devicetree, linux-kernel
In-Reply-To: <b9f010ca-1564-4a3a-b004-ef179d5c90a6@kernel.org>
Hi Krzysztof,
On 30-Jun-25 11:36 AM, Krzysztof Kozlowski wrote:
> On 30/06/2025 10:38, Maxime Ripard wrote:
>> On Mon, Jun 30, 2025 at 10:24:06AM +0200, Krzysztof Kozlowski wrote:
>>> On 29/06/2025 14:07, Hans de Goede wrote:
>>>> Hi Krzysztof,
>>>>
>>>> On 28-Jun-25 1:49 PM, Krzysztof Kozlowski wrote:
>>>>> On 27/06/2025 11:48, Luca Weiss wrote:
>>>>>> Hi Krzysztof,
>>>>>>
>>>>>> On Fri Jun 27, 2025 at 10:08 AM CEST, Krzysztof Kozlowski wrote:
>>>>>>> On Mon, Jun 23, 2025 at 08:44:45AM +0200, Luca Weiss wrote:
>>>>>>>> Document the interconnects property which is a list of interconnect
>>>>>>>> paths that is used by the framebuffer and therefore needs to be kept
>>>>>>>> alive when the framebuffer is being used.
>>>>>>>>
>>>>>>>> Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
>>>>>>>> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
>>>>>>>> ---
>>>>>>>> Documentation/devicetree/bindings/display/simple-framebuffer.yaml | 3 +++
>>>>>>>> 1 file changed, 3 insertions(+)
>>>>>>>>
>>>>>>>> diff --git a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
>>>>>>>> index 296500f9da05e296dbbeec50ba5186b6b30aaffc..f0fa0ef23d91043dfb2b220c654b80e2e80850cd 100644
>>>>>>>> --- a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
>>>>>>>> +++ b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
>>>>>>>> @@ -79,6 +79,9 @@ properties:
>>>>>>>> power-domains:
>>>>>>>> description: List of power domains used by the framebuffer.
>>>>>>>>
>>>>>>>> + interconnects:
>>>>>>>> + description: List of interconnect paths used by the framebuffer.
>>>>>>>> +
>>>>>>>
>>>>>>> maxItems: 1, or this is not a simple FB anymore. Anything which needs
>>>>>>> some sort of resources in unknown way is not simple anymore. You need
>>>>>>> device specific bindings.
>>>>>>
>>>>>> The bindings support an arbitrary number of clocks, regulators,
>>>>>> power-domains. Why should I artificially limit the interconnects to only
>>>>>> one?
>>>>>
>>>>> And IMO they should not. Bindings are not supposed to be generic.
>>>>
>>>> The simplefb binding is a binding to allow keeping the firmware, e.g.
>>>> uboot setup framebuffer alive to e.g. show a boot splash until
>>>> the native display-engine drive loads. Needing display-engine
>>>> specific bindings totally contradicts the whole goal of
>>>
>>> No, it does not. DT is well designed for that through expressing
>>> compatibility. I did not say you cannot have generic fallback for simple
>>> use case.
>>>
>>> But this (and previous patchset) grows this into generic binding ONLY
>>> and that is not correct.
>>
>> Can we have a proper definition of what a correct device tree binding is
>> then?
>>
>> It's a bit surprising to have *that* discussion over a binding that is
>> now well older than a decade now, and while there is definitely some
>> generic bindings in ePAPR/DT spec, like the CPU ones.
>
> Hm? In ARM world at least they are specific, e.g. they have specific
> compatibles.
>
>>
>> If you don't consider that spec to be correct DT bindings, please
>> provide a definition of what that is, and / or reasonable alternatives.
>>
>> Also, no, a device specific binding isn't reasonable here, because we
>> *don't* have a device. From a technical standpoint, the firmware creates
>
> You touch internal parts of the SoC and you list very specific SoC
> parts. Interconnect is internal part of the SoC and only specific
> devices are using it.
>
> You define here generic SW construct for something which is opposite of
> generic: the interconnect connecting two specific, unique components of
> one, given SoC.
>
>> the framebuffer, Linux just uses it. Just like you don't have a
>> device/platform specific compatible for PSCI, SCPI, et al.
>
> They follow some sort of spec and still they do not reference chosen
> SoC-design-specific properties.
It does not look like this discussion is going anywhere,
despite 2 drm subsystem maintainers and the simplefb
maintainer telling you that this is what is necessary
and also that we believe this is the right thing todo.
IOW despite 3 domain experts telling you we want this,
you keep coming up with vague, not really technical
argument about this not being generic / simple enough.
Looking at this from a driver pov interconnects are just
another resource we need to avoid from turning off.
And this is simple and generic, the actual display-engine
drivers are very complex and when powering things up
this needs to be done in a very specific order with
specific delays. That is hw-specific. The simplefb/simpledrm
code does not need any of this knowledge everything is
already setup. The simple* drivers just needs to claim all
listed resources in an arbitrary order and without any delays
as someone who has written many many drivers this is
about as simple and generic as it can get.
But as mentioned it looks like this discussion is going
anywhere. Is there some sort of arbitration / appeal
process which we can use when DT-maintainers block
a binding which has been acked and is seen as necessary
by the subsystem maintainers of the subsystem for which
the bindings are ?
Regards,
Hans
^ permalink raw reply
* Re: [PATCH v2 1/5] dt-bindings: display: simple-framebuffer: Add interconnects property
From: Maxime Ripard @ 2025-06-30 10:45 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Hans de Goede, Luca Weiss, Maarten Lankhorst, Thomas Zimmermann,
David Airlie, Simona Vetter, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Javier Martinez Canillas, Helge Deller, linux-fbdev,
dri-devel, devicetree, linux-kernel
In-Reply-To: <b9f010ca-1564-4a3a-b004-ef179d5c90a6@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 4326 bytes --]
On Mon, Jun 30, 2025 at 11:36:51AM +0200, Krzysztof Kozlowski wrote:
> On 30/06/2025 10:38, Maxime Ripard wrote:
> > On Mon, Jun 30, 2025 at 10:24:06AM +0200, Krzysztof Kozlowski wrote:
> >> On 29/06/2025 14:07, Hans de Goede wrote:
> >>> Hi Krzysztof,
> >>>
> >>> On 28-Jun-25 1:49 PM, Krzysztof Kozlowski wrote:
> >>>> On 27/06/2025 11:48, Luca Weiss wrote:
> >>>>> Hi Krzysztof,
> >>>>>
> >>>>> On Fri Jun 27, 2025 at 10:08 AM CEST, Krzysztof Kozlowski wrote:
> >>>>>> On Mon, Jun 23, 2025 at 08:44:45AM +0200, Luca Weiss wrote:
> >>>>>>> Document the interconnects property which is a list of interconnect
> >>>>>>> paths that is used by the framebuffer and therefore needs to be kept
> >>>>>>> alive when the framebuffer is being used.
> >>>>>>>
> >>>>>>> Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
> >>>>>>> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> >>>>>>> ---
> >>>>>>> Documentation/devicetree/bindings/display/simple-framebuffer.yaml | 3 +++
> >>>>>>> 1 file changed, 3 insertions(+)
> >>>>>>>
> >>>>>>> diff --git a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
> >>>>>>> index 296500f9da05e296dbbeec50ba5186b6b30aaffc..f0fa0ef23d91043dfb2b220c654b80e2e80850cd 100644
> >>>>>>> --- a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
> >>>>>>> +++ b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
> >>>>>>> @@ -79,6 +79,9 @@ properties:
> >>>>>>> power-domains:
> >>>>>>> description: List of power domains used by the framebuffer.
> >>>>>>>
> >>>>>>> + interconnects:
> >>>>>>> + description: List of interconnect paths used by the framebuffer.
> >>>>>>> +
> >>>>>>
> >>>>>> maxItems: 1, or this is not a simple FB anymore. Anything which needs
> >>>>>> some sort of resources in unknown way is not simple anymore. You need
> >>>>>> device specific bindings.
> >>>>>
> >>>>> The bindings support an arbitrary number of clocks, regulators,
> >>>>> power-domains. Why should I artificially limit the interconnects to only
> >>>>> one?
> >>>>
> >>>> And IMO they should not. Bindings are not supposed to be generic.
> >>>
> >>> The simplefb binding is a binding to allow keeping the firmware, e.g.
> >>> uboot setup framebuffer alive to e.g. show a boot splash until
> >>> the native display-engine drive loads. Needing display-engine
> >>> specific bindings totally contradicts the whole goal of
> >>
> >> No, it does not. DT is well designed for that through expressing
> >> compatibility. I did not say you cannot have generic fallback for simple
> >> use case.
> >>
> >> But this (and previous patchset) grows this into generic binding ONLY
> >> and that is not correct.
> >
> > Can we have a proper definition of what a correct device tree binding is
> > then?
> >
> > It's a bit surprising to have *that* discussion over a binding that is
> > now well older than a decade now, and while there is definitely some
> > generic bindings in ePAPR/DT spec, like the CPU ones.
>
> Hm? In ARM world at least they are specific, e.g. they have specific
> compatibles.
>
> >
> > If you don't consider that spec to be correct DT bindings, please
> > provide a definition of what that is, and / or reasonable alternatives.
> >
> > Also, no, a device specific binding isn't reasonable here, because we
> > *don't* have a device. From a technical standpoint, the firmware creates
>
> You touch internal parts of the SoC and you list very specific SoC
> parts. Interconnect is internal part of the SoC and only specific
> devices are using it.
>
> You define here generic SW construct for something which is opposite of
> generic: the interconnect connecting two specific, unique components of
> one, given SoC.
>
> > the framebuffer, Linux just uses it. Just like you don't have a
> > device/platform specific compatible for PSCI, SCPI, et al.
>
> They follow some sort of spec and still they do not reference chosen
> SoC-design-specific properties.
ish.
I mean, on theory, you're absolutely correct. In practice,
assigned-clock-parents, assigned-clock-rates, or protected-clocks for
example exist and are *only* about SoC-design specific behaviours.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [PATCH] staging: sm750fb: fix all checkpatch warnings in .c and .h files
From: Dan Carpenter @ 2025-06-30 16:07 UTC (permalink / raw)
To: Manish Kumar
Cc: sudipm.mukherjee, teddy.wang, gregkh, linux-fbdev, linux-staging,
linux-kernel
In-Reply-To: <20250628082305.20847-1-manish1588@gmail.com>
On Sat, Jun 28, 2025 at 01:53:05PM +0530, Manish Kumar wrote:
> This patch resolves all checkpatch.pl --strict warnings in the
> sm750fb driver source files, including both C and header files.
>
> Changes include:
> - Replacing CamelCase identifiers with snake_case
> - Avoiding chained assignments
> - Fixing indentation, spacing, and alignment issues
> - Updating function declarations and comment styles
> - Making code conform to kernel coding style
>
> No functional changes.
>
> Signed-off-by: Manish Kumar <manish1588@gmail.com>
> ---
> drivers/staging/sm750fb/sm750.c | 90 ++++++++++---------
> drivers/staging/sm750fb/sm750.h | 32 +++----
> drivers/staging/sm750fb/sm750_accel.c | 120 +++++++++++++-------------
> drivers/staging/sm750fb/sm750_hw.c | 24 +++---
> 4 files changed, 135 insertions(+), 131 deletions(-)
>
> diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
> index e77ad73f0db1..8794195a9594 100644
> --- a/drivers/staging/sm750fb/sm750.c
> +++ b/drivers/staging/sm750fb/sm750.c
> @@ -33,7 +33,7 @@
> static int g_hwcursor = 1;
> static int g_noaccel;
> static int g_nomtrr;
> -static const char * const g_fbmode[] = {NULL, NULL};
> +static const char *g_fbmode[] = {NULL, NULL};
You're removing a patch which we never applied. Start from a fresh
tree.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH v3 0/2] staging: fbtft: cleanup fbtft_framebuffer_alloc()
From: Dan Carpenter @ 2025-06-30 16:23 UTC (permalink / raw)
To: Abdun Nihaal
Cc: andy, gregkh, lorenzo.stoakes, tzimmermann, riyandhiman14, willy,
notro, thomas.petazzoni, dri-devel, linux-fbdev, linux-staging,
linux-kernel
In-Reply-To: <cover.1751207100.git.abdun.nihaal@gmail.com>
On Sun, Jun 29, 2025 at 08:10:09PM +0530, Abdun Nihaal wrote:
> Fix a potential memory leak and cleanup error handling in
> fbtft_framebuffer_alloc().
>
Thanks!
Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org>
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH v3 2/2] staging: fbtft: cleanup error handling in fbtft_framebuffer_alloc()
From: Greg KH @ 2025-06-30 17:16 UTC (permalink / raw)
To: Abdun Nihaal
Cc: andy, dan.carpenter, lorenzo.stoakes, tzimmermann, riyandhiman14,
willy, notro, thomas.petazzoni, dri-devel, linux-fbdev,
linux-staging, linux-kernel, Andy Shevchenko
In-Reply-To: <4e062d040806dc29d6124ac0309e741c63f13ac0.1751207100.git.abdun.nihaal@gmail.com>
On Sun, Jun 29, 2025 at 08:10:11PM +0530, Abdun Nihaal wrote:
> The error handling in fbtft_framebuffer_alloc() mixes managed allocation
> and plain allocation, and performs error handling in an order different
> from the order in fbtft_framebuffer_release().
>
> Fix them by moving vmem allocation closer to where it is used, and using
> plain kzalloc() for txbuf allocation.
>
> Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
> Suggested-by: Dan Carpenter <dan.carpenter@linaro.org>
> Signed-off-by: Abdun Nihaal <abdun.nihaal@gmail.com>
> ---
> v2->v3:
> - Remove the if check before kfree of txbuf.buf, because it is zero
> initialized on allocation, and kfree is NULL aware.
This patch does not apply to my tree, can you rebase and resend?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v3 2/2] staging: fbtft: cleanup error handling in fbtft_framebuffer_alloc()
From: Abdun Nihaal @ 2025-06-30 19:17 UTC (permalink / raw)
To: Greg KH
Cc: andy, dan.carpenter, lorenzo.stoakes, tzimmermann, riyandhiman14,
willy, notro, thomas.petazzoni, dri-devel, linux-fbdev,
linux-staging, linux-kernel, Andy Shevchenko
In-Reply-To: <2025063022-chump-pointless-6580@gregkh>
Hello Greg,
On Mon, Jun 30, 2025 at 07:16:38PM +0200, Greg KH wrote:
> This patch does not apply to my tree, can you rebase and resend?
I think you have added both the V1 patch and this current V3 patchset to
your tree, that's why this patch does not apply.
Commit eb2cb7dab60f ("staging: fbtft: fix potential memory leak in fbtft_framebuffer_alloc()")
on staging-testing is an older version of this patchset, and so it has to be dropped.
Regards,
Nihaal
^ permalink raw reply
* Re: [PATCH v3 2/2] staging: fbtft: cleanup error handling in fbtft_framebuffer_alloc()
From: Greg KH @ 2025-07-01 5:14 UTC (permalink / raw)
To: Abdun Nihaal
Cc: andy, dan.carpenter, lorenzo.stoakes, tzimmermann, riyandhiman14,
willy, notro, thomas.petazzoni, dri-devel, linux-fbdev,
linux-staging, linux-kernel, Andy Shevchenko
In-Reply-To: <ezkfonpaubsmw6gr4tutgnjmbhvsuwkhaiya7xozl2szfqi4f3@zmde3sfybyzi>
On Tue, Jul 01, 2025 at 12:47:22AM +0530, Abdun Nihaal wrote:
> Hello Greg,
>
> On Mon, Jun 30, 2025 at 07:16:38PM +0200, Greg KH wrote:
> > This patch does not apply to my tree, can you rebase and resend?
>
> I think you have added both the V1 patch and this current V3 patchset to
> your tree, that's why this patch does not apply.
>
> Commit eb2cb7dab60f ("staging: fbtft: fix potential memory leak in fbtft_framebuffer_alloc()")
> on staging-testing is an older version of this patchset, and so it has to be dropped.
I can't "drop" patches as my tree can not be rebased. Can you send a
fix-up patch instead, OR a revert?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v3 2/2] staging: fbtft: cleanup error handling in fbtft_framebuffer_alloc()
From: Andy Shevchenko @ 2025-07-01 7:03 UTC (permalink / raw)
To: Greg KH
Cc: Abdun Nihaal, andy, dan.carpenter, lorenzo.stoakes, tzimmermann,
riyandhiman14, willy, notro, thomas.petazzoni, dri-devel,
linux-fbdev, linux-staging, linux-kernel, Andy Shevchenko
In-Reply-To: <2025070128-amplifier-hyphen-cb09@gregkh>
On Tue, Jul 1, 2025 at 8:14 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> On Tue, Jul 01, 2025 at 12:47:22AM +0530, Abdun Nihaal wrote:
> > On Mon, Jun 30, 2025 at 07:16:38PM +0200, Greg KH wrote:
> > > This patch does not apply to my tree, can you rebase and resend?
> >
> > I think you have added both the V1 patch and this current V3 patchset to
> > your tree, that's why this patch does not apply.
> >
> > Commit eb2cb7dab60f ("staging: fbtft: fix potential memory leak in fbtft_framebuffer_alloc()")
> > on staging-testing is an older version of this patchset, and so it has to be dropped.
>
> I can't "drop" patches as my tree can not be rebased. Can you send a
> fix-up patch instead, OR a revert?
I think the cleaner solution will be revert and v3 patches together as
v4. Abdun, can you do that?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v3 2/2] staging: fbtft: cleanup error handling in fbtft_framebuffer_alloc()
From: Abdun Nihaal @ 2025-07-01 8:51 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Greg KH, andy, dan.carpenter, lorenzo.stoakes, tzimmermann,
riyandhiman14, willy, notro, thomas.petazzoni, dri-devel,
linux-fbdev, linux-staging, linux-kernel, Andy Shevchenko
In-Reply-To: <CAHp75Vev8r7KZ79=CoUtt0wbx0x3O0ZckesWtQrxs-MBpiBz_Q@mail.gmail.com>
On Tue, Jul 01, 2025 at 10:03:50AM +0300, Andy Shevchenko wrote:
> On Tue, Jul 1, 2025 at 8:14 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> > I can't "drop" patches as my tree can not be rebased. Can you send a
> > fix-up patch instead, OR a revert?
>
> I think the cleaner solution will be revert and v3 patches together as
> v4. Abdun, can you do that?
Sure, I'll send a revert in v4.
Regards,
Nihaal
^ permalink raw reply
* [PATCH] fbdev: fix potential buffer overflow in do_register_framebuffer()
From: Yongzhen Zhang @ 2025-07-01 9:07 UTC (permalink / raw)
To: simona, deller; +Cc: linux-fbdev, Yongzhen Zhang
The current implementation may lead to buffer overflow when:
1. Unregistration creates NULL gaps in registered_fb[]
2. All array slots become occupied despite num_registered_fb < FB_MAX
3. The registration loop exceeds array bounds
Add boundary check to prevent registered_fb[FB_MAX] access.
Signed-off-by: Yongzhen Zhang <zhangyongzhen@kylinos.cn>
---
drivers/video/fbdev/core/fbmem.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index dfcf5e4d1d4c..53f1719b1ae1 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -449,6 +449,9 @@ static int do_register_framebuffer(struct fb_info *fb_info)
if (!registered_fb[i])
break;
+ if (i >= FB_MAX)
+ return -ENXIO;
+
if (!fb_info->modelist.prev || !fb_info->modelist.next)
INIT_LIST_HEAD(&fb_info->modelist);
--
2.25.1
^ permalink raw reply related
* [PATCH 0/2] backlight: mp3309c: Drop pwm_apply_args()
From: Uwe Kleine-König @ 2025-07-01 9:22 UTC (permalink / raw)
To: Flavio Suligoi, Lee Jones, Daniel Thompson, Jingoo Han,
Helge Deller
Cc: Daniel Thompson, dri-devel, linux-fbdev, linux-pwm
Hello,
the first patch of this series is what I really care about: There are
hardly any drivers left that use pwm_apply_args(). When all of them are
converted to not use it any more, I intend to drop that function.
The 2nd patch is just a change that I noticed while editing the driver
that is IMHO nice. If you don't agree and only apply the first patch, I
won't argue. It's an alternative approach to what Daniel Thompson did in
commit 7ee6478d5aa9 ("backlight: mp3309c: Fully initialize
backlight_properties during probe").
Best regards
Uwe
Uwe Kleine-König (2):
backlight: mp3309c: Drop pwm_apply_args()
backlight: mp3309c: Initialize backlight properties without memset
drivers/video/backlight/mp3309c.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
base-commit: 1343433ed38923a21425c602e92120a1f1db5f7a
--
2.49.0
^ permalink raw reply
* [PATCH 1/2] backlight: mp3309c: Drop pwm_apply_args()
From: Uwe Kleine-König @ 2025-07-01 9:22 UTC (permalink / raw)
To: Flavio Suligoi, Lee Jones, Daniel Thompson, Jingoo Han,
Helge Deller
Cc: dri-devel, linux-fbdev, linux-pwm
In-Reply-To: <cover.1751361465.git.u.kleine-koenig@baylibre.com>
pwm_apply_args() sole purpose is to initialize all parameters specified
in the device tree for consumers that rely on pwm_config() and
pwm_enable(). The mp3309c backlight driver uses pwm_apply_might_sleep()
which gets passed the full configuration and so doesn't rely on the
default being explicitly applied.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
---
drivers/video/backlight/mp3309c.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/backlight/mp3309c.c b/drivers/video/backlight/mp3309c.c
index 372058e26129..bb4e85531cea 100644
--- a/drivers/video/backlight/mp3309c.c
+++ b/drivers/video/backlight/mp3309c.c
@@ -222,7 +222,6 @@ static int mp3309c_parse_fwnode(struct mp3309c_chip *chip,
if (IS_ERR(chip->pwmd))
return dev_err_probe(dev, PTR_ERR(chip->pwmd), "error getting pwm data\n");
pdata->dimming_mode = DIMMING_PWM;
- pwm_apply_args(chip->pwmd);
}
/*
--
2.49.0
^ permalink raw reply related
* [PATCH 2/2] backlight: mp3309c: Initialize backlight properties without memset
From: Uwe Kleine-König @ 2025-07-01 9:22 UTC (permalink / raw)
To: Flavio Suligoi, Lee Jones, Daniel Thompson, Jingoo Han,
Helge Deller
Cc: dri-devel, linux-fbdev, linux-pwm
In-Reply-To: <cover.1751361465.git.u.kleine-koenig@baylibre.com>
Assigning values to a struct using a compound literal (since C99) also
guarantees that all unspecified struct members are empty-initialized, so
it properly replaces the memset to zero.
The code looks a bit nicer and more idiomatic (though that might be
subjective?). The resulting binary is a bit smaller. On ARCH=arm with
an allnoconfig + minimal changes to enable the mp3309c driver the
difference is 12 bytes.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
---
drivers/video/backlight/mp3309c.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/video/backlight/mp3309c.c b/drivers/video/backlight/mp3309c.c
index bb4e85531cea..9337110ce6e5 100644
--- a/drivers/video/backlight/mp3309c.c
+++ b/drivers/video/backlight/mp3309c.c
@@ -352,12 +352,13 @@ static int mp3309c_probe(struct i2c_client *client)
chip->pdata = pdata;
/* Backlight properties */
- memset(&props, 0, sizeof(struct backlight_properties));
- props.brightness = pdata->default_brightness;
- props.max_brightness = pdata->max_brightness;
- props.scale = BACKLIGHT_SCALE_LINEAR;
- props.type = BACKLIGHT_RAW;
- props.power = BACKLIGHT_POWER_ON;
+ props = (typeof(props)){
+ .brightness = pdata->default_brightness,
+ .max_brightness = pdata->max_brightness,
+ .scale = BACKLIGHT_SCALE_LINEAR,
+ .type = BACKLIGHT_RAW,
+ .power = BACKLIGHT_POWER_ON,
+ };
chip->bl = devm_backlight_device_register(dev, "mp3309c", dev, chip,
&mp3309c_bl_ops, &props);
if (IS_ERR(chip->bl))
--
2.49.0
^ permalink raw reply related
* [PATCH v4 0/2] staging: fbtft: cleanup fbtft_framebuffer_alloc()
From: Abdun Nihaal @ 2025-07-01 9:40 UTC (permalink / raw)
To: andy
Cc: Abdun Nihaal, dan.carpenter, gregkh, lorenzo.stoakes, tzimmermann,
riyandhiman14, willy, notro, thomas.petazzoni, dri-devel,
linux-fbdev, linux-staging, linux-kernel
Cleanup error handling in fbtft_framebuffer_alloc()
This patchset includes the revert commit for the v1 patch, and the
cleanup patch that is not yet applied.
I have not included the v3 patch ("staging: fbtft: fix potential memory
leak in fbtft_framebuffer_alloc()") in this patchset, as it has been
already applied on staging-testing
v4:
- Add a revert patch to remove v1 patch
- Not included the patch that is already applied on staging-testing
- Added Reviewed-by tags
v3:
- Remove a redundant check before calling kfree
v2:
- Change the earlier patch to also handle the error code returned by
fb_deferred_io_init() and update Fixes tag to point to the commit that
introduced the memory allocation (which leads to leak).
- Add second patch to make the error handling order symmetric to
fbtft_framebuffer_release() and also remove managed allocation for
txbuf as suggested by Andy and Dan.
Link to v3: https://lore.kernel.org/linux-staging/cover.1751207100.git.abdun.nihaal@gmail.com/
Link to v2: https://lore.kernel.org/linux-staging/cover.1751086324.git.abdun.nihaal@gmail.com/T/#md111471ddd69e6ddb0a6b98e565551ffbd791a34
Link to v1: https://lore.kernel.org/all/20250626172412.18355-1-abdun.nihaal@gmail.com/
Abdun Nihaal (2):
Revert "staging: fbtft: fix potential memory leak in
fbtft_framebuffer_alloc()"
staging: fbtft: cleanup error handling in fbtft_framebuffer_alloc()
drivers/staging/fbtft/fbtft-core.c | 32 +++++++++++++++---------------
1 file changed, 16 insertions(+), 16 deletions(-)
--
2.43.0
^ 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