[PATCH v4] mtd: spi-nor: Add support for XM25LU64C

[Tudor Ambarus]

On 7/11/25 9:43 AM, Ssunk wrote:
> The XM25LU64C is a 64Mbit (8MB) SPI-NOR flash memory manufactured by
> Wuhan Xinxin Semiconductor Manufacturing Corp. (XMC). This device
> supports SFDP. However, additional flashflags beyond SFDP are required
> to fully describe its capabilities.

what flags are you referring to?
> This patch adds an explicit entry for the XM25LU64C, marking support for:
> 
>   - 4KiB sector erase (SECT_4K)
won't need it, defined in sfdp
>   - Dual and Quad read modes (DUAL_READ, QUAD_READ)
defined in sfdp

>   - Block-level lock/unlock support (HAS_LOCK)
>   - Top/Bottom protection bits (HAS_TB)

these shall be ok
> 
> These flash capabilities were confirmed against the vendor datasheet:
> 
>   https://www.xmcwh.com/uploads/954/XM25LU64C_V1.5.pdf
> 
> ### Testing:

you can add the testing comments in the "---" comment section

> Tested according to the "Minimum testing requirements" described in:
> 
>   https://docs.kernel.org/driver-api/mtd/spi-nor.html
> 
> - This flash is populated on the MT8189-chromebook board and was tested at 52M
> - frequency using the jedec,spi-nor SPI controller.

this is the compatible for the SPI NOR flash, not the SPI controller :)

> - Detected correctly by Linux MTD subsystem:
> 
>     # cat /sys/bus/spi/devices/spi5.0/spi-nor/partname
>     XM25LU64C
> 
>     # cat /sys/bus/spi/devices/spi5.0/spi-nor/jedec_id
>     204117
> 
>     # cat /sys/bus/spi/devices/spi5.0/spi-nor/manufacturer
>     xmc
> 
> - Verified SFDP table presence and correctness:
> 
>     # xxd -p /sys/bus/spi/devices/spi5.0/spi-nor/sfdp
>     53464450060102ff00060110300000ff20000104d00000ff84000102c0...

we need the full output. We'll reference it in case there will be updates
to this flash entry. Please send the full output.

>     # sha256sum /sys/bus/spi/devices/spi5.0/spi-nor/sfdp
>     27ef209af54d6fef4f51f14300e50db95f13180024f3e1aa1c4202edb4914be5
>     
> - Dump debugfs data:
>     # cat /sys/kernel/debug/spi-nor/spi5.0/capabilities
>     Supported read modes by the flash
>      1S-1S-1S
>       opcode	0x03
>       mode cycles	0
>       dummy cycles	0
>      1S-1S-2S
>       opcode	0x3b
>       mode cycles	0
>       dummy cycles	8
>      1S-2S-2S
>       opcode	0xbb
>       mode cycles	2
>       dummy cycles	2
>      1S-1S-4S
>       opcode	0x6b
>       mode cycles	0
>       dummy cycles	8
>      1S-4S-4S
>       opcode	0xeb
>       mode cycles	2
>       dummy cycles	4
>      4S-4S-4S
>       opcode	0xeb
>       mode cycles	2
>       dummy cycles	0
>     Supported page program modes by the flash
>      1S-1S-1S
>       opcode		0x02
>     Supported page program modes by the flash
>      1S-1S-1S
>      opcode		0x02
>       
>     # cat /sys/kernel/debug/spi-nor/spi5.0/params
>     name		XM25LU64C
>     id			20 41 17 20 41 17
>     size		8.00 MiB
>     write size		1
>     page size		256
>     address nbytes	3
>     flags		HAS_16BIT_SR | SOFT_RESET
> 
>     opcodes
>      read		0xbb
>      dummy cycles	4
>      erase		0x20
>      program		0x02
>      8D extension	none
> 
>     protocols
>      read		1S-2S-2S
>      write		1S-1S-1S
>      register		1S-1S-1S
> 
>     erase commands
>      20 (4.00 KiB) [1]
>      52 (32.0 KiB) [2]
>      d8 (64.0 KiB) [3]
>      c7 (8.00 MiB)
> 
>     sector map
>      region (in hex)   | erase mask | flags
>      ------------------+------------+----------
>      00000000-007fffff |     [ 123] |
> 
> - Vrify write:
>     # dd if=/dev/urandom of=./spi_test bs=1M count=2
>     2+0 records in
>     2+0 records out
>     2097152 bytes (2.1 MB, 2.0 MiB) copied, 0.0334051 s, 62.8 MB/s

here you just generated a file of 2 MB
>     
>     # sha256sum spi*
>     be845b59c00525b0e0d570468c7b014bc8e9895c61ce74e8ca4cfc00e34d08aa  spi_test
> 

and here you get the sha256sum of it. you haven't verified the correctness
of a flash write. Please follow the testing steps in their fullness. 

> Signed-off-by: Kankan Sun <ssunkkan at gmail.com>
> 
> ---
> 
> Changes since v2:
> - Fixed broken datasheet URL
> - Rewrote commit message to clarify SFDP usage and flash flags
> - Removed irrelevant internal vendor references
> - Added test information of Minimum testing requirements
> 
> ---
>  drivers/mtd/spi-nor/xmc.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/mtd/spi-nor/xmc.c b/drivers/mtd/spi-nor/xmc.c
> index d5a06054b0dd..f1f2a9ba353e 100644
> --- a/drivers/mtd/spi-nor/xmc.c
> +++ b/drivers/mtd/spi-nor/xmc.c
> @@ -19,6 +19,12 @@ static const struct flash_info xmc_nor_parts[] = {
>  		.name = "XM25QH128A",
>  		.size = SZ_16M,
>  		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
> +	}, {
> +		.id = SNOR_ID(0x20, 0x41, 0x17),
> +		.name = "XM25LU64C",

remove name, but add it as a comment. See commits of recent flash additions.
> +		.size = SZ_8M,

if the flash defines SFDP, you won't need the size field.

> +		.flags = SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB

these are ok, if tested. Did you test locking?
,
> +		.no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,

you won't need this, they'll be discovered at sfdp parsing.
>  	},
>  };
>