Re: Warnings from include/linux/gpio/consumer.h with CONFIG_GPIOLIB=n

[Linus Walleij]

On Sat, Sep 2, 2017 at 6:49 AM, Florian Fainelli  wrote:

> I think Sergei or someone else was mentioning that before a while ago,
> but when CONFIG_GPIOLIB=n most gpiod_* inline stubs have WARN_ON() that
> will scare people.
>
> What do you recommend doing for code that might be built with or without
> CONFIG_GPIOLIB, should we just encapsulate the part that deals with
> GPIOs under an #if IS_ENABLED(CONFIG_GPIOLIB) or something? The
> particular piece of code that I just saw this with is
> drivers/net/phy/mdio_bus.c.

I think I kind of answered the question in the last week in discussion,
I liked when you brought out the notion of consumer API contract, I
guess I should think about documenting it properly.

Anyways, the stubs make it possible to compile out the GPIO code,
at the cost of warnings spewn if the API is anyways called. So there
are IMO two use cases:

- Compile coverage with !GPIOLIB, such as COMPILE_TEST etc,
  who cares what gets compiled in or called: it's fine with the
  stubs.

- Actual systems that are using GPIO in an entirely optional way.
  there the callers need to make sure that they don't call these
  APIs if they don't actually use them, which is what your patch
  does.

Yours,
Linus Walleij

Re: Warnings from include/linux/gpio/consumer.h with CONFIG_GPIOLIB=n

[Linus Walleij]

On Sat, Sep 2, 2017 at 6:49 AM, Florian Fainelli  wrote:

> I think Sergei or someone else was mentioning that before a while ago,
> but when CONFIG_GPIOLIB=n most gpiod_* inline stubs have WARN_ON() that
> will scare people.
>
> What do you recommend doing for code that might be built with or without
> CONFIG_GPIOLIB, should we just encapsulate the part that deals with
> GPIOs under an #if IS_ENABLED(CONFIG_GPIOLIB) or something? The
> particular piece of code that I just saw this with is
> drivers/net/phy/mdio_bus.c.

I think I kind of answered the question in the last week in discussion,
I liked when you brought out the notion of consumer API contract, I
guess I should think about documenting it properly.

Anyways, the stubs make it possible to compile out the GPIO code,
at the cost of warnings spewn if the API is anyways called. So there
are IMO two use cases:

- Compile coverage with !GPIOLIB, such as COMPILE_TEST etc,
  who cares what gets compiled in or called: it's fine with the
  stubs.

- Actual systems that are using GPIO in an entirely optional way.
  there the callers need to make sure that they don't call these
  APIs if they don't actually use them, which is what your patch
  does.

Yours,
Linus Walleij

Warnings from include/linux/gpio/consumer.h with CONFIG_GPIOLIB=n

[Florian Fainelli]

Hi Linus,

I think Sergei or someone else was mentioning that before a while ago,
but when CONFIG_GPIOLIB=n most gpiod_* inline stubs have WARN_ON() that
will scare people.

What do you recommend doing for code that might be built with or without
CONFIG_GPIOLIB, should we just encapsulate the part that deals with
GPIOs under an #if IS_ENABLED(CONFIG_GPIOLIB) or something? The
particular piece of code that I just saw this with is
drivers/net/phy/mdio_bus.c.

Thanks!
-- 
Florian

Warnings from include/linux/gpio/consumer.h with CONFIG_GPIOLIB=n

[Florian Fainelli]

Hi Linus,

I think Sergei or someone else was mentioning that before a while ago,
but when CONFIG_GPIOLIB=n most gpiod_* inline stubs have WARN_ON() that
will scare people.

What do you recommend doing for code that might be built with or without
CONFIG_GPIOLIB, should we just encapsulate the part that deals with
GPIOs under an #if IS_ENABLED(CONFIG_GPIOLIB) or something? The
particular piece of code that I just saw this with is
drivers/net/phy/mdio_bus.c.

Thanks!
-- 
Florian