Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751907AbdCAIMP (ORCPT ); Wed, 1 Mar 2017 03:12:15 -0500 Received: from mail-it0-f67.google.com ([209.85.214.67]:32875 "EHLO mail-it0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751113AbdCAIMN (ORCPT ); Wed, 1 Mar 2017 03:12:13 -0500 MIME-Version: 1.0 In-Reply-To: <254c5202-64cd-ddae-2e76-8db6a4486b80@gmail.com> References: <20170222021558.710-1-ytht.net@gmail.com> <254c5202-64cd-ddae-2e76-8db6a4486b80@gmail.com> From: lepton Date: Tue, 28 Feb 2017 20:14:23 -0800 Message-ID: Subject: Re: [PATCH v2] mtd: Fix mtdblock for >4GB MTD devices To: Marek Vasut Cc: David Woodhouse , Brian Norris , boris.brezillon@free-electrons.com, richard@nod.at, cyrille.pitchen@atmel.com, linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1484 Lines: 42 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 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 >> --- >> 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