Thread (15 messages) 15 messages, 3 authors, 2021-03-10

Re: [PATCH v3 05/15] dt_bindings: mfd: Add ROHM BD71815 PMIC

From: Matti Vaittinen <hidden>
Date: 2021-03-10 06:31:50
Also in: lkml

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
[off-list ref] wrote:
quoted
Hello Rob,

On Mon, 2021-03-08 at 10:39 -0700, Rob Herring wrote:
quoted
On Mon, 08 Mar 2021 12:40:50 +0200, Matti Vaittinen wrote:
quoted
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
quoted
*** 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 :]
quoted
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.


Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help