On 09/10/2013 11:04 AM, Mark Brown wrote: > On Tue, Sep 10, 2013 at 09:07:43AM -0600, Stephen Warren wrote: >> On 09/10/2013 04:09 AM, Mark Brown wrote: > >>> No. There are a couple of issues here. One is that we don't want >>> to litter all drivers with conditional code to check if they >>> actually got the regulator and so on, that's just pointless make >>> work on the part of consumers. > >> So that's exactly the difference between (a) and (b) above. > > Right, but the idea is that we just only ignore a failure to get a > supply if we can usefully run without that supply being present and > there's more code there than simply ignoring the error - if the driver > can genuinely just ignore all errors and otherwise not do anything > different then requesting the regulator in the first place is clearly a > waste of time and enabling it would be a waste of power. > > A driver should only be carrying code for a missing regulator if it can > usefully work without it, like the cases where devices can use an > internal reference if one is not available. OK, so I believe you're saying that the case of a chip with just a single power source, which absolutely must be present in HW for the chip to be powered, isn't appropriate for regulator_get_optional(). Something must always define a regulator for that power source, even if there is no external SW control over that power source. If so, how does a driver (or binding) that's been written without any support for a regulator (since so far all boards have had no SW control over that power source; it's always on) get enhanced to support boards where there is SW control over the power source? We either allow the regulator to be optional (since SW control over the regulator is optional), or go back to every board file and DT and add a dummy regulator in (which then breaks DT ABI, and even ignoring that is a pain). And note that when I say "optional" at the start of the previous paragraph, I'm talking about probe-time regulator_get() operations and DT content. Clearly as far as the rest of the driver is concerned, something can always provide a dummy regulator so that e.g. regulator_enable/disable() elsewhere always have something to operate on. However, probe() either needs to call an API that automatically provides such a dummy regulator, or open-code that itself. I'm still not clear which option you think should be used. -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
