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 CF1D1C43461 for ; Thu, 8 Apr 2021 12:12:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9C66A61165 for ; Thu, 8 Apr 2021 12:12:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231454AbhDHMNF (ORCPT ); Thu, 8 Apr 2021 08:13:05 -0400 Received: from mout.kundenserver.de ([212.227.126.134]:54669 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229837AbhDHMND (ORCPT ); Thu, 8 Apr 2021 08:13:03 -0400 Received: from mail-ot1-f51.google.com ([209.85.210.51]) by mrelayeu.kundenserver.de (mreue010 [213.165.67.97]) with ESMTPSA (Nemesis) id 1MpD7H-1lvWIO0k4F-00qgzI; Thu, 08 Apr 2021 14:12:51 +0200 Received: by mail-ot1-f51.google.com with SMTP id y19-20020a0568301d93b02901b9f88a238eso2007403oti.11; Thu, 08 Apr 2021 05:12:50 -0700 (PDT) X-Gm-Message-State: AOAM533aQ5x2KJXqDZ4QIKID1luXPLRkW+oLSy1Gzf8ZUrad1i6ySbHB ufTeJn2FORdxmaa+3UyWrrpy67VYPvwhS1VrEEo= X-Google-Smtp-Source: ABdhPJxHyCWMenVUxv33s1E6jvbsFFZTfTMiy2a27GKmZ/Mw2GJW7+vO9jPST57wudsWVl6e6VoT2RKQT0t6kEAsZEE= X-Received: by 2002:a9d:316:: with SMTP id 22mr7238748otv.210.1617883969787; Thu, 08 Apr 2021 05:12:49 -0700 (PDT) MIME-Version: 1.0 References: <20210408092011.52763-1-david@redhat.com> <20210408092011.52763-3-david@redhat.com> <7496ac87-9676-1b4e-3444-c2a662ec376b@redhat.com> <3a2d64a7-8425-8daf-17ee-95b9f0c635f9@redhat.com> In-Reply-To: <3a2d64a7-8425-8daf-17ee-95b9f0c635f9@redhat.com> From: Arnd Bergmann Date: Thu, 8 Apr 2021 14:12:33 +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:Fhq6otmHI4POdFwHt6AOwgyAZRigRhN6pYbDOSuC4J1om7dvrxN 5Ja69gop/zE0tH6oGXFj2WuiEReiKVTdhjARmeZqehRikmeHB1KRTCWyAzVLPZwVHqmj4Jx 6aeO7SDSa6Y9EBsqax8EYS9n8MB67Gl2tRVMhvRKM+Bdy5fkBBIW72BtVuwevJh6orrXC2/ PWGIsjYCGxliLoXtNqRjg== X-UI-Out-Filterresults: notjunk:1;V03:K0:v1yEok7Aps8=:oJGvh1r5lWw1xJfdrq+xlr Ht9WHwiKNTWEOBrNy/4Bgan/MFdgbYC5OvRhWjdWFE8NWDfmSvAsJT0pdJF3P/eVwu2FApR67 4YCuSWZp2QV7APeU1Tqqej/hmGOQ+1TTef8YZQbVU9tVdq1TC6N8iwQQe74z/6EjKJJXcZJZz 81opv8h8QXywWH8nwCVSDi4BFruWpXuK15bVajIssq//NO0WmnQsDuCT9l86UxzF3UPnZNbQx z8ecfWzUimGTm33Xh7b2GpKEKSSnjbvWTl1NKGOrWMBJN12JzGSS1dk7GSNMGsZw81PYj1i/5 NXslN3720iOd/Qg8/A9UQw0QknFagfOI4FMIlzI/fAfnkeW8LBLi3owHrPz4PDoVjWBXetNDd FS7Uai+RV5dsFQSoUbMxyCAx9C0SNi6h3snLzp6ii88+ePyuDjDN8HNm9Qfon4t29xz1GtMo2 1JRBjAzZPks5cebUx+uOwaJYUzlTqnTxg2uMAhp93SPzLhOUky1+nMgP2DtyHLA2Ywt5hrKge ABKjLB2RnIGpsEev7X0TWm+jpwFGfgKMwpUmU/t22vn89iLI/5upVlGcILlCaMjuCGklDmav9 FoIuKO9SXBk3Et8Rj8wEXzbiymI3/iX3wm Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 8, 2021 at 2:00 PM David Hildenbrand wrote: > > On 08.04.21 13:44, Arnd Bergmann wrote: > > On Thu, Apr 8, 2021 at 1:00 PM David Hildenbrand wrote: > >>> > >>> It is a somewhat awkward way to say "prevent this symbol from > >>> being =y if the dependency is =m". > >> > >> What would be the right thing to do in the case here then to achieve the > >> "if DRMA_ASPEED_GFX is enabled, also enable DMA_CMA id possible"? > >> > >> One approach could be to have for DMA_CMA > >> > >> default y if DRMA_ASPEED_GFX > >> > >> but it feels like the wrong way to tackle this. > > > > I'm still not sure what you are trying to achieve. Is the idea only to provide > > a useful default for DMA_CMA depending on which drivers are enabled? > > "Random drivers should not override a user configuration of core knobs > (e.g., CONFIG_DMA_CMA=n)." > > Let's assume I'm a distribution and want to set CONFIG_CMA=n or want to > set CONFIG_DMA_CMA=n with CONFIG_CMA=y; there is no way to do that with > e.g., DRMA_ASPEED_GFX=y because it will always override my (user!) > setting -- even though it doesn't really always need it. Using "select" > is the problem here. I agree on the part of removing the 'select' if we don't need it. The part I couldn't figure out was what the 'imply' is supposed to help with. Most other users that added imply tried (and failed) to fix a build problem. > > This is something you could do using a hidden helper symbol like > > > > config DRMA_ASPEED_GFX > > bool "Aspeed display driver" > > select DRM_WANT_CMA > > > > config DRM_WANT_CMA > > bool > > help > > Select this from any driver that benefits from CMA being enabled > > > > config DMA_CMA > > bool "Use CMA helpers for DRM" > > default DRM_WANT_CMA > > > > Arnd > > > > That's precisely what I had first, with an additional "WANT_CMA" -- but > looking at the number of such existing options (I was able to spot 1 !) > I wondered if there is a better approach to achieve the same; "imply" > sounded like a good candidate. I can probably find a couple more, but regardless of how many others exist, this would be a much clearer way of doing it than 'imply' since it has none of the ambiguity and misuse problems. I think the reason we don't see more is that generally speaking, those defaults are widely ignored anyway. You almost always start out with a defconfig file that contains everything you know you need, and then you add bits to that. Having the default in any form only helps to make that defconfig file one line shorter, while requiring other users to add another line to turn it off when they do not want it. Arnd 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 8DB56C433B4 for ; Thu, 8 Apr 2021 12:12:55 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0223261107 for ; Thu, 8 Apr 2021 12:12:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0223261107 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 6B15A6B0080; Thu, 8 Apr 2021 08:12:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 688E86B0081; Thu, 8 Apr 2021 08:12:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 528988D0001; Thu, 8 Apr 2021 08:12:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 35B166B0080 for ; Thu, 8 Apr 2021 08:12:54 -0400 (EDT) Received: from smtpin38.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id DF01318360DD7 for ; Thu, 8 Apr 2021 12:12:53 +0000 (UTC) X-FDA: 78009088626.38.43307E0 Received: from mout.kundenserver.de (mout.kundenserver.de [217.72.192.73]) by imf06.hostedemail.com (Postfix) with ESMTP id 6CDB8C0007C1 for ; Thu, 8 Apr 2021 12:12:54 +0000 (UTC) Received: from mail-ot1-f49.google.com ([209.85.210.49]) by mrelayeu.kundenserver.de (mreue107 [213.165.67.113]) with ESMTPSA (Nemesis) id 1MvJjz-1lm8ry1w3d-00rKvY for ; Thu, 08 Apr 2021 14:12:51 +0200 Received: by mail-ot1-f49.google.com with SMTP id h6-20020a0568300346b02901b71a850ab4so2033326ote.6 for ; Thu, 08 Apr 2021 05:12:50 -0700 (PDT) X-Gm-Message-State: AOAM533799dOIfN2jxuAslZmAc9yfwbIz/A5RCOVSofRexGECPiJ6uyj EpufRHFnEhU4AKFHRyBDYkvZ3g8+OGpjpazyEp4= X-Google-Smtp-Source: ABdhPJxHyCWMenVUxv33s1E6jvbsFFZTfTMiy2a27GKmZ/Mw2GJW7+vO9jPST57wudsWVl6e6VoT2RKQT0t6kEAsZEE= X-Received: by 2002:a9d:316:: with SMTP id 22mr7238748otv.210.1617883969787; Thu, 08 Apr 2021 05:12:49 -0700 (PDT) MIME-Version: 1.0 References: <20210408092011.52763-1-david@redhat.com> <20210408092011.52763-3-david@redhat.com> <7496ac87-9676-1b4e-3444-c2a662ec376b@redhat.com> <3a2d64a7-8425-8daf-17ee-95b9f0c635f9@redhat.com> In-Reply-To: <3a2d64a7-8425-8daf-17ee-95b9f0c635f9@redhat.com> From: Arnd Bergmann Date: Thu, 8 Apr 2021 14:12:33 +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:N7zjMIYNHT/KcniJFAhQUIJf+VcTrEUs+e0qttMH2icM7PKyhp8 rVv4FTMLZz+UQJrZKJiRkGKHaeK1NuTsATC/F48qB/QFES2+8IkmnUnfmMDjqYhs92tAsw+ KnVnei9+RaT1nc9OouiafjOy3cCIgVvp3nk5gQ39E8uLxgoPiZ/hSun7SgEsrwcZ6dtFyth MhXSu6h/SunrUSu6Yxy7Q== X-UI-Out-Filterresults: notjunk:1;V03:K0:I5wyP7Jjco0=:cQhBT8GbzHu9YzNpUwTQky rq5y6z0M72rqVoKhux3gXP/A3JnGH97wb2++mWSDpVJ80Qa2UM9Lu6nzUOzv7wyVyLN5TBz5u Nf4ylEKr1dkJH/Z5oZEaWzypOcLxQT2gM8H74AMRVRMdbiVx36iyZ4Eg/UdcW4hKdp4/1m7/6 szq+scdkm/TWWDbCEtvClQ6NeZFUxgcCJMstWGvyVcHwZmHlXZzbcLnixoeT0jacGORU0AHMK Zj1wLA4861X2LYgIn0XTLUfD1qt7dz7OdTsE0iCa0lf4IbWD4ZKS/TG/deAXUbba41/64Tsxn UyKmVIQ0vrtnGvgA2MoXBoIquMMXuTlMB8YW/mSh+K4VXth2JaeFh6C89ZrYAXbRstj750ZCu E9iJl8tbD5DcSI7Bb1JSLTCRTBBP/9IpP4/kTCCkKtUPHA9PQ21sETof6oft5IO0bv47lznYL h8FxTzhexoE/IY/78U8JfWUgSRQEeCYGiItA4N0eYZbqgd3xDPMZ/l+6k6r2/by9fLOgIW44S Ciouzok7l0i8nGKVijB+X/ZLv9LZQHwf2VFaP2JL18y39/4luwpQRAWa3DBApKy5eKqCMDawc 56EdcJLdjSNEpCBdljBkms84sNMu8FRkQ3 X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 6CDB8C0007C1 X-Stat-Signature: 9oi9u9sfb8szutnw7unyqtjpgbkzzih5 Received-SPF: none (arndb.de>: No applicable sender policy available) receiver=imf06; identity=mailfrom; envelope-from=""; helo=mout.kundenserver.de; client-ip=217.72.192.73 X-HE-DKIM-Result: none/none X-HE-Tag: 1617883974-485340 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 2:00 PM David Hildenbrand wrote: > > On 08.04.21 13:44, Arnd Bergmann wrote: > > On Thu, Apr 8, 2021 at 1:00 PM David Hildenbrand wrote: > >>> > >>> It is a somewhat awkward way to say "prevent this symbol from > >>> being =y if the dependency is =m". > >> > >> What would be the right thing to do in the case here then to achieve the > >> "if DRMA_ASPEED_GFX is enabled, also enable DMA_CMA id possible"? > >> > >> One approach could be to have for DMA_CMA > >> > >> default y if DRMA_ASPEED_GFX > >> > >> but it feels like the wrong way to tackle this. > > > > I'm still not sure what you are trying to achieve. Is the idea only to provide > > a useful default for DMA_CMA depending on which drivers are enabled? > > "Random drivers should not override a user configuration of core knobs > (e.g., CONFIG_DMA_CMA=n)." > > Let's assume I'm a distribution and want to set CONFIG_CMA=n or want to > set CONFIG_DMA_CMA=n with CONFIG_CMA=y; there is no way to do that with > e.g., DRMA_ASPEED_GFX=y because it will always override my (user!) > setting -- even though it doesn't really always need it. Using "select" > is the problem here. I agree on the part of removing the 'select' if we don't need it. The part I couldn't figure out was what the 'imply' is supposed to help with. Most other users that added imply tried (and failed) to fix a build problem. > > This is something you could do using a hidden helper symbol like > > > > config DRMA_ASPEED_GFX > > bool "Aspeed display driver" > > select DRM_WANT_CMA > > > > config DRM_WANT_CMA > > bool > > help > > Select this from any driver that benefits from CMA being enabled > > > > config DMA_CMA > > bool "Use CMA helpers for DRM" > > default DRM_WANT_CMA > > > > Arnd > > > > That's precisely what I had first, with an additional "WANT_CMA" -- but > looking at the number of such existing options (I was able to spot 1 !) > I wondered if there is a better approach to achieve the same; "imply" > sounded like a good candidate. I can probably find a couple more, but regardless of how many others exist, this would be a much clearer way of doing it than 'imply' since it has none of the ambiguity and misuse problems. I think the reason we don't see more is that generally speaking, those defaults are widely ignored anyway. You almost always start out with a defconfig file that contains everything you know you need, and then you add bits to that. Having the default in any form only helps to make that defconfig file one line shorter, while requiring other users to add another line to turn it off when they do not want it. Arnd 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,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,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 B1BA4C433B4 for ; Thu, 8 Apr 2021 12:14:32 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 2886F610F9 for ; Thu, 8 Apr 2021 12:14:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2886F610F9 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=EyUl8uteoORhAUhaQrTKxPs5h3z76gIXtBK4g1frYrs=; b=fuH4nGwykvADqH9kIplqM1VB6 vAFYnEtlJSiWKO1wU22yEgW7EpXI5PJHP3MuqG1EQCVCXiEbDA3ZQBowyJeh1tETGxL+uPP11/LQw 97pUShFUJ7gvxjNlld1i6PIMU/dbOEi967oR0zbf/+YL7Fbu3AkNfSVIUzWKyo+hDSCQpSV+bXs0G UBd1UwxxuOmfkTvWmPSRwW6AVW2hLOXx4hXyWrkFSq/oidRpMGexyf7xhs+r9syB5nPMOcBzWhtKi 1VFYFykPUHT83F8SfXXL8EV9rND8i8vsXqxiyB6KlLzv4H9A8pFFQW8AZEtqoUSuZogk3wiG6Qzlm NNgufRCSg==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lUTWt-007w9Q-7P; Thu, 08 Apr 2021 12:12:59 +0000 Received: from mout.kundenserver.de ([212.227.126.134]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lUTWn-007w8i-NH for linux-arm-kernel@lists.infradead.org; Thu, 08 Apr 2021 12:12:55 +0000 Received: from mail-ot1-f42.google.com ([209.85.210.42]) by mrelayeu.kundenserver.de (mreue010 [213.165.67.97]) with ESMTPSA (Nemesis) id 1N4yqC-1lbwGt1XYi-010uIy for ; Thu, 08 Apr 2021 14:12:51 +0200 Received: by mail-ot1-f42.google.com with SMTP id t23-20020a0568301e37b02901b65ab30024so2037161otr.4 for ; Thu, 08 Apr 2021 05:12:50 -0700 (PDT) X-Gm-Message-State: AOAM533olVG9Vh52S9YN08KTMjfhroff7oxbA1rhnQdFIxGLSQnMryQe pPVqRMPbXGjOBoL7nwPwEducWI1gbRXYI6TJBPY= X-Google-Smtp-Source: ABdhPJxHyCWMenVUxv33s1E6jvbsFFZTfTMiy2a27GKmZ/Mw2GJW7+vO9jPST57wudsWVl6e6VoT2RKQT0t6kEAsZEE= X-Received: by 2002:a9d:316:: with SMTP id 22mr7238748otv.210.1617883969787; Thu, 08 Apr 2021 05:12:49 -0700 (PDT) MIME-Version: 1.0 References: <20210408092011.52763-1-david@redhat.com> <20210408092011.52763-3-david@redhat.com> <7496ac87-9676-1b4e-3444-c2a662ec376b@redhat.com> <3a2d64a7-8425-8daf-17ee-95b9f0c635f9@redhat.com> In-Reply-To: <3a2d64a7-8425-8daf-17ee-95b9f0c635f9@redhat.com> From: Arnd Bergmann Date: Thu, 8 Apr 2021 14:12:33 +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 X-Provags-ID: V03:K1:oamD++Hs1otYTAtnM0tOJl9LMmYv/V7xc9Ntupp/AcBUsGKf0u3 sZIa+Vn40Cjcsa7+MsJpFaxjbwDtAvHhd6lebjmUhml6dJi05pF7N7OWGtbhCO0sOtxC4QY GWkeB+K0BzkIfeIxdTJuFVaNsjZiFJnVjtAq1LwnWlWwA3Z8FezZe4d2XVm2M3Z03BuWyci p5aEYjr40EOVdUOpBmYnA== X-UI-Out-Filterresults: notjunk:1;V03:K0:iVnTO44Vw3w=:bnRHE+hBDRgvCF8jY4Jy/5 90s8sGtTJmf2XdZIAMJbkcY+/OvuqaeHygCnKS5PqTJbrdyWUF23jzx761PzWZ3+0wCK0Namb BnbnTrGB0cU9ye3AyW/Rt+m6Xxopo5dSPB4x1FfNvBcjzBtIz7HJ0/Aax57/Foo9Sy6rH9HVC hI4zywsPiz7aNchy8hCuTTmt7Q+836VLIfs8G96ckDRhb1VR2mF+hUD5MxA9CZHjQS3iR0xSo 84u8gb2fRdnfNS4AzLmA2ris3+/k2IH89U4p5ynlRWgX3HCGhzZJ4yh3V/fqcYNIoFqwpgaw1 0mdPM22v1qi2xoC3gVhUNyJI5I682rQXe1LnYSEYqMZSkQBIBULr5l9mgRXOK+AjWs8FsL1HP jTCY9nzrELaM1Pz4YXTzRt04j6rmqxZz92wRorL9Ma1+NAjz9aETnzeGhyjHv0EZqytIWbqmq XCN/arKZj/O/NzxOomHUo+RDeKEdOfjD6H9ACWeT1iFuUxhy85WrEMFOyXo3rWzewYC0LxZZI 9P8budc2m+smZvLKJ9a5jFXhW5ajTDfz4PSGO/ygvFfa6oVZ1CUyElOp2FCaYthx7AlqqDF6L k7llIEnAacOSyu6rQ/mFPjGcev8nnP2rDl X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210408_131253_892645_95A8E041 X-CRM114-Status: GOOD ( 36.49 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Apr 8, 2021 at 2:00 PM David Hildenbrand wrote: > > On 08.04.21 13:44, Arnd Bergmann wrote: > > On Thu, Apr 8, 2021 at 1:00 PM David Hildenbrand wrote: > >>> > >>> It is a somewhat awkward way to say "prevent this symbol from > >>> being =y if the dependency is =m". > >> > >> What would be the right thing to do in the case here then to achieve the > >> "if DRMA_ASPEED_GFX is enabled, also enable DMA_CMA id possible"? > >> > >> One approach could be to have for DMA_CMA > >> > >> default y if DRMA_ASPEED_GFX > >> > >> but it feels like the wrong way to tackle this. > > > > I'm still not sure what you are trying to achieve. Is the idea only to provide > > a useful default for DMA_CMA depending on which drivers are enabled? > > "Random drivers should not override a user configuration of core knobs > (e.g., CONFIG_DMA_CMA=n)." > > Let's assume I'm a distribution and want to set CONFIG_CMA=n or want to > set CONFIG_DMA_CMA=n with CONFIG_CMA=y; there is no way to do that with > e.g., DRMA_ASPEED_GFX=y because it will always override my (user!) > setting -- even though it doesn't really always need it. Using "select" > is the problem here. I agree on the part of removing the 'select' if we don't need it. The part I couldn't figure out was what the 'imply' is supposed to help with. Most other users that added imply tried (and failed) to fix a build problem. > > This is something you could do using a hidden helper symbol like > > > > config DRMA_ASPEED_GFX > > bool "Aspeed display driver" > > select DRM_WANT_CMA > > > > config DRM_WANT_CMA > > bool > > help > > Select this from any driver that benefits from CMA being enabled > > > > config DMA_CMA > > bool "Use CMA helpers for DRM" > > default DRM_WANT_CMA > > > > Arnd > > > > That's precisely what I had first, with an additional "WANT_CMA" -- but > looking at the number of such existing options (I was able to spot 1 !) > I wondered if there is a better approach to achieve the same; "imply" > sounded like a good candidate. I can probably find a couple more, but regardless of how many others exist, this would be a much clearer way of doing it than 'imply' since it has none of the ambiguity and misuse problems. I think the reason we don't see more is that generally speaking, those defaults are widely ignored anyway. You almost always start out with a defconfig file that contains everything you know you need, and then you add bits to that. Having the default in any form only helps to make that defconfig file one line shorter, while requiring other users to add another line to turn it off when they do not want it. Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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 0CB79C433B4 for ; Thu, 8 Apr 2021 12:25:37 +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 9D48D61159 for ; Thu, 8 Apr 2021 12:25:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9D48D61159 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 9F57B6EAC3; Thu, 8 Apr 2021 12:25:35 +0000 (UTC) X-Greylist: delayed 456 seconds by postgrey-1.36 at gabe; Thu, 08 Apr 2021 12:25:33 UTC Received: from mout.kundenserver.de (mout.kundenserver.de [217.72.192.75]) by gabe.freedesktop.org (Postfix) with ESMTPS id B3B896E1B2; Thu, 8 Apr 2021 12:25:33 +0000 (UTC) Received: from mail-ot1-f42.google.com ([209.85.210.42]) by mrelayeu.kundenserver.de (mreue108 [213.165.67.113]) with ESMTPSA (Nemesis) id 1MulyX-1lladc1QI7-00rpz6; Thu, 08 Apr 2021 14:12:51 +0200 Received: by mail-ot1-f42.google.com with SMTP id c24-20020a9d6c980000b02902662e210895so2017058otr.9; Thu, 08 Apr 2021 05:12:50 -0700 (PDT) X-Gm-Message-State: AOAM532qlZZWe1mBt6a7FxbK4io7+EqHh7e+YVSHFXbr1nPyCWZzXZGW mJL306AQ5CCD1C39qWH7iZxAtwOo5O8wG3vEBeg= X-Google-Smtp-Source: ABdhPJxHyCWMenVUxv33s1E6jvbsFFZTfTMiy2a27GKmZ/Mw2GJW7+vO9jPST57wudsWVl6e6VoT2RKQT0t6kEAsZEE= X-Received: by 2002:a9d:316:: with SMTP id 22mr7238748otv.210.1617883969787; Thu, 08 Apr 2021 05:12:49 -0700 (PDT) MIME-Version: 1.0 References: <20210408092011.52763-1-david@redhat.com> <20210408092011.52763-3-david@redhat.com> <7496ac87-9676-1b4e-3444-c2a662ec376b@redhat.com> <3a2d64a7-8425-8daf-17ee-95b9f0c635f9@redhat.com> In-Reply-To: <3a2d64a7-8425-8daf-17ee-95b9f0c635f9@redhat.com> From: Arnd Bergmann Date: Thu, 8 Apr 2021 14:12:33 +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 X-Provags-ID: V03:K1:PO5cu5spogXk5DGrkbNGI8rtRE+z3P3iPSU4K20G+j8HMUSvjkj 8nVfXV8EZZnAETqr7lWSSCxtKRj4ZU7QtcH78hdY2tUH9tfiM0j2dR4PEqvjR/KuocV8PDG j0TC1fifFSW7y9CmLycAD3ViHKfq49KEVoOlywOMtuJcfA8kyw+nEHXvMJx0Dm+d5031vGE Z7UBAvtOctqirH2coydqg== X-UI-Out-Filterresults: notjunk:1;V03:K0:BzYbHMwt0Jg=:oyv+qLTYRqlbCqFvDMwVxp Q55KvxQpTxFEouR6tVSH/11soLZXwP6hAnaTNM4Wq4wsIRH8sSeoHX6KOtWbHmIQxqzBBZh/0 2AjU8A6sabtdVp7rv/JqQUZs9TarYKUMLxQLtlHMMjRsNiKdUIqCq239zebDhZgkp1stdcFl/ PZmsg01NiQ3jqP5I01Jyg+57aHccStCgobHNdXSjpPj0WJ6DIKYoSaboiqXTZ+e6RxgdfP+uY AhAm1J0DywVaefivbGbLjnZteZDrhjFI32l3emTP8rqpH8O1LP+QqgmNOCUUI28vOty5cj01A YWgCdQt+tPNNDchXpZmfT2HXku5gTTWgHmGHdW1bLTCHln6cJd1WcHjk/dvNZxFQRtTviNi6z uzHV7TD5nXfOvbHCzXs1eQT64BuuKygVjU+THjsRGKqZmuxKORRU7Wt7KT2HhSHH2S7LeF3ga VhIJ3TprL63c1yq2ZGI/ZS1anYGS+OpSmEcCSR6nChPBK6Gloyik48HgXCABDcr2ckTWtev68 IMueShW8SjsuYbU7JlEM4LrQFyVTmj1QZcoqnv0Wv3t7H76BuB+ieBLKv0pdmp7H8jxH2gonS zdWZkgHdywCy18n0+3po0tkcSR1Z6sjVJB 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: Linux ARM , Linux Fbdev development list , linux-aspeed , Bartlomiej Zolnierkiewicz , David Airlie , Andrew Jeffery , Randy Dunlap , The etnaviv authors , Linux Kernel Mailing List , dri-devel , Michal Simek , Linux-MM , Joel Stanley , Russell King , Peter Collingbourne , Masahiro Yamada , Mike Rapoport 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 8, 2021 at 2:00 PM David Hildenbrand wrote: > > On 08.04.21 13:44, Arnd Bergmann wrote: > > On Thu, Apr 8, 2021 at 1:00 PM David Hildenbrand wrote: > >>> > >>> It is a somewhat awkward way to say "prevent this symbol from > >>> being =y if the dependency is =m". > >> > >> What would be the right thing to do in the case here then to achieve the > >> "if DRMA_ASPEED_GFX is enabled, also enable DMA_CMA id possible"? > >> > >> One approach could be to have for DMA_CMA > >> > >> default y if DRMA_ASPEED_GFX > >> > >> but it feels like the wrong way to tackle this. > > > > I'm still not sure what you are trying to achieve. Is the idea only to provide > > a useful default for DMA_CMA depending on which drivers are enabled? > > "Random drivers should not override a user configuration of core knobs > (e.g., CONFIG_DMA_CMA=n)." > > Let's assume I'm a distribution and want to set CONFIG_CMA=n or want to > set CONFIG_DMA_CMA=n with CONFIG_CMA=y; there is no way to do that with > e.g., DRMA_ASPEED_GFX=y because it will always override my (user!) > setting -- even though it doesn't really always need it. Using "select" > is the problem here. I agree on the part of removing the 'select' if we don't need it. The part I couldn't figure out was what the 'imply' is supposed to help with. Most other users that added imply tried (and failed) to fix a build problem. > > This is something you could do using a hidden helper symbol like > > > > config DRMA_ASPEED_GFX > > bool "Aspeed display driver" > > select DRM_WANT_CMA > > > > config DRM_WANT_CMA > > bool > > help > > Select this from any driver that benefits from CMA being enabled > > > > config DMA_CMA > > bool "Use CMA helpers for DRM" > > default DRM_WANT_CMA > > > > Arnd > > > > That's precisely what I had first, with an additional "WANT_CMA" -- but > looking at the number of such existing options (I was able to spot 1 !) > I wondered if there is a better approach to achieve the same; "imply" > sounded like a good candidate. I can probably find a couple more, but regardless of how many others exist, this would be a much clearer way of doing it than 'imply' since it has none of the ambiguity and misuse problems. I think the reason we don't see more is that generally speaking, those defaults are widely ignored anyway. You almost always start out with a defconfig file that contains everything you know you need, and then you add bits to that. Having the default in any form only helps to make that defconfig file one line shorter, while requiring other users to add another line to turn it off when they do not want it. Arnd _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel