[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHp75VcY9JWGH3+HmmJQQtLLTLPvaZ1RJzmPZ1wFBM+gqRiTHw@mail.gmail.com>
Date: Wed, 13 Aug 2025 12:06:32 +0200
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Bartosz Golaszewski <brgl@...ev.pl>
Cc: Matti Vaittinen <mazziesaccount@...il.com>, Jonathan Cameron <jic23@...nel.org>,
David Lechner <dlechner@...libre.com>, Nuno Sá <nuno.sa@...log.com>,
Andy Shevchenko <andy@...nel.org>, Marcelo Schmitt <marcelo.schmitt@...log.com>,
Javier Carrasco <javier.carrasco.cruz@...il.com>,
Tobias Sperling <tobias.sperling@...ting.com>, Antoniu Miclaus <antoniu.miclaus@...log.com>,
Trevor Gamblin <tgamblin@...libre.com>, Esteban Blanc <eblanc@...libre.com>,
Linus Walleij <linus.walleij@...aro.org>, linux-gpio@...r.kernel.org,
linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org,
Matti Vaittinen <matti.vaittinen@...rohmeurope.com>
Subject: Re: [PATCH] iio: adc: bd79124: Add GPIOLIB dependency
On Wed, Aug 13, 2025 at 11:40 AM Bartosz Golaszewski <brgl@...ev.pl> wrote:
> On Wed, 13 Aug 2025 11:16:06 +0200, Matti Vaittinen
> <mazziesaccount@...il.com> said:
> > The bd79124 has ADC inputs which can be muxed to be GPIOs. The driver
> > supports this by registering a GPIO-chip for channels which aren't used
> > as ADC.
> >
> > The Kconfig entry does not handle the dependency to GPIOLIB, which
> > causes errors:
> >
> > ERROR: modpost: "devm_gpiochip_add_data_with_key" [drivers/iio/adc/rohm-bd79124.ko] undefined!
> > ERROR: modpost: "gpiochip_get_data" [drivers/iio/adc/rohm-bd79124.ko] undefined!
> >
> > at linking phase if GPIOLIB is not configured to be used.
> >
> > Fix this by adding dependency to the GPIOLIB.
...
> > I am somewhat curious why the failure occurs only at the linking phase?
> > Wouldn't it either be better to have these functions
> > devm_gpiochip_add_data_with_key() and gpiochip_get_data() only declared
> > when the CONFIG_GPIOLIB is y/m, to get errors already during
> > compilation, or provide stubs?
>
> Providing stubs is not correct for sure - a GPIO provider must always pull
> in the relevant infrastructure over Kconfig.
I disagree with this statement. The (provided) resource can be
optional and hence the stubs are a way to go.
> As for the former: it seems it's
> a common pattern for the headers containing the "provider" part of the
> subystem API, you'd get the same issue with regulators or pinctrl.
>
> I don't have a good answer, I'd just apply this as it's not a common issue
> from what I can tell.
If the GPIO functionality is optional (not the main one), the user
should be able to compile it conditionally, in such a case it's either
an ifdeffery in the code, or separate module with its own stubs.
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists