Message-ID: <dffaa91e826647723de9c7ada1de6bd9b51365c9.camel@fi.rohmeurope.com>
Date:   Wed, 10 Mar 2021 08:30:57 +0200
From:   Matti Vaittinen <matti.vaittinen@...rohmeurope.com>
To:     Rob Herring <robh@...nel.org>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        devicetree <devicetree@...r.kernel.org>
Subject: Re: [PATCH v3 05/15] dt_bindings: mfd: Add ROHM BD71815 PMIC

Hello Rob,

(I dropped other personal mails from CC - kept only the lists)

On Tue, 2021-03-09 at 08:11 -0700, Rob Herring wrote:
> On Tue, Mar 9, 2021 at 5:51 AM Matti Vaittinen
> <matti.vaittinen@...rohmeurope.com> wrote:
> > Hello Rob,
> > 
> > On Mon, 2021-03-08 at 10:39 -0700, Rob Herring wrote:
> > > On Mon, 08 Mar 2021 12:40:50 +0200, Matti Vaittinen wrote:
> > > > 
> > > dtschema/dtc warnings/errors:
> > > Unknown file referenced: [Errno 2] No such file or directory:
> > > '/usr/local/lib/python3.8/dist-
> > > packages/dtschema/schemas/regulator/rohm,bd71815-regulator.yaml'
> > 
> > This bothers me slightly. The patch 04/15 should bring-in the
> > rohm,bd71815-regulator.yaml. Does this error indicate that file is
> > missing or is my $ref somehow invalid?
> 
> Then it's simply a false positive. I usually check these and try to
> only send the email if the dependency is not in the series so the
> dependency is clear. It's a balance of replying quickly and my time
> reviewing the errors.

Oh, good to know. I was assuming I got it wrong once again... Thanks!

Rest of the mail is further discussion why I wonder if yaml bindings
are worth it - you can skip it if you're not in a mood for babbling ;)

Best Regards
	Matti

> > *** opinion follows - not sure if it just me but... ***
> > 
> > I know I should probably keep my mouth shut but... I am more and
> > more
> > thinking that the yaml bindings are yet another 'excessive unit-
> > test'
> > type solution. Tooling which should "force doing things correctly"
> > is
> > eventually hindering development and causing the end result being
> > sub-
> > optimal.
> 
> It's about validating DTS files actually do what the bindings say.
> It's pretty clear that the free form text bindings left a lot of
> things ambiguous.
> 
> How would you propose we can check every property in a DTS file has a
> definition (minimally of it's type)? Freeform text can simply never
> do
> that.

True. But I am not at all sure that the benefit of verifying the .dts
files programmatically exceeds cost (work + lost readability for humans
+ impact of increased "not that fun" work). Anyways, as I wrote - this
is just my biased opinion. Other people may have different opinions :]

> > I mean that creating binding docs takes way too much time from
> > someone
> > like me who is "yaml-illiterate". And when I eventually get yaml
> > done -
> > the end result is far less descriptive for human eyes than the
> > "good
> > old" free-text format would've been. I know one can add comments -
> > but
> > I don't see much of them in the binding docs...
> 
> Because people do the minimum?

I know. This is the very basic nature of most human beings. I think
this must be accepted. And likelihood for doing bare minimum sky-
rockets when people feel the work they do is dull/boring/not fun. And I
just have a feeling that many who enjoy writing drivers find writing
the yaml bindings quite not fun. (I have absolutely no statistics to
back up this statement - it's just a feeling).

Big question is how to get best results in this not-so-perfect world
when we know that people are both lazy and make mistakes?

I have kind of deja-vu here. I've seen many attempts of tightening
mechanical checks to get rid of human errors. In my opinion it rarely
works well. To pick few I've seen:

- demand for 100 % UT test coverage.
	=> lazy people started to avoid code changes
	=> autogenerated test cases which assumed current code was
	   correct and brought no value but incredible inertia to all 
	   changes.
- demand for heavy(ish) RCA/EDA process when severe faults were fixed
	=> lazy people started to mark severe faults as minor
- demand for peculiar, hard to remember syntax for commit messages to
automatically fill in different statistics/management data
	=> lazy people started to commit all changes in same category
	   (syntax they had memorized/had alias for).
- demand for DT docs which can be verified
	=> ... ?

Common thing is that all of these have valid, good intention - but
overhead of doing them exceeded the (visible) benefits and lazy people
tried to get around of them / did bare minimum. And as a side impact -
part of the work got more boring - which also has (bad) consequences.

I am not surprized if people try skipping creating DT docs. Or if the
people do bare minimum with the DT docs.

>  The only comments/description I object
> to are duplicating generic descriptions of common properties.

I know. And I don't think you are to blame here.

> There's certainly lots of things we could do. There are tools which
> generate pretty docs out of json-schema. Not sure how useful they
> would be OOTB. But I simply don't have the bandwidth to look into
> them. I can barely keep up with reviews...

Yes. I understand this. And now I am just taking more of that time -
sorry. I just gave an opinion (knowing it probably won't change
anything - but at least I've told what I am afraid of).

Thanks for the open discussion :) I appreciate it. And I do really
admire the amount of effort you (have) put in this! I do also admire
your skills here. And I absolutely respect your opinions what comes to
how the DT should look like. I just see the usefulness of the bindings
verification differently. I hope you don't find this as a personal
attack.

Powered by blists - more mailing lists