* Re: [PATCH 3/5] arm64: dts: qcom: msm8953-xiaomi-vince: correct wled ovp value
From: Konrad Dybcio @ 2026-01-07 14:08 UTC (permalink / raw)
To: Barnabás Czémán, Lee Jones, Daniel Thompson,
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
Cc: dri-devel, linux-leds, devicetree, linux-kernel, Daniel Thompson,
linux-arm-msm, linux-fbdev
In-Reply-To: <20260107-pmi8950-wled-v1-3-5e52f5caa39c@mainlining.org>
On 1/7/26 2:31 PM, Barnabás Czémán wrote:
> Correct wled ovp value from 29600 to 29500.
This tells us what the fix is, but not why the fix needs to be made.
We can infer the former from the patch contents, but it's really
important that the next reader, perhaps in 5 years, can find out the
reason it was made.
How about:
"""
PMI8950 doesn't actually support setting an OVP threshold value of
29.6 V. The closest allowed value is 29.5 V. Set that instead.
"""
With this or similar commit message:
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH 2/5] backlight: qcom-wled: Support ovp values for PMI8950
From: Konrad Dybcio @ 2026-01-07 14:05 UTC (permalink / raw)
To: Barnabás Czémán, Lee Jones, Daniel Thompson,
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
Cc: dri-devel, linux-leds, devicetree, linux-kernel, Daniel Thompson,
linux-arm-msm, linux-fbdev
In-Reply-To: <20260107-pmi8950-wled-v1-2-5e52f5caa39c@mainlining.org>
On 1/7/26 2:31 PM, Barnabás Czémán wrote:
> WLED4 found in PMI8950 supports different ovp values.
>
> Fixes: 10258bf4534bf ("backlight: qcom-wled: Add PMI8950 compatible")
> Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
> ---
[...]
> case 4:
> - u32_opts = wled4_opts;
> - size = ARRAY_SIZE(wled4_opts);
> + if (of_device_is_compatible(dev->of_node, "qcom,pmi8950-wled")) {
> + u32_opts = pmi8950_wled4_opts;
> + size = ARRAY_SIZE(pmi8950_wled4_opts);
> + } else {
> + u32_opts = wled4_opts;
> + size = ARRAY_SIZE(wled4_opts);
> + }
I really don't like how this driver went about abstracting parsing
all of that, but that's not your fault
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH 1/5] dt-bindings: backlight: qcom-wled: Document ovp values for PMI8950
From: Konrad Dybcio @ 2026-01-07 14:03 UTC (permalink / raw)
To: Barnabás Czémán, Lee Jones, Daniel Thompson,
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
Cc: dri-devel, linux-leds, devicetree, linux-kernel, Daniel Thompson,
linux-arm-msm, linux-fbdev
In-Reply-To: <20260107-pmi8950-wled-v1-1-5e52f5caa39c@mainlining.org>
On 1/7/26 2:31 PM, Barnabás Czémán wrote:
> Document ovp values supported by wled found in PMI8950.
>
> Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
> ---
> .../bindings/leds/backlight/qcom-wled.yaml | 20 ++++++++++++++++++--
> 1 file changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml
> index a8490781011d..306fb6642617 100644
> --- a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml
> +++ b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml
> @@ -98,8 +98,6 @@ properties:
> description: |
> Over-voltage protection limit. This property is for WLED4 only.
> $ref: /schemas/types.yaml#/definitions/uint32
> - enum: [ 18100, 19600, 29600, 31100 ]
> - default: 29600
>
> qcom,num-strings:
> description: |
> @@ -239,6 +237,24 @@ allOf:
> minimum: 0
> maximum: 4095
>
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: qcom,pmi8950-wled
> +
> + then:
> + properties:
> + qcom,ovp-millivolt:
> + enum: [ 17800, 19400, 29500, 31000 ]
> + default: 29500
> +
> + else:
> + properties:
> + qcom,ovp-millivolt:
> + enum: [ 18100, 19600, 29600, 31100 ]
> + default: 29600
Out of the supported ones:
{ .compatible = "qcom,pmi8950-wled", .data = (void *)4 },
{ .compatible = "qcom,pmi8994-wled", .data = (void *)4 },
{ .compatible = "qcom,pmi8998-wled", .data = (void *)4 },
{ .compatible = "qcom,pm660l-wled", .data = (void *)4 },
I can confirm both allowed and default values for PMI8950/98/PM660L
I could not find any data for PMI8994 (or PMI8996, the essentially
PMI8994-revbump), but it's very probable that 8950 is an oddball,
so:
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v2 6/6] video/logo: move logo selection logic to Kconfig
From: Geert Uytterhoeven @ 2026-01-07 13:53 UTC (permalink / raw)
To: Helge Deller
Cc: Vincent Mailhol, Greg Kroah-Hartman, Rich Felker,
John Paul Adrian Glaubitz, linux-fbdev, dri-devel, linux-kernel,
linux-sh, linux-m68k
In-Reply-To: <487ac672-3a2e-4897-aaba-7ae44bcf341a@gmx.de>
Hi Helge,
On Wed, 7 Jan 2026 at 13:21, Helge Deller <deller@gmx.de> wrote:
> On 1/7/26 11:36, Geert Uytterhoeven wrote:
> > On Tue, 6 Jan 2026 at 21:10, Vincent Mailhol <mailhol@kernel.org> wrote:
> >> On 06/01/2026 at 12:48, Geert Uytterhoeven wrote:
> >>> Thanks for your patch, which is now commit bd710b3da7308cb1
> >>> ("video/logo: move logo selection logic to Kconfig") in fbdev/for-next.
> >>>
> >>> On Thu, 1 Jan 2026 at 16:26, Vincent Mailhol <mailhol@kernel.org> wrote:
> >>>> Now that the path to the logo file can be directly entered in Kbuild,
> >>>> there is no more need to handle all the logo file selection in the
> >>>> Makefile and the C files.
> >>>
> >>> This may do the wrong thing when booting a multi-platform kernel.
> >>>
> >>>>
> >>>> The only exception is the logo_spe_clut224 which is only used by the
> >>>> Cell processor (found for example in the Playstation 3) [1]. This
> >>>> extra logo uses its own different image which shows up on a separate
> >>>> line just below the normal logo. Because the extra logo uses a
> >>>> different image, it can not be factorized under the custom logo logic.
> >>>>
> >>>> Move all the logo file selection logic to Kbuild (except from the
> >>>> logo_spe_clut224.ppm), this done, clean-up the C code to only leave
> >>>> one entry for each logo type (monochrome, 16-colors and 224-colors).
> >>>>
> >>>> [1] Cell SPE logos
> >>>> Link: https://lore.kernel.org/all/20070710122702.765654000@pademelon.sonytel.be/
> >>>>
> >>>> Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
> >>>
> >>>> --- a/drivers/video/logo/Kconfig
> >>>> +++ b/drivers/video/logo/Kconfig
> >>>
> >>>> @@ -61,6 +63,12 @@ config LOGO_LINUX_CLUT224
> >>>> config LOGO_LINUX_CLUT224_FILE
> >>>> string "224-color logo .ppm file"
> >>>> depends on LOGO_LINUX_CLUT224
> >>>> + default "drivers/video/logo/logo_dec_clut224.ppm" if MACH_DECSTATION || ALPHA
> >>>> + default "drivers/video/logo/logo_mac_clut224.ppm" if MAC
> >>>
> >>> E.g. an m68k multi-platform kernel including Mac support will scare
> >>> non-Mac users into thinking their machine was assimilated by the
> >>> Apple Empire...
> >>>> --- a/drivers/video/logo/logo.c
> >>>> +++ b/drivers/video/logo/logo.c
> >>>> -#ifdef CONFIG_LOGO_MAC_CLUT224
> >>>> - /* Macintosh Linux logo on m68k */
> >>>> - if (MACH_IS_MAC)
> >>>
> >>> MACH_IS_MAC can be a runtime check.
> >>
> >> OK. I missed this.
> >>
> >> I think there are two options to fix this:
> >>
> >> 1. Keep CONFIG_LOGO_MAC_CLUT224 untouched
> >> 2. Remove logo_mac_clut224.ppm
> >>
> >> The first option is less controversial but I would like to ask you what
> >> you think about removing the logo_mac_clut224 file.
> >>
> >> Here, we are speaking of the Macintosh 68k which ended sales in 1995,
> >> right? So the user base should be rather small, I guess.
> >
> > Yes, the user base is small.
> >
> > BTW, the only reason you don't have this issue with MACH_DECSTATION and
> > the various SGI_IP* options is that MIPS does not support multi-platform
> > kernels.
> >
> >> And people who still want the custom MAC logo would still be able to add
> >>
> >> CONFIG_LOGO_MAC_CLUT224="path/to/logo_mac_clut224.ppm"
> >
> > LOGO_LINUX_CLUT224_FILE ;-)
> >
> >> to their config to restore the old behaviour anyway.
> >>
> >> My choice would go more toward the removal option but what do you think?
> >
> > I am not too attached to keeping the dynamic behavior for the Mac logo,
> > I just wanted to point out the impact.
> > I expect most people who care about logos (in products) just have their
> > own custom out-of-tree code. As fb_find_logo() and the underlying
> > infrastructure still exists, I don't expect them to have too much
> > trouble forward porting that to newer kernels.
> >
> > What do other people think?
>
> This is about a small visible icon. It's not some relevant feature.
> So, I think it's unfortunate that the patch then drops the specific mac logo.
> But adding additional coding and complexity to simply make this logo
> visible for such a small user base IMHO does not justify the effort.
This patch does not drop the specific Mac logo.
Instead, it prioritizes the Mac logo over the generic logo when Mac
support is enabled in a multi-platform kernel.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH 4/5] arm64: dts: qcom: msm8937-xiaomi-land: correct wled ovp value
From: Barnabás Czémán @ 2026-01-07 13:31 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, 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
Cc: dri-devel, linux-leds, devicetree, linux-kernel, Daniel Thompson,
linux-arm-msm, linux-fbdev, Konrad Dybcio,
Barnabás Czémán
In-Reply-To: <20260107-pmi8950-wled-v1-0-5e52f5caa39c@mainlining.org>
Correct wled ovp value from 29600 to 29500.
Fixes: 2144f6d57d8e ("arm64: dts: qcom: Add Xiaomi Redmi 3S")
Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
---
arch/arm64/boot/dts/qcom/msm8937-xiaomi-land.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8937-xiaomi-land.dts b/arch/arm64/boot/dts/qcom/msm8937-xiaomi-land.dts
index 91837ff940f1..4f301e7c6517 100644
--- a/arch/arm64/boot/dts/qcom/msm8937-xiaomi-land.dts
+++ b/arch/arm64/boot/dts/qcom/msm8937-xiaomi-land.dts
@@ -178,7 +178,7 @@ &pmi8950_wled {
qcom,num-strings = <2>;
qcom,external-pfet;
qcom,current-limit-microamp = <20000>;
- qcom,ovp-millivolt = <29600>;
+ qcom,ovp-millivolt = <29500>;
status = "okay";
};
--
2.52.0
^ permalink raw reply related
* [PATCH 1/5] dt-bindings: backlight: qcom-wled: Document ovp values for PMI8950
From: Barnabás Czémán @ 2026-01-07 13:31 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, 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
Cc: dri-devel, linux-leds, devicetree, linux-kernel, Daniel Thompson,
linux-arm-msm, linux-fbdev, Konrad Dybcio,
Barnabás Czémán
In-Reply-To: <20260107-pmi8950-wled-v1-0-5e52f5caa39c@mainlining.org>
Document ovp values supported by wled found in PMI8950.
Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
---
.../bindings/leds/backlight/qcom-wled.yaml | 20 ++++++++++++++++++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml
index a8490781011d..306fb6642617 100644
--- a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml
+++ b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml
@@ -98,8 +98,6 @@ properties:
description: |
Over-voltage protection limit. This property is for WLED4 only.
$ref: /schemas/types.yaml#/definitions/uint32
- enum: [ 18100, 19600, 29600, 31100 ]
- default: 29600
qcom,num-strings:
description: |
@@ -239,6 +237,24 @@ allOf:
minimum: 0
maximum: 4095
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: qcom,pmi8950-wled
+
+ then:
+ properties:
+ qcom,ovp-millivolt:
+ enum: [ 17800, 19400, 29500, 31000 ]
+ default: 29500
+
+ else:
+ properties:
+ qcom,ovp-millivolt:
+ enum: [ 18100, 19600, 29600, 31100 ]
+ default: 29600
+
required:
- compatible
- reg
--
2.52.0
^ permalink raw reply related
* [PATCH 5/5] arm64: dts: qcom: msm8953-xiaomi-daisy: fix backlight
From: Barnabás Czémán @ 2026-01-07 13:31 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, 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
Cc: dri-devel, linux-leds, devicetree, linux-kernel, Daniel Thompson,
linux-arm-msm, linux-fbdev, Konrad Dybcio,
Barnabás Czémán
In-Reply-To: <20260107-pmi8950-wled-v1-0-5e52f5caa39c@mainlining.org>
Set qcom,num-strings to 3 instead of 2 for avoid stripes.
Fixes: 38d779c26395 ("arm64: dts: qcom: msm8953: Add device tree for Xiaomi Mi A2 Lite")
Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
---
arch/arm64/boot/dts/qcom/msm8953-xiaomi-daisy.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8953-xiaomi-daisy.dts b/arch/arm64/boot/dts/qcom/msm8953-xiaomi-daisy.dts
index ddd7af616794..59f873a06e4d 100644
--- a/arch/arm64/boot/dts/qcom/msm8953-xiaomi-daisy.dts
+++ b/arch/arm64/boot/dts/qcom/msm8953-xiaomi-daisy.dts
@@ -157,7 +157,7 @@ &pm8953_resin {
&pmi8950_wled {
qcom,current-limit-microamp = <20000>;
- qcom,num-strings = <2>;
+ qcom,num-strings = <3>;
status = "okay";
};
--
2.52.0
^ permalink raw reply related
* [PATCH 2/5] backlight: qcom-wled: Support ovp values for PMI8950
From: Barnabás Czémán @ 2026-01-07 13:31 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, 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
Cc: dri-devel, linux-leds, devicetree, linux-kernel, Daniel Thompson,
linux-arm-msm, linux-fbdev, Konrad Dybcio,
Barnabás Czémán
In-Reply-To: <20260107-pmi8950-wled-v1-0-5e52f5caa39c@mainlining.org>
WLED4 found in PMI8950 supports different ovp values.
Fixes: 10258bf4534bf ("backlight: qcom-wled: Add PMI8950 compatible")
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..91335aeb65a3 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 pmi8950_wled4_ovp_values[] = {
+ 31000, 29500, 19400, 17800,
+};
+
+static const struct wled_var_cfg pmi8950_wled4_ovp_cfg = {
+ .values = pmi8950_wled4_ovp_values,
+ .size = ARRAY_SIZE(pmi8950_wled4_ovp_values),
+};
+
static inline u32 wled5_ovp_values_fn(u32 idx)
{
/*
@@ -1357,6 +1366,29 @@ static int wled_configure(struct wled *wled)
},
};
+ const struct wled_u32_opts pmi8950_wled4_opts[] = {
+ {
+ .name = "qcom,current-boost-limit",
+ .val_ptr = &cfg->boost_i_limit,
+ .cfg = &wled4_boost_i_limit_cfg,
+ },
+ {
+ .name = "qcom,current-limit-microamp",
+ .val_ptr = &cfg->string_i_limit,
+ .cfg = &wled4_string_i_limit_cfg,
+ },
+ {
+ .name = "qcom,ovp-millivolt",
+ .val_ptr = &cfg->ovp,
+ .cfg = &pmi8950_wled4_ovp_cfg,
+ },
+ {
+ .name = "qcom,switching-freq",
+ .val_ptr = &cfg->switch_freq,
+ .cfg = &wled3_switch_freq_cfg,
+ },
+ };
+
const struct wled_u32_opts wled5_opts[] = {
{
.name = "qcom,current-boost-limit",
@@ -1423,8 +1455,13 @@ static int wled_configure(struct wled *wled)
break;
case 4:
- u32_opts = wled4_opts;
- size = ARRAY_SIZE(wled4_opts);
+ if (of_device_is_compatible(dev->of_node, "qcom,pmi8950-wled")) {
+ u32_opts = pmi8950_wled4_opts;
+ size = ARRAY_SIZE(pmi8950_wled4_opts);
+ } else {
+ u32_opts = wled4_opts;
+ size = ARRAY_SIZE(wled4_opts);
+ }
*cfg = wled4_config_defaults;
wled->wled_set_brightness = wled4_set_brightness;
wled->wled_sync_toggle = wled3_sync_toggle;
--
2.52.0
^ permalink raw reply related
* [PATCH 3/5] arm64: dts: qcom: msm8953-xiaomi-vince: correct wled ovp value
From: Barnabás Czémán @ 2026-01-07 13:31 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, 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
Cc: dri-devel, linux-leds, devicetree, linux-kernel, Daniel Thompson,
linux-arm-msm, linux-fbdev, Konrad Dybcio,
Barnabás Czémán
In-Reply-To: <20260107-pmi8950-wled-v1-0-5e52f5caa39c@mainlining.org>
Correct wled ovp value from 29600 to 29500.
Fixes: aa17e707e04a ("arm64: dts: qcom: msm8953: Add device tree for Xiaomi Redmi 5 Plus")
Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
---
arch/arm64/boot/dts/qcom/msm8953-xiaomi-vince.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8953-xiaomi-vince.dts b/arch/arm64/boot/dts/qcom/msm8953-xiaomi-vince.dts
index d46325e79917..c2a290bf493c 100644
--- a/arch/arm64/boot/dts/qcom/msm8953-xiaomi-vince.dts
+++ b/arch/arm64/boot/dts/qcom/msm8953-xiaomi-vince.dts
@@ -169,7 +169,7 @@ &pm8953_resin {
&pmi8950_wled {
qcom,current-limit-microamp = <20000>;
- qcom,ovp-millivolt = <29600>;
+ qcom,ovp-millivolt = <29500>;
qcom,num-strings = <2>;
qcom,external-pfet;
qcom,cabc;
--
2.52.0
^ permalink raw reply related
* [PATCH 0/5] Fix PMI8950 WLED ovp values and more
From: Barnabás Czémán @ 2026-01-07 13:31 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, 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
Cc: dri-devel, linux-leds, devicetree, linux-kernel, Daniel Thompson,
linux-arm-msm, linux-fbdev, Konrad Dybcio,
Barnabás Czémán
This patch series fixes supported ovp values related to pmi8950 wled
and corrects wled related properties in xiaomi-daisy, xiaomi-land and
in xiaomi-vince.
Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
---
Barnabás Czémán (5):
dt-bindings: backlight: qcom-wled: Document ovp values for PMI8950
backlight: qcom-wled: Support ovp values for PMI8950
arm64: dts: qcom: msm8953-xiaomi-vince: correct wled ovp value
arm64: dts: qcom: msm8937-xiaomi-land: correct wled ovp value
arm64: dts: qcom: msm8953-xiaomi-daisy: fix backlight
.../bindings/leds/backlight/qcom-wled.yaml | 20 +++++++++--
arch/arm64/boot/dts/qcom/msm8937-xiaomi-land.dts | 2 +-
arch/arm64/boot/dts/qcom/msm8953-xiaomi-daisy.dts | 2 +-
arch/arm64/boot/dts/qcom/msm8953-xiaomi-vince.dts | 2 +-
drivers/video/backlight/qcom-wled.c | 41 ++++++++++++++++++++--
5 files changed, 60 insertions(+), 7 deletions(-)
---
base-commit: f96074c6d01d8a5e9e2fccd0bba5f2ed654c1f2d
change-id: 20260107-pmi8950-wled-b014578f67a6
Best regards,
--
Barnabás Czémán <barnabas.czeman@mainlining.org>
^ permalink raw reply
* Re: [PATCH v2 6/6] video/logo: move logo selection logic to Kconfig
From: Helge Deller @ 2026-01-07 12:20 UTC (permalink / raw)
To: Geert Uytterhoeven, Vincent Mailhol
Cc: Greg Kroah-Hartman, Rich Felker, John Paul Adrian Glaubitz,
linux-fbdev, dri-devel, linux-kernel, linux-sh, linux-m68k
In-Reply-To: <CAMuHMdXz9uKxQ0dH68a+xt4FHqVgdskvO3QRvev1_Wq8h-a1Qg@mail.gmail.com>
On 1/7/26 11:36, Geert Uytterhoeven wrote:
> Hi Vincent,
>
> On Tue, 6 Jan 2026 at 21:10, Vincent Mailhol <mailhol@kernel.org> wrote:
>> On 06/01/2026 at 12:48, Geert Uytterhoeven wrote:
>>> Thanks for your patch, which is now commit bd710b3da7308cb1
>>> ("video/logo: move logo selection logic to Kconfig") in fbdev/for-next.
>>>
>>> On Thu, 1 Jan 2026 at 16:26, Vincent Mailhol <mailhol@kernel.org> wrote:
>>>> Now that the path to the logo file can be directly entered in Kbuild,
>>>> there is no more need to handle all the logo file selection in the
>>>> Makefile and the C files.
>>>
>>> This may do the wrong thing when booting a multi-platform kernel.
>>>
>>>>
>>>> The only exception is the logo_spe_clut224 which is only used by the
>>>> Cell processor (found for example in the Playstation 3) [1]. This
>>>> extra logo uses its own different image which shows up on a separate
>>>> line just below the normal logo. Because the extra logo uses a
>>>> different image, it can not be factorized under the custom logo logic.
>>>>
>>>> Move all the logo file selection logic to Kbuild (except from the
>>>> logo_spe_clut224.ppm), this done, clean-up the C code to only leave
>>>> one entry for each logo type (monochrome, 16-colors and 224-colors).
>>>>
>>>> [1] Cell SPE logos
>>>> Link: https://lore.kernel.org/all/20070710122702.765654000@pademelon.sonytel.be/
>>>>
>>>> Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
>>>
>>>> --- a/drivers/video/logo/Kconfig
>>>> +++ b/drivers/video/logo/Kconfig
>>>
>>>> @@ -61,6 +63,12 @@ config LOGO_LINUX_CLUT224
>>>> config LOGO_LINUX_CLUT224_FILE
>>>> string "224-color logo .ppm file"
>>>> depends on LOGO_LINUX_CLUT224
>>>> + default "drivers/video/logo/logo_dec_clut224.ppm" if MACH_DECSTATION || ALPHA
>>>> + default "drivers/video/logo/logo_mac_clut224.ppm" if MAC
>>>
>>> E.g. an m68k multi-platform kernel including Mac support will scare
>>> non-Mac users into thinking their machine was assimilated by the
>>> Apple Empire...
>>>
>>>> + default "drivers/video/logo/logo_parisc_clut224.ppm" if PARISC
>>>> + default "drivers/video/logo/logo_sgi_clut224.ppm" if SGI_IP22 || SGI_IP27 || SGI_IP32
>>>> + default "drivers/video/logo/logo_sun_clut224.ppm" if SPARC
>>>> + default "drivers/video/logo/logo_superh_clut224.ppm" if SUPERH
>>>> default "drivers/video/logo/logo_linux_clut224.ppm"
>>>> help
>>>> Takes a path to a 224-color logo in the portable pixmap file
>>>
>>>> --- a/drivers/video/logo/logo.c
>>>> +++ b/drivers/video/logo/logo.c
>>>> @@ -48,59 +48,21 @@ const struct linux_logo * __ref fb_find_logo(int depth)
>>>> if (nologo || logos_freed)
>>>> return NULL;
>>>>
>>>> - if (depth >= 1) {
>>>> #ifdef CONFIG_LOGO_LINUX_MONO
>>>> - /* Generic Linux logo */
>>>> + if (depth >= 1)
>>>> logo = &logo_linux_mono;
>>>> #endif
>>>> -#ifdef CONFIG_LOGO_SUPERH_MONO
>>>> - /* SuperH Linux logo */
>>>> - logo = &logo_superh_mono;
>>>> -#endif
>>>> - }
>>>>
>>>> - if (depth >= 4) {
>>>> #ifdef CONFIG_LOGO_LINUX_VGA16
>>>> - /* Generic Linux logo */
>>>> + if (depth >= 4)
>>>> logo = &logo_linux_vga16;
>>>> #endif
>>>> -#ifdef CONFIG_LOGO_SUPERH_VGA16
>>>> - /* SuperH Linux logo */
>>>> - logo = &logo_superh_vga16;
>>>> -#endif
>>>> - }
>>>>
>>>> - if (depth >= 8) {
>>>> #ifdef CONFIG_LOGO_LINUX_CLUT224
>>>> - /* Generic Linux logo */
>>>> + if (depth >= 8)
>>>> logo = &logo_linux_clut224;
>>>> #endif
>>>> -#ifdef CONFIG_LOGO_DEC_CLUT224
>>>> - /* DEC Linux logo on MIPS/MIPS64 or ALPHA */
>>>> - logo = &logo_dec_clut224;
>>>> -#endif
>>>> -#ifdef CONFIG_LOGO_MAC_CLUT224
>>>> - /* Macintosh Linux logo on m68k */
>>>> - if (MACH_IS_MAC)
>>>
>>> MACH_IS_MAC can be a runtime check.
>>
>> OK. I missed this.
>>
>> I think there are two options to fix this:
>>
>> 1. Keep CONFIG_LOGO_MAC_CLUT224 untouched
>> 2. Remove logo_mac_clut224.ppm
>>
>> The first option is less controversial but I would like to ask you what
>> you think about removing the logo_mac_clut224 file.
>>
>> Here, we are speaking of the Macintosh 68k which ended sales in 1995,
>> right? So the user base should be rather small, I guess.
>
> Yes, the user base is small.
>
> BTW, the only reason you don't have this issue with MACH_DECSTATION and
> the various SGI_IP* options is that MIPS does not support multi-platform
> kernels.
>
>> And people who still want the custom MAC logo would still be able to add
>>
>> CONFIG_LOGO_MAC_CLUT224="path/to/logo_mac_clut224.ppm"
>
> LOGO_LINUX_CLUT224_FILE ;-)
>
>> to their config to restore the old behaviour anyway.
>>
>> My choice would go more toward the removal option but what do you think?
>
> I am not too attached to keeping the dynamic behavior for the Mac logo,
> I just wanted to point out the impact.
> I expect most people who care about logos (in products) just have their
> own custom out-of-tree code. As fb_find_logo() and the underlying
> infrastructure still exists, I don't expect them to have too much
> trouble forward porting that to newer kernels.
>
> What do other people think?
This is about a small visible icon. It's not some relevant feature.
So, I think it's unfortunate that the patch then drops the specific mac logo.
But adding additional coding and complexity to simply make this logo
visible for such a small user base IMHO does not justify the effort.
Helge
^ permalink raw reply
* Re: [PATCH v2 6/6] video/logo: move logo selection logic to Kconfig
From: Geert Uytterhoeven @ 2026-01-07 10:36 UTC (permalink / raw)
To: Vincent Mailhol
Cc: Helge Deller, Greg Kroah-Hartman, Yoshinori Sato, Rich Felker,
John Paul Adrian Glaubitz, linux-fbdev, dri-devel, linux-kernel,
linux-sh, linux-m68k
In-Reply-To: <dda4052e-b843-43fa-850c-a1bb20e4a8e3@kernel.org>
Hi Vincent,
On Tue, 6 Jan 2026 at 21:10, Vincent Mailhol <mailhol@kernel.org> wrote:
> On 06/01/2026 at 12:48, Geert Uytterhoeven wrote:
> > Thanks for your patch, which is now commit bd710b3da7308cb1
> > ("video/logo: move logo selection logic to Kconfig") in fbdev/for-next.
> >
> > On Thu, 1 Jan 2026 at 16:26, Vincent Mailhol <mailhol@kernel.org> wrote:
> >> Now that the path to the logo file can be directly entered in Kbuild,
> >> there is no more need to handle all the logo file selection in the
> >> Makefile and the C files.
> >
> > This may do the wrong thing when booting a multi-platform kernel.
> >
> >>
> >> The only exception is the logo_spe_clut224 which is only used by the
> >> Cell processor (found for example in the Playstation 3) [1]. This
> >> extra logo uses its own different image which shows up on a separate
> >> line just below the normal logo. Because the extra logo uses a
> >> different image, it can not be factorized under the custom logo logic.
> >>
> >> Move all the logo file selection logic to Kbuild (except from the
> >> logo_spe_clut224.ppm), this done, clean-up the C code to only leave
> >> one entry for each logo type (monochrome, 16-colors and 224-colors).
> >>
> >> [1] Cell SPE logos
> >> Link: https://lore.kernel.org/all/20070710122702.765654000@pademelon.sonytel.be/
> >>
> >> Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
> >
> >> --- a/drivers/video/logo/Kconfig
> >> +++ b/drivers/video/logo/Kconfig
> >
> >> @@ -61,6 +63,12 @@ config LOGO_LINUX_CLUT224
> >> config LOGO_LINUX_CLUT224_FILE
> >> string "224-color logo .ppm file"
> >> depends on LOGO_LINUX_CLUT224
> >> + default "drivers/video/logo/logo_dec_clut224.ppm" if MACH_DECSTATION || ALPHA
> >> + default "drivers/video/logo/logo_mac_clut224.ppm" if MAC
> >
> > E.g. an m68k multi-platform kernel including Mac support will scare
> > non-Mac users into thinking their machine was assimilated by the
> > Apple Empire...
> >
> >> + default "drivers/video/logo/logo_parisc_clut224.ppm" if PARISC
> >> + default "drivers/video/logo/logo_sgi_clut224.ppm" if SGI_IP22 || SGI_IP27 || SGI_IP32
> >> + default "drivers/video/logo/logo_sun_clut224.ppm" if SPARC
> >> + default "drivers/video/logo/logo_superh_clut224.ppm" if SUPERH
> >> default "drivers/video/logo/logo_linux_clut224.ppm"
> >> help
> >> Takes a path to a 224-color logo in the portable pixmap file
> >
> >> --- a/drivers/video/logo/logo.c
> >> +++ b/drivers/video/logo/logo.c
> >> @@ -48,59 +48,21 @@ const struct linux_logo * __ref fb_find_logo(int depth)
> >> if (nologo || logos_freed)
> >> return NULL;
> >>
> >> - if (depth >= 1) {
> >> #ifdef CONFIG_LOGO_LINUX_MONO
> >> - /* Generic Linux logo */
> >> + if (depth >= 1)
> >> logo = &logo_linux_mono;
> >> #endif
> >> -#ifdef CONFIG_LOGO_SUPERH_MONO
> >> - /* SuperH Linux logo */
> >> - logo = &logo_superh_mono;
> >> -#endif
> >> - }
> >>
> >> - if (depth >= 4) {
> >> #ifdef CONFIG_LOGO_LINUX_VGA16
> >> - /* Generic Linux logo */
> >> + if (depth >= 4)
> >> logo = &logo_linux_vga16;
> >> #endif
> >> -#ifdef CONFIG_LOGO_SUPERH_VGA16
> >> - /* SuperH Linux logo */
> >> - logo = &logo_superh_vga16;
> >> -#endif
> >> - }
> >>
> >> - if (depth >= 8) {
> >> #ifdef CONFIG_LOGO_LINUX_CLUT224
> >> - /* Generic Linux logo */
> >> + if (depth >= 8)
> >> logo = &logo_linux_clut224;
> >> #endif
> >> -#ifdef CONFIG_LOGO_DEC_CLUT224
> >> - /* DEC Linux logo on MIPS/MIPS64 or ALPHA */
> >> - logo = &logo_dec_clut224;
> >> -#endif
> >> -#ifdef CONFIG_LOGO_MAC_CLUT224
> >> - /* Macintosh Linux logo on m68k */
> >> - if (MACH_IS_MAC)
> >
> > MACH_IS_MAC can be a runtime check.
>
> OK. I missed this.
>
> I think there are two options to fix this:
>
> 1. Keep CONFIG_LOGO_MAC_CLUT224 untouched
> 2. Remove logo_mac_clut224.ppm
>
> The first option is less controversial but I would like to ask you what
> you think about removing the logo_mac_clut224 file.
>
> Here, we are speaking of the Macintosh 68k which ended sales in 1995,
> right? So the user base should be rather small, I guess.
Yes, the user base is small.
BTW, the only reason you don't have this issue with MACH_DECSTATION and
the various SGI_IP* options is that MIPS does not support multi-platform
kernels.
> And people who still want the custom MAC logo would still be able to add
>
> CONFIG_LOGO_MAC_CLUT224="path/to/logo_mac_clut224.ppm"
LOGO_LINUX_CLUT224_FILE ;-)
> to their config to restore the old behaviour anyway.
>
> My choice would go more toward the removal option but what do you think?
I am not too attached to keeping the dynamic behavior for the Mac logo,
I just wanted to point out the impact.
I expect most people who care about logos (in products) just have their
own custom out-of-tree code. As fb_find_logo() and the underlying
infrastructure still exists, I don't expect them to have too much
trouble forward porting that to newer kernels.
What do other people think?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH 3/3] staging: rtl8723bs: remove unnecessary parentheses and true comparisons
From: Lorenzo Simonelli @ 2026-01-07 9:47 UTC (permalink / raw)
To: gregkh
Cc: sudipm.mukherjee, teddy.wang, linux-staging, linux-kernel,
linux-fbdev, Lorenzo Simonelli
In-Reply-To: <20260107094714.300380-1-lorenzosimonelli02@gmail.com>
Clean up unnecessary double parentheses and explicit comparisons to
true in rtw_mlme.c. This improves readability and adheres to the
Linux kernel coding style
Signed-off-by: Lorenzo Simonelli <lorenzosimonelli02@gmail.com>
---
drivers/staging/rtl8723bs/core/rtw_mlme.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_mlme.c b/drivers/staging/rtl8723bs/core/rtw_mlme.c
index ff4e668f1..d9e6778e1 100644
--- a/drivers/staging/rtl8723bs/core/rtw_mlme.c
+++ b/drivers/staging/rtl8723bs/core/rtw_mlme.c
@@ -468,11 +468,11 @@ static void update_current_network(struct adapter *adapter, struct wlan_bssid_ex
&pmlmepriv->cur_network.network,
&pmlmepriv->cur_network.network,
&pmlmepriv->cur_network.network);
-
- if ((check_fwstate(pmlmepriv, _FW_LINKED) == true) && (is_same_network(&pmlmepriv->cur_network.network, pnetwork, 0))) {
+ if ((check_fwstate(pmlmepriv, _FW_LINKED) == true) &&
+ (is_same_network(&pmlmepriv->cur_network.network, pnetwork, 0))) {
update_network(&pmlmepriv->cur_network.network, pnetwork, adapter, true);
rtw_update_protection(adapter, (pmlmepriv->cur_network.network.ies) + sizeof(struct ndis_802_11_fix_ie),
- pmlmepriv->cur_network.network.ie_length);
+ pmlmepriv->cur_network.network.ie_length);
}
}
@@ -710,7 +710,7 @@ void rtw_surveydone_event_callback(struct adapter *adapter, u8 *pbuf)
rtw_set_signal_stat_timer(&adapter->recvpriv);
if (pmlmepriv->to_join) {
- if ((check_fwstate(pmlmepriv, WIFI_ADHOC_STATE) == true)) {
+ if (check_fwstate(pmlmepriv, WIFI_ADHOC_STATE)) {
if (check_fwstate(pmlmepriv, _FW_LINKED) == false) {
set_fwstate(pmlmepriv, _FW_UNDER_LINKING);
@@ -1386,8 +1386,8 @@ void rtw_stassoc_event_callback(struct adapter *adapter, u8 *pbuf)
spin_lock_bh(&pmlmepriv->lock);
- if ((check_fwstate(pmlmepriv, WIFI_ADHOC_MASTER_STATE) == true) ||
- (check_fwstate(pmlmepriv, WIFI_ADHOC_STATE) == true)) {
+ if (check_fwstate(pmlmepriv, WIFI_ADHOC_MASTER_STATE) ||
+ check_fwstate(pmlmepriv, WIFI_ADHOC_STATE)) {
if (adapter->stapriv.asoc_sta_count == 2) {
spin_lock_bh(&pmlmepriv->scanned_queue.lock);
ptarget_wlan = rtw_find_network(&pmlmepriv->scanned_queue, cur_network->network.mac_address);
--
2.52.0
^ permalink raw reply related
* [PATCH 2/3] staging: rtl8723bs: remove trailing whitespace
From: Lorenzo Simonelli @ 2026-01-07 9:47 UTC (permalink / raw)
To: gregkh
Cc: sudipm.mukherjee, teddy.wang, linux-staging, linux-kernel,
linux-fbdev, Lorenzo Simonelli
In-Reply-To: <20260107094714.300380-1-lorenzosimonelli02@gmail.com>
Remove a trailing whitespace found by checkpatch.pl in rtw_mlme.c
at line 2021.
Signed-off-by: Lorenzo Simonelli <lorenzosimonelli02@gmail.com>
---
drivers/staging/rtl8723bs/core/rtw_mlme.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_mlme.c b/drivers/staging/rtl8723bs/core/rtw_mlme.c
index 98704179a..ff4e668f1 100644
--- a/drivers/staging/rtl8723bs/core/rtw_mlme.c
+++ b/drivers/staging/rtl8723bs/core/rtw_mlme.c
@@ -2018,7 +2018,7 @@ int rtw_restruct_wmm_ie(struct adapter *adapter, u8 *in_ie, u8 *out_ie, uint in_
return ielength;
}
-/* Ported from 8185: IsInPreAuthKeyList().
+/* Ported from 8185: IsInPreAuthKeyList().
* (Renamed from SecIsInPreAuthKeyList(), 2006-10-13.)
* Added by Annie, 2006-05-07.
*
--
2.52.0
^ permalink raw reply related
* [PATCH 1/3] staging: sm750fb: fix static const char array warning
From: Lorenzo Simonelli @ 2026-01-07 9:47 UTC (permalink / raw)
To: gregkh
Cc: sudipm.mukherjee, teddy.wang, linux-staging, linux-kernel,
linux-fbdev, Lorenzo Simonelli
In-Reply-To: <20260107094714.300380-1-lorenzosimonelli02@gmail.com>
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
^ permalink raw reply related
* [PATCH 0/3] staging: style cleanups for sm750fb and rtl8723bs
From: Lorenzo Simonelli @ 2026-01-07 9:47 UTC (permalink / raw)
To: gregkh
Cc: sudipm.mukherjee, teddy.wang, linux-staging, linux-kernel,
linux-fbdev, Lorenzo Simonelli
This patch series performs various style cleanups in the staging
directory to resolve warnings reported by checkpatch.pl.
The changes include:
- Fixing 'static const char * const' declarations in sm750fb.
- Removing trailing whitespace in rtw_mlme.c.
- Simplifying boolean expressions by removing unnecessary parentheses
and explicit comparisons to 'true'.
All patches have been checked with checkpatch.pl and the modified
files have been verified to compile correctly.
Lorenzo Simonelli (3):
staging: sm750fb: fix static const char array warning
staging: rtl8723bs: remove trailing whitespace
staging: rtl8723bs: remove unnecessary parentheses and true comparisons
drivers/staging/rtl8723bs/core/rtw_mlme.c | 14 +++++++-------
drivers/staging/sm750fb/sm750.c | 2 +-
2 files changed, 8 insertions(+), 8 deletions(-)
--
2.52.0
^ permalink raw reply
* Re: [PATCH v4 4/4] fbdev: sh_mobile_lcdc: Make FB_DEVICE dependency optional
From: Thomas Zimmermann @ 2026-01-07 7:33 UTC (permalink / raw)
To: Chintan Patel, linux-fbdev, linux-staging, linux-omap
Cc: linux-kernel, dri-devel, andy, deller, gregkh
In-Reply-To: <20260107044258.528624-5-chintanlike@gmail.com>
Am 07.01.26 um 05:42 schrieb Chintan Patel:
> The sh_mobile_lcdc driver exposes overlay configuration via sysfs, but the
> core driver does not require CONFIG_FB_DEVICE.
>
> Make overlay sysfs optional so that the driver can build and operate
> even when FB_DEVICE is disabled. The kernel naturally ignores the
> missing attribute group, preserving buildability and type safety.
>
> Suggested-by: Helge Deller <deller@gmx.de>
> Signed-off-by: Chintan Patel <chintanlike@gmail.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
> drivers/video/fbdev/sh_mobile_lcdcfb.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/sh_mobile_lcdcfb.c b/drivers/video/fbdev/sh_mobile_lcdcfb.c
> index dd950e4ab5ce..5f3a0cd27db3 100644
> --- a/drivers/video/fbdev/sh_mobile_lcdcfb.c
> +++ b/drivers/video/fbdev/sh_mobile_lcdcfb.c
> @@ -1343,14 +1343,17 @@ static DEVICE_ATTR_RW(overlay_mode);
> static DEVICE_ATTR_RW(overlay_position);
> static DEVICE_ATTR_RW(overlay_rop3);
>
> -static struct attribute *overlay_sysfs_attrs[] = {
> +static struct attribute *overlay_sysfs_attrs[] __maybe_unused = {
> &dev_attr_overlay_alpha.attr,
> &dev_attr_overlay_mode.attr,
> &dev_attr_overlay_position.attr,
> &dev_attr_overlay_rop3.attr,
> NULL,
> };
> +
> +#ifdef CONFIG_FB_DEVICE
> ATTRIBUTE_GROUPS(overlay_sysfs);
> +#endif
>
> static const struct fb_fix_screeninfo sh_mobile_lcdc_overlay_fix = {
> .id = "SH Mobile LCDC",
--
--
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 v4 3/4] fbdev: omapfb: Make FB_DEVICE dependency optional
From: Thomas Zimmermann @ 2026-01-07 7:33 UTC (permalink / raw)
To: Chintan Patel, linux-fbdev, linux-staging, linux-omap
Cc: linux-kernel, dri-devel, andy, deller, gregkh
In-Reply-To: <20260107044258.528624-4-chintanlike@gmail.com>
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>
> ---
> drivers/video/fbdev/omap2/omapfb/Kconfig | 3 ++-
> .../video/fbdev/omap2/omapfb/omapfb-sysfs.c | 18 ++++++++++++++----
> 2 files changed, 16 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/video/fbdev/omap2/omapfb/Kconfig b/drivers/video/fbdev/omap2/omapfb/Kconfig
> index f4cdf999a080..2d20e79adefc 100644
> --- a/drivers/video/fbdev/omap2/omapfb/Kconfig
> +++ b/drivers/video/fbdev/omap2/omapfb/Kconfig
> @@ -5,7 +5,6 @@ config OMAP2_VRFB
> menuconfig FB_OMAP2
> tristate "OMAP2+ frame buffer support"
> depends on FB
> - depends on FB_DEVICE
> depends on DRM_OMAP = n
> depends on GPIOLIB
> select FB_OMAP2_DSS
> @@ -13,6 +12,8 @@ menuconfig FB_OMAP2
> select FB_IOMEM_HELPERS
> help
> Frame buffer driver for OMAP2+ based boards.
> + FB_DEVICE is not required, but if enabled, provides sysfs interface
> + for framebuffer configuration and debugging.
>
> if FB_OMAP2
>
> diff --git a/drivers/video/fbdev/omap2/omapfb/omapfb-sysfs.c b/drivers/video/fbdev/omap2/omapfb/omapfb-sysfs.c
> index 831b2c2fbdf9..38a635d38d58 100644
> --- a/drivers/video/fbdev/omap2/omapfb/omapfb-sysfs.c
> +++ b/drivers/video/fbdev/omap2/omapfb/omapfb-sysfs.c
> @@ -558,10 +558,15 @@ int omapfb_create_sysfs(struct omapfb2_device *fbdev)
>
> DBG("create sysfs for fbs\n");
> for (i = 0; i < fbdev->num_fbs; i++) {
> + struct device *dev;
> int t;
> +
> + dev = dev_of_fbinfo(fbdev->fbs[i]);
> + if (!dev)
> + continue;
> +
> for (t = 0; t < ARRAY_SIZE(omapfb_attrs); t++) {
> - r = device_create_file(fbdev->fbs[i]->dev,
> - &omapfb_attrs[t]);
> + r = device_create_file(dev, &omapfb_attrs[t]);
>
> if (r) {
> dev_err(fbdev->dev, "failed to create sysfs "
> @@ -580,9 +585,14 @@ void omapfb_remove_sysfs(struct omapfb2_device *fbdev)
>
> DBG("remove sysfs for fbs\n");
> for (i = 0; i < fbdev->num_fbs; i++) {
> + struct device *dev;
> +
> + dev = dev_of_fbinfo(fbdev->fbs[i]);
> + if (!dev)
> + continue;
> +
> for (t = 0; t < ARRAY_SIZE(omapfb_attrs); t++)
> - device_remove_file(fbdev->fbs[i]->dev,
> - &omapfb_attrs[t]);
> + device_remove_file(dev, &omapfb_attrs[t]);
> }
> }
>
--
--
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 v4 2/4] staging: fbtft: Make FB_DEVICE dependency optional
From: Thomas Zimmermann @ 2026-01-07 7:33 UTC (permalink / raw)
To: Chintan Patel, linux-fbdev, linux-staging, linux-omap
Cc: linux-kernel, dri-devel, andy, deller, gregkh
In-Reply-To: <20260107044258.528624-3-chintanlike@gmail.com>
Am 07.01.26 um 05:42 schrieb Chintan Patel:
> fbtft provides sysfs interfaces for debugging and gamma configuration,
> but these are not required for the core driver.
>
> Drop the hard dependency on CONFIG_FB_DEVICE and make sysfs support
> optional by using dev_of_fbinfo() at runtime. When FB_DEVICE is disabled,
> sysfs operations are skipped while the code remains buildable and
> type-checked.
>
> Suggested-by: Thomas Zimmermann <tzimmermann@suse.de>
> Suggested-by: Helge Deller <deller@gmx.de>
> Reviewed-by: Helge Deller <deller@gmx.de>
> Signed-off-by: Chintan Patel <chintanlike@gmail.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
> drivers/staging/fbtft/Kconfig | 5 ++++-
> drivers/staging/fbtft/fbtft-sysfs.c | 20 ++++++++++++++++----
> 2 files changed, 20 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/staging/fbtft/Kconfig b/drivers/staging/fbtft/Kconfig
> index c2655768209a..578412a2f379 100644
> --- a/drivers/staging/fbtft/Kconfig
> +++ b/drivers/staging/fbtft/Kconfig
> @@ -2,11 +2,14 @@
> menuconfig FB_TFT
> tristate "Support for small TFT LCD display modules"
> depends on FB && SPI
> - depends on FB_DEVICE
> depends on BACKLIGHT_CLASS_DEVICE
> depends on GPIOLIB || COMPILE_TEST
> select FB_BACKLIGHT
> select FB_SYSMEM_HELPERS_DEFERRED
> + help
> + Support for small TFT LCD display modules over SPI bus. FB_DEVICE
> + is not required, but if enabled, provides sysfs interface for debugging
> + and gamma curve configuration.
>
> if FB_TFT
>
> diff --git a/drivers/staging/fbtft/fbtft-sysfs.c b/drivers/staging/fbtft/fbtft-sysfs.c
> index e45c90a03a90..d05599d80011 100644
> --- a/drivers/staging/fbtft/fbtft-sysfs.c
> +++ b/drivers/staging/fbtft/fbtft-sysfs.c
> @@ -203,14 +203,26 @@ static struct device_attribute debug_device_attr =
>
> void fbtft_sysfs_init(struct fbtft_par *par)
> {
> - device_create_file(par->info->dev, &debug_device_attr);
> + struct device *dev;
> +
> + dev = dev_of_fbinfo(par->info);
> + if (!dev)
> + return;
> +
> + device_create_file(dev, &debug_device_attr);
> if (par->gamma.curves && par->fbtftops.set_gamma)
> - device_create_file(par->info->dev, &gamma_device_attrs[0]);
> + device_create_file(dev, &gamma_device_attrs[0]);
> }
>
> void fbtft_sysfs_exit(struct fbtft_par *par)
> {
> - device_remove_file(par->info->dev, &debug_device_attr);
> + struct device *dev;
> +
> + dev = dev_of_fbinfo(par->info);
> + if (!dev)
> + return;
> +
> + device_remove_file(dev, &debug_device_attr);
> if (par->gamma.curves && par->fbtftops.set_gamma)
> - device_remove_file(par->info->dev, &gamma_device_attrs[0]);
> + device_remove_file(dev, &gamma_device_attrs[0]);
> }
--
--
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 v4 1/4] fb: Add dev_of_fbinfo() helper for optional sysfs support
From: Thomas Zimmermann @ 2026-01-07 7:32 UTC (permalink / raw)
To: Chintan Patel, linux-fbdev, linux-staging, linux-omap
Cc: linux-kernel, dri-devel, andy, deller, gregkh
In-Reply-To: <20260107044258.528624-2-chintanlike@gmail.com>
Am 07.01.26 um 05:42 schrieb Chintan Patel:
> 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>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
> include/linux/fb.h | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index 05cc251035da..dad3fb61a06a 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -628,6 +628,15 @@ static inline void unlock_fb_info(struct fb_info *info)
> mutex_unlock(&info->lock);
> }
>
> +static inline struct device *dev_of_fbinfo(const struct fb_info *info)
> +{
> +#ifdef CONFIG_FB_DEVICE
> + return info->dev;
> +#else
> + return NULL;
> +#endif
> +}
> +
> static inline void __fb_pad_aligned_buffer(u8 *dst, u32 d_pitch,
> u8 *src, u32 s_pitch, u32 height)
> {
--
--
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
* [PATCH v4 4/4] fbdev: sh_mobile_lcdc: Make FB_DEVICE dependency optional
From: Chintan Patel @ 2026-01-07 4:42 UTC (permalink / raw)
To: linux-fbdev, linux-staging, linux-omap
Cc: linux-kernel, dri-devel, tzimmermann, andy, deller, gregkh,
Chintan Patel
In-Reply-To: <20260107044258.528624-1-chintanlike@gmail.com>
The sh_mobile_lcdc driver exposes overlay configuration via sysfs, but the
core driver does not require CONFIG_FB_DEVICE.
Make overlay sysfs optional so that the driver can build and operate
even when FB_DEVICE is disabled. The kernel naturally ignores the
missing attribute group, preserving buildability and type safety.
Suggested-by: Helge Deller <deller@gmx.de>
Signed-off-by: Chintan Patel <chintanlike@gmail.com>
---
drivers/video/fbdev/sh_mobile_lcdcfb.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/sh_mobile_lcdcfb.c b/drivers/video/fbdev/sh_mobile_lcdcfb.c
index dd950e4ab5ce..5f3a0cd27db3 100644
--- a/drivers/video/fbdev/sh_mobile_lcdcfb.c
+++ b/drivers/video/fbdev/sh_mobile_lcdcfb.c
@@ -1343,14 +1343,17 @@ static DEVICE_ATTR_RW(overlay_mode);
static DEVICE_ATTR_RW(overlay_position);
static DEVICE_ATTR_RW(overlay_rop3);
-static struct attribute *overlay_sysfs_attrs[] = {
+static struct attribute *overlay_sysfs_attrs[] __maybe_unused = {
&dev_attr_overlay_alpha.attr,
&dev_attr_overlay_mode.attr,
&dev_attr_overlay_position.attr,
&dev_attr_overlay_rop3.attr,
NULL,
};
+
+#ifdef CONFIG_FB_DEVICE
ATTRIBUTE_GROUPS(overlay_sysfs);
+#endif
static const struct fb_fix_screeninfo sh_mobile_lcdc_overlay_fix = {
.id = "SH Mobile LCDC",
--
2.43.0
^ permalink raw reply related
* [PATCH v4 3/4] fbdev: omapfb: Make FB_DEVICE dependency optional
From: Chintan Patel @ 2026-01-07 4:42 UTC (permalink / raw)
To: linux-fbdev, linux-staging, linux-omap
Cc: linux-kernel, dri-devel, tzimmermann, andy, deller, gregkh,
Chintan Patel
In-Reply-To: <20260107044258.528624-1-chintanlike@gmail.com>
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>
---
drivers/video/fbdev/omap2/omapfb/Kconfig | 3 ++-
.../video/fbdev/omap2/omapfb/omapfb-sysfs.c | 18 ++++++++++++++----
2 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/Kconfig b/drivers/video/fbdev/omap2/omapfb/Kconfig
index f4cdf999a080..2d20e79adefc 100644
--- a/drivers/video/fbdev/omap2/omapfb/Kconfig
+++ b/drivers/video/fbdev/omap2/omapfb/Kconfig
@@ -5,7 +5,6 @@ config OMAP2_VRFB
menuconfig FB_OMAP2
tristate "OMAP2+ frame buffer support"
depends on FB
- depends on FB_DEVICE
depends on DRM_OMAP = n
depends on GPIOLIB
select FB_OMAP2_DSS
@@ -13,6 +12,8 @@ menuconfig FB_OMAP2
select FB_IOMEM_HELPERS
help
Frame buffer driver for OMAP2+ based boards.
+ FB_DEVICE is not required, but if enabled, provides sysfs interface
+ for framebuffer configuration and debugging.
if FB_OMAP2
diff --git a/drivers/video/fbdev/omap2/omapfb/omapfb-sysfs.c b/drivers/video/fbdev/omap2/omapfb/omapfb-sysfs.c
index 831b2c2fbdf9..38a635d38d58 100644
--- a/drivers/video/fbdev/omap2/omapfb/omapfb-sysfs.c
+++ b/drivers/video/fbdev/omap2/omapfb/omapfb-sysfs.c
@@ -558,10 +558,15 @@ int omapfb_create_sysfs(struct omapfb2_device *fbdev)
DBG("create sysfs for fbs\n");
for (i = 0; i < fbdev->num_fbs; i++) {
+ struct device *dev;
int t;
+
+ dev = dev_of_fbinfo(fbdev->fbs[i]);
+ if (!dev)
+ continue;
+
for (t = 0; t < ARRAY_SIZE(omapfb_attrs); t++) {
- r = device_create_file(fbdev->fbs[i]->dev,
- &omapfb_attrs[t]);
+ r = device_create_file(dev, &omapfb_attrs[t]);
if (r) {
dev_err(fbdev->dev, "failed to create sysfs "
@@ -580,9 +585,14 @@ void omapfb_remove_sysfs(struct omapfb2_device *fbdev)
DBG("remove sysfs for fbs\n");
for (i = 0; i < fbdev->num_fbs; i++) {
+ struct device *dev;
+
+ dev = dev_of_fbinfo(fbdev->fbs[i]);
+ if (!dev)
+ continue;
+
for (t = 0; t < ARRAY_SIZE(omapfb_attrs); t++)
- device_remove_file(fbdev->fbs[i]->dev,
- &omapfb_attrs[t]);
+ device_remove_file(dev, &omapfb_attrs[t]);
}
}
--
2.43.0
^ permalink raw reply related
* [PATCH v4 2/4] staging: fbtft: Make FB_DEVICE dependency optional
From: Chintan Patel @ 2026-01-07 4:42 UTC (permalink / raw)
To: linux-fbdev, linux-staging, linux-omap
Cc: linux-kernel, dri-devel, tzimmermann, andy, deller, gregkh,
Chintan Patel
In-Reply-To: <20260107044258.528624-1-chintanlike@gmail.com>
fbtft provides sysfs interfaces for debugging and gamma configuration,
but these are not required for the core driver.
Drop the hard dependency on CONFIG_FB_DEVICE and make sysfs support
optional by using dev_of_fbinfo() at runtime. When FB_DEVICE is disabled,
sysfs operations are skipped while the code remains buildable and
type-checked.
Suggested-by: Thomas Zimmermann <tzimmermann@suse.de>
Suggested-by: Helge Deller <deller@gmx.de>
Reviewed-by: Helge Deller <deller@gmx.de>
Signed-off-by: Chintan Patel <chintanlike@gmail.com>
---
drivers/staging/fbtft/Kconfig | 5 ++++-
drivers/staging/fbtft/fbtft-sysfs.c | 20 ++++++++++++++++----
2 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/fbtft/Kconfig b/drivers/staging/fbtft/Kconfig
index c2655768209a..578412a2f379 100644
--- a/drivers/staging/fbtft/Kconfig
+++ b/drivers/staging/fbtft/Kconfig
@@ -2,11 +2,14 @@
menuconfig FB_TFT
tristate "Support for small TFT LCD display modules"
depends on FB && SPI
- depends on FB_DEVICE
depends on BACKLIGHT_CLASS_DEVICE
depends on GPIOLIB || COMPILE_TEST
select FB_BACKLIGHT
select FB_SYSMEM_HELPERS_DEFERRED
+ help
+ Support for small TFT LCD display modules over SPI bus. FB_DEVICE
+ is not required, but if enabled, provides sysfs interface for debugging
+ and gamma curve configuration.
if FB_TFT
diff --git a/drivers/staging/fbtft/fbtft-sysfs.c b/drivers/staging/fbtft/fbtft-sysfs.c
index e45c90a03a90..d05599d80011 100644
--- a/drivers/staging/fbtft/fbtft-sysfs.c
+++ b/drivers/staging/fbtft/fbtft-sysfs.c
@@ -203,14 +203,26 @@ static struct device_attribute debug_device_attr =
void fbtft_sysfs_init(struct fbtft_par *par)
{
- device_create_file(par->info->dev, &debug_device_attr);
+ struct device *dev;
+
+ dev = dev_of_fbinfo(par->info);
+ if (!dev)
+ return;
+
+ device_create_file(dev, &debug_device_attr);
if (par->gamma.curves && par->fbtftops.set_gamma)
- device_create_file(par->info->dev, &gamma_device_attrs[0]);
+ device_create_file(dev, &gamma_device_attrs[0]);
}
void fbtft_sysfs_exit(struct fbtft_par *par)
{
- device_remove_file(par->info->dev, &debug_device_attr);
+ struct device *dev;
+
+ dev = dev_of_fbinfo(par->info);
+ if (!dev)
+ return;
+
+ device_remove_file(dev, &debug_device_attr);
if (par->gamma.curves && par->fbtftops.set_gamma)
- device_remove_file(par->info->dev, &gamma_device_attrs[0]);
+ device_remove_file(dev, &gamma_device_attrs[0]);
}
--
2.43.0
^ permalink raw reply related
* [PATCH v4 1/4] fb: Add dev_of_fbinfo() helper for optional sysfs support
From: Chintan Patel @ 2026-01-07 4:42 UTC (permalink / raw)
To: linux-fbdev, linux-staging, linux-omap
Cc: linux-kernel, dri-devel, tzimmermann, andy, deller, gregkh,
Chintan Patel
In-Reply-To: <20260107044258.528624-1-chintanlike@gmail.com>
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(+)
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 05cc251035da..dad3fb61a06a 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -628,6 +628,15 @@ static inline void unlock_fb_info(struct fb_info *info)
mutex_unlock(&info->lock);
}
+static inline struct device *dev_of_fbinfo(const struct fb_info *info)
+{
+#ifdef CONFIG_FB_DEVICE
+ return info->dev;
+#else
+ return NULL;
+#endif
+}
+
static inline void __fb_pad_aligned_buffer(u8 *dst, u32 d_pitch,
u8 *src, u32 s_pitch, u32 height)
{
--
2.43.0
^ permalink raw reply related
* [PATCH v4 0/4] fbdev: Make CONFIG_FB_DEVICE optional for drivers
From: Chintan Patel @ 2026-01-07 4:42 UTC (permalink / raw)
To: linux-fbdev, linux-staging, linux-omap
Cc: linux-kernel, dri-devel, tzimmermann, andy, deller, gregkh,
Chintan Patel
This series makes CONFIG_FB_DEVICE optional for fbdev drivers that use
it only for sysfs interfaces, addressing Thomas Zimmermann’s TODO to
remove hard FB_DEVICE dependencies.
The series introduces a small helper, dev_of_fbinfo(), which returns
NULL when CONFIG_FB_DEVICE=n. This allows sysfs code paths to be skipped
via runtime checks, avoids #ifdef CONFIG_FB_DEVICE clutter, and keeps
full compile-time syntax checking.
Signed-off-by: Chintan Patel <chintanlike@gmail.com>
---
Changes in v4:
- PTR_IF() was removed and overlay sysfs is now optional via __maybe_unused
and #ifdef CONFIG_FB_DEVICE (suggested by Helge Deller)
- Decouple variable definition and assignment in
omapfb_remove/create_sysfs (suggested by Andy Shevchenko)
- Added Reviewed-by tags:
- fb: Add dev_of_fbinfo(): Helge Deller, Andy Shevchenko
- staging: fbtft: Helge Deller
Changes in v3:
- Use PTR_IF() to conditionally include overlay_sysfs_group in
overlay_sysfs_groups(suggested by Andy Shevchenko)
- Decouple variable definition and assignment in
fbtft_sysfs_init/exit(suggested by Andy Shevchenko)
Changes in v2:
- Add dev_of_fbinfo() helper (suggested by Helge Deller)
- Replace #ifdef CONFIG_FB_DEVICE blocks with runtime NULL checks
- Switch to fb_dbg() / fb_info() logging (suggested by Thomas Zimmermann)
---
Chintan Patel (4):
fb: Add dev_of_fbinfo() helper for optional sysfs support
staging: fbtft: Make FB_DEVICE dependency optional
fbdev: omapfb: Make FB_DEVICE dependency optional
fbdev: sh_mobile_lcdc: Make FB_DEVICE dependency optional
drivers/staging/fbtft/Kconfig | 5 ++++-
drivers/staging/fbtft/fbtft-sysfs.c | 20 +++++++++++++++----
drivers/video/fbdev/omap2/omapfb/Kconfig | 3 ++-
.../video/fbdev/omap2/omapfb/omapfb-sysfs.c | 18 +++++++++++++----
drivers/video/fbdev/sh_mobile_lcdcfb.c | 5 ++++-
include/linux/fb.h | 9 +++++++++
6 files changed, 49 insertions(+), 11 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