On Wed, Dec 28, 2011 at 08:40:56PM +0800, Richard Zhao wrote: > On Wed, Dec 28, 2011 at 12:14:04PM +0000, Mark Brown wrote: > > On Wed, Dec 28, 2011 at 08:05:20PM +0800, Richard Zhao wrote: > > > > Looks like the problem with your mail client is that it's wrapping at > > exactly 80 characters which is too little - you need to leave space for > > being quoted. > I'm using vim. any suggestion for auto-wrapping? :set tw=72 It'd also be useful to leave blank lines > > > > You can't usefully work with voltages without knowing what the actual > > > > voltages are > if people don't enable REGULATOR, the stubs (if you mean the dummy func) > are only be used to pass build. The code is optimized out by compiler. No, this is not the case. All the functions have return values which still need to be handled gracefully by drivers using those functions. > > - the only sensible stubs we could provide would return > > > > errors but then any driver using the stubs would probably fail to do > > > > whatever it was doing. > In this case, If regulator_get return NULL, I won't call other regulator > functions at runtime. That should be OK for your use case but it might not be sensible for other cases. Any stubs for this provided by the core need to work well for any user. > > > - I saw linux/regulator/consumer.h has some dummy functions if !REGULATOR. I > > > tried to make clk-reg-cpufreq driver work even !REGULATOR. I think that's > > > why the dummy functions are there. If regulator_get return NULL, it'll avoid > > > calling other regulator functions. But regulator_is_supported_voltage and > > > regulator_set_voltage_time don't have such dummy ones. Undefined functions. > > I can only repeat what I wrote above explaining why no stubs are > > provided. > One word. You mean I have to always depends on REGULATOR config, right? Yes. -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
