On Fri, Oct 24, 2014 at 4:11 PM, Mark Brown <broonie@xxxxxxxxxx> 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. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
