From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7D34BC2BA2B for ; Thu, 16 Apr 2020 07:21:03 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 4562F206D5 for ; Thu, 16 Apr 2020 07:21:03 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4562F206D5 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id C60456EB1A; Thu, 16 Apr 2020 07:21:02 +0000 (UTC) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.134]) by gabe.freedesktop.org (Postfix) with ESMTPS id 6AEE96EB1A for ; Thu, 16 Apr 2020 07:21:00 +0000 (UTC) Received: from mail-qt1-f180.google.com ([209.85.160.180]) by mrelayeu.kundenserver.de (mreue011 [212.227.15.129]) with ESMTPSA (Nemesis) id 1MjjOl-1ixNuz2hT9-00lFfv for ; Thu, 16 Apr 2020 09:20:58 +0200 Received: by mail-qt1-f180.google.com with SMTP id c16so9876589qtv.1 for ; Thu, 16 Apr 2020 00:20:58 -0700 (PDT) X-Gm-Message-State: AGi0PuZ9y0/WhePNBoO7yIP/SXhnA0YN6JS3bGYzKyw+ol3iN1FHmbE8 AF0V7fQGBl3818EKrh7z9QgsQxYtF4aZ+6ZkBP4= X-Google-Smtp-Source: APiQypLki807vlF5rf3bUb/lMDePEthLpUaUBhHRg0/ZUfeGPkLYlO08Klb1Ee851xvIZfXGDxWFM30tec+bUhtYF5c= X-Received: by 2002:ac8:6757:: with SMTP id n23mr12043843qtp.304.1587021657410; Thu, 16 Apr 2020 00:20:57 -0700 (PDT) MIME-Version: 1.0 References: <20200408202711.1198966-1-arnd@arndb.de> <20200408224224.GD11886@ziepe.ca> <87k12pgifv.fsf@intel.com> <7d9410a4b7d0ef975f7cbd8f0b6762df114df539.camel@mellanox.com> <20200410171320.GN11886@ziepe.ca> <16441479b793077cdef9658f35773739038c39dc.camel@mellanox.com> <20200414132900.GD5100@ziepe.ca> <20200414152312.GF5100@ziepe.ca> <834c7606743424c64951dd2193ca15e29799bf18.camel@mellanox.com> In-Reply-To: <834c7606743424c64951dd2193ca15e29799bf18.camel@mellanox.com> From: Arnd Bergmann Date: Thu, 16 Apr 2020 09:20:40 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC 0/6] Regressions for "imply" behavior change To: Saeed Mahameed X-Provags-ID: V03:K1:5yfjy7iLdtWCjlg2JFdTSr6Ig7I2eW38Ge5byiktwIKwkpA54IB NfojU1VQC9H3jnzGIoeBm16eodYxhdzp1/qJDsCeXcvb1qXFcvge08qkSIpg7PBccBKvwUX 33F4Gap6wT4NsAM1Razmaa2Oj/QjjEWlkgN48FkdX5qdMI4OyyA/+lmdnYdpqf0eJTW0CgU xAfR3XFa4U5Ntqzbo+y5w== X-UI-Out-Filterresults: notjunk:1;V03:K0:kqFBDuXmrdI=:2SujjyFX6vbqqZcQU1l6Kt PVVTSKvjR+Nm1iG60BJvZH/yJ9JKfIkRXY46a0OPr9YKWdjEZBVzKPxe9B24YCH3d8B9qki6+ 8FbNm0doH5bIrcm6daJ0DenOr9KKOpaSfUpQM+HNQiOZo9XHK2jeJ5t/n9q/HtYxhP1ikC68w 3p7IRvpXuRbCRl25NXB2/G93dSU2A/vUEK73mQp3Wqv9GFA7SCFbXm3QLe24zS6AsjiOCA6/Q nhPKYFU7X/TEsIXmB886rkf4X1EWAzvt6cEiaDFm2VGg5uTigl31kwIyl0Qs12YxzOsC02ovp 3fyLXSDFh2qc8htOPAQ1t7xX3pgUnjmg/ytYfc6YIrnBqki8n5KPqzLe1wEoGWvwDNwDBEIap SBoLlexiQ/Ea7p2GsoP2Y1yvOvluIplTPazVwZsduuAkkk1a2QnJN/rz+6fnlTJoRMhdQ4/Lp Xy6cKcxfegtlC8oyy/alwplW889NR6it1NkAOWKdS4Q3oPJqML7uNeTrizPNqVhMxUgnghLMn m8p/f2w/JkDafavb9zP9oJfHOe2Tj/4xeYYS0ATgKatubjrgDHYbyp6wH8aw8VGTKAjj5UcOV t/nOL44p+DBRtWwSnHuxwvfOoCiA/sV47ALBIlMtq758//Xa28wQjKv5GHVW+T0SwLa7wDnX7 kpiHerKleLo0uw1OWgheqLGZTCGomzg1R+fVdTsNx0B1VrYMLgc+UYEaj6oFs7wKTqQJ+e6Zh YBLPcn6iUQ6cMH7GT3fn0udBhvwkSKv9o2p/mmpHC6VvcfOjXe3P9mSelvkKOyoFVTa36PxaL VPHiZs+qd9Ym0TT9aX6rmuEZPFSaYYJ9Th+upko2EJ3PyI8ek4= X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "airlied@linux.ie" , "jernej.skrabec@siol.net" , "leon@kernel.org" , "narmstrong@baylibre.com" , "linux-rdma@vger.kernel.org" , "netdev@vger.kernel.org" , "masahiroy@kernel.org" , "nico@fluxnic.net" , "linux-kernel@vger.kernel.org" , "dri-devel@lists.freedesktop.org" , "linux-renesas-soc@vger.kernel.org" , "a.hajda@samsung.com" , "jonas@kwiboo.se" , "kieran.bingham+renesas@ideasonboard.com" , "Laurent.pinchart@ideasonboard.com" , "jgg@ziepe.ca" , "davem@davemloft.net" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Thu, Apr 16, 2020 at 5:25 AM Saeed Mahameed wrote: > > On Tue, 2020-04-14 at 20:47 +0200, Arnd Bergmann wrote: > > On Tue, Apr 14, 2020 at 7:49 PM Saeed Mahameed > > wrote: > > > On Tue, 2020-04-14 at 17:25 +0200, Arnd Bergmann wrote: > > > > On Tue, Apr 14, 2020 at 5:23 PM Jason Gunthorpe > > > > wrote: > > > > Correct. > > > > > > > > > > Great ! > > > > > > Then bottom line we will change mlx5/Kconfig: to > > > > > > depends on VXLAN || !VXLAN > > > > Ok > > > > BTW how about adding a new Kconfig option to hide the details of > ( BAR || !BAR) ? as Jason already explained and suggested, this will > make it easier for the users and developers to understand the actual > meaning behind this tristate weird condition. > > e.g have a new keyword: > reach VXLAN > which will be equivalent to: > depends on VXLAN && !VXLAN I'd love to see that, but I'm not sure what keyword is best. For your suggestion of "reach", that would probably do the job, but I'm not sure if this ends up being more or less confusing than what we have today. > > > This will force MLX5_CORE to m when necessary to make vxlan > > > reachable > > > to mlx5_core. So no need for explicit use of IS_REACHABLE(). > > > in mlx5 there are 4 of these: > > > > > > imply PTP_1588_CLOCK > > > imply VXLAN > > > imply MLXFW > > > imply PCI_HYPERV_INTERFACE > > > > As mentioned earlier, we do need to replace the 'imply > > PTP_1588_CLOCK' > > with the same > > > > depends on PTP_1588_CLOCK || !PTP_1588_CLOCK > > > > So far I have not seen problems for the other two options, so I > > assume they > > are fine for now -- it seems to build just fine without > > PCI_HYPERV_INTERFACE, > > and MLXFW has no other dependencies, meaning that 'imply' is the > > same as 'select' here. Using 'select MLXFW' would make it clearer > > perhaps. > > No, I would like to avoid select and allow building mlx5 without MLXFW, > MLXFW already has a stub protected with IS_REACHABLE(), this is why we > don't have an issue with it. So the 'imply MLXFW' should be dropped then? Arnd _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel