- Oct 18, 2023
-
-
Mamta Shukla authored
mt25qu512a supports locking/unlocking through the SR BP bits. Enable locking support. Tested with mtd-utils- flash_lock/flash_unlock on MT25QU512ABB8E12. Signed-off-by:
Mamta Shukla <mamta.shukla@leica-geosystems.com> Link: https://lore.kernel.org/r/20231017074711.12167-1-tudor.ambarus@linaro.org Signed-off-by:
Tudor Ambarus <tudor.ambarus@linaro.org>
-
- Sep 27, 2023
-
-
Nicolas Ferre authored
Add the at25ff321a 4MB SPI flash which is able to provide SFDP information. Link: https://www.renesas.com/us/en/document/dst/at25ff321a-datasheet Signed-off-by:
Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/20230926131655.51224-1-nicolas.ferre@microchip.com Signed-off-by:
-
- Sep 19, 2023
-
-
Michael Walle authored
Now that all flash_info tables are converted to the new format, remove the old INFOx() macros. Signed-off-by:
Michael Walle <mwalle@kernel.org> Link: https://lore.kernel.org/r/20230807-mtd-flash-info-db-rework-v3-41-e60548861b10@kernel.org Signed-off-by:
-
Michael Walle authored
The Atmel AT26DF321 and AT25DF321 have the same ID. Both were just discovered by reading their IDs, that is, there is no probing by name. Thus only the first one (the AT25DF321) in the list was ever probed. Luckily, the AT25DF is also the newer series. Drop the AT26DF321. Signed-off-by:
-
Michael Walle authored
The flash ID is the new primary key into our database. Sort the entry by it. Keep the most specific ones first, because there might be ID collisions between shorter and longer ones. Signed-off-by:
-
Michael Walle authored
The flash ID is the new primary key into our database. Sort the entry by it. Keep the most specific ones first, because there might be ID collisions between shorter and longer ones. Signed-off-by:
-
Michael Walle authored
The flash ID is the new primary key into our database. Sort the entry by it. Keep the most specific ones first, because there might be ID collisions between shorter and longer ones. Signed-off-by:
-
Michael Walle authored
The flash ID is the new primary key into our database. Sort the entry by it. Keep the most specific ones first, because there might be ID collisions between shorter and longer ones. Signed-off-by:
-
Michael Walle authored
The flash ID is the new primary key into our database. Sort the entry by it. Keep the most specific ones first, because there might be ID collisions between shorter and longer ones. Signed-off-by:
-
Michael Walle authored
The flash ID is the new primary key into our database. Sort the entry by it. Keep the most specific ones first, because there might be ID collisions between shorter and longer ones. Signed-off-by:
-
Michael Walle authored
The flash ID is the new primary key into our database. Sort the entry by it. Keep the most specific ones first, because there might be ID collisions between shorter and longer ones. Signed-off-by:
-
Michael Walle authored
The flash ID is the new primary key into our database. Sort the entry by it. Keep the most specific ones first, because there might be ID collisions between shorter and longer ones. Signed-off-by:
-
Michael Walle authored
The flash ID is the new primary key into our database. Sort the entry by it. Keep the most specific ones first, because there might be ID collisions between shorter and longer ones. Signed-off-by:
-
Michael Walle authored
The INFOx() macros are going away. Convert the flash_info database to the new format. Signed-off-by:
-
Michael Walle authored
There won't be any new entries, nor are the entries that much different and the very odd page and sector sizes make the new format hard to read. Therefore, convert the old S3AN_INFO() macro. Signed-off-by:
-
Michael Walle authored
The INFOx() macros are going away. Convert the flash_info database to the new format. Signed-off-by:
-
Michael Walle authored
The INFOx() macros are going away. Convert the flash_info database to the new format. Signed-off-by:
-
Michael Walle authored
The INFOx() macros are going away. Convert the flash_info database to the new format. Signed-off-by:
-
Michael Walle authored
The INFOx() macros are going away. Convert the flash_info database to the new format. Signed-off-by:
-
Michael Walle authored
The INFOx() macros are going away. Convert the flash_info database to the new format. Signed-off-by:
-
Michael Walle authored
The INFOx() macros are going away. Convert the flash_info database to the new format. Signed-off-by:
-
Michael Walle authored
The INFOx() macros are going away. Convert the flash_info database to the new format. Signed-off-by:
-
Michael Walle authored
The INFOx() macros are going away. Convert the flash_info database to the new format. Signed-off-by:
-
Michael Walle authored
The INFOx() macros are going away. Convert the flash_info database to the new format. Signed-off-by:
-
Michael Walle authored
The INFOx() macros are going away. Convert the flash_info database to the new format. Signed-off-by:
-
Michael Walle authored
The INFOx() macros are going away. Convert the flash_info database to the new format. Signed-off-by:
-
Michael Walle authored
The INFOx() macros are going away. Convert the flash_info database to the new format. Signed-off-by:
-
Michael Walle authored
Most of the comments are a relict of the past when the flash_info was just one table. Most of them are useless. Remove them. Signed-off-by:
-
Michael Walle authored
After all the preparation, it is now time to introduce the new macros to specify flashes in our database: SNOR_ID() and SNOR_OTP(). An flash_info entry might now look like: { .id = SNOR_ID(0xef, 0x60, 0x16), .otp = SNOR_OTP(256, 3, 0x1000, 0x1000), .flags = SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB, } Signed-off-by: -
Michael Walle authored
Move the OTP ops out of the flash_info structure. Besides of saving some space, there will be a new macro SNOR_OTP() which can be used to set the ops: .otp = SNOR_OTP(...), Signed-off-by:
-
Michael Walle authored
Create a new structure to hold a flash ID and its length. The goal is to have a new macro SNOR_ID() which can have a flexible id length. This way we can get rid of all the individual INFOx() macros. Signed-off-by:
-
Michael Walle authored
The id will be converted to an own structure. To differentiate between flashes with and without IDs, introduce a temporary macro INFO0() and convert all flashes with no ID to use it. The difference between INFO0() and INFOx() is that the former, doesn't have a pointer to the id structure. Something which isn't possible to do within the INFOx() macro. After the flash_info conversion, that macro will be removed along with all the other INFOx() macros. Signed-off-by:
-
Michael Walle authored
Drop the size parameter to indicate we need to do SFDP, we can do that because it is guaranteed that the size will be set by SFDP and because PARSE_SFDP forced the SFDP parsing it must be overwritten. There is a (very tiny) chance that this might break block protection support: we now rely on the SFDP reported size of the flash for the BP calculation. OTOH, if the flash reports its size wrong, we are in bigger trouble than just having the BP calculation wrong. Signed-off-by:
-
Michael Walle authored
Most of the (old, non-SFDP) flashes use a sector size of 64k. Make that a default value so it can be optional in the flash_info database. As a preparation for conversion to the new database format, set the sector size to zero if the default value is used. This way, the actual change is happening with this patch ant not with a later conversion patch. Signed-off-by:
-
Michael Walle authored
4k sector erase sizes are only a thing with uniform erase types. Push the "we want 4k erase sizes" handling into spi_nor_select_uniform_erase(). One might wonder why the former sector_size isn't used anymore. It is because we either search for the largest erase size or if selected through kconfig, the 4k erase size. Now, why is that correct? For this, we have to differentiate between (1) flashes with SFDP and (2) without SFDP. For (1), we just set one (or two if SECT_4K is set) erase types and wanted_size is exactly one of these. For (2) things are a bit more complicated. For flashes which we don't have in our flash_info database, the generic driver is used and sector_size was already 0, which in turn selected the largest erase size. For flashes which had SFDP and an entry in flash_info, sector_size was always the largest sector and thus the largest erase type. Signed-off-by:
-
Michael Walle authored
If .n_banks is not set in the flash_info database, the default value should be 1. This way, we don't have to always set the .n_banks parameter in flash_info. Signed-off-by:
Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20230807-mtd-flash-info-db-rework-v3-8-e60548861b10@kernel.org Signed-off-by:
-
Michael Walle authored
First, fixups might want to replace the n_banks parameter, thus we need it in the (writable) parameter struct. Secondly, this way we can have a default in the core and just skip setting the n_banks in the flash_info database. Most of the flashes doesn't have more than one bank. Signed-off-by:
-
Michael Walle authored
The INFO() macro always set the page_size to 256 bytes. Make that an optional parameter. This default is a sane one for all older flashes, newer ones will set the page size by its SFDP tables anyway. Signed-off-by:
-
Michael Walle authored
.n_sectors is rarely used. In fact it is only used in swp.c and to calculate the flash size in the core. The use in swp.c might be converted to use the (largest) flash erase size. For now, we just locally calculate the sector size. Simplify the flash_info database and set the size of the flash directly. This also let us use the SZ_x macros. Verified that there's no flash that specifies BP and sector size of zero to make sure we avoid a division by zero in spi_nor_get_min_prot_length_sr(). We'll protect from a possible division by zero in a further patch by introducing a default value for sector_size. Signed-off-by:
-
Michael Walle authored
The default value of addr_nbytes is already 3. Drop it. Signed-off-by:
-
