From patchwork Fri Feb 2 11:59:52 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Arnd Bergmann X-Patchwork-Id: 10196497 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 0F121603D7 for ; Fri, 2 Feb 2018 11:59:57 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id E362328E3C for ; Fri, 2 Feb 2018 11:59:56 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id D571728E3E; Fri, 2 Feb 2018 11:59:56 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id AD3BE28E3C for ; Fri, 2 Feb 2018 11:59:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751604AbeBBL7y (ORCPT ); Fri, 2 Feb 2018 06:59:54 -0500 Received: from mail-ot0-f194.google.com ([74.125.82.194]:35668 "EHLO mail-ot0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751561AbeBBL7x (ORCPT ); Fri, 2 Feb 2018 06:59:53 -0500 Received: by mail-ot0-f194.google.com with SMTP id a2so8661713otf.2; Fri, 02 Feb 2018 03:59:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=CiXGeIhj3zwXCNKCsnj7zFc9GCrioSLEf2kQebKqFcs=; b=AYY4boIVv5+MBzk18Td4wGucBc5KoPx96CuoTeTVcfk1zCumMQ9jZ7UpExMGv4xx4z piqBUFCJ79vnv7C5NUGbZOqZePaePEMMX8hVrMuUnPHGES0qgcbFm4JidYylgtwKbgWm XDuG6iTZQtDourFtOmHf2h6wuLjk2eh5WiNl+w81YFCo1UM+PTPIJAE5gkaqeWi2BBZB DB1jQuyMqtbRx9SnoHwzbPt7jLMPMRtX1OUPwUk6bc4JepzXOxJwVt5+obuiDzav0eEE vl/Y3W26SZkydQnsnEgZzU2au3jk7NKeQ8le9LVE+yKSf7Z3rbQwftD++RS2tcu6Ozrc d73w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=CiXGeIhj3zwXCNKCsnj7zFc9GCrioSLEf2kQebKqFcs=; b=XPo8WHJekROF1pfDbM6u9FYT63Kw+0uDOjA+nqqFhV9ffNWDtvLmj+LFuivCc/uXts dcnx/Q8A8NnWDq/biybqEXvcBgLP6bzOU1bKCM/9i8itup/xNdpljpflyKKGBeXEM0+K f608S9ZlluJNDwiNxufuIJ88XZlOW5kO3IwoztD0rqNquauuccBrNncukftqlXlrWCes +Z/VALNZyTBifuFSQm9tS91OqmTneO7bjnQD+5jeiX76LtbKfX6U1aXAQWWWucLuWTOQ oUEw4tbAINGauNVpbk9BGkKRm06xjtDJeiwb48MQXH72e0V5Rg7UgmPfQfkyTBQhwg4q njdA== X-Gm-Message-State: AKwxyteoDetjaswe6TX+HipfffSOni/Dl2RQ/CwQ4ueR3w7nayBciWyT IQUs2Fl8oyWVLYpBmSKJ+c6ag73u0SjfvtI1hJ8= X-Google-Smtp-Source: AH8x226dk2TtMw9NHXqsuFmOcDz34ezsgsYB6EvojrIBmo/l62wy5Go4DbKF3jLRWuiaI9eyHQHrTZW0EQqO0VqrTvc= X-Received: by 10.157.69.6 with SMTP id w6mr1085523ote.351.1517572792520; Fri, 02 Feb 2018 03:59:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.68.33 with HTTP; Fri, 2 Feb 2018 03:59:52 -0800 (PST) In-Reply-To: References: <20180115161431.803248-1-arnd@arndb.de> <1737876.npfVsP8Sog@amdc3058> From: Arnd Bergmann Date: Fri, 2 Feb 2018 12:59:52 +0100 X-Google-Sender-Auth: erm8z8sBdEawmd6KL90r8TYrX8k Message-ID: Subject: Re: [PATCH 1/2] fbdev: don't select I2C directly To: Randy Dunlap Cc: Bartlomiej Zolnierkiewicz , Rob Clark , Jordan Crouse , dri-devel , linux-fbdev@vger.kernel.org, linux-i2c@vger.kernel.org, Wolfram Sang , Srinivas Kandagatla , Linux Kernel Mailing List Sender: linux-fbdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fbdev@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Fri, Feb 2, 2018 at 1:21 AM, Randy Dunlap wrote: > On 02/01/2018 08:14 AM, Bartlomiej Zolnierkiewicz wrote: >> On Monday, January 15, 2018 05:14:04 PM Arnd Bergmann wrote: >>> Using a Kconfig 'select' statement for a user-visible symbol that other >>> drivers depend on often causes circular dependencies. A new one showed >>> up when I wanted to add an NVMEM dependency to the DRM_MSM driver: >>> >>> drivers/i2c/Kconfig:7:error: recursive dependency detected! >>> drivers/i2c/Kconfig:7: symbol I2C is selected by FB_DDC >>> drivers/video/fbdev/Kconfig:63: symbol FB_DDC is selected by FB_CYBER2000_DDC >>> drivers/video/fbdev/Kconfig:390: symbol FB_CYBER2000_DDC depends on FB_CYBER2000 >>> drivers/video/fbdev/Kconfig:378: symbol FB_CYBER2000 depends on FB >>> drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER >>> drivers/gpu/drm/Kconfig:77: symbol DRM_KMS_FB_HELPER depends on DRM_KMS_HELPER >>> drivers/gpu/drm/Kconfig:71: symbol DRM_KMS_HELPER is selected by DRM_MSM >>> drivers/gpu/drm/msm/Kconfig:2: symbol DRM_MSM depends on NVMEM >>> drivers/nvmem/Kconfig:1: symbol NVMEM is selected by EEPROM_AT24 >>> drivers/misc/eeprom/Kconfig:3: symbol EEPROM_AT24 depends on I2C >>> >>> Here, the problem is that many fbdev drivers have an i2c based interface >>> and just 'select i2c' for that, while we also select the framebuffer >>> subsystem indirectly from a DRM driver that now depends on i2c. >>> >>> This does away with the 'select' statement and instead uses 'depends on', >>> like almost all I2C users. >> >> I worry that this change may cause various driver options to no longer >> be visible to people configuring their kernels and not having I2C already >> selected. >> >> DRM somehow manages to select I2C and I would prefer to be it the same >> way for fbdev (also looking at the current next tree there are still >> some drivers that 'select I2C').. > > a. Linus has stated that a driver should not enable an entire subsystem, > so depends on would be better than select. > If I had the email/patch, I would be glad to Ack it. > > b. DRM configuration is a mess. You shouldn't want to follow their model. :) Right, that should also be fixed, so DRM no longer includes I2C ;-) At the moment, DRM is the most common cause for circular dependencies because it has a number of 'select' statements for symbols that otherwise are used with 'depends on'. We should probably address the 'select I2C' portion in there, but also some of the others like: drivers/gpu/drm/Kconfig: select POWER_SUPPLY drivers/gpu/drm/Kconfig: select HWMON drivers/gpu/drm/Kconfig: select FB drivers/gpu/drm/udl/Kconfig: select USB drivers/gpu/drm/sti/Kconfig: select OF drivers/gpu/drm/sti/Kconfig: select RESET_CONTROLLER drivers/gpu/drm/etnaviv/Kconfig: select CMA if HAVE_DMA_CONTIGUOUS drivers/gpu/drm/etnaviv/Kconfig: select TMPFS drivers/gpu/drm/i915/Kconfig.debug: select DEBUG_FS drivers/gpu/drm/i915/Kconfig.debug: select PREEMPT_COUNT drivers/gpu/drm/i915/Kconfig.debug: select TRACING drivers/gpu/drm/i915/Kconfig.debug: select FAULT_INJECTION drivers/gpu/drm/mediatek/Kconfig: select MEMORY drivers/gpu/drm/mediatek/Kconfig: select GENERIC_PHY drivers/gpu/drm/msm/Kconfig: select REGULATOR > c. If I2C is not enabled in the FB menu, someone could just add something like this: > > comment "Enable I2C to see more driver choices" > depends on !I2C I don't think that would address the issue of 'defconfig' builds losing I2C support when it's no longer automatically selection. On x86, this is not an issue, as X86 always enables I2C. For the rest, we could do a hack like this: which would let all 'defconfig' versions keep working. It's a bit ugly, but at least wouldn't cause other circular dependencies. Arnd --- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html --- a/drivers/i2c/Kconfig +++ b/drivers/i2c/Kconfig @@ -8,6 +8,7 @@ config I2C tristate "I2C support" select RT_MUTEXES select IRQ_DOMAIN + default DRM || FB ---help--- I2C (pronounce: I-squared-C) is a slow serial bus protocol used in many micro controller applications and developed by Philips. SMBus,