From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id 4D5BDAC0C8E for ; Fri, 12 Jan 2024 12:16:09 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=MgDph4e+sGi2L1cl2rvv2X9+1bzdWjyWS9qMqOAFwKk=; c=relaxed/simple; d=groups.io; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:To:Cc:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Type; s=20140610; t=1705061768; v=1; b=iomasAbLxaMEpxV9Fn18AZYMRkMct1TQPHII1n33mZvcSbBNMgLZvcVLlk3ocoH7ecZzUjHZ Z8AUpilMAlgCp0yUDNt8dc1rUzJc1c1MHLLZzsJVJk9n7te52qdRhfJjg+rJscSfAuaMh7oC7G9 bpXah6yiA/eiZoIWVQz+Ceh4= X-Received: by 127.0.0.2 with SMTP id QmesYY7687511xoI1HQ8jy5M; Fri, 12 Jan 2024 04:16:08 -0800 X-Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by mx.groups.io with SMTP id smtpd.web11.5679.1705061767199936541 for ; Fri, 12 Jan 2024 04:16:07 -0800 X-Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by ams.source.kernel.org (Postfix) with ESMTP id 73262B81CC0 for ; Fri, 12 Jan 2024 12:16:05 +0000 (UTC) X-Received: by smtp.kernel.org (Postfix) with ESMTPSA id C9239C433F1 for ; Fri, 12 Jan 2024 12:16:04 +0000 (UTC) X-Received: by mail-lj1-f177.google.com with SMTP id 38308e7fff4ca-2cd7e429429so32094271fa.1 for ; Fri, 12 Jan 2024 04:16:04 -0800 (PST) X-Gm-Message-State: 3YxrTg49ibOImKvL9KZSCqqXx7686176AA= X-Google-Smtp-Source: AGHT+IFEJdRjLxbM+N6sZ9mnFrF5KlBdwE6gxF7V0CWxBXxHwuX7mGf16/malsDW3G9kZsTjynnMc4Q0xlaNoXVcp5E= X-Received: by 2002:a2e:9155:0:b0:2cc:671c:a449 with SMTP id q21-20020a2e9155000000b002cc671ca449mr769852ljg.2.1705061763033; Fri, 12 Jan 2024 04:16:03 -0800 (PST) MIME-Version: 1.0 References: <20240112113754.14710-1-kraxel@redhat.com> <20240112113754.14710-4-kraxel@redhat.com> In-Reply-To: <20240112113754.14710-4-kraxel@redhat.com> From: "Ard Biesheuvel" Date: Fri, 12 Jan 2024 13:15:52 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [PATCH 3/4] OvmfPkg/VirtNorFlashDxe: allow larger writes without block erase To: Gerd Hoffmann Cc: devel@edk2.groups.io, Laszlo Ersek , Jiewen Yao , oliver@redhat.com Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,ardb@kernel.org List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: Content-Type: text/plain; charset="UTF-8" X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=iomasAbL; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io On Fri, 12 Jan 2024 at 12:38, Gerd Hoffmann wrote: > > Raise the limit for writes without block erase from two to four > P30_MAX_BUFFER_SIZE_IN_BYTES blocks. With this in place almost > all efi variable updates are handled without block erase. With > the old limit some variable updates (with device paths) took the > block erase code path. > > Signed-off-by: Gerd Hoffmann > --- > OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c b/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c > index 90db12716a4c..c631ffd3a62d 100644 > --- a/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c > +++ b/OvmfPkg/VirtNorFlashDxe/VirtNorFlash.c > @@ -555,7 +555,7 @@ NorFlashWriteSingleBlock ( > // To avoid pathological cases were a 2 byte write is disregarded because it > // occurs right at a 128 byte buffered write alignment boundary, permit up to > // twice the max buffer size, and perform two writes if needed. Please update the comment > - if ((*NumBytes + (Offset & BOUNDARY_OF_32_WORDS)) <= (2 * P30_MAX_BUFFER_SIZE_IN_BYTES)) { > + if ((*NumBytes + (Offset & BOUNDARY_OF_32_WORDS)) <= (4 * P30_MAX_BUFFER_SIZE_IN_BYTES)) { > // Check to see if we need to erase before programming the data into NOR. > // If the destination bits are only changing from 1s to 0s we can just write. > // After a block is erased all bits in the block is set to 1. Reviewed-by: Ard Biesheuvel -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#113728): https://edk2.groups.io/g/devel/message/113728 Mute This Topic: https://groups.io/mt/103680934/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=-=-=-=-=-=-=-=-=-=-=-