13.11.2020 17:29, Mark Brown пишет:

On Fri, Nov 13, 2020 at 01:37:01AM +0300, Dmitry Osipenko wrote:

quoted

12.11.2020 23:01, Mark Brown пишет:

quoted

quoted

But it's not allowed to change voltage of a dummy regulator, is it
intentional?

quoted

quoted

Of course not, we can't know if the requested new voltage is valid - the
driver would have to have explict support for handling situations where
it's not possible to change the voltage (which it can detect through
enumerating the values it wants to set at startup).

quoted

quoted

[Requesting the same supply multiple times]

quoted

But how driver is supposed to recognize that it's a dummy or buggy
regulator if it rejects all voltages?

It's not clear if it matters - it's more a policy decision on the part
of the driver about what it thinks safe error handling is.  If it's not
possible to read voltages from the regulator the consumer driver has to
decide what it thinks it's safe for it to do, either way it has no idea
what the actual current voltage is.  It could assume that it's something
that supports all the use cases it wants to use and just carry on with
no configuration of voltages, it could decide that it might not support
everything and not make any changes to be safe, or do something like
try to figure out that if we're currently at a given OPP that's the top
OPP possible.  Historically when we've not had regulator control in
these drivers so they have effectively gone with the first option of
just assuming it's a generally safe value, this often aligns with what
the power on requirements for SoCs are so it's not unreasonable.

I don't think that in a case of this particular driver there is a way to
make any decisions other than to assume that all changes are safe to be
done if regulator isn't specified in a device-tree.

If regulator_get() returns a dummy regulator, then this means that
regulator isn't specified in a device-tree. But then the only way for a
consumer driver to check whether regulator is dummy, is to check
presence of the supply property in a device-tree.

We want to emit error messages when something goes wrong, for example
when regulator voltage fails to change. It's fine that voltage changes
are failing for a dummy regulator, but then consumer driver shouldn't
recognize it as a error condition.

The regulator_get_optional() provides a more consistent and
straightforward way for consumer drivers to check presence of a physical
voltage regulator in comparison to dealing with a regulator_get(). The
dummy regulator is nice to use when there is no need to change
regulator's voltage, which doesn't work for a dummy regulator.