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  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sun, 22 Nov 2020 15:43:33 +0100
From:   Jan Kiszka <jan.kiszka@...mens.com>
To:     Qu Wenruo <wqu@...e.com>,
        Michał Mirosław <mirq-linux@...e.qmqm.pl>,
        Maxime Coquelin <mcoquelin.stm32@...il.com>,
        Alexandre Torgue <alexandre.torgue@...com>
Cc:     Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        broonie@...nel.org
Subject: Re: About regression caused by commit aea6cb99703e ("regulator:
 resolve supply after creating regulator")

On 09.11.20 00:28, Qu Wenruo wrote:
> 
> 
> On 2020/11/9 上午1:18, Michał Mirosław wrote:
>> On Sun, Nov 08, 2020 at 03:35:33PM +0800, Qu Wenruo wrote:
>>> Hi Michał,
>>>
>>> Recently when testing v5.10-rc2, I found my RK3399 boards failed to boot
>>> from NVME.
>>>
>>> It turns out that, commit aea6cb99703e ("regulator: resolve supply after
>>> creating regulator") seems to be the cause.
>>>
>>> In RK3399 board, vpcie1v8 and vpcie0v9 of the pcie controller is
>>> provided by RK808 regulator.
>>> With that commit, now RK808 regulator fails to register:
>>>
>>> [    1.402500] rk808-regulator rk808-regulator: there is no dvs0 gpio
>>> [    1.403104] rk808-regulator rk808-regulator: there is no dvs1 gpio
>>> [    1.419856] rk808 0-001b: failed to register 12 regulator
>>> [    1.422801] rk808-regulator: probe of rk808-regulator failed with
>>> error -22
>>
>> Hi,
>>
>> This looks lika the problem fixed by commit cf1ad559a20d ("regulator: defer
>> probe when trying to get voltage from unresolved supply") recently accepted
>> to regulator tree [1]. Can you verify this?
> 
> Thanks, tested with that commit cherry picked to v5.10-rc2 and it solves
> the problem.
> 

We are still missing some magic fix for stable trees: On the STM32MP15x,
things are broken since 5.4.73 now. And 5.9.y is not booting as well on
that board. Reverting the original commit make it boot again.

Linus master is fine, though, but I'm tired of bisecting. Any
suggestions? Or is there something queued up already?

In any case: Is that board in no stable Q&A farm? It's a basic "boot
fails" regression.

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Powered by blists - more mailing lists