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

[Albert ARIBAUD <albert.u.boot@aribaud.net>]

Hello Jagan,

On Fri, 11 Mar 2016 12:09:37 +0530, Jagan Teki
<jagannadh.teki@gmail.com> wrote:
> On 11 March 2016 at 07:50, Marek Vasut <marex@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@denx.de>
> > Cc: Simon Glass <sjg@chromium.org>
> > Cc: Jagan Teki <jteki@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 are being used already in some code, then changes to this
code should keep on using uNN types.

[1] http://www.denx.de/wiki/U-Boot/CodingStyle
[2]
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/CodingStyle

> Jagan.

Amicalement,
-- 
Albert.