From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751752AbdISMTE (ORCPT ); Tue, 19 Sep 2017 08:19:04 -0400 Received: from hermes.aosc.io ([199.195.250.187]:52351 "EHLO hermes.aosc.io" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751109AbdISMTC (ORCPT ); Tue, 19 Sep 2017 08:19:02 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Tue, 19 Sep 2017 20:19:01 +0800 From: icenowy@aosc.io To: Maxime Ripard Cc: Srinivas Kandagatla , Chen-Yu Tsai , devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-sunxi@googlegroups.com Subject: Re: [linux-sunxi] Re: [PATCH] nvmem: sunxi-sid: add support for A64/H5's SID controller In-Reply-To: <20170919115502.exfbpdwb3c3eenee@flea.lan> References: <20170918154204.54427-1-icenowy@aosc.io> <20170919082019.6bopwauso4mbslqo@flea.lan> <20170919115502.exfbpdwb3c3eenee@flea.lan> Message-ID: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 在 2017-09-19 19:55，Maxime Ripard 写道： > On Tue, Sep 19, 2017 at 04:23:14PM +0800, Icenowy Zheng wrote: >> >> >> 于 2017年9月19日 GMT+08:00 下午4:20:19, Maxime Ripard >> 写到: >> >On Mon, Sep 18, 2017 at 11:42:04PM +0800, Icenowy Zheng wrote: >> >> Allwinner A64/H5 SoCs come with a SID controller like the one in H3, >> >but >> >> without the silicon bug that makes the initial value at 0x200 wrong, >> >so >> >> the value at 0x200 can be directly read. >> >> >> >> Add support for this kind of SID controller. >> >> >> >> Signed-off-by: Icenowy Zheng >> >> --- >> >> Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt | 1 >> >+ >> >> drivers/nvmem/sunxi_sid.c | 6 >> >++++++ >> >> 2 files changed, 7 insertions(+) >> >> >> >> diff --git >> >a/Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt >> >b/Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt >> >> index ef06d061913c..6ea0836939ee 100644 >> >> --- a/Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt >> >> +++ b/Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt >> >> @@ -5,6 +5,7 @@ Required properties: >> >> "allwinner,sun4i-a10-sid" >> >> "allwinner,sun7i-a20-sid" >> >> "allwinner,sun8i-h3-sid" >> >> + "allwinner,sun50i-a64-sid" >> >> >> >> - reg: Should contain registers location and length >> >> >> >> diff --git a/drivers/nvmem/sunxi_sid.c b/drivers/nvmem/sunxi_sid.c >> >> index 0d6648be93b8..3c9fd4fb9207 100644 >> >> --- a/drivers/nvmem/sunxi_sid.c >> >> +++ b/drivers/nvmem/sunxi_sid.c >> >> @@ -199,10 +199,16 @@ static const struct sunxi_sid_cfg sun8i_h3_cfg >> >= { >> >> .need_register_readout = true, >> >> }; >> >> >> >> +static const struct sunxi_sid_cfg sun50i_a64_cfg = { >> >> + .value_offset = 0x200, >> >> + .size = 0x100, >> >> +}; >> >> + >> > >> >How did you get those values? >> >> In the BSP U-Boot headers. > > This should be mentionned in your commit log then. P.S. the 0x200 offset is not in the header, but as a proven experience on new generation SID controllers. > >> >Also, it's reported that the SID can only be accessed in secure >> >mode, did you test it? >> >> Yes, however the secure is broken again, and this only >> happen if Secure Boot bit is burned. > > Is broken again, meaning? > > As far as I know, the only breakage we've had is on the A80 / A83T, > but we don't have anything like it on the A64, do we? A80/A83T is not the *only* breakage, but the *most serious* breakage, which affected correctly using SMP in non-secure. Newer Allwinner SoCs doesn't have the GIC broken, but the TZPC still doesn't work when not Secure Boot, which means that all peripherals set to secure-only can still be accessed. Affected SoCs are at least H3, H5, A64. It seems that the registers marked as secure-only inside PRCM still works -- however this still has no meaningful secure/non-secure seperation, as the secure setting register in PRCM is not secure-only at least on SoCs without SB enabled. > >> If it's really burned, we will have no clean way to access SID. > > Well, in such a case we shouldn't access it either, so.. We will need the THS calibration data. Maybe a custom call to ATF can be created, but I consider it dirty. > > Maxime