linux-kernel - Re: [PATCH 1/1] arm64: dts: allwinner: a64: olinuxino: Add VCC-PG supply

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Fri, 29 Nov 2019 15:34:04 +0800
From:   Chen-Yu Tsai <wens@...e.org>
To:     Stefan Mavrodiev <stefan@...mex.com>
Cc:     Maxime Ripard <mripard@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        "moderated list:ARM/Allwinner sunXi SoC support" 
        <linux-arm-kernel@...ts.infradead.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>,
        linux-sunxi <linux-sunxi@...glegroups.com>
Subject: Re: [PATCH 1/1] arm64: dts: allwinner: a64: olinuxino: Add VCC-PG supply

On Fri, Nov 29, 2019 at 3:22 PM Stefan Mavrodiev <stefan@...mex.com> wrote:
>
>
> On 11/28/19 12:33 PM, Maxime Ripard wrote:
> Hi Maxime,
> > Hi Stefan,
> >
> > On Wed, Nov 27, 2019 at 09:07:40AM +0200, Stefan Mavrodiev wrote:
> >> On 11/26/19 6:27 PM, Maxime Ripard wrote:
> >>> Hi Stefan,
> >>>
> >>> On Tue, Nov 26, 2019 at 01:05:08PM +0200, Stefan Mavrodiev wrote:
> >>>> On A64-OLinuXino boards, PG9 is used for USB1 enable/disable. The
> >>>> port is supplied by DLDO4, which is disabled by default. The patch
> >>>> adds the regulator as vcc-pg, which is later used by the pinctrl.
> >>>>
> >>>> Signed-off-by: Stefan Mavrodiev <stefan@...mex.com>
> >>>> ---
> >>>>    arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts | 4 ++++
> >>>>    1 file changed, 4 insertions(+)
> >>>>
> >>>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
> >>>> index 01a9a52edae4..c9d8c9c4ef20 100644
> >>>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
> >>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
> >>>> @@ -163,6 +163,10 @@
> >>>>            status = "okay";
> >>>>    };
> >>>>
> >>>> +&pio {
> >>>> +  vcc-pg-supply=<&reg_dldo4>;
> >>> The equal sign should have spaces around it.
> >>>
> >>> Also, can you please list all the bank supplies while you're at it?
> >> Sure. Should the supplies defined as regulators names be added also to the
> >> pio node?
> >> For example reg_aldo1 is named "vcc-pe".
> > As far as I can tell, the A64 has regulators for PC, PD, PE, PG and
> > PL, so you should list those (PL being under r_pio)
>
> After quick check I've found a bug (maybe?). It's not possible to specify
> vcc-pl-supply, because of this:
>
> https://elixir.bootlin.com/linux/latest/source/drivers/pinctrl/sunxi/pinctrl-sunxi.c#L778
>
> During the probe of the pmu, the pinctrl tries to get a regulator, that
> doesn't exist yet.
> Because of this the system doesn't start (as expected).

It's a circular dependency. The pinctrl driver requires a regulator, which
is provided by the PMIC, which requires the pinctrl driver to mux a pin
for the bus.

For now there's no way to fix it, other than breaking the dependency.

> I've tried to ignore -EPROBE_DEFER. This seems to work, but only because
> the regulator for
> PL is defined as "regulator-always-on". The problem is that the refcount
> is not incremented.
> So if you export one gpio and the unexport it, the regulator will be
> disabled. I'm not sure
> how this can be resolved.
>
> Should I skip vcc-pl-supply for now and list the other bank supplies?

Yes. That is the preferred and probably only way to deal with it.
Please leave a comment saying why vcc-pl was skipped.

ChenYu

> >> Also, since the commit message will be different for better representation
> >> of the changes, should I send the next
> >> patch as v2 or as a new one?
> > Either way works for me as long as the commit message matches the changes.
> >
> > Thanks!
> > Maxime