linux-stable.git/drivers/mtd/chips, branch linux-5.4.y

mtd: cfi_cmdset_0001: Byte swap OTP info

2023-12-08T07:44:27+00:00

[ Upstream commit 565fe150624ee77dc63a735cc1b3bff5101f38a3 ]

Currently the offset into the device when looking for OTP
bits can go outside of the address of the MTD NOR devices,
and if that memory isn't readable, bad things happen
on the IXP4xx (added prints that illustrate the problem before
the crash):

cfi_intelext_otp_walk walk OTP on chip 0 start at reg_prot_offset 0x00000100
ixp4xx_copy_from copy from 0x00000100 to 0xc880dd78
cfi_intelext_otp_walk walk OTP on chip 0 start at reg_prot_offset 0x12000000
ixp4xx_copy_from copy from 0x12000000 to 0xc880dd78
8<--- cut here ---
Unable to handle kernel paging request at virtual address db000000
[db000000] *pgd=00000000
(...)

This happens in this case because the IXP4xx is big endian and
the 32- and 16-bit fields in the struct cfi_intelext_otpinfo are not
properly byteswapped. Compare to how the code in read_pri_intelext()
byteswaps the fields in struct cfi_pri_intelext.

Adding a small byte swapping loop for the OTP in read_pri_intelext()
and the crash goes away.

The problem went unnoticed for many years until I enabled
CONFIG_MTD_OTP on the IXP4xx as well, triggering the bug.

Cc: stable@vger.kernel.org
Reviewed-by: Nicolas Pitre 
Signed-off-by: Linus Walleij 
Signed-off-by: Miquel Raynal 
Link: https://lore.kernel.org/linux-mtd/20231020-mtd-otp-byteswap-v4-1-0d132c06aa9d@linaro.org
Signed-off-by: Sasha Levin

mtd: cfi_cmdset_0001: Support the absence of protection registers

2023-12-08T07:44:27+00:00

[ Upstream commit b359ed5184aebf9d987e54abc5dae7ac03ed29ae ]

The flash controller implemented by the Arm Base platform behaves like
the Intel StrataFlash J3 device, but omits several features. In
particular it doesn't implement a protection register, so "Number of
Protection register fields" in the Primary Vendor-Specific Extended
Query, is 0.

The Intel StrataFlash J3 datasheet only lists 1 as a valid value for
NumProtectionFields. It describes the field as:

	"Number of Protection register fields in JEDEC ID space.
	“00h,” indicates that 256 protection bytes are available"

While a value of 0 may arguably not be architecturally valid, the
driver's current behavior is certainly wrong: if NumProtectionFields is
0, read_pri_intelext() adds a negative value to the unsigned extra_size,
and ends up in an infinite loop.

Fix it by ignoring a NumProtectionFields of 0.

Signed-off-by: Jean-Philippe Brucker 
Tested-by: Sudeep Holla 
Tested-by: Catalin Marinas 
Signed-off-by: Vignesh Raghavendra 
Stable-dep-of: 565fe150624e ("mtd: cfi_cmdset_0001: Byte swap OTP info")
Signed-off-by: Sasha Levin

mtd: cfi_cmdset_0002: Use chip_ready() for write on S29GL064N

2022-06-14T16:12:03+00:00

commit 0a8e98305f63deaf0a799d5cf5532cc83af035d1 upstream.

Since commit dfeae1073583("mtd: cfi_cmdset_0002: Change write buffer to
check correct value") buffered writes fail on S29GL064N. This is
because, on S29GL064N, reads return 0xFF at the end of DQ polling for
write completion, where as, chip_good() check expects actual data
written to the last location to be returned post DQ polling completion.
Fix is to revert to using chip_good() for S29GL064N which only checks
for DQ lines to settle down to determine write completion.

Link: https://lore.kernel.org/r/b687c259-6413-26c9-d4c9-b3afa69ea124@pengutronix.de/
Fixes: dfeae1073583("mtd: cfi_cmdset_0002: Change write buffer to check correct value")
Cc: stable@vger.kernel.org
Signed-off-by: Tokunori Ikegami 
Acked-by: Vignesh Raghavendra 
Signed-off-by: Miquel Raynal 
Link: https://lore.kernel.org/linux-mtd/20220323170458.5608-3-ikegami.t@gmail.com
Signed-off-by: Greg Kroah-Hartman

mtd: cfi_cmdset_0002: Move and rename chip_check/chip_ready/chip_good_for_write

2022-06-14T16:11:47+00:00

commit 083084df578a8bdb18334f69e7b32d690aaa3247 upstream.

This is a preparation patch for the S29GL064N buffer writes fix. There
is no functional change.

Link: https://lore.kernel.org/r/b687c259-6413-26c9-d4c9-b3afa69ea124@pengutronix.de/
Fixes: dfeae1073583("mtd: cfi_cmdset_0002: Change write buffer to check correct value")
Signed-off-by: Tokunori Ikegami 
Cc: stable@vger.kernel.org
Acked-by: Vignesh Raghavendra 
Signed-off-by: Miquel Raynal 
Link: https://lore.kernel.org/linux-mtd/20220323170458.5608-2-ikegami.t@gmail.com
Signed-off-by: Greg Kroah-Hartman

mtd: fixup CFI on ixp4xx

2022-01-20T08:19:19+00:00

commit 603362b4a58393061dcfed1c7f0d0fd4aba61126 upstream.

drivers/mtd/maps/ixp4xx.c requires MTD_CFI_BE_BYTE_SWAP to be set
in order to compile.

drivers/mtd/maps/ixp4xx.c:57:4: error: #error CONFIG_MTD_CFI_BE_BYTE_SWAP required

This patch avoids the #error output by enforcing the policy in
Kconfig. Not sure if this is the right approach, but it helps doing
randconfig builds.

Signed-off-by: Arnd Bergmann 
Acked-by: Linus Walleij 
Signed-off-by: Miquel Raynal 
Link: https://lore.kernel.org/linux-mtd/20210927141045.1597593-1-arnd@kernel.org
Cc: Anders Roxell 
Signed-off-by: Greg Kroah-Hartman

mtd: cfi_cmdset_0002: fix crash when erasing/writing AMD cards

2021-08-26T12:36:12+00:00

commit 2394e628738933aa014093d93093030f6232946d upstream.

Erasing an AMD linear flash card (AM29F016D) crashes after the first
sector has been erased. Likewise, writing to it crashes after two bytes
have been written. The reason is a missing check for a null pointer -
the cmdset_priv field is not set for this type of card.

Fixes: 4844ef80305d ("mtd: cfi_cmdset_0002: Add support for polling status register")
Signed-off-by: Andreas Persson 
Signed-off-by: Miquel Raynal 
Link: https://lore.kernel.org/linux-mtd/DB6P189MB05830B3530B8087476C5CFE4C1159@DB6P189MB0583.EURP189.PROD.OUTLOOK.COM
Signed-off-by: Greg Kroah-Hartman

mtd: cfi_cmdset_0002: don't free cfi->cfiq in error path of cfi_amdstd_setup()

2020-10-01T11:17:16+00:00

[ Upstream commit 03976af89e3bd9489d542582a325892e6a8cacc0 ]

Else there may be a double-free problem, because cfi->cfiq will
be freed by mtd_do_chip_probe() if both the two invocations of
check_cmd_set() return failure.

Signed-off-by: Hou Tao 
Reviewed-by: Richard Weinberger 
Signed-off-by: Vignesh Raghavendra 
Signed-off-by: Sasha Levin

mtd: cfi_cmdset_0002: fix delayed error detection on HyperFlash

2020-01-23T07:22:57+00:00

commit c15995695ea971253ea9507f6732c8cd35384e01 upstream.

The commit 4844ef80305d ("mtd: cfi_cmdset_0002: Add support for polling
status register") added checking for the status register error bits into
chip_good() to only return 1 if these bits are 0s.  Unfortunately, this
means that polling using chip_good() always reaches a timeout condition
when erase or program failure bits are set. Let's fully delegate the task
of determining the error conditions to cfi_check_err_status() and make
chip_good() only look for the Device Ready/Busy condition.

Fixes: 4844ef80305d ("mtd: cfi_cmdset_0002: Add support for polling status register")
Signed-off-by: Sergei Shtylyov 
Signed-off-by: Vignesh Raghavendra 
Signed-off-by: Greg Kroah-Hartman

mtd: cfi_cmdset_0002: only check errors when ready in cfi_check_err_status()

2020-01-23T07:22:57+00:00

commit 72914a8cff7e1d910c58e125e15a0da409e3135f upstream.

Cypress S26K{L|S}P{128|256|512}S datasheet says that the error bits in
the status register are only valid when the "device ready" bit 7 is set.
Add the check for the device ready bit in cfi_check_err_status() as that
function isn't always called with this bit set.

Fixes: 4844ef80305d ("mtd: cfi_cmdset_0002: Add support for polling status register")
Signed-off-by: Sergei Shtylyov 
Signed-off-by: Vignesh Raghavendra 
Signed-off-by: Greg Kroah-Hartman

mtd: cfi_cmdset_0002: Fix do_erase_chip() to get chip as erasing mode

2019-09-15T21:51:07+00:00

The chip state is set to erasing by the function after getting chip.
So it should be to get chip as erasing mode at first.
But previously it was to get chip as writing mode then fix as erasing.

Signed-off-by: Tokunori Ikegami 
Cc: linux-mtd@lists.infradead.org
Signed-off-by: Richard Weinberger