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

[Jagan Teki]

On 12 March 2016 at 20:07, Jagan Teki <jagannadh.teki at gmail.com> wrote:
> Hi Marek,
>
> On 12 March 2016 at 00:29, Marek Vasut <marex at denx.de> wrote:
>> On 03/11/2016 07:44 PM, Jagan Teki wrote:
>>> On 12 March 2016 at 00:03, Marek Vasut <marex at denx.de> wrote:
>>>> On 03/11/2016 07:07 PM, Jagan Teki wrote:
>>>>> On 11 March 2016 at 23:32, Marek Vasut <marex at denx.de> wrote:
>>>>>> 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.
>>>>>
>>>>> 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.

Applied to u-boot-spi/master

thanks!
-- 
Jagan.