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: <2bcd2718-9ae5-4475-86a3-93fce973d047@kernel.org>
Date: Fri, 7 Mar 2025 08:07:42 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Uwe Kleine-König <ukleinek@...nel.org>
Cc: Abel Vesa <abel.vesa@...aro.org>, Lee Jones <lee@...nel.org>,
 Pavel Machek <pavel@...nel.org>,
 Anjelique Melendez <anjelique.melendez@....qualcomm.com>,
 Kamal Wadhwa <quic_kamalw@...cinc.com>,
 Jishnu Prakash <jishnu.prakash@....qualcomm.com>,
 Bjorn Andersson <andersson@...nel.org>,
 Konrad Dybcio <konradybcio@...nel.org>, Johan Hovold <johan@...nel.org>,
 Sebastian Reichel <sre@...nel.org>, Pavel Machek <pavel@....cz>,
 linux-leds@...r.kernel.org, linux-pwm@...r.kernel.org,
 linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC] leds: rgb: leds-qcom-lpg: Compute PWM value based on
 period instead

On 07/03/2025 00:33, Uwe Kleine-König wrote:
> Hello Krzysztof,
> 
> On Tue, Mar 04, 2025 at 05:30:40PM +0100, Krzysztof Kozlowski wrote:
>> On 04/03/2025 17:03, Uwe Kleine-König wrote:
>>> On Tue, Mar 04, 2025 at 10:53:53AM +0100, Krzysztof Kozlowski wrote:
>>>> On 04/03/2025 07:24, Uwe Kleine-König wrote:
>>>>>> [...]
>>>>>> ---
>>>>>> base-commit: 0067a4b21c9ab441bbe6bf3635b3ddd21f6ca7c3
>>>>>
>>>>> My git repo doesn't know that commit. Given that you said your patch
>>>>> bases on that other series, this isn't surprising. Please use a publicly
>>>>> available commit as base parameter, otherwise you (and I) don't benefit
>>>>> from the armada of build bots because they just silently fail to test in
>>>>
>>>> As you can easily see in the signature, this patchset was generated by
>>>> b4 and such tag was added automatically. No point in stripping it even
>>>> if it is not useful (life, happens).
>>>
>>> My request was not about stripping it, but making it useful. I don't
>>> know the b4 patch sending side, but git send-email has the capability to
>>> make it more useful in this scenario. I didn't check, but
>>> `b4 --edit-deps` which Abel mentioned sounds about right.
>>>
>>> The relevant documentation for the git side is the paragraph "BASE TREE
>>> INFORMATION" in git-format-patch(1).
>>
>> Useful how? The dependency is on the lists, so there is no base-commit
>> you would know.
> 
> Have you tried to understand the part of the manpage I pointed out? It
> seems to me "base-commit" has different semantics for us and only mine
> is aligned to git's (and consequently b4's) meaning.
> The correct base commit would have been
> cd3215bbcb9d4321def93fea6cfad4d5b42b9d1d.
> 
>> And regardless of edit-deps, that base-commit tag is standard from b4,
>> so what do you expect from all submitters even if this was not RFC?
> 
> I don't understand this question. I expect from submitters to pick a
> publicly known commit as base no matter if the series is an RFC or who's
> standard this is.
> 
>> Always base on known commit?
> 
> Yes please. The manpage isn't explicit about that but the above
> referenced commit has:
> 
>     The base tree info consists of the "base commit", which is a well-known
>     commit that is part of the stable part of the project history everybody
>     else works off of, and zero or more "prerequisite patches", which are
>     well-known patches in flight that is not yet part of the "base commit"
>     that need to be applied on top of "base commit" in topological order
>     before the patches can be applied.
> 
>> But for most of the cases this is
>> irrelevant. I can have intermediate commit between linux-next tip and my
>> patch, thus base-commit will be bogus for you, but it does not matter
>> for the patch - it's based on linux-next.
> 
> I agree, linux-next is the base. So the respective tip of linux-next is
> the right thing to pass to git format-patch --base (independent of if
> it's called directly or through b4). Ideally you also drop the
> irrelevant intermediate patches to make the build bots test exactly the
> changes you suggest with your series. I would expect that this is the
> tree you actually tested, so it shouldn't be a big hurdle.
> 
> So summarizing we have: Iff you use --base with a non-public commit, it's

Which is easily visible that it was not the case here. No human used
format-patch thus no human used --base.

> useless and irrelevant. I fully agree. Our conclusion is different
> though. You accept it's useless (and even request from me that I do the
> same), and I asked the submitter to use --base as intended to make the
> resulting information usable.

Because you expect additional steps for users of b4 and pointing in
review standard use of b4 is extremely nitpicking.

Best regards,
Krzysztof

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ