On Wednesday 25 March 2009, Grant Likely wrote:

quoted

quoted

This case really does sound like a driver bug and that the existing
cfi-flash binding is sufficient to describe the hardware.  IIUC, when
all the flash chips are of the same type the physmap_of driver should
be smart enough to detect each of the flash chips within the reg
range.

*When* all are identical then this works, yes. But in the Intel P30 case
the 2 chips are not identical. And from my understanding this is not a
problem/bug in the physmap_of driver.

To satisfy my own curiosity, why is physmap_of unable to probe
multiple cfi chips that are non identical?  After detecting the first
chip it and calculated then end address of it can it not do another
full cfi probe for the rest of the reg range?

The "real" probing is done in the mtd core (cfi_probe). So it's nothing that 
could be changed in physmap_of. I have to admit that I didn't fully debug it.

Regardless, even if it could the solution you have below is probably a
better idea anyway than relying on probing.

quoted

quoted

If I'm wrong and it cannot do this, then it would be a simple matter
of adding an additional tuple to reg for each discrete chip.  A
simple, backwards compatible extension which doesn't require a new
binding.

So you are thinking of something like this?

       flash@f0000000,0 {
               #address-cells = <1>;
               #size-cells = <1>;
               compatible = "cfi-flash";
               reg = <0 0x00000000 0x02000000
                      0 0x02000000 0x02000000>;
               bank-width = <2>;
               device-width = <2>;
               partition@0 {
                       label = "test-part1";
                       reg = <0 0x04000000>;
               };
       };

Yes, this looks good to me.  In fact, it is probably better to be
explicit about multiple chips anyway in terms of providing the driver
as much information as possible about where to probe for the chips.
It also elegantly supports sparsely mapped flash chips (ie. if the
board supports larger chips than is actually populated).

OK, then we have a solution. Grant, thanks for your input here.

Best regards,
Stefan