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

[Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx>]

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.

> 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...

Best regards,
Krzysztof