lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 30 Oct 2019 08:26:50 +0000
From:   "Vaittinen, Matti" <Matti.Vaittinen@...rohmeurope.com>
To:     "robh@...nel.org" <robh@...nel.org>
CC:     "dmurphy@...com" <dmurphy@...com>,
        "linux-leds@...r.kernel.org" <linux-leds@...r.kernel.org>,
        "linux-rtc@...r.kernel.org" <linux-rtc@...r.kernel.org>,
        "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "alexandre.belloni@...tlin.com" <alexandre.belloni@...tlin.com>,
        "mazziesaccount@...il.com" <mazziesaccount@...il.com>,
        "mturquette@...libre.com" <mturquette@...libre.com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "jacek.anaszewski@...il.com" <jacek.anaszewski@...il.com>,
        "linus.walleij@...aro.org" <linus.walleij@...aro.org>,
        "a.zummo@...ertech.it" <a.zummo@...ertech.it>,
        "lgirdwood@...il.com" <lgirdwood@...il.com>,
        "mark.rutland@....com" <mark.rutland@....com>,
        "bgolaszewski@...libre.com" <bgolaszewski@...libre.com>,
        "linux-clk@...r.kernel.org" <linux-clk@...r.kernel.org>,
        "sboyd@...nel.org" <sboyd@...nel.org>,
        "pavel@....cz" <pavel@....cz>,
        "broonie@...nel.org" <broonie@...nel.org>,
        "lee.jones@...aro.org" <lee.jones@...aro.org>
Subject: Re: [RFC PATCH v2 02/13] dt-bindings: mfd: Document ROHM BD71828
 bindings


On Tue, 2019-10-29 at 14:34 -0500, Rob Herring wrote:
> On Fri, Oct 25, 2019 at 05:49:17AM +0000, Vaittinen, Matti wrote:
> > Hello Dan,
> > 
> > Thanks again for checking this :)
> > 
> > On Thu, 2019-10-24 at 14:35 -0500, Dan Murphy wrote:
> > > Matti
> > > 
> > > On 10/24/19 6:41 AM, Matti Vaittinen wrote:
> > > > ROHM BD71828 Power management IC integrates 7 buck converters,
> > > > 7
> > > > LDOs,
> > > > a real-time clock (RTC), 3 GPO/regulator control pins, HALL
> > > > input
> > > > and a 32.768 kHz clock gate.
> > > > 
> > > > Document the dt bindings drivers are using.
> > > > 
> > > > Signed-off-by: Matti Vaittinen <
> > > > matti.vaittinen@...rohmeurope.com>
> > > > ---
> > > > 
> > > > No changes since v1
> > > > 
> > > >   .../bindings/mfd/rohm,bd71828-pmic.txt        | 180
> > > > ++++++++++++++++++
> > > >   1 file changed, 180 insertions(+)
> > > >   create mode 100644
> > > > Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.txt
> > > 
> > > I will let maintainers weigh in here but if this is new this
> > > should 
> > > probably be in the yaml format to avoid conversion in the future
> > 
> > Oh... This is new to me. I guess there are reasons for this - but I
> > must say I am not excited as I have never used yaml for anything.
> > I'll
> > do as you suggest and wait for what others have to say :) Thanks
> > for
> > pointing this out though.
> 
> Sorry for your lack of excitement. It could be XML...

Thanks, I appreciate that, apology accepted X-D

> There aren't many MFD examples yet, but there is max77650 in my tree
> and 
> linux-next.

I looked at the max77650 MFD binding from linux-next. After that I also
looked some of the generic documents for DT bindings (I know - I should
have done that earlier and your job had been easier). But all that left
me "slightly" puzzled. After some further wandering in the virtual
world I spotted this:
https://elinux.org/images/6/6b/LPC2018_json-schema_for_Devicetree.pdf

I think this link in some dt-yaml-binding-readme might be helpful.

So if I understand this correctly, idea is to convert the dts sources
to use yaml (right?). This is seen better because more people know
JSON/YAML than dts format(?) Fair enough. Although some of us know dts
format decently well but have never used JSON or yaml. I guess dts
support is not going away though and yaml examples do not seem terribly
hard at first sight.

What comes to binding docs - well, in my eyes (which may be biased)
writing documentation in anything intended to be interpreted by a
machine is still a step backwards for a human document reader. Sure
syntax validation or reviewing is easier if format is machine readable
- but free text info is more, well, informative (form me at least). I
for example wouldn't like reading a book written in any script or
markup language. Nor writing one. It is difficult for me to understand
the documentation change to yaml, maybe because I am more often using
the binding docs for composing DT for a device than reviewing them ;)

Anyways, I guess I'd better either try learning the yaml, figure out
what are schemas and see how to convert yaml docs to text for nicer
reading (I assume this is doable) and how to verify yaml binding docs
are Ok - or quit contributing. No one is forcing me to do this.
Continuing complaining on this is probably not getting us anywhere so I
might as well shut up now :/

And Sorry Rob. I am seeing you have been really close to this yaml/JSON
change so my wondering may be frustrating. I don't intend to be
disrespectful - I see that you have done huge work with this. I am
just... ...Slightly set in my ways. Little bit pig-headed and somewhat
a smart-arse - so I couldn't just let it go without giving out an
opinion.

> > > i2c {
> > > 
> > >          pmic@4b {
> > > 
> > >                  [...]
> > > 
> > >          };
> > > 
> > > };
> > 
> > I don't think the I2C node is needed in example. It is not part of
> > the
> > PMIC - and I don't see the containing bus in other examples I just
> > opened. (the two other rohm,xxx PMIC docs - well, biased as I wrote
> > them), da9150.txt, lp3943.txt, max77686.txt, tps6507x.txt,
> > tps65910.txt
> 
> It will be needed for the schema because the examples are compiled
> and 
> validated.

Thanks for explaining the reason.

Br,
	Matti Vaittinen

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ