[PATCH] regulator: stub out devm_regulator_get_exclusive

2014-10-25 Thread Mark Brown
On Fri, Oct 24, 2014 at 05:57:24PM -0400, Rob Clark wrote: > Oh, you are only looking at the one in mdp4_kms_init(), which could > possibly be a simple regulator_get(). Look instead at the ones in > hdmi_init(), where I need to know whether to defer or not. At one No, I saw that - looking at

[PATCH] regulator: stub out devm_regulator_get_exclusive

2014-10-24 Thread Mark Brown
On Fri, Oct 24, 2014 at 04:36:24PM -0400, Rob Clark wrote: > 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

[PATCH] regulator: stub out devm_regulator_get_exclusive

2014-10-24 Thread Mark Brown
On Fri, Oct 24, 2014 at 03:18:27PM -0500, Felipe Balbi wrote: > On Fri, Oct 24, 2014 at 09:11:38PM +0100, Mark Brown wrote: > > 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

[PATCH] regulator: stub out devm_regulator_get_exclusive

2014-10-24 Thread Mark Brown
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 > >

[PATCH] regulator: stub out devm_regulator_get_exclusive

2014-10-24 Thread Rob Clark
On Fri, Oct 24, 2014 at 5:18 PM, Mark Brown wrote: > On Fri, Oct 24, 2014 at 04:36:24PM -0400, Rob Clark wrote: > >> 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

[PATCH] regulator: stub out devm_regulator_get_exclusive

2014-10-24 Thread Rob Clark
On Fri, Oct 24, 2014 at 4:11 PM, 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,

[PATCH] regulator: stub out devm_regulator_get_exclusive

2014-10-24 Thread Felipe Balbi
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

[PATCH] regulator: stub out devm_regulator_get_exclusive

2014-10-24 Thread Felipe Balbi
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 > >

[PATCH] regulator: stub out devm_regulator_get_exclusive

2014-10-24 Thread Felipe Balbi
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?: