From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout02.his.huawei.com (canpmsgout02.his.huawei.com [113.46.200.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 123CC302CDB for ; Fri, 14 Nov 2025 09:28:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.217 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763112535; cv=none; b=np3sKsSvzAwaGNfFMWnig0ghkrvqntmiLcCpV3jNg9ky2va8n1HuIUkRNKF0d3v7JbtGVbvvu6whcJFoNHHDMpTyJWnmNBdp7hdfh7sqRWnMon03IlZHu+zgy8oVy47csXK7x+jb+pXUi9iCmXAfTFj0t/EMiOv6arbCTybEuls= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763112535; c=relaxed/simple; bh=Co3VklCZqIKXbjVFNDJF6WCAZsDXAw13qYqmEWW/+hs=; h=Subject:To:CC:References:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type; b=FEK0zQcAyAlSC+5TiMU5iPDQCUU9qvByG0ngEL5JwLxJ8/FMFmhmcMteQiX0LaF+wEYJ9xDaZfH5x0j3toJko2nqQGaa4/2mnGjKqn6tE9b2I9knar6wmnMI5mWaqWGsVBkg63ZkfPrPPPAI0KCB0azIKPDc8A62fU+6ST9mrMw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=qwQubv6p; arc=none smtp.client-ip=113.46.200.217 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="qwQubv6p" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=EPhjjw9jvWhXdsW7KJ+gvHj3YCMaaj9HqAmBiZasGfY=; b=qwQubv6piDdxYZtWXta0tQ03QhpAMHpJgtPEsx8kG0DdYmxU0TLhEC9HG84dpbnABvDRam/iq yxFZ6Sqwt/d0CftBV1nL2C89gkX0ORat9NlwHxq6U8LMhbHndmhxd8zgCIgzp8/h4wowtb2wi0V 9FDa/fmsBYbE3KqgkCd5BCA= Received: from mail.maildlp.com (unknown [172.19.163.252]) by canpmsgout02.his.huawei.com (SkyGuard) with ESMTPS id 4d7Bbt13KWzcb1j; Fri, 14 Nov 2025 17:26:50 +0800 (CST) Received: from kwepemk500005.china.huawei.com (unknown [7.202.194.90]) by mail.maildlp.com (Postfix) with ESMTPS id 41386180B66; Fri, 14 Nov 2025 17:28:43 +0800 (CST) Received: from [10.174.178.46] (10.174.178.46) by kwepemk500005.china.huawei.com (7.202.194.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Fri, 14 Nov 2025 17:28:42 +0800 Subject: Re: [PATCH v2 1/1] mtd: ubi: skip programming unused bits in ubi headers To: Cheng Ming Lin , , , , , CC: , , Cheng Ming Lin References: <20251114024452.2927429-1-linchengming884@gmail.com> <20251114024452.2927429-2-linchengming884@gmail.com> From: Zhihao Cheng Message-ID: <37a8a673-4c5e-fd61-ae63-6059be311a34@huawei.com> Date: Fri, 14 Nov 2025 17:28:41 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 In-Reply-To: <20251114024452.2927429-2-linchengming884@gmail.com> Content-Type: text/plain; charset="gbk"; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: kwepems500001.china.huawei.com (7.221.188.70) To kwepemk500005.china.huawei.com (7.202.194.90) ÔÚ 2025/11/14 10:44, Cheng Ming Lin дµÀ: > From: Cheng Ming Lin > > This patch prevents unnecessary programming of bits in ec_hdr and > vid_hdr that are not used or read during normal UBI operation. These > unused bits are typcially already set to 1 in erased flash and do not > need to be explicitly programmed to 0 if they are not used. > > Programming such unused areas offers no functional benefit and may > result in unnecessary flash wear, reducing the overall lifetime of the > device. By skipping these writes, we preserve the flash state as much as > possible and minimize wear caused by redundant operations. > > This change ensures that only necessary fields are written when preparing > UBI headers, improving flash efficiency without affecting functionality. > > Additionally, the Kioxia TC58NVG1S3HTA00 datasheet (page 63) also notes > that continuous program/erase cycling with a high percentage of '0' bits > in the data pattern can accelerate block endurance degradation. > This further supports avoiding large 0x00 patterns. > > Link: https://europe.kioxia.com/content/dam/kioxia/newidr/productinfo/datasheet/201910/DST_TC58NVG1S3HTA00-TDE_EN_31442.pdf > > Signed-off-by: Cheng Ming Lin > --- > drivers/mtd/ubi/io.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) Reviewed-by: Zhihao Cheng > > diff --git a/drivers/mtd/ubi/io.c b/drivers/mtd/ubi/io.c > index a4999bce4..dfb9c27c0 100644 > --- a/drivers/mtd/ubi/io.c > +++ b/drivers/mtd/ubi/io.c > @@ -868,6 +868,8 @@ int ubi_io_write_ec_hdr(struct ubi_device *ubi, int pnum, > return -EROFS; > } > > + memset((char *)ec_hdr + UBI_EC_HDR_SIZE, 0xFF, ubi->ec_hdr_alsize - UBI_EC_HDR_SIZE); > + > err = ubi_io_write(ubi, ec_hdr, pnum, 0, ubi->ec_hdr_alsize); > return err; > } > @@ -1150,6 +1152,14 @@ int ubi_io_write_vid_hdr(struct ubi_device *ubi, int pnum, > return -EROFS; > } > > + if (ubi->vid_hdr_shift) { > + memset((char *)p, 0xFF, ubi->vid_hdr_shift); > + memset((char *)p + ubi->vid_hdr_shift + UBI_VID_HDR_SIZE, 0xFF, > + ubi->vid_hdr_alsize - (ubi->vid_hdr_shift + UBI_VID_HDR_SIZE)); > + } else { > + memset((char *)p + UBI_VID_HDR_SIZE, 0xFF, ubi->vid_hdr_alsize - UBI_VID_HDR_SIZE); > + } > + > err = ubi_io_write(ubi, p, pnum, ubi->vid_hdr_aloffset, > ubi->vid_hdr_alsize); > return err; >