]> git.baikalelectronics.ru Git - kernel.git/commit
nvmem: eeprom: at25: fix FRAM byte_len
authorRalph Siemsen <ralph.siemsen@linaro.org>
Mon, 8 Nov 2021 18:16:27 +0000 (13:16 -0500)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Tue, 14 Dec 2021 09:57:22 +0000 (10:57 +0100)
commit725892b96a79acec775c5ebd598c9e938dec6950
treee2820ae19ba00d3693572cec0f1c511565a437fb
parentcae8b40fb5a908e4c1258bc9bcc373c98144ac6b
nvmem: eeprom: at25: fix FRAM byte_len

commit bad4f410c4ac5f52db21ac5bc8dc16e666f85568 upstream.

Commit 5c957fce922d ("nvmem: prepare basics for FRAM support") added
support for FRAM devices such as the Cypress FM25V. During testing, it
was found that the FRAM detects properly, however reads and writes fail.
Upon further investigation, two problem were found in at25_probe() routine.

1) In the case of an FRAM device without platform data, eg.
       fram == true && spi->dev.platform_data == NULL
the stack local variable "struct spi_eeprom chip" is not initialized
fully, prior to being copied into at25->chip. The chip.flags field in
particular can cause problems.

2) The byte_len of FRAM is computed from its ID register, and is stored
into the stack local "struct spi_eeprom chip" structure. This happens
after the same structure has been copied into at25->chip. As a result,
at25->chip.byte_len does not contain the correct length of the device.
In turn this can cause checks at beginning of at25_ee_read() to fail
(or equally, it could allow reads beyond the end of the device length).

Fix both of these issues by eliminating the on-stack struct spi_eeprom.
Instead use the one inside at25_data structure, which starts of zeroed.

Fixes: 5c957fce922d ("nvmem: prepare basics for FRAM support")
Cc: stable <stable@vger.kernel.org>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Ralph Siemsen <ralph.siemsen@linaro.org>
Link: https://lore.kernel.org/r/20211108181627.645638-1-ralph.siemsen@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drivers/misc/eeprom/at25.c