[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e1fed734-8629-5bf2-60ba-ee62243def6f@linaro.org>
Date: Wed, 6 Jul 2022 22:09:05 +0200
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Christian Marangi <ansuelsmth@...il.com>
Cc: Bjorn Andersson <bjorn.andersson@...aro.org>,
Andy Gross <agross@...nel.org>,
Konrad Dybcio <konrad.dybcio@...ainline.org>,
Michael Turquette <mturquette@...libre.com>,
Stephen Boyd <sboyd@...nel.org>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
linux-arm-msm@...r.kernel.org, linux-clk@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/5] ARM: DTS: qcom: fix dtbs_check warning with new rpmcc
clocks
On 06/07/2022 21:10, Christian Marangi wrote:
> On Wed, Jul 06, 2022 at 05:07:12PM +0200, Krzysztof Kozlowski wrote:
>> On 06/07/2022 12:20, Christian Marangi wrote:
>>> On Wed, Jul 06, 2022 at 09:44:04AM +0200, Krzysztof Kozlowski wrote:
>>>> On 05/07/2022 22:28, Christian Marangi wrote:
>>>>> Fix dtbs_check warning for new rpmcc Documentation changes and add the
>>>>> required clocks.
>>>>
>>>> There is no warning in the kernel, right? So the commit is not correct.
>>>>
>>>
>>> Oh ok, the warning is generated by the new Documentation.
>>
>> Patches, especially DTS, might go via different trees, so the moment DTS
>> is applied there might be no such warning.
>>
>
> I'm still confused about this topic...
> With this kind of change, I notice I sent Documentation change and then
> rob bot complain about dtbs_check having warning...
>
> So the correct way is to send Documentation change and fix dtbs_check
> warning in the same commit OR keep what I'm doing with sending
> Documentation changes and fix DTS in a separate commit?
Binding is almost always separate from DTS and always separate from
driver. The order depends on what you're doing. If you bring ABI break
change to bindings, then the order does not matter, because each order
will be non-bisectable. Because you broke ABI. That's the case in this
patchset.
For other cases, usually bindings patches should be the first in patchset.
How it goes via maintainer trees is not your problem here. Patches might
go together or might go separate.
Anyway it was not the topic of my comment. Comment was about not
specific commit msg which does not fit the Linux kernel process and does
not fit git history once applied by maintainer. It fits even less when
backported to stable kernels, which you commit msg encourages to do.
Best regards,
Krzysztof
Powered by blists - more mailing lists