On 2025年8月13日 15:27:58 +0300 Andy Shevchenko <andriy.shevchenko@xxxxxxxxx> wrote: > On Wed, Aug 13, 2025 at 02:17:44PM +0200, Bartosz Golaszewski wrote: > > On Wed, Aug 13, 2025 at 12:07 PM Andy Shevchenko > > <andy.shevchenko@xxxxxxxxx> wrote: > > > On Wed, Aug 13, 2025 at 11:40 AM Bartosz Golaszewski <brgl@xxxxxxxx> wrote: > > > > On 2025年8月13日 11:16:06 +0200, Matti Vaittinen > > > > <mazziesaccount@xxxxxxxxx> said: > > ... > > > > > 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. > > > > Honestly, it makes much more sense to factor out that optional > > functionality into its own compilation unit that can be left out > > completely for !CONFIG_GPIOLIB with a single internal registration > > function being stubbed within the driver. > > That's what I suggested under "separate module with its own stubs" above. > I agree that's the long term ideal. For now I'm going to queue this fix up and mark it for stable. We can tidy up and make it optional again as a follow up. Jonathan