This helper really is just a little helper for internal purposes, and is
I/O operation oriented, despite its name. It has already been misused
in commit 5008c3ec3f ("mtd: spi-nor: core: Check read CR support"), so
rename it to clarify its purpose: it is only useful for reads and page
programs.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Commit 5008c3ec3f ("mtd: spi-nor: core: Check read CR support") adds a
controller check to make sure the core will not use CR reads on
controllers not supporting them. The approach is valid but the fix is
incorrect. Unfortunately, the author could not catch it, because the
expected behavior was met. The patch indeed drops the RDCR capability,
but it does it for all controllers!
The issue comes from the use of spi_nor_spimem_check_op() which is an
internal helper dedicated to check read/write operations only, despite
its generic name.
This helper looks for the biggest number of address bytes that can be
used for a page operation and tries 4 then 3. It then calls the usual
spi-mem helpers to do the checks. These will always fail because there
is now an inconsistency: the address cycles are forced to 4 (then 3)
bytes, but the bus width during the address cycles rightfully remains
0. There is a non-zero address length but a zero address bus width,
which is an invalid combination.
The correct check in this case is to directly call spi_mem_supports_op()
which doesn't messes up with the operation content.
Fixes: 5008c3ec3f ("mtd: spi-nor: core: Check read CR support")
Cc: stable@vger.kernel.org
Acked-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Acked-by: Takahiro Kuwano <takahiro.kuwano@infineon.com>
Reviewed-by: Pratyush Yadav <pratyush@kernel.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
This was done entirely with mindless brute force, using
git grep -l '\<k[vmz]*alloc_objs*(.*, GFP_KERNEL)' |
xargs sed -i 's/\(alloc_objs*(.*\), GFP_KERNEL)/\1)/'
to convert the new alloc_obj() users that had a simple GFP_KERNEL
argument to just drop that argument.
Note that due to the extreme simplicity of the scripting, any slightly
more complex cases spread over multiple lines would not be triggered:
they definitely exist, but this covers the vast bulk of the cases, and
the resulting diff is also then easier to check automatically.
For the same reason the 'flex' versions will be done as a separate
conversion.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This is the result of running the Coccinelle script from
scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to
avoid scalar types (which need careful case-by-case checking), and
instead replace kmalloc-family calls that allocate struct or union
object instances:
Single allocations: kmalloc(sizeof(TYPE), ...)
are replaced with: kmalloc_obj(TYPE, ...)
Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...)
are replaced with: kmalloc_objs(TYPE, COUNT, ...)
Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...)
are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...)
(where TYPE may also be *VAR)
The resulting allocations no longer return "void *", instead returning
"TYPE *".
Signed-off-by: Kees Cook <kees@kernel.org>
Some SPI controllers like Intel's one on the PCI bus do not support
opcode 35h. This opcode is used to read the Configuration Register on
SPI-NOR chips that have 16-bit Status Register configured regardless
of the controller support for it. Adding a check call in the setup step
allows disabling use of the 35h opcode and falling back to the manual
Status Registers management.
Before:
openat(AT_FDCWD, "/dev/mtd0", O_RDWR) = 4
ioctl(4, MIXER_WRITE(6) or MEMUNLOCK, {start=0, length=0x2000000}) = -1
EOPNOTSUPP
After:
openat(AT_FDCWD, "/dev/mtd0", O_RDWR) = 4
ioctl(4, MIXER_WRITE(6) or MEMUNLOCK, {start=0, length=0x2000000}) = 0
ioctl(4, MIXER_WRITE(5) or MEMLOCK, {start=0x1800000, length=0x800000}) = 0
Suggested-by: Adeel Arshad <adeel.arshad@intel.com>
Signed-off-by: Jakub Czapiga <czapiga@google.com>
Reviewed-by: Pratyush Yadav <pratyush@kernel.org>
Signed-off-by: Pratyush Yadav <pratyush@kernel.org>
On Octal DTR capable flashes like Micron Xcella the writes cannot start
or end at an odd address in Octal DTR mode. Extra 0xff bytes need to be
appended or prepended to make sure the start address and end address are
even. 0xff is used because on NOR flashes a program operation can only
flip bits from 1 to 0, not the other way round. 0 to 1 flip needs to
happen via erases.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Reviewed-by: Michael Walle <michael@walle.cc>
Signed-off-by: Luke Wang <ziniu.wang_1@nxp.com>
Signed-off-by: Pratyush Yadav <pratyush@kernel.org>
Link: https://lore.kernel.org/r/20250708091646.292-2-ziniu.wang_1@nxp.com
On Octal DTR capable flashes like Micron Xcella reads cannot start or
end at an odd address in Octal DTR mode. Extra bytes need to be read at
the start or end to make sure both the start address and length remain
even.
To avoid allocating too much extra memory, thereby putting unnecessary
memory pressure on the system, the temporary buffer containing the extra
padding bytes is capped at PAGE_SIZE bytes. The rest of the 2-byte
aligned part should be read directly in the main buffer.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Reviewed-by: Michael Walle <michael@walle.cc>
Signed-off-by: Luke Wang <ziniu.wang_1@nxp.com>
Signed-off-by: Pratyush Yadav <pratyush@kernel.org>
Link: https://lore.kernel.org/r/20250708091646.292-1-ziniu.wang_1@nxp.com
The core driver is using of_property_read_bool() and relies on implicit
inclusion of <linux/of.h>, which comes from <linux/mtd/mtd.h>.
It is good practice to directly include all headers used, it avoids
implicit dependencies and spurious breakage if someone rearranges
headers and causes the implicit include to vanish.
Include the missing header.
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/r/20250307-spi-nor-headers-cleanup-v1-1-c186a9511c1e@linaro.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Pull MTD updates from Miquel Raynal:
"MTD changes:
- There's been no major core change, just a bunch of driver related
improvements.
Amongst them the conversion to of_property_present() for
non-boolean properties, the addition of the support for Fujitsu
MB85RS128TY FRAM, a couple of improvements to the phram driver and
the usual load of misc changes.
Raw NAND changes:
- A new controller driver, from Nuvoton, has been merged
- Bastien Curutchet has contributed a series improving the Davinci
controller driver, both on the organization of the code, but also
on the performance side. The binding has also been converted to
yaml, received a new OOB layout and now supports on-die ECC engines
- The Qualcomm controller driver has been deeply cleaned to extract
some parts of the code into a shared file with the Qualcomm SPI
memory controller
- Aside from these main changes, the Cadence binding has been
converted to yaml, the brcmnand controller driver has received a
small fix, otherwise some more minor changes have also made their
way in
SPI NAND changes:
- The SPI NAND subsystem has seen a great improvement, with the
advent of DTR operations (DDR operations, which may be extended to
the address cycles). The first vendor driver to benefit from these
improvements is the Winbond driver
- A new manufacturer driver is added SkyHigh, with a new constraint
for the core, it is impossible to disable the on-die ECC engine
- A Foresee device is also now supported
SPI NOR changes:
- Several flash entries have been added: Atmel AT25SF321, Spansion
S28HL256T and S28HL02GT
- Support for vcc-supply regulators and their DT bindings has been
added
- The mx25u25635f entry has been dropped. The flash shares its ID
with mx25u25645g and both parts have an SFDP table. Removing their
entry lets them be driven by the generic SFDP-based driver"
* tag 'mtd/for-6.14' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux: (47 commits)
mtd: spinand: skyhigh: Align with recent read from cache variant changes
mtd: spinand: winbond: Add support for DTR operations
mtd: spinand: winbond: Add comment about naming
mtd: spinand: winbond: Update the *JW chip definitions
mtd: spinand: Add support for read DTR operations
mtd: spinand: Enhance the logic when picking a variant
mtd: spinand: Add an optional frequency to read from cache macros
mtd: spinand: Create distinct fast and slow read from cache variants
mtd: hyperbus: Use of_property_present() for non-boolean properties
mtd: st_spi_fsm: Switch from CONFIG_PM_SLEEP guards to pm_sleep_ptr()
mtd: rawnand: davinci: add ROM supported OOB layout
mtd: spi-nor: sysfs: constify 'struct bin_attribute'
mtd: spi-nor: spansion: Add support for S28HL02GT
mtd: spi-nor: spansion: Add support for S28HL256T
mtd: spi-nor: extend description of size member of struct flash_info
mtd: rawnand: davinci: Reduce polling interval in NAND_OP_WAITRDY_INSTR
mtd: rawnand: qcom: Fix build issue on x86 architecture
mtd: rawnand: qcom: use FIELD_PREP and GENMASK
mtd: nand: Add qpic_common API file
mtd: rawnand: qcom: Add qcom prefix to common api
...
This reverts commit 98d1fb94ce.
The commit uses data nbits instead of addr nbits for dummy phase. This
causes a regression for all boards where spi-tx-bus-width is smaller
than spi-rx-bus-width. It is a common pattern for boards to have
spi-tx-bus-width == 1 and spi-rx-bus-width > 1. The regression causes
all reads with a dummy phase to become unavailable for such boards,
leading to a usually slower 0-dummy-cycle read being selected.
Most controllers' supports_op hooks call spi_mem_default_supports_op().
In spi_mem_default_supports_op(), spi_mem_check_buswidth() is called to
check if the buswidths for the op can actually be supported by the
board's wiring. This wiring information comes from (among other things)
the spi-{tx,rx}-bus-width DT properties. Based on these properties,
SPI_TX_* or SPI_RX_* flags are set by of_spi_parse_dt().
spi_mem_check_buswidth() then uses these flags to make the decision
whether an op can be supported by the board's wiring (in a way,
indirectly checking against spi-{rx,tx}-bus-width).
Now the tricky bit here is that spi_mem_check_buswidth() does:
if (op->dummy.nbytes &&
spi_check_buswidth_req(mem, op->dummy.buswidth, true))
return false;
The true argument to spi_check_buswidth_req() means the op is treated as
a TX op. For a board that has say 1-bit TX and 4-bit RX, a 4-bit dummy
TX is considered as unsupported, and the op gets rejected.
The commit being reverted uses the data buswidth for dummy buswidth. So
for reads, the RX buswidth gets used for the dummy phase, uncovering
this issue. In reality, a dummy phase is neither RX nor TX. As the name
suggests, these are just dummy cycles that send or receive no data, and
thus don't really need to have any buswidth at all.
Ideally, dummy phases should not be checked against the board's wiring
capabilities at all, and should only be sanity-checked for having a sane
buswidth value. Since we are now at rc7 and such a change might
introduce many unexpected bugs, revert the commit for now. It can be
sent out later along with the spi_mem_check_buswidth() fix.
Fixes: 98d1fb94ce ("mtd: spi-nor: core: replace dummy buswidth from addr to data")
Reported-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Closes: https://lore.kernel.org/linux-mtd/3342163.44csPzL39Z@steina-w/
Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Signed-off-by: Pratyush Yadav <pratyush@kernel.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
The default dummy cycle for Macronix SPI NOR flash in Octal Output
Read Mode(1-1-8) is 20.
Currently, the dummy buswidth is set according to the address bus width.
In the 1-1-8 mode, this means the dummy buswidth is 1. When converting
dummy cycles to bytes, this results in 20 x 1 / 8 = 2 bytes, causing the
host to read data 4 cycles too early.
Since the protocol data buswidth is always greater than or equal to the
address buswidth. Setting the dummy buswidth to match the data buswidth
increases the likelihood that the dummy cycle-to-byte conversion will be
divisible, preventing the host from reading data prematurely.
Fixes: 0e30f47232 ("mtd: spi-nor: add support for DTR protocol")
Cc: stable@vger.kernel.org
Reviewed-by: Pratyush Yadav <pratyush@kernel.org>
Signed-off-by: Cheng Ming Lin <chengminglin@mxic.com.tw>
Link: https://lore.kernel.org/r/20241112075242.174010-2-linchengming884@gmail.com
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Macronix swaps bytes on a 16-bit boundary when configured in Octal DTR.
The byte order of 16-bit words is swapped when read or written in 8D-8D-8D
mode compared to STR modes. Allow operations to specify the byte order in
DTR mode, so that controllers can swap the bytes back at run-time to
address the flash's endianness requirements, if they are capable. If the
controller is not capable of swapping the bytes, the protocol is downgrade
via spi_nor_spimem_adjust_hwcaps(). When available, the swapping of the
bytes is always done regardless if it's a data or register access, so that
it comply with the JESD216 requirements: "Byte order of 16-bit words is
swapped when read in 8D-8D-8D mode compared to 1-1-1".
Merge Tudor's patch and add modifications for suiting newer version
of Linux kernel.
Suggested-by: Michael Walle <mwalle@kernel.org>
Signed-off-by: JaimeLiao <jaimeliao@mxic.com.tw>
Signed-off-by: AlvinZhou <alvinzhou@mxic.com.tw>
Link: https://lore.kernel.org/r/20240926141956.2386374-4-alvinzhou.tw@gmail.com
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
The Everspin FRAM devices are the only user of the NO_FR flag. Drop the
global flag and instead use a manufacturer fixup for the Everspin
flashes to drop the fast read support.
Signed-off-by: Michael Walle <mwalle@kernel.org>
Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Reviewed-by: Pratyush Yadav <pratyush@kernel.org>
[pratyush@kernel.org: s/evervision/everspin/g in code and commit message]
Signed-off-by: Pratyush Yadav <pratyush@kernel.org>
Link: https://lore.kernel.org/r/20240419141249.609534-5-mwalle@kernel.org
With the removal of the Xilinx flashes, there is no more flash driver
using that hook. The original intention was to let the driver configure
special requirements like page size an opcodes. This is already
possible by other means and it is unlikely a flash will overwrite the
(more or less complex) setup function.
Signed-off-by: Michael Walle <mwalle@kernel.org>
Reviewed-by: Pratyush Yadav <pratyush@kernel.org>
Acked-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Signed-off-by: Pratyush Yadav <pratyush@kernel.org>
Link: https://lore.kernel.org/r/20240419141249.609534-4-mwalle@kernel.org
The Xilinx flashes were the only users of page sizes that were not power
of 2. Support for them has been dropped, thus we can also get rid of the
special page size handling for it.
Signed-off-by: Michael Walle <mwalle@kernel.org>
Acked-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Reviewed-by: Pratyush Yadav <pratyush@kernel.org>
[pratyush@kernel.org: fixup minor typos and grammar in commit message]
Signed-off-by: Pratyush Yadav <pratyush@kernel.org>
Link: https://lore.kernel.org/r/20240419141249.609534-3-mwalle@kernel.org
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>
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
...
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>
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>
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 <mwalle@kernel.org>
Link: https://lore.kernel.org/r/20230807-mtd-flash-info-db-rework-v3-11-e60548861b10@kernel.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
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 <mwalle@kernel.org>
Link: https://lore.kernel.org/r/20230807-mtd-flash-info-db-rework-v3-10-e60548861b10@kernel.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
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 <mwalle@kernel.org>
Link: https://lore.kernel.org/r/20230807-mtd-flash-info-db-rework-v3-9-e60548861b10@kernel.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
.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 <mwalle@kernel.org>
Link: https://lore.kernel.org/r/20230807-mtd-flash-info-db-rework-v3-5-e60548861b10@kernel.org
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
