On Thu, Oct 28, 2021 at 06:50:58AM +0000, Richard Zhu wrote:

quoted

I would be really surprised to see PCI hardware that was able to support a
supply being physically absent, and this use of _is_enabled() is quite
simply not how any of this is supposed to work in the regulator API even
for regulators that can be optional.

[Richard Zhu] Actually, this regulator is one GPIO fixed regulator.
Controlled by SW to turn on (GPIO high) or turn off (GPIO low) the supply.
In some boards designs, this supply might be always on(GPIO high).
So, in point of SW driver view, this regulator is optional.

No, it's not.  The regulator API supports the systems where the
regualtor is always on perfectly well, the client driver should not need
to do anything to support them.

quoted

Perhaps it's not causing problems in this design but if the supply is ever
shared with anything else then the software will run into trouble.
There will also be problems with the error handling on a system where
the regulator needs to be controlled.

[Richard Zhu] This GPIO fixed regulator is only used by controller driver.
It makes sense to disable the enabled regulator when driver probe is failed.

The driver should undo any enables it did itself, it should not undo any
enables that anything else did which means it should never be basing
decisions on regulator_is_enabled().  While the regulator may not be
shared in the particular board you're looking at it may be shared in
other systems.