From: Linus Torvalds <torvalds@linux-foundation.org>
To: Jakub Kicinski <kuba@kernel.org>
Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
David Miller <davem@davemloft.net>,
Netdev <netdev@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
bpf <bpf@vger.kernel.org>,
NetFilter <netfilter-devel@vger.kernel.org>,
linux-can@vger.kernel.org
Subject: Re: 32bit x86 build broken (was: Re: [GIT PULL] Networking for 5.16-rc1)
Date: Thu, 11 Nov 2021 18:48:43 -0800 [thread overview]
Message-ID: <CAHk-=wiNEdrLirAbHwJvmp_s2Kjjd5eV680hTZnbBT2gXK4QbQ@mail.gmail.com> (raw)
In-Reply-To: <20211111174654.3d1f83e3@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
On Thu, Nov 11, 2021 at 5:46 PM Jakub Kicinski <kuba@kernel.org> 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
next prev parent reply other threads:[~2021-11-12 2:49 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-11 16:33 [GIT PULL] Networking for 5.16-rc1 Jakub Kicinski
2021-11-11 23:09 ` pr-tracker-bot
2021-11-12 1:46 ` 32bit x86 build broken (was: Re: [GIT PULL] Networking for 5.16-rc1) Jakub Kicinski
2021-11-12 2:46 ` YueHaibing
2021-11-12 2:48 ` Linus Torvalds [this message]
2021-11-12 14:33 ` Jakub Kicinski
2021-11-12 15:04 ` Srinivas Pandruvada
2021-11-13 8:46 ` Daniel Lezcano
2021-11-16 17:19 ` Rafael J. Wysocki
2021-11-12 20:44 ` Linus Torvalds
2021-11-12 2:50 ` Srinivas Pandruvada
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='CAHk-=wiNEdrLirAbHwJvmp_s2Kjjd5eV680hTZnbBT2gXK4QbQ@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=bpf@vger.kernel.org \
--cc=davem@davemloft.net \
--cc=kuba@kernel.org \
--cc=linux-can@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=rafael.j.wysocki@intel.com \
--cc=srinivas.pandruvada@linux.intel.com \
/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;
as well as URLs for NNTP newsgroup(s).