From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Fri, 11 Mar 2016 19:47:09 +0100 Subject: [U-Boot] [PATCH] sf: Correct data types in stm_is_locked_sr() In-Reply-To: References: <1457662816-10584-1-git-send-email-marex@denx.de> Message-ID: <20160311194709.4ce60e08@lilith> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hello Jagan, On Fri, 11 Mar 2016 12:09:37 +0530, Jagan Teki wrote: > On 11 March 2016 at 07:50, Marek Vasut 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 > > Cc: Simon Glass > > Cc: Jagan Teki > > --- > > 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.