- 19 Sep, 2023 34 commits
-
-
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 <mwalle@kernel.org> Link: https://lore.kernel.org/r/20230807-mtd-flash-info-db-rework-v3-34-e60548861b10@kernel.orgSigned-off-by:
Tudor Ambarus <tudor.ambarus@linaro.org>
-
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.orgSigned-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:
-
Michael Walle authored
In commit 59273180 ("mtd: spi-nor: Create macros to define chip IDs and geometries") SPI_NOR_ID() were introduced, but it did only update the INFO() macro in core.h. Also use it in S3AN_INFO(). Signed-off-by:
-
Michael Walle authored
This part is not a flash but an EEPROM like FRAM. It is even has a DT binding for the (correct) driver (at25), see Documentation/devicetree/bindings/eeprom/at25.yaml. Just remove it. Signed-off-by:
-
Michael Walle authored
CAT25xx are actually EEPROMs manufactured by Catalyst. The devices are ancient (DS are from 1998), there are not in-tree users, nor are there any device tree bindings. Remove it. The correct driver is the at25. Signed-off-by:
-
- 17 Sep, 2023 6 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull x86 fixes from Ingo Molnar: "Misc fixes: - Fix an UV boot crash - Skip spurious ENDBR generation on _THIS_IP_ - Fix ENDBR use in putuser() asm methods - Fix corner case boot crashes on 5-level paging - and fix a false positive WARNING on LTO kernels" * tag 'x86-urgent-2023-09-17' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/purgatory: Remove LTO flags x86/boot/compressed: Reserve more memory for page tables x86/ibt: Avoid duplicate ENDBR in __put_user_nocheck*() x86/ibt: Suppress spurious ENDBR x86/platform/uv: Use alternate source for socket to node data
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull scheduler fixes from Ingo Molnar: "Fix a performance regression on large SMT systems, an Intel SMT4 balancing bug, and a topology setup bug on (Intel) hybrid processors" * tag 'sched-urgent-2023-09-17' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/sched: Restore the SD_ASYM_PACKING flag in the DIE domain sched/fair: Fix SMT4 group_smt_balance handling sched/fair: Optimize should_we_balance() for large SMT systems
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull objtool fix from Ingo Molnar: "Fix a cold functions related false-positive objtool warning that triggers on Clang" * tag 'objtool-urgent-2023-09-17' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: objtool: Fix _THIS_IP_ detection for cold functions
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull WARN fix from Ingo Molnar: "Fix a missing preempt-enable in the WARN() slowpath" * tag 'core-urgent-2023-09-17' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: panic: Reenable preemption in WARN slowpath
-
Linus Torvalds authored
The choose_32_64() macros were added to deal with an odd inconsistency between the 32-bit and 64-bit layout of 'struct stat' way back when in commit a52dd971 ("vfs: de-crapify "cp_new_stat()" function"). Then a decade later Mikulas noticed that said inconsistency had been a mistake in the early x86-64 port, and shouldn't have existed in the first place. So commit 932aba1e ("stat: fix inconsistency between struct stat and struct compat_stat") removed the uses of the helpers. But the helpers remained around, unused. Get rid of them. Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
