Re: [PATCH v4 1/2] dt-bindings: spi: add loongson spi

[zhuyinbo]

在 2023/3/29 下午7:37, Krzysztof Kozlowski 写道:
> On 29/03/2023 12:39, zhuyinbo wrote:
> > 在 2023/3/28 下午8:57, Rob Herring 写道:
> > > On Tue, 28 Mar 2023 19:22:09 +0800, Yinbo Zhu wrote:
> > > > Add the Loongson platform spi binding with DT schema format using
> > > > json-schema.
> > > >
> > > > Signed-off-by: Yinbo Zhu <zhuyinbo@xxxxxxxxxxx>
> > > > ---
> > > >    .../bindings/spi/loongson,ls-spi.yaml         | 43 +++++++++++++++++++
> > > >    MAINTAINERS                                   |  6 +++
> > > >    2 files changed, 49 insertions(+)
> > > >    create mode 100644 Documentation/devicetree/bindings/spi/loongson,ls-spi.yaml
> > >
> > > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
> > > on your patch (DT_CHECKER_FLAGS is new in v5.13):
> > >
> > > yamllint warnings/errors:
> > >
> > > dtschema/dtc warnings/errors:
> > > Error: Documentation/devicetree/bindings/spi/loongson,ls-spi.example.dts:22.28-29 syntax error
> > > FATAL ERROR: Unable to parse input tree
> > > make[1]: *** [scripts/Makefile.lib:419: Documentation/devicetree/bindings/spi/loongson,ls-spi.example.dtb] Error 1
> > > make[1]: *** Waiting for unfinished jobs....
> > > make: *** [Makefile:1512: dt_binding_check] Error 2
> > >
> > > doc reference errors (make refcheckdocs):
> > >
> > > See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20230328112210.23089-2-zhuyinbo@xxxxxxxxxxx
> > >
> > > The base for the series is generally the latest rc1. A different dependency
> > > should be noted in *this* patch.
> > Hi Rob,
> >
> > I'm sorry, actually, I don't know what the specific operation I should
> > do when I received the check warning
> > from your bot. Does it means that I should add dependency note into this
> > patch's changelog ?
>
> Yes, this is explicitly mentioned in the sentence you quoted.
okay, I got it, thanks!
> > or something else, I really
> > don't know. Actually, I'm always bothered by these things that how to
> > resolve the dependency issue for two
> > dependent patches that do not belong to the same series.
>
> Another approach, as Rob suggested last time, would be to just get rid
> of the dependency and open-code the clock IDs...
Thank you very much for your suggestion,  I will open-code the clock
IDs and fix that checkpatch issue then resend this series patch.
> Best regards,
> Krzysztof