linux-kernel - Re: [PATCH v8 01/11] dt-bindings: clock: meson: add A1 PLL clock controller bindings

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Fri, 2 Dec 2022 14:36:11 +0100
From:   neil.armstrong@...aro.org
To:     Dmitry Rokosov <ddrokosov@...rdevices.ru>,
        Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc:     Jerome Brunet <jbrunet@...libre.com>,
        Rob Herring <robh@...nel.org>, devicetree@...r.kernel.org,
        sboyd@...nel.org, khilman@...libre.com, kernel@...rdevices.ru,
        robh+dt@...nel.org, martin.blumenstingl@...glemail.com,
        linux-arm-kernel@...ts.infradead.org, jian.hu@...ogic.com,
        linux-kernel@...r.kernel.org, krzysztof.kozlowski+dt@...aro.org,
        linux-amlogic@...ts.infradead.org, rockosov@...il.com,
        mturquette@...libre.com, linux-clk@...r.kernel.org
Subject: Re: [PATCH v8 01/11] dt-bindings: clock: meson: add A1 PLL clock
 controller bindings

On 02/12/2022 12:28, Dmitry Rokosov wrote:
>>>>>> On Fri, 02 Dec 2022 01:56:53 +0300, Dmitry Rokosov wrote:
>>>>>>> From: Jian Hu <jian.hu@...ogic.com>
>>>>>>>
>>>>>>> Add the documentation to support Amlogic A1 PLL clock driver,
>>>>>>> and add A1 PLL clock controller bindings.
>>>>>>>
>>>>>>> Signed-off-by: Jian Hu <jian.hu@...ogic.com>
>>>>>>> Signed-off-by: Dmitry Rokosov <ddrokosov@...rdevices.ru>
>>>>>>> ---
>>>>>>>   .../bindings/clock/amlogic,a1-pll-clkc.yaml   | 52 +++++++++++++++++++
>>>>>>>   include/dt-bindings/clock/a1-pll-clkc.h       | 16 ++++++
>>>>>>>   2 files changed, 68 insertions(+)
>>>>>>>   create mode 100644 Documentation/devicetree/bindings/clock/amlogic,a1-pll-clkc.yaml
>>>>>>>   create mode 100644 include/dt-bindings/clock/a1-pll-clkc.h
>>>>>>>
>>>>>>
>>>>>> 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:
>>>>>> ./Documentation/devicetree/bindings/clock/amlogic,a1-pll-clkc.yaml:26:6: [warning] wrong indentation: expected 6 but found 5 (indentation)
>>>>>>
>>>>>> dtschema/dtc warnings/errors:
>>>>>> ./Documentation/devicetree/bindings/clock/amlogic,a1-pll-clkc.yaml: $id: relative path/filename doesn't match actual path or filename
> 
> ...
> 
>>>>>
>>>>> Please find all fixes of above warnings and errors in the my patch
>>>>> located at the link:
>>>>>
>>>>> https://lore.kernel.org/linux-amlogic/20221201225703.6507-9-ddrokosov@sberdevices.ru/
>>>>
>>>> Why? This patch here is broken and it should be fixed. Don't apply
>>>> broken patches...
>>>
>>> Dmitry is ressurecting a series that is several years old and not his to
>>> begin with.
>>>
>>> He was unsure about take the code of somebody else.
>>> To be fair, he even asked for advice on IRC about to proceed.
>>>
>>> Dmitry, as you may have guessed, for next revision, please fix Jian Hu
>>> original patches in place, not with fixup patches.
>>>
>>> If your fixes are minor (not complete rewrite), please keep the original
>>> author and add your SoB
>>
>> We never take intentionally wrong patches, e.g. code which does not even
>> compile, and immediately fix it in next patch.
>>
>> Can you imagine adding such drivers? Which are broken in the commit they
>> are added?
>>
>> So the patchset is old or abandoned, take ownership, add co-developed
>> etc. Just don't add known broken code.
> 
> Okay, I've got your point. It's reasonable.
> I will fix Jian Hu's patches (squash with mine) and mark all of them
> with co-developed and SoB Jian Hu tags. Thank you for explanation.

It was clearly explained in the cover-letter, nobody expected these patches
to be applied as-is.

Using RFC would have been the best solution, but this situation is rather
specific and he made the right decisions to trigger this current discussion
toward an acceptable solution for everybody.

Neil

>