On Fri, Oct 24, 2014 at 4:11 PM, Mark Brown broonie@kernel.org 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.
oh, looks like a case of overambitious mailing list filter rules.. I did not see the earlier threads on the topic.
iirc, I was using _get_exclusive() in a few places where I wanted to be sure not to get dummy-regulator in cases where I should -EPROBE_DEFER instead (since probe order with DT is slightly hilarious, and since I depend on a few other drivers I end up deferring at least a couple times at boot)... I don't quite remember the details. But afaict regulator_get() still allows dummy-regulator, which is what I specifically don't want.
If you have a recommendation for a better way, I am all ears.
BR, -R
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.