Mark Brown wrote: > On Fri, Feb 05, 2010 at 10:45:09PM +0200, Mike Rapoport wrote: >> On Thu, Feb 4, 2010 at 6:21 PM, Mark Brown > >>> The bodge I'm thinking of would do something like log an error and >>> substitute in a dummy regulator when regulator_get() would have failed >>> so that the driver sees behaviour equivalent to the stubbed regulator >>> API if the bodge is active. A central thing seems much more sensible >>> here - there's nothing specific to this driver going on here and having >>> the API behave in a consistent manner seems good. > >> I agree that such approach have more sense than checking for -ENODEV >> in each and every driver that uses the regulator framework. I just >> wonder, if there should be some mechanism that can switch the >> substitution of the dummy regulators on and off. And if yes, how >> should the platform code communicate with the regulator core the need >> for such dummy regulators... > > So, having thought about this a bit more we actually have two different > use cases here. One is where you've got a system which has software > controllable regulators for everything but may not have plumbed in all > the supplies, the other is for systems where only a very few supplies > are on software controlled regulators which are just trying to save the > hassle of hooking up the bulk of the supplies to fixed voltage > regulators. These two use cases should probably be handled differently > - the first one is really expected to have all the supplies hooked up > and so should warn when using the bodge regulator but the warning isn't > helpful in the second case. Sounds right to me. > We already have some support for boards to set up the API in the form of > regulator_set_full_constraints() so we could do something similar for > dummy regulators, or create a new single API to set a bunch of options > via a struct which is probably less hassle going forward. Struct sounds more reasonable that just a call to e.g. regulator_warn_dummy_fixed_regulator :) > -- > To unsubscribe from this list: send the line "unsubscribe linux-input" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Sincerely yours, Mike. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
