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.5 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, 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 DEB09C2BA2B for ; Thu, 16 Apr 2020 06:51:27 +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 AE62F2087E for ; Thu, 16 Apr 2020 06:51:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="JHwymh36" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AE62F2087E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch 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 2557B6EAC5; Thu, 16 Apr 2020 06:51:27 +0000 (UTC) Received: from mail-oi1-x241.google.com (mail-oi1-x241.google.com [IPv6:2607:f8b0:4864:20::241]) by gabe.freedesktop.org (Postfix) with ESMTPS id 552296EAC5 for ; Thu, 16 Apr 2020 06:51:26 +0000 (UTC) Received: by mail-oi1-x241.google.com with SMTP id j16so15771712oih.10 for ; Wed, 15 Apr 2020 23:51:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pLZEHboHrVUvSiMzAU5mB2mWJMs+hZ8IHC8retFcrgk=; b=JHwymh36ehjFDNDrb8YuMyQ1MkWFaqFQka5rlpHvpOpNowJkEQBJjUJHh6tEn9ItJf 44VDASM1Nm9+28OJ0BhPDfmpGS7h0JIyE4ei3cCTN1kvXMsSEqE7hJ6ugWHQLwwsjP4k SXfyV81W2EeHu0cLCfENisqsTzpcXqPmUQBbg= 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=pLZEHboHrVUvSiMzAU5mB2mWJMs+hZ8IHC8retFcrgk=; b=GuKwQgebcI6xigr4Ff2WNYyL0PnTnXX1M3vZ0PsZIufSwHOveQihU6FbZAyfiJXfHu 79Eop2bPwJeOpUGeVLMvvzBzP3oGxOgXIROcD+/D2qatyQKKOg4h/w4D/ueMCM27Fi3+ Tr9Ng1EZuqVzOJMbXbpvCRTYQLE0ocQdpqpwKFpHzHF16bXKwSkNdOV45Y9lwUkGS3Dx 2hZAE9gFe4hxAjpT7dyTunnfT8kwc/BZwZmkN6smApOhKYAmcHMF3tHCzwZ0/VavxZNz LEEeQFkKLjQ1WkIR3WG4VhyfpfjQ4uNc2LONyqeaW3Q65MZTtZlgmHUC3gaa3+EQ244W y8rA== X-Gm-Message-State: AGi0Pua9LUzroRRea+NSteUdQnTrpLoTsMWf/VPy4qyQ5HLbG2FjfsoC 4eXlu5qBF7j4uamtNInJoOhTVaiB6OrrB+Cc6YAGIw== X-Google-Smtp-Source: APiQypLyNc+eIs12WumzaBN5ipx1548wfPjx2IqBdj2oxsFx0exWa6GdqAAPbqs2svHCYqkW3eZbfQLmptUx4Q5ixiM= X-Received: by 2002:aca:2113:: with SMTP id 19mr2018002oiz.128.1587019885629; Wed, 15 Apr 2020 23:51:25 -0700 (PDT) MIME-Version: 1.0 References: <20200408202711.1198966-1-arnd@arndb.de> <20200408202711.1198966-6-arnd@arndb.de> <20200414201739.GJ19819@pendragon.ideasonboard.com> <20200414205158.GM19819@pendragon.ideasonboard.com> <20200415211220.GQ4758@pendragon.ideasonboard.com> In-Reply-To: From: Daniel Vetter Date: Thu, 16 Apr 2020 08:51:14 +0200 Message-ID: Subject: Re: [RFC 5/6] drm/rcar-du: fix selection of CMM driver To: Arnd Bergmann 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: Jernej Skrabec , Leon Romanovsky , Nicolas Pitre , David Airlie , Networking , Masahiro Yamada , Neil Armstrong , Saeed Mahameed , "linux-kernel@vger.kernel.org" , dri-devel , Linux-Renesas , Andrzej Hajda , Jonas Karlman , Kieran Bingham , Geert Uytterhoeven , Laurent Pinchart , "David S. Miller" , linux-rdma Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Wed, Apr 15, 2020 at 11:22 PM Arnd Bergmann wrote: > > On Wed, Apr 15, 2020 at 11:12 PM Laurent Pinchart > wrote: > > On Wed, Apr 15, 2020 at 09:07:14PM +0200, Arnd Bergmann wrote: > > > On Wed, Apr 15, 2020 at 5:18 PM Arnd Bergmann wrote: > > > > On Wed, Apr 15, 2020 at 4:13 PM Geert Uytterhoeven wrote: > > > > > On Wed, Apr 15, 2020 at 3:47 PM Arnd Bergmann wrote: > > > > > > On Tue, Apr 14, 2020 at 10:52 PM Laurent Pinchart wrote: > > > > > > > Doesn't "imply" mean it gets selected by default but can be manually > > > > > > > disabled ? > > > > > > > > > > > > That may be what it means now (I still don't understand how it's defined > > > > > > as of v5.7-rc1), but traditionally it was more like a 'select if all > > > > > > dependencies are met'. > > > > > > > > > > That's still what it is supposed to mean right now ;-) > > > > > Except that now it should correctly handle the modular case, too. > > > > > > > > Then there is a bug. If I run 'make menuconfig' now on a mainline kernel > > > > and enable CONFIG_DRM_RCAR_DU, I can set > > > > DRM_RCAR_CMM and DRM_RCAR_LVDS to 'y', 'n' or 'm' regardless > > > > of whether CONFIG_DRM_RCAR_DU is 'm' or 'y'. The 'implies' > > > > statement seems to be ignored entirely, except as reverse 'default' > > > > setting. > > > > > > Here is another version that should do what we want and is only > > > half-ugly. I can send that as a proper patch if it passes my testing > > > and nobody hates it too much. > > > > This may be a stupid question, but doesn't this really call for fixing > > Kconfig ? This seems to be such a common pattern that requiring > > constructs similar to the ones below will be a never-ending chase of > > offenders. > > Maybe, I suppose the hardest part here would be to come up with > an appropriate name for the keyword ;-) > > Any suggestions? > > This specific issue is fairly rare though, in most cases the dependencies > are in the right order so a Kconfig symbol 'depends on' a second one > when the corresponding loadable module uses symbols from that second > module. The problem here is that the two are mixed up. > > The much more common problem is the one where one needs to > wrong > > config FOO > depends on BAR || !BAR > > To ensure the dependency is either met or BAR is disabled, but > not FOO=y with BAR=m. If you have any suggestions for a keyword > for that thing, we can clean up hundreds of such instances. Some ideas: config FOO can use BAR maybe BAR optional BAR We should probably double-check that this is only ever used for when both FOO and BAR are tri-state, since without that it doesn't make much sense. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel