linux-kernel - Re: [PATCH] mtd: spi-nor: micron-st: added support for np8p128ax60

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-next>] [day] [month] [year] [list]

Message-ID: <CAGiusB0B5dN_K+bW1xudmT6UNmVOL=voBOuSVJeiYo3v6ywO8w@mail.gmail.com>
Date:   Tue, 31 Aug 2021 12:11:51 +0200
From:   Andrea Zanotti <andreazanottifo@...il.com>
To:     Michael Walle <michael@...le.cc>
Cc:     Tudor Ambarus <tudor.ambarus@...rochip.com>,
        Pratyush Yadav <p.yadav@...com>,
        Miquel Raynal <miquel.raynal@...tlin.com>,
        Richard Weinberger <richard@....at>,
        Vignesh Raghavendra <vigneshr@...com>,
        linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mtd: spi-nor: micron-st: added support for np8p128ax60

Il giorno mar 31 ago 2021 alle ore 11:09 Andrea Zanotti
<andreazanottifo@...il.com> ha scritto:
>
> Hi Michael,
>
> Il giorno mar 31 ago 2021 alle ore 10:39 Michael Walle <michael@...le.cc> ha scritto:
>>
>> Hi Andrea,
>>
>> Am 2021-08-31 10:13, schrieb Andrea Zanotti:
>> > From: Andrea Zanotti <andreazanottifo@...il.com>
>> >
>> > Added support for P8P Parallel Phase Change Memory.
>>
>> Please use present tense, eg "add support..."
>>
>> Is there a public datasheet? If so, please include it above
>> your SoB like so:
>> Datasheet: https://...
>>
>
> I will format the header as per your suggestions. I used the same datasheet
> linked by you at the end of the email
>
>>
>> > Added memory information (page size and sector size) as per data-
>> > sheet information, after typos corrections.
>>
>> After typos corrections?
>>
>
> The one specified in the following paragraph. I'll better write this. (What I meant
> is that there are some typos in the datasheet itself)
>
>>
>> > At page 37, paragraph 'SPI Memory Organization', it is written
>> > down that the memory is organized as:
>> >  * 16.772.216 bytes (typo here, there 16.777.216 bytes)
>> >  * 128 sectors of 128 Kbytes each (correct)
>> >  * 131.072 pages of 64 bytes each (typo here, as the total would be
>> >    64Mbit, but the total memory is actually 128Mbit, correct value
>> >    is 262.144 pages)
>> >
>> > Patch tested against the aforementioned PCM memory.
>>
>> What SPI host controller was used?
>>
>
> I used an AT91SAM9G20 processor, SPI controller "atmel,at91rm9200-spi" (spi-atmel.c)
>
>>
>> > No known regressions inserted, as the patch only adds the possibility
>> > to recognize said PCM memory inside the common spi-nor driver.
>>
>> Please drop this. If there were any regressions, the patch wouldn't
>> be picked up anyway.
>>
>
> It will be dropped.
>
>> >
>> > Signed-off-by: Andrea Zanotti <andreazanottifo@...il.com>
>> > ---
>> >  drivers/mtd/spi-nor/micron-st.c | 1 +
>> >  1 file changed, 1 insertion(+)
>> >
>> > diff --git a/drivers/mtd/spi-nor/micron-st.c
>> > b/drivers/mtd/spi-nor/micron-st.c
>> > index c224e59820a1..c78331451082 100644
>> > --- a/drivers/mtd/spi-nor/micron-st.c
>> > +++ b/drivers/mtd/spi-nor/micron-st.c
>> > @@ -128,6 +128,7 @@ static const struct flash_info micron_parts[] = {
>> >       { "mt35xu02g", INFO(0x2c5b1c, 0, 128 * 1024, 2048,
>> >                           SECT_4K | USE_FSR | SPI_NOR_OCTAL_READ |
>> >                           SPI_NOR_4B_OPCODES) },
>> > +     { "np8p128ax60", {0x89, 0xda, 0x18}, 3, 128 * 1024, 128, 64, 0, 0 },
>>
>> Eh? Please use INFO(). And why isn't this 0x20 for micron.
>>
>
> With INFO() macro I am locked in with .page_size = 256 (I would need 64), or am I missing something?
>
>>
>> I found this datasheet:
>> https://media.digikey.com/pdf/Data%20Sheets/Micron%20Technology%20Inc%20PDFs/NP8P128Ax60E_Rev_K.pdf
>>
>> According to that datasheet, the manuf id is 0x20. And the device id
>> should be either 0x88e1 or 0x8821.
>>
>
> You are right, checking it right now.
>

- As per datasheet, table 10 on page 18, Manufacturer code is 0x89
(column "data" for parameter "Manufacturer Code").
- On the datasheet, I agree with you that the device code is
advertised as either 0x88e1 or 0x8821. I changed the byte array
to something wrong in order to have the debug warning on the JEDEC id
bytes, and this is the log:

spi-nor spi0.0: unrecognized JEDEC id bytes: 89 da 18 00 00 00

Second and third byte are "0xda" and "0x18". I am not an expert in the
spi-nor driver, but from my understanding
(if it's wrong, please correct me) the spi-nor driver tries to match
the the read bytes from the memory with the ones
in the tables. I don't know if the datasheet is wrong also in that
cell of the table, or if I am interpreting the data wrongly.


>>
>> >  };
>> >
>> >  static const struct flash_info st_parts[] = {
>>
>> --
>> -michael