From: Ingo Molnar <mingo@kernel.org>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-tip-commits@vger.kernel.org"
<linux-tip-commits@vger.kernel.org>, lkp <lkp@intel.com>,
"x86@kernel.org" <x86@kernel.org>,
linux-um@lists.infradead.org
Subject: [PATCH -v2] accel/habanalabs: Don't build the driver on UML
Date: Thu, 8 May 2025 10:57:51 +0200 [thread overview]
Message-ID: <aBxyDyVT5QbOlhPq@gmail.com> (raw)
In-Reply-To: <007a7132d1396912b1381e96cc4401a10071ed24.camel@sipsolutions.net>
* Johannes Berg <johannes@sipsolutions.net> wrote:
> +linux-um
>
> On Wed, 2025-05-07 at 18:40 +0000, tip-bot2 for Ingo Molnar wrote:
> >
> > To resolve these kinds of problems and to allow <asm/tsc.h> to be included on UML,
> > add a simplified version of <asm/tsc.h>, which only adds the rdtsc() definition.
>
> OK, weird, why would that be needed - UM isn't really X86.
>
> > arch/um/include/asm/tsc.h | 25 +++++++++++++++++++++++++
>
> Feels that should be in arch/x86/um/asm/ instead, which I believe is
> also included but then at least pretends to keep the notion that UML
> could be ported to other architectures ;-)
>
> > +static __always_inline u64 rdtsc(void)
> > +{
> > + EAX_EDX_DECLARE_ARGS(val, low, high);
> > +
> > + asm volatile("rdtsc" : EAX_EDX_RET(val, low, high));
> > +
> > + return EAX_EDX_VAL(val, low, high);
> > +}
>
> Though I also wonder where this is called at all that would be relevant
> for UML? If it's not then perhaps we should just make using it
> unbuildable, a la
>
> u64 __um_has_no_rdtsc(void);
> #define rdtsc() __um_has_no_rdtsc()
>
> or something like that... (and then of course keep it in the current
> location). But looking at the 0-day report that'd probably break
> building the driver on UML; while the driver doesn't seem important we
> wouldn't really want that...
>
> Actually, that's just because of the stupid quirk in UML/X86:
>
> config DRM_ACCEL_HABANALABS
> tristate "HabanaLabs AI accelerators"
> depends on DRM_ACCEL
> depends on X86_64
>
> that last line should almost certainly be "depends on X86 && X86_64"
> because ARCH=um will set UM and X86_64, but not X86 since the arch
> Kconfig symbols are X86 and UM respectively, but the UML subarch still
> selects X86_64 ...
>
>
> I dunno. I guess we can put rdtsc() into UML on x86 as I suggested about
> the file placement, or we can also just fix the Kconfig there.
The Kconfig solution looks much simpler to me too :)
Patch attached, does this look good to you?
Thanks,
Ingo
===================================>
From: Ingo Molnar <mingo@kernel.org>
Date: Wed, 7 May 2025 20:25:59 +0200
Subject: [PATCH] accel/habanalabs: Don't build the driver on UML
The following commit:
288a4ff0ad29 ("x86/msr: Move rdtsc{,_ordered}() to <asm/tsc.h>")
removed the <asm/msr.h> include from the accel/habanalabs driver, which broke
the build on UML:
drivers/accel/habanalabs/common/habanalabs_ioctl.c:326:23: error: call to undeclared function 'rdtsc'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
Make the driver depend on 'X86 && X86_64', instead of just 'X86_64',
thus it won't be built on UML.
Suggested-by: Johannes Berg <johannes.berg@intel.com>
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Ofir Bitton <obitton@habana.ai>
Cc: Oded Gabbay <ogabbay@kernel.org>
Link: https://lore.kernel.org/r/202505080003.0t7ewxGp-lkp@intel.com
---
drivers/accel/habanalabs/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/accel/habanalabs/Kconfig b/drivers/accel/habanalabs/Kconfig
index be85336107f9..1919fbb169c7 100644
--- a/drivers/accel/habanalabs/Kconfig
+++ b/drivers/accel/habanalabs/Kconfig
@@ -6,7 +6,7 @@
config DRM_ACCEL_HABANALABS
tristate "HabanaLabs AI accelerators"
depends on DRM_ACCEL
- depends on X86_64
+ depends on X86 && X86_64
depends on PCI && HAS_IOMEM
select GENERIC_ALLOCATOR
select HWMON
next prev parent reply other threads:[~2025-05-08 9:18 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-07 16:41 [tip:x86/msr 5/19] drivers/accel/habanalabs/common/habanalabs_ioctl.c:326:23: error: call to undeclared function 'rdtsc'; ISO C99 and later do not support implicit function declarations kernel test robot
[not found] ` <174664324585.406.10812098910624084030.tip-bot2@tip-bot2>
2025-05-07 20:36 ` [tip: x86/msr] um: Add UML version of <asm/tsc.h> to define rdtsc() Johannes Berg
2025-05-08 8:57 ` Ingo Molnar [this message]
2025-05-08 9:02 ` [PATCH -v2] accel/habanalabs: Don't build the driver on UML Johannes Berg
2025-05-08 9:03 ` Ingo Molnar
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=aBxyDyVT5QbOlhPq@gmail.com \
--to=mingo@kernel.org \
--cc=johannes@sipsolutions.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.org \
--cc=linux-um@lists.infradead.org \
--cc=lkp@intel.com \
--cc=x86@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.