Hello Andrew, On Mon, Jul 29, 2024 at 01:31:06PM -0700, Andrew Morton wrote: > On Mon, 29 Jul 2024 16:34:08 +0200 Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxx> wrote: > > On Mon, Jul 08, 2024 at 02:55:50PM -0700, Andrew Morton wrote: > > > > > > The patch titled > > > Subject: mul_u64_u64_div_u64: make it precise always > > > has been added to the -mm mm-nonmm-unstable branch. Its filename is > > > mul_u64_u64_div_u64-make-it-precise-always.patch > > > > this patch appeared in next-20240723 as > > 3cc8bf1a81efde105d8e57398cf8554b57768777. But it's not included in later > > next snapshots and also didn't land in v6.11-rc1. > > All of mm.git has been excluded from -next for a few days, as it > contains rather a lot of 6.12 material. > > > I have some patches pending that rely on mul_u64_u64_div_u64 being > > precise and want to add a variant that rounds up. So getting this "in" > > would be great. > > It was a bit late for -rc1. I plan to add it to 6.11-rcX soon via > mm.git's hotfixes branches. Please send along a more complete > description of your need for more precision so I can add that to the > changelog to further justify a post-rc1 merge. My personal interest is to get the calculations in pwm drivers right. This function is used in several drivers below drivers/pwm/ . With the errors in mul_u64_u64_div_u64(), pwm consumers might not get the settings they request. Although I have to admit that I'm not aware it breaks real use cases (because typically the periods used are too short to make the involved multiplications overflow), but I pretty sure am not aware of all usages and it breaks testing. Another justification is commits like https://git.kernel.org/tip/77baa5bafcbe1b2a15ef9c37232c21279c95481c, where people start to work around the precision shortcomings of mul_u64_u64_div_u64(). Best regards Uwe
Attachment:
signature.asc
Description: PGP signature
