On 06/09/2022 16:41, Andrew Halaney wrote: > On Mon, Sep 05, 2022 at 06:50:02PM +0200, Krzysztof Kozlowski wrote: >> On 02/09/2022 20:51, Andrew Halaney wrote: >>> For RPMH regulators it doesn't make sense to indicate >>> regulator-allow-set-load without saying what modes you can switch to, >>> so be sure to indicate a dependency on regulator-allowed-modes. >> >> Hmmmm.... What about other regulators? >> > > My understanding (which very well might be wrong) is that if your > regulator is allowed to change modes, and sets regulator-allow-set-load, > then you have to describe what modes you can switch to. >> But if you don't allow setting modes (for example qcom_rpm-regulator.c) > and just allow yourself to set_load() directly, then you don't need it. > > So there is a more general requirement that applies regulator wide, but > I'm not sure how you would apply that at a higher level. I don't see a > good way to figure out in dt-binding land what regulator ops each > binding supports. The bindings don't express it, but the regulator core explicitly asks for set_mode with set_load callbacks in drms_uA_update(), which depends on REGULATOR_CHANGE_DRMS (toggled with regulator-allow-set-load). drms_uA_update() later calls regulator_mode_constrain() which checks if mode changing is allowed (REGULATOR_CHANGE_MODE). Therefore based on current implementation and meaning of set-load/allowed-modes properties, I would say that this applies to all regulators. I don't think that RPMh is special here. Best regards, Krzysztof
