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]
Message-ID: <3b02ab6f-56c7-a877-1b2f-01fc1fb8f552@linaro.org>
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

> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ