[PATCH v2 2/2] power: pmic: fix regulators behaviour

[Svyatoslav Ryhel]

16 липня 2023 р. 16:08:10 GMT+03:00, Simon Glass <sjg at chromium.org> написав(-ла):
>Hi Svyatoslav,
>
>On Sat, 15 Jul 2023 at 22:08, Svyatoslav Ryhel <clamor95 at gmail.com> wrote:
>>
>>
>>
>> 16 липня 2023 р. 02:40:37 GMT+03:00, Simon Glass <sjg at chromium.org> написав(-ла):
>> >Hi Svyatoslav,
>> >
>> >On Sat, 15 Jul 2023 at 12:34, Svyatoslav Ryhel <clamor95 at gmail.com> wrote:
>> >>
>> >> Currently device tree entries of regulators are completely
>> >> ignored and regulators are probed only if they are called
>> >> by the device which uses it. This results into two issues:
>> >> regulators which must run under boot-on or always-on mode
>> >> are ignored and not enabled; dts props like voltage are
>> >> not applied to the regulator so the regulator may be enabled
>> >> with random actual voltage, which may have unexpected
>> >> consequences.
>> >>
>> >> This patch changes this behavior. Post-probe function is
>> >> introduced which performs probing of each pmics child and if
>> >> it is a regulator, regulator_autoset function is called, which
>> >> handles always-on and boot-on regulators, but if none of those
>> >> props are set, the regulator is disabled.
>> >>
>> >> Later disabled regulators can be re-enabled by devices which
>> >> use them without issues.
>> >>
>> >> Signed-off-by: Svyatoslav Ryhel <clamor95 at gmail.com>
>> >> ---
>> >>  drivers/power/pmic/pmic-uclass.c | 18 ++++++++++++++++++
>> >>  1 file changed, 18 insertions(+)
>> >
>> >Can you add a test for this to test/dm/pmic.c ?
>> >
>>
>> Sure, may you specify what I should add to tests/dm/pmic.c? Which behavior is needed?
>
>Just for the change you are making...you should be able to check that
>it sets the regulators if you make sure there are some autoset ones in
>sandbox.

Easier to tell then to do. I am basically interfering into device establishment process. If smth goes wrong, any regulator related test should fail. At least my devices refused to boot/gave unexpected behavior while developing. I will look if I can find anything meaningful.

>>
>> >>
>> >> diff --git a/drivers/power/pmic/pmic-uclass.c b/drivers/power/pmic/pmic-uclass.c
>> >> index 0e2f5e1f41..8a26b519c9 100644
>> >> --- a/drivers/power/pmic/pmic-uclass.c
>> >> +++ b/drivers/power/pmic/pmic-uclass.c
>> >> @@ -16,6 +16,7 @@
>> >>  #include <dm/device-internal.h>
>> >>  #include <dm/uclass-internal.h>
>> >>  #include <power/pmic.h>
>> >> +#include <power/regulator.h>
>> >>  #include <linux/ctype.h>
>> >>
>> >>  #if CONFIG_IS_ENABLED(PMIC_CHILDREN)
>> >> @@ -198,9 +199,26 @@ static int pmic_pre_probe(struct udevice *dev)
>> >>         return 0;
>> >>  }
>> >>
>> >> +static int pmic_post_probe(struct udevice *dev)
>> >> +{
>> >> +       struct udevice *child;
>> >> +       int ret;
>> >> +
>> >> +       device_foreach_child_probe(child, dev) {
>> >> +               if (device_get_uclass_id(child) == UCLASS_REGULATOR) {
>> >> +                       ret = regulator_autoset(child);
>> >> +                       if (ret == -EMEDIUMTYPE)
>> >> +                               regulator_set_enable(child, false);
>> >> +               };
>> >> +       };
>> >> +
>> >> +       return 0;
>> >> +}
>> >> +
>> >>  UCLASS_DRIVER(pmic) = {
>> >>         .id             = UCLASS_PMIC,
>> >>         .name           = "pmic",
>> >>         .pre_probe      = pmic_pre_probe,
>> >> +       .post_probe     = pmic_post_probe,
>> >>         .per_device_auto        = sizeof(struct uc_pmic_priv),
>> >>  };
>> >> --
>> >> 2.39.2
>> >>
>> >
>> >Regards,
>> >Simon
>
>Regards,
>Simon