lkml.org 
[lkml]   [2021]   [Nov]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RESEND PATCH v2 04/13] backlight: qcom-wled: Fix off-by-one maximum with default num_strings
On Fri, Nov 12, 2021 at 01:35:01PM +0100, Marijn Suijten wrote:
> On 2021-11-12 12:08:39, Daniel Thompson wrote:
> > On Fri, Nov 12, 2021 at 01:26:57AM +0100, Marijn Suijten wrote:
> > > + if (string_len > 0) {
> > > + dev_warn(dev, "qcom,num-strings and qcom,enabled-strings are ambiguous\n");
> >
> > The warning should also be below the error message on the next if statement.
>
> Agreed.
>
> > This warning occurs even when there is no ambiguity.
> >
> > This could be:
> >
> > if (string_len > 0 && val != string_len)
> >
> > Combined these changes allows us to give a much more helpful and assertive
> > warning message:
> >
> > qcom,num-strings mis-matches and will partially override
> > qcom,enabled-strings (remove qcom,num-strings?)
>
> I want to let the user know it's set regardless of whether they're
> equivalent; no need to set both.
>
> How about:
>
> Only one of qcom,num-strings or qcom,enabled-strings should be set
>
> That should be more descriptive? Otherwise, let me know if you really
> want to allow users to (unnecessarily) set both - or if it can / should
> be caught in DT validation instead.

Yes. I can live with that text. Let's use that.

Maybe I wouldn't if there gazilions of existing DTs with both
properties but IIRC the number is likely to be small or zero
(although we couldn't be 100% sure which).


Daniel.

\
 
 \ /
  Last update: 2021-11-12 14:20    [W:0.087 / U:0.128 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site