From fd50596dbc7d7119a42beac67aacbde3521e5ff5 Mon Sep 17 00:00:00 2001 From: Christopher Haster Date: Sun, 18 Aug 2024 15:53:29 -0500 Subject: [PATCH] ckparity: Don't check parity when incrementing revision count It doesn't really matter, since any bit-errors will be thrown out during fetch anyways, but checking the parity of revision counts is technically the wrong thing to do if we care about compatibility with non-ckparity builds. Note this lfsr_bd_readck call was immediately followed by ignoring the LFS_ERR_CORRUPT error and defaulting the revision count to zero. Thanks allowing lfsr_bd_readck to be more aggressively inlined, this saves both code and stack: code stack default before: 36412 2616 default after: 36412 (+0.0%) 2616 (+0.0%) ckparity before: 37972 3088 ckparity after: 37900 (-0.2%) 3048 (-1.3%) --- lfs.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/lfs.c b/lfs.c index 46206c47..ac2f89d7 100644 --- a/lfs.c +++ b/lfs.c @@ -7477,9 +7477,8 @@ static int lfsr_mdir_swap__(lfs_t *lfs, lfsr_mdir_t *mdir_, // first thing we need to do is read our current revision count uint32_t rev; - int err = LFSR_BD_READCK(lfs, mdir->rbyd.blocks[0], 0, 0, - &rev, sizeof(uint32_t), - LFSR_CK_PARITY(0, sizeof(uint32_t))); + int err = lfsr_bd_read(lfs, mdir->rbyd.blocks[0], 0, 0, + &rev, sizeof(uint32_t)); if (err && err != LFS_ERR_CORRUPT) { return err; }