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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <c7b200d180278b43ddf8e1f870c846df@walle.cc>
Date:   Thu, 31 Aug 2023 08:41:02 +0200
From:   Michael Walle <michael@...le.cc>
To:     SSunk <ssunkkan@...il.com>
Cc:     linux-kernel@...r.kernel.org, linux-mtd@...ts.infradead.org,
        miquel.raynal@...tlin.com, pratyush@...nel.org, richard@....at,
        ssunkkan@...il.com, tudor.ambarus@...aro.org, vigneshr@...com
Subject: Re: [PATCH] Add support for more XMC series

Hi,

>>>> Since this is the first time I've submitted code to the Linux
>>>> community, please forgive me for some of the missteps that I've 
>>>> made.
>>>> I uploaded the incorrect patch file.
>>>> In a previous e-mail you said:
>>>> XMC parts seem to have SFDP tables and they should work out of the 
>>>> box
>>>> without any patches with the generic spi nor driver [1]. Therefore,
>>>> you don't need any entry at all.
>>>> 
>>>> I think it is related to the PARSE_SFDP flag.
>>>> The XMC flash part supports SFDP, so i don’t need to add
>>>> NO_SFDP_FLAGS() macro.
>>>> drivers/mtd/spi-nor/xmc.c | 17 +++++++++++++----
>>>> 1 file changed, 13 insertions(+), 4 deletions(-)
>>>> 
>>>> diff --git a/drivers/mtd/spi-nor/xmc.c b/drivers/mtd/spi-nor/xmc.c
>>>> index 051411e86339..e78bf11792d9 100644
>>>> --- a/drivers/mtd/spi-nor/xmc.c
>>>> +++ b/drivers/mtd/spi-nor/xmc.c
>>>> @@ -11,11 +11,20 @@
>>>> static const struct flash_info xmc_nor_parts[] = {
>>>> 	/* XMC (Wuhan Xinxin Semiconductor Manufacturing Corp.) */
>>>> 	{ "XM25QH64A", INFO(0x207017, 0, 64 * 1024, 128)
>>>> -		NO_SFDP_FLAGS(SECT_4K | SPI_NOR_DUAL_READ |
>>>> -			      SPI_NOR_QUAD_READ) },
>>>> +		PARSE_SFDP },
>>>> 	{ "XM25QH128A", INFO(0x207018, 0, 64 * 1024, 256)
>>>> -		NO_SFDP_FLAGS(SECT_4K | SPI_NOR_DUAL_READ |
>>>> -			      SPI_NOR_QUAD_READ) },
>>>> +		PARSE_SFDP },
>>>> +	{ "XM25QH128C", INFO(0x204018, 0, 64 * 1024, 256)
>>>> +		PARSE_SFDP },
>>>> +	{ "XM25QH256C", INFO(0x204019, 0, 64 * 1024, 512)
>>>> +		PARSE_SFDP },
>>>> +	{ "XM25QU256C", INFO(0x204119, 0, 64 * 1024, 512)
>>>> +		PARSE_SFDP },
>>>> +	{ "XM25QH512C", INFO(0x204020, 0, 64 * 1024, 1024)
>>>> +		PARSE_SFDP },
>>>> +	{ "XM25QU512C", INFO(0x204120, 0, 64 * 1024, 1024)
>>>> +		PARSE_SFDP },
>>>> +
>>>> };
>>>> 
>>>> const struct spi_nor_manufacturer spi_nor_xmc = {
>>>>> Correct. If the flash is working with PARSE_SFDP, it has SFDP and
>>>>> all the information of the flash_info table is pulled from the SFDP
>>>>> tables, except for the part name. Therefore, you don't need any 
>>>>> entry
>>>>> at all. The flash should just work out of the box. Are you using 
>>>>> the
>>>>> latest kernel?
>>>>> 
>>>>> -michael
>>> --
>>> Hi Michael,
>>> 
>>> According to you, does this piece of my code still need to be 
>>> modified?
>> 
>> You don't need it at all. The flash will work as is - that is without
>> that
>> piece of code.
>> 
>> -michael
> --
> Hi michael,
> 
> If these entries are not added, the flash part name is unknown and our 
> customers
> cannot see our flash part name on the kernel log.
> So,I think it's necessary to add these entries.

They can still see the jedec id in the sysfs. We don't add entries just 
for the
names. Sorry.

-michael

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ