Hi Harry, Leo and other amdgpu maintainers,
On 2024-08-24 20:33:53+, Thomas Weißschuh wrote:
> The value of "min_input_signal" returned from ATIF on a Framework AMD 13
> is "12". This leads to a fairly bright minimum display backlight.
>
> Introduce a quirk t
On 2024-08-30 12:16:46+, Helge Deller wrote:
> On 8/30/24 11:45, Thomas Weißschuh wrote:
> > Introduce a device-managed variant of register_framebuffer() which
> > automatically unregisters the framebuffer on device destruction.
> > This can simplify the error handling an
Introduce a device-managed variant of register_framebuffer() which
automatically unregisters the framebuffer on device destruction.
This can simplify the error handling and resource management in drivers.
Signed-off-by: Thomas Weißschuh
---
This is a fixed resend of [0], which was broken.
Thanks
Hi everybody,
On 2024-08-27 17:25:14+, Thomas Weißschuh wrote:
> Introduce a device-managed variant of register_framebuffer() which
> automatically unregisters the framebuffer on device destruction.
> This can simplify the error handling and resource management in drivers.
Bert repo
On 2024-08-28 19:42:51+, Helge Deller wrote:
> On 8/27/24 17:25, Thomas Weißschuh wrote:
> > These variables are only used inside efifb_probe().
> > Afterwards they are using memory unnecessarily.
>
> Did you check if this change really saves some memory?
Nope...
&g
The driver core can register and cleanup sysfs groups already.
Make use of that functionality to simplify the error handling and
cleanup.
Also avoid a UAF race during unregistering where the sysctl attributes
were usable after the info struct was freed.
Signed-off-by: Thomas Weißschuh
Since commit b9cfd1d271ab ("fbdev/efifb: Use screen_info pointer from device")
efifb uses a local copy of screen_info and applies its modifications
there. Adapt the sysfs attributes to also work with the custom copy
instead of the unmodified platform data.
Signed-off-by: Thomas
These variables are only used inside efifb_probe().
Afterwards they are using memory unnecessarily.
Signed-off-by: Thomas Weißschuh
---
drivers/video/fbdev/efifb.c | 36 ++--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/video/fbdev
Introduce a device-managed variant of register_framebuffer() which
automatically unregisters the framebuffer on device destruction.
This can simplify the error handling and resource management in drivers.
Signed-off-by: Thomas Weißschuh
---
drivers/video/fbdev/core/fbmem.c | 24
This simplifies the error handling.
Also the drvdata slot is now unused and can be used for other usecases.
Signed-off-by: Thomas Weißschuh
---
drivers/video/fbdev/efifb.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/video/fbdev/efifb.c b/drivers
Some random optimization and fixes I came up with while looking at
efifb.c.
I can't get the efifb driver to probe on my hardware,
so this is only compile-tested.
If somebody could actually test it, that would be great.
Signed-off-by: Thomas Weißschuh
---
Thomas Weißschuh (5):
fbdev/
uot;
sysfs file has not shown any negative impact.
One quirk seems to be that 0% at panel_power_savings=0 seems to be
slightly darker than at panel_power_savings=4.
Signed-off-by: Thomas Weißschuh
Tested-by: Dustin L. Howett
Reviewed-by: Mario Limonciello
---
drivers/gpu/drm/amd/amdg
isible.
Tested on a Framework AMD 13 BIOS 3.05 with the matte panel.
Link: https://community.frame.work/t/25711/9
Link: https://community.frame.work/t/47036
Signed-off-by: Thomas Weißschuh
Tested-by: Dustin L. Howett
Reviewed-by: Mario Limonciello
---
drivers/gpu/drm/drm_panel_backlight_quirks.
ucture
- Quirk by EDID and DMI instead of only DMI
- Limit quirk to only single Framework 13 matte panel
- Link to v1:
https://lore.kernel.org/r/20240610-amdgpu-min-backlight-quirk-v1-1-8459895a5...@weissschuh.net
---
Dustin L. Howett (1):
drm: panel-backlight-quirks: Add Framework 13 gloss
From: "Dustin L. Howett"
I have tested these panels on the Framework Laptop 13 AMD with firmware
revision 3.05 (latest at time of submission).
Signed-off-by: Dustin L. Howett
Signed-off-by: Thomas Weißschuh
Reviewed-by: Mario Limonciello
---
drivers/gpu/drm/drm_panel_backlight_qui
panels.
Add a quirk infrastructure with which the minimum valid backlight value
can be maintained as part of the kernel.
Signed-off-by: Thomas Weißschuh
Tested-by: Dustin L. Howett
Reviewed-by: Mario Limonciello
---
Documentation/gpu/drm-kms-helpers.rst| 3 ++
drivers/gpu/drm/Kconfig
"struct drm_edid" is the safe and recommended alternative to "struct edid".
Rename the member to make sure that no usage sites are missed,
as "struct drm_edid" has some restrictions, for example it can not be
used with kfree().
Signed-off-by: Thomas Weißschuh
---
On 2024-08-21 15:54:14+, Mario Limonciello wrote:
> On 8/18/2024 01:56, Thomas Weißschuh wrote:
> > Not all platforms provide correct PWM backlight capabilities through ATIF.
>
> I don't think correct is an accurate term here. How about 'optimial'?
Looks typ
On 2024-08-21 15:51:17+, Mario Limonciello wrote:
> On 8/18/2024 01:56, Thomas Weißschuh wrote:
> > Panels using a PWM-controlled backlight source do not have a standard
> > way to communicate their valid PWM ranges.
> > On x86 the ranges are read from ACPI through d
Hi Mario,
(+ a question for Dustin inside)
On 2024-08-21 15:45:46+, Mario Limonciello wrote:
> On 8/18/2024 01:56, Thomas Weißschuh wrote:
> > The value of "min_input_signal" returned from ATIF on a Framework AMD 13
> > is "12". This leads to a fair
Hi Melissa,
On 2024-08-19 11:31:44+, Melissa Wen wrote:
> On 08/18, Thomas Weißschuh wrote:
> > The AMD DRM drivers use 'struct edid', raw pointers and even custom
> > structs to represent EDID data.
> > Uniformly switch to the safe and recommended "str
On 2024-08-19 11:51:45+, Jani Nikula wrote:
> On Sun, 18 Aug 2024, Thomas Weißschuh wrote:
> > "struct drm_edid" is the safe and recommended alternative to "struct edid".
> >
> > Rename the member to make sure that no usage sites are missed,
> >
On 2024-08-19 11:21:21+, Jani Nikula wrote:
> On Sun, 18 Aug 2024, Thomas Weißschuh wrote:
> > drm_edid_is_valid() does not modify its argument, so mark it as const.
>
> That's not true.
Indeed, thanks for noticing.
It turns out this patch is not necessary anyways and
"struct drm_edid" is the safe and recommended alternative to "struct edid".
Rename the member to make sure that no usage sites are missed,
as "struct drm_edid" has some restrictions, for example it can not be
used with kfree().
Signed-off-by: Thomas Weißschuh
-
The callers of dc_link_add_remote_sink() are using 'struct edid' which
they all need to cast to uint8_t *.
Allow the direct passing of 'struct edid' to avoid these cast and also
move the length calculation so it does not need to be duplicated
everywhere.
Signed-off-
The argument edid is passed in as const.
Preserve this constness through the edid_buf variable and the used
helper functions.
Signed-off-by: Thomas Weißschuh
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a
The custom "struct dc_edid" can be replaced by the standard "struct
drm_edid.
Rename the member to make sure that no usage sites are missed,
as "struct drm_edid" has some restrictions, for example it can not be
used with kfree().
Signed-off-by: Thomas Weißschuh
---
dr
Reduce the number of casts needed by reusing the edid_buf variable.
Also initialize edid_buf after the !edid case has been handled to avoid
the ternary expression.
Signed-off-by: Thomas Weißschuh
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 8 +---
1 file changed, 5
"struct drm_edid" is the safe and recommended alternative to "struct edid".
Rename the member to make sure that no usage sites are missed,
as "struct drm_edid" has some restrictions, for example it can not be
used with kfree().
Signed-off-by: Thomas Weißschuh
-
drm_edid_is_valid() does not modify its argument, so mark it as const.
Signed-off-by: Thomas Weißschuh
---
drivers/gpu/drm/drm_edid.c | 2 +-
include/drm/drm_edid.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
The parsing functions do not modify their edid argument.
Mark the const to reflect this to the caller.
Signed-off-by: Thomas Weißschuh
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 14 +++---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 2 +-
2 files changed, 8
"struct drm_edid" is the safe and recommended alternative to "struct edid".
Now that all callers of dc_link_add_remote_sink() have access to a
validate struct drm_edid, pass it around directly.
Signed-off-by: Thomas Weißschuh
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgp
"struct drm_edid" is the safe and recommended alternative to "struct edid".
Rename the member to make sure that no usage sites are missed,
as "struct drm_edid" has some restrictions, for example it can not be
used with kfree().
Signed-off-by: Thomas Weißschuh
--
As struct drm_edid is opaque, drivers can't directly memcmp() the
contained data. Add a helper to provide this functionality.
Signed-off-by: Thomas Weißschuh
---
drivers/gpu/drm/drm_edid.c | 18 ++
include/drm/drm_edid.h | 1 +
2 files changed, 19 insertions(+)
diff
The prototype is the whole content of commit
575d0df6dae4 ("drm/amd/display: refine the EDID override").
Apparently the definition was never added.
Fixes: 575d0df6dae4 ("drm/amd/display: refine the EDID override")
Signed-off-by: Thomas Weißschuh
---
drivers/gpu/drm/amd/dis
All usages of these fields have been removed.
Fixes: 7c7f5b15be65 ("drm/amd/display: Refactor edid read.")
Signed-off-by: Thomas Weißschuh
---
drivers/gpu/drm/amd/display/dc/dc_ddc_types.h | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dc_ddc_
around some code.
The remaining patches perform the actual conversion in steps.
[0]
https://lore.kernel.org/lkml/20240818-amdgpu-min-backlight-quirk-v5-0-b6c0ead0c...@weissschuh.net/
Signed-off-by: Thomas Weißschuh
---
Thomas Weißschuh (12):
drm/amd/display: remove spurious definition for
d
panels.
Add a quirk infrastructure with which the minimum valid backlight value
can be maintained as part of the kernel.
Signed-off-by: Thomas Weißschuh
Tested-by: Dustin L. Howett
---
Documentation/gpu/drm-kms-helpers.rst| 3 ++
drivers/gpu/drm/Kconfig | 4
Not all platforms provide correct PWM backlight capabilities through ATIF.
Use the generic drm panel minimum backlight quirk infrastructure to
override the capabilities where necessary.
Signed-off-by: Thomas Weißschuh
Tested-by: Dustin L. Howett
---
drivers/gpu/drm/amd/amdgpu/Kconfig
isible.
Tested on a Framework AMD 13 BIOS 3.05 with the matte panel.
Link: https://community.frame.work/t/25711/9
Link: https://community.frame.work/t/47036
Signed-off-by: Thomas Weißschuh
Tested-by: Dustin L. Howett
---
drivers/gpu/drm/drm_panel_backlight_quirks.c | 8
1 file changed,
From: "Dustin L. Howett"
I have tested these panels on the Framework Laptop 13 AMD with firmware
revision 3.05 (latest at time of submission).
Signed-off-by: Dustin L. Howett
---
drivers/gpu/drm/drm_panel_backlight_quirks.c | 16
1 file changed, 16 insertions(+)
diff --git a/
net
---
Dustin L. Howett (1):
drm: panel-backlight-quirks: Add Framework 13 glossy and 2.8k panels
Thomas Weißschuh (3):
drm: Add panel backlight quirks
drm/amd/display: Add support for minimum backlight quirk
drm: panel-backlight-quirks: Add Framework 13 matte panel
Hi Dustin,
On 2024-08-17 14:23:42+, Dustin Howett wrote:
> On Sat, Aug 17, 2024 at 1:59 PM Dustin L. Howett wrote:
> >
> > This patch depends on
> > 20240812-amdgpu-min-backlight-quirk-v4-0-56a63ff89...@weissschuh.net
> >
> > I have tested these panels on the Framework Laptop 13 AMD with firm
isible.
Tested on a Framework AMD 13 BIOS 3.05 with the matte panel.
Link: https://community.frame.work/t/25711/9
Link: https://community.frame.work/t/47036
Signed-off-by: Thomas Weißschuh
---
drivers/gpu/drm/drm_panel_backlight_quirks.c | 8
1 file changed, 8 insertions(+)
with newer panels.
Add a quirk infrastructure with which the minimum valid backlight value
can be maintained as part of the kernel.
Signed-off-by: Thomas Weißschuh
---
Documentation/gpu/drm-kms-helpers.rst| 3 ++
drivers/gpu/drm/Kconfig | 4 ++
drivers/gpu/drm
Not all platforms provide correct PWM backlight capabilities through ATIF.
Use the generic drm panel minimum backlight quirk infrastructure to
override the capabilities where necessary.
Signed-off-by: Thomas Weißschuh
---
drivers/gpu/drm/amd/amdgpu/Kconfig| 1 +
drivers/gpu/drm
mdgpu-min-backlight-quirk-v1-1-8459895a5...@weissschuh.net
---
Thomas Weißschuh (3):
drm: Add panel backlight quirks
drm: panel-backlight-quirks: Add Framework 13 matte panel
drm/amd/display: Add support for minimum backlight quirk
Documentation/gpu/drm-kms-helpers.rst
On 2024-08-10 15:30:58+, Aditya Garg wrote:
>
> >
> > Also include linux/device.h as you are using functions from there.
> > Like devm_kcalloc().
>
> Alright, I’ll add that
> >
> >>>
> +#include
> +#include
> +
> +#include "hid-ids.h"
> +
> +#define APPLETB_
On 2024-08-10 13:23:30+, Aditya Garg wrote:
> Hi Thomas
>
> >> diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
> >> index e40f1ddeb..1d825a474 100644
> >> --- a/drivers/hid/Makefile
> >> +++ b/drivers/hid/Makefile
> >> @@ -29,6 +29,7 @@ obj-$(CONFIG_HID_ALPS) += hid-alps.o
> >> obj-$(
On 2024-08-08 13:50:33+, Aditya Garg wrote:
> From: Kerem Karabay
>
> This commit adds a driver for the backlight of Apple Touch Bars on x86
> Macs. Note that currently only T2 Macs are supported.
>
> This driver is based on previous work done by Ronald Tschalär
> .
>
> Signed-off-by: Kerem
Hi,
On 2024-08-01 10:52:55+, Hans de Goede wrote:
> On 7/31/24 10:55 PM, Daniel Vetter wrote:
> > On Wed, Jul 31, 2024 at 08:40:12PM +0300, Jani Nikula wrote:
> >> On Wed, 31 Jul 2024, Thomas Weißschuh wrote:
> >>> The value of "min_input_signal"
I
- Limit quirk to only single Framework 13 matte panel
- Link to v1:
https://lore.kernel.org/r/20240610-amdgpu-min-backlight-quirk-v1-1-8459895a5...@weissschuh.net
---
Thomas Weißschuh (2):
drm/connector: add drm_connector_get_cmdline_min_brightness_override()
drm/amd/display: impleme
This is useful if the minimum backlight as reported by machines VBT
does not match the user expectations.
As an example, the minimum backlight brightness on the Framework 13
matte panel is too high.
Signed-off-by: Thomas Weißschuh
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 6
-off-by: Thomas Weißschuh
---
drivers/gpu/drm/drm_connector.c | 34 ++
include/drm/drm_connector.h | 2 ++
2 files changed, 36 insertions(+)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index ab6ab7ff7ea8..d0b3d5d6c7c2 100644
x27;
completely for which this series provides the foundation.
Only compile-tested.
Signed-off-by: Thomas Weißschuh
---
Changes in v2:
- Rebase onto current amdgpu/drm-next and
recent changes to hardcoded bios handling
- Add patch for drm/radeon
- Link to v1:
https://lore.kernel.org/r/
p;array[0]' to the equivalent
'array' and using 'max_t(int, ...)' instead of manual casts.
Signed-off-by: Thomas Weißschuh
---
drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 6 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 4 ++--
drivers/gpu/drm/amd/amdgpu/a
p;array[0]' to the equivalent
'array' and using 'max_t(int, ...)' instead of manual casts.
Signed-off-by: Thomas Weißschuh
---
drivers/gpu/drm/radeon/radeon_atombios.c | 17 ++---
drivers/gpu/drm/radeon/radeon_combios.c| 26 +
Hi amdgpu maintainers,
did you get a chance to look at the patch and the suspected bug?
Thanks,
Thomas
On 2024-06-16 20:14:45+, Thomas Weißschuh wrote:
> On 2024-06-16 11:12:03+0000, Thomas Weißschuh wrote:
> > Instead of manually passing around 'struct edid *' and its si
Hi Hans,
On 2024-07-18 10:25:18+, Hans de Goede wrote:
> On 6/24/24 6:15 PM, Thomas Weißschuh wrote:
> > On 2024-06-24 11:11:40+, Hans de Goede wrote:
> >> On 6/23/24 10:51 AM, Thomas Weißschuh wrote:
> >>> The value of "min_input_signal" returned
Hi Hans!
thanks for your feedback!
On 2024-06-24 11:11:40+, Hans de Goede wrote:
> On 6/23/24 10:51 AM, Thomas Weißschuh wrote:
> > The value of "min_input_signal" returned from ATIF on a Framework AMD 13
> > is "12". This leads to a fairly bright minimu
isible.
Tested on a Framework AMD 13 BIOS 3.05 with the matte panel.
Link: https://community.frame.work/t/25711/9
Link: https://community.frame.work/t/47036
Signed-off-by: Thomas Weißschuh
---
drivers/gpu/drm/drm_panel_backlight_quirks.c | 9 +
1 file changed, 9 insertions(+)
ework 13 matte panel
- Link to v1:
https://lore.kernel.org/r/20240610-amdgpu-min-backlight-quirk-v1-1-8459895a5...@weissschuh.net
---
Thomas Weißschuh (3):
drm: Add panel backlight quirks
drm: panel-backlight-quirks: Add Framework 13 matte panel
drm/amd/display: Add support ba
with newer panels.
Add a quirk infrastructure with which the valid backlight ranges can be
maintained as part of the kernel.
Signed-off-by: Thomas Weißschuh
---
Documentation/gpu/drm-kms-helpers.rst| 3 ++
drivers/gpu/drm/Kconfig | 4 ++
drivers/gpu/drm/Makefile
Not all platforms provide correct PWM backlight capabilities through ATIF.
Use the generic drm backlight quirk infrastructure to override the
capabilities where necessary.
Signed-off-by: Thomas Weißschuh
---
drivers/gpu/drm/amd/amdgpu/Kconfig| 1 +
drivers/gpu/drm/amd/display
On 2024-06-16 11:12:03+, Thomas Weißschuh wrote:
> Instead of manually passing around 'struct edid *' and its size,
> use 'struct drm_edid', which encapsulates a validated combination of
> both.
>
> As the drm_edid_ can handle NULL gracefully, the explicit
p;array[0]' to the equivalent
'array' and using 'max_t(int, ...)' instead of manual casts.
Signed-off-by: Thomas Weißschuh
---
While this patch introduces a new user for drm_edid_raw(),
if amdgpu proper gets migrated to 'struct drm_edid', that usage will go
away.
On 2024-06-10 14:58:02+, Mario Limonciello wrote:
> +Kieran
>
> On 6/10/2024 14:26, Thomas Weißschuh wrote:
> > The value of "min_input_signal" returned from ATIF on a Framework AMD 13
> > is "12". This leads to a fairly bright minimum display backligh
readable even in daylight.
Tested on a Framework AMD 13 BIOS 3.05 and Framework AMD 16.
Link: https://community.frame.work/t/25711/9
Link: https://community.frame.work/t/47036
Signed-off-by: Thomas Weißschuh
---
drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 35
+Cc Hans who ins involved with the backlight subsystem
Hi Julius,
today I stumbled upon a mail from Hans [0], which explains that the
backlight subsystem is not actually a good fit (yet?) for external
displays.
It seems a new API is in the works that would better fit, but I'm not
sure about the
On 2023-08-20 11:41:18+0200, Julius Zint wrote:
> [..]
> diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
> index 51387b1ef012..b964a820956d 100644
> --- a/drivers/video/backlight/Kconfig
> +++ b/drivers/video/backlight/Kconfig
> @@ -472,6 +472,14 @@ config BACKLIGHT_
Hi,
this should probably also go to the maintainers of the "HID CORE LAYER"
for review:
HID CORE LAYER
M: Jiri Kosina
M: Benjamin Tissoires
L: linux-in...@vger.kernel.org
And maybe it would better fit to be in drivers/hid/ ?
(Something for the maintainers to figure out)
Some t
Since commit ee6d3dd4ed48 ("driver core: make kobj_type constant.")
the driver core allows the usage of const struct kobj_type.
Take advantage of this to constify the structure definition to prevent
modification at runtime.
Signed-off-by: Thomas Weißschuh
---
drivers/dma-buf/dma
Since commit ee6d3dd4ed48 ("driver core: make kobj_type constant.")
the driver core allows the usage of const struct kobj_type.
Take advantage of this to constify the structure definitions to prevent
modification at runtime.
Signed-off-by: Thomas Weißschuh
---
drivers/gpu/drm/
Since commit ee6d3dd4ed48 ("driver core: make kobj_type constant.")
the driver core allows the usage of const struct kobj_type.
Take advantage of this to constify the structure definitions to prevent
modification at runtime.
Signed-off-by: Thomas Weißschuh
---
drivers/gpu/drm/
Since commit ee6d3dd4ed48 ("driver core: make kobj_type constant.")
the driver core allows the usage of const struct kobj_type.
Take advantage of this to constify the structure definitions to prevent
modification at runtime.
Signed-off-by: Thomas Weißschuh
---
drivers/gpu/d
Instead of relying on an accidental, transitive inclusion of linux/leds.h
use it directly.
Also drop the forware definition of struct led_classdev that is now
provided by linux/leds.h.
Signed-off-by: Thomas Weißschuh
---
drivers/gpu/drm/nouveau/nouveau_led.h | 2 +-
1 file changed, 1 insertion
On 2021-09-23T10:48+0100, Lee Jones wrote:
> On Tue, 07 Sep 2021, Thomas Weißschuh wrote:
>
> > backlight.h documents "struct backlight_ops->get_brightness()" to return
> > a negative errno on failure.
> > So far these errors have not been handled in the backl
On 2021-09-07T14:47+0200, Thomas Weißschuh wrote:
> backlight.h documents "struct backlight_ops->get_brightness()" to return
> a negative errno on failure.
> So far these errors have not been handled in the backlight core.
> This leads to negative values being exposed th
On 2021-09-07T14:10+0100, Daniel Thompson wrote:
> On Tue, Sep 07, 2021 at 02:47:51PM +0200, Thomas Weißschuh wrote:
> > backlight.h documents "struct backlight_ops->get_brightness()" to return
> > a negative errno on failure.
> > So far these errors have not
.
Signed-off-by: Thomas Weißschuh
---
v1:
https://lore.kernel.org/dri-devel/20210906215525.15418-1-li...@weissschuh.net/
v1 -> v2:
* use dev_err() instead of dev_warn() (Daniel Thompson)
* Finish logging format string with newline (Daniel Thompson)
* Log errno via dedicated error pointe
.
Signed-off-by: Thomas Weißschuh
---
drivers/video/backlight/backlight.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/video/backlight/backlight.c
b/drivers/video/backlight/backlight.c
index 537fe1b376ad..d681962f8509 100644
--- a/drivers/vi
81 matches
Mail list logo
