diff options
author | Jean-Philippe Brucker <jean-philippe@linaro.org> | 2020-04-17 16:23:26 +0200 |
---|---|---|
committer | Vignesh Raghavendra <vigneshr@ti.com> | 2020-04-30 23:42:57 +0530 |
commit | b359ed5184aebf9d987e54abc5dae7ac03ed29ae (patch) | |
tree | 1f759caf05875f0c88a400bb93e86c08d5e93aa4 /ipc | |
parent | ae83d0b416db002fe95601e7f97f64b59514d936 (diff) | |
download | linux-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