linux-kernel - Re: ARM.STM32 - Mainline stable kernel 5.9.10 hangs indefinitely on a STM32MP157A-DK1 board.

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]

Message-Id: <N91BKQ.LV5OVN39B5VU2@gmail.com>
Date:   Tue, 24 Nov 2020 14:22:35 +0000
From:   Manuel Reis <mluis.reis@...il.com>
To:     Alexandre Torgue <alexandre.torgue@...com>
Cc:     mcoquelin.stm32@...il.com,
        Michał Mirosław <mirq-linux@...e.qmqm.pl>,
        linux-kernel@...r.kernel.org,
        Michael Opdenacker <michael.opdenacker@...tlin.com>
Subject: Re: ARM.STM32 - Mainline stable kernel 5.9.10 hangs indefinitely on
 a
 STM32MP157A-DK1 board.

Thank you very much Alex,

Tried, tested and verified. Got it working with stable/master 
(v5.10-rc5).

Regards,
Manuel

On ter, 24 nov, 2020 at 14:11, Alexandre Torgue 
<alexandre.torgue@...com> wrote:
> Hi Manuel
> 
> On 11/24/20 1:50 PM, Manuel Reis wrote:
>> To:     Maxime Coquelin <mcoquelin.stm32@...il.com>
>> To:     Alexandre Torgue <alexandre.torgue@...com>
>> Cc:    linux-kernel@...r.kernel.org
>> CC:    Michael Opdenacker <michael.opdenacker@...tlin.com>
>> 
>> Hi there,
>> 
>> Mainline stable kernel 5.9.10 hangs indefinitely on a 
>> STM32MP157A-DK1 Discovery Kit board.
>> 
>> Built plain vanilla 5.9.10 stable kernel for multi_v7_defconfig (set 
>> compression to XZ) using arm-linux-gnueabi-gcc (Ubuntu 
>> 10.2.0-8ubuntu1) 10.2.0.
>> 
>> Downloaded it to the board memory via tftp running U-Boot v2020.07. 
>> After boot, kernel initiates and prints several messages until it 
>> hangs on:
>> 
>> [ 2.692879] stpmic1 1-0033: PMIC Chip Version: 0x10
>> [ 2.704158] vddcore: supplied by regulator-dummy
>> [ 2.710304] vdd_ddr: supplied by regulator-dummy
>> [ 2.716414] vdd: supplied by regulator-dummy
>> [ 2.722355] v3v3: supplied by regulator-dummy
>> [ 2.728033] v1v8_audio: supplied by v3v3
>> [ 2.734287] v3v3_hdmi: supplied by regulator-dummy
>> [ 2.741035] vtt_ddr: supplied by vdd_ddr
>> [ 2.743833] vdd_usb: supplied by regulator-dummy
>> [ 2.751332] vdda: supplied by regulator-dummy
>> [ 2.757371] v1v2_hdmi: supplied by v3v3
>> 
>> No other information or indication is given, even though I added 
>> kernel debugging features such as the ones in "Kernel hacking 
>> ->Debug Oops, Lockups and Hangs".
>> 
>> Any help would be appreciated. Let me know if I can provide any 
>> further information.
>> 
> 
> It has been introduced by commit aea6cb99703e ("regulator: resolve 
> supply after creating regulator") and should fixed by this one:
> 
> cf1ad559a20d ("regulator: defer probe when trying to get voltage from 
> unresolved supply").
> 
> Should be taken in stable tree.
> 
> regards
> alex
> 
> 
>> Cheers,
>> Manuel
>>