RE: [PATCH 1/4] mfd: da903x: Make it explicitly non-modular

[Steve Twiss]

Hi Paul,

On 06 June 2017 21:23, Paul Gortmaker wrote:

> Subject: Re: [PATCH 1/4] mfd: da903x: Make it explicitly non-modular
> 
> > >    As always, the option exists for someone with the hardware and the desire
> > >    to extend the functionality to make any given driver tristate.  But given
> > >    the number of these tree wide and the fact that I can't test that new
> > >    extended functionality in all cases, I just make the code consistent with
> > >    existing Kconfig/Makefile settings that currently restrict them to "bool".
> >
> > I see your point, however we have many customers and it is unclear whether
> > they are using modules for any of these drivers.
> > Even if that feature in Kconfig is not enabled, it is possible a tristate change has
> > been made and is being used, but has not been pushed back into the Linux
> > mainline.
> 
> I'd have to suspect that is pretty unlikely, but in the end if you think
> these chips have a use case for being modular that isn't just academic,
> then there is no reason why they can't be tristate.
> 
> > So I would recommend against removing this feature.
> >
> > The driver code is being supported by Dialog Semiconductor, where possible.
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/MAINTAINERS?h=v4.12-rc4#n3984
> > If there is a question about supporting modules in these drivers, we have the
> > ability to test on target for da9055/52.
> 
> So, the "conversion" patches would be the trivial one line change from
> "bool" to "tristate" and the real effort is the validation.  Do you want
> to submit those trivial changes after you've had a chance to validate
> them?  There is no point in me sending you one line patches to test.

Sure, agreed.

The responsibility can fall back to Dialog for this change. We will submit
for these "Make it explicitly non-modular" patches and remove the ambiguity
caused by the Kconfig bool options.

Regards,
Steve