linux-kernel - Re: [PATCH 1/2] fbdev: don't select I2C directly

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAMuHMdUdagXOG=v-xsLBoTb=rjS0HgAxZJE92NZsyqFzG=CVaQ@mail.gmail.com>
Date:   Tue, 6 Feb 2018 12:07:00 +0100
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Randy Dunlap <rdunlap@...radead.org>,
        Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
        Rob Clark <robdclark@...il.com>,
        Jordan Crouse <jcrouse@...eaurora.org>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        Linux Fbdev development list <linux-fbdev@...r.kernel.org>,
        Linux I2C <linux-i2c@...r.kernel.org>,
        Wolfram Sang <wsa@...-dreams.de>,
        Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] fbdev: don't select I2C directly

On Fri, Feb 2, 2018 at 12:59 PM, Arnd Bergmann <arnd@...db.de> wrote:
> On Fri, Feb 2, 2018 at 1:21 AM, Randy Dunlap <rdunlap@...radead.org> wrote:
>> 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

USB? Seriously?

> 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:
>
> --- 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,
>
> which would let all 'defconfig' versions keep working. It's a bit ugly, but
> at least wouldn't cause other circular dependencies.

And then we'll have to refresh all defconfigs for machines with FB and
without I2C?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds