Re: [PATCH v4 2/4] dt-bindings: mfd: sprd: Add bindings for ums512 global registers

[Rob Herring]

On Fri, Oct 15, 2021 at 7:45 AM Lee Jones <lee.jones@xxxxxxxxxx> wrote:
>
> On Thu, 14 Oct 2021, Rob Herring wrote:
>
> > On Thu, Oct 14, 2021 at 1:48 AM Lee Jones <lee.jones@xxxxxxxxxx> wrote:
> > >
> > > On Wed, 13 Oct 2021, Geert Uytterhoeven wrote:
> > >
> > > > Hi Lee,
> > > >
> > > > On Tue, Oct 12, 2021 at 10:15 AM Lee Jones <lee.jones@xxxxxxxxxx> wrote:
> > > > > On Mon, 11 Oct 2021, Rob Herring wrote:
> > > > > > On Wed, Oct 6, 2021 at 3:00 AM Lee Jones <lee.jones@xxxxxxxxxx> wrote:
> > > > > > > On Thu, 23 Sep 2021, Chunyan Zhang wrote:
> > > > > > >
> > > > > > > > From: Chunyan Zhang <chunyan.zhang@xxxxxxxxxx>
> > > > > > > >
> > > > > > > > Add bindings for Unisoc system global register which provide register map
> > > > > > > > for clocks.
> > > > > > > >
> > > > > > > > Signed-off-by: Chunyan Zhang <chunyan.zhang@xxxxxxxxxx>
> > > > > > > > Reviewed-by: Rob Herring <robh@xxxxxxxxxx>
> > > > > > > > ---
> > > > > > > >  .../bindings/mfd/sprd,ums512-glbreg.yaml      | 68 +++++++++++++++++++
> > > > > > > >  1 file changed, 68 insertions(+)
> > > > > > > >  create mode 100644 Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.yaml
> > > > > > >
> > > > > > > Unapplied v3 and applied this (v4) instead, thanks.
> > > > > >
> > > > > > What about the clock binding this depends on:
> > > > > >
> > > > > > Unknown file referenced: [Errno 2] No such file or directory:
> > > > > > '/usr/local/lib/python3.8/dist-packages/dtschema/schemas/clock/sprd,ums512-clk.yaml'
> > > > > > xargs: dt-doc-validate: exited with status 255; aborting
> > > > > > make[1]: *** Deleting file
> > > > > > 'Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.example.dt.yaml'
> > > > > > Unknown file referenced: [Errno 2] No such file or directory:
> > > > > > '/usr/local/lib/python3.8/dist-packages/dtschema/schemas/clock/sprd,ums512-clk.yaml'
> > > > > > make[1]: *** [scripts/Makefile.lib:385:
> > > > > > Documentation/devicetree/bindings/mfd/sprd,ums512-glbreg.example.dt.yaml]
> > > > > > Error 255
> > > > > >
> > > > > >
> > > > > > Once again, all the components of MFD bindings need to be applied together.
> > > >
> > > > Just ran into this, too...
> > > >
> > > > > I can't apply what is not sent to me.
> > > > >
> > > > > This patch came in on its own.
> > > >
> > > > Then please reject/postpone patches that don't build (yet) ;-)
> > >
> > > I don't explicitly build DT documentation.
> > >
> > > Since I use the build bots to let me know if there are strange !(C,
> > > ASM, arm, aarch64, mips, ppc, x86) build issues or ones with odd
> > > configuration possibilities (randconfig) in the repos I maintain, you
> > > might have to convince them that this is important too.
> >
> > It's really just a matter of turning on the build in
> > allyesconfig/allmodconfig builds. I've not done that primarily because
> > there's one person I don't want to yell at me, but I could probably
> > make it arm and/or arm64 only. It's really arch and config
> > independent, so doing it multiple times is kind of pointless.
> >
> > I assume for bots you mean kernel-ci mainly? Do you run that before
> > stuff gets into linux-next? IMO, that's too late. But still a slight
> > improvement if things go in via one tree. Otherwise, I see the
> > breakage twice, 1st linux-next then the merge window.
>
> Kernel test robot <lkp@xxxxxxxxx> is the one that springs to mind.

It already does sometimes. I haven't figured out when, but I randomly
see some reports and doesn't report a lot of the cases.

> Although, I'm sure there are other, less prolific implementations.

Rob's bot, but that checks patches (not branches) and applies series
so you won't get errors unless the series is in the wrong patch order.

Rob