netdev - Re: [PATCH net-next] mdio_bus: Remove unneeded gpiod NULL check

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: <CACRpkdbK03cwzmGs=0nVeCp6NnX0-41dhEotxfDT46O4xDzagQ@mail.gmail.com>
Date:   Thu, 7 Sep 2017 23:33:50 +0200
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Woojung.Huh@...rochip.com
Cc:     Andrew Lunn <andrew@...n.ch>, Fabio Estevam <festevam@...il.com>,
        Sergei Shtylyov <sergei.shtylyov@...entembedded.com>,
        "David S. Miller" <davem@...emloft.net>,
        Florian Fainelli <f.fainelli@...il.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Fabio Estevam <fabio.estevam@....com>
Subject: Re: [PATCH net-next] mdio_bus: Remove unneeded gpiod NULL check

On Thu, Sep 7, 2017 at 11:30 PM,  <Woojung.Huh@...rochip.com> wrote:
>> If someone is using GPIO descriptors with GPIO disabled, i.e. calling
>> gpiod_get() and friends, this is very likely to be a bug, and what
>> the driver wants to do is:
>>
>>  depends on GPIOLIB
>>
>> or
>>
>>  select GPIOLIB
>>
>> in Kconfig. The whole optional thing is mainly a leftover from when it
>> was possible to have a local implementation of the GPIOLIB API in
>> some custom header file, noone sane should be doing that anymore,
>> and if they do, they can very well face the warnings.
>>
>> If someone is facing a lot of WARN_ON() messages to this, it is a clear
>> indication that they need to fix their Kconfig and in that case it is proper.
> Linus & Andrew,
>
> I knew that it is already in David's pulling request.
> Configuring GPIOLIB is the right solution  even if platform doesn't use it?

I guess?

"Platform doesn't use it" what does that mean?

Does it mean it does not call the
APIs of the GPIOLIB, does it mean it doesn't have a GPIO driver
at probe (but may have one by having it probed from a module)
or does it mean the platform can never have it?

If it calls the APIs, it is using it.

Yours,
Linus Walleij