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

[Andy Shevchenko]

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