[PATCH 1/2] linux/bitfield.h: import FIELD_PREP_CONST macro from Linux Kernel

[PATCH 1/2] linux/bitfield.h: import FIELD_PREP_CONST macro from Linux Kernel

[Christian Marangi]

Import FIELD_PREP_CONST macro from Linux Kernel to permit usage of
FIELD_PREP with scenario where a constant value is needed.

Refer to commit e2192de59e45 ("bitfield: add FIELD_PREP_CONST()") in
Linux kernel for extensive explaination of why this is useful.

This is also to better align with the Linux Kernel for easier porting of
driver.

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
---
 include/linux/bitfield.h | 26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/include/linux/bitfield.h b/include/linux/bitfield.h
index 7ad02f8cbb9..1b73ba6f9fa 100644
--- a/include/linux/bitfield.h
+++ b/include/linux/bitfield.h
@@ -90,6 +90,32 @@
 		((typeof(_mask))(_val) << __bf_shf(_mask)) & (_mask);	\
 	})
 
+#define __BF_CHECK_POW2(n)	BUILD_BUG_ON_ZERO(((n) & ((n) - 1)) != 0)
+
+/**
+ * FIELD_PREP_CONST() - prepare a constant bitfield element
+ * @_mask: shifted mask defining the field's length and position
+ * @_val:  value to put in the field
+ *
+ * FIELD_PREP_CONST() masks and shifts up the value.  The result should
+ * be combined with other fields of the bitfield using logical OR.
+ *
+ * Unlike FIELD_PREP() this is a constant expression and can therefore
+ * be used in initializers. Error checking is less comfortable for this
+ * version, and non-constant masks cannot be used.
+ */
+#define FIELD_PREP_CONST(_mask, _val)					\
+	(								\
+		/* mask must be non-zero */				\
+		BUILD_BUG_ON_ZERO((_mask) == 0) +			\
+		/* check if value fits */				\
+		BUILD_BUG_ON_ZERO(~((_mask) >> __bf_shf(_mask)) & (_val)) + \
+		/* check if mask is contiguous */			\
+		__BF_CHECK_POW2((_mask) + (1ULL << __bf_shf(_mask))) +	\
+		/* and create the value */				\
+		(((typeof(_mask))(_val) << __bf_shf(_mask)) & (_mask))	\
+	)
+
 /**
  * FIELD_GET() - extract a bitfield element
  * @_mask: shifted mask defining the field's length and position
-- 
2.48.1

[PATCH 2/2] mtd: spinand: winbond: add Winbond W25N04KV flash support

[Christian Marangi]

Add Winbond W25N04KV flash support that use a different value to detect
ECC bitflip.

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
---
 drivers/mtd/nand/spi/winbond.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/drivers/mtd/nand/spi/winbond.c b/drivers/mtd/nand/spi/winbond.c
index dd4ed257a83..16abf89dbbf 100644
--- a/drivers/mtd/nand/spi/winbond.c
+++ b/drivers/mtd/nand/spi/winbond.c
@@ -11,6 +11,7 @@
 #include <linux/device.h>
 #include <linux/kernel.h>
 #endif
+#include <linux/bitfield.h>
 #include <linux/bug.h>
 #include <linux/mtd/spinand.h>
 
@@ -18,6 +19,8 @@
 
 #define WINBOND_CFG_BUF_READ		BIT(3)
 
+#define W25N04KV_STATUS_ECC_5_8_BITFLIPS FIELD_PREP_CONST(STATUS_ECC_MASK, 0x3)
+
 static SPINAND_OP_VARIANTS(read_cache_variants,
 		SPINAND_PAGE_READ_FROM_CACHE_QUADIO_OP(0, 2, NULL, 0),
 		SPINAND_PAGE_READ_FROM_CACHE_X4_OP(0, 1, NULL, 0),
@@ -121,6 +124,7 @@ static int w25n02kv_ecc_get_status(struct spinand_device *spinand,
 		return -EBADMSG;
 
 	case STATUS_ECC_HAS_BITFLIPS:
+	case W25N04KV_STATUS_ECC_5_8_BITFLIPS:
 		/*
 		 * Let's try to retrieve the real maximum number of bitflips
 		 * in order to avoid forcing the wear-leveling layer to move
@@ -172,6 +176,15 @@ static const struct spinand_info winbond_spinand_table[] = {
 					      &update_cache_variants),
 		     0,
 		     SPINAND_ECCINFO(&w25n02kv_ooblayout, w25n02kv_ecc_get_status)),
+	SPINAND_INFO("W25N04KV",
+		     SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0xaa, 0x23),
+		     NAND_MEMORG(1, 2048, 128, 64, 4096, 40, 2, 1, 1),
+		     NAND_ECCREQ(8, 512),
+		     SPINAND_INFO_OP_VARIANTS(&read_cache_variants,
+					      &write_cache_variants,
+					      &update_cache_variants),
+		     0,
+		     SPINAND_ECCINFO(&w25n02kv_ooblayout, w25n02kv_ecc_get_status)),
 };
 
 static int winbond_spinand_init(struct spinand_device *spinand)
-- 
2.48.1

Re: [PATCH 1/2] linux/bitfield.h: import FIELD_PREP_CONST macro from Linux Kernel

[Quentin Schulz]

Hi Christian,

On 6/3/25 10:51 AM, Christian Marangi wrote:
> Import FIELD_PREP_CONST macro from Linux Kernel to permit usage of
> FIELD_PREP with scenario where a constant value is needed.
> 
> Refer to commit e2192de59e45 ("bitfield: add FIELD_PREP_CONST()") in
> Linux kernel for extensive explaination of why this is useful.
> 
> This is also to better align with the Linux Kernel for easier porting of
> driver.
> 

Do you know it it'd be possible to simply copy Linux kernel's bitfield.h 
instead of "cherry-picking" individual commit(s)?

Cheers,
Quentin

Re: [PATCH 1/2] linux/bitfield.h: import FIELD_PREP_CONST macro from Linux Kernel

[Christian Marangi]

On Tue, Jun 03, 2025 at 05:08:13PM +0200, Quentin Schulz wrote:
> Hi Christian,
> 
> On 6/3/25 10:51 AM, Christian Marangi wrote:
> > Import FIELD_PREP_CONST macro from Linux Kernel to permit usage of
> > FIELD_PREP with scenario where a constant value is needed.
> > 
> > Refer to commit e2192de59e45 ("bitfield: add FIELD_PREP_CONST()") in
> > Linux kernel for extensive explaination of why this is useful.
> > 
> > This is also to better align with the Linux Kernel for easier porting of
> > driver.
> > 
> 
> Do you know it it'd be possible to simply copy Linux kernel's bitfield.h
> instead of "cherry-picking" individual commit(s)?
> 

Mhhh what do you mean? You mean syncing the full header with latest
version?

Isn't that more risky??

-- 
	Ansuel

Re: [PATCH 1/2] linux/bitfield.h: import FIELD_PREP_CONST macro from Linux Kernel

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1206 bytes --]

On Tue, Jun 03, 2025 at 10:37:22PM +0200, Christian Marangi wrote:
> On Tue, Jun 03, 2025 at 05:08:13PM +0200, Quentin Schulz wrote:
> > Hi Christian,
> > 
> > On 6/3/25 10:51 AM, Christian Marangi wrote:
> > > Import FIELD_PREP_CONST macro from Linux Kernel to permit usage of
> > > FIELD_PREP with scenario where a constant value is needed.
> > > 
> > > Refer to commit e2192de59e45 ("bitfield: add FIELD_PREP_CONST()") in
> > > Linux kernel for extensive explaination of why this is useful.
> > > 
> > > This is also to better align with the Linux Kernel for easier porting of
> > > driver.
> > > 
> > 
> > Do you know it it'd be possible to simply copy Linux kernel's bitfield.h
> > instead of "cherry-picking" individual commit(s)?
> > 
> 
> Mhhh what do you mean? You mean syncing the full header with latest
> version?
> 
> Isn't that more risky??

It would be helpful and shouldn't be too risky. At a quick glance, the
first minor issue is to just keep using <linux/bug.h> as
include/linux/bug*h also need to be resynced. This kind of change would
need to be run through CI as well as documented at
https://docs.u-boot.org/en/latest/develop/ci_testing.html

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH 1/2] linux/bitfield.h: import FIELD_PREP_CONST macro from Linux Kernel

[Quentin Schulz]

Hi Christian,

On 6/3/25 10:37 PM, Christian Marangi wrote:
> On Tue, Jun 03, 2025 at 05:08:13PM +0200, Quentin Schulz wrote:
>> Hi Christian,
>>
>> On 6/3/25 10:51 AM, Christian Marangi wrote:
>>> Import FIELD_PREP_CONST macro from Linux Kernel to permit usage of
>>> FIELD_PREP with scenario where a constant value is needed.
>>>
>>> Refer to commit e2192de59e45 ("bitfield: add FIELD_PREP_CONST()") in
>>> Linux kernel for extensive explaination of why this is useful.
>>>
>>> This is also to better align with the Linux Kernel for easier porting of
>>> driver.
>>>
>>
>> Do you know it it'd be possible to simply copy Linux kernel's bitfield.h
>> instead of "cherry-picking" individual commit(s)?
>>
> 
> Mhhh what do you mean? You mean syncing the full header with latest
> version?
> 
> Isn't that more risky??
> 

Not necessarily, it means it's easier for us to simply sync with newer 
Linux kernel versions or make sure that we're actually importing the 
same macros/constants/etc. And also the review is extremely simple. 
Checkout master U-Boot, checkout the Linux kernel at whatever version 
you're saying you're copying the file from, copy it, check the diff, 
matches patch? Reviewed-by given since it already went through proper 
review in the kernel :)

Also would make it easier to port drivers from the kernel to U-Boot as 
the kernel community encourages more and more uses of macros from that 
header but if we only do cherry-picks (or even partial cherry-picks) 
then things get unnecessarily harder.

The kernel typically gets more eyes on and fixes than U-Boot (or such is 
my gut feeling), so being able to easily know if we need to backport 
something to U-Boot by simply reading the kernel mailing list/scouring 
the git history of the kernel is pretty useful.

Cheers,
Quentin