Message ID | 20221130200945.24459-1-rdunlap@infradead.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp1128441wrr; Wed, 30 Nov 2022 12:11:47 -0800 (PST) X-Google-Smtp-Source: AA0mqf5f4a32d1EKk7dAER25wjBfn9wb476PPpldMCN1YleXWyAef/8OxSWGtCja2CMZIR5z+mXq X-Received: by 2002:a17:902:e849:b0:186:898a:f33d with SMTP id t9-20020a170902e84900b00186898af33dmr44484788plg.33.1669839107578; Wed, 30 Nov 2022 12:11:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669839107; cv=none; d=google.com; s=arc-20160816; b=0fJ7I5W23xxjH933k8/dhDgNiVD5IfyUwBWoicajmWFjGpLUZKuo/Eft7Ik0cHUlHi C2Z9aamoosEkA3Dh2Mae90bDfIHUBJdZkrrKxjO/JjlAx++fNmmEzSrUnmqXGnTeMkLl 3kA0mrn4Xr/7ZN6N/n+aSMvUSsf04z6GA3Yv15d09ZljdM8CLoc/qz4l1qSsZjVszlci cNmaHnM5PscN9nc8gdfbPxbtKGjRYmkdaHX+MpQTHt4QEtCnuVVbecqDKTEYsZifbAj0 rmWKEffu2FPoT2LTapz2HDX3fsHPxALMgDABakmR7h+m6fmi8FtF4Hx2IECZ0mW10zBo L2kg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=E47s7ipLMlIc2p61K7hVJzDyYXzzIeBc7VvzcwFMKS0=; b=YGQlplYLJ1JNz+HFlhueFgapxKZYA3S8NtSR88eFDcbNAlbELmuQxBmVazllfK5TS0 qNjXRdLY1UECIDrbdqd8bDTPTZryRId1Rxkpr9zZ/Swu3LMlq6x8ZRnM+XNTsl+WhGqg A954kAJ5QiBV2kNS3/FhlGT4+VuwRrgO8xtZ/ZL91nRt1+wg2nQccHpl2BCh0Q21qS/j MIvVtjgfF4ici0GucWu8d4PGQpeY2q5CAAhpLBGFjMk9ERhpHy8cYnJAeX4W/zl1vbX/ INJrvQrIQnXZDQk1c6nkwgXtlceibPc1s5CgYOVsDz43ZOXYHYrcbpbBY7iIawrrG3uc nxtg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b=fCreKj5U; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id gt19-20020a17090af2d300b002182cd7d958si4954546pjb.46.2022.11.30.12.11.32; Wed, 30 Nov 2022 12:11:47 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b=fCreKj5U; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229773AbiK3UKz (ORCPT <rfc822;heyuhang3455@gmail.com> + 99 others); Wed, 30 Nov 2022 15:10:55 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44686 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229900AbiK3UKU (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 30 Nov 2022 15:10:20 -0500 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EFFA594902; Wed, 30 Nov 2022 12:09:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To:Content-ID: Content-Description:In-Reply-To:References; bh=E47s7ipLMlIc2p61K7hVJzDyYXzzIeBc7VvzcwFMKS0=; b=fCreKj5Uhk8PkDJ0ePgOKryMGY Oo5vAepcgn4j3ApgPA8Yt8s94K3O+M9LixUfH0tkR6V102fEfIfojXL8+fnMDam4Ce2ZibF4kbrgS g/W6809lzC8ktKSJbUTn73N7wWnSp1/l6Kwuf9gg1JVkO9EX7eg+j9QMpec4i4Tb6qVzlSv8yYJxB aPRo+FS+mGMpvTBF51YdoWIwOYa7ZOjZKgXEI4Os2uF9puTFIZQUihfwb+FqPZb6PAKzHcIkQm6cQ nhGbt+r7Zk8CV0KxuekterH7AUvfW/9eqqRifh0FP+y/xeo0nwceJAFC8iFAM/svEYUfGWX4LkcfH aexETR5g==; Received: from [2601:1c2:d80:3110::a2e7] (helo=casper.infradead.org) by casper.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1p0TP3-00FGQd-BU; Wed, 30 Nov 2022 20:09:57 +0000 From: Randy Dunlap <rdunlap@infradead.org> To: linux-kernel@vger.kernel.org Cc: Randy Dunlap <rdunlap@infradead.org>, Jason Gunthorpe <jgg@nvidia.com>, Leon Romanovsky <leon@kernel.org>, Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com>, linux-rdma@vger.kernel.org, Jeff Dike <jdike@addtoit.com>, Richard Weinberger <richard@nod.at>, Anton Ivanov <anton.ivanov@cambridgegreys.com>, Johannes Berg <johannes@sipsolutions.net>, linux-um@lists.infradead.org Subject: [PATCH 1/2 v2] IB/qib: don't use qib_wc_x86_64 for UML Date: Wed, 30 Nov 2022 12:09:45 -0800 Message-Id: <20221130200945.24459-1-rdunlap@infradead.org> X-Mailer: git-send-email 2.38.1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1750953211657544597?= X-GMAIL-MSGID: =?utf-8?q?1750953211657544597?= |
Series |
[1/2,v2] IB/qib: don't use qib_wc_x86_64 for UML
|
|
Commit Message
Randy Dunlap
Nov. 30, 2022, 8:09 p.m. UTC
When building qib_wc_x86_64.c on ARCH=um, references to some cpuinfo
fields cause build errors since cpuinfo does not contain x86-specific
fields.
Fix the build errors by making this driver depend on !UML.
Prevents these build errors:
../drivers/infiniband/hw/qib/qib_wc_x86_64.c: In function ‘qib_unordered_wc’:
../drivers/infiniband/hw/qib/qib_wc_x86_64.c:149:29: error: ‘struct cpuinfo_um’ has no member named ‘x86_vendor’
149 | return boot_cpu_data.x86_vendor != X86_VENDOR_AMD;
../drivers/infiniband/hw/qib/qib_wc_x86_64.c:149:44: error: ‘X86_VENDOR_AMD’ undeclared (first use in this function); did you mean ‘X86_VENDOR_ANY’?
149 | return boot_cpu_data.x86_vendor != X86_VENDOR_AMD;
../drivers/infiniband/hw/qib/qib_wc_x86_64.c:149:44: note: each undeclared identifier is reported only once for each function it appears in
../drivers/infiniband/hw/qib/qib_wc_x86_64.c:150:1: error: control reaches end of non-void function [-Werror=return-type]
150 | }
Fixes: 68f5d3f3b654 ("um: add PCI over virtio emulation driver")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Jason Gunthorpe <jgg@nvidia.com>
Cc: Leon Romanovsky <leon@kernel.org>
Cc: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com>
Cc: linux-rdma@vger.kernel.org
Cc: Jeff Dike <jdike@addtoit.com>
Cc: Richard Weinberger <richard@nod.at>
Cc: Anton Ivanov <anton.ivanov@cambridgegreys.com>
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: linux-um@lists.infradead.org
---
v2: rebase & resend
drivers/infiniband/hw/qib/Kconfig | 1 +
1 file changed, 1 insertion(+)
Comments
On Wed, Nov 30, 2022 at 12:09:45PM -0800, Randy Dunlap wrote: > When building qib_wc_x86_64.c on ARCH=um, references to some cpuinfo > fields cause build errors since cpuinfo does not contain x86-specific > fields. > > Fix the build errors by making this driver depend on !UML. > > Prevents these build errors: > > ../drivers/infiniband/hw/qib/qib_wc_x86_64.c: In function ‘qib_unordered_wc’: > ../drivers/infiniband/hw/qib/qib_wc_x86_64.c:149:29: error: ‘struct cpuinfo_um’ has no member named ‘x86_vendor’ > 149 | return boot_cpu_data.x86_vendor != X86_VENDOR_AMD; > ../drivers/infiniband/hw/qib/qib_wc_x86_64.c:149:44: error: ‘X86_VENDOR_AMD’ undeclared (first use in this function); did you mean ‘X86_VENDOR_ANY’? > 149 | return boot_cpu_data.x86_vendor != X86_VENDOR_AMD; > ../drivers/infiniband/hw/qib/qib_wc_x86_64.c:149:44: note: each undeclared identifier is reported only once for each function it appears in > ../drivers/infiniband/hw/qib/qib_wc_x86_64.c:150:1: error: control reaches end of non-void function [-Werror=return-type] > 150 | } > > Fixes: 68f5d3f3b654 ("um: add PCI over virtio emulation driver") > Signed-off-by: Randy Dunlap <rdunlap@infradead.org> > Cc: Jason Gunthorpe <jgg@nvidia.com> > Cc: Leon Romanovsky <leon@kernel.org> > Cc: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com> > Cc: linux-rdma@vger.kernel.org > Cc: Jeff Dike <jdike@addtoit.com> > Cc: Richard Weinberger <richard@nod.at> > Cc: Anton Ivanov <anton.ivanov@cambridgegreys.com> > Cc: Johannes Berg <johannes@sipsolutions.net> > Cc: linux-um@lists.infradead.org > --- > v2: rebase & resend > > drivers/infiniband/hw/qib/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff -- a/drivers/infiniband/hw/qib/Kconfig b/drivers/infiniband/hw/qib/Kconfig > --- a/drivers/infiniband/hw/qib/Kconfig > +++ b/drivers/infiniband/hw/qib/Kconfig > @@ -3,6 +3,7 @@ config INFINIBAND_QIB > tristate "Intel PCIe HCA support" > depends on 64BIT && INFINIBAND_RDMAVT > depends on PCI > + depends on !UML I would advocate to add this line to whole drivers/infiniband. None of RDMA code makes sense for UML. Thanks > help > This is a low-level driver for Intel PCIe QLE InfiniBand host > channel adapters. This driver does not support the Intel
----- Ursprüngliche Mail ----- > I would advocate to add this line to whole drivers/infiniband. > None of RDMA code makes sense for UML. Yes. Makes sense. Thanks, //richard
On Thu, 2022-12-01 at 11:22 +0200, Leon Romanovsky wrote: > > > +++ b/drivers/infiniband/hw/qib/Kconfig > > @@ -3,6 +3,7 @@ config INFINIBAND_QIB > > tristate "Intel PCIe HCA support" > > depends on 64BIT && INFINIBAND_RDMAVT > > depends on PCI > > + depends on !UML > > I would advocate to add this line to whole drivers/infiniband. > None of RDMA code makes sense for UML. > You could argue that one might want to eventually use kunit for some bits and pieces in there, so it'd make sense to be able to build the parts that _can_ be built, but I have no idea :) johannes
On Thu, Dec 01, 2022 at 10:28:18AM +0100, Johannes Berg wrote: > On Thu, 2022-12-01 at 11:22 +0200, Leon Romanovsky wrote: > > > > > +++ b/drivers/infiniband/hw/qib/Kconfig > > > @@ -3,6 +3,7 @@ config INFINIBAND_QIB > > > tristate "Intel PCIe HCA support" > > > depends on 64BIT && INFINIBAND_RDMAVT > > > depends on PCI > > > + depends on !UML > > > > I would advocate to add this line to whole drivers/infiniband. > > None of RDMA code makes sense for UML. > > > > You could argue that one might want to eventually use kunit for some > bits and pieces in there, so it'd make sense to be able to build the > parts that _can_ be built, but I have no idea :) But now, we don't have anyone in RDMA who uses kunit. Once it will be needed, he/she will extend drivers/infiniband to support it. Thanks > > johannes
On Thu, Dec 01, 2022 at 11:22:04AM +0200, Leon Romanovsky wrote: > I would advocate to add this line to whole drivers/infiniband. > None of RDMA code makes sense for UML. software iWarp and RoCE absolutely make sense on UML.
On Thu, Dec 01, 2022 at 09:15:31AM -0800, Christoph Hellwig wrote: > On Thu, Dec 01, 2022 at 11:22:04AM +0200, Leon Romanovsky wrote: > > I would advocate to add this line to whole drivers/infiniband. > > None of RDMA code makes sense for UML. > > software iWarp and RoCE absolutely make sense on UML. Ok, to be more pedantic "none of RDMA HW code ...". However does anybody use rxe or siw in UML? Thanks
diff -- a/drivers/infiniband/hw/qib/Kconfig b/drivers/infiniband/hw/qib/Kconfig --- a/drivers/infiniband/hw/qib/Kconfig +++ b/drivers/infiniband/hw/qib/Kconfig @@ -3,6 +3,7 @@ config INFINIBAND_QIB tristate "Intel PCIe HCA support" depends on 64BIT && INFINIBAND_RDMAVT depends on PCI + depends on !UML help This is a low-level driver for Intel PCIe QLE InfiniBand host channel adapters. This driver does not support the Intel