[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <d2030810-a307-0438-d4b0-be6aa092e551@kernel.org>
Date: Tue, 9 Mar 2021 21:56:30 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Martin Kepplinger <martin.kepplinger@...i.sm>,
alice.guo@....nxp.com
Cc: devicetree@...r.kernel.org, festevam@...il.com,
kernel@...gutronix.de, linux-arm-kernel@...ts.infradead.org,
linux-imx@....com, linux-kernel@...r.kernel.org, robh@...nel.org,
s.hauer@...gutronix.de, shawnguo@...nel.org
Subject: Re: [PATCH] arm64: dts: imx8mq: remove SoC ID compatible
On 09/03/2021 14:42, Martin Kepplinger wrote:
> this reverts commit ce58459d8c7f4174e7b8a8ea903dd949631334a3 for imx8mq.
>
> this is most likely not the real fix but works around the problem I have
> (with v5.12-rc2) I want to report:
>
> [ 0.766925] SoC revision 0x21
> [ 0.770286] imx8_soc_info soc@0: SoC revision via nvmem read failed: -517
>
> This leads to the system not booting up.
>
> This change makes use of the old way of reading soc_revision and thus
> works around the problem.
>
> What could be missing for the nvmem way to work here? Should it work
> in any case? I assume so if you add the compatible to imx8mq.dtsi. But
> if it would work, why keep the ocotp reads?
Hi,
Thanks for the report. 517 is deferred probe, so this could mean that
efuse/ocotp did not come up yet. However soc_id driver should handle it
and re-try after some try, shouldn't it? Unless there is a bug inside
(your change basically disables soc_id driver).
Best regards,
Krzysztof
Powered by blists - more mailing lists