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] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkdZZuNbihnQb1zo7G4fPZgomF3v7CacWQG3muvdj4g-euQ@mail.gmail.com>
Date:   Fri, 7 Apr 2017 10:16:13 +0200
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc:     Andy Shevchenko <andy.shevchenko@...il.com>,
        Arnd Bergmann <arnd@...db.de>,
        kbuild test robot <fengguang.wu@...el.com>,
        "kbuild-all@...org" <kbuild-all@...org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        tipbuild@...or.com, Ingo Molnar <mingo@...nel.org>
Subject: Re: [tip:x86/platform 1/1] platform_bt.c:undefined reference to `gpiod_add_lookup_table'

On Tue, Apr 4, 2017 at 5:27 PM, Andy Shevchenko
<andriy.shevchenko@...ux.intel.com> wrote:
> On Mon, 2017-04-03 at 12:44 +0300, Andy Shevchenko wrote:

>> ...and they should not. So, there are two ways of fix this:
>> - add a stub for gpiod_add_lookup_table() for !GPIOLIB case, or
>> - add ifdeffery around this code here (with obvious increase of
>> ugliness).
>
> Linus, there is a (minor) issue with one of the user of
> gpiod_add_lookup_table(), i.e. we have a code which is either built-in
> or not compiled at all and it has some external dependency without
> having an explicit Kconfig option. The external dependency considers
> GPIOLIB as an optional, and thus some configurations might bring
> unresolved symbols.
>
> There are at least two solutions:
> - add a stub for gpiod_add_lookup_table() for !GPIOLIB case, or
> - add ifdeffery around this code here (with obvious increase of
> ugliness).
>
> What is your opinion on the case?

I've heard similar things about other places where people want
to have "half GPIOLIB" adding a few lookup stubs for just numbing
gpiolib.

If it is just a stub without much code I guess that is prettier, but
still it is a bit weird, because I guess the table that are passed
to gpiod_add_lookup_table() will still be compiled into the object
so you are anyways carrying cruft, and then what is the point in
not just doing select GPIOLIB.

But we might be looking at the wrong thing.

Looking closer at the file I see it is some kind of translation
of SFI (simple firmware interface) information into platform/board
data.

IMO SFI is just another hardware description language, and
SFI-described GPIO should be in drivers/gpio/gpiolib-sfi.c or
something like this akin to ACPI and OF. Why is it contained as
platform hacks?

Also a lot of the code down there and I mean
arch/x86/platform/intel-mid/device_libs/ is starting to look like the
ARM board files before we started to convert to device tree.
It includes using the old GPIO interface with the global number space
rather than descriptors and such quite extensively.

So I'm a bit worried that we are seeing a symptom of board data
stockpiling in arch/x86 and not really a GPIO compilation problem.

Yours,
Linus Walleij

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ