From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Fri, 11 Mar 2016 19:33:49 +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> <56E2BA29.4040208@denx.de> <56E30836.4010209@denx.de> Message-ID: <56E30F8D.8020908@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 03/11/2016 07:07 PM, Jagan Teki wrote: > On 11 March 2016 at 23:32, Marek Vasut wrote: >> On 03/11/2016 06:34 PM, Jagan Teki wrote: >>> On 11 March 2016 at 17:59, Marek Vasut wrote: >>>> On 03/11/2016 07:39 AM, 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? >>>> >>>> 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_. " There are multiple discussions about the same thing in U-Boot ML as well, I am sure you can find them yourself. I would be much more interested in getting this fix into current release instead of discussing some stupid type. -- Best regards, Marek Vasut