public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzk@kernel.org>
To: "Uwe Kleine-König" <ukleinek@kernel.org>
Cc: Abel Vesa <abel.vesa@linaro.org>, Lee Jones <lee@kernel.org>,
	Pavel Machek <pavel@kernel.org>,
	Anjelique Melendez <anjelique.melendez@oss.qualcomm.com>,
	Kamal Wadhwa <quic_kamalw@quicinc.com>,
	Jishnu Prakash <jishnu.prakash@oss.qualcomm.com>,
	Bjorn Andersson <andersson@kernel.org>,
	Konrad Dybcio <konradybcio@kernel.org>,
	Johan Hovold <johan@kernel.org>,
	Sebastian Reichel <sre@kernel.org>, Pavel Machek <pavel@ucw.cz>,
	linux-leds@vger.kernel.org, linux-pwm@vger.kernel.org,
	linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC] leds: rgb: leds-qcom-lpg: Compute PWM value based on period instead
Date: Tue, 4 Mar 2025 17:30:40 +0100	[thread overview]
Message-ID: <bdca9e9f-7e0d-4ca7-8e8b-f27ea8bb3b54@kernel.org> (raw)
In-Reply-To: <ovnmhbzwwimil3opuv6e2ayyntlx7upxfkzm5qdfskx2x7hl7x@wmtul33ttow5>

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

  reply	other threads:[~2025-03-04 16:30 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-03 16:14 [PATCH RFC] leds: rgb: leds-qcom-lpg: Compute PWM value based on period instead Abel Vesa
2025-03-03 22:48 ` Sebastian Reichel
2025-03-04  6:24 ` Uwe Kleine-König
2025-03-04  9:21   ` Abel Vesa
2025-03-04  9:52     ` Abel Vesa
2025-03-04 15:38     ` Uwe Kleine-König
2025-03-05 14:32       ` Abel Vesa
2025-03-05 14:42         ` neil.armstrong
2025-03-06 22:34           ` Uwe Kleine-König
2025-03-04  9:53   ` Krzysztof Kozlowski
2025-03-04 16:03     ` Uwe Kleine-König
2025-03-04 16:30       ` Krzysztof Kozlowski [this message]
2025-03-06 23:33         ` Uwe Kleine-König
2025-03-07  7:07           ` Krzysztof Kozlowski
2025-03-08 19:15             ` Uwe Kleine-König

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bdca9e9f-7e0d-4ca7-8e8b-f27ea8bb3b54@kernel.org \
    --to=krzk@kernel.org \
    --cc=abel.vesa@linaro.org \
    --cc=andersson@kernel.org \
    --cc=anjelique.melendez@oss.qualcomm.com \
    --cc=jishnu.prakash@oss.qualcomm.com \
    --cc=johan@kernel.org \
    --cc=konradybcio@kernel.org \
    --cc=lee@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=linux-pwm@vger.kernel.org \
    --cc=pavel@kernel.org \
    --cc=pavel@ucw.cz \
    --cc=quic_kamalw@quicinc.com \
    --cc=sre@kernel.org \
    --cc=ukleinek@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox