linux-kernel - Re: [PATCH 10/13] dt-bindings: spi: add bindings for microchip mpfs spi

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a2ce221d-5ab7-52c5-176e-e64a081a6805@microchip.com>
Date:   Tue, 9 Nov 2021 13:20:25 +0000
From:   <Conor.Dooley@...rochip.com>
To:     <krzysztof.kozlowski@...onical.com>, <robh@...nel.org>
CC:     <robh+dt@...nel.org>, <gregkh@...uxfoundation.org>,
        <linus.walleij@...aro.org>, <linux-riscv@...ts.infradead.org>,
        <aou@...s.berkeley.edu>, <paul.walmsley@...ive.com>,
        <linux-usb@...r.kernel.org>, <Daire.McNamara@...rochip.com>,
        <linux-spi@...r.kernel.org>, <geert@...ux-m68k.org>,
        <devicetree@...r.kernel.org>, <linux-rtc@...r.kernel.org>,
        <linux-gpio@...r.kernel.org>, <broonie@...nel.org>,
        <palmer@...belt.com>, <bgolaszewski@...libre.com>,
        <jassisinghbrar@...il.com>, <linux-crypto@...r.kernel.org>,
        <Ivan.Griffin@...rochip.com>, <atish.patra@....com>,
        <Lewis.Hanly@...rochip.com>, <bin.meng@...driver.com>,
        <alexandre.belloni@...tlin.com>, <linux-i2c@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <a.zummo@...ertech.it>
Subject: Re: [PATCH 10/13] dt-bindings: spi: add bindings for microchip mpfs
 spi

On 09/11/2021 13:04, Krzysztof Kozlowski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On 09/11/2021 13:58, Conor.Dooley@...rochip.com wrote:
>> On 09/11/2021 12:53, Krzysztof Kozlowski wrote:
>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>>
>>> On 09/11/2021 13:16, Conor.Dooley@...rochip.com wrote:
>>>> On 09/11/2021 04:06, Rob Herring wrote:
>>>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>>>>
>>>>> On Mon, 08 Nov 2021 15:05:51 +0000, conor.dooley@...rochip.com wrote:
>>>>>> From: Conor Dooley <conor.dooley@...rochip.com>
>>>>>>
>>>>>> Add device tree bindings for the {q,}spi controller on
>>>>>> the Microchip PolarFire SoC.
>>>>>>
>>>>>> Signed-off-by: Conor Dooley <conor.dooley@...rochip.com>
>>>>>> ---
>>>>>>     .../bindings/spi/microchip,mpfs-spi.yaml      | 72 +++++++++++++++++++
>>>>>>     1 file changed, 72 insertions(+)
>>>>>>     create mode 100644 Documentation/devicetree/bindings/spi/microchip,mpfs-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:
>>>>> Documentation/devicetree/bindings/spi/microchip,mpfs-spi.example.dts:19:18: fatal error: dt-bindings/clock/microchip,mpfs-clock.h: No such file or directory
>>>>>       19 |         #include "dt-bindings/clock/microchip,mpfs-clock.h"
>>>> Rob,
>>>> Should I drop the header from the example or is there a way for me
>>>> specify the dependent patch to pass this check?
>>>
>>> The error has to be fixed, although not necessarily by dropping the
>>> header, but by posting it. How this can pass on your system? There is no
>>> such file added in this patchset.
>> I linked the patch adding the clock as a dependency in the cover letter
>> [1], which is why I was wondering if there was a better way to do so
>> that would get picked up by the checker bot.
> 
> It's not only about the bot, but dependency when applied. If you did not
> warn clk maintainer that clock bindings should go via Rob's tree or
> should be provided as a tag, the patches here cannot be applied in this
> cycle.
It was not my (our) intention to send the clock patches via rob's tree.
And since this is my first time trying to upstream wholescale changes to 
a device tree I honestly didn't expect this series to get accepted in 
this cycle anyway.
> 
> Best regards,
> Krzysztof
>