summaryrefslogtreecommitdiff
path: root/configs/mx7dsabresd_defconfig
diff options
context:
space:
mode:
authorMarek Vasut <marex@denx.de>2016-03-11 03:20:16 +0100
committerJagan Teki <jteki@openedev.com>2016-03-12 19:55:42 +0530
commitea9619aed6908e83b0679bd9c9aa4ae97714ef97 (patch)
tree2de8be1ebdc1346e144f3a1b052e24c8bed05e16 /configs/mx7dsabresd_defconfig
parente6601df8acf19a369b4c12ef16296f719dd237ca (diff)
downloadu-boot-imx-ea9619aed6908e83b0679bd9c9aa4ae97714ef97.zip
u-boot-imx-ea9619aed6908e83b0679bd9c9aa4ae97714ef97.tar.gz
u-boot-imx-ea9619aed6908e83b0679bd9c9aa4ae97714ef97.tar.bz2
sf: Correct data types in stm_is_locked_sr()
The stm_is_locked_sr() function is picked from Linux kernel. For reason unknown, the 64bit data types used by the function and present in Linux were replaced with 32bit unsigned ones, which causes trouble. The testcase performed was done using ST M25P80 chip. The command used was: => sf protect unlock 0 0x10000 The call chain starts in stm_unlock(), which calls stm_is_locked_sr() with negative ofs argument. This works fine in Linux, where the "ofs" is loff_t, which is signed long long, while this fails in U-Boot, where "ofs" is u32 (unsigned int). Because of this signedness problem, the expression past the return statement to be incorrectly evaluated to 1, which in turn propagates back to stm_unlock() and results in -EINVAL. The correction is very simple, just use the correctly sized data types with correct signedness in the function to make it work as intended. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Simon Glass <sjg@chromium.org> Reviewed-by: Jagan Teki <jteki@openedev.com>
Diffstat (limited to 'configs/mx7dsabresd_defconfig')
0 files changed, 0 insertions, 0 deletions