From patchwork Sat Dec 7 04:42:02 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Simon Glass X-Patchwork-Id: 1205362 X-Patchwork-Delegate: bmeng.cn@gmail.com Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=lists.denx.de (client-ip=85.214.62.61; helo=phobos.denx.de; envelope-from=u-boot-bounces@lists.denx.de; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=chromium.org header.i=@chromium.org header.b="MG8hSXTq"; dkim-atps=neutral Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 47VH930Skxz9sPL for ; Sat, 7 Dec 2019 15:51:18 +1100 (AEDT) Received: from phobos.denx.de (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 6E2768170D; Sat, 7 Dec 2019 05:47:57 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=chromium.org header.i=@chromium.org header.b="MG8hSXTq"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 93E2C81709; Sat, 7 Dec 2019 05:47:52 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on phobos.denx.de X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,SPF_HELO_NONE,TVD_PH_BODY_ACCOUNTS_PRE, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from mail-il1-x141.google.com (mail-il1-x141.google.com [IPv6:2607:f8b0:4864:20::141]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id DE90481707 for ; Sat, 7 Dec 2019 05:47:49 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=sjg@chromium.org Received: by mail-il1-x141.google.com with SMTP id z90so8110436ilc.8 for ; Fri, 06 Dec 2019 20:47:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=iJDysTb9kExFMrTFoubw4VKJbdA0XYBbQKANxgCyStQ=; b=MG8hSXTqga3p5jnk4xdzVUeshxkdqysQ7aR48LNGlCjqmby+581g+YeRWH2p7uPISU PPdH87O+asCxTvzlgHPateOJvrlA0DLkdB9/aEXnPCJxXsZjzHcVT0kEuo0POV1olzlb aHwUivY66D15wPEoF9z3jSx03rO6PXtHso750= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=iJDysTb9kExFMrTFoubw4VKJbdA0XYBbQKANxgCyStQ=; b=HrGcXUV/BiSfC60XbW5XCBGqyrVpQTQe6wmm8qT59kvpO3kNehiegrQI2L7sfOLACz +lKmduqUbyaYCSbCk1/jwoe9wUrNgnPPL7+7IDB/mWfu1ZLNqmiRhPbALQHACbeVQHDD UysKUypUFi2eymzMxaaq/NGBJiNQYmMOXKtZ2myLIKFfCQzH6AI0IBsp6y/6zcsnyAca yoh37f69zIaEay291GNVq+DFeEUm8JtjB+/zYmm83SZlqYKS80tv8aWyG19UwgLpZzTz qsjXtUERNq9XBWj9kFgO6R90/G31cRajlDwCj0BogqEgzMSq9LwyVzzlitcaLTzbmckE bXVg== X-Gm-Message-State: APjAAAUPeFquShwKAJFswSRyO9Dec3qG4WmsnLphJ9owNfjbzq2NL/y2 GCvOB6FTc30ngAIXua+emrpdrfa/7H0= X-Google-Smtp-Source: APXvYqySG+b7LgYV1zqaXqO8jKXqdzZIdc/XS/h48NzlQnnCaCZAVjYHLlXPprZ00R4NVQ4lSov5qw== X-Received: by 2002:a92:5d92:: with SMTP id e18mr3098546ilg.75.1575694068685; Fri, 06 Dec 2019 20:47:48 -0800 (PST) Received: from kiwi.bld.corp.google.com ([2620:15c:183:0:8223:87c:a681:66aa]) by smtp.gmail.com with ESMTPSA id o7sm4549410ilo.58.2019.12.06.20.47.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 Dec 2019 20:47:48 -0800 (PST) From: Simon Glass To: U-Boot Mailing List Subject: [PATCH v6 029/102] x86: Correct mrccache find_next_mrc_cache() calculation Date: Fri, 6 Dec 2019 21:42:02 -0700 Message-Id: <20191206213936.v6.29.I73b4396e3d9bb2ef5dd5d745e4f7df6652047567@changeid> X-Mailer: git-send-email 2.24.0.393.g34dc348eaf-goog In-Reply-To: <20191207044315.51770-1-sjg@chromium.org> References: <20191207044315.51770-1-sjg@chromium.org> MIME-Version: 1.0 X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.26 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.101.4 at phobos.denx.de X-Virus-Status: Clean This should take account of the end of the new cache record since a record cannot extend beyond the end of the flash region. This problem was not seen before due to the alignment of the relatively small amount of MRC data. But with Apollo Lake the MRC data is about 45KB, even if most of it is zeroes. Fix this bug and update the parameter name to be less confusing. Signed-off-by: Simon Glass Reviewed-by: Bin Meng --- Changes in v6: None Changes in v5: None Changes in v4: - Add comments about MRC-cache records being the same size - apollolake -> Apollo Lake Changes in v3: - Add an extra size parameter to the find_next_mrc_cache() function Changes in v2: None arch/x86/lib/mrccache.c | 18 ++++++++++++++---- 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/arch/x86/lib/mrccache.c b/arch/x86/lib/mrccache.c index 33bb52039b..9d56685d36 100644 --- a/arch/x86/lib/mrccache.c +++ b/arch/x86/lib/mrccache.c @@ -80,21 +80,31 @@ struct mrc_data_container *mrccache_find_current(struct mrc_region *entry) /** * find_next_mrc_cache() - get next cache entry * + * This moves to the next cache entry in the region, making sure it has enough + * space to hold data of size @data_size. + * * @entry: MRC cache flash area * @cache: Entry to start from + * @data_size: Required data size of the new entry. Note that we assume that + * all cache entries are the same size * * @return next cache entry if found, NULL if we got to the end */ static struct mrc_data_container *find_next_mrc_cache(struct mrc_region *entry, - struct mrc_data_container *cache) + struct mrc_data_container *prev, int data_size) { + struct mrc_data_container *cache; ulong base_addr, end_addr; base_addr = entry->base + entry->offset; end_addr = base_addr + entry->length; - cache = next_mrc_block(cache); - if ((ulong)cache >= end_addr) { + /* + * We assume that all cache entries are the same size, but let's use + * data_size here for clarity. + */ + cache = next_mrc_block(prev); + if ((ulong)cache + mrc_block_size(data_size) > end_addr) { /* Crossed the boundary */ cache = NULL; debug("%s: no available entries found\n", __func__); @@ -131,7 +141,7 @@ int mrccache_update(struct udevice *sf, struct mrc_region *entry, /* Move to the next block, which will be the first unused block */ if (cache) - cache = find_next_mrc_cache(entry, cache); + cache = find_next_mrc_cache(entry, cache, cur->data_size); /* * If we have got to the end, erase the entire mrc-cache area and start