Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756407AbbHZPbx (ORCPT ); Wed, 26 Aug 2015 11:31:53 -0400 Received: from blu004-omc1s35.hotmail.com ([65.55.116.46]:59622 "EHLO BLU004-OMC1S35.hotmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751879AbbHZPbv (ORCPT ); Wed, 26 Aug 2015 11:31:51 -0400 X-Greylist: delayed 311 seconds by postgrey-1.27 at vger.kernel.org; Wed, 26 Aug 2015 11:31:51 EDT X-TMN: [u75EIe8zjkGZrjOoXEk15Snuoe9P95lZ] X-Originating-Email: [bpringle@sympatico.ca] Message-ID: From: Bill Pringlemeir To: Brian Norris CC: Stefan Agner , dwmw2@infradead.org, sebastian@breakpoint.cc, robh+dt@kernel.org, pawel.moll@arm.com, mark.rutland@arm.com, ijc+devicetree@hellion.org.uk, galak@codeaurora.org, shawn.guo@linaro.org, kernel@pengutronix.de, boris.brezillon@free-electrons.com, marb@ixxat.de, aaron@tastycactus.com, bpringlemeir@gmail.com, linux-mtd@lists.infradead.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, albert.aribaud@3adev.fr, klimov.linux@gmail.com, Bill Pringlemeir Subject: Re: [PATCH v10 3/5] mtd: nand: vf610_nfc: add device tree bindings Organization: Twits of the world References: <1438594050-4595-1-git-send-email-stefan@agner.ch> <1438594050-4595-4-git-send-email-stefan@agner.ch> <20150825202546.GL81844@google.com> Date: Wed, 26 Aug 2015 11:26:36 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-OriginalArrivalTime: 26 Aug 2015 15:26:38.0147 (UTC) FILETIME=[99B43930:01D0E013] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3054 Lines: 69 On 25 Aug 2015, computersforpeace@gmail.com wrote: > Sorry, I realized a potential issue here. > On Mon, Aug 03, 2015 at 11:27:28AM +0200, Stefan Agner wrote: >> Signed-off-by: Bill Pringlemeir >> Acked-by: Shawn Guo >> Reviewed-by: Brian Norris >> Signed-off-by: Stefan Agner >> --- >> .../devicetree/bindings/mtd/vf610-nfc.txt | 45 ++++++++++++++++++++++ >> 1 file changed, 45 insertions(+) create mode 100644 >> Documentation/devicetree/bindings/mtd/vf610-nfc.txt >> diff --git a/Documentation/devicetree/bindings/mtd/vf610-nfc.txt >> b/Documentation/devicetree/bindings/mtd/vf610-nfc.txt >> new file mode 100644 >> index 0000000..cae5f25 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/mtd/vf610-nfc.txt >>>> -0,0 +1,45 @@ >> +- nand-bus-width: see nand.txt >> +- nand-ecc-mode: see nand.txt >> +- nand-on-flash-bbt: see nand.txt > Stumbling across the "multi-CS" questions on the driver reminds me: it > typically makes sense to define new NAND bindings using separate NAND > *controller* and *flash* device nodes. The above 3 properties, at > least, would apply on a per-flash basis, not per-controller > typically. See sunxi-nand, for instance: > http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/mtd/sunxi-nand.txt > brcmnand had a similar pattern: > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt > (Perhaps it's time we standardized this a little more formally...) These would apply per chip, but the controller has to be configured to support each and every one. Every time an operation was performed, we would have to check the chip type and reconfigure the controller. Currently, the driver does not support this and it would add a lot of overhead in some cases unless a register cache was used. Is the flexibility of using a system with combined 8/16bit devices really worth all the overhead? Isn't it sort of brain dead hardware not to make all of the chips similar? Why would everyone have to pay for such a crazy setup? To separate it would at least be a lie versus the code in the current form. As well, there are only a few SOC which support multiple chip selects. The 'multi-CS' register bits of this controller varies between PowerPC, 68K/Coldfire and ARM platforms. I looked briefly at the brcmnand.c and it seems that it is not supporting different ECC per chip even though the nodes are broken out this way. In fact, if some raw functions are called, I think it will put it in ECC mode even if it wasn't before? Well, I agree that this would be good generically, I think it puts a lot of effort in the drivers for not so much payoff? Fwiw, Bill Pringlemeir. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/