On Tue, Mar 03, 2015 at 08:15:41AM -0800, Bjorn Andersson wrote: > On Tue 03 Mar 04:50 PST 2015, Mark Brown wrote: > > Why would the driver need to do that? I guess I'll see later on in the > > series but the changelog should make that clear. Drivers aren't > > supposed to ever need to look at their init data, modifying the init > > data from what the machine provied is usually a red flag. > I think what you're getting at is that the init_data should come from a > board file or device tree. With the reworkings done in patch 4 this Yes, that's the entire purpose of the init data. > As this matches a regulator, there is no way for the driver (or anyone > else to affect the init_data). That's a goal not a problem. There is an interface for the machine description to configure the system integration which neither the regulator driver nor the consumer driver should be a part of. > The problem at hand is that there is nothing in this code path telling > the core that we can do DRMS - something we can figure out in the driver > by basically looking at the ops for the registering regulator. No, that way lies people doing all the crap they usually do with putting the default constraints for their reference design or the maximum limits for their PMIC into the constraints and then getting upset when drivers then go and use this to make their CPU catch fire or whatever. You need to provide a way for the machine description to say DRMS (or really setting the load which is what's actually happening here now we have that op) is safe on a given system. I think that means adding a new permission to DT and then using that; it's more sensible to want to use this feature in the context where we're working with an external processor which also has a chance to have system tuning than when we're working with the PMIC directly so a permission that enable load setting seems good. We could even kill the existing DRMS permission, there's one user in a legacy STE platform.
Attachment:
signature.asc
Description: Digital signature
