From: Mitch Bradley <wmb@firmworks.com>
To: Sean MacLennan <smaclennan@pikatech.com>
Cc: linuxppc-dev@ozlabs.org, devicetree-discuss@ozlabs.org,
avorontsov@ru.mvista.com, linux-mtd@lists.infradead.org
Subject: Re: [PATCH] ndfc driver
Date: Tue, 09 Dec 2008 22:28:09 -1000 [thread overview]
Message-ID: <493F7D99.5070400@firmworks.com> (raw)
In-Reply-To: <20081209230135.35e1b9d1@lappy.seanm.ca>
>
> n Mon, 08 Dec 2008 21:57:12 -1000
> "Mitch Bradley" <wmb@firmworks.com> wrote:
>
>
>> > One address/size cell isn't enough for the next generation of NAND
>> > FLASH chips.
>> >
>>
>
> I am no dts expert, but I thought I could put:
>
> nand {
> #address-cells = <1>;
> #size-cells = <1>;
>
> in my dts and you could put:
>
> nand {
> #address-cells = <2>;
> #size-cells = <2>;
>
> and, assuming we specified the reg entry right, everything would just
> work. Is that assumption wrong?
>
> And if the assumption is true, should I make a note in the doc that you
> can make the address and size bigger?
>
> Cheers,
> Sean
>
>
In principle that is correct, but the device tree partition parser in
the Linux kernel assumes one address cell and one size cell, or at least
it did the last time I looked.
I wrote a patch to fix that and circulated it on the linuxppc list, but
since lost interest. OLPC (my main focus) is probably going to switch to
managed NAND (SSD, LBA-NAND, eMMC, or some such thing with a built-in
Flash Translation Layer) at some point. Raw NAND is starting to go by
the wayside.
next prev parent reply other threads:[~2008-12-10 8:28 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-04 3:28 [PATCH] ndfc driver Sean MacLennan
2008-12-04 14:01 ` Josh Boyer
2008-12-04 17:17 ` Sean MacLennan
2008-12-09 0:34 ` Sean MacLennan
2008-12-09 2:11 ` Anton Vorontsov
2008-12-09 2:45 ` Sean MacLennan
2008-12-09 3:32 ` Josh Boyer
2008-12-09 4:54 ` Sean MacLennan
2008-12-09 7:57 ` Mitch Bradley
2008-12-10 4:01 ` Sean MacLennan
2008-12-10 8:28 ` Mitch Bradley [this message]
2008-12-09 6:10 ` Stefan Roese
2008-12-09 11:24 ` Josh Boyer
2008-12-10 23:16 ` Sean MacLennan
2008-12-17 4:14 ` Sean MacLennan
2008-12-17 11:34 ` Josh Boyer
2008-12-17 13:26 ` Josh Boyer
2008-12-09 0:51 ` Sean MacLennan
-- strict thread matches above, loose matches on Subject: below --
2008-12-23 12:26 Kostas Nakos
2008-12-23 22:00 ` Sean MacLennan
2008-12-24 6:58 ` knakos
2008-12-27 1:56 ` Sean MacLennan
2008-12-29 10:58 ` Kostas Nakos
2009-01-06 1:23 ` Sean MacLennan
2009-01-07 9:51 ` Kostas Nakos
2009-01-07 17:21 ` Sean MacLennan
2009-01-08 15:37 ` Kostas Nakos
2008-10-30 6:08 Sean MacLennan
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=493F7D99.5070400@firmworks.com \
--to=wmb@firmworks.com \
--cc=avorontsov@ru.mvista.com \
--cc=devicetree-discuss@ozlabs.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=smaclennan@pikatech.com \
/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