On Thu, Oct 28, 2021 at 06:50:58AM +0000, Richard Zhu wrote: > > 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. > > 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.
Attachment:
signature.asc
Description: PGP signature
