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

[Simon Glass]

Hi Svyatoslav,

On Sun, 16 Jul 2023 at 07:20, Svyatoslav Ryhel <clamor95 at gmail.com> wrote:
>
>
>
> 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.

Something like this in test/dm/regulator.c:

struct udevice *pmic, *reg;

// This should automatically probe the
ut_asserok(pmic_get("pmic at 41"), &pmic);

// Check that the regulators are probed and on
ut_assertok(regulator_get_by_devname("ldo2", &reg));
ut_assert(regulator_get_enable(reg));

See test.dtsi and sandbox_pmic.dtsi for the DT nodes. You'll need to
update ldo2 t too add the properties to cause an autoset.

Regards,
Simon