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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 02267C433F5 for ; Wed, 27 Oct 2021 13:26:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id DBC8860041 for ; Wed, 27 Oct 2021 13:26:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242130AbhJ0N20 (ORCPT ); Wed, 27 Oct 2021 09:28:26 -0400 Received: from mail.kernel.org ([198.145.29.99]:54990 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229585AbhJ0N2W (ORCPT ); Wed, 27 Oct 2021 09:28:22 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 122C460041 for ; Wed, 27 Oct 2021 13:25:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1635341157; bh=DRpvfgGLpwYbFsAv9yOUJyHOhSz2wXFNo6XVbHhRxJ0=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=Ymw0mh2QQY60jm8+Gnw47dKypKUt0vp+Hrwbe+lvi7IvM9xPkr7HMHZUAES5inqA4 XbofBsLNudDsE3y0LF7jVZQnA7x/bKsIgNvNbHyE0tB+cKLNZ4gWXNdOoeaUchaIOB vyuzgfgeciZ3PYuWgewDXi8SeYO1WyBMFcwscHNHvafk7qIPbrVu4fHunL4upzgXR+ UvXhyAzscA9C/OTv27InGyFGgfSL2XGuY8YQ6yeY/Ekfllk/q1JJmZShivCEXPurEP /iT9NqSeS3OBfhwgrEc0l76EUFIw7518/kJJWCb4gJqETWUburbQQ6H5lvKz9XRHC6 6gpn/duVDWJRQ== Received: by mail-wr1-f47.google.com with SMTP id d3so4151216wrh.8 for ; Wed, 27 Oct 2021 06:25:56 -0700 (PDT) X-Gm-Message-State: AOAM532xEHDQhgAHT4f3u7VtkpTi1kfq+aYB5H8AjPuYOrJetW+ldsHJ 4B2RDCNULTrjDa7gNLxHWgFhDXkYcN1ttoDCvHo= X-Google-Smtp-Source: ABdhPJzZ/yYljL8fOUgPtoPN2mhzZdD5s1jNGK4CxGyNcQokOv7BNnyqQrxKssWuwuOwTp5bj3HmRZiUoB0GktTIEHg= X-Received: by 2002:a05:6000:18c7:: with SMTP id w7mr39409910wrq.411.1635341155532; Wed, 27 Oct 2021 06:25:55 -0700 (PDT) MIME-Version: 1.0 References: <20210927142816.2069269-1-arnd@kernel.org> <202109270923.97AFDE89DB@keescook> <878ryeit9i.fsf@intel.com> <3604fb90-f6c3-0fa2-c864-7f1795caee1e@redhat.com> <87tuh2hb17.fsf@intel.com> In-Reply-To: <87tuh2hb17.fsf@intel.com> From: Arnd Bergmann Date: Wed, 27 Oct 2021 15:25:38 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] [RESEND] drm: fb_helper: fix CONFIG_FB dependency To: Jani Nikula Cc: Javier Martinez Canillas , Daniel Vetter , Kees Cook , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Arnd Bergmann , Alex Deucher , =?UTF-8?Q?Christian_K=C3=B6nig?= , dri-devel , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 27, 2021 at 3:06 PM Jani Nikula wrote: > On Wed, 27 Oct 2021, Arnd Bergmann wrote: > > 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... That's not going to help in this case, the way the helper functions work is that you select them as needed, and you avoid the other dependencies. This part works fine. We could probably get rid of this symbol by just making it an unconditional part of drm.ko, as almost every driver ends up using it anyway. Arguably, this would make the end result worse, as you'd again get drm.ko itself to link against the old framebuffer code. What I'm not sure about is whether drivers/video/fbdev/core/fb.ko could be split up into smaller parts so DRM_FBDEV_EMULATION could only depend on a set of common code without the bits that are needed for the classic fbdev drivers. Arnd