Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp883906pxb; Wed, 27 Oct 2021 14:26:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwkbKCkeb7uDrsGN0QSEkZNdcZ59kFlcarQn/dLdIyT4TQkcN7er0xH1LZMf4f1qo8X9gim X-Received: by 2002:aa7:cb0a:: with SMTP id s10mr416160edt.289.1635369964993; Wed, 27 Oct 2021 14:26:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635369964; cv=none; d=google.com; s=arc-20160816; b=BB66BXRWa5mXJ/ctgEeTEX1v/5yIwGVNmkphEIE4YW5GmpJ+KtI6tSUuN25J6DL4aT Mlhc80TD+JVraWU8M3zXAqgFxprvcgwhxbpImFQaCg49QWtg+eVHKlPdchUcGsTo0oZc TV0KttqLt7L4hihN5qqeEkPNuuYqiLTA1RMXYtbZ+R+TB74KJV8xkQw461f+S6mekrnB v/B7nzItpsecLKAhlezvbVThAP3+2Itn8HPaq65w0iGUt8f4XUB3P8cpWPJ3/UMz7HaM uoxtZkGZNuRsvTM9JO/HFnVe+enZKURyRk3hmpWkFeDpl9XuUOPwMI73Qcv3u4Oxefbl 0hXA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :organization:in-reply-to:subject:cc:to:from; bh=sxRJBHU+mSn45qKQ03h4iknhD6q2Hxm/z8r4WkYf6wI=; b=dMMqOwPkWSoNZYENQVUh5d/JRvxpuGIFfn4rjmWs0u6RPbZmx/qu4v01NtgCSOrkP5 P9Z7nocnhMMubKa4/00WRz08XGKZJf494ZcDncop8EKrCO4PNhPayytB+wo+ikKCYJr6 bdUx70xc57yzIuSlBJPPH+dnpedIpoYZAQJ3SAGj2evwvv+CYRpq2Bt/oS8eYHuQln8m g4kVsug3pgpHQjYfZUXkiQadMnTbdWdn11XxmUwgnb9Zng5KjZjNsYyX//JftHHfkQQV 7zUKko82OshoD+gLmE9YCirUpxvXYCJea3roZOrBMNvTN/GwLehYm4IzMruYQ3ResZAA f3Vw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y7si1901190eda.624.2021.10.27.14.25.42; Wed, 27 Oct 2021 14:26:04 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236323AbhJ0NJg (ORCPT + 97 others); Wed, 27 Oct 2021 09:09:36 -0400 Received: from mga03.intel.com ([134.134.136.65]:28690 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235246AbhJ0NJg (ORCPT ); Wed, 27 Oct 2021 09:09:36 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10149"; a="230102611" X-IronPort-AV: E=Sophos;i="5.87,186,1631602800"; d="scan'208";a="230102611" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Oct 2021 06:06:50 -0700 X-IronPort-AV: E=Sophos;i="5.87,186,1631602800"; d="scan'208";a="497857989" Received: from smaharan-mobl.gar.corp.intel.com (HELO localhost) ([10.251.214.195]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Oct 2021 06:06:46 -0700 From: Jani Nikula To: Arnd Bergmann , Javier Martinez Canillas Cc: Daniel Vetter , Kees Cook , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Arnd Bergmann , Alex Deucher , Christian =?utf-8?Q?K=C3=B6nig?= , dri-devel , Linux Kernel Mailing List Subject: Re: [PATCH] [RESEND] drm: fb_helper: fix CONFIG_FB dependency In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <20210927142816.2069269-1-arnd@kernel.org> <202109270923.97AFDE89DB@keescook> <878ryeit9i.fsf@intel.com> <3604fb90-f6c3-0fa2-c864-7f1795caee1e@redhat.com> Date: Wed, 27 Oct 2021 16:06:44 +0300 Message-ID: <87tuh2hb17.fsf@intel.com> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 27 Oct 2021, Arnd Bergmann wrote: > On Wed, Oct 27, 2021 at 2:38 PM Javier Martinez Canillas > wrote: >> > >> > This is something we can't easily express in Kconfig, as we can't add the >> > dependency to a symbol that only gets selected by other drivers, which >> > is why the dependency has to be in the user-visible symbol, >> > in this case DRM_FBDEV_EMULATION. >> > >> >> Why the dependency has to be in a user-visible symbol? What could be the >> problem with having something like: >> >> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig >> index cea777ae7fb9..f80b404946ca 100644 >> --- a/drivers/gpu/drm/Kconfig >> +++ b/drivers/gpu/drm/Kconfig >> @@ -82,6 +82,7 @@ config DRM_DEBUG_SELFTEST >> config DRM_KMS_HELPER >> tristate >> depends on DRM >> + depends on (DRM_FBDEV_EMULATION && FB) || !DRM_FBDEV_EMULATION >> help >> CRTC helpers for KMS drivers. >> >> @@ -104,7 +105,6 @@ config DRM_FBDEV_EMULATION >> bool "Enable legacy fbdev support for your modesetting driver" >> depends on DRM >> depends on FB >> - select DRM_KMS_HELPER >> select FB_CFB_FILLRECT >> select FB_CFB_COPYAREA >> select FB_CFB_IMAGEBLIT > > This fails because of all the other drivers that try to 'select DRM_KMS_HELPER'. > Kconfig will now complain about a symbol that gets selected while its > dependencies > are not met. > > To work around that, every single driver that has 'selects DRM_KMS_HELPER' would > now have to also list 'depends on (DRM_FBDEV_EMULATION && FB) || > !DRM_FBDEV_EMULATION'. So the fix would be that nobody selects DRM_KMS_HELPER... BR, Jani. > > Arnd -- Jani Nikula, Intel Open Source Graphics Center