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.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 5D7D2C43603 for ; Tue, 17 Dec 2019 15:49:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2BC2A24655 for ; Tue, 17 Dec 2019 15:49:40 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="ZD9Px2de" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727572AbfLQPtj (ORCPT ); Tue, 17 Dec 2019 10:49:39 -0500 Received: from mail-pg1-f195.google.com ([209.85.215.195]:47064 "EHLO mail-pg1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726858AbfLQPtj (ORCPT ); Tue, 17 Dec 2019 10:49:39 -0500 Received: by mail-pg1-f195.google.com with SMTP id z124so5872258pgb.13; Tue, 17 Dec 2019 07:49:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0bppgrIeedrGmyWxXyk9G+dVbYZCgNhYwm2U7ZZ9wCI=; b=ZD9Px2deC+SHCKG9ben+v59xHHrWyaFrSLjtTdXYD5Cu8Xp4QbtXWV60beYRhfIxp2 proVUwu7FUIenM8UkMOb66K3mp5e2IlEjIh3o4UQU/7qLZi964kgmRv7C8Yc7jO/BLAx 0UC1hce8XrR9qFX8lR4LhjtjQ30PwNQAUIRQfN5eOQ4CB6bHx+5aD2YS9QR4k6UQYNj7 0fMuf+B/yhF/Yk0m1tvcHlE6eNfRMCsIGiQInA+AXiTmdHKL4JZ+WZ4qAJCuU45+mR7h 8iJ2j63ebfeMOxN26mqPIRBXcqafsWL3YgTQP8nmoXUMtbNRjX9igbksCTH45EuBkLwd oQrw== 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=0bppgrIeedrGmyWxXyk9G+dVbYZCgNhYwm2U7ZZ9wCI=; b=KDx6r1Hulh7KqNlAt0CU9SfPMpLaIW5G6+VdmjKt7f4xO0ws8BqShABVyPTc0j1cuQ ASQIX/iC9Aqnx5UV1tIeeN2Z2gRnrFamLm+fux1pqtnz4zHvpzQ+yHQb03e6NY7DaebI FfS2dZ1FrOyT9txOBDjjTi9Uq01TcQFdreBQn8ehc3CYr+y+IJgNPjDvLILkISOVjzfJ bn3sEWpDPuabyjezQ89EdFuGmihtWCbAZFoeXhryCquhpvM42F2IAjX1CGjeYHPk08hI Enwq+PeMq2B1EzAbIw2HcRHIg0dU9LhgulXPu/MUuaXlNWMVsWX98ZIKU1SBi30YhjpN aYqQ== X-Gm-Message-State: APjAAAXFRWmcmTNIUBYFSy5PAwynTtdwwkXFbTgXH3pj/GBLpOy7PxHL rR1S1Ery+YeCcCN841rgWOl04W7rkqXwT6lWUpw= X-Google-Smtp-Source: APXvYqxhFVyocJZP/Fex0nME1DxI3VWvcXcmcx2qeijL59/bQ3PzHYDrqfQ8F28lrvEGowIJEQutCUYuXH5Nq9a2Pxc= X-Received: by 2002:a62:1a09:: with SMTP id a9mr23011227pfa.64.1576597778583; Tue, 17 Dec 2019 07:49:38 -0800 (PST) MIME-Version: 1.0 References: <20191216162209.5b5256dd@canb.auug.org.au> <20191217054255.GA26868@ravnborg.org> <65c9dc7b-3c61-8204-07da-212632732791@infradead.org> <87d0cnynst.fsf@intel.com> In-Reply-To: <87d0cnynst.fsf@intel.com> From: Andy Shevchenko Date: Tue, 17 Dec 2019 17:49:28 +0200 Message-ID: Subject: Re: [Intel-gfx] linux-next: Tree for Dec 16 (drm_panel & intel_panel) To: Jani Nikula Cc: Steven Price , Stephen Rothwell , intel-gfx , Randy Dunlap , Linux Kernel Mailing List , dri-devel , Linux Next Mailing List , Sam Ravnborg , Lee Jones , Daniel Thompson , Jingoo Han Content-Type: text/plain; charset="UTF-8" Sender: linux-next-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-next@vger.kernel.org On Tue, Dec 17, 2019 at 5:28 PM Jani Nikula wrote: > On Tue, 17 Dec 2019, Andy Shevchenko wrote: > > On Tue, Dec 17, 2019 at 1:56 PM Steven Price wrote: > > I think the proper one is to have s/IS_ENABLED/IS_REACHABLE/. > > It fixes issue for me. > > As discussed off-line, this will allow silently building and linking a > configuration that's actually broken. (No backlight support despite > expectations.) In my case I have deliberately compile backlight as a module to be used exclusively with backlight-gpio which has nothing to do with i915. I dunno if backlight is a MUST dependency for i915. >From my perspective the original commit, with all good that it provides, should not break previously working configurations. Though we might argue if my "working" kernel configuration had been broken in the first place... Just my 2 cents, though. > IMO deep down the problem is that we "select" BACKLIGHT_CLASS_DEVICE all > over the place, while we should "depends on" it. Everything else is just > duct tape that allows configurations where built-in code calls backlight > symbols in modules. It used to be more about an interaction with ACPI, > now we've added DRM_PANEL to the mix. > > I've proposed a fix five years ago [1]. That's what it takes to fix > these recurring failures for good. I'm not really all that interested in > the whack-a-mole with the hacks. Agree with this. The root cause must be fixed once and for all. I guess it should be a logical continuation of Sam's series. > [1] http://lore.kernel.org/r/1413580403-16225-1-git-send-email-jani.nikula@intel.com -- With Best Regards, Andy Shevchenko