* Re: [PATCH v2 2/7] backlight: qcom-wled: Support ovp values for PMI8994
From: Daniel Thompson @ 2026-01-09 13:33 UTC (permalink / raw)
To: Konrad Dybcio
Cc: barnabas.czeman, Lee Jones, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Kiran Gunda,
Helge Deller, Luca Weiss, Konrad Dybcio, Eugene Lepshy,
Gianluca Boiano, Alejandro Tafalla, dri-devel, linux-leds,
devicetree, linux-kernel, linux-arm-msm, linux-fbdev
In-Reply-To: <0fe51f7f-9b77-4bff-ab1c-21c44a863a7a@oss.qualcomm.com>
On Fri, Jan 09, 2026 at 12:09:11PM +0100, Konrad Dybcio wrote:
> On 1/9/26 7:36 AM, barnabas.czeman@mainlining.org wrote:
> > On 2026-01-08 12:28, Daniel Thompson wrote:
> >> On Thu, Jan 08, 2026 at 04:43:20AM +0100, Barnabás Czémán wrote:
> >>> WLED4 found in PMI8994 supports different ovp values.
> >>>
> >>> Fixes: 6fc632d3e3e0 ("video: backlight: qcom-wled: Add PMI8994 compatible")
> >>> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> >>> Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
> >>> ---
> >>> drivers/video/backlight/qcom-wled.c | 41 +++++++++++++++++++++++++++++++++++--
> >>> 1 file changed, 39 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/drivers/video/backlight/qcom-wled.c b/drivers/video/backlight/qcom-wled.c
> >>> index a63bb42c8f8b..5decbd39b789 100644
> >>> --- a/drivers/video/backlight/qcom-wled.c
> >>> +++ b/drivers/video/backlight/qcom-wled.c
> >>> @@ -1244,6 +1244,15 @@ static const struct wled_var_cfg wled4_ovp_cfg = {
> >>> .size = ARRAY_SIZE(wled4_ovp_values),
> >>> };
> >>>
> >>> +static const u32 pmi8994_wled_ovp_values[] = {
> >>> + 31000, 29500, 19400, 17800,
> >>> +};
> >>> +
> >>> +static const struct wled_var_cfg pmi8994_wled_ovp_cfg = {
> >>> + .values = pmi8994_wled_ovp_values,
> >>> + .size = ARRAY_SIZE(pmi8994_wled_ovp_values),
> >>> +};
> >>> +
> >>
> >> Do these *have* to be named after one of the two PMICs that implement
> >> this OVP range.
> >>
> >> Would something like wled4_alternative_ovp_values[] (and the same
> >> throughout the patch) be more descriptive?
> > I don't know. I don't like the PMIC naming either but at least it
> > descriptive about wich PMIC is needing these values.
It's the descriptive but wrong element I dislike (pmi8994_wled_ovp_cfg
is used by pmi8550).
I know these things crop up for "historical reasons" when is appears in
the same patchset I have to question the naming.
> > I think PMIC naming would be fine if compatibles what representing the
> > same configurations would be deprecated and used as a fallback compatbile
> > style.
> > I mean we could kept the first added compatible for a configuration.
> > Maybe they should be named diferently i don't know if WLEDs have subversion.
>
> Every PMIC peripheral is versioned.
>
> WLED has separate versioning for the digital and analog parts:
>
> PMIC ANA DIG
> ---------------------------
> PMI8937 2.0 1.0 (also needs the quirk)
> PMI8950 2.0 1.0
> PMI8994 2.0 1.0
> PMI8996 2.1 1.0
> PMI8998 3.1 3.0
> PM660L 4.1 4.0
>
> I don't know for sure if "PMIC4 with WLED ANA/DIG 3.x" a good
> discriminant though..
Peronally I'd prefer that to making them all use pmi8994 structures.
It's a much better link back to the docs (at least for those with the
power to read them ;-) ).
Daniel.
^ permalink raw reply
* Re: [PATCH v2 2/7] backlight: qcom-wled: Support ovp values for PMI8994
From: barnabas.czeman @ 2026-01-09 15:42 UTC (permalink / raw)
To: Daniel Thompson
Cc: Konrad Dybcio, Lee Jones, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Kiran Gunda,
Helge Deller, Luca Weiss, Konrad Dybcio, Eugene Lepshy,
Gianluca Boiano, Alejandro Tafalla, dri-devel, linux-leds,
devicetree, linux-kernel, linux-arm-msm, linux-fbdev
In-Reply-To: <aWEDr3O9T7bASnj9@aspen.lan>
On 2026-01-09 14:33, Daniel Thompson wrote:
> On Fri, Jan 09, 2026 at 12:09:11PM +0100, Konrad Dybcio wrote:
>> On 1/9/26 7:36 AM, barnabas.czeman@mainlining.org wrote:
>> > On 2026-01-08 12:28, Daniel Thompson wrote:
>> >> On Thu, Jan 08, 2026 at 04:43:20AM +0100, Barnabás Czémán wrote:
>> >>> WLED4 found in PMI8994 supports different ovp values.
>> >>>
>> >>> Fixes: 6fc632d3e3e0 ("video: backlight: qcom-wled: Add PMI8994 compatible")
>> >>> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>> >>> Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
>> >>> ---
>> >>> drivers/video/backlight/qcom-wled.c | 41 +++++++++++++++++++++++++++++++++++--
>> >>> 1 file changed, 39 insertions(+), 2 deletions(-)
>> >>>
>> >>> diff --git a/drivers/video/backlight/qcom-wled.c b/drivers/video/backlight/qcom-wled.c
>> >>> index a63bb42c8f8b..5decbd39b789 100644
>> >>> --- a/drivers/video/backlight/qcom-wled.c
>> >>> +++ b/drivers/video/backlight/qcom-wled.c
>> >>> @@ -1244,6 +1244,15 @@ static const struct wled_var_cfg wled4_ovp_cfg = {
>> >>> .size = ARRAY_SIZE(wled4_ovp_values),
>> >>> };
>> >>>
>> >>> +static const u32 pmi8994_wled_ovp_values[] = {
>> >>> + 31000, 29500, 19400, 17800,
>> >>> +};
>> >>> +
>> >>> +static const struct wled_var_cfg pmi8994_wled_ovp_cfg = {
>> >>> + .values = pmi8994_wled_ovp_values,
>> >>> + .size = ARRAY_SIZE(pmi8994_wled_ovp_values),
>> >>> +};
>> >>> +
>> >>
>> >> Do these *have* to be named after one of the two PMICs that implement
>> >> this OVP range.
>> >>
>> >> Would something like wled4_alternative_ovp_values[] (and the same
>> >> throughout the patch) be more descriptive?
>> > I don't know. I don't like the PMIC naming either but at least it
>> > descriptive about wich PMIC is needing these values.
>
> It's the descriptive but wrong element I dislike (pmi8994_wled_ovp_cfg
> is used by pmi8550).
No, pmi8950 is using pmi8994_wled_opts struct what is using
pmi8994_wled_ovp_cfg.
>
> I know these things crop up for "historical reasons" when is appears in
> the same patchset I have to question the naming.
>
>
>> > I think PMIC naming would be fine if compatibles what representing the
>> > same configurations would be deprecated and used as a fallback compatbile
>> > style.
>> > I mean we could kept the first added compatible for a configuration.
>> > Maybe they should be named diferently i don't know if WLEDs have subversion.
>>
>> Every PMIC peripheral is versioned.
>>
>> WLED has separate versioning for the digital and analog parts:
>>
>> PMIC ANA DIG
>> ---------------------------
>> PMI8937 2.0 1.0 (also needs the quirk)
>> PMI8950 2.0 1.0
>> PMI8994 2.0 1.0
>> PMI8996 2.1 1.0
>> PMI8998 3.1 3.0
>> PM660L 4.1 4.0
>>
>> I don't know for sure if "PMIC4 with WLED ANA/DIG 3.x" a good
>> discriminant though..
>
> Peronally I'd prefer that to making them all use pmi8994 structures.
> It's a much better link back to the docs (at least for those with the
> power to read them ;-) ).
>
>
> Daniel.
^ permalink raw reply
* Re: [PATCH v2 2/7] backlight: qcom-wled: Support ovp values for PMI8994
From: barnabas.czeman @ 2026-01-09 15:45 UTC (permalink / raw)
To: Daniel Thompson
Cc: Konrad Dybcio, Lee Jones, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Kiran Gunda,
Helge Deller, Luca Weiss, Konrad Dybcio, Eugene Lepshy,
Gianluca Boiano, Alejandro Tafalla, dri-devel, linux-leds,
devicetree, linux-kernel, linux-arm-msm, linux-fbdev
In-Reply-To: <00d0c357d31463272d786bcc9abfe295@mainlining.org>
On 2026-01-09 16:42, barnabas.czeman@mainlining.org wrote:
> On 2026-01-09 14:33, Daniel Thompson wrote:
>> On Fri, Jan 09, 2026 at 12:09:11PM +0100, Konrad Dybcio wrote:
>>> On 1/9/26 7:36 AM, barnabas.czeman@mainlining.org wrote:
>>> > On 2026-01-08 12:28, Daniel Thompson wrote:
>>> >> On Thu, Jan 08, 2026 at 04:43:20AM +0100, Barnabás Czémán wrote:
>>> >>> WLED4 found in PMI8994 supports different ovp values.
>>> >>>
>>> >>> Fixes: 6fc632d3e3e0 ("video: backlight: qcom-wled: Add PMI8994 compatible")
>>> >>> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>> >>> Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
>>> >>> ---
>>> >>> drivers/video/backlight/qcom-wled.c | 41 +++++++++++++++++++++++++++++++++++--
>>> >>> 1 file changed, 39 insertions(+), 2 deletions(-)
>>> >>>
>>> >>> diff --git a/drivers/video/backlight/qcom-wled.c b/drivers/video/backlight/qcom-wled.c
>>> >>> index a63bb42c8f8b..5decbd39b789 100644
>>> >>> --- a/drivers/video/backlight/qcom-wled.c
>>> >>> +++ b/drivers/video/backlight/qcom-wled.c
>>> >>> @@ -1244,6 +1244,15 @@ static const struct wled_var_cfg wled4_ovp_cfg = {
>>> >>> .size = ARRAY_SIZE(wled4_ovp_values),
>>> >>> };
>>> >>>
>>> >>> +static const u32 pmi8994_wled_ovp_values[] = {
>>> >>> + 31000, 29500, 19400, 17800,
>>> >>> +};
>>> >>> +
>>> >>> +static const struct wled_var_cfg pmi8994_wled_ovp_cfg = {
>>> >>> + .values = pmi8994_wled_ovp_values,
>>> >>> + .size = ARRAY_SIZE(pmi8994_wled_ovp_values),
>>> >>> +};
>>> >>> +
>>> >>
>>> >> Do these *have* to be named after one of the two PMICs that implement
>>> >> this OVP range.
>>> >>
>>> >> Would something like wled4_alternative_ovp_values[] (and the same
>>> >> throughout the patch) be more descriptive?
>>> > I don't know. I don't like the PMIC naming either but at least it
>>> > descriptive about wich PMIC is needing these values.
>>
>> It's the descriptive but wrong element I dislike (pmi8994_wled_ovp_cfg
>> is used by pmi8550).
> No, pmi8950 is using pmi8994_wled_opts struct what is using
> pmi8994_wled_ovp_cfg.
Maybe would be better move opts to compatible data.
>>
>> I know these things crop up for "historical reasons" when is appears
>> in
>> the same patchset I have to question the naming.
>>
>>
>>> > I think PMIC naming would be fine if compatibles what representing the
>>> > same configurations would be deprecated and used as a fallback compatbile
>>> > style.
>>> > I mean we could kept the first added compatible for a configuration.
>>> > Maybe they should be named diferently i don't know if WLEDs have subversion.
>>>
>>> Every PMIC peripheral is versioned.
>>>
>>> WLED has separate versioning for the digital and analog parts:
>>>
>>> PMIC ANA DIG
>>> ---------------------------
>>> PMI8937 2.0 1.0 (also needs the quirk)
>>> PMI8950 2.0 1.0
>>> PMI8994 2.0 1.0
>>> PMI8996 2.1 1.0
>>> PMI8998 3.1 3.0
>>> PM660L 4.1 4.0
>>>
>>> I don't know for sure if "PMIC4 with WLED ANA/DIG 3.x" a good
>>> discriminant though..
>>
>> Peronally I'd prefer that to making them all use pmi8994 structures.
>> It's a much better link back to the docs (at least for those with the
>> power to read them ;-) ).
>>
>>
>> Daniel.
^ permalink raw reply
* Re: [PATCH 00/12] Recover sysfb after DRM probe failure
From: Zack Rusin @ 2026-01-10 4:52 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: dri-devel, Alex Deucher, amd-gfx, Ard Biesheuvel, Ce Sun,
Chia-I Wu, Christian König, Danilo Krummrich, Dave Airlie,
Deepak Rawat, Dmitry Osipenko, Gerd Hoffmann, Gurchetan Singh,
Hans de Goede, Hawking Zhang, Helge Deller, intel-gfx, intel-xe,
Jani Nikula, Javier Martinez Canillas, Jocelyn Falempe,
Joonas Lahtinen, Lijo Lazar, linux-efi, linux-fbdev, linux-hyperv,
linux-kernel, Lucas De Marchi, Lyude Paul, Maarten Lankhorst,
Mario Limonciello (AMD), Mario Limonciello, Maxime Ripard,
nouveau, Rodrigo Vivi, Simona Vetter, spice-devel,
Thomas Hellström, Timur Kristóf, Tvrtko Ursulin,
virtualization, Vitaly Prosyak
In-Reply-To: <c816f7ed-66e0-4773-b3d1-4769234bd30b@suse.de>
[-- Attachment #1: Type: text/plain, Size: 3519 bytes --]
On Fri, Jan 9, 2026 at 5:34 AM Thomas Zimmermann <tzimmermann@suse.de> wrote:
>
> Hi
>
> Am 29.12.25 um 22:58 schrieb Zack Rusin:
> > Almost a rite of passage for every DRM developer and most Linux users
> > is upgrading your DRM driver/updating boot flags/changing some config
> > and having DRM driver fail at probe resulting in a blank screen.
> >
> > Currently there's no way to recover from DRM driver probe failure. PCI
> > DRM driver explicitly throw out the existing sysfb to get exclusive
> > access to PCI resources so if the probe fails the system is left without
> > a functioning display driver.
> >
> > Add code to sysfb to recever system framebuffer when DRM driver's probe
> > fails. This means that a DRM driver that fails to load reloads the system
> > framebuffer driver.
> >
> > This works best with simpledrm. Without it Xorg won't recover because
> > it still tries to load the vendor specific driver which ends up usually
> > not working at all. With simpledrm the system recovers really nicely
> > ending up with a working console and not a blank screen.
> >
> > There's a caveat in that some hardware might require some special magic
> > register write to recover EFI display. I'd appreciate it a lot if
> > maintainers could introduce a temporary failure in their drivers
> > probe to validate that the sysfb recovers and they get a working console.
> > The easiest way to double check it is by adding:
> > /* XXX: Temporary failure to test sysfb restore - REMOVE BEFORE COMMIT */
> > dev_info(&pdev->dev, "Testing sysfb restore: forcing probe failure\n");
> > ret = -EINVAL;
> > goto out_error;
> > or such right after the devm_aperture_remove_conflicting_pci_devices .
>
> Recovering the display like that is guess work and will at best work
> with simple discrete devices where the framebuffer is always located in
> a confined graphics aperture.
>
> But the problem you're trying to solve is a real one.
>
> What we'd want to do instead is to take the initial hardware state into
> account when we do the initial mode-setting operation.
>
> The first step is to move each driver's remove_conflicting_devices call
> to the latest possible location in the probe function. We usually do it
> first, because that's easy. But on most hardware, it could happen much
> later.
Well, some drivers (vbox, vmwgfx, bochs and currus-qemu) do it because
they request pci regions which is going to fail otherwise. Because
grabbining the pci resources is in general the very first thing that
those drivers need to do to setup anything, we
remove_conflicting_devices first or at least very early.
I also don't think it's possible or even desirable by some drivers to
reuse the initial state, good example here is vmwgfx where by default
some people will setup their vm's with e.g. 8mb ram, when the vmwgfx
loads we allow scanning out from system memory, so you can set your vm
up with 8mb of vram but still use 4k resolutions when the driver
loads, this way the suspend size of the vm is very predictable (tiny
vram plus whatever ram was setup) while still allowing a lot of
flexibility.
In general I think however this is planned it's two or three separate series:
1) infrastructure to reload the sysfb driver (what this series is)
2) making sure that drivers that do want to recover cleanly actually
clean out all the state on exit properly,
3) abstracting at least some of that cleanup in some driver independent way
z
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5414 bytes --]
^ permalink raw reply
* [PATCH] video/logo: don't select LOGO_LINUX_MONO and LOGO_LINUX_VGA16 by default
From: Vincent Mailhol @ 2026-01-10 12:23 UTC (permalink / raw)
To: Helge Deller; +Cc: linux-fbdev, dri-devel, linux-kernel, Vincent Mailhol
Nowadays, nearly all systems have a color depth of eight or more and
are thus able to display the clut224 logo. This means that the
monochrome and vga16 logos will never be displayed on an average
machine and are thus just a waste of bytes.
Set CONFIG_LOGO_LINUX_MONO and CONFIG_LOGO_LINUX_VGA16 configuration
symbols to no by default.
Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
---
To be applied on top of my previous "video/logo: allow custom boot
logo and simplify logic" series:
Link: https://lore.kernel.org/all/20260108-custom-logo-v3-0-5a7aada7a6d4@kernel.org/
---
drivers/video/logo/Kconfig | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/video/logo/Kconfig b/drivers/video/logo/Kconfig
index 34ee207e5e77..cda15b95891e 100644
--- a/drivers/video/logo/Kconfig
+++ b/drivers/video/logo/Kconfig
@@ -20,7 +20,6 @@ config FB_LOGO_EXTRA
config LOGO_LINUX_MONO
bool "Standard black and white Linux logo"
- default y
config LOGO_LINUX_MONO_FILE
string "Monochrome logo .pbm file"
@@ -38,7 +37,6 @@ config LOGO_LINUX_MONO_FILE
config LOGO_LINUX_VGA16
bool "Standard 16-color Linux logo"
- default y
config LOGO_LINUX_VGA16_FILE
string "16-color logo .ppm file"
---
base-commit: f10c325a345fef0a688a2bcdfab1540d1c924148
change-id: 20260110-mono_and_vga16_logos_default_to_no-fea83b350250
prerequisite-change-id: 20251227-custom-logo-932df316a02c:v3
prerequisite-patch-id: 5053eddfae57689a621f3224acc18742a25c2887
prerequisite-patch-id: 2fd02272fb8f94575c67124366f58811dcceb6ad
prerequisite-patch-id: 81d5632ac8717a56b335bb356e8fe5d9e8b1639f
prerequisite-patch-id: 268d8fb7ce93d0cb137c32b6f149fda376da37e8
prerequisite-patch-id: f6229ba399af73d57a647050a8f0f6871c4a96ef
prerequisite-patch-id: 6a6d392a9acf6eb2fe2827e3beebbc4b341f50a5
prerequisite-patch-id: 359180711835dc73be129380a5664210e19d50f1
Best regards,
--
Vincent Mailhol <mailhol@kernel.org>
^ permalink raw reply related
* Re: [PATCH v2] fbdev: bitblit: bound-check glyph index in bit_putcs*
From: Woody Suwalski @ 2026-01-10 13:20 UTC (permalink / raw)
To: Vitaly Chikunov, Junjie Cao
Cc: Thomas Zimmermann, Simona Vetter, Helge Deller, Zsolt Kajtar,
Albin Babu Varghese, linux-fbdev, dri-devel, linux-kernel, stable,
regressions, Greg Kroah-Hartman
In-Reply-To: <aU23brU4lZqIkw4Z@altlinux.org>
Vitaly Chikunov wrote:
> Dear linux-fbdev, stable,
>
> On Mon, Oct 20, 2025 at 09:47:01PM +0800, Junjie Cao wrote:
>> bit_putcs_aligned()/unaligned() derived the glyph pointer from the
>> character value masked by 0xff/0x1ff, which may exceed the actual font's
>> glyph count and read past the end of the built-in font array.
>> Clamp the index to the actual glyph count before computing the address.
>>
>> This fixes a global out-of-bounds read reported by syzbot.
>>
>> Reported-by: syzbot+793cf822d213be1a74f2@syzkaller.appspotmail.com
>> Closes: https://syzkaller.appspot.com/bug?extid=793cf822d213be1a74f2
>> Tested-by: syzbot+793cf822d213be1a74f2@syzkaller.appspotmail.com
>> Signed-off-by: Junjie Cao <junjie.cao@intel.com>
> This commit is applied to v5.10.247 and causes a regression: when
> switching VT with ctrl-alt-f2 the screen is blank or completely filled
> with angle characters, then new text is not appearing (or not visible).
>
> This commit is found with git bisect from v5.10.246 to v5.10.247:
>
> 0998a6cb232674408a03e8561dc15aa266b2f53b is the first bad commit
> commit 0998a6cb232674408a03e8561dc15aa266b2f53b
> Author: Junjie Cao <junjie.cao@intel.com>
> AuthorDate: 2025-10-20 21:47:01 +0800
> Commit: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> CommitDate: 2025-12-07 06:08:07 +0900
>
> fbdev: bitblit: bound-check glyph index in bit_putcs*
>
> commit 18c4ef4e765a798b47980555ed665d78b71aeadf upstream.
>
> bit_putcs_aligned()/unaligned() derived the glyph pointer from the
> character value masked by 0xff/0x1ff, which may exceed the actual font's
> glyph count and read past the end of the built-in font array.
> Clamp the index to the actual glyph count before computing the address.
>
> This fixes a global out-of-bounds read reported by syzbot.
>
> Reported-by: syzbot+793cf822d213be1a74f2@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=793cf822d213be1a74f2
> Tested-by: syzbot+793cf822d213be1a74f2@syzkaller.appspotmail.com
> Signed-off-by: Junjie Cao <junjie.cao@intel.com>
> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> Signed-off-by: Helge Deller <deller@gmx.de>
> Cc: stable@vger.kernel.org
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> drivers/video/fbdev/core/bitblit.c | 16 ++++++++++++----
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
> The minimal reproducer in cli, after kernel is booted:
>
> date >/dev/tty2; chvt 2
>
> and the date does not appear.
>
> Thanks,
>
> #regzbot introduced: 0998a6cb232674408a03e8561dc15aa266b2f53b
>
>> ---
>> v1: https://lore.kernel.org/linux-fbdev/5d237d1a-a528-4205-a4d8-71709134f1e1@suse.de/
>> v1 -> v2:
>> - Fix indentation and add blank line after declarations with the .pl helper
>> - No functional changes
>>
>> drivers/video/fbdev/core/bitblit.c | 16 ++++++++++++----
>> 1 file changed, 12 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/video/fbdev/core/bitblit.c b/drivers/video/fbdev/core/bitblit.c
>> index 9d2e59796c3e..085ffb44c51a 100644
>> --- a/drivers/video/fbdev/core/bitblit.c
>> +++ b/drivers/video/fbdev/core/bitblit.c
>> @@ -79,12 +79,16 @@ static inline void bit_putcs_aligned(struct vc_data *vc, struct fb_info *info,
>> struct fb_image *image, u8 *buf, u8 *dst)
>> {
>> u16 charmask = vc->vc_hi_font_mask ? 0x1ff : 0xff;
>> + unsigned int charcnt = vc->vc_font.charcount;
>> u32 idx = vc->vc_font.width >> 3;
>> u8 *src;
>>
>> while (cnt--) {
>> - src = vc->vc_font.data + (scr_readw(s++)&
>> - charmask)*cellsize;
>> + u16 ch = scr_readw(s++) & charmask;
>> +
>> + if (ch >= charcnt)
>> + ch = 0;
>> + src = vc->vc_font.data + (unsigned int)ch * cellsize;
>>
>> if (attr) {
>> update_attr(buf, src, attr, vc);
>> @@ -112,14 +116,18 @@ static inline void bit_putcs_unaligned(struct vc_data *vc,
>> u8 *dst)
>> {
>> u16 charmask = vc->vc_hi_font_mask ? 0x1ff : 0xff;
>> + unsigned int charcnt = vc->vc_font.charcount;
>> u32 shift_low = 0, mod = vc->vc_font.width % 8;
>> u32 shift_high = 8;
>> u32 idx = vc->vc_font.width >> 3;
>> u8 *src;
>>
>> while (cnt--) {
>> - src = vc->vc_font.data + (scr_readw(s++)&
>> - charmask)*cellsize;
>> + u16 ch = scr_readw(s++) & charmask;
>> +
>> + if (ch >= charcnt)
>> + ch = 0;
>> + src = vc->vc_font.data + (unsigned int)ch * cellsize;
>>
>> if (attr) {
>> update_attr(buf, src, attr, vc);
>> --
>> 2.48.1
>>
I have done the same bisecting work, too bad I did not notice Vitaly's
work earlier :-(
There is a "cheap" workaround for systems before 5.11, (not addressing
the root issue but) working:
diff --git a/drivers/video/fbdev/core/bitblit.c
b/drivers/video/fbdev/core/bitblit.c
index 7c2fc9f..c5a1a9d 100644
--- a/drivers/video/fbdev/core/bitblit.c
+++ b/drivers/video/fbdev/core/bitblit.c
@@ -86,7 +86,7 @@ static inline void bit_putcs_aligned(struct vc_data
*vc, struct fb_info *info,
while (cnt--) {
u16 ch = scr_readw(s++) & charmask;
- if (ch >= charcnt)
+ if (charcnt && ch >= charcnt)
ch = 0;
src = vc->vc_font.data + (unsigned int)ch * cellsize;
@@ -125,7 +125,7 @@ static inline void bit_putcs_unaligned(struct
vc_data *vc,
while (cnt--) {
u16 ch = scr_readw(s++) & charmask;
- if (ch >= charcnt)
+ if (charcnt && ch >= charcnt)
ch = 0;
src = vc->vc_font.data + (unsigned int)ch * cellsize;
I will try next to go full backport from 5.11 as Thorsten has suggested.
However the bigger problem is that the fbdev patch has landed in the
5.4.302 EOL, and essentially the 5.4 EOL kernel is now hanging broken :-(
Thanks, Woody
^ permalink raw reply related
* Re: [PATCH v2] fbdev: bitblit: bound-check glyph index in bit_putcs*
From: Woody Suwalski @ 2026-01-11 5:26 UTC (permalink / raw)
To: Vitaly Chikunov, Junjie Cao
Cc: Thomas Zimmermann, Simona Vetter, Helge Deller, Zsolt Kajtar,
Albin Babu Varghese, linux-fbdev, dri-devel, linux-kernel, stable,
regressions, Greg Kroah-Hartman
In-Reply-To: <e6aac320-846d-eecf-0016-23b56d7cd854@gmail.com>
Woody Suwalski wrote:
> Vitaly Chikunov wrote:
>> Dear linux-fbdev, stable,
>>
>> On Mon, Oct 20, 2025 at 09:47:01PM +0800, Junjie Cao wrote:
>>> bit_putcs_aligned()/unaligned() derived the glyph pointer from the
>>> character value masked by 0xff/0x1ff, which may exceed the actual
>>> font's
>>> glyph count and read past the end of the built-in font array.
>>> Clamp the index to the actual glyph count before computing the address.
>>>
>>> This fixes a global out-of-bounds read reported by syzbot.
>>>
>>> Reported-by: syzbot+793cf822d213be1a74f2@syzkaller.appspotmail.com
>>> Closes: https://syzkaller.appspot.com/bug?extid=793cf822d213be1a74f2
>>> Tested-by: syzbot+793cf822d213be1a74f2@syzkaller.appspotmail.com
>>> Signed-off-by: Junjie Cao <junjie.cao@intel.com>
>> This commit is applied to v5.10.247 and causes a regression: when
>> switching VT with ctrl-alt-f2 the screen is blank or completely filled
>> with angle characters, then new text is not appearing (or not visible).
>>
>> This commit is found with git bisect from v5.10.246 to v5.10.247:
>>
>> 0998a6cb232674408a03e8561dc15aa266b2f53b is the first bad commit
>> commit 0998a6cb232674408a03e8561dc15aa266b2f53b
>> Author: Junjie Cao <junjie.cao@intel.com>
>> AuthorDate: 2025-10-20 21:47:01 +0800
>> Commit: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> CommitDate: 2025-12-07 06:08:07 +0900
>>
>> fbdev: bitblit: bound-check glyph index in bit_putcs*
>>
>> commit 18c4ef4e765a798b47980555ed665d78b71aeadf upstream.
>>
>> bit_putcs_aligned()/unaligned() derived the glyph pointer from
>> the
>> character value masked by 0xff/0x1ff, which may exceed the
>> actual font's
>> glyph count and read past the end of the built-in font array.
>> Clamp the index to the actual glyph count before computing the
>> address.
>>
>> This fixes a global out-of-bounds read reported by syzbot.
>>
>> Reported-by:
>> syzbot+793cf822d213be1a74f2@syzkaller.appspotmail.com
>> Closes:
>> https://syzkaller.appspot.com/bug?extid=793cf822d213be1a74f2
>> Tested-by: syzbot+793cf822d213be1a74f2@syzkaller.appspotmail.com
>> Signed-off-by: Junjie Cao <junjie.cao@intel.com>
>> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
>> Signed-off-by: Helge Deller <deller@gmx.de>
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>
>> drivers/video/fbdev/core/bitblit.c | 16 ++++++++++++----
>> 1 file changed, 12 insertions(+), 4 deletions(-)
>>
>> The minimal reproducer in cli, after kernel is booted:
>>
>> date >/dev/tty2; chvt 2
>>
>> and the date does not appear.
>>
>> Thanks,
>>
>> #regzbot introduced: 0998a6cb232674408a03e8561dc15aa266b2f53b
>>
>>> ---
>>> v1:
>>> https://lore.kernel.org/linux-fbdev/5d237d1a-a528-4205-a4d8-71709134f1e1@suse.de/
>>> v1 -> v2:
>>> - Fix indentation and add blank line after declarations with the
>>> .pl helper
>>> - No functional changes
>>>
>>> drivers/video/fbdev/core/bitblit.c | 16 ++++++++++++----
>>> 1 file changed, 12 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/video/fbdev/core/bitblit.c
>>> b/drivers/video/fbdev/core/bitblit.c
>>> index 9d2e59796c3e..085ffb44c51a 100644
>>> --- a/drivers/video/fbdev/core/bitblit.c
>>> +++ b/drivers/video/fbdev/core/bitblit.c
>>> @@ -79,12 +79,16 @@ static inline void bit_putcs_aligned(struct
>>> vc_data *vc, struct fb_info *info,
>>> struct fb_image *image, u8 *buf, u8 *dst)
>>> {
>>> u16 charmask = vc->vc_hi_font_mask ? 0x1ff : 0xff;
>>> + unsigned int charcnt = vc->vc_font.charcount;
>>> u32 idx = vc->vc_font.width >> 3;
>>> u8 *src;
>>> while (cnt--) {
>>> - src = vc->vc_font.data + (scr_readw(s++)&
>>> - charmask)*cellsize;
>>> + u16 ch = scr_readw(s++) & charmask;
>>> +
>>> + if (ch >= charcnt)
>>> + ch = 0;
>>> + src = vc->vc_font.data + (unsigned int)ch * cellsize;
>>> if (attr) {
>>> update_attr(buf, src, attr, vc);
>>> @@ -112,14 +116,18 @@ static inline void bit_putcs_unaligned(struct
>>> vc_data *vc,
>>> u8 *dst)
>>> {
>>> u16 charmask = vc->vc_hi_font_mask ? 0x1ff : 0xff;
>>> + unsigned int charcnt = vc->vc_font.charcount;
>>> u32 shift_low = 0, mod = vc->vc_font.width % 8;
>>> u32 shift_high = 8;
>>> u32 idx = vc->vc_font.width >> 3;
>>> u8 *src;
>>> while (cnt--) {
>>> - src = vc->vc_font.data + (scr_readw(s++)&
>>> - charmask)*cellsize;
>>> + u16 ch = scr_readw(s++) & charmask;
>>> +
>>> + if (ch >= charcnt)
>>> + ch = 0;
>>> + src = vc->vc_font.data + (unsigned int)ch * cellsize;
>>> if (attr) {
>>> update_attr(buf, src, attr, vc);
>>> --
>>> 2.48.1
>>>
> I have done the same bisecting work, too bad I did not notice Vitaly's
> work earlier :-(
>
> There is a "cheap" workaround for systems before 5.11, (not addressing
> the root issue but) working:
>
> diff --git a/drivers/video/fbdev/core/bitblit.c
> b/drivers/video/fbdev/core/bitblit.c
> index 7c2fc9f..c5a1a9d 100644
> --- a/drivers/video/fbdev/core/bitblit.c
> +++ b/drivers/video/fbdev/core/bitblit.c
> @@ -86,7 +86,7 @@ static inline void bit_putcs_aligned(struct vc_data
> *vc, struct fb_info *info,
> while (cnt--) {
> u16 ch = scr_readw(s++) & charmask;
>
> - if (ch >= charcnt)
> + if (charcnt && ch >= charcnt)
> ch = 0;
> src = vc->vc_font.data + (unsigned int)ch * cellsize;
>
> @@ -125,7 +125,7 @@ static inline void bit_putcs_unaligned(struct
> vc_data *vc,
> while (cnt--) {
> u16 ch = scr_readw(s++) & charmask;
>
> - if (ch >= charcnt)
> + if (charcnt && ch >= charcnt)
> ch = 0;
> src = vc->vc_font.data + (unsigned int)ch * cellsize;
>
> I will try next to go full backport from 5.11 as Thorsten has suggested.
>
> However the bigger problem is that the fbdev patch has landed in the
> 5.4.302 EOL, and essentially the 5.4 EOL kernel is now hanging broken :-(
>
> Thanks, Woody
>
I have tested the solution of backporting the series of patches from
5.11, it seems to be working OK.
However for the soon-to-be-EOL 5.10 and already EOL'ed 5.4 I would
suggest a simpler solution where we replace most of the logic from 5.11
with a hardcoded charcnt=256, if charcnt not set. This would take
advantage of the bugfix from Junjie, and be a minimal change for the
5.10 kernel (works on 5.4 as well)
--- a/drivers/video/fbdev/core/bitblit.c 2026-01-10
16:28:37.438569812 -0500
+++ b/drivers/video/fbdev/core/bitblit.c 2026-01-10
16:32:51.356236549 -0500
@@ -86,6 +86,8 @@ static inline void bit_putcs_aligned(str
while (cnt--) {
u16 ch = scr_readw(s++) & charmask;
+ if (charcnt == 0)
+ charcnt = 256;
if (ch >= charcnt)
ch = 0;
src = vc->vc_font.data + (unsigned int)ch * cellsize;
@@ -125,6 +127,8 @@ static inline void bit_putcs_unaligned(s
while (cnt--) {
u16 ch = scr_readw(s++) & charmask;
+ if (charcnt == 0)
+ charcnt = 256;
if (ch >= charcnt)
ch = 0;
src = vc->vc_font.data + (unsigned int)ch * cellsize;
Thanks, Woody
^ permalink raw reply
* Re: [PATCH] staging: sm750fb: improve clarity in TODO file
From: Greg Kroah-Hartman @ 2026-01-11 12:51 UTC (permalink / raw)
To: Tejas Chaudhari; +Cc: Sudip Mukherjee, Teddy Wang, linux-staging, linux-fbdev
In-Reply-To: <20251223185950.12328-1-tejaschaudhari038@gmail.com>
On Wed, Dec 24, 2025 at 12:29:50AM +0530, Tejas Chaudhari wrote:
> Improve wording and consistency in the sm750fb TODO file
> by clarifying references to checkpatch.pl and improving
> sentence readability.
>
> No functional changes.
>
> Signed-off-by: Tejas Chaudhari <tejaschaudhari038@gmail.com>
> ---
> drivers/staging/sm750fb/TODO | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/sm750fb/TODO b/drivers/staging/sm750fb/TODO
> index 7ce632d04..56ffd9b36 100644
> --- a/drivers/staging/sm750fb/TODO
> +++ b/drivers/staging/sm750fb/TODO
> @@ -1,8 +1,8 @@
> TODO:
> -- lots of checkpatch cleanup
> +- lots of checkpatch.pl cleanup
> - use kernel coding style
> - refine the code and remove unused code
> -- Implement hardware acceleration for imageblit if image->depth > 1
> +- Implement hardware acceleration for imageblit when image->depth > 1
> - must be ported to the atomic kms framework in the drm subsystem (which will
> give you a basic fbdev driver for free)
>
> --
> 2.39.5 (Apple Git-154)
>
>
Does not apply to the tree anymore due to other changes in this file,
sorry. Please rebase on the staging-testing branch and try again.
greg k-h
^ permalink raw reply
* Re: [PATCH] staging: sm750fb: rename fixId to fix_id
From: Greg KH @ 2026-01-11 12:51 UTC (permalink / raw)
To: Tejas Chaudhari; +Cc: linux-staging, linux-fbdev, sudipm.mukherjee, teddy.wang
In-Reply-To: <20251223192703.16502-1-tejaschaudhari038@gmail.com>
On Wed, Dec 24, 2025 at 12:57:03AM +0530, Tejas Chaudhari wrote:
> Rename the local fixId array to fix_id to follow
> kernel naming conventions and fix a checkpatch
> CamelCase warning.
>
> No functional changes.
>
> Signed-off-by: Tejas Chaudhari <tejaschaudhari038@gmail.com>
> ---
> drivers/staging/sm750fb/sm750.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
> index 15b5de33b..7afb58561 100644
> --- a/drivers/staging/sm750fb/sm750.c
> +++ b/drivers/staging/sm750fb/sm750.c
> @@ -740,7 +740,7 @@ static int lynxfb_set_fbinfo(struct fb_info *info, int index)
> "kernel HELPERS prepared vesa_modes",
> };
>
> - static const char *fixId[2] = {
> + static const char *fix_id[2] = {
> "sm750_fb1", "sm750_fb2",
> };
>
> @@ -862,7 +862,7 @@ static int lynxfb_set_fbinfo(struct fb_info *info, int index)
> fix->ywrapstep = crtc->ywrapstep;
> fix->accel = FB_ACCEL_SMI;
>
> - strscpy(fix->id, fixId[index], sizeof(fix->id));
> + strscpy(fix->id, fix_id[index], sizeof(fix->id));
>
> fix->smem_start = crtc->o_screen + sm750_dev->vidmem_start;
> pr_info("fix->smem_start = %lx\n", fix->smem_start);
> --
> 2.39.5 (Apple Git-154)
>
Does not apply to the tree anymore :(
^ permalink raw reply
* Re: [PATCH 1/3] staging: sm750fb: fix static const char array warning
From: Greg KH @ 2026-01-11 12:58 UTC (permalink / raw)
To: Lorenzo Simonelli
Cc: sudipm.mukherjee, teddy.wang, linux-staging, linux-kernel,
linux-fbdev
In-Reply-To: <20260107094714.300380-2-lorenzosimonelli02@gmail.com>
On Wed, Jan 07, 2026 at 10:47:12AM +0100, Lorenzo Simonelli wrote:
> Fix the checkpatch.pl warning: "static const char * array should
> probably be static const char * const" by adding the missing
> const modifier.
>
> Signed-off-by: Lorenzo Simonelli <lorenzosimonelli02@gmail.com>
> ---
> drivers/staging/sm750fb/sm750.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
> index fecd7457e..15b5de33b 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 *g_fbmode[] = {NULL, NULL};
> +static const char * const g_fbmode[] = {NULL, NULL};
> static const char *g_def_fbmode = "1024x768-32@60";
> static char *g_settings;
> static int g_dualview;
> --
> 2.52.0
>
Please ALWAYS test-build your patches before sending them out. That way
you catch obvious bugs like the one that this change introduces :(
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v4 1/4] fb: Add dev_of_fbinfo() helper for optional sysfs support
From: Helge Deller @ 2026-01-11 18:50 UTC (permalink / raw)
To: Chintan Patel, linux-fbdev, linux-staging, linux-omap
Cc: linux-kernel, dri-devel, tzimmermann, andy, gregkh
In-Reply-To: <20260107044258.528624-2-chintanlike@gmail.com>
On 1/7/26 05:42, Chintan Patel wrote:
> Add dev_of_fbinfo() to return the framebuffer struct device when
> CONFIG_FB_DEVICE is enabled, or NULL otherwise.
>
> This allows fbdev drivers to use sysfs interfaces via runtime checks
> instead of CONFIG_FB_DEVICE ifdefs, keeping the code clean while
> remaining fully buildable.
>
> Suggested-by: Helge Deller <deller@gmx.de>
> Reviewed-by: Helge Deller <deller@gmx.de>
> Reviewed-by: Andy Shevchenko <andy@kernel.org>
> Signed-off-by: Chintan Patel <chintanlike@gmail.com>
> ---
> include/linux/fb.h | 9 +++++++++
> 1 file changed, 9 insertions(+)
Whole v4 series applied to fbdev git tree.
Thanks!
Helge
^ permalink raw reply
* Re: [PATCH v4 3/4] fbdev: omapfb: Make FB_DEVICE dependency optional
From: Helge Deller @ 2026-01-11 18:52 UTC (permalink / raw)
To: Thomas Zimmermann, Chintan Patel, linux-fbdev, linux-staging,
linux-omap
Cc: linux-kernel, dri-devel, andy, gregkh
In-Reply-To: <aa922030-b0a1-4503-a3c0-7ce4c36c236e@suse.de>
On 1/7/26 08:33, Thomas Zimmermann wrote:
>
>
> Am 07.01.26 um 05:42 schrieb Chintan Patel:
>> omapfb provides several sysfs interfaces for framebuffer configuration
>> and debugging, but these are not required for the core driver.
>>
>> Remove the hard dependency on CONFIG_FB_DEVICE and make sysfs support
>> optional by using dev_of_fbinfo() to obtain the backing device at runtime.
>> When FB_DEVICE is disabled, sysfs operations are skipped while the code
>> still builds and is type-checked.
>>
>> Suggested-by: Helge Deller <deller@gmx.de>
>> Signed-off-by: Chintan Patel <chintanlike@gmail.com>
>
> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
applied to fbdev.
Thanks!
Helge
>> ---
>> drivers/video/fbdev/omap2/omapfb/Kconfig | 3 ++-
>> .../video/fbdev/omap2/omapfb/omapfb-sysfs.c | 18 ++++++++++++++----
>> 2 files changed, 16 insertions(+), 5 deletions(-)
^ permalink raw reply
* Re: [PATCH v3 0/7] video/logo: allow custom boot logo and simplify logic
From: Helge Deller @ 2026-01-11 18:59 UTC (permalink / raw)
To: Vincent Mailhol
Cc: Geert Uytterhoeven, linux-fbdev, dri-devel, linux-kernel,
linux-sh, linux-m68k
In-Reply-To: <20260108-custom-logo-v3-0-5a7aada7a6d4@kernel.org>
On 1/8/26 20:04, Vincent Mailhol wrote:
> This series allows the user to replace the default kernel boot logo by
> a custom one directly in the kernel configuration. This makes it
> easier to customise the boot logo without the need to modify the
> sources and allows such customisation to remain persistent after
> applying the configuration to another version of the kernel.
>
> Patch #1 and #2 are clean-up and preparation while patch #3 is the
> main feature of this series: making the boot logo customisable.
>
> While working on this, I realised that managing the logo file directly
> in Kbuild allows us to simplify how we handle the different existing
> variants of the Tux logo. This series thus ends with a clean-up which
> moves all the logo selection logic to Kbuild except from one special
> case (details in the patch description), simplifying the Makefile and
> the C code.
>
> Patch #4 and #5 do a tree-wide clean-up on the Kconfig symbols that
> are to be removed in patch #7. Patch #6 removes the Macintosh 68k logo
> which is conflicting with our simplification plans. Patch #7 finally
> simplifies the logic as explained above.
>
> Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
series applied to fbdev git tree.
Thanks!
Helge
> Changes in v3:
>
> - v2 broke the logo selection for m68k resulting in the MAC logo
> replacing the default logo on some machine where it shouldn't.
> v3 resolves the conflict by removing that logo.
>
> - Typo fix in patch #4 description.
>
> Link to v2: https://lore.kernel.org/r/20260101-custom-logo-v2-0-8eec06dfbf85@kernel.org
>
> Changes in v2:
>
> - By removing the logo_spe_clut224.o target from the Makefile, v1
> also removed the logo_spe_clut224 object which is still being
> referenced in
>
> arch/powerpc/platforms/cell/spu_base.c
>
> Restore the logo_spe_clut224.o target.
>
> Link to v1: https://lore.kernel.org/r/20251230-custom-logo-v1-0-4736374569ee@kernel.org
>
> ---
> Vincent Mailhol (7):
> video/logo: remove orphan .pgm Makefile rule
> video/logo: add a type parameter to the logo makefile function
> video/logo: allow custom logo
> newport_con: depend on LOGO_LINUX_CLUT224 instead of LOGO_SGI_CLUT224
> sh: defconfig: remove CONFIG_LOGO_SUPERH_*
> video/logo: remove logo_mac_clut224
> video/logo: move logo selection logic to Kconfig
>
> arch/sh/configs/dreamcast_defconfig | 2 -
> arch/sh/configs/ecovec24_defconfig | 2 -
> arch/sh/configs/kfr2r09_defconfig | 2 -
> arch/sh/configs/migor_defconfig | 2 -
> arch/sh/configs/rts7751r2d1_defconfig | 2 -
> arch/sh/configs/rts7751r2dplus_defconfig | 2 -
> arch/sh/configs/se7724_defconfig | 2 -
> arch/sh/configs/se7780_defconfig | 2 -
> arch/sh/configs/sh7785lcr_defconfig | 3 -
> arch/sh/configs/urquell_defconfig | 3 -
> drivers/video/console/newport_con.c | 4 +-
> drivers/video/logo/Kconfig | 82 +-
> drivers/video/logo/Makefile | 29 +-
> drivers/video/logo/logo.c | 46 +-
> drivers/video/logo/logo_mac_clut224.ppm | 1604 ------------------------------
> include/linux/linux_logo.h | 8 -
> 16 files changed, 63 insertions(+), 1732 deletions(-)
> ---
> base-commit: 9ace4753a5202b02191d54e9fdf7f9e3d02b85eb
> change-id: 20251227-custom-logo-932df316a02c
>
> Best regards,
^ permalink raw reply
* Re: [PATCH] video/logo: don't select LOGO_LINUX_MONO and LOGO_LINUX_VGA16 by default
From: Helge Deller @ 2026-01-11 19:12 UTC (permalink / raw)
To: Vincent Mailhol; +Cc: linux-fbdev, dri-devel, linux-kernel
In-Reply-To: <20260110-mono_and_vga16_logos_default_to_no-v1-1-30f36da979b4@kernel.org>
On 1/10/26 13:23, Vincent Mailhol wrote:
> Nowadays, nearly all systems have a color depth of eight or more and
> are thus able to display the clut224 logo. This means that the
> monochrome and vga16 logos will never be displayed on an average
> machine and are thus just a waste of bytes.
>
> Set CONFIG_LOGO_LINUX_MONO and CONFIG_LOGO_LINUX_VGA16 configuration
> symbols to no by default.
I agree, that on basically every system today there is no need for the
monochrome or VGA16 logo.
But I'm not sure about the historic/exotic platforms, e.g. m68, sparc
and so on.
So, maybe instead of dropping the default "y", we should e.g. do:
+ default y if SUPERH
+ default y if XYZ (some other architecture/platform) ???
+ default n (for all others)
The question is: Which arches may have needed the VGA16 or monochrome logo?
Helge
> Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
> ---
> To be applied on top of my previous "video/logo: allow custom boot
> logo and simplify logic" series:
>
> Link: https://lore.kernel.org/all/20260108-custom-logo-v3-0-5a7aada7a6d4@kernel.org/
> ---
> drivers/video/logo/Kconfig | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/video/logo/Kconfig b/drivers/video/logo/Kconfig
> index 34ee207e5e77..cda15b95891e 100644
> --- a/drivers/video/logo/Kconfig
> +++ b/drivers/video/logo/Kconfig
> @@ -20,7 +20,6 @@ config FB_LOGO_EXTRA
>
> config LOGO_LINUX_MONO
> bool "Standard black and white Linux logo"
> - default y
>
> config LOGO_LINUX_MONO_FILE
> string "Monochrome logo .pbm file"
> @@ -38,7 +37,6 @@ config LOGO_LINUX_MONO_FILE
>
> config LOGO_LINUX_VGA16
> bool "Standard 16-color Linux logo"
> - default y
>
> config LOGO_LINUX_VGA16_FILE
> string "16-color logo .ppm file"
>
> ---
> base-commit: f10c325a345fef0a688a2bcdfab1540d1c924148
> change-id: 20260110-mono_and_vga16_logos_default_to_no-fea83b350250
> prerequisite-change-id: 20251227-custom-logo-932df316a02c:v3
> prerequisite-patch-id: 5053eddfae57689a621f3224acc18742a25c2887
> prerequisite-patch-id: 2fd02272fb8f94575c67124366f58811dcceb6ad
> prerequisite-patch-id: 81d5632ac8717a56b335bb356e8fe5d9e8b1639f
> prerequisite-patch-id: 268d8fb7ce93d0cb137c32b6f149fda376da37e8
> prerequisite-patch-id: f6229ba399af73d57a647050a8f0f6871c4a96ef
> prerequisite-patch-id: 6a6d392a9acf6eb2fe2827e3beebbc4b341f50a5
> prerequisite-patch-id: 359180711835dc73be129380a5664210e19d50f1
>
> Best regards,
^ permalink raw reply
* Re: [PATCH v4 1/4] fb: Add dev_of_fbinfo() helper for optional sysfs support
From: Chintan Patel @ 2026-01-11 19:51 UTC (permalink / raw)
To: Helge Deller, linux-fbdev, linux-staging, linux-omap
Cc: linux-kernel, dri-devel, tzimmermann, andy, gregkh
In-Reply-To: <40911dd0-52e1-46de-b060-0372988291ca@gmx.de>
On 1/11/26 10:50, Helge Deller wrote:
> On 1/7/26 05:42, Chintan Patel wrote:
>> Add dev_of_fbinfo() to return the framebuffer struct device when
>> CONFIG_FB_DEVICE is enabled, or NULL otherwise.
>>
>> This allows fbdev drivers to use sysfs interfaces via runtime checks
>> instead of CONFIG_FB_DEVICE ifdefs, keeping the code clean while
>> remaining fully buildable.
>>
>> Suggested-by: Helge Deller <deller@gmx.de>
>> Reviewed-by: Helge Deller <deller@gmx.de>
>> Reviewed-by: Andy Shevchenko <andy@kernel.org>
>> Signed-off-by: Chintan Patel <chintanlike@gmail.com>
>> ---
>> include/linux/fb.h | 9 +++++++++
>> 1 file changed, 9 insertions(+)
>
> Whole v4 series applied to fbdev git tree.
>
Appreciate Helge and everyone who reviewed it! This was my first kernel
series and it was good learning experience for me.
^ permalink raw reply
* Re: [PATCH] video/logo: don't select LOGO_LINUX_MONO and LOGO_LINUX_VGA16 by default
From: Vincent Mailhol @ 2026-01-11 21:25 UTC (permalink / raw)
To: Helge Deller; +Cc: linux-fbdev, dri-devel, linux-kernel
In-Reply-To: <d48231e4-6c69-4948-99a9-121cd17e2db0@gmx.de>
On 11/01/2026 at 20:12, Helge Deller wrote:
> On 1/10/26 13:23, Vincent Mailhol wrote:
>> Nowadays, nearly all systems have a color depth of eight or more and
>> are thus able to display the clut224 logo. This means that the
>> monochrome and vga16 logos will never be displayed on an average
>> machine and are thus just a waste of bytes.
>>
>> Set CONFIG_LOGO_LINUX_MONO and CONFIG_LOGO_LINUX_VGA16 configuration
>> symbols to no by default.
>
> I agree, that on basically every system today there is no need for the
> monochrome or VGA16 logo.
> But I'm not sure about the historic/exotic platforms, e.g. m68, sparc
> and so on.
>
> So, maybe instead of dropping the default "y", we should e.g. do:
> + default y if SUPERH
SUPERH also has a clut224 logo, so I assume we can also default to no
for it.
> + default y if XYZ (some other architecture/platform) ???
> + default n (for all others)
>
> The question is: Which arches may have needed the VGA16 or monochrome logo?
My wild guess would be none. Furthermore, no one "needs" a logo. It is
just a fun thing to add. This is why the LOGO sub menu is turned off by
default and that none of the defconfig would automatically select a LOGO.
And so, because a user interaction is needed anyway, the few who still
want a monochrome or vga16 logo can turn the option back on just after
selecting the LOGO sub-menu.
I guess the same could be said in reverse: we could keep all the logo on
by default as it is now and the users who only need the clut224 can turn
off the monochrome and vga16. But let's go for the majority ;)
Well, if someone can come with the list you are looking for, I will
happily add it to the patch. We can wait for a couple weeks if you want,
no rush here!
Or your can already stage it in fbdev-next and I will send you a v2 as
needed. Maybe we will get more comments if this reaches linux-next?
Yours sincerely,
Vincent Mailhol
^ permalink raw reply
* [PATCH v5] staging: fbtft: use dev_of_fbinfo() instead of info->dev
From: Chintan Patel @ 2026-01-12 1:07 UTC (permalink / raw)
To: linux-fbdev, linux-staging, linux-omap
Cc: linux-kernel, dri-devel, tzimmermann, andy, deller, gregkh,
Chintan Patel, kernel test robot
This fixes commit
a06d03f9f238 ("staging: fbtft: Make FB_DEVICE dependency optional")
from my previous v4 series:
https://patchwork.kernel.org/project/dri-devel/cover/20260107044258.528624-1-chintanlike@gmail.com/
All direct accesses to info->dev or fb_info->dev are replaced with
dev_of_fbinfo() helper, improving readability and ensuring
compilation succeeds when CONFIG_FB_DEVICE=n.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202601110740.Y9XK5HtN-lkp@intel.com
Signed-off-by: Chintan Patel <chintanlike@gmail.com>
---
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 8a5ccc8ae0a1..309e81d7d208 100644
--- a/drivers/staging/fbtft/fbtft-core.c
+++ b/drivers/staging/fbtft/fbtft-core.c
@@ -364,8 +364,9 @@ static int fbtft_fb_setcolreg(unsigned int regno, unsigned int red,
{
unsigned int val;
int ret = 1;
+ struct device *dev = dev_of_fbinfo(info);
- dev_dbg(info->dev,
+ dev_dbg(dev,
"%s(regno=%u, red=0x%X, green=0x%X, blue=0x%X, trans=0x%X)\n",
__func__, regno, red, green, blue, transp);
@@ -389,9 +390,10 @@ static int fbtft_fb_setcolreg(unsigned int regno, unsigned int red,
static int fbtft_fb_blank(int blank, struct fb_info *info)
{
struct fbtft_par *par = info->par;
+ struct device *dev = dev_of_fbinfo(info);
int ret = -EINVAL;
- dev_dbg(info->dev, "%s(blank=%d)\n",
+ dev_dbg(dev, "%s(blank=%d)\n",
__func__, blank);
if (!par->fbtftops.blank)
@@ -739,6 +741,7 @@ int fbtft_register_framebuffer(struct fb_info *fb_info)
char text2[50] = "";
struct fbtft_par *par = fb_info->par;
struct spi_device *spi = par->spi;
+ struct device *dev = dev_of_fbinfo(fb_info);
/* sanity checks */
if (!par->fbtftops.init_display) {
@@ -793,7 +796,7 @@ int fbtft_register_framebuffer(struct fb_info *fb_info)
if (spi)
sprintf(text2, ", spi%d.%d at %d MHz", spi->controller->bus_num,
spi_get_chipselect(spi, 0), spi->max_speed_hz / 1000000);
- dev_info(fb_info->dev,
+ dev_info(dev,
"%s frame buffer, %dx%d, %d KiB video memory%s, fps=%lu%s\n",
fb_info->fix.id, fb_info->var.xres, fb_info->var.yres,
fb_info->fix.smem_len >> 10, text1,
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v5] staging: fbtft: use dev_of_fbinfo() instead of info->dev
From: Greg KH @ 2026-01-12 6:48 UTC (permalink / raw)
To: Chintan Patel
Cc: linux-fbdev, linux-staging, linux-omap, linux-kernel, dri-devel,
tzimmermann, andy, deller, kernel test robot
In-Reply-To: <20260112010740.186248-1-chintanlike@gmail.com>
On Sun, Jan 11, 2026 at 05:07:39PM -0800, Chintan Patel wrote:
> This fixes commit
> a06d03f9f238 ("staging: fbtft: Make FB_DEVICE dependency optional")
>
> from my previous v4 series:
> https://patchwork.kernel.org/project/dri-devel/cover/20260107044258.528624-1-chintanlike@gmail.com/
>
> All direct accesses to info->dev or fb_info->dev are replaced with
> dev_of_fbinfo() helper, improving readability and ensuring
> compilation succeeds when CONFIG_FB_DEVICE=n.
>
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202601110740.Y9XK5HtN-lkp@intel.com
> Signed-off-by: Chintan Patel <chintanlike@gmail.com>
> ---
> 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 8a5ccc8ae0a1..309e81d7d208 100644
> --- a/drivers/staging/fbtft/fbtft-core.c
> +++ b/drivers/staging/fbtft/fbtft-core.c
> @@ -364,8 +364,9 @@ static int fbtft_fb_setcolreg(unsigned int regno, unsigned int red,
> {
> unsigned int val;
> int ret = 1;
> + struct device *dev = dev_of_fbinfo(info);
>
> - dev_dbg(info->dev,
> + dev_dbg(dev,
> "%s(regno=%u, red=0x%X, green=0x%X, blue=0x%X, trans=0x%X)\n",
> __func__, regno, red, green, blue, transp);
>
> @@ -389,9 +390,10 @@ static int fbtft_fb_setcolreg(unsigned int regno, unsigned int red,
> static int fbtft_fb_blank(int blank, struct fb_info *info)
> {
> struct fbtft_par *par = info->par;
> + struct device *dev = dev_of_fbinfo(info);
> int ret = -EINVAL;
>
> - dev_dbg(info->dev, "%s(blank=%d)\n",
> + dev_dbg(dev, "%s(blank=%d)\n",
> __func__, blank);
>
> if (!par->fbtftops.blank)
> @@ -739,6 +741,7 @@ int fbtft_register_framebuffer(struct fb_info *fb_info)
> char text2[50] = "";
> struct fbtft_par *par = fb_info->par;
> struct spi_device *spi = par->spi;
> + struct device *dev = dev_of_fbinfo(fb_info);
>
> /* sanity checks */
> if (!par->fbtftops.init_display) {
> @@ -793,7 +796,7 @@ int fbtft_register_framebuffer(struct fb_info *fb_info)
> if (spi)
> sprintf(text2, ", spi%d.%d at %d MHz", spi->controller->bus_num,
> spi_get_chipselect(spi, 0), spi->max_speed_hz / 1000000);
> - dev_info(fb_info->dev,
> + dev_info(dev,
> "%s frame buffer, %dx%d, %d KiB video memory%s, fps=%lu%s\n",
> fb_info->fix.id, fb_info->var.xres, fb_info->var.yres,
> fb_info->fix.smem_len >> 10, text1,
> --
> 2.43.0
>
Hi,
This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him
a patch that has triggered this response. He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created. Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.
You are receiving this message because of the following common error(s)
as indicated below:
- This looks like a new version of a previously submitted patch, but you
did not list below the --- line any changes from the previous version.
Please read the section entitled "The canonical patch format" in the
kernel file, Documentation/process/submitting-patches.rst for what
needs to be done here to properly describe this.
If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.
thanks,
greg k-h's patch email bot
^ permalink raw reply
* Re: [PATCH v5] staging: fbtft: use dev_of_fbinfo() instead of info->dev
From: Andy Shevchenko @ 2026-01-12 7:07 UTC (permalink / raw)
To: Chintan Patel
Cc: linux-fbdev, linux-staging, linux-omap, linux-kernel, dri-devel,
tzimmermann, andy, deller, gregkh, kernel test robot
In-Reply-To: <20260112010740.186248-1-chintanlike@gmail.com>
On Mon, Jan 12, 2026 at 3:07 AM Chintan Patel <chintanlike@gmail.com> wrote:
> This fixes commit
> a06d03f9f238 ("staging: fbtft: Make FB_DEVICE dependency optional")
Convert to be as Fixes tag instead.
> from my previous v4 series:
> https://patchwork.kernel.org/project/dri-devel/cover/20260107044258.528624-1-chintanlike@gmail.com/
This is unneeded churn in the commit message, also this patch wrongly
marked as v5 that triggered Greg's bot response. You had to number it
as v1, but now please, address the above and below comments and make
it v6 with a Changelog added (explaining changes in v5 and in v6).
> All direct accesses to info->dev or fb_info->dev are replaced with
> dev_of_fbinfo() helper, improving readability and ensuring
> compilation succeeds when CONFIG_FB_DEVICE=n.
...
> @@ -364,8 +364,9 @@ static int fbtft_fb_setcolreg(unsigned int regno, unsigned int red,
> {
> unsigned int val;
> int ret = 1;
> + struct device *dev = dev_of_fbinfo(info);
Try to keep it in reversed xmas tree order.
...
> static int fbtft_fb_blank(int blank, struct fb_info *info)
> {
> struct fbtft_par *par = info->par;
> + struct device *dev = dev_of_fbinfo(info);
> int ret = -EINVAL;
Ditto.
> - dev_dbg(info->dev, "%s(blank=%d)\n",
> + dev_dbg(dev, "%s(blank=%d)\n",
> __func__, blank);
Since you are changing it anyway, make it one line.
...
> @@ -739,6 +741,7 @@ int fbtft_register_framebuffer(struct fb_info *fb_info)
> char text2[50] = "";
> struct fbtft_par *par = fb_info->par;
> struct spi_device *spi = par->spi;
> + struct device *dev = dev_of_fbinfo(fb_info);
Reversed xmas tree order (as much as it's possible with this added line).
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v5] staging: fbtft: use dev_of_fbinfo() instead of info->dev
From: Greg KH @ 2026-01-12 7:17 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Chintan Patel, linux-fbdev, linux-staging, linux-omap,
linux-kernel, dri-devel, tzimmermann, andy, deller,
kernel test robot
In-Reply-To: <CAHp75VeF+Sj=dxA4RZAvVddGSG3brUsy8kz7mvtst2YpqNm99w@mail.gmail.com>
On Mon, Jan 12, 2026 at 09:07:42AM +0200, Andy Shevchenko wrote:
> On Mon, Jan 12, 2026 at 3:07 AM Chintan Patel <chintanlike@gmail.com> wrote:
> > - dev_dbg(info->dev, "%s(blank=%d)\n",
> > + dev_dbg(dev, "%s(blank=%d)\n",
> > __func__, blank);
>
> Since you are changing it anyway, make it one line.
Wait, why would dev_dbg() ever had __func__ added to it? That's
automatically included in the output if the user wants it, please do not
duplicate it again.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v5] staging: fbtft: use dev_of_fbinfo() instead of info->dev
From: Thomas Zimmermann @ 2026-01-12 8:36 UTC (permalink / raw)
To: Chintan Patel, linux-fbdev, linux-staging, linux-omap
Cc: linux-kernel, dri-devel, andy, deller, gregkh, kernel test robot
In-Reply-To: <20260112010740.186248-1-chintanlike@gmail.com>
Hi
Am 12.01.26 um 02:07 schrieb Chintan Patel:
> This fixes commit
> a06d03f9f238 ("staging: fbtft: Make FB_DEVICE dependency optional")
>
> from my previous v4 series:
> https://patchwork.kernel.org/project/dri-devel/cover/20260107044258.528624-1-chintanlike@gmail.com/
>
> All direct accesses to info->dev or fb_info->dev are replaced with
> dev_of_fbinfo() helper, improving readability and ensuring
> compilation succeeds when CONFIG_FB_DEVICE=n.
>
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202601110740.Y9XK5HtN-lkp@intel.com
> Signed-off-by: Chintan Patel <chintanlike@gmail.com>
> ---
> 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 8a5ccc8ae0a1..309e81d7d208 100644
> --- a/drivers/staging/fbtft/fbtft-core.c
> +++ b/drivers/staging/fbtft/fbtft-core.c
> @@ -364,8 +364,9 @@ static int fbtft_fb_setcolreg(unsigned int regno, unsigned int red,
> {
> unsigned int val;
> int ret = 1;
> + struct device *dev = dev_of_fbinfo(info);
>
> - dev_dbg(info->dev,
> + dev_dbg(dev,
> "%s(regno=%u, red=0x%X, green=0x%X, blue=0x%X, trans=0x%X)\n",
> __func__, regno, red, green, blue, transp);
Rather use fb_dbg() from <linux/fb.h>. It will format the output
appropriately.
>
> @@ -389,9 +390,10 @@ static int fbtft_fb_setcolreg(unsigned int regno, unsigned int red,
> static int fbtft_fb_blank(int blank, struct fb_info *info)
> {
> struct fbtft_par *par = info->par;
> + struct device *dev = dev_of_fbinfo(info);
> int ret = -EINVAL;
>
> - dev_dbg(info->dev, "%s(blank=%d)\n",
> + dev_dbg(dev, "%s(blank=%d)\n",
> __func__, blank);
>
> if (!par->fbtftops.blank)
> @@ -739,6 +741,7 @@ int fbtft_register_framebuffer(struct fb_info *fb_info)
> char text2[50] = "";
> struct fbtft_par *par = fb_info->par;
> struct spi_device *spi = par->spi;
> + struct device *dev = dev_of_fbinfo(fb_info);
>
> /* sanity checks */
> if (!par->fbtftops.init_display) {
> @@ -793,7 +796,7 @@ int fbtft_register_framebuffer(struct fb_info *fb_info)
> if (spi)
> sprintf(text2, ", spi%d.%d at %d MHz", spi->controller->bus_num,
> spi_get_chipselect(spi, 0), spi->max_speed_hz / 1000000);
> - dev_info(fb_info->dev,
> + dev_info(dev,
fb_info() here.
Best regards
Thomas
> "%s frame buffer, %dx%d, %d KiB video memory%s, fps=%lu%s\n",
> fb_info->fix.id, fb_info->var.xres, fb_info->var.yres,
> fb_info->fix.smem_len >> 10, text1,
--
--
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 v5] staging: fbtft: use dev_of_fbinfo() instead of info->dev
From: kernel test robot @ 2026-01-12 10:05 UTC (permalink / raw)
To: Chintan Patel, linux-fbdev, linux-staging, linux-omap
Cc: llvm, oe-kbuild-all, linux-kernel, dri-devel, tzimmermann, andy,
deller, gregkh, Chintan Patel, kernel test robot
In-Reply-To: <20260112010740.186248-1-chintanlike@gmail.com>
Hi Chintan,
kernel test robot noticed the following build errors:
[auto build test ERROR on staging/staging-testing]
url: https://github.com/intel-lab-lkp/linux/commits/Chintan-Patel/staging-fbtft-use-dev_of_fbinfo-instead-of-info-dev/20260112-091221
base: staging/staging-testing
patch link: https://lore.kernel.org/r/20260112010740.186248-1-chintanlike%40gmail.com
patch subject: [PATCH v5] staging: fbtft: use dev_of_fbinfo() instead of info->dev
config: x86_64-randconfig-005-20260112 (https://download.01.org/0day-ci/archive/20260112/202601121705.2kgxpvsS-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
rustc: rustc 1.88.0 (6b00bc388 2025-06-23)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260112/202601121705.2kgxpvsS-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202601121705.2kgxpvsS-lkp@intel.com/
All errors (new ones prefixed by >>):
>> drivers/staging/fbtft/fbtft-core.c:367:23: error: call to undeclared function 'dev_of_fbinfo'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
367 | struct device *dev = dev_of_fbinfo(info);
| ^
>> drivers/staging/fbtft/fbtft-core.c:367:17: error: incompatible integer to pointer conversion initializing 'struct device *' with an expression of type 'int' [-Wint-conversion]
367 | struct device *dev = dev_of_fbinfo(info);
| ^ ~~~~~~~~~~~~~~~~~~~
drivers/staging/fbtft/fbtft-core.c:393:23: error: call to undeclared function 'dev_of_fbinfo'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
393 | struct device *dev = dev_of_fbinfo(info);
| ^
drivers/staging/fbtft/fbtft-core.c:393:17: error: incompatible integer to pointer conversion initializing 'struct device *' with an expression of type 'int' [-Wint-conversion]
393 | struct device *dev = dev_of_fbinfo(info);
| ^ ~~~~~~~~~~~~~~~~~~~
drivers/staging/fbtft/fbtft-core.c:744:23: error: call to undeclared function 'dev_of_fbinfo'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
744 | struct device *dev = dev_of_fbinfo(fb_info);
| ^
drivers/staging/fbtft/fbtft-core.c:744:17: error: incompatible integer to pointer conversion initializing 'struct device *' with an expression of type 'int' [-Wint-conversion]
744 | struct device *dev = dev_of_fbinfo(fb_info);
| ^ ~~~~~~~~~~~~~~~~~~~~~~
6 errors generated.
vim +/dev_of_fbinfo +367 drivers/staging/fbtft/fbtft-core.c
360
361 static int fbtft_fb_setcolreg(unsigned int regno, unsigned int red,
362 unsigned int green, unsigned int blue,
363 unsigned int transp, struct fb_info *info)
364 {
365 unsigned int val;
366 int ret = 1;
> 367 struct device *dev = dev_of_fbinfo(info);
368
369 dev_dbg(dev,
370 "%s(regno=%u, red=0x%X, green=0x%X, blue=0x%X, trans=0x%X)\n",
371 __func__, regno, red, green, blue, transp);
372
373 switch (info->fix.visual) {
374 case FB_VISUAL_TRUECOLOR:
375 if (regno < 16) {
376 u32 *pal = info->pseudo_palette;
377
378 val = chan_to_field(red, &info->var.red);
379 val |= chan_to_field(green, &info->var.green);
380 val |= chan_to_field(blue, &info->var.blue);
381
382 pal[regno] = val;
383 ret = 0;
384 }
385 break;
386 }
387 return ret;
388 }
389
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH 1/4] staging: sm750fb: Convert sw_i2c_read_sda to return bool
From: Karthikey Kadati @ 2026-01-12 10:25 UTC (permalink / raw)
To: sudipm.mukherjee, teddy.wang, gregkh
Cc: linux-fbdev, linux-staging, linux-kernel, Karthikey Kadati,
Unix Antigravity
The sw_i2c_read_sda function currently returns unsigned char (1 or 0).
Standardize it to return bool (true or false) to match kernel standards.
Signed-off-by: Unix Antigravity <unix.antigravity@test.com>
Signed-off-by: Karthikey Kadati <karthikey3608@gmail.com>
---
drivers/staging/sm750fb/ddk750_swi2c.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/sm750fb/ddk750_swi2c.c b/drivers/staging/sm750fb/ddk750_swi2c.c
index 0ef8d4ff2..9d48673d3 100644
--- a/drivers/staging/sm750fb/ddk750_swi2c.c
+++ b/drivers/staging/sm750fb/ddk750_swi2c.c
@@ -180,7 +180,7 @@ static void sw_i2c_sda(unsigned char value)
* Return Value:
* The SDA data bit sent by the Slave
*/
-static unsigned char sw_i2c_read_sda(void)
+static bool sw_i2c_read_sda(void)
{
unsigned long gpio_dir;
unsigned long gpio_data;
@@ -196,9 +196,9 @@ static unsigned char sw_i2c_read_sda(void)
/* Now read the SDA line */
gpio_data = peek32(sw_i2c_data_gpio_data_reg);
if (gpio_data & (1 << sw_i2c_data_gpio))
- return 1;
+ return true;
else
- return 0;
+ return false;
}
/*
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 1/4] staging: sm750fb: Convert sw_i2c_read_sda to return bool
From: Greg KH @ 2026-01-12 10:31 UTC (permalink / raw)
To: Karthikey Kadati
Cc: sudipm.mukherjee, teddy.wang, linux-fbdev, linux-staging,
linux-kernel, Unix Antigravity
In-Reply-To: <20260112102502.19761-1-karthikey3608@gmail.com>
On Mon, Jan 12, 2026 at 03:55:02PM +0530, Karthikey Kadati wrote:
> The sw_i2c_read_sda function currently returns unsigned char (1 or 0).
>
> Standardize it to return bool (true or false) to match kernel standards.
>
> Signed-off-by: Unix Antigravity <unix.antigravity@test.com>
You have to be a legal person to sign off on a patch, with a valid email
address :(
Also, your patches were a patch series, but not connected to each other,
nor were they related. I see them in my inbox as:
1 T Jan 12 Karthikey Kadat (2.0K) [PATCH 4/4] staging: atomisp: Replace ia_css_region with v4l2_rect
2 T Jan 12 Karthikey Kadat (2.4K) [PATCH 2/4] staging: octeon: Remove port status typedefs
3 T Jan 12 Karthikey Kadat (9.1K) [PATCH 3/4] staging: atomisp: Remove input_system typedefs
4 T Jan 12 Karthikey Kadat (1.1K) [PATCH 1/4] staging: sm750fb: Convert sw_i2c_read_sda to return bool
But not threaded, so that's a bit odd. Perhaps you didn't use git
send-email for these?
thanks,
greg k-h
^ permalink raw reply
* [PATCH v2] staging: sm750fb: Convert sw_i2c_read_sda to return bool
From: Karthikey Kadati @ 2026-01-12 10:38 UTC (permalink / raw)
To: sudipm.mukherjee, teddy.wang, gregkh
Cc: linux-fbdev, linux-staging, linux-kernel, Karthikey Kadati
The sw_i2c_read_sda function currently returns unsigned char (1 or 0).
Standardize it to return bool (true or false) to match kernel standards.
Signed-off-by: Karthikey Kadati <karthikey3608@gmail.com>
---
drivers/staging/sm750fb/ddk750_swi2c.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/sm750fb/ddk750_swi2c.c b/drivers/staging/sm750fb/ddk750_swi2c.c
index 0ef8d4ff2..9d48673d3 100644
--- a/drivers/staging/sm750fb/ddk750_swi2c.c
+++ b/drivers/staging/sm750fb/ddk750_swi2c.c
@@ -180,7 +180,7 @@ static void sw_i2c_sda(unsigned char value)
* Return Value:
* The SDA data bit sent by the Slave
*/
-static unsigned char sw_i2c_read_sda(void)
+static bool sw_i2c_read_sda(void)
{
unsigned long gpio_dir;
unsigned long gpio_data;
@@ -196,9 +196,9 @@ static unsigned char sw_i2c_read_sda(void)
/* Now read the SDA line */
gpio_data = peek32(sw_i2c_data_gpio_data_reg);
if (gpio_data & (1 << sw_i2c_data_gpio))
- return 1;
+ return true;
else
- return 0;
+ return false;
}
/*
--
2.43.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox