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: 10196499 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 E423B60467 for ; Fri, 2 Feb 2018 11:59:58 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id D446028E3C for ; Fri, 2 Feb 2018 11:59:58 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id C89D528E3E; Fri, 2 Feb 2018 11:59:58 +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=-4.1 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_MED,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 3929128E3C for ; Fri, 2 Feb 2018 11:59:57 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id B476A6F05C; Fri, 2 Feb 2018 11:59:55 +0000 (UTC) X-Original-To: dri-devel@lists.freedesktop.org Delivered-To: dri-devel@lists.freedesktop.org Received: from mail-ot0-x244.google.com (mail-ot0-x244.google.com [IPv6:2607:f8b0:4003:c0f::244]) by gabe.freedesktop.org (Postfix) with ESMTPS id 8E0FB6F05C for ; Fri, 2 Feb 2018 11:59:53 +0000 (UTC) Received: by mail-ot0-x244.google.com with SMTP id 73so10893475oti.12 for ; 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=IljsOWjMbo7TMdYa7z5g2Vc9jcWixEDTd3f8k+o94jlIWhg/Ns1I5xNDUVwWZFMZjc SJhU8VASyhCJDO9ABEAhMssIzsYa5jjzVWPR5Q16mXNqw2t40VUhwiKDPdxrcJ1N/csR kqESire85dnT+bEO60jEYNMKiRlVhE4O1hA6JmGuga6au15vMQ1fy57AzkyeyTMKTDd5 dFNTHowmwRPXeASLiF9BLuXBFOXkqe3bKvEK6ncs/3kr305oN1JiNb70XdTI+BQbQ/hS sZXWhLQ0QEhMGfQeGMZJlOW7fy9HZELKMmKX9nM3cFjYA1VYnHyLtprvVGzA8ss06wNU DOOg== X-Gm-Message-State: AKwxytfbwjNmQitNdmla5wsX+cP98F7Kh8KhUR1n1pELhApv+ZB8EjP8 zmZPeoqj9H8jvsQNiqd5gWJfyOBvPWOHr60djo4= 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 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-fbdev@vger.kernel.org, Bartlomiej Zolnierkiewicz , Wolfram Sang , dri-devel , Linux Kernel Mailing List , Srinivas Kandagatla , linux-i2c@vger.kernel.org Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" 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 --- 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,