Re: [PATCH v3 0/9] backlight: qcom-wled: fix and solidify handling of enabled-strings
On Wed, 22 Dec 2021, Marijn Suijten wrote: > On 2021-11-16 15:42:15, Lee Jones wrote: > > On Tue, 16 Nov 2021, Daniel Thompson wrote: > > > > > Hi Lee > > > > > > On Mon, Nov 15, 2021 at 09:34:50PM +0100, Marijn Suijten wrote: > > > > This patchset fixes WLED's handling of enabled-strings: besides some > > > > cleanup it is now actually possible to specify a non-contiguous array of > > > > enabled strings (not necessarily starting at zero) and the values from > > > > DT are now validated to prevent possible unexpected out-of-bounds > > > > register and array element accesses. > > > > Off-by-one mistakes in the maximum number of strings, also causing > > > > out-of-bounds access, have been addressed as well. > > > > > > They have arrived piecemeal (during v1, v2 and v3) but all patches on > > > the set should now have my R-b: attached to them. > > > > I can see that. Nothing for you to worry about. > > > > I'll apply these when I conduct my next sweep, thanks. > > Thanks for that Lee! Has the next sweep already passed by? Seems > everyone is preparing for the 5.17 merge window but these patches > haven't yet landed on the backlight tree [1]. I'd appreciate it if we > can make them appear in the 5.17 window :) No need to panic. v5.17-rc1 isn't due to be cut for either 3.5 or 4.5 weeks. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v3 0/9] backlight: qcom-wled: fix and solidify handling of enabled-strings
On 2021-11-16 15:42:15, Lee Jones wrote: > On Tue, 16 Nov 2021, Daniel Thompson wrote: > > > Hi Lee > > > > On Mon, Nov 15, 2021 at 09:34:50PM +0100, Marijn Suijten wrote: > > > This patchset fixes WLED's handling of enabled-strings: besides some > > > cleanup it is now actually possible to specify a non-contiguous array of > > > enabled strings (not necessarily starting at zero) and the values from > > > DT are now validated to prevent possible unexpected out-of-bounds > > > register and array element accesses. > > > Off-by-one mistakes in the maximum number of strings, also causing > > > out-of-bounds access, have been addressed as well. > > > > They have arrived piecemeal (during v1, v2 and v3) but all patches on > > the set should now have my R-b: attached to them. > > I can see that. Nothing for you to worry about. > > I'll apply these when I conduct my next sweep, thanks. Thanks for that Lee! Has the next sweep already passed by? Seems everyone is preparing for the 5.17 merge window but these patches haven't yet landed on the backlight tree [1]. I'd appreciate it if we can make them appear in the 5.17 window :) [1]: https://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight.git/ Thanks! - Marijn > -- > Lee Jones [李琼斯] > Senior Technical Lead - Developer Services > Linaro.org │ Open source software for Arm SoCs > Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v3 0/9] backlight: qcom-wled: fix and solidify handling of enabled-strings
On Tue, 16 Nov 2021, Daniel Thompson wrote: > Hi Lee > > On Mon, Nov 15, 2021 at 09:34:50PM +0100, Marijn Suijten wrote: > > This patchset fixes WLED's handling of enabled-strings: besides some > > cleanup it is now actually possible to specify a non-contiguous array of > > enabled strings (not necessarily starting at zero) and the values from > > DT are now validated to prevent possible unexpected out-of-bounds > > register and array element accesses. > > Off-by-one mistakes in the maximum number of strings, also causing > > out-of-bounds access, have been addressed as well. > > They have arrived piecemeal (during v1, v2 and v3) but all patches on > the set should now have my R-b: attached to them. I can see that. Nothing for you to worry about. I'll apply these when I conduct my next sweep, thanks. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v3 0/9] backlight: qcom-wled: fix and solidify handling of enabled-strings
Hi Lee On Mon, Nov 15, 2021 at 09:34:50PM +0100, Marijn Suijten wrote: > This patchset fixes WLED's handling of enabled-strings: besides some > cleanup it is now actually possible to specify a non-contiguous array of > enabled strings (not necessarily starting at zero) and the values from > DT are now validated to prevent possible unexpected out-of-bounds > register and array element accesses. > Off-by-one mistakes in the maximum number of strings, also causing > out-of-bounds access, have been addressed as well. They have arrived piecemeal (during v1, v2 and v3) but all patches on the set should now have my R-b: attached to them. Daniel.
[PATCH v3 0/9] backlight: qcom-wled: fix and solidify handling of enabled-strings
This patchset fixes WLED's handling of enabled-strings: besides some cleanup it is now actually possible to specify a non-contiguous array of enabled strings (not necessarily starting at zero) and the values from DT are now validated to prevent possible unexpected out-of-bounds register and array element accesses. Off-by-one mistakes in the maximum number of strings, also causing out-of-bounds access, have been addressed as well. Changes in v3: - Use __le16 type for cpu_to_le16 result; - Reword ambiguity warning between qcom,num-strings and qcom,enabled-strings to explain that only one should/needs to be set; - Move this warning from patch 4 patch 5, where the length of qcom,enabled-strings starts to be taken into account; - Drop DT patches that have been picked up in the qcom tree. v2: https://lore.kernel.org/lkml/2022002706.453289-1-marijn.suij...@somainline.org/T Changes in v2: - Reordered patch 4/10 (Validate enabled string indices in DT) to sit before patch 1/10 (Pass number of elements to read to read_u32_array); - Pulled qcom,num-strings out of the DT enumeration parser, and moved it after qcom,enabled-strings parser to always have final sign-off over the number of strings; - Extra validation for this number of strings against qcom,enabled-strings; - Recombined patch 9 (Consistently use enabled-strings in set_brightness) and patch 10 (Consider enabled_strings in autodetection), which both solve the same problem in two different functions. In addition the autodetection code uses set_brightness as helper already; - Improved DT configurations for pmi8994 and pm660l, currently in 5.15 rc's. v1: https://lore.kernel.org/dri-devel/20211004192741.621870-1-marijn.suij...@somainline.org/T Marijn Suijten (9): backlight: qcom-wled: Validate enabled string indices in DT backlight: qcom-wled: Pass number of elements to read to read_u32_array backlight: qcom-wled: Use cpu_to_le16 macro to perform conversion backlight: qcom-wled: Fix off-by-one maximum with default num_strings backlight: qcom-wled: Override default length with qcom,enabled-strings backlight: qcom-wled: Remove unnecessary 4th default string in WLED3 backlight: qcom-wled: Provide enabled_strings default for WLED 4 and 5 backlight: qcom-wled: Remove unnecessary double whitespace backlight: qcom-wled: Respect enabled-strings in set_brightness drivers/video/backlight/qcom-wled.c | 130 +++- 1 file changed, 72 insertions(+), 58 deletions(-) base-commit: fa55b7dcdc43c1aa1ba12bca9d2dd4318c2a0dbf -- 2.33.1