Re: [PATCH v2 2/5] gpio: elkhartlake: depend on MFD_INTEL_EHL_PSE_GPIO

Andy Shevchenko
2025-03-03T13:20:03Z

On Mon, Mar 03, 2025 at 02:46:24PM +0200, Raag Jadav wrote:
> On Mon, Mar 03, 2025 at 02:21:55PM +0200, Andy Shevchenko wrote:
> > On Mon, Mar 03, 2025 at 02:13:35PM +0200, Raag Jadav wrote:
> > > On Mon, Mar 03, 2025 at 01:44:52PM +0200, Andy Shevchenko wrote:
> > > > On Mon, Mar 03, 2025 at 01:38:15PM +0200, Raag Jadav wrote:
> > > > > On Mon, Mar 03, 2025 at 10:21:13AM +0200, Andy Shevchenko wrote:
> > > > > > On Mon, Mar 03, 2025 at 10:17:42AM +0530, Raag Jadav wrote:

...

> > > > > > > config GPIO_ELKHARTLAKE
> > > > > > > tristate "Intel Elkhart Lake PSE GPIO support"
> > > > > > > - depends on X86 || COMPILE_TEST
> > > > > > > + depends on (X86 && MFD_INTEL_EHL_PSE_GPIO) || COMPILE_TEST
> > > > > > > select GPIO_TANGIER
> > > > > >
> > > > > > Looking on how GPIO PMIC drivers are written, I would redo this as
> > > > > >
> > > > > > depends on (X86 || COMPILE_TEST) && MFD_INTEL_EHL_PSE_GPIO
> > > > >
> > > > > True, but perhaps allow independent COMPILE_TEST where possible?
> > > >
> > > > It will be tested in all-or-none way. Or you think it has to be tested
> > > > individually? If so, why is it needed?
> > >
> > > Better CI coverage?
> >
> > How? I do not see the difference, can you elaborate?
> > (Assuming that CIs are using the merge_config.sh approach or alike)
>
> That is my understanding of it.
>
> config COMPILE_TEST
> bool "Compile also drivers which will not load"
> depends on HAS_IOMEM
> help
> Some drivers can be compiled on a different platform than they are
> intended to be run on. Despite they cannot be loaded there (or even
> when they load they cannot be used due to missing HW support),
> developers still, opposing to distributors, might want to build such
> drivers to compile-test them.

Yes, and how does my suggestion prevent from this happening?

--
With Best Regards,
Andy Shevchenko