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

[Andy Shevchenko]

On Mon, Mar 03, 2025 at 04:01:43PM +0200, Raag Jadav wrote:
> On Mon, Mar 03, 2025 at 03:19:57PM +0200, Andy Shevchenko wrote:
> > 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:

...

> > > > > 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?
> 
> Nothing's preventing it, but since we have an opportunity to allow
> a wider build test (even without arch or mfd dependency), shouldn't
> we allow it?

We are going circles here. My point that there is a little sense to do that
without MFD as it's impractical. On top of that this is inconsistent to other
drivers with similar design.

-- 
With Best Regards,
Andy Shevchenko