[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9c9fda240903041547x540899f9hd94cbf49baac660b@mail.gmail.com>
Date: Thu, 5 Mar 2009 08:47:03 +0900
From: Kyungmin Park <kmpark@...radead.org>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Adrian Hunter <adrian.hunter@...ia.com>,
Rohit Hagargundgi <h.rohit@...sung.com>,
"linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/3] [MTD] Flex-OneNAND support
Hi,
On Thu, Mar 5, 2009 at 1:50 AM, Andrew Morton <akpm@...ux-foundation.org> wrote:
> On Wed, 04 Mar 2009 13:41:59 +0200 Adrian Hunter <adrian.hunter@...ia.com> wrote:
>
>> Andrew Morton wrote:
>> >> ...
>> >>
>> >> +static loff_t flexonenand_get_addr(struct onenand_chip *this, int block)
>> >> +{
>> >> + loff_t ofs = 0;
>> >> + int die = 0, boundary;
>> >> +
>> >> + if (ONENAND_IS_DDP(this) && block >= this->density_mask) {
>> >> + block -= this->density_mask;
>> >> + die = 1;
>> >> + ofs = this->diesize[0];
>> >> + }
>> >> +
>> >> + boundary = this->boundary[die];
>> >> + ofs += block << (this->erase_shift - 1);
>> >> + if (block > (boundary + 1))
>> >> + ofs += (block - boundary - 1) << (this->erase_shift - 1);
>> >
>> > Both `block' and `boundary' have 32-bit types. Are you sure that the
>> > left-shift cannot overflow?
>>
>> Only very recently has MTD supported sizes greater than 32 bits internally
>> for any type of flash. The external APIs (ioctls) are still 32-bit based.
>>
>> For this driver, supporting sizes over 32-bits is a separate issue - and
>> may never be needed.
>
> So it doesn't support files >4G? What's the max device size (now and
> projected)?
Umm it's not simple question. basically Flex-OneNAND based on NAND
flash technology. It means if NAND flash technology are advanced, it
can also get more size. Currently max Flex-OneNAND has 16 Gib (2GiB)
So it will be exceed the 4GiB soon. but I'm not sure when this device is opened.
I think we know the issues currently and then if the device is opened,
handle this one if required.
How do you think?
Thank you,
Kyungmin Park
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists