On Thu, Oct 13, 2011 at 12:38:21PM -0600, Grant Likely wrote: > These *sound* like flags that the driver would set based on its own > capabilities; in which case it is something that would be encoded > directly into the driver. They're almost entirely a combination of system specifics and software capabilities - it's not even reliably one or the other. For example the ability to switch regulator modes is going to depend on a combination of the modes a specific regulator offers, the set of things connected to the regulator in the current system (not all of which will be software visible), how good all the connected consumer drivers are at providing accurate information about what they're going to need from the system in terms of quality of regulation and current draw and how good the board design is in making these things reality. For robustness (for some of these things if you get it wrong we're talking catastrophic hardware failure) the Linux regulator API is extremely conservative and won't touch the hardware unless explicitly told that a specific thing is OK on a given board. -- 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
