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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 8B6C8C433B4 for ; Thu, 8 Apr 2021 10:45:07 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 03E516113A for ; Thu, 8 Apr 2021 10:45:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 03E516113A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 6ED026B0078; Thu, 8 Apr 2021 06:45:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6C3DE6B007E; Thu, 8 Apr 2021 06:45:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 564BA6B0080; Thu, 8 Apr 2021 06:45:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0190.hostedemail.com [216.40.44.190]) by kanga.kvack.org (Postfix) with ESMTP id 398BD6B0078 for ; Thu, 8 Apr 2021 06:45:06 -0400 (EDT) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id EEA868E63 for ; Thu, 8 Apr 2021 10:45:05 +0000 (UTC) X-FDA: 78008867370.12.9ABB68D Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.13]) by imf02.hostedemail.com (Postfix) with ESMTP id C8DFA40002DE for ; Thu, 8 Apr 2021 10:44:55 +0000 (UTC) Received: from mail-wm1-f51.google.com ([209.85.128.51]) by mrelayeu.kundenserver.de (mreue107 [213.165.67.113]) with ESMTPSA (Nemesis) id 1MYN7M-1l7qpR1wAc-00VQVp for ; Thu, 08 Apr 2021 12:45:03 +0200 Received: by mail-wm1-f51.google.com with SMTP id n11-20020a05600c4f8bb029010e5cf86347so3793933wmq.1 for ; Thu, 08 Apr 2021 03:45:03 -0700 (PDT) X-Gm-Message-State: AOAM5324XlRjv+4/hgas8KTRjcwQL4m/rNSYRxHRJZEHtl3aswc4tHiP SskyttTuGODQT1gzDG2soJiWmLj+I9wdD6hGyzQ= X-Google-Smtp-Source: ABdhPJytz/lV77i5o3bCVeCx28eGBRpFGJa3HAhceDBuu8+SNlIqf7YyHBd9MAcXBsV7ViVqwijCZWLATsW/w+YkaWY= X-Received: by 2002:a1c:4c0c:: with SMTP id z12mr7558571wmf.38.1617878702742; Thu, 08 Apr 2021 03:45:02 -0700 (PDT) MIME-Version: 1.0 References: <20210408092011.52763-1-david@redhat.com> <20210408092011.52763-3-david@redhat.com> In-Reply-To: From: Arnd Bergmann Date: Thu, 8 Apr 2021 12:44:46 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv To: David Hildenbrand Cc: Linux Kernel Mailing List , Linux-MM , Joel Stanley , David Airlie , Daniel Vetter , Andrew Jeffery , Lucas Stach , Russell King , Christian Gmeiner , Mike Rapoport , Bartlomiej Zolnierkiewicz , Linus Walleij , Michal Simek , Masahiro Yamada , Randy Dunlap , Peter Collingbourne , linux-aspeed , dri-devel , Linux ARM , The etnaviv authors , Linux Fbdev development list Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:VVfrd7IodlxsV3+1P2h4IPJOlW/drKCeLK6HwTyIqUIaNDr3j93 XZeGAZAdKgkCLJUgFLYpjVmHQBJRFcWnq/HyGnSYRCOfpVZL4ujGuZet9G5y8G0mzXszLCT avW2SILu8TMhOMijDl0wo8qjSKK6xOzG0t7KcduwYFDLTl/a5/bH6vnt5VX3XKiptfMifRB rr/KRbfQxpYhZxENOInqA== X-UI-Out-Filterresults: notjunk:1;V03:K0:84zFqr9Xqpg=:DC0rYWhzlR0ckjjGVyEQ1p KIIxZSFMVrMQgmOvQ7bnXbAh2bJGyBiOLxO/JWu8SzNupRfYbgxCowFLExf/R5uAUmC9Kxw7C FixQeOxNiHLCIbcrnKGN/um+JkYhR4xH0cTiiMFBSYW6Ii53vvAN9EbhvZvp1T8UmMUag6rlv eOIapqwgtd+2+cDXiXHOS3/JRCQ7YUTbWXvmigcmu3Lq6vq/56J0SuEO3uGRAIJPVbe0N72Ir TJgA/iuVnZ9Px4WPBo3Cw//am4s6/p8FKBKs4m+t6/+DfjStwcDIjEx7XG+tKtU7YuyPljIhf B2HZLEfF9EWv0V75n6iU5Hos7mGByW820Ln73WnL5l+CEk0wYhNkVf1pue1/zOaDRJNwxeG2l fCoHOoTXnDsE1chSdVzOkb7M20QYSeR/fXhB82vOsSvZPrnma70J5H44vsmG7i5ggtms1QsWv vEB2/8TxHykjfzP8yfbSbKkxPVt0k2mlndNo6G8PcucYPd5rwfxNBDWE2i+kKN+O1uRPgU/t0 gdfZmXbu4ME6jv7wvXfacYNMnNhNfx1C0QseB49CTrSQ3fGDBDoIkbBdne4XL8ElyFhZbEl6t /lHHIOOlawhDygUg8xfdPTMTDmSErI/i+9 X-Rspamd-Queue-Id: C8DFA40002DE X-Stat-Signature: gwbunwj53eoppqiw7n3iwizdt4skn3qm X-Rspamd-Server: rspam02 Received-SPF: none (arndb.de>: No applicable sender policy available) receiver=imf02; identity=mailfrom; envelope-from=""; helo=mout.kundenserver.de; client-ip=212.227.17.13 X-HE-DKIM-Result: none/none X-HE-Tag: 1617878695-772946 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Apr 8, 2021 at 12:29 PM David Hildenbrand wrote: > On 08.04.21 12:20, Arnd Bergmann wrote: > > On Thu, Apr 8, 2021 at 11:22 AM David Hildenbrand wrote: > >> > >> Random drivers should not override a user configuration of core knobs > >> (e.g., CONFIG_DMA_CMA=n). Use "imply" instead, to still respect > >> dependencies and manual overrides. > >> > >> "This is similar to "select" as it enforces a lower limit on another > >> symbol except that the "implied" symbol's value may still be set to n > >> from a direct dependency or with a visible prompt." > >> > >> Implying DRM_CMA should be sufficient, as that depends on CMA. > >> > >> Note: If this is a real dependency, we should use "depends on DMA_CMA" > >> instead - but I assume the driver can work without CMA just fine -- > >> esp. when we wouldn't have HAVE_DMA_CONTIGUOUS right now. > > > > 'imply' is almost never the right solution, and it tends to cause more > > problems than it solves. > > I thought that was the case with "select" :) Yes, but that's a different set of problems > > > > In particular, it does not prevent a configuration with 'DRM_CMA=m' > > I assume you meant "DRM_CMA=n" ? DRM_CMA cannot be built as a module. Ok, at least that makes it easier. > > and 'DRMA_ASPEED_GFX=y', or any build failures from such > > a configuration. > > I don't follow. "DRM_CMA=n" and 'DRMA_ASPEED_GFX=y' is supposed to work > just fine (e.g., without HAVE_DMA_CONTIGUOUS) or what am I missing? I thought you were trying to solve the problem where DRMA_ASPEED_GFX can optionally link against CMA but would fail to build when the CMA code is in a loadable module. If the problem you are trying to solve is a different one, you need a different solution, not what I posted above. > > If you want this kind of soft dependency, you need > > 'depends on DRM_CMA || !DRM_CMA'. > > Seriously? I think the point of imply is "please enable if possible and > not prevented by someone else". That used to be the meaning, but it changed a few years ago. Now it means "when a used manually turns on this symbol, turn on the implied one as well, but let them turn it off again if they choose". This is pretty much a NOP. > Your example looks more like a NOP - no? > Or will it have the same effect? The example I gave is only meaningful if both are tristate, which is not the case here as you explain. It is a somewhat awkward way to say "prevent this symbol from being =y if the dependency is =m". Arnd