linux-kernel - Re: [PATCH v2 17/41] mtd: spi-nor: atmel: convert flash

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 06 Sep 2023 09:38:08 +0200
From:   Michael Walle <mwalle@...nel.org>
To:     Tudor Ambarus <tudor.ambarus@...aro.org>
Cc:     Pratyush Yadav <pratyush@...nel.org>,
        Miquel Raynal <miquel.raynal@...tlin.com>,
        Richard Weinberger <richard@....at>,
        Vignesh Raghavendra <vigneshr@...com>,
        linux-kernel@...r.kernel.org, linux-mtd@...ts.infradead.org
Subject: Re: [PATCH v2 17/41] mtd: spi-nor: atmel: convert flash_info to new
 format

Am 2023-09-06 09:35, schrieb Tudor Ambarus:
> On 22.08.2023 10:09, Michael Walle wrote:
>> The INFOx() macros are going away. Convert the flash_info database to
>> the new format.
>> 
>> Signed-off-by: Michael Walle <mwalle@...nel.org>
>> ---
>>  drivers/mtd/spi-nor/atmel.c | 122 
>> +++++++++++++++++++++++++++++---------------
>>  1 file changed, 80 insertions(+), 42 deletions(-)
>> 
>> diff --git a/drivers/mtd/spi-nor/atmel.c b/drivers/mtd/spi-nor/atmel.c
>> index d2de2cb0c066..ccc985c48ae3 100644
>> --- a/drivers/mtd/spi-nor/atmel.c
>> +++ b/drivers/mtd/spi-nor/atmel.c
>> @@ -163,48 +163,86 @@ static const struct spi_nor_fixups 
>> atmel_nor_global_protection_fixups = {
>>  };
>> 
>>  static const struct flash_info atmel_nor_parts[] = {
>> -	{ "at25fs010",  INFO(0x1f6601, 0, 32 * 1024,   4)
>> -		FLAGS(SPI_NOR_HAS_LOCK)
>> -		NO_SFDP_FLAGS(SECT_4K)
>> -		.fixups = &at25fs_nor_fixups },
>> -	{ "at25fs040",  INFO(0x1f6604, 0, 64 * 1024,   8)
>> -		FLAGS(SPI_NOR_HAS_LOCK)
>> -		NO_SFDP_FLAGS(SECT_4K)
>> -		.fixups = &at25fs_nor_fixups },
>> -	{ "at25df041a", INFO(0x1f4401, 0, 64 * 1024,   8)
>> -		FLAGS(SPI_NOR_HAS_LOCK | SPI_NOR_SWP_IS_VOLATILE)
>> -		NO_SFDP_FLAGS(SECT_4K)
>> -		.fixups = &atmel_nor_global_protection_fixups },
>> -	{ "at25df321",  INFO(0x1f4700, 0, 64 * 1024,  64)
>> -		FLAGS(SPI_NOR_HAS_LOCK | SPI_NOR_SWP_IS_VOLATILE)
>> -		NO_SFDP_FLAGS(SECT_4K)
>> -		.fixups = &atmel_nor_global_protection_fixups },
>> -	{ "at25df321a", INFO(0x1f4701, 0, 64 * 1024,  64)
>> -		FLAGS(SPI_NOR_HAS_LOCK | SPI_NOR_SWP_IS_VOLATILE)
>> -		NO_SFDP_FLAGS(SECT_4K)
>> -		.fixups = &atmel_nor_global_protection_fixups },
>> -	{ "at25df641",  INFO(0x1f4800, 0, 64 * 1024, 128)
>> -		FLAGS(SPI_NOR_HAS_LOCK | SPI_NOR_SWP_IS_VOLATILE)
>> -		NO_SFDP_FLAGS(SECT_4K)
>> -		.fixups = &atmel_nor_global_protection_fixups },
>> -	{ "at25sl321",	INFO(0x1f4216, 0, 64 * 1024, 64)
>> -		NO_SFDP_FLAGS(SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
>> -	{ "at26f004",   INFO(0x1f0400, 0, 64 * 1024,  8)
>> -		NO_SFDP_FLAGS(SECT_4K) },
>> -	{ "at26df081a", INFO(0x1f4501, 0, 64 * 1024, 16)
>> -		FLAGS(SPI_NOR_HAS_LOCK | SPI_NOR_SWP_IS_VOLATILE)
>> -		NO_SFDP_FLAGS(SECT_4K)
>> -		.fixups = &atmel_nor_global_protection_fixups },
>> -	{ "at26df161a", INFO(0x1f4601, 0, 64 * 1024, 32)
>> -		FLAGS(SPI_NOR_HAS_LOCK | SPI_NOR_SWP_IS_VOLATILE)
>> -		NO_SFDP_FLAGS(SECT_4K)
>> -		.fixups = &atmel_nor_global_protection_fixups },
>> -	{ "at26df321",  INFO(0x1f4700, 0, 64 * 1024, 64)
>> -		FLAGS(SPI_NOR_HAS_LOCK | SPI_NOR_SWP_IS_VOLATILE)
>> -		NO_SFDP_FLAGS(SECT_4K)
>> -		.fixups = &atmel_nor_global_protection_fixups },
>> -	{ "at45db081d", INFO(0x1f2500, 0, 64 * 1024, 16)
>> -		NO_SFDP_FLAGS(SECT_4K) },
>> +	{
>> +		.id = SNOR_ID(0x1f, 0x66, 0x01),
>> +		.name = "at25fs010",
> 
> nitpick, we shall respect the order of the members declared in
> flash_info struct.

The id is the first one on purpose, because that's our main
key to the entry. I couldn't swap the properties in flash_info
yet because the old entry style used also positional parameters,
i.e. the first entry was always the name.

> And I'll let you double check if the conversion is accurate :D.

See the cover letter for the objdump trick :)

-michael