From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <segher@kernel.crashing.org>
Received: from mail-in-05.arcor-online.net (mail-in-05.arcor-online.net
	[151.189.21.45])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "mx.arcor.de",
	Issuer "Thawte Premium Server CA" (verified OK))
	by ozlabs.org (Postfix) with ESMTP id 6C843DDE17
	for <linuxppc-dev@ozlabs.org>; Tue, 12 Jun 2007 20:53:48 +1000 (EST)
In-Reply-To: <20070612044459.GD4198@localhost.localdomain>
References: <bd6ef296692e8cfb81118f2dc85189a5@kernel.crashing.org>
	<4662EAA9.70104@ru.mvista.com>
	<e4197fd2753f2b4d548d5dde9e3fd1d3@kernel.crashing.org>
	<466308F4.8050004@ru.mvista.com>
	<8ac5664208e0f59329b62ac2138bbc8c@kernel.crashing.org>
	<466312C2.4090200@ru.mvista.com>
	<548a7e11ffb577f6395b8f5a9c2fba2d@kernel.crashing.org>
	<466323EF.5040807@ru.mvista.com>
	<1181228442.2785.60.camel@pmac.infradead.org>
	<18fbfbaf113ab76b602d279848d9b405@kernel.crashing.org>
	<20070612044459.GD4198@localhost.localdomain>
Mime-Version: 1.0 (Apple Message framework v623)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <9e1a55ac71a2ecf5155d2fddf547025e@kernel.crashing.org>
From: Segher Boessenkool <segher@kernel.crashing.org>
Subject: Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
Date: Tue, 12 Jun 2007 12:53:36 +0200
To: David Gibson <david@gibson.dropbear.id.au>
Cc: linuxppc-dev@ozlabs.org, linux-mtd@lists.infradead.org,
	David Woodhouse <dwmw2@infradead.org>, Milton Miller <miltonm@bga.com>
List-Id: Linux on PowerPC Developers Mail List <linuxppc-dev.ozlabs.org>
List-Unsubscribe: <https://ozlabs.org/mailman/listinfo/linuxppc-dev>,
	<mailto:linuxppc-dev-request@ozlabs.org?subject=unsubscribe>
List-Archive: <http://ozlabs.org/pipermail/linuxppc-dev>
List-Post: <mailto:linuxppc-dev@ozlabs.org>
List-Help: <mailto:linuxppc-dev-request@ozlabs.org?subject=help>
List-Subscribe: <https://ozlabs.org/mailman/listinfo/linuxppc-dev>,
	<mailto:linuxppc-dev-request@ozlabs.org?subject=subscribe>

>> So I think the best thing to have would be
>>
>> 	compatible      "cfi-flash"
>> 	bank-width      like you said
>> 	device-width    width of a single flash device
>> 	reg             complete address range of this thing
>>
>> and then the Linux OF CFI flash code / MTD code just keeps
>> on probing devices from that address range until it has it
>> filled.
>>
>> Sounds good / comments / anything I missed?
>
> Looks pretty sensible to me.

Great!

> Presumably the compatible property could
> also have more specific entries for the particular chip type.

Yes, of course.

> Of course, Ebony has flash which is JEDEC rather than CFI probed, so I
> have an interest in a binding for that, too.

For JEDEC flash, you probably want extra properties
for manufacturing ID and chip ID.  Also, you need
to describe the block sizes in some way (on CFI, this
can be probed; on JEDEC, not).  Anything else?


Segher