From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-in-11.arcor-online.net ([151.189.21.51]) by canuck.infradead.org with esmtps (Exim 4.63 #1 (Red Hat Linux)) id 1Huu6Y-0000uH-BW for linux-mtd@lists.infradead.org; Sun, 03 Jun 2007 13:43:04 -0400 In-Reply-To: <4662EAA9.70104@ru.mvista.com> References: <7fc919fce0761f861be3069a853d3169@bga.com> <4662EAA9.70104@ru.mvista.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Segher Boessenkool Subject: Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800 Date: Sun, 3 Jun 2007 19:40:57 +0200 To: Sergei Shtylyov Cc: linuxppc-dev@ozlabs.org, linux-mtd@lists.infradead.org, Milton Miller List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , >>> I think "direct-mapped" as compatible is a bit too broad or vague. > >>> The compatible is supposed to be useable to find and match a driver >>> without regard to the name of the node. Perhaps direct-mapped-rom? >>> (as opossed to a direct-mapped-ram, sram, or some width flash bank). > >> "actual-name-of-the-chip", "cfi-command-set-#", "cfi" seems >> like a good start. > > No, it doesn't -- since that info is almost *absolutely* useless > (the only exception is "cfi") in the context of Linux MTD subsys. > Please, try to understand that knowing that chip is CFI compatible > in itself doesn't yet guarantee that you can access the chip -- it all > depends on its mapping to the real physical address range, therefore > this group IMO cannot even constitute a valid "compatible" property. You obviously completely misunderstand the semantics of the "compatible" property. >> People here tried to create a generic "flash" device binding. >> It didn't work out (part of the problem is its scope was way >> too big; another problem is it was too Linux-mtd specific). > > And that's why its worked, and the abstaractly "correct" scheme > wouldn't have. Ha. Ha. Ha. Great joke :-) >> Now since the probing is done in platform-specific code here, >> you don't *need* an "official" binding -- just get your >> "compatible" prop right so you can correctly probe the device >> node, and then maybe add some node-specific properties if you >> need them. > > I wonder what are you trying to get us to do: directly call stuff > from drivers/mtd/ or what (that's especially starnge because we now > have an OF driver for simply mapped NOR flashes)? I am pointing out how to do a flash node in a platform- specific way, in platform-specific code, since there is no working "generic" way yet (and very likely there will never be). Segher