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. Hope that makes sense, Andrew > > > > With this in place devicetree validation can catch issues like this: > > > > /mnt/extrassd/git/linux-next/arch/arm64/boot/dts/qcom/sm8350-hdk.dtb: pm8350-rpmh-regulators: ldo5: 'regulator-allowed-modes' is a dependency of 'regulator-allow-set-load' > > From schema: /mnt/extrassd/git/linux-next/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml > > > > Suggested-by: Johan Hovold <johan@xxxxxxxxxx> > > Signed-off-by: Andrew Halaney <ahalaney@xxxxxxxxxx> > > > Best regards, > Krzysztof >
