summaryrefslogtreecommitdiff
path: root/tools/Makefile
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2021-11-12 10:56:25 -0800
committerLinus Torvalds <torvalds@linux-foundation.org>2021-11-12 10:56:25 -0800
commitd9c8e52ff9e84ff1a406330f9ea4de7c5eb40282 (patch)
treec13c6c7939af16747d1b5559297ff08a2271f400 /tools/Makefile
parent5833291ab6de9c3e2374336b51c814e515e8f3a5 (diff)
thermal: int340x: fix build on 32-bit targets
Commit aeb58c860dc5 ("thermal/drivers/int340x: processor_thermal: Suppot 64 bit RFIM responses") started using 'readq()' to read 64-bit status responses from the int340x hardware. That's all fine and good, but on 32-bit targets a 64-bit 'readq()' is ambiguous, since it's no longer an atomic access. Some hardware might require 64-bit accesses, and other hardware might want low word first or high word first. It's quite likely that the driver isn't relevant in a 32-bit environment any more, and there's a patch floating around to just make it depend on X86_64, but let's make it buildable on x86-32 anyway. The driver previously just read the low 32 bits, so the hardware certainly is ok with 32-bit reads, and in a little-endian environment the low word first model is the natural one. So just add the include for the 'io-64-nonatomic-lo-hi.h' version. Fixes: aeb58c860dc5 ("thermal/drivers/int340x: processor_thermal: Suppot 64 bit RFIM responses") Reported-by: Jakub Kicinski <kuba@kernel.org> Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'tools/Makefile')
0 files changed, 0 insertions, 0 deletions