Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <a78822d5-f0a1-6c42-8269-e8168ea5cd5b@samsung.com>
Date:   Thu, 25 Aug 2022 16:23:23 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0)
        Gecko/20100101 Thunderbird/91.12.0
Subject: Re: [PATCH v4] regulator: core: Resolve supply name earlier to
 prevent double-init
Content-Language: en-US
To:     Mark Brown <broonie@kernel.org>
Cc:     =?UTF-8?Q?Christian_Kohlschu=cc=88tter?= 
        <christian@kohlschutter.com>, heiko@sntech.de, lgirdwood@gmail.com,
        linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
        linux-mmc@vger.kernel.org, linux-rockchip@lists.infradead.org,
        m.reichl@fivetechno.de, robin.murphy@arm.com,
        vincent.legoll@gmail.com, wens@kernel.org
From:   Marek Szyprowski <m.szyprowski@samsung.com>
In-Reply-To: <YwdpOX0xCzYwhjmx@sirena.org.uk>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="utf-8"
CMS-TYPE: 201P
References: <YvorNPDQQr2SH/NF@sirena.org.uk>
        <20220818124646.6005-1-christian@kohlschutter.com>
        <CGME20220825113251eucas1p247c3d57de823da148ca4790975a4aba8@eucas1p2.samsung.com>
        <58b92e75-f373-dae7-7031-8abd465bb874@samsung.com>
        <YwdpOX0xCzYwhjmx@sirena.org.uk>
Precedence: bulk

Hi Mark,

On 25.08.2022 14:21, Mark Brown wrote:
> On Thu, Aug 25, 2022 at 01:32:50PM +0200, Marek Szyprowski wrote:
>
>> This patch landed recently in linux next as commit 8a866d527ac0
>> ("regulator: core: Resolve supply name earlier to prevent double-init").
>> Unfortunately it breaks booting of Samsung Exynos 5800 based Peach-Pi
>> (arch/arm/boot/dts/exynos5800-peach-pi.dts) and Peach-Pit
>> (arch/arm/boot/dts/exynos5420-peach-pit.dts) Chromebooks. The last
>> message in the kernel log is a message about disabling 'vdd_1v2'
>> regulator. This regulator is not used directly, however it is a supply
>> for other critical regulators.
> This suggests that supplies are ending up not getting bound.  Could you
> perhaps add logging to check that we're attempting to resolve the supply
> (in the
>
>
> +       if ((rdev->supply_name && !rdev->supply) &&
> +                       (rdev->constraints->always_on ||
> +                        rdev->constraints->boot_on)) {
>
> block)?


I've spent a little time debugging this issue and here are my findings. 
The problem is during the 'vdd_mif' regulator registration. It has one 
supply called 'inb1' and provided by 'vdd_1v2' regulator. Both 'vdd_mif' 
and 'vdd_1v2' regulators are provided by the same PMIC.

The problem is that 'inb1' supply is being routed to dummy regulator 
after this change. The regulator_resolve_supply(), which is just after 
the above mentioned check, returns 0 and bounds 'vdd_mif' supply to 
dummy-regulator. This happens because regulator_dev_lookup() called in 
regulator_resolve_supply() returns -19, what in turn lets the code to 
use dummy-regulator. I didn't check why it doesn't return -EPROBE_DEFER 
in that case yet.

> I'd also note that it's useful to paste the actual error
> messages you're seeing rather than just a description of them.

There is really nothing more that I can paste here:

[   32.306264] systemd-logind[1375]: New seat seat0.
[   32.331790] systemd-logind[1375]: Watching system buttons on 
/dev/input/event1 (gpio-keys)
[   32.550686] systemd-logind[1375]: Watching system buttons on 
/dev/input/event0 (cros_ec)
[   32.570493] systemd-logind[1375]: Failed to start user service, 
ignoring: Unknown unit: user@0.service
[   32.750913] systemd-logind[1375]: New session c1 of user root.
[   35.070357] vdd_1v2:

--- EOF ---


Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland