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 8D4CFC77B7A for ; Mon, 17 Apr 2023 17:58:41 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 5D22486003; Mon, 17 Apr 2023 19:58:39 +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="zY8d/vVj"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 4C9628600C; Mon, 17 Apr 2023 19:58:37 +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 198C785AA1 for ; Mon, 17 Apr 2023 19:58:35 +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=C+Ke508rYx+FQSYlEUwWaUQjAbbT6CXMxO8RJaZXjBY=; b=zY8d/ vVj7U31sL3j3QihuLu58wdnX83DjHFIR3/EZEy0Y8jm0O5KP5iB7g0WdhQT/QOy/dOoNXbByY7Mr9 No2A3ysWRrWGEYc4fd5fz/s7uIC1LAQli6Mx0RhCJSwB07F+wC5NiyN7+/TULh6TGNgQUIdw7znOA LXlZlk5qf8xT8zq1tQ+VhxzswDruAsgm+SEOOKvv/nhV1/tstp+j7rmdqCHsxkHanYMbzyv5zWUmZ c1OaphMgYrfWR0htwo+BkAjnvAalKMAZNGOBOi1fJsFNPByyv/pkz5lZYVuvAgS+a3rOOSuZ1gif/ 6tEE64WCjEA1zz/fh0Uv1u/QjgyeA==; 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 1poT7U-00039V-O7; Mon, 17 Apr 2023 18:58:30 +0100 Date: Mon, 17 Apr 2023 18:58:24 +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 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. > > > > 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); >