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

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

On Tue, Mar 04, 2025 at 07:22:23AM +0200, Raag Jadav wrote:
> On Mon, Mar 03, 2025 at 04:20:08PM +0200, Andy Shevchenko wrote:
> > 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?
> > 
> > I don't see much benefit out of this. If MFD is not available, the other
> > drivers may be built, but it won't make any practical sense except build for
> > the sake of build. I think when they are all together, it makes real sense
> > to compile test. MFD driver here is like a subsubsystem dependecy, we don't
> > usually compile the drivers without subsystem being enabled.
> 
> I thought the point of COMPILE_TEST is to do exactly that, but sure if
> you insist.

I think it's okay to compile test the whole batch of the related to each other
drivers, they are not many and again, the configuration that MFD is absent and
leaf drivers are built sounds to me impractical, so not really used in the real
life. If the leaf driver makes sense separately on some future HW or HW designs,
then we might reconsider the dependencies.

-- 
With Best Regards,
Andy Shevchenko