Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp1654633pxk; Fri, 25 Sep 2020 23:55:18 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzBjtGwb0fd8BrRm8/Xw+g/yZ/65iRPWpPcIxpXGrA71B3g46wgNKJx4uKd19dIm8XTe+yQ X-Received: by 2002:a05:6402:1710:: with SMTP id y16mr5464852edu.197.1601103318191; Fri, 25 Sep 2020 23:55:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601103318; cv=none; d=google.com; s=arc-20160816; b=XbGskedg8G7L1jqcMtIN0cpRYd4RDN9PJhmYoSDqIBI6jrjRtvggzjNlJwZKu/WQAm WZAejoQ+SXHapP1Q0wc2NeZDTElcNa5w6HQh4C69VNva9YMrJ4+CvtIuGCAfouD/y0/T O7bh40IO1XUx/qrJrIH1KbF4YYJpEkqnEyUB8La3BIhj0UqxgQ9YRA9ZjbXwMqMSDSr4 LfXATFWfo9p32R9mtz75BRCJGOj9Ez4whRKpeIrY2lAAb5HuXpMQIWhp00P4SQjVTEVT BauWGDUjcreqIYfkw6vUY9l1GWpZEQSEk9+HWd8OsNglbs8iQK0Xym+pHNLWacxWEL+E RKEg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=xpNLH6trUrJ8NPil8dHhvLDN7w6B7Rmuv42TduNYptE=; b=kZZZ4Y0jgtzobD1JClGQDCGJxGd91cHdPzvaIHhYAowVDxsgVmNpIiPqxQM8XKhO+c FoOdy4HKrZjcLuQuBtizpeT9lB91XxGHeKv4GDtsPbVKdO5BgUL9nnuLsNFwc9PsLZLG 4GAfQIyiKUMtVEPm7PTV/nn+JQEti/1Mpdt0GRyhCXK9n4D3X++wZtHu9VZImJvlkwf6 ssICbzs7TzgIFPKpItS4qbVQEKuynhdGeq8oUObeQ3AmV6ArHwWott55b5s2hBbyBthq Lko8cYhF6bCissi6QR4oI698otL2wypDWtZoE9HswMMZzLnO8ttE/Y93AoyuYrxi7SaB pKuw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=nvidia.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n18si3761602edt.207.2020.09.25.23.54.55; Fri, 25 Sep 2020 23:55:18 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=nvidia.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728871AbgIZGxN (ORCPT + 99 others); Sat, 26 Sep 2020 02:53:13 -0400 Received: from mail.kernel.org ([198.145.29.99]:42172 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726694AbgIZGxN (ORCPT ); Sat, 26 Sep 2020 02:53:13 -0400 Received: from localhost (unknown [213.57.247.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id C75D920878; Sat, 26 Sep 2020 06:53:11 +0000 (UTC) Date: Sat, 26 Sep 2020 09:53:08 +0300 From: Leon Romanovsky To: Jason Wang Cc: "Michael S. Tsirkin" , Randy Dunlap , Eli Cohen , virtualization@lists.linux-foundation.org, LKML , "netdev@vger.kernel.org" , Saeed Mahameed Subject: Re: [PATCH v3 -next] vdpa: mlx5: change Kconfig depends to fix build errors Message-ID: <20200926065308.GC2280698@unreal> References: <73f7e48b-8d16-6b20-07d3-41dee0e3d3bd@infradead.org> <20200918082245.GP869610@unreal> <20200924052932-mutt-send-email-mst@kernel.org> <20200924102413.GD170403@mtl-vdi-166.wap.labs.mlnx> <079c831e-214d-22c1-028e-05d84e3b7f04@infradead.org> <20200924120217-mutt-send-email-mst@kernel.org> <20200925072005.GB2280698@unreal> <20200925061847-mutt-send-email-mst@kernel.org> <821c501c-53ce-3e80-8a73-f0680193df20@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <821c501c-53ce-3e80-8a73-f0680193df20@redhat.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 25, 2020 at 07:29:24PM +0800, Jason Wang wrote: > > On 2020/9/25 下午6:19, Michael S. Tsirkin wrote: > > On Fri, Sep 25, 2020 at 10:20:05AM +0300, Leon Romanovsky wrote: > > > On Thu, Sep 24, 2020 at 12:02:43PM -0400, Michael S. Tsirkin wrote: > > > > On Thu, Sep 24, 2020 at 08:47:05AM -0700, Randy Dunlap wrote: > > > > > On 9/24/20 3:24 AM, Eli Cohen wrote: > > > > > > On Thu, Sep 24, 2020 at 05:30:55AM -0400, Michael S. Tsirkin wrote: > > > > > > > > > --- linux-next-20200917.orig/drivers/vdpa/Kconfig > > > > > > > > > +++ linux-next-20200917/drivers/vdpa/Kconfig > > > > > > > > > @@ -31,7 +31,7 @@ config IFCVF > > > > > > > > > > > > > > > > > > config MLX5_VDPA > > > > > > > > > bool "MLX5 VDPA support library for ConnectX devices" > > > > > > > > > - depends on MLX5_CORE > > > > > > > > > + depends on VHOST_IOTLB && MLX5_CORE > > > > > > > > > default n > > > > > > > > While we are here, can anyone who apply this patch delete the "default n" line? > > > > > > > > It is by default "n". > > > > > > I can do that > > > > > > > > > > > > > > Thanks > > > > > > > Hmm other drivers select VHOST_IOTLB, why not do the same? > > > > > v1 used select, but Saeed requested use of depends instead because > > > > > select can cause problems. > > > > > > > > > > > I can't see another driver doing that. Perhaps I can set dependency on > > > > > > VHOST which by itself depends on VHOST_IOTLB? > > > > > > > > > > > > > > > > help > > > > > > > > > Support library for Mellanox VDPA drivers. Provides code that is > > > > > > > > > > > > > Saeed what kind of problems? It's used with select in other places, > > > > isn't it? > > > IMHO, "depends" is much more explicit than "select". > > > > > > Thanks > > This is now how VHOST_IOTLB has been designed though. > > If you want to change VHOST_IOTLB to depends I think > > we should do it consistently all over. > > > > > > config VHOST_IOTLB > > tristate > > help > > Generic IOTLB implementation for vhost and vringh. > > This option is selected by any driver which needs to support > > an IOMMU in software. > > > Yes, since there's no prompt for VHOST_IOTLB which means, if there's no > other symbol that select VHOST_IOTLB, you can't enable MLX5 at all. > > See kconfig-language.rst: > > >     In general use select only for non-visible symbols >     (no prompts anywhere) and for symbols with no dependencies. >     That will limit the usefulness but on the other hand avoid >     the illegal configurations all over. Thanks, I wasn't aware of this clarification. > > Thanks > > > > > > > > > > > -- > > > > > ~Randy >