linux-stable.git/drivers/mtd/chips, branch v5.8 Linux kernel stable tree 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>
mtd: cfi_cmdset_0002: don't free cfi->cfiq in error path of cfi_amdstd_setup() 2019-11-09T09:12:47+00:00 Hou Tao houtao1@huawei.com 2019-10-08T02:36:37+00:00 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 <houtao1@huawei.com> Reviewed-by: Richard Weinberger <richard@nod.at> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> 
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 <houtao1@huawei.com>
Reviewed-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
mtd: cfi_cmdset_*: kill useless 'ret' variable initializers 2019-11-09T09:12:09+00:00 Sergei Shtylyov sergei.shtylyov@cogentembedded.com 2019-10-03T20:27:39+00:00 ea4f51356fd986124beeab8e21b048dfe06d67e7 The 'ret' local variables are typically initialized to 0 but this value is often unused, thus we can kill those initializers. Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> 
The 'ret' local variables are typically initialized to 0 but this value is
often unused, thus we can kill those initializers.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
mtd: cfi_util: use DIV_ROUND_UP() in cfi_udelay() 2019-11-09T09:10:48+00:00 Sergei Shtylyov sergei.shtylyov@cogentembedded.com 2019-09-27T20:22:32+00:00 d532c28b8c151cdb5b50280801c748ac4d93d563 Use DIV_ROUND_UP() in cfi_udelay() instead of open-coding it... Doing this also helpfully gets rid of two complaints from 'scripts/checkpatch.pl --strict': CHECK: spaces preferred around that '+' (ctx:VxV) #29: FILE: drivers/mtd/chips/cfi_util.c:29: + msleep((us+999)/1000); ^ CHECK: spaces preferred around that '/' (ctx:VxV) #29: FILE: drivers/mtd/chips/cfi_util.c:29: + msleep((us+999)/1000); ^ Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> 
Use DIV_ROUND_UP() in cfi_udelay() instead of open-coding it...

Doing this also helpfully gets rid of two complaints from
'scripts/checkpatch.pl --strict':

CHECK: spaces preferred around that '+' (ctx:VxV)
#29: FILE: drivers/mtd/chips/cfi_util.c:29:
+		msleep((us+999)/1000);
 		          ^

CHECK: spaces preferred around that '/' (ctx:VxV)
#29: FILE: drivers/mtd/chips/cfi_util.c:29:
+		msleep((us+999)/1000);
			       ^

Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
mtd: cfi_cmdset_0002: Fix do_erase_chip() to get chip as erasing mode 2019-09-15T21:51:07+00:00 Tokunori Ikegami ikegami.t@gmail.com 2019-08-21T16:46:51+00:00 8a9485ff09088c67b70e4e38b1679c1b9bedb808 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 <ikegami.t@gmail.com> Cc: linux-mtd@lists.infradead.org Signed-off-by: Richard Weinberger <richard@nod.at> 
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 <ikegami.t@gmail.com>
Cc: linux-mtd@lists.infradead.org
Signed-off-by: Richard Weinberger <richard@nod.at>
mtd: cfi_cmdset_0002: Disable write buffer functions if FORCE_WORD_WRITE is 1 2019-08-27T12:25:53+00:00 Tokunori Ikegami ikegami.t@gmail.com 2019-08-05T19:03:26+00:00 557c759036fc3976a5358cef23e65a263853b93f Some write buffer functions are not used when FORCE_WORD_WRITE is set to 1. So the compile warning messages are output if FORCE_WORD_WRITE is 1. To resolve this disable the write buffer functions if FORCE_WORD_WRITE is 1. Cc: Fabio Bettoni <fbettoni@gmail.com> Co: Hauke Mehrtens <hauke@hauke-m.de> Cc: Chris Packham <chris.packham@alliedtelesis.co.nz> Cc: Joakim Tjernlund <Joakim.Tjernlund@infinera.com> Cc: linux-mtd@lists.infradead.org Signed-off-by: Tokunori Ikegami <ikegami.t@gmail.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> 
Some write buffer functions are not used when FORCE_WORD_WRITE is set to 1.
So the compile warning messages are output if FORCE_WORD_WRITE is 1. To
resolve this disable the write buffer functions if FORCE_WORD_WRITE is 1.

Cc: Fabio Bettoni <fbettoni@gmail.com>
Co: Hauke Mehrtens <hauke@hauke-m.de>
Cc: Chris Packham <chris.packham@alliedtelesis.co.nz>
Cc: Joakim Tjernlund <Joakim.Tjernlund@infinera.com>
Cc: linux-mtd@lists.infradead.org
Signed-off-by: Tokunori Ikegami <ikegami.t@gmail.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
mtd: cfi_cmdset_0002: Split do_write_oneword() to reduce exit paths 2019-08-27T12:25:53+00:00 Tokunori Ikegami ikegami.t@gmail.com 2019-08-05T19:03:25+00:00 0bcf880b062ef88d144ffe90918c56dd11e3d935 The do_write_oneword_done() is called twice at the exit paths. By splitting the retry functionality it can be reduced to call once. Cc: Fabio Bettoni <fbettoni@gmail.com> Co: Hauke Mehrtens <hauke@hauke-m.de> Cc: Chris Packham <chris.packham@alliedtelesis.co.nz> Cc: Joakim Tjernlund <Joakim.Tjernlund@infinera.com> Cc: linux-mtd@lists.infradead.org Signed-off-by: Tokunori Ikegami <ikegami.t@gmail.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> 
The do_write_oneword_done() is called twice at the exit paths.
By splitting the retry functionality it can be reduced to call once.

Cc: Fabio Bettoni <fbettoni@gmail.com>
Co: Hauke Mehrtens <hauke@hauke-m.de>
Cc: Chris Packham <chris.packham@alliedtelesis.co.nz>
Cc: Joakim Tjernlund <Joakim.Tjernlund@infinera.com>
Cc: linux-mtd@lists.infradead.org
Signed-off-by: Tokunori Ikegami <ikegami.t@gmail.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>