On 03/11/2016 06:34 PM, Jagan Teki wrote: > On 11 March 2016 at 17:59, Marek Vasut <ma...@denx.de> wrote: >> On 03/11/2016 07:39 AM, Jagan Teki wrote: >>> On 11 March 2016 at 07:50, Marek Vasut <ma...@denx.de> wrote: >>>> 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 <ma...@denx.de> >>>> Cc: Simon Glass <s...@chromium.org> >>>> Cc: Jagan Teki <jt...@openedev.com> >>>> --- >>>> drivers/mtd/spi/spi_flash.c | 6 +++--- >>>> 1 file changed, 3 insertions(+), 3 deletions(-) >>>> >>>> diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c >>>> index 2ae2e3c..44d9e9b 100644 >>>> --- a/drivers/mtd/spi/spi_flash.c >>>> +++ b/drivers/mtd/spi/spi_flash.c >>>> @@ -665,7 +665,7 @@ int sst_write_bp(struct spi_flash *flash, u32 offset, >>>> size_t len, >>>> >>>> #if defined(CONFIG_SPI_FLASH_STMICRO) || defined(CONFIG_SPI_FLASH_SST) >>>> static void stm_get_locked_range(struct spi_flash *flash, u8 sr, loff_t >>>> *ofs, >>>> - u32 *len) >>>> + u64 *len) >>> >>> What about uint64_t? >> >> This is now same as Linux too. > > I couldn't find it on l2-mtd and ML as well, it is still uint64_t > You are not supposed to use stdint.h types in either kernel or u-boot if this is what you are concerned about. Thus, u64.
-- Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot