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

[Paul Gortmaker]

[RE: [PATCH 1/4] mfd: da903x: Make it explicitly non-modular] On 06/06/2017 (Tue 15:27) Steve Twiss wrote:

> Hi Paul,
> 
> On 05 June 2017 20:30, Paul Gortmaker wrote:
> 
> > Subject: Re: [PATCH 1/4] mfd: da903x: Make it explicitly non-modular
> > 
> > [RE: [PATCH 1/4] mfd: da903x: Make it explicitly non-modular]
> > On 05/06/2017 (Mon 10:30) Steve Twiss wrote:
> > 
> > > On 03 June 2017 14:04 Paul Gortmaker wrote:
> > > > The Kconfig currently controlling compilation of this code is:
> > > >
> > > > drivers/mfd/Kconfig:config PMIC_DA903X
> > > > drivers/mfd/Kconfig:    bool "Dialog Semiconductor DA9030/DA9034 PMIC
> > > > Support"
> > > >
> > > > ...meaning that it currently is not being built as a module by anyone.
> > >
> > > With regards to your four patches,
> > >
> > >  [4/4] mfd: da9055-i2c: Make it explicitly non-modular	- - -	2017-06-03
> > >  [3/4] mfd: da9055-core: make it explicitly non-modular	- - -	2017-06-03
> > >  [2/4] mfd: da9052-*: Make it explicitly non-modular	- - -	2017-06-03
> > >  [1/4] mfd: da903x: Make it explicitly non-modular	- - -	2017-06-03
> > >
> > > Is there an reason not to make the Kconfig tristate?
> > > Would that not be simpler?
> > 
> > I explicitly covered that in the 0/4 e-mail:
> 
> Apologies, I don't seem to have been CC'ed on the 0/4 e-mail, although I
> got the others. Dialog's developer e-mail addresses come as part of the
> Support Opensource e-mail distribution list.

That was my fault; looking back I see I neglected to glue all the Cc:
into the 0/N e-mail like I normally do - sorry about that.

> 
> >    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.

Thanks,
Paul.
--

> 
> Regards,
> Steve