From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] sf: Correct data types in stm_is_locked_sr()
Date: Fri, 11 Mar 2016 13:29:29 +0100 [thread overview]
Message-ID: <56E2BA29.4040208@denx.de> (raw)
In-Reply-To: <CAD6G_RRuUZ3bzhSAykRd7JaHHOxYwrJXts4pDG88Lf9LC4Ew9g@mail.gmail.com>
On 03/11/2016 07:39 AM, Jagan Teki 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?
This is now same as Linux too.
--
Best regards,
Marek Vasut
next prev parent reply other threads:[~2016-03-11 12:29 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-11 2:20 [U-Boot] [PATCH] sf: Correct data types in stm_is_locked_sr() Marek Vasut
2016-03-11 6:39 ` Jagan Teki
2016-03-11 12:29 ` Marek Vasut [this message]
2016-03-11 17:34 ` Jagan Teki
2016-03-11 18:02 ` Marek Vasut
2016-03-11 18:07 ` Jagan Teki
2016-03-11 18:33 ` Marek Vasut
2016-03-11 18:44 ` Jagan Teki
2016-03-11 18:59 ` Marek Vasut
2016-03-12 14:37 ` Jagan Teki
2016-03-12 14:39 ` Jagan Teki
2016-03-11 18:47 ` Albert ARIBAUD
2016-03-11 19:11 ` Jagan Teki
2016-03-11 19:34 ` Albert ARIBAUD
2016-03-12 14:34 ` Jagan Teki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56E2BA29.4040208@denx.de \
--to=marex@denx.de \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox