From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from imap.sh.mvista.com (unknown [63.81.120.155]) by ozlabs.org (Postfix) with ESMTP id 3145CDDEC4 for ; Tue, 5 Jun 2007 00:48:23 +1000 (EST) Message-ID: <46642691.7070400@ru.mvista.com> Date: Mon, 04 Jun 2007 18:49:53 +0400 From: Sergei Shtylyov MIME-Version: 1.0 To: Segher Boessenkool Subject: Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800 References: <7fc919fce0761f861be3069a853d3169@bga.com> <1180769992.14025.1.camel@localhost.localdomain> <4662E7EA.70506@ru.mvista.com> <46630256.8050909@ru.mvista.com> <1180904670.31677.18.camel@localhost.localdomain> <466406BB.3070607@ru.mvista.com> <879d8eb0b405619a9e457d137c27baa2@kernel.crashing.org> In-Reply-To: <879d8eb0b405619a9e457d137c27baa2@kernel.crashing.org> Content-Type: text/plain; charset=us-ascii; format=flowed 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: , Segher Boessenkool wrote: >>> So you are saying that because the current linux MTD stuff can only >>> probe (which doesn't always work), we should not put the proper chip >>> interface type in the device-tree ? >> No. But if/when we put it, it'll only be able to influence >> interface probing, but not "force" the interface. > Of course it can; that just means you have to fix MTD I wouldn't call this a fix, more like an additional feature. Probing has worked well enough. > and/or the way your platform calls MTD. The platform code is not supposed to call MTD *at all*. The only expeption so far are physmap_configure() and physmap_set_partitions() which are both considered obsolete (in favor of platform device). Maybe linux-mtd people will correct me though... >> The money was not the only factor, you know, I was under the >> pressure of schedules, and had a lot more things to do. > The bigger Linux community does not (and should not) > care about your corporate schedules. Your patches > won't be merged upstream until they are deemed to be > of acceptable quality. If that doesn't fit your > employer's schedule, well tough luck, they can maintain > their own kernel fork I'm sure? But the driver have been nevertheless merged. Moreover, the it was one of the MTD maintainers who expressed desire for partition info to be kept with device node in the first place. > Segher WBR, Sergei