Hi,
On Fri, Oct 24, 2014 at 09:11:38PM +0100, Mark Brown wrote:
On Fri, Oct 24, 2014 at 02:15:11PM -0500, Felipe Balbi wrote:
If we don't stup that call out, we will have build failures for any drivers using that function when .config happens to have CONFIG_REGULATOR=n.
One such case below, found with randconfig
drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c: In function ‘mdp4_kms_init’: drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c:384:2: error: implicit declaration \
As previously and repeatedly reported the regulator usage in this driver appears extremely problematic, among these problems is that it almost certainly has no sensible reason to be using regulator_get_exclusive() or any variant of it. Sadly every time it's been raised with the video people they've completely ignored the mail so here we are.
Right now not having the stub seems to only be affecting buggy users (which given the use cases for _exclusive() isn't *that* surprising) so I'm more inclined to leave this there in the hope that the users get fixed or we can at least get some sort of dialogue with the relevant maintainers.
quite frankly, flawed or not, I still think it's wrong of regulator framework to cause a build break during randconfig. Pretty much every other call is stubbed out, why wouldn't this be ? Moreover, if nobody cared to this day, why would this randconfig build break change their minds ?
Not that I really care, it's just yet another build break I need to ignore when build-testing. Whatever.