[U-Boot] [PATCH] sf: Correct data types in stm_is_locked_sr()

[Marek Vasut]

On 03/11/2016 06:34 PM, Jagan Teki wrote:
> On 11 March 2016 at 17:59, Marek Vasut <marex at denx.de> wrote:
>> On 03/11/2016 07:39 AM, Jagan Teki wrote:
>>> On 11 March 2016 at 07:50, Marek Vasut <marex at 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 <marex at denx.de>
>>>> Cc: Simon Glass <sjg at chromium.org>
>>>> Cc: Jagan Teki <jteki at 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