[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAL_JsqKgzQRo4rn5eL0MKz_df5N2JbZmOo_mmJ05UufK8fsx0g@mail.gmail.com>
Date: Mon, 3 Aug 2020 12:39:44 -0600
From: Rob Herring <robh@...nel.org>
To: Pavel Pisa <pisa@....felk.cvut.cz>
Cc: c.emde@...dl.org, devicetree@...r.kernel.org,
Marc Kleine-Budde <mkl@...gutronix.de>,
linux-can@...r.kernel.org, socketcan@...tkopp.net,
Wolfgang Grandegger <wg@...ndegger.com>,
David Miller <davem@...emloft.net>,
Mark Rutland <mark.rutland@....com>,
netdev <netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
martin.jerabek01@...il.com, ondrej.ille@...il.com,
jnovak@....cvut.cz, jara.beran@...il.com, porazil@...ron.com
Subject: Re: [PATCH v3 2/6] dt-bindings: net: can: binding for CTU CAN FD
open-source IP core.
On Sat, Aug 1, 2020 at 3:28 PM Pavel Pisa <pisa@....felk.cvut.cz> wrote:
>
> Hello Rob ad others,
>
> On Wednesday 29 of July 2020 01:12:31 Pavel Pisa wrote:
> > On Saturday 04 of January 2020 00:53:59 Rob Herring wrote:
> > > On Sat, Dec 21, 2019 at 03:07:31PM +0100, pisa@....felk.cvut.cz wrote:
> > > > From: Pavel Pisa <pisa@....felk.cvut.cz>
> > > >
> > > > Signed-off-by: Pavel Pisa <pisa@....felk.cvut.cz>
> > > > ---
> > > > .../devicetree/bindings/net/can/ctu,ctucanfd.txt | 61
> > > > ++++++++++++++++++++++ 1 file changed, 61 insertions(+)
> > > > create mode 100644
> > > > Documentation/devicetree/bindings/net/can/ctu,ctucanfd.txt
> > >
> > > Bindings are moving DT schema format now. Not something I'd require on a
> > > respin I've already reviewed, but OTOH it's been 10 months to respin
> > > from v2. So:
> > >
> > > Reviewed-by: Rob Herring <robh@...nel.org>
> > >
> > > If you have a v4, then please convert to a schema.
> >
>
> ...
>
> > I am trying to resolve that only one review feedback which I have received
> > before v4 patches sending. I have spent half day to update and integrate
> > self build packages to my stable Debian to can run
> >
> > make -k dt_binding_check
> >
> > but unfortunately, I have not achieved promissing result even when tested
> > on Linux kernel unpatched sources. I used actual git
> > dt-schema/dt-doc-validate with 5.4 kernel build but I get only long series
> > of
>
> I have succeed to run make dt_binding_check on stable Debian with 5.4
> kernel with only denumerable bunch of errors, probably normal one.
> Details to make dt_binding_check usable on stable Debian later.
>
> When invoked with base directory specified
>
> /usr/local/bin/dt-doc-validate -u /usr/src/linux-5.4/Documentation/devicetree/bindings/ net/can/ctu,ctucanfd.yaml
>
> then no problem is reported in ctu,ctucanfd.yaml .
> Please is the specification correct even after human check?
>
> > pi@...ee:/usr/src/linux-5.4-rt/_build/arm/px6$ make dt_binding_check -k
> > GNUmakefile:40: *** mixed implicit and normal rules: deprecated syntax
> > make -C /usr/src/linux-5.4-rt O=/usr/src/linux-5.4-rt/_build/arm/px6/
> > ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- QTDIR=/usr/share/qt4
> > dt_binding_check CHKDT Documentation/devicetree/bindings/arm/actions.yaml
> > /usr/src/linux-5.4-rt/Documentation/devicetree/bindings/arm/actions.yaml:
> > found incompatible YAML document in "<unicode string>", line 2, column 1
> > make[3]: ***
>
> The remark to save time of others, actual stable Debian Buster provides package
> python3-ruamel.yaml in 0.15.34-1+b1 version. But use of make dt_binding_check
> and dt-doc-validate and dt-validate with this version lead to many errors
> "found incompatible YAML document". The validation tools can be make
> to work when next packages are added and replaced in stable Debian
pip/setup.py should check the dependencies which includes
'ruamel.yaml>0.15.69'. Did you not use pip?
> python3-pyrsistent 0.15.5-1
> python3-pyfakefs 4.0.2-1
> python3-zipp 1.0.0-3
> python3-importlib-metadata 1.6.0
These must all be indirect dependencies as I have no idea what they provide.
> python3-jsonschema 3.2.0-3
> python3-ruamel.yaml.clib 0.2.0-3
> python3-ruamel.yaml 0.16.10-2
>
> The dependencies and interdependence of the tools are really wide and that
> the tools are unusable in the actual regular Debian stable distribution
> should be described somewhere visible enough to save developers
> time.
I can't document distro specifics for what I don't have. Manually
documenting dependencies and their versions seems like a recipe for
inaccurate and out of date documentation.
Rob
Powered by blists - more mailing lists