linux.git/drivers/mtd/maps, branch v6.6.132

mtd: maps: physmap-core: fix flash size larger than 32-bit

2024-03-26T22:19:52+00:00

[ Upstream commit 3884f03edd34887514a0865a80769cd5362d5c3b ]

mtd-ram can potentially be larger than 4GB. get_bitmask_order() uses
fls() that is not guaranteed to work with values larger than 32-bit.
Specifically on aarch64 fls() returns 0 when all 32 LSB bits are clear.
Use fls64() instead.

Fixes: ba32ce95cbd987 ("mtd: maps: Merge gpio-addr-flash.c into physmap-core.c")
Signed-off-by: Baruch Siach 
Signed-off-by: Miquel Raynal 
Link: https://lore.kernel.org/linux-mtd/9fbf3664ce00f8b07867f1011834015f21d162a5.1707388458.git.baruch@tkos.co.il
Signed-off-by: Sasha Levin

mtd: maps: vmu-flash: Fix the (mtd core) switch to ref counters

2024-02-01T00:18:50+00:00

commit a7d84a2e7663bbe12394cc771107e04668ea313a upstream.

While switching to ref counters for track mtd devices use, the vmu-flash
driver was forgotten. The reason for reading the ref counter seems
debatable, but let's just fix the build for now.

Fixes: 19bfa9ebebb5 ("mtd: use refcount to prevent corruption")
Reported-by: kernel test robot 
Closes: https://lore.kernel.org/oe-kbuild-all/202312022315.79twVRZw-lkp@intel.com/
Cc: stable@vger.kernel.org
Signed-off-by: Miquel Raynal 
Link: https://lore.kernel.org/linux-mtd/20231205075936.13831-1-miquel.raynal@bootlin.com
Signed-off-by: Greg Kroah-Hartman

mtd: physmap-core: Restore map_rom fallback

2023-09-11T15:48:22+00:00

When the exact mapping type driver was not available, the old
physmap_of_core driver fell back to mapping the region as ROM.
Unfortunately this feature was lost when the DT and pdata cases were
merged.  Revive this useful feature.

Fixes: 642b1e8dbed7bbbf ("mtd: maps: Merge physmap_of.c into physmap-core.c")
Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Miquel Raynal 
Link: https://lore.kernel.org/linux-mtd/550e8c8c1da4c4baeb3d71ff79b14a18d4194f9e.1693407371.git.geert+renesas@glider.be

mtd: maps: fix -Wvoid-pointer-to-enum-cast warning

2023-08-18T14:38:54+00:00

When building with clang 18 I see the following warning:
|       drivers/mtd/maps/physmap-versatile.c:209:25: warning: cast to smaller
|               integer type 'enum versatile_flashprot' from 'const void *' [-Wvoid-pointer-to-enum-cast]
|         209 |                 versatile_flashprot = (enum versatile_flashprot)devid->data;

This is due to the fact that `devid->data` is a void* while `enum versatile_flashprot`
has the size of an int.

Cast `devid->data` to a uintptr_t to silence the above warning for clang
builds using W=1.

Link: https://github.com/ClangBuiltLinux/linux/issues/1910
Reported-by: Nathan Chancellor 
Signed-off-by: Justin Stitt 
Signed-off-by: Miquel Raynal 
Link: https://lore.kernel.org/linux-mtd/20230816-void-drivers-mtd-maps-physmap-versatile-v2-1-433a25272bfa@google.com

mtd: Explicitly include correct DT includes

2023-07-27T15:03:41+00:00

The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it was merged into the regular platform bus.
As part of that merge prepping Arm DT support 13 years ago, they
"temporarily" include each other. They also include platform_device.h
and of.h. As a result, there's a pretty much random mix of those include
files used throughout the tree. In order to detangle these headers and
replace the implicit includes with struct declarations, users need to
explicitly include the correct includes.

Signed-off-by: Rob Herring 
Reviewed-by: Linus Walleij 
Acked-by: Heiko Stuebner 
Signed-off-by: Miquel Raynal 
Link: https://lore.kernel.org/linux-mtd/20230714174751.4060439-1-robh@kernel.org

mtd: physmap-core: Use devm_platform_get_and_ioremap_resource()

2023-07-12T12:08:31+00:00

Convert platform_get_resource(), devm_ioremap_resource() to a single
call to devm_platform_get_and_ioremap_resource(), as this is exactly
what this function does.

Signed-off-by: Yangtao Li 
Signed-off-by: Miquel Raynal 
Link: https://lore.kernel.org/linux-mtd/20230707040622.78174-18-frank.li@vivo.com

mtd: lantiq-flash: Use devm_platform_get_and_ioremap_resource()

2023-07-12T12:08:24+00:00

Convert platform_get_resource(), devm_ioremap_resource() to a single
call to devm_platform_get_and_ioremap_resource(), as this is exactly
what this function does.

Signed-off-by: Yangtao Li 
Signed-off-by: Miquel Raynal 
Link: https://lore.kernel.org/linux-mtd/20230707040622.78174-14-frank.li@vivo.com

mtd: plat-ram: Use devm_platform_get_and_ioremap_resource()

2023-07-12T12:08:22+00:00

Convert platform_get_resource(), devm_ioremap_resource() to a single
call to devm_platform_get_and_ioremap_resource(), as this is exactly
what this function does.

Signed-off-by: Yangtao Li 
Signed-off-by: Miquel Raynal 
Link: https://lore.kernel.org/linux-mtd/20230707040622.78174-13-frank.li@vivo.com

mtd: maps: pismo: Switch back to use i2c_driver's .probe()

2023-06-19T08:26:03+00:00

After commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new()
call-back type"), all drivers being converted to .probe_new() and then
commit 03c835f498b5 ("i2c: Switch .probe() to not take an id parameter")
convert back to (the new) .probe() to be able to eventually drop
.probe_new() from struct i2c_driver.

Signed-off-by: Uwe Kleine-König 
Signed-off-by: Miquel Raynal 
Link: https://lore.kernel.org/linux-mtd/20230611204327.828122-1-u.kleine-koenig@pengutronix.de

Merge tag 'spi-nor/for-6.4' into mtd/next

2023-04-19T18:38:20+00:00

SPI NOR core changes:
* introduce Read While Write support for flashes featuring several banks
* set the 4-Byte Address Mode method based on SFDP data
* allow post_sfdp hook to return errors
* parse SCCR MC table and introduce support for multi-chip devices

SPI NOR manufacturer drivers changes:
* macronix: add support for mx25uw51245g with RWW
* spansion:
  - determine current address mode at runtime as it can be changed in a
    non-volatile way and differ from factory defaults or from what SFDP
    advertises.
  - enable JFFS2 write buffer mode for few ECC'd NOR flashes: S25FS256T,
    s25hx and s28hx
  - add support for s25hl02gt and s25hs02gt

Signed-off-by: Miquel Raynal