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

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] [day] [month] [year] [list]

Message-ID: <bdca9e9f-7e0d-4ca7-8e8b-f27ea8bb3b54@kernel.org>
Date: Tue, 4 Mar 2025 17:30:40 +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 04/03/2025 17:03, Uwe Kleine-König wrote:
> Hello Krzysztof,
> 
> On Tue, Mar 04, 2025 at 10:53:53AM +0100, Krzysztof Kozlowski wrote:
>> On 04/03/2025 07:24, Uwe Kleine-KÃ¶nig wrote:
>>> instead which gives you a more exact result. The challenge here however
>>> is that the multiplication might overflow. If you know that the result
>>> fits into a u64, mul_u64_u64_div_u64() is the function that gets this
>>> right for you.
>>>
>>>>  	chan->pwm_value = min(val, max);
>>>>  }
>>>> [...]
>>>> ---
>>>> 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.

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?
Always base on known commit? 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.

Best regards,
Krzysztof