linux-stable.git/drivers/mtd/chips, branch v5.13.2 Linux kernel stable tree mtd: core: Constify buf in mtd_write_user_prot_reg() 2021-04-16T18:30:54+00:00 Tudor Ambarus tudor.ambarus@microchip.com 2021-04-03T06:09:31+00:00 1df1fc8c62f7527d953c7f3869930067bf5b3f29 The write buffer comes from user and should be const. Constify write buffer in mtd core and across all _write_user_prot_reg() users. cfi_cmdset_{0001, 0002} and onenand_base will pay the cost of an explicit cast to discard the const qualifier since the beginning, since they are using an otp_op_t function prototype that is used for both reads and writes. mtd_dataflash and SPI NOR will benefit of the const buffer because they are using different paths for writes and reads. Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20210403060931.7119-1-tudor.ambarus@microchip.com 
The write buffer comes from user and should be const.
Constify write buffer in mtd core and across all _write_user_prot_reg()
users. cfi_cmdset_{0001, 0002} and onenand_base will pay the cost of an
explicit cast to discard the const qualifier since the beginning, since
they are using an otp_op_t function prototype that is used for both reads
and writes. mtd_dataflash and SPI NOR will benefit of the const buffer
because they are using different paths for writes and reads.

Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210403060931.7119-1-tudor.ambarus@microchip.com
Merge tag 'cfi/for-5.13' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux into mtd/next 2021-04-15T19:12:54+00:00 Richard Weinberger richard@nod.at 2021-04-15T19:12:54+00:00 203ba0f64eefd0b751c1f34189f4fb1b21182b94 CFI changes Just a couple of fixes for v5.13-rc1 * Disable broken buffered writes for CFI chips within ID 0x2201 * Address a Coverity report for unused value 
CFI changes

Just a couple of fixes for v5.13-rc1
* Disable broken buffered writes for CFI chips within ID 0x2201
* Address a Coverity report for unused value
mtd: cfi_cmdset_0002: remove redundant assignment to variable timeo 2021-04-07T18:43:19+00:00 Colin Ian King colin.king@canonical.com 2021-03-25T17:45:14+00:00 f3907773d60229afa8e6c0a3ee5085715192a9cb The variable timeo is being initialized with a value that is never read and it is being updated later with a new value. The initialization is redundant and can be removed. Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Link: https://lore.kernel.org/r/20210325174514.486272-1-colin.king@canonical.com Addresses-Coverity: ("Unused value") 
The variable timeo is being initialized with a value that is never read
and it is being updated later with a new value.  The initialization is
redundant and can be removed.

Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Link: https://lore.kernel.org/r/20210325174514.486272-1-colin.king@canonical.com
Addresses-Coverity: ("Unused value")
mtd: cfi_cmdset_0002: Disable buffered writes for AMD chip 0x2201 2021-04-07T18:41:42+00:00 Mauri Sandberg sandberg@mailfence.com 2021-03-09T17:48:59+00:00 7e4404113686868858a34210c28ae122e967aa64 Buffer writes do not work with AMD chip 0x2201. The chip in question is a AMD/Spansion/Cypress Semiconductor S29GL256N and datasheet [1] talks about writing buffers being possible. While waiting for a neater solution resort to writing word-sized chunks only. Without the patch kernel logs will be flooded with entries like below: jffs2_scan_eraseblock(): End of filesystem marker found at 0x0 jffs2_build_filesystem(): unlocking the mtd device... done. jffs2_build_filesystem(): erasing all blocks after the end marker... MTD do_write_buffer_wait(): software timeout, address:0x01ec000a. jffs2: Write clean marker to block at 0x01920000 failed: -5 MTD do_write_buffer_wait(): software timeout, address:0x01e2000a. jffs2: Write clean marker to block at 0x01880000 failed: -5 MTD do_write_buffer_wait(): software timeout, address:0x01e0000a. jffs2: Write clean marker to block at 0x01860000 failed: -5 MTD do_write_buffer_wait(): software timeout, address:0x01dc000a. jffs2: Write clean marker to block at 0x01820000 failed: -5 MTD do_write_buffer_wait(): software timeout, address:0x01da000a. jffs2: Write clean marker to block at 0x01800000 failed: -5 ... Tested on a Buffalo wzr-hp-g300nh running kernel 5.10.16. [1] https://www.cypress.com/file/219941/download or https://datasheetspdf.com/pdf-file/565708/SPANSION/S29GL256N/1 Signed-off-by: Mauri Sandberg <sandberg@mailfence.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Link: https://lore.kernel.org/r/20210309174859.362060-1-sandberg@mailfence.com 
Buffer writes do not work with AMD chip 0x2201. The chip in question
is a AMD/Spansion/Cypress Semiconductor S29GL256N and datasheet [1]
talks about writing buffers being possible. While waiting for a neater
solution resort to writing word-sized chunks only.

Without the patch kernel logs will be flooded with entries like below:

jffs2_scan_eraseblock(): End of filesystem marker found at 0x0
jffs2_build_filesystem(): unlocking the mtd device...
done.
jffs2_build_filesystem(): erasing all blocks after the end marker...
MTD do_write_buffer_wait(): software timeout, address:0x01ec000a.
jffs2: Write clean marker to block at 0x01920000 failed: -5
MTD do_write_buffer_wait(): software timeout, address:0x01e2000a.
jffs2: Write clean marker to block at 0x01880000 failed: -5
MTD do_write_buffer_wait(): software timeout, address:0x01e0000a.
jffs2: Write clean marker to block at 0x01860000 failed: -5
MTD do_write_buffer_wait(): software timeout, address:0x01dc000a.
jffs2: Write clean marker to block at 0x01820000 failed: -5
MTD do_write_buffer_wait(): software timeout, address:0x01da000a.
jffs2: Write clean marker to block at 0x01800000 failed: -5
...

Tested on a Buffalo wzr-hp-g300nh running kernel 5.10.16.

[1] https://www.cypress.com/file/219941/download
or  https://datasheetspdf.com/pdf-file/565708/SPANSION/S29GL256N/1

Signed-off-by: Mauri Sandberg <sandberg@mailfence.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Link: https://lore.kernel.org/r/20210309174859.362060-1-sandberg@mailfence.com
mtd: cfi: Fix fall-through warnings for Clang 2021-03-11T11:17:39+00:00 Gustavo A. R. Silva gustavoars@kernel.org 2021-03-05T08:19:33+00:00 c6f51f1f5527946a83da930b43da2e37dc741dc2 In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple warnings by explicitly adding multiple break statements and a return instead of letting the code fall through to the next case. Link: https://github.com/KSPP/linux/issues/115 Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Acked-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20210305081933.GA137147@embeddedor 
In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding multiple break statements and a return
instead of letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Acked-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20210305081933.GA137147@embeddedor
mtd: Replace HTTP links with HTTPS ones 2020-08-02T20:17:19+00:00 Alexander A. Klimov grandmaster@al2klimov.de 2020-07-13T16:54:08+00:00 c13ac5552546c8971c0a4a3e947e25b0f8786aa9 Rationale: Reduces attack surface on kernel devs opening the links for MITM as HTTPS traffic is much harder to manipulate. Deterministic algorithm: For each file: If not .svg: For each line: If doesn't contain `\bxmlns\b`: For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`: If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`: If both the HTTP and HTTPS versions return 200 OK and serve the same content: Replace HTTP with HTTPS. Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Richard Weinberger <richard@nod.at> 
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.

Deterministic algorithm:
For each file:
  If not .svg:
    For each line:
      If doesn't contain `\bxmlns\b`:
        For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
	  If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
            If both the HTTP and HTTPS versions
            return 200 OK and serve the same content:
              Replace HTTP with HTTPS.

Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Richard Weinberger <richard@nod.at>
mtd: cfi_cmdset_0001: Support the absence of protection registers 2020-04-30T18:12:57+00:00 Jean-Philippe Brucker jean-philippe@linaro.org 2020-04-17T14:23:26+00:00 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 <jean-philippe@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Tested-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> 
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 <jean-philippe@linaro.org>
Tested-by: Sudeep Holla <sudeep.holla@arm.com>
Tested-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
mtd: Convert fallthrough comments into statements 2020-03-30T08:14:54+00:00 Miquel Raynal miquel.raynal@bootlin.com 2020-03-25T21:21:15+00:00 025a06c1104cd8995646b761d117816b5f28c873 Use Joe Perches cvt_fallthrough.pl script to convert /* fallthrough */ comments (and its derivatives) into a fallthrough; statement. This automatically drops useless ones. Do it MTD-wide. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Acked-by: Vignesh Raghavendra <vigneshr@ti.com> Acked-by: Tudor Ambarus <tudor.ambarus@microchip.com> Acked-by: Richard Weinberger <richard@nod.at> Link: https://lore.kernel.org/linux-mtd/20200325212115.14170-1-miquel.raynal@bootlin.com 
Use Joe Perches cvt_fallthrough.pl script to convert

	/* fallthrough */

comments (and its derivatives) into a

	fallthrough;

statement. This automatically drops useless ones.

Do it MTD-wide.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Vignesh Raghavendra <vigneshr@ti.com>
Acked-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Acked-by: Richard Weinberger <richard@nod.at>
Link: https://lore.kernel.org/linux-mtd/20200325212115.14170-1-miquel.raynal@bootlin.com
mtd: cfi_cmdset_0002: fix delayed error detection on HyperFlash 2019-11-09T09:13:53+00:00 Sergei Shtylyov sergei.shtylyov@cogentembedded.com 2019-10-31T20:39:39+00:00 c15995695ea971253ea9507f6732c8cd35384e01 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 <sergei.shtylyov@cogentembedded.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> 
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 <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
mtd: cfi_cmdset_0002: only check errors when ready in cfi_check_err_status() 2019-11-09T09:13:41+00:00 Sergei Shtylyov sergei.shtylyov@cogentembedded.com 2019-10-31T20:37:27+00:00 72914a8cff7e1d910c58e125e15a0da409e3135f 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 <sergei.shtylyov@cogentembedded.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> 
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 <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>