[PATCH 1/5] mtd: ofpart: grab device tree node directly from master device node

[Boris Brezillon]

On Thu, 29 Oct 2015 18:23:47 +0100
Marek Vasut <marex at denx.de> wrote:

> On Thursday, October 29, 2015 at 08:24:48 AM, Boris Brezillon wrote:
> > Hi Robert,
> 
> Hi!
> 
> > On Thu, 29 Oct 2015 07:32:33 +0100
> > 
> > Robert Jarzmik <robert.jarzmik at free.fr> wrote:
> > > Marek Vasut <marex at denx.de> writes:
> > > >> Isn't there the case of a single NAND controller with 2 identical
> > > >> chips, each a 8 bit NAND chip, and the controller aggregating them to
> > > >> offer the OS a single 16-bit NAND chip ?
> > 
> > Honestly, I don't know how this can possibly work, do you have a real
> > example of that use case.
> > 
> > Here are a few reasons making it impossible:
> > 
> > 1/ NAND are accessed using specific command sequences, and those
> > commands and addresses cycles are sent on through the data bus (AFAIR
> > only the lower 8bits of a 16bits bus are used for those
> > command/address cycles), so even if you connect the CLE/ALE/CS/RB pins
> > on both chips, the one connected on the MSB side of the data bus will
> > just receive garbage during the command/address sequences, and your
> > program/read operations won't work
> 
> Unless you duplicate the command to both MSB and LSB.

Except it's now how devices supporting 16 bits data bus are supposed to
work, which means your NAND controller will probably not be able to
send the command/address value on the higher 8 bits...

> 
> > 2/ NAND chips can have bad blocks, so even if you were able to address
> > 2 chips (which according to #1 is impossible), you might try to write
> > on a bad block on the chip connected on the MSB side of the data bus.
> 
> This one is a valid problem. The other valid issue here is where the
> command might fail on one chip and pass on the other.
> 
> > 3/ There probably are plenty of other reasons why this is not
> > possible ;-).
> 
> It's possible, implementable, but a really bad idea.

Possible and implementable, maybe with an adapted software stack
and a customized NAND controller. I know you're working on emulating
flash devices using FPGA, so the next step is to create a new NAND
controller IP supporting that kind of stuff and adding support for
this feature to the NAND framework ;-).
Anyway, it"s definitely a bad idea.

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com