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-next>] [day] [month] [year] [list]
Message-ID: <c13f1683-97c9-40b4-f740-73eaceb7c98f@suse.com>
Date:   Sun, 8 Nov 2020 15:35:33 +0800
From:   Qu Wenruo <wqu@...e.com>
To:     Michał Mirosław <mirq-linux@...e.qmqm.pl>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
CC:     broonie@...nel.org
Subject: About regression caused by commit aea6cb99703e ("regulator: resolve
 supply after creating regulator")

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

Since voltages from rk808 are not proper registered, then it prevents
the rockchip PCIE controller to find its voltage provider:

[    1.855276] rockchip_pcie_probe: parse_host_dt err=-517


I currently tested with that commit reverted, then the RK808 works again.

Is this a known regression? Or the RK808 device tree is out of spec?

It would help a lot to fix the problem before the regression makes all
RK3399 boards to lose their ability to initialize PCIE controller.


BTW I didn't find that patch submitted to mail lists like
linux-arm-kernel. I doubt if that commit really got enough testing from
arm community, especially considering that currently ARM is the biggest
user of device-tree and regulators.

Maybe it's a good idea to also submit such patches to arm related mail
lists next time?

Thanks,
Qu

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ