Messages in this thread | | | Date | Wed, 07 Jul 2021 14:46:59 +0200 | From | Michael Walle <> | Subject | Re: [PATCH] mtd:spi-nor:Update Winbond SPI NOR Flash device ID |
| |
Hi,
Am 2021-07-07 13:58, schrieb MODEL WORK LST: > Shame on me, I don't use the plain text to reply. > Please allow me send again.
Please also avoid top-posting ;)
> It is my first time update patch for Linux, please advise me if I do > wrong.
No worries!
> We are testing these device by the NXP evaluation board.
Ok, this should then go into the commit message, too. Usually the SoC and the SPI controller which was used for testing go in there.
> But the running Linux revision for that board is still 4.x. To update > the latest ID, > should we prepare the system that can work with latest Linux revision?
Yes that would be preferable, either use spi-nor/next or just linux-next [1]. There, my patches for dumping/reading the SFDP are already integrated.
> For the test process, I was wondering to ask mount the device to UBIFS > is a good way for test?
It depends what flags or features are you plan to support. Ususually, reading/writing the raw mtd device will be enough. If you also add locking support, for example, you should also test the locking by using the mtd-utils.
I'd say testing whole UBIFS is overkill. Bascially you will just make sure reading and writing is possible. And if the results make sense, eg. does it actually use Quad I/O or Dual I/O.
Also look at dmesg and see if it is probed correctly.
> For the ID, this time we add new ID that is not include in the > flash_info[]. > And we would keep our device who share the same ID have compatible > with each other. > Make sure the FW or SW only need to maintain an unique for each > density. > If the same density device have different behavior, Winbond would apply > new ID.
Oh I wasn't clear here. FW is not firmware but your 'FW' model. Eg. the W25Q32FW. In my experience it shared the same id with W25Q32JW, if I remember correctly.
We do have many problems with vendors sharing the same flash id between different flash models which then have different features; we have a hard time distinguish them at runtime because they appear to be the same by looking at the JEDEC id.
So if you are aware of any other winbond flashes which reuse the IDs which you are adding below, that would be good to know.
And to make you/Winbond aware that this is not really good and if possible should be avoided for future chips.
> Or have application note for customer to aware the difference.
The problem is not the difference, but the fact that we cannot detect it on runtime.
> For the SFDP, I would check how to work and fill the information.
Great. Thanks!
-michael
| |