summaryrefslogtreecommitdiffstats
path: root/ipc
diff options
context:
space:
mode:
authorJean-Philippe Brucker <jean-philippe@linaro.org>2020-04-17 16:23:26 +0200
committerVignesh Raghavendra <vigneshr@ti.com>2020-04-30 23:42:57 +0530
commitb359ed5184aebf9d987e54abc5dae7ac03ed29ae (patch)
tree1f759caf05875f0c88a400bb93e86c08d5e93aa4 /ipc
parentae83d0b416db002fe95601e7f97f64b59514d936 (diff)
downloadlinux-stable-b359ed5184aebf9d987e54abc5dae7ac03ed29ae.tar.gz
linux-stable-b359ed5184aebf9d987e54abc5dae7ac03ed29ae.tar.bz2
linux-stable-b359ed5184aebf9d987e54abc5dae7ac03ed29ae.zip
mtd: cfi_cmdset_0001: Support the absence of protection registers
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>
Diffstat (limited to 'ipc')
0 files changed, 0 insertions, 0 deletions