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
