Hi Linus,
The following changes since commit fa55b7dcdc43c1aa1ba12bca9d2dd4318c2a0dbf:
Linux 5.16-rc1 (2021-11-14 13:56:52 -0800)
are available in the Git repository at:
ssh://[email protected]/pub/scm/linux/kernel/git/sre/linux-power-supply.git tags/for-v5.16-rc
for you to fetch changes up to 644106cdb89844be2496b21175b7c0c2e0fab381:
power: reset: ltc2952: Fix use of floating point literals (2021-11-16 15:22:39 +0100)
----------------------------------------------------------------
Power Supply Fixes for 5.16 cycle
Three fixes for the 5.16 cycle:
1. Avoid going beyond last capacity in the power-supply core
2. Replace 1E6L with NSEC_PER_MSEC to avoid floating point calculation
in LLVM resulting in a build failure
3. Fix ADC measurements in bq25890 charger driver
----------------------------------------------------------------
Linus Walleij (1):
power: supply: core: Break capacity loop
Nathan Chancellor (1):
power: reset: ltc2952: Fix use of floating point literals
Yauhen Kharuzhy (1):
power: bq25890: Enable continuous conversion for ADC at charging
drivers/power/reset/ltc2952-poweroff.c | 4 ++--
drivers/power/supply/bq25890_charger.c | 4 ++--
drivers/power/supply/power_supply_core.c | 4 ++++
3 files changed, 8 insertions(+), 4 deletions(-)
On Sat, Jan 8, 2022 at 3:22 AM Sebastian Reichel <[email protected]> wrote:
>
> 2. Replace 1E6L with NSEC_PER_MSEC to avoid floating point calculation
> in LLVM resulting in a build failure
So I think the patch is obviously the right thing to do regardless,
but that still makes me go "WTF?"
Those uses of 1E6L were perhaps strange, but they were only used in
constant compile-time expressions that were cast to 'unsigned long' in
the end, so how the heck did llvm end up with any floating point in
there?
In this case there was really no excuse not to just use a better
constant, but there are other situations where it might well be quite
reasonable to use floating point calculations to create an integer
constant (eg maybe some spec describes an algorithm in FP, but the
implementation uses fixed-point arithmetic and has initializers that
do the conversion).
Imagine for a moment that you want to do fixed-point math (perhaps
because you have a microcontroller without an FP unit - it's not
limited to just "the kernel doesn't do FP"). Further imagine just for
a moment that you still want some fundamental constants like PI in
that fixed-point format.
The sane way to generate said constants is to do something like
#define FIXPT_1 (1u << FIXPT_SHIFT)
#define FIXPT_FP(x) ((fixpt_t) (((x)*FIXPT_1)+0.5))
#define FIXPT_PI FIXPT_FP(3.14159265)
rather than have to do something incredibly stupid and illogical and
unreadable like
#define FIXPT_PI 205887
So honestly, this seems to be just llvm being completely stupid. The
fact that you don't want to generate floating point code has *NOTHING*
to do with floating point literals for constant expressions.
In fact, even if you don't want to generate floating point code -
again, maybe you don't have a FP unit - doesn't mean that you might
not want to generate normal floating point constants. You may end up
having explicit software floating point, and doing things like passing
the floating point values around manually, ie
union fp {
uint64_t val;
double fp_val;
};
and having code like
static const union fp sqrt2 = { .fp_val = 1.4142.... };
and then doing all the math in 'uint64_t' just because you wrote a
couple of math routines yourself:
fp_mul(&res, sqrt2.val, x);
again, there's no floating point *code* generated, but that doesn't
mean that the compiler shouldn't allow users to use floating point
*values*.
Sadly, I see in the LLVM discussions that the llvm people seem to be
completely out to lunch and in denial, and claim "maybe this is a gcc
bug".
No. Gcc just isn't being stupid.
Nathan, Nick, please talk some sense into the llvm people. The two
examples above are very much not about the Linux kernel (although I
think we actually have a couple of places that do things exactly like
that) they are about generic coding issues.
Linus
The pull request you sent on Sat, 8 Jan 2022 12:22:29 +0100:
> ssh://[email protected]/pub/scm/linux/kernel/git/sre/linux-power-supply.git tags/for-v5.16-rc
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/d445d649c7929ddafff319ad90e3e190722c685a
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html