Re: [PATCH RFC] leds: rgb: leds-qcom-lpg: Compute PWM value based on period instead

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux