Hi Albert, On 12 March 2016 at 01:04, Albert ARIBAUD <albert.u.b...@aribaud.net> wrote: > Hello Jagan, > > On Sat, 12 Mar 2016 00:41:25 +0530, Jagan Teki > <jagannadh.t...@gmail.com> wrote: >> Hi Albert, >> >> On 12 March 2016 at 00:17, Albert ARIBAUD <albert.u.b...@aribaud.net> wrote: >> > Hello Jagan, >> > >> > On Fri, 11 Mar 2016 12:09:37 +0530, Jagan Teki >> > <jagannadh.t...@gmail.com> 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? >> > >> > Well, the U-Boot coding style [1] suggest that we follow the Linux >> > coding style [2] which itself suggests [chapter 5, item (d)] that when >> >> uNN types means uint32_t/uint64_t ? > > No, uNN means u8/u16/u32, but I'll admit that may not have been totally > unambiguous. > >> > uNN types are being used already in some code, then changes to this >> > code should keep on using uNN types. >> >> Sorry, I didn't understand here - if the code having these uNN types >> the changes to same uNN types? > > It was better explained in the URL I gave. :) > > Basically: the Linux (and therefore U-Boot) coding style guide says if > some code uses u8/u16/u32, then changes to this code should keep using > u8/u16/u32; and here, drivers/mtd/spi/spi_flash.c uses u8, u16 and u32 > so the wrongly-sized u32 should be changed into a u64, not into a > uint64_t.
Thanks for detailed explanation. -- Jagan. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
