Thread (11 messages) 11 messages, 7 authors, 2021-11-16

Re: 32bit x86 build broken (was: Re: [GIT PULL] Networking for 5.16-rc1)

flat view

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: 2021-11-12 02:49:06
Also in: bpf, linux-can, lkml, netfilter-devel

On Thu, Nov 11, 2021 at 5:46 PM Jakub Kicinski [off-list ref] wrote:
Rafael, Srinivas, we're getting 32 bit build failures after pulling back
from Linus today.

make[1]: *** [/home/nipa/net/Makefile:1850: drivers] Error 2
make: *** [Makefile:219: __sub-make] Error 2
../drivers/thermal/intel/int340x_thermal/processor_thermal_mbox.c: In function ‘send_mbox_cmd’:
../drivers/thermal/intel/int340x_thermal/processor_thermal_mbox.c:79:37: error: implicit declaration of function ‘readq’; did you mean ‘readl’? [-Werror=implicit-function-declaration]
   79 |                         *cmd_resp = readq((void __iomem *) (proc_priv->mmio_base + MBOX_OFFSET_DATA));
      |                                     ^~~~~
      |                                     readl
Gaah.

The trivial fix is *probably* just a simple

    #include <linux/io-64-nonatomic-lo-hi.h>

to say that a non-atomic readq() is ok done low word first. IOW, just a

  --- a/drivers/thermal/intel/int340x_thermal/processor_thermal_mbox.c
  +++ b/drivers/thermal/intel/int340x_thermal/processor_thermal_mbox.c
  @@ -7,6 +7,7 @@
   #include <linux/kernel.h>
   #include <linux/module.h>
   #include <linux/pci.h>
  +#include <linux/io-64-nonatomic-lo-hi.h>
   #include "processor_thermal_device.h"

   #define MBOX_CMD_WORKLOAD_TYPE_READ  0x0E

Of course, it depends on the hardware. It might not matter. Or maybe
it really wants the high word read first.

Looking at that driver, and how it didn't use to do 64-bit reads at
all, I suspect the answer is "doesn't matter".

                Linus
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help