From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id D7914C77B73 for ; Thu, 20 Apr 2023 11:17:03 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 7800A862FD; Thu, 20 Apr 2023 13:17:01 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=metanate.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=metanate.com header.i=@metanate.com header.b="KOPvnzKi"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 09FC78631A; Thu, 20 Apr 2023 13:16:59 +0200 (CEST) Received: from metanate.com (unknown [IPv6:2001:8b0:1628:5005::111]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id D571B85D63 for ; Thu, 20 Apr 2023 13:16:55 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=metanate.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=john@metanate.com DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=metanate.com; s=stronger; h=In-Reply-To:Content-Type:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description; bh=owv9/Iwc9lMOKj1SJYcCJgqOCsG3TkN9KMmMJe0/esY=; b=KOPvn zKiJUCpfJ9qlI0johdfvlaQFSMxd/fXQBuMfh8NKNzxQYyjLZcqJfXMaCzLFJtIFeQuNZ03XsfSji RplmQOS3tBsHpTZZYV2O2n1VYLL3tnaPt4Gi36kRJWU1mRnvYeuRrd4pDHlk69/SooHZp6CepSm2m 9vAH43Y/2rxVhRo9sdoPQi9kAc5236oyTo+l03PNQqy2lLlr9NGQU921rh//4Prxn4v7WjiR7D0G1 OTgh2AcgN/hhIk3CA7bkz/yTCRDPcazJpJ6pu4hpLi1zwpYqgY+Etg42+kl8HwJ1wJe3UKLSo9yqn SyOZyytX/WR9AOxo5zIRHjXXtlxzA==; Received: from [81.174.171.191] (helo=donbot) by email.metanate.com with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1ppSHQ-0007hR-3V; Thu, 20 Apr 2023 12:16:49 +0100 Date: Thu, 20 Apr 2023 12:16:48 +0100 From: John Keeping To: Jonas Karlman Cc: Simon Glass , Philipp Tomsich , Kever Yang , u-boot@lists.denx.de Subject: Re: [PATCH] rockchip: efuse: fix rk3399 reading multiple values Message-ID: References: <20230417160914.2838607-1-john@metanate.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Authenticated: YES X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.8 at phobos.denx.de X-Virus-Status: Clean On Mon, Apr 17, 2023 at 06:58:30PM +0100, John Keeping wrote: > On Mon, Apr 17, 2023 at 05:39:24PM +0000, Jonas Karlman wrote: > > On 2023-04-17 18:09, John Keeping wrote: > > > Update rk3399 to match the pattern in the other device-specific > > > implementations to ensure the previous address is cleared when reading > > > multiple blocks. > > > > Does this fix a real issue for you? > > > > Compared to the other device-specific implementations this reg behaves > > differently on RK3399. The addr field is not read back, or it gets > > auto-cleared when EFUSE_STROBE is cleared, the use of clrsetbits_le32 > > may mislead that this reg holds the addr value from prior iteration. > > I don't have an RK3399 to test with, but I spotted this when > experimenting with RK3288's secure efuse which has a similar layout to > the RK3399 efuses. > > Having looked through the RK3399 TRM, I can't see anything about the > address auto-clearing and the documentation for redundancy read mode > requiring two strobe cycles suggests that the address is preserved. > > Howe are you testing reads? dump_efuse only reads one block at a time > so it isn't sufficient to trigger an issue here as there is an > unconditional write to EFUSE_CTRL before this loop. I found an RK3399 which I had for a previous project and have now tested this - I can't see any evidence of the address auto-clearing so it looks to me like this patch fixes a real issue. > > > > > > Signed-off-by: John Keeping > > > --- > > > drivers/misc/rockchip-efuse.c | 4 ++-- > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/misc/rockchip-efuse.c b/drivers/misc/rockchip-efuse.c > > > index 2f96b79ea4..d302271239 100644 > > > --- a/drivers/misc/rockchip-efuse.c > > > +++ b/drivers/misc/rockchip-efuse.c > > > @@ -207,8 +207,8 @@ static int rockchip_rk3399_efuse_read(struct udevice *dev, int offset, > > > udelay(1); > > > > > > while (size--) { > > > - setbits_le32(efuse->base + EFUSE_CTRL, > > > - EFUSE_STROBE | RK3399_ADDR(offset++)); > > > + clrsetbits_le32(efuse->base + EFUSE_CTRL, RK3399_A_MASK, > > > + EFUSE_STROBE | RK3399_ADDR(offset++)); > > > udelay(1); > > > *buffer++ = readl(efuse->base + EFUSE_DOUT); > > > clrbits_le32(efuse->base + EFUSE_CTRL, EFUSE_STROBE); > >