From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-in-07.arcor-online.net (mail-in-07.arcor-online.net [151.189.21.47]) (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 11A24DDE48 for ; Mon, 4 Jun 2007 05:48:27 +1000 (EST) In-Reply-To: <46630F8F.6080708@ru.mvista.com> References: <7fc919fce0761f861be3069a853d3169@bga.com> <4662FA67.3020107@ru.mvista.com> <4663060C.2020906@ru.mvista.com> <46630F8F.6080708@ru.mvista.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: From: Segher Boessenkool Subject: Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800 Date: Sun, 3 Jun 2007 21:48:15 +0200 To: Sergei Shtylyov Cc: ppcdev , linux-mtd@lists.infradead.org, Milton Miller List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , >>> No! It doesn't have anything to do with "ranges" of parent (don't >>> even know why it would). :-O > >> So learn about it please? "ranges" means exactly that: >> child nodes' address space is direct mapped. > > Well, now we certainly need a parent node -- which would be static > bus controller? I have no clue what a "static bus controller" is. Your flash node obviously needs _some_ parent node though -- this is a tree after all. > But those have multiple chips selects, so we should know which range > to use. Ugh... That is described in the "reg" property of the flash node, just like for any other node. >> Because that is a) not what you are supposed to do according >> to the standard (so it might very well not work with a >> "third-party" device tree that equally conforms to the standard); >> b) "device_type" describes some other information (namely, the >> OF programming model for the device node) that is completely >> unrelated to the process of driver matching; and c) it is wholly >> redundant to the information in "compatible" *ANYWAY*. > > Hm, well. Than changing "compatible" prop would make sense. Yes. >>> And why you haven't complained at MPC5200 IDE driver > >> Since no one paid me to review the code? Please don't try > > Sigh, nobody pays me for that too. :-) Yeah it's a shame isn't it? >>> which does the same (well, maybe you have :-) or at PowerMac IDE >>> driver which matches wither by "name" or "device_type"? Well, quite >>> a lot of drivers are doing this... > >> See before why that may be. Short answer is "history". > > Well, at least that's cleared. Okido, good to hear. >>> Anyway, reasonable suggestions on how to make MTD nodes more >>> viable are always welcome. I just haven't seen reasonable enough >>> yet. ;-) > >> I suggest you read, and try to understand, some of the base >> device tree specifications first. > > Read them some months ago -- do you think I would have plunged into > that not reading anything first? :-/ It seems we really need more howto-style docs... Segher