Received: by 10.192.165.148 with SMTP id m20csp291193imm; Thu, 3 May 2018 20:31:25 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrR8fH/dhP9IGhF3rgn3x1kGvdLA5Y+POMCXgMnST0vhex7QTehE5zmJyTXMhoxAX+3Dvrp X-Received: by 2002:a65:4cc7:: with SMTP id n7-v6mr21357620pgt.354.1525404685681; Thu, 03 May 2018 20:31:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525404685; cv=none; d=google.com; s=arc-20160816; b=kix+idvhaLcVxclpBATpqPzOfGL+VzhqbgOQ+dfH5K1J+O4GLBbkjpByWvXr+6M+Nv v0JjT1jRVIMGYlQcyBL67+2RrCi+v5uoIakWbL+sJ0NhLIb6rHxQvEXubVd9b0WsfF3c OpHCIq39F3zZMKm/yGGqDq+zSxOXVHUnXVlz5oYyKO94gkUWsKHIy+Vm6zouv4XNRL86 sDpL5y5ZZ/of9b0XTyBGkSt+9fVP5vJ8OOZfZUczjKXCa7bnzMn2yVxLqOPHLOQkTtnT D9hjkYCUUWaQiwAFt8qlWI4IbZuxqVtMdqDSim+6ZewxprNGRpCrf9BR0/7KKav4628g yBDQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature :arc-authentication-results; bh=Ep7V33KfIZvtK/xymwWAoxlCpgJcKDztlsSk5PrTMNM=; b=O8+1cwm/cTaXMT+apfxFklF3fOzNdkcRsT0+TqeVGNdh31n4iFlYj68rfBa6dhzHh1 mZG4FiPp8hULO/HMqRdnxXHyx3S99O675vkFpjeTzBFDBwnFEm31J1NI6hoCQT5JKyto iTH2qWUx0JLk6lZXptFYmrveYe2mExFY8LK0N1Zqu6lsPukYFQfHeychkAgZhvH4mL3k fRWZbE/mrjtFMdc0vKKMgJNkkCFrooryIky5BBmaTxqKuuly8DdecjqrNpmIZxuFny7b p3PctVnbvuPTiGXhtX63XFNBAjNbwuMgdmLxbvZcnYv8QXD0uaYNfFkuzVEzSbYPbrPh qDaQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=DnSZTxDg; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o76si2642321pfj.118.2018.05.03.20.31.11; Thu, 03 May 2018 20:31:25 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=DnSZTxDg; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751336AbeEDDa6 (ORCPT + 99 others); Thu, 3 May 2018 23:30:58 -0400 Received: from mail-yw0-f193.google.com ([209.85.161.193]:34770 "EHLO mail-yw0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751236AbeEDDa4 (ORCPT ); Thu, 3 May 2018 23:30:56 -0400 Received: by mail-yw0-f193.google.com with SMTP id x27-v6so3720216ywj.1 for ; Thu, 03 May 2018 20:30:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ep7V33KfIZvtK/xymwWAoxlCpgJcKDztlsSk5PrTMNM=; b=DnSZTxDg+nMCrbK2EnzkohQ2mFAgEBr/4TChd8p5/tpNAUBHlN7qf99NuVI+z/iNtY 0KdXaeM5FTXeZbpw1jYFq3pvbwYH8kK2xw7FMwrieA5+NivWuYBFwrhgRmuf8udcaJpY n1TQDMGyOWPErt84P98suUfNFLLBqs5MtVL8rjDHaZtzJDYTC1NtFfK7kn3LOPHq8JJD cUqPQ1nnlvwEovBsN3JJzzAZ6YLblklVXMtXSwcX3+Y8NB3kMseKfRNwGtnzg//CPqzo S+1C3uWmMGrPDvXyXfjqKyQmckwlJw3+Mz+zCAiFqUn/l333zPgQgwZi9N7qeVplffFc Q73Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ep7V33KfIZvtK/xymwWAoxlCpgJcKDztlsSk5PrTMNM=; b=GV3SDPYOZREN0QdBr9B0a77sXxWsPBNhK7UZ4od+r6u7QhD34ueI1u41ikSPymCT03 3uHHwsjd8OD+mdVpeNyS9+ZUlFp+ZnkE+RXR7Chvw91qHdbGy42g5MKBNdp9oovb/SZ4 nO8wkTmL3mnBKCGdmDrEiHWsXPHEavjeJCSxLE2y9Jk8sEnEvEXfpgPtVoop8gSVYhW6 IvfMn8tetQ6eBViIy6mk5uyk/P6dZ4uEEEMhy3AgbOySEIfWhAcgiSlV72TSerFUh3Ri MBqc6Zh5G8nFQk+FrefqfryNM0xjptOByzk9VPTdvYMgu3x8abuc4Kj4YgTphdd6TuyC XM9w== X-Gm-Message-State: ALQs6tDMjK4OTG6VhtZbWtoN3FnsygCaJHDiGuKgssrEKkBZXVF1JZ99 pKyrH1RsZFCMzX95NA7mkDpuouRYAo8AvvdoAkvzHg== X-Received: by 2002:a0d:cf01:: with SMTP id r1-v6mr14465431ywd.464.1525404655555; Thu, 03 May 2018 20:30:55 -0700 (PDT) MIME-Version: 1.0 References: <20180425223340.206907-1-gthelen@google.com> <20180430233500.GI26909@ziepe.ca> <20180501204803.GE28551@ziepe.ca> In-Reply-To: <20180501204803.GE28551@ziepe.ca> From: Greg Thelen Date: Fri, 04 May 2018 03:30:44 +0000 Message-ID: Subject: Re: [PATCH 3/5] ib_srpt: depend on INFINIBAND_ADDR_TRANS To: Jason Gunthorpe Cc: Doug Ledford , Bart Van Assche , Christoph Hellwig , linux-rdma@vger.kernel.org, LKML , Tarick Bedeir Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 1, 2018 at 1:48 PM Jason Gunthorpe wrote: > On Tue, May 01, 2018 at 03:08:57AM +0000, Greg Thelen wrote: > > On Mon, Apr 30, 2018 at 4:35 PM Jason Gunthorpe wrote: > > > > > On Wed, Apr 25, 2018 at 03:33:39PM -0700, Greg Thelen wrote: > > > > INFINIBAND_SRPT code depends on INFINIBAND_ADDR_TRANS provided symbols. > > > > So declare the kconfig dependency. This is necessary to allow for > > > > enabling INFINIBAND without INFINIBAND_ADDR_TRANS. > > > > > > > > Signed-off-by: Greg Thelen > > > > Cc: Tarick Bedeir > > > > drivers/infiniband/ulp/srpt/Kconfig | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/drivers/infiniband/ulp/srpt/Kconfig > > b/drivers/infiniband/ulp/srpt/Kconfig > > > > index 31ee83d528d9..fb8b7182f05e 100644 > > > > +++ b/drivers/infiniband/ulp/srpt/Kconfig > > > > @@ -1,6 +1,6 @@ > > > > config INFINIBAND_SRPT > > > > tristate "InfiniBand SCSI RDMA Protocol target support" > > > > - depends on INFINIBAND && TARGET_CORE > > > > + depends on INFINIBAND && INFINIBAND_ADDR_TRANS && TARGET_CORE > > > > > Isn't INFINIBAND && INFINIBAND_ADDR_TRANS a bit redundant? Can't have > > > INFINIBAND_ADDR_TRANS without INFINIBAND. > > > > By kconfig INFINIBAND_ADDR_TRANS depends on INFINIBAND. So yes, it seems > > redundant. I don't know if anyone has designs to break this dependency and > > allow for ADDR_TRANS without INFINIBAND. Assuming not, I'd be willing to > > amend my series removing redundant INFINIBAND and a followup series to > > remove it from similar depends. Though I'm not familiar with rdma dev tree > > lifecycle. Is rdma/for-rc a throw away branch (akin to linux-next), or > > will it be merged into linus/master? If throwaway, then we can amend > > its patches, otherwise followups will be needed. > > > > Let me know what you'd prefer. Thanks. > I think a single update patch to fix all of these, and the > pre-existing ones would be great I just posted the cleanup: https://lkml.org/lkml/2018/5/3/1045