From: Ali Ahmet Memis <ali@iusegentoo.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: linux-hwmon@vger.kernel.org, Sashiko <sashiko-bot@kernel.org>,
Wilken Gottwalt <wilken.gottwalt@posteo.net>
Subject: Re: [PATCH RESEND] hwmon: (corsair-psu) Fix linear11 calculation
Date: Tue, 4 Aug 2026 00:15:06 +0000 [thread overview]
Message-ID: <20260804001526.211161-1-ali@iusegentoo.com> (raw)
In-Reply-To: <20260803232156.2340048-1-linux@roeck-us.net>
On Mon, 3 Aug 2026 16:21:55 -0700 Guenter Roeck wrote:
> + if (exp >= 0)
> + result *= (int)(1UL << exp);
> + else
> + result /= (int)(1UL << -exp);
This breaks the build on 32 bit. result is s64 and the divisor is only known
at runtime, so the compiler emits a libgcc call instead of a shift, and
__divdi3 is only provided by sparc and parisc. SENSORS_CORSAIR_PSU just
depends on HID, so i386 and 32 bit arm are reachable.
On this patch applied to 2d2338c93da7:
$ make ARCH=i386 defconfig
$ ./scripts/config --set-val CONFIG_SENSORS_CORSAIR_PSU y
$ make ARCH=i386 olddefconfig
$ make ARCH=i386 vmlinux
[...]
LD .tmp_vmlinux1
ld: drivers/hwmon/corsair-psu.o: in function `corsairpsu_get_value':
corsair-psu.c:(.text+0xa0b): undefined reference to `__divdi3'
ld: corsair-psu.c:(.text+0xa63): undefined reference to `__divdi3'
ld: corsair-psu.c:(.text+0xa83): undefined reference to `__divdi3'
ld: corsair-psu.c:(.text+0xaa3): undefined reference to `__divdi3'
make[2]: *** [scripts/Makefile.vmlinux:72: vmlinux.unstripped] Error 1
Only the divide is a problem, the multiply builds fine. div_s64() would do
it, or keeping a shift on the negative branch, since the divisor is a power
of two anyway.
The mantissa fix itself looks right to me. ((s16)((val & 0x7ff) << 5)) >> 5
puts bit 10 of the mantissa into the sign bit of the s16 before the
arithmetic shift brings it back, which is what the old order failed to do.
One small thing on the changelog: it says right shifting negative values is
implementation defined and that multiply and divide are used to avoid that,
but exp and mant are still computed with >> on values that can be negative.
That is the normal sign extension idiom and fine in practice, it just reads
as if those had been converted too.
next prev parent reply other threads:[~2026-08-04 0:16 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-03 23:21 [PATCH RESEND] hwmon: (corsair-psu) Fix linear11 calculation Guenter Roeck
2026-08-03 23:34 ` sashiko-bot
2026-08-04 0:15 ` Ali Ahmet Memis [this message]
2026-08-04 2:58 ` Guenter Roeck
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=20260804001526.211161-1-ali@iusegentoo.com \
--to=ali@iusegentoo.com \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=sashiko-bot@kernel.org \
--cc=wilken.gottwalt@posteo.net \
/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