[PATCH v2] mtd: Fix mtdblock for >4GB MTD devices

[lepton]

If checking some calling side,  the len is from cache_size of struct
mtdblk_dev, it's defined as unsigned int now. So it's not 64bit yet.

BTW, seems it's just block size (512) at some other calling side.

(Sorry for previous same content email, just found out it's html
format and rejected by mail list)

On Mon, Feb 27, 2017 at 1:31 AM, Marek Vasut <marek.vasut at gmail.com> wrote:
> On 02/22/2017 03:15 AM, Lepton Wu wrote:
>> Change to use loff_t instead of unsigned long in some functions
>> to make sure mtdblock can handle offset bigger than 4G in 32 bits mode.
>>
>> Signed-off-by: Lepton Wu <ytht.net at gmail.com>
>> ---
>>  Changes in v2:
>>   - Make the commit message more clearer and fix some format issues.
>>
>>  drivers/mtd/mtdblock.c    | 35 ++++++++++++++++++-----------------
>>  drivers/mtd/mtdblock_ro.c |  4 ++--
>>  2 files changed, 20 insertions(+), 19 deletions(-)
>>
>> diff --git a/drivers/mtd/mtdblock.c b/drivers/mtd/mtdblock.c
>> index bb4c14f83c75..373c0edca803 100644
>> --- a/drivers/mtd/mtdblock.c
>> +++ b/drivers/mtd/mtdblock.c
>> @@ -61,8 +61,8 @@ static void erase_callback(struct erase_info *done)
>>       wake_up(wait_q);
>>  }
>>
>> -static int erase_write (struct mtd_info *mtd, unsigned long pos,
>> -                     int len, const char *buf)
>> +static int erase_write(struct mtd_info *mtd, loff_t pos, int len,
>> +                    const char *buf)
>
> Can the length be 64bit too now ?
>
> [...]
>
> --
> Best regards,
> Marek Vasut