linux-stable.git/drivers/video/backlight, branch v5.16.3

backlight: qcom-wled: Respect enabled-strings in set_brightness

2022-01-27T11:01:52+00:00

[ Upstream commit ec961cf3241153e0f27d850f1bf0f172e7d27a21 ]

The hardware is capable of controlling any non-contiguous sequence of
LEDs specified in the DT using qcom,enabled-strings as u32
array, and this also follows from the DT-bindings documentation.  The
numbers specified in this array represent indices of the LED strings
that are to be enabled and disabled.

Its value is appropriately used to setup and enable string modules, but
completely disregarded in the set_brightness paths which only iterate
over the number of strings linearly.
Take an example where only string 2 is enabled with
qcom,enabled_strings=<2>: this string is appropriately enabled but
subsequent brightness changes would have only touched the zero'th
brightness register because num_strings is 1 here.  This is simply
addressed by looking up the string for this index in the enabled_strings
array just like the other codepaths that iterate over num_strings.

Likewise enabled_strings is now also used in the autodetection path for
consistent behaviour: when a list of strings is specified in DT only
those strings will be probed for autodetection, analogous to how the
number of strings that need to be probed is already bound by
qcom,num-strings.  After all autodetection uses the set_brightness
helpers to set an initial value, which could otherwise end up changing
brightness on a different set of strings.

Fixes: 775d2ffb4af6 ("backlight: qcom-wled: Restructure the driver for WLED3")
Fixes: 03b2b5e86986 ("backlight: qcom-wled: Add support for WLED4 peripheral")
Signed-off-by: Marijn Suijten 
Reviewed-by: AngeloGioacchino Del Regno 
Reviewed-by: Daniel Thompson 
Signed-off-by: Lee Jones 
Link: https://lore.kernel.org/r/20211115203459.1634079-10-marijn.suijten@somainline.org
Signed-off-by: Sasha Levin

backlight: qcom-wled: Use cpu_to_le16 macro to perform conversion

2022-01-27T11:01:52+00:00

[ Upstream commit 0a139358548968b2ff308257b4fbeec7badcc3e1 ]

The kernel already provides appropriate primitives to perform endianness
conversion which should be used in favour of manual bit-wrangling.

Signed-off-by: Marijn Suijten 
Reviewed-by: AngeloGioacchino Del Regno 
Reviewed-by: Daniel Thompson 
Signed-off-by: Lee Jones 
Link: https://lore.kernel.org/r/20211115203459.1634079-4-marijn.suijten@somainline.org
Signed-off-by: Sasha Levin

backlight: qcom-wled: Override default length with qcom,enabled-strings

2022-01-27T11:01:52+00:00

[ Upstream commit 2b4b49602f9feca7b7a84eaa33ad9e666c8aa695 ]

The length of qcom,enabled-strings as property array is enough to
determine the number of strings to be enabled, without needing to set
qcom,num-strings to override the default number of strings when less
than the default (which is also the maximum) is provided in DT.

This also introduces an extra warning when qcom,num-strings is set,
denoting that it is not necessary to set both anymore.  It is usually
more concise to set just qcom,num-length when a zero-based, contiguous
range of strings is needed (the majority of the cases), or to only set
qcom,enabled-strings when a specific set of indices is desired.

Fixes: 775d2ffb4af6 ("backlight: qcom-wled: Restructure the driver for WLED3")
Signed-off-by: Marijn Suijten 
Reviewed-by: AngeloGioacchino Del Regno 
Reviewed-by: Daniel Thompson 
Signed-off-by: Lee Jones 
Link: https://lore.kernel.org/r/20211115203459.1634079-6-marijn.suijten@somainline.org
Signed-off-by: Sasha Levin

backlight: qcom-wled: Fix off-by-one maximum with default num_strings

2022-01-27T11:01:52+00:00

[ Upstream commit 5ada78b26f935f8751852dffa24f6b545b1d2517 ]

When not specifying num-strings in the DT the default is used, but +1 is
added to it which turns WLED3 into 4 and WLED4/5 into 5 strings instead
of 3 and 4 respectively, causing out-of-bounds reads and register
read/writes.  This +1 exists for a deficiency in the DT parsing code,
and is simply omitted entirely - solving this oob issue - by parsing the
property separately much like qcom,enabled-strings.

This also enables more stringent checks on the maximum value when
qcom,enabled-strings is provided in the DT, by parsing num-strings after
enabled-strings to allow it to check against (and in a subsequent patch
override) the length of enabled-strings: it is invalid to set
num-strings higher than that.
The DT currently utilizes it to get around an incorrect fixed read of
four elements from that array (has been addressed in a prior patch) by
setting a lower num-strings where desired.

Fixes: 93c64f1ea1e8 ("leds: add Qualcomm PM8941 WLED driver")
Signed-off-by: Marijn Suijten 
Reviewed-By: AngeloGioacchino Del Regno 
Reviewed-by: Daniel Thompson 
Signed-off-by: Lee Jones 
Link: https://lore.kernel.org/r/20211115203459.1634079-5-marijn.suijten@somainline.org
Signed-off-by: Sasha Levin

backlight: qcom-wled: Pass number of elements to read to read_u32_array

2022-01-27T11:01:52+00:00

[ Upstream commit e29e24bdabfeddbf8b1a4ecac1af439a85150438 ]

of_property_read_u32_array takes the number of elements to read as last
argument. This does not always need to be 4 (sizeof(u32)) but should
instead be the size of the array in DT as read just above with
of_property_count_elems_of_size.

To not make such an error go unnoticed again the driver now bails
accordingly when of_property_read_u32_array returns an error.
Surprisingly the indentation of newlined arguments is lining up again
after prepending `rc = `.

Fixes: 775d2ffb4af6 ("backlight: qcom-wled: Restructure the driver for WLED3")
Signed-off-by: Marijn Suijten 
Reviewed-by: AngeloGioacchino Del Regno 
Reviewed-by: Daniel Thompson 
Signed-off-by: Lee Jones 
Link: https://lore.kernel.org/r/20211115203459.1634079-3-marijn.suijten@somainline.org
Signed-off-by: Sasha Levin

backlight: qcom-wled: Validate enabled string indices in DT

2022-01-27T11:01:52+00:00

[ Upstream commit c05b21ebc5bce3ecc78c2c71afd76d92c790a2ac ]

The strings passed in DT may possibly cause out-of-bounds register
accesses and should be validated before use.

Fixes: 775d2ffb4af6 ("backlight: qcom-wled: Restructure the driver for WLED3")
Signed-off-by: Marijn Suijten 
Reviewed-by: AngeloGioacchino Del Regno 
Reviewed-by: Daniel Thompson 
Signed-off-by: Lee Jones 
Link: https://lore.kernel.org/r/20211115203459.1634079-2-marijn.suijten@somainline.org
Signed-off-by: Sasha Levin

video: backlight: ili9320: Make ili9320_remove() return void

2021-10-20T14:13:59+00:00

Up to now ili9320_remove() returns zero unconditionally. Make it return
void instead which makes it easier to see in the callers that there is
no error to handle.

Also the return value of spi remove callbacks is ignored anyway.

Signed-off-by: Uwe Kleine-König 
Reviewed-by: Daniel Thompson 
Signed-off-by: Lee Jones 
Link: https://lore.kernel.org/r/20211019120927.3822792-1-u.kleine-koenig@pengutronix.de

backlight: Propagate errors from get_brightness()

2021-09-23T09:48:00+00:00

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 through sysfs although only
positive values are documented to be reported.

Signed-off-by: Thomas Weißschuh 
Reviewed-by: Daniel Thompson 
Signed-off-by: Lee Jones

video: backlight: Drop maximum brightness override for brightness zero

2021-09-22T07:32:48+00:00

The note in c2adda27d202f ("video: backlight: Add of_find_backlight helper
in backlight.c") says that gpio-backlight uses brightness as power state.
This has been fixed since in ec665b756e6f7 ("backlight: gpio-backlight:
Correct initial power state handling") and other backlight drivers do not
require this workaround. Drop the workaround.

This fixes the case where e.g. pwm-backlight can perfectly well be set to
brightness 0 on boot in DT, which without this patch leads to the display
brightness to be max instead of off.

Fixes: c2adda27d202f ("video: backlight: Add of_find_backlight helper in backlight.c")
Cc:  # 5.4+
Cc:  # 4.19.x: ec665b756e6f7: backlight: gpio-backlight: Correct initial power state handling
Signed-off-by: Marek Vasut 
Acked-by: Noralf Trønnes 
Reviewed-by: Daniel Thompson 
Signed-off-by: Lee Jones

backlight: pwm_bl: Improve bootloader/kernel device handover

2021-08-19T09:59:03+00:00

Currently there are (at least) two problems in the way pwm_bl starts
managing the enable_gpio pin. Both occur when the backlight is initially
off and the driver finds the pin not already in output mode and, as a
result, unconditionally switches it to output-mode and asserts the signal.

Problem 1: This could cause the backlight to flicker since, at this stage
in driver initialisation, we have no idea what the PWM and regulator are
doing (an unconfigured PWM could easily "rest" at 100% duty cycle).

Problem 2: This will cause us not to correctly honour the
post_pwm_on_delay (which also risks flickers).

Fix this by moving the code to configure the GPIO output mode until after
we have examines the handover state. That allows us to initialize
enable_gpio to off if the backlight is currently off and on if the
backlight is on.

Cc: stable@vger.kernel.org
Reported-by: Marek Vasut 
Signed-off-by: Daniel Thompson 
Acked-by: Marek Vasut 
Tested-by: Marek Vasut 
Signed-off-by: Lee Jones