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

[Jagan Teki]

Hi Albert,

On 12 March 2016 at 01:04, Albert ARIBAUD <albert.u.boot at aribaud.net> wrote:
> Hello Jagan,
>
> On Sat, 12 Mar 2016 00:41:25 +0530, Jagan Teki
> <jagannadh.teki at gmail.com> wrote:
>> Hi Albert,
>>
>> On 12 March 2016 at 00:17, Albert ARIBAUD <albert.u.boot at aribaud.net> wrote:
>> > Hello Jagan,
>> >
>> > On Fri, 11 Mar 2016 12:09:37 +0530, Jagan Teki
>> > <jagannadh.teki at gmail.com> 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?
>> >
>> > 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.