Hi Marek, On 12 March 2016 at 00:29, Marek Vasut <ma...@denx.de> wrote: > On 03/11/2016 07:44 PM, Jagan Teki wrote: >> On 12 March 2016 at 00:03, Marek Vasut <ma...@denx.de> wrote: >>> On 03/11/2016 07:07 PM, Jagan Teki wrote: >>>> On 11 March 2016 at 23:32, Marek Vasut <ma...@denx.de> wrote: >>>>> 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. >>>> >>>> No, I'm saying Linux is still using uint64_t and why can't we use the same? >>>> >>> Very quick google search gets you for example here: >>> >>> http://article.gmane.org/gmane.linux.kernel/259313 >>> >>> Quote: >>> " >>> In short: having the kernel use the same names as user space is ACTIVELY >>> BAD, exactly because those names have standards-defined visibility, >>> which means that the kernel _cannot_ use them in all places anyway. So >>> don't even _try_. >>> " >> >> Yes, clear I knew this too - but this protect code is a copy from >> Linux it better to be the same. ie only my concern. > > Thus, linux should be fixed.
I think Linux look OK with using uint64_t as offset and remaining were not using not uNN and issue with u-boot only as you mentioned on the log message. thanks! -- Jagan. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
