IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The i should be signed to find out the end of the loop. Otherwise,
i >= 0 is always true and loop becomes infinite. Make its type to be
int.
Fixes: 6a9eda34418f ("mtd: spi-nor: core: set mtd->eraseregions for non-uniform erase map")
Signed-off-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Reviewed-by: Michael Walle <mwalle@kernel.org>
Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20240304090103.818092-1-usama.anjum@collabora.com
Some of Infineon SPI NOR flash devices support hybrid sector layout that
overlays 4KB sectors on a 256KB sector and SPI NOR framework recognizes
that by parsing SMPT and construct params->erase_map. The hybrid sector
layout is similar to CFI flash devices that have small sectors on top
and/or bottom address. In case of CFI flash devices, the erase map
information is parsed through CFI table and populated into
mtd->eraseregions so that users can create MTD partitions that aligned
with small sector boundaries. This patch provides the same capability to
SPI NOR flash devices that have non-uniform erase map.
Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>
Reviewed-by: Michael Walle <mwalle@kernel.org>
Link: https://lore.kernel.org/r/35d0962986e493b06c13bdf7ada8130a9966dc02.1708404584.git.Takahiro.Kuwano@infineon.com
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Introduce n_regions in spi_nor_erase_map structure and remove
SNOR_LAST_REGION flag. Loop logics that depend on the flag are also
reworked to use n_regions as loop condition.
Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>
Suggested-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Suggested-by: Michael Walle <mwalle@kernel.org>
Reviewed-by: Michael Walle <mwalle@kernel.org>
Link: https://lore.kernel.org/r/eded84294bd81e966d6f423e578fc2cfb9a4a5b6.1708404584.git.Takahiro.Kuwano@infineon.com
[ta: update spi_nor_init_erase_cmd_list() and break the for loop sooner.]
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Encoding bitmask flags into offset worsen the code readability. The
erase type mask and flags should be stored in dedicated members. Also,
erase_map.uniform_erase_type can be removed as it is redundant.
Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>
Suggested-by: Michael Walle <mwalle@kernel.org>
Reviewed-by: Michael Walle <mwalle@kernel.org>
Link: https://lore.kernel.org/r/8e5e9e4081ed9f16ea9dce30693304a4b54d19b1.1708404584.git.Takahiro.Kuwano@infineon.com
[ta: remove spi_nor_region_end()]
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Apart from preventing the mtdblk to run on top of ftl or ubiblk (which
may cause security issues and has no meaning anyway), there are a few
misc fixes.
* Raw NAND
Two meaningful changes this time. The conversion of the brcmnand driver
to the ->exec_op() API, this series brought additional changes to the
core in order to help controller drivers to handle themselves the WP pin
during destructive operations when relevant.
There is also a series bringing important fixes to the sequential read
feature.
As always, there is as well a whole bunch of miscellaneous W=1 fixes,
together with a few runtime fixes (double free, timeout value, OOB
layout, missing register initialization) and the usual load of remove
callbacks turned into void (which led to switch the txx9ndfmc driver to
use module_platform_driver()).
* SPI NOR
SPI NOR comes with die erase support for multi die flashes, with new
octal protocols (1-1-8 and 1-8-8) parsed from SFDP and with an updated
documentation about what the contributors shall consider when proposing
flash additions or updates.
Michael Walle stepped out from the reviewer role to maintainer.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEE9HuaYnbmDhq/XIDIJWrqGEe9VoQFAmWFeUsACgkQJWrqGEe9
VoSBzQgAsUDieAMF4zIo5QN6l+8DpDMrkOK1Z5l4B/3goA2ZUz4cs80Kj/53l/kO
tD8Ckn5SA82ZrVZiCJS5D8yplB+4+IWFU9dV/TcoINafLew5R/bBqo4XwgfVgvwy
a4PuFlV9eedDW18cfbZA29TsnKoWdGaWxsyY+Gceukm94VuQbaZIPs3wkmBdWEOM
V+FZaWg7vLW99x2XFDNpBqKFSzjTPAt1W5WM2ASdrb3pSKVOlt02qFlvMFwodVeR
YExYwd1BNNsn9I6lKF/07a5wdX4NygXzqIpYytIaTzeBV3iRgN59uMfWbOh6tHeu
MOEnmWoc3RwsyBXlBTKGafk2DTB6zg==
=gbYM
-----END PGP SIGNATURE-----
Merge tag 'mtd/for-6.8' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux
Pull mtd updates from Miquel Raynal:
"MTD:
- Apart from preventing the mtdblk to run on top of ftl or ubiblk
(which may cause security issues and has no meaning anyway), there
are a few misc fixes.
Raw NAND:
- Two meaningful changes this time. The conversion of the brcmnand
driver to the ->exec_op() API, this series brought additional
changes to the core in order to help controller drivers to handle
themselves the WP pin during destructive operations when relevant.
- There is also a series bringing important fixes to the sequential
read feature.
- As always, there is as well a whole bunch of miscellaneous W=1
fixes, together with a few runtime fixes (double free, timeout
value, OOB layout, missing register initialization) and the usual
load of remove callbacks turned into void (which led to switch the
txx9ndfmc driver to use module_platform_driver()).
SPI NOR:
- SPI NOR comes with die erase support for multi die flashes, with
new octal protocols (1-1-8 and 1-8-8) parsed from SFDP and with an
updated documentation about what the contributors shall consider
when proposing flash additions or updates.
- Michael Walle stepped out from the reviewer role to maintainer"
* tag 'mtd/for-6.8' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux: (39 commits)
mtd: rawnand: Clarify conditions to enable continuous reads
mtd: rawnand: Prevent sequential reads with on-die ECC engines
mtd: rawnand: Fix core interference with sequential reads
mtd: rawnand: Prevent crossing LUN boundaries during sequential reads
mtd: Fix gluebi NULL pointer dereference caused by ftl notifier
dt-bindings: mtd: partitions: u-boot: Fix typo
mtd: rawnand: s3c2410: fix Excess struct member description kernel-doc warnings
MAINTAINERS: change my mail to the kernel.org one
mtd: spi-nor: sfdp: get the 1-1-8 and 1-8-8 protocol from SFDP
mtd: spi-nor: drop superfluous debug prints
mtd: spi-nor: sysfs: hide the flash name if not set
mtd: spi-nor: mark the flash name as obsolete
mtd: spi-nor: print flash ID instead of name
mtd: maps: vmu-flash: Fix the (mtd core) switch to ref counters
mtd: ssfdc: Remove an unused variable
mtd: rawnand: diskonchip: fix a potential double free in doc_probe
mtd: rawnand: rockchip: Add missing title to a kernel doc comment
mtd: rawnand: rockchip: Rename a structure
mtd: rawnand: pl353: Fix kernel doc
mtd: spi-nor: micron-st: Add support for mt25qu01g
...
BFPT 17th DWORD contains the information about 1-1-8 and 1-8-8.
Parse BFPT DWORD[17] instruction to determine whether flash
supports 1-1-8 and 1-8-8, and set its dummy cycles accordingly.
Validated only the 1-1-8 read using a macronix flash with
Xilinx board zynq-picozed.
Signed-off-by: JaimeLiao <jaimeliao@mxic.com.tw>
Reviewed-by: Michael Walle <mwalle@kernel.org>
Link: https://lore.kernel.org/r/20231219102103.92738-2-jaimeliao.tw@gmail.com
[ta: update commit message, get rid of extra dereference]
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
The mtd data shall be obtained with the mtd ioctls or with
new debugfs entries if one cares. Drop the debug prints.
Reviewed-by: Michael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20231215082138.16063-5-tudor.ambarus@linaro.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
The flash name is not reliable as we saw flash ID collisions.
Hide the flash name if not set.
Signed-off-by: JaimeLiao <jaimeliao@mxic.com.tw>
Reviewed-by: Michael Walle <michael@walle.cc>
[ta: update commit subject and description and the sysfs description]
Link: https://lore.kernel.org/r/20231215082138.16063-4-tudor.ambarus@linaro.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
We saw flash ID collisions which make the flash name unreliable. Print
the manufacturer and device ID instead of the flash name.
Lower the print to dev_dbg to stop polluting the kernel log.
Suggested-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Michael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20231215082138.16063-2-tudor.ambarus@linaro.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
JESD216 mentions die erase, but does not provide an opcode for it.
Check BFPT dword 11, bits 30:24, "Chip Erase, Typical time", it says:
"Typical time to erase one chip (die). User must poll device busy to
determine if the operation has completed. For a device consisting of
multiple dies, that are individually accessed, the time is for each die
to which a chip erase command is applied."
So when a flash consists of a single die, this is the erase time for the
full chip (die) erase, and when it consists of multiple dies, it's the
die erase time. Chip and die are the same thing.
Add support for die erase. For now, benefit of the die erase when addr
and len are aligned with die size. This could be improved however for
the uniform and non-uniform erases cases to use the die erase when
possible. For example if one requests that an erase of a 2 die device
starting from the last 64KB of the first die to the end of the flash
size, we could use just 2 commands, a 64KB erase and a die erase.
This improvement is left as an exercise for the reader.
Tested-by: Fabio Estevam <festevam@denx.de>
Link: https://lore.kernel.org/r/20231125123529.55686-2-tudor.ambarus@linaro.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
When the software reset command isn't supported, we now stop reporting
the warning message to avoid unnecessary warnings and potential confusion.
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Reviewed-by: Michael Walle <michael@walle.cc>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Pratyush Yadav <pratyush@kernel.org>
Signed-off-by: "Chia-Lin Kao (AceLan)" <acelan.kao@canonical.com>
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Link: https://lore.kernel.org/r/20231129064311.272422-2-acelan.kao@canonical.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This commit updates the SPI subsystem, particularly affecting "SPI MEM"
drivers and core parts, by replacing the -ENOTSUPP error code with
-EOPNOTSUPP.
The key motivations for this change are as follows:
1. The spi-nor driver currently uses EOPNOTSUPP, whereas calls to spi-mem
might return ENOTSUPP. This update aims to unify the error reporting
within the SPI subsystem for clarity and consistency.
2. The use of ENOTSUPP has been flagged by checkpatch as inappropriate,
mainly being reserved for NFS-related errors. To align with kernel coding
standards and recommendations, this change is being made.
3. By using EOPNOTSUPP, we provide more specific context to the error,
indicating that a particular operation is not supported. This helps
differentiate from the more generic ENOTSUPP error, allowing drivers to
better handle and respond to different error scenarios.
Risks and Considerations:
While this change is primarily intended as a code cleanup and error code
unification, there is a minor risk of breaking user-space applications
that rely on specific return codes for unsupported operations. However,
this risk is considered low, as such use-cases are unlikely to be common
or critical. Nevertheless, developers and users should be aware of this
change, especially if they have scripts or tools that specifically handle
SPI error codes.
This commit does not introduce any functional changes to the SPI subsystem
or the affected drivers.
Signed-off-by: "Chia-Lin Kao (AceLan)" <acelan.kao@canonical.com>
Acked-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Michael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20231129064311.272422-1-acelan.kao@canonical.com
Signed-off-by: Mark Brown <broonie@kernel.org>
them slimmer and self explanatory. In order to make the entries
as slim as possible, we introduced sane default values so that
the actual flash entries don't need to specify them. We now use
a flexible macro to specify the flash ID instead of the previous
INFOx() macros that had hardcoded ID lengths.
Instead of:
- { "w25q512nwm", INFO(0xef8020, 0, 64 * 1024, 0)
- OTP_INFO(256, 3, 0x1000, 0x1000) },
We now use:
+ .id = SNOR_ID(0xef, 0x80, 0x20),
+ .name = "w25q512nwm",
+ .otp = SNOR_OTP(256, 3, 0x1000, 0x1000),
We also removed some flash entries: the very old Catalyst
SPI EEPROMs that were introduced once with the SPI-NOR subsystem,
and a Fujitsu MRAM. Both should use the at25 EEPROM driver.
The latter even has device tree bindings for the at25 driver.
We made sure that the conversion didn't introduce any unwanted
changes by comparing the .rodata segment before and after the
conversion. The patches landed in linux-next immediately after
v6.6-rc2, we haven't seen any regressions yet.
Apart of the autumn cleaning we introduced a new flash entry,
at25ff321a, and added block protection support for mt25qu512a.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEHUIqys8OyG1eHf7fS1VPR6WNFOkFAmUvhfgACgkQS1VPR6WN
FOlQUAf/ZFUi5nktXOERKghKIwQulTIWdxsV2ZitezzFEPeObHaXR/kiF53mKbyS
txutJglHFYpsLaLptGwrUja2bWVI5OEZCLknIsRRPH4wy3aWlyef1yonl6//U/O9
lWLEKcUFgsmJKTe+Ga6BWJFBlExCfhPM6Hu9q3O/z0cV107fNdHBo41p9Xvn2B3l
miNyxhsojdXfDIFexjZHC+kYS5cQv9fRLyBKDvWoAsjSj9HoPt9Y/46x2TKfsJ83
d8JJH8ABwk6hpgjcTECorqcljsB6FdQ80s+0klmrfqO1UBt0ptrS/OwcmYMuivZn
urpGYUAWFgFGivBb+nUfG/VgAQ3E7w==
=qzxq
-----END PGP SIGNATURE-----
Merge tag 'spi-nor/for-6.7' into mtd/next
For SPI NOR we cleaned the flash info entries in order to have
them slimmer and self explanatory. In order to make the entries
as slim as possible, we introduced sane default values so that
the actual flash entries don't need to specify them. We now use
a flexible macro to specify the flash ID instead of the previous
INFOx() macros that had hardcoded ID lengths.
Instead of:
- { "w25q512nwm", INFO(0xef8020, 0, 64 * 1024, 0)
- OTP_INFO(256, 3, 0x1000, 0x1000) },
We now use:
+ .id = SNOR_ID(0xef, 0x80, 0x20),
+ .name = "w25q512nwm",
+ .otp = SNOR_OTP(256, 3, 0x1000, 0x1000),
We also removed some flash entries: the very old Catalyst
SPI EEPROMs that were introduced once with the SPI-NOR subsystem,
and a Fujitsu MRAM. Both should use the at25 EEPROM driver.
The latter even has device tree bindings for the at25 driver.
We made sure that the conversion didn't introduce any unwanted
changes by comparing the .rodata segment before and after the
conversion. The patches landed in linux-next immediately after
v6.6-rc2, we haven't seen any regressions yet.
Apart of the autumn cleaning we introduced a new flash entry,
at25ff321a, and added block protection support for mt25qu512a.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Parse SFDP table to get size and functions of mt25qu512a. BFPT wrongly
advertises 16bit SR support and made the locking fail. Add a post BFPT
fixup hook to clear the 16bit SR support.
cat /sys/bus/spi/devices/spi-PRP0001:00/spi-nor/jedec_id
20bb20104400
cat /sys/bus/spi/devices/spi-PRP0001:00/spi-nor/manufacturer
st
cat /sys/bus/spi/devices/spi-PRP0001:00/spi-nor/partname
mt25qu512a
xxd -p /sys/bus/spi/devices/spi-PRP0001:00/spi-nor/sfdp
53464450060101ff00060110300000ff84000102800000ffffffffffffff
ffffffffffffffffffffffffffffffffffffe520fbffffffff1f29eb276b
273b27bbffffffffffff27bbffff29eb0c2010d80f520000244a99008b8e
03e1ac0127387a757a75fbbdd55c4a0f82ff81bd3d36ffffffffffffffff
ffffffffffffffffffe7ffff21dcffff
md5sum /sys/bus/spi/devices/spi-PRP0001:00/spi-nor/sfdp
610efba1647e00ac6db18beb11e84c04
/sys/bus/spi/devices/spi-PRP0001:00/spi-nor/sfdp
Signed-off-by: Mamta Shukla <mamta.shukla@leica-geosystems.com>
Reviewed-by: Pratyush Yadav <pratyush@kernel.org>
Link: https://lore.kernel.org/r/20231017074711.12167-2-tudor.ambarus@linaro.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
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>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Link: https://lore.kernel.org/linux-mtd/20231008200143.196369-21-u.kleine-koenig@pengutronix.de
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Link: https://lore.kernel.org/linux-mtd/20231008200143.196369-20-u.kleine-koenig@pengutronix.de
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 <mwalle@kernel.org>
Link: https://lore.kernel.org/r/20230807-mtd-flash-info-db-rework-v3-40-e60548861b10@kernel.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
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-39-e60548861b10@kernel.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
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-38-e60548861b10@kernel.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
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-37-e60548861b10@kernel.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
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-36-e60548861b10@kernel.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
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-35-e60548861b10@kernel.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
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.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
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-33-e60548861b10@kernel.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
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-32-e60548861b10@kernel.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
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-31-e60548861b10@kernel.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
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 <mwalle@kernel.org>
Link: https://lore.kernel.org/r/20230807-mtd-flash-info-db-rework-v3-29-e60548861b10@kernel.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
