On Tue, Aug 29, 2023, at 09:31, Andy Shevchenko wrote:
> On Tue, Aug 29, 2023 at 11:14:31AM +0200, Nuno Sá wrote:
>> On Thu, 2023-08-10 at 18:36 +0300, Andy Shevchenko wrote:
>> > On Thu, Aug 10, 2023 at 01:57:02PM +0200, Nuno Sá wrote:
>> > > On Thu, 2023-08-10 at 12:33 +0300, Dumitru Ceclan wrote:
>
>> > > Is ad717x_gpio_cleanup() being used anywhere? Moreover I would maybe just
>> > > get rid of
>> > > the #ifdef wrapper and just select GPIOLIB. How often will it be disabled
>> > > anyways?
>> >
>> > The agreement is that users are depend on and not selecting GPIOLIB.
>> > Any news in these agreement terms?
>>
>> Hmm no idea about that. If you say so, it's just one new thing I'm learning :)
>Based outside of the U.S.? Some titles might be unavailable in your current location. Go to amazon.de to see the video catalog available in Germany.
> That's the last I know.
> Cc'ing to GPIOLIB maintainers...
>From a Kconfig perspective, any user-visible symbol ideally only uses
'depends on', while hidden symbols usually use 'select'.
For the GPIOLIB symbol specifically, we have a mix of both, but the
overall usage is that gpio consumers only use 'depends on',
while some of the providers use 'select'. This risks causing build
breakage from a dependency loop when combined with other symbols
that have the same problem (e.g. I2C), but it tends to work out
as long as a strong hierarchy is kept. In particular, using 'select'
from an arch/*/Kconfig platform option is generally harmless as
long as those don't depend on anything else.
The new driver is a gpio provider and at least ad4130 and
ad5592r uses 'select' here, but then again ad74115 and
ad74113 use 'depends on' and ads7950 uses neither.
I think the best way to handle these is to remove both
the 'select' and the #ifdef in the driver and instead use
'if (IS_ENABLED(CONFIG_GPIOLIB))' to handle optional gpio
providers in the code.
Arnd
