From: Marijn Suijten <marijn.suijten@somainline.org>
To: Daniel Thompson <daniel.thompson@linaro.org>
Cc: phone-devel@vger.kernel.org, Andy Gross <agross@kernel.org>,
Bjorn Andersson <bjorn.andersson@linaro.org>,
Lee Jones <lee.jones@linaro.org>,
Jingoo Han <jingoohan1@gmail.com>,
~postmarketos/upstreaming@lists.sr.ht,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@somainline.org>,
Konrad Dybcio <konrad.dybcio@somainline.org>,
Martin Botka <martin.botka@somainline.org>,
Jami Kettunen <jami.kettunen@somainline.org>,
Pavel Dubrova <pashadubrova@gmail.com>,
Kiran Gunda <kgunda@codeaurora.org>,
Courtney Cavin <courtney.cavin@sonymobile.com>,
Bryan Wu <cooloney@gmail.com>,
linux-arm-msm@vger.kernel.org, dri-devel@lists.freedesktop.org,
linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 05/10] backlight: qcom-wled: Fix off-by-one maximum with default num_strings
Date: Tue, 5 Oct 2021 17:23:26 +0200 [thread overview]
Message-ID: <20211005152326.5k5cb53ajqnactrg@SoMainline.org> (raw)
In-Reply-To: <20211005140349.kefi26yev3gy3zhv@maple.lan>
On 2021-10-05 15:03:49, Daniel Thompson wrote:
[..]
> > I much prefer doing that instead of trying to wrangle enumeration
> > parsing around integer values that are supposed to be used as-is. After
> > all this variable is already named to set the `+ 1` override currently,
> > and `qcom,enabled_strings` has "custom" handling as well. I'll extend
> > the validation to ensure num_strings>=1 too.
>
> Great.
>
>
> > In addition, and this needs some investigation on the dt-bindings side
> > too, it might be beneficial to make both properties mutually exclusive.
> > When specifying qcom,enabled_strings it makes little sense to also
> > provide qcom,num_strings and we want the former to take precedence.
>
> If we are designing a "fix" for that then my view is that if both are
> passed then num-strings should take precedence because it is an
> explicit statement about the number of strings where enabled_strings
> is implicit. In other words, if num-strings <= len(enabled_strings) then
> we should do what we are told, otherwise report error.
IMO both should be identical (num-strings == len(enabled-strings)) to
avoid ambiguity, but do read on.
> > At that point one might ask why qcom,num_strings remains at all when
> > DT can use qcom,enabled_strings instead. We will supposedly have to
> > keep backwards compatibility with DTs in mind so none of this can be
> > removed or made mutually exclusive from a driver standpoint, that all
> > has to be done in dt-bindings yaml to be enforced on checked-in DTs.
>
> So... perhaps I made a make offering a Reviewed-by: to a patch
> that allows len(enabled-strings) to have precedence. If anything
> currently uses enabled-strings then it *will* be 4 cells long and
> is relying on num-strings to ensure the right things happens ;-) .
Unfortunately Konrad (one of my team members) landed such a patch at the
beginning of this year because I failed to submit this patchset in time
while it has been sitting in my queue since 2019 after being used in a
downstream project. This is in pmi8994 which doesn't have anything
widely used / production ready yet, so I'd prefer to fix the DT instead
and remove / fix his comment:
/* Yes, all four strings *have to* be defined or things won't work. */
But this is mostly because, prior to this patchset, no default was set
for WLED4 so the 0'th string would get enabled num-strings (3 in
pmi8994's case) times.
Aside that there's only one more PMIC (also being worked on by
SoMainline) that sets qcom,enabled-strings: this is pm660l, pulled from
our local tree, and it actually has enabled-strings of length 2 which is
broken in its current form, exactly because of relying on this patchset.
Finally, we already discussed this inside SoMainline and the
number/enabled leds should most likely be moved out of the PMIC dtsi's
as they're probably panel, hence board or even device dependent.
> We'd like that case to keep working so we must allow num-strings to have
> precedence. In other words, when you add the new code, please put it at
> the end of the function!
Since there don't seem to be any substantial platforms/PMICs using this
functionality in a working manner, can I talk you into agreeing with
fixing the DT instead?
PS. In -next pmi8994_wled is only enabled for sony-xperia-tone, and
pm660l_wled has yet to be enabled by anything.
- Marijn
next prev parent reply other threads:[~2021-10-05 15:23 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-04 19:27 [PATCH 00/10] backlight: qcom-wled: fix and solidify handling of enabled-strings Marijn Suijten
2021-10-04 19:27 ` [PATCH 01/10] backlight: qcom-wled: Pass number of elements to read to read_u32_array Marijn Suijten
2021-10-05 9:05 ` Daniel Thompson
2021-10-04 19:27 ` [PATCH 02/10] backlight: qcom-wled: Use cpu_to_le16 macro to perform conversion Marijn Suijten
2021-10-05 9:06 ` Daniel Thompson
2021-10-04 19:27 ` [PATCH 03/10] backlight: qcom-wled: Override num-strings when enabled-strings is set Marijn Suijten
2021-10-05 9:38 ` Daniel Thompson
2021-10-04 19:27 ` [PATCH 04/10] backlight: qcom-wled: Validate enabled string indices in DT Marijn Suijten
2021-10-05 9:14 ` Daniel Thompson
2021-10-05 10:03 ` Marijn Suijten
2021-10-05 10:42 ` Daniel Thompson
2021-10-04 19:27 ` [PATCH 05/10] backlight: qcom-wled: Fix off-by-one maximum with default num_strings Marijn Suijten
2021-10-05 9:19 ` Daniel Thompson
2021-10-05 10:06 ` Marijn Suijten
2021-10-05 10:38 ` Daniel Thompson
2021-10-05 10:53 ` Daniel Thompson
2021-10-05 11:44 ` Marijn Suijten
2021-10-05 14:03 ` Daniel Thompson
2021-10-05 15:23 ` Marijn Suijten [this message]
2021-10-05 16:24 ` Daniel Thompson
2021-10-05 16:50 ` Konrad Dybcio
2021-10-05 17:34 ` Marijn Suijten
2021-10-06 14:44 ` Daniel Thompson
2021-10-07 21:28 ` Marijn Suijten
2021-10-04 19:27 ` [PATCH 06/10] backlight: qcom-wled: Remove unnecessary 4th default string in wled3 Marijn Suijten
2021-10-05 9:20 ` Daniel Thompson
2021-10-04 19:27 ` [PATCH 07/10] backlight: qcom-wled: Provide enabled_strings default for wled 4 and 5 Marijn Suijten
2021-10-05 9:21 ` Daniel Thompson
2021-10-04 19:27 ` [PATCH 08/10] backlight: qcom-wled: Remove unnecessary double whitespace Marijn Suijten
2021-10-05 9:21 ` Daniel Thompson
2021-10-04 19:27 ` [PATCH 09/10] backlight: qcom-wled: Consistently use enabled-strings in set_brightness Marijn Suijten
2021-10-05 9:33 ` Daniel Thompson
2021-10-05 10:12 ` Marijn Suijten
2021-10-04 19:27 ` [PATCH 10/10] backlight: qcom-wled: Consider enabled_strings in autodetection Marijn Suijten
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20211005152326.5k5cb53ajqnactrg@SoMainline.org \
--to=marijn.suijten@somainline.org \
--cc=agross@kernel.org \
--cc=angelogioacchino.delregno@somainline.org \
--cc=bjorn.andersson@linaro.org \
--cc=cooloney@gmail.com \
--cc=courtney.cavin@sonymobile.com \
--cc=daniel.thompson@linaro.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=jami.kettunen@somainline.org \
--cc=jingoohan1@gmail.com \
--cc=kgunda@codeaurora.org \
--cc=konrad.dybcio@somainline.org \
--cc=lee.jones@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.botka@somainline.org \
--cc=pashadubrova@gmail.com \
--cc=phone-devel@vger.kernel.org \
--cc=~postmarketos/upstreaming@lists.sr.ht \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).