From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jani Nikula Date: Mon, 20 Apr 2020 08:14:02 +0000 Subject: Re: [PATCH 0/8] drm, fbdev: rework dependencies Message-Id: <87y2qq1smt.fsf@intel.com> List-Id: References: <20200417155553.675905-1-arnd@arndb.de> <20200417171453.GS3456981@phenom.ffwll.local> <20200417190854.GI26002@ziepe.ca> In-Reply-To: <20200417190854.GI26002@ziepe.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Jason Gunthorpe , Daniel Vetter Cc: marex@denx.de, linux-fbdev@vger.kernel.org, dsd@laptop.org, Arnd Bergmann , Saeed Mahameed , airlied@linux.ie, masahiroy@kernel.org, Nicolas Pitre , thellstrom@vmware.com, dri-devel@lists.freedesktop.org, geert@linux-m68k.org, linux-renesas-soc@vger.kernel.org, Andrzej Hajda , kieran.bingham+renesas@ideasonboard.com, linux-graphics-maintainer@vmware.com, Laurent.pinchart@ideasonboard.com, haojian.zhuang@gmail.com, jfrederich@gmail.com, robert.jarzmik@free.fr, daniel@zonque.org On Fri, 17 Apr 2020, Jason Gunthorpe wrote: > On Fri, Apr 17, 2020 at 07:14:53PM +0200, Daniel Vetter wrote: >> On Fri, Apr 17, 2020 at 05:55:45PM +0200, Arnd Bergmann wrote: >> > I tried to fix up some dependencies after the sii8620 "imply EXTCON" >> > statementn broke, trying a few things but in the backing out a >> > change that would completely reverse the LEDS_CLASS selects into >> > a 'depends on'. >> > >> > However, what I got now are multiple changes that remove gratious >> > "selects" that lead to circular dependencies for sii8620 and others: >> > >> > - Anything doing "select FB" is now gone, or becomes "depends on FB", >> > >> > - DDC support depends on I2C instead of selecting it >> > >> > - backlight class device support is never selected by framebuffer >> > drivers but has proper dependencies >> > >> > I have done thousands of randconfig build tests on this, but no >> > runtime tests. >> > >> > Some of the 'depends on FOO || !FOO' statements could be simplified >> > into a new 'uses FOO' syntax based on a patch from Saeed Mahameed, >> > but I would for the moment treat that as a cleanup that can be done >> > later. >> > >> > If we can agree on these changes, maybe someone can merge them >> > through the drm-misc tree. >> > >> > Please review >> >> Biggest concern I have is that usability of make menuconfig is horrible, >> and it's very hard to find options that are hidden by depends on. You can >> use the search interface, if you happen to know the option. >> >> Once you've surmounted that bar, the next one is trying to find what >> exactly you need to enable. Which again means endless of recursive >> screaming at Kconfig files, since make menuconfig doesn't help you at all. > > +1 on this. But this is a general kconfig problem, and not unique to > DRM, I've done this screaming for many different things now.. eg to > turn on every single RDMA driver. > > I hackily delt with it by creating this rather insane script based on > the python kconfiglib to try and sort things out mostly automatically: > > https://github.com/jgunthorpe/Kernel-Maintainer-Tools/blob/master/gj_tools/cmd_kconfig.py > > It would be great if menuconfig had a key to say 'hey, really, turn > this on and everything it depends on, recursively' I'm really all for switching to using depends when that is the semantically right thing to do. In many places using select is a hack to make the UI simpler, and that's just plain wrong. We'll be doomed to perpetual randconfig build failures and duct tape fixes. I'm pretty tired of this, and I regularly ignore those duct tape fixes to i915 backlight build issues on some bizarre configs that nobody will ever use, and would not exist if depends were used throughout. I'm fine with select but only when it's restricted to symbols that have no dependencies of their own and have no UI. This is in line with Documentation/kbuild/kconfig-language.rst. Not enforcing this is another Kconfig tool shortcoming. See also my reply to Sam [1]. BR, Jani. [1] https://lore.kernel.org/dri-devel/871roi37qe.fsf@intel.com/ -- Jani Nikula, Intel Open Source Graphics Center 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=-5.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS autolearn=ham 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 85C90C3A5A0 for ; Mon, 20 Apr 2020 08:14:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 68D32218AC for ; Mon, 20 Apr 2020 08:14:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726262AbgDTIOP (ORCPT ); Mon, 20 Apr 2020 04:14:15 -0400 Received: from mga11.intel.com ([192.55.52.93]:51570 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726200AbgDTION (ORCPT ); Mon, 20 Apr 2020 04:14:13 -0400 IronPort-SDR: uyGw6ozG7EF01H2yT+BKAJLWcQpA0dM+s347lXYgIi7fkCsgPSbXt1LBYsMWpcRaczlfQXDPOi qakC0amIpUaw== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Apr 2020 01:14:13 -0700 IronPort-SDR: GQi+lZ63AuQCCQCozaTBET02e0q31aTNZ8Mhwo8nHFR6eJJau/IulOjjXySYruUpzlKYn8Glfu dahNvYB8YH7A== X-IronPort-AV: E=Sophos;i="5.72,406,1580803200"; d="scan'208";a="429039579" Received: from iastakh-mobl.ccr.corp.intel.com (HELO localhost) ([10.252.63.229]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Apr 2020 01:14:05 -0700 From: Jani Nikula To: Jason Gunthorpe , Daniel Vetter Cc: Arnd Bergmann , dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org, Nicolas Pitre , Andrzej Hajda , Saeed Mahameed , masahiroy@kernel.org, Laurent.pinchart@ideasonboard.com, linux-renesas-soc@vger.kernel.org, kieran.bingham+renesas@ideasonboard.com, airlied@linux.ie, daniel@zonque.org, haojian.zhuang@gmail.com, robert.jarzmik@free.fr, marex@denx.de, stefan@agner.ch, linux-graphics-maintainer@vmware.com, thellstrom@vmware.com, jfrederich@gmail.com, dsd@laptop.org, geert@linux-m68k.org Subject: Re: [PATCH 0/8] drm, fbdev: rework dependencies In-Reply-To: <20200417190854.GI26002@ziepe.ca> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <20200417155553.675905-1-arnd@arndb.de> <20200417171453.GS3456981@phenom.ffwll.local> <20200417190854.GI26002@ziepe.ca> Date: Mon, 20 Apr 2020 11:14:02 +0300 Message-ID: <87y2qq1smt.fsf@intel.com> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-renesas-soc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-renesas-soc@vger.kernel.org On Fri, 17 Apr 2020, Jason Gunthorpe wrote: > On Fri, Apr 17, 2020 at 07:14:53PM +0200, Daniel Vetter wrote: >> On Fri, Apr 17, 2020 at 05:55:45PM +0200, Arnd Bergmann wrote: >> > I tried to fix up some dependencies after the sii8620 "imply EXTCON" >> > statementn broke, trying a few things but in the backing out a >> > change that would completely reverse the LEDS_CLASS selects into >> > a 'depends on'. >> > >> > However, what I got now are multiple changes that remove gratious >> > "selects" that lead to circular dependencies for sii8620 and others: >> > >> > - Anything doing "select FB" is now gone, or becomes "depends on FB", >> > >> > - DDC support depends on I2C instead of selecting it >> > >> > - backlight class device support is never selected by framebuffer >> > drivers but has proper dependencies >> > >> > I have done thousands of randconfig build tests on this, but no >> > runtime tests. >> > >> > Some of the 'depends on FOO || !FOO' statements could be simplified >> > into a new 'uses FOO' syntax based on a patch from Saeed Mahameed, >> > but I would for the moment treat that as a cleanup that can be done >> > later. >> > >> > If we can agree on these changes, maybe someone can merge them >> > through the drm-misc tree. >> > >> > Please review >> >> Biggest concern I have is that usability of make menuconfig is horrible, >> and it's very hard to find options that are hidden by depends on. You can >> use the search interface, if you happen to know the option. >> >> Once you've surmounted that bar, the next one is trying to find what >> exactly you need to enable. Which again means endless of recursive >> screaming at Kconfig files, since make menuconfig doesn't help you at all. > > +1 on this. But this is a general kconfig problem, and not unique to > DRM, I've done this screaming for many different things now.. eg to > turn on every single RDMA driver. > > I hackily delt with it by creating this rather insane script based on > the python kconfiglib to try and sort things out mostly automatically: > > https://github.com/jgunthorpe/Kernel-Maintainer-Tools/blob/master/gj_tools/cmd_kconfig.py > > It would be great if menuconfig had a key to say 'hey, really, turn > this on and everything it depends on, recursively' I'm really all for switching to using depends when that is the semantically right thing to do. In many places using select is a hack to make the UI simpler, and that's just plain wrong. We'll be doomed to perpetual randconfig build failures and duct tape fixes. I'm pretty tired of this, and I regularly ignore those duct tape fixes to i915 backlight build issues on some bizarre configs that nobody will ever use, and would not exist if depends were used throughout. I'm fine with select but only when it's restricted to symbols that have no dependencies of their own and have no UI. This is in line with Documentation/kbuild/kconfig-language.rst. Not enforcing this is another Kconfig tool shortcoming. See also my reply to Sam [1]. BR, Jani. [1] https://lore.kernel.org/dri-devel/871roi37qe.fsf@intel.com/ -- Jani Nikula, Intel Open Source Graphics Center 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=-5.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS autolearn=unavailable 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 5B899C3A5A0 for ; Mon, 20 Apr 2020 08:14:20 +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 3CB1C20BED for ; Mon, 20 Apr 2020 08:14:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3CB1C20BED Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com 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 857F56E46C; Mon, 20 Apr 2020 08:14:19 +0000 (UTC) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by gabe.freedesktop.org (Postfix) with ESMTPS id 20CBD6E45C for ; Mon, 20 Apr 2020 08:14:18 +0000 (UTC) IronPort-SDR: KkySJW5LmZEfxrw/ImaCSzl8xaRL0jMeVETZIa3XFVVQSWbbt1aQYb3l1d+4wYvdpqUpEC41uO FL7HL4vXfWxQ== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Apr 2020 01:14:13 -0700 IronPort-SDR: GQi+lZ63AuQCCQCozaTBET02e0q31aTNZ8Mhwo8nHFR6eJJau/IulOjjXySYruUpzlKYn8Glfu dahNvYB8YH7A== X-IronPort-AV: E=Sophos;i="5.72,406,1580803200"; d="scan'208";a="429039579" Received: from iastakh-mobl.ccr.corp.intel.com (HELO localhost) ([10.252.63.229]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Apr 2020 01:14:05 -0700 From: Jani Nikula To: Jason Gunthorpe , Daniel Vetter Subject: Re: [PATCH 0/8] drm, fbdev: rework dependencies In-Reply-To: <20200417190854.GI26002@ziepe.ca> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <20200417155553.675905-1-arnd@arndb.de> <20200417171453.GS3456981@phenom.ffwll.local> <20200417190854.GI26002@ziepe.ca> Date: Mon, 20 Apr 2020 11:14:02 +0300 Message-ID: <87y2qq1smt.fsf@intel.com> MIME-Version: 1.0 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: marex@denx.de, linux-fbdev@vger.kernel.org, dsd@laptop.org, Arnd Bergmann , Saeed Mahameed , airlied@linux.ie, masahiroy@kernel.org, Nicolas Pitre , thellstrom@vmware.com, dri-devel@lists.freedesktop.org, geert@linux-m68k.org, linux-renesas-soc@vger.kernel.org, Andrzej Hajda , kieran.bingham+renesas@ideasonboard.com, linux-graphics-maintainer@vmware.com, Laurent.pinchart@ideasonboard.com, haojian.zhuang@gmail.com, jfrederich@gmail.com, robert.jarzmik@free.fr, daniel@zonque.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Fri, 17 Apr 2020, Jason Gunthorpe wrote: > On Fri, Apr 17, 2020 at 07:14:53PM +0200, Daniel Vetter wrote: >> On Fri, Apr 17, 2020 at 05:55:45PM +0200, Arnd Bergmann wrote: >> > I tried to fix up some dependencies after the sii8620 "imply EXTCON" >> > statementn broke, trying a few things but in the backing out a >> > change that would completely reverse the LEDS_CLASS selects into >> > a 'depends on'. >> > >> > However, what I got now are multiple changes that remove gratious >> > "selects" that lead to circular dependencies for sii8620 and others: >> > >> > - Anything doing "select FB" is now gone, or becomes "depends on FB", >> > >> > - DDC support depends on I2C instead of selecting it >> > >> > - backlight class device support is never selected by framebuffer >> > drivers but has proper dependencies >> > >> > I have done thousands of randconfig build tests on this, but no >> > runtime tests. >> > >> > Some of the 'depends on FOO || !FOO' statements could be simplified >> > into a new 'uses FOO' syntax based on a patch from Saeed Mahameed, >> > but I would for the moment treat that as a cleanup that can be done >> > later. >> > >> > If we can agree on these changes, maybe someone can merge them >> > through the drm-misc tree. >> > >> > Please review >> >> Biggest concern I have is that usability of make menuconfig is horrible, >> and it's very hard to find options that are hidden by depends on. You can >> use the search interface, if you happen to know the option. >> >> Once you've surmounted that bar, the next one is trying to find what >> exactly you need to enable. Which again means endless of recursive >> screaming at Kconfig files, since make menuconfig doesn't help you at all. > > +1 on this. But this is a general kconfig problem, and not unique to > DRM, I've done this screaming for many different things now.. eg to > turn on every single RDMA driver. > > I hackily delt with it by creating this rather insane script based on > the python kconfiglib to try and sort things out mostly automatically: > > https://github.com/jgunthorpe/Kernel-Maintainer-Tools/blob/master/gj_tools/cmd_kconfig.py > > It would be great if menuconfig had a key to say 'hey, really, turn > this on and everything it depends on, recursively' I'm really all for switching to using depends when that is the semantically right thing to do. In many places using select is a hack to make the UI simpler, and that's just plain wrong. We'll be doomed to perpetual randconfig build failures and duct tape fixes. I'm pretty tired of this, and I regularly ignore those duct tape fixes to i915 backlight build issues on some bizarre configs that nobody will ever use, and would not exist if depends were used throughout. I'm fine with select but only when it's restricted to symbols that have no dependencies of their own and have no UI. This is in line with Documentation/kbuild/kconfig-language.rst. Not enforcing this is another Kconfig tool shortcoming. See also my reply to Sam [1]. BR, Jani. [1] https://lore.kernel.org/dri-devel/871roi37qe.fsf@intel.com/ -- Jani Nikula, Intel Open Source Graphics Center _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel