Spansion SPI parts

Can we fix the Spansion SPI flash device names in drivers/mtd/devices/m25p80.c?
There is no Spansion s25sl device family. The references should be changed to s25fl, at a couple of locations (see below).

Thanks,
Gernot

--
Dr. Gernot Hoyler, Customer Engineering, Spansion LLC
-------------------------------------------------------------------------------------

On Fri, Jul 16, 2010 at 10:08, Hoyler, Gernot wrote:
> Can we fix the Spansion SPI flash device names in drivers/mtd/devices/m25p80.c?
> There is no Spansion s25sl device family. The references should be changed to s25fl, at a couple of locations (see below).

you will need to verify all platform resources in board files are
updated as well
-mike

Hi Mike,

> you will need to verify all platform resources in board files are updated as well -mike

I had run a recursive grep through the original kernel source tree, see below.
In this output, I do not see any directly matching board driver references... 
except some refs to s25sl128b which seems to be declared by some derived Freescale
driver (fsl_m25p80). I assume we cannot fix that derivative (because it only comes
with the Freescale BSPs), so we should be clean!

Thx, Gernot

=======================================================================
% find linux-2.6.34 -exec grep -i s25sl {} \; -print
                                modal = "s25sl128b";
linux-2.6.34-fixed/arch/powerpc/boot/dts/p2020rdb.dts
                                modal = "s25sl128b";
linux-2.6.34-fixed/arch/powerpc/boot/dts/p2020rdb_camp_core0.dts
                                modal = "s25sl128b";
linux-2.6.34-fixed/arch/powerpc/boot/dts/p1020rdb.dts
        { "s25sl004a",  INFO(0x010212,      0,  64 * 1024,   8, 0) },
        { "s25sl008a",  INFO(0x010213,      0,  64 * 1024,  16, 0) },
        { "s25sl016a",  INFO(0x010214,      0,  64 * 1024,  32, 0) },
        { "s25sl032a",  INFO(0x010215,      0,  64 * 1024,  64, 0) },
        { "s25sl064a",  INFO(0x010216,      0,  64 * 1024, 128, 0) },
        { "s25sl12800", INFO(0x012018, 0x0300, 256 * 1024,  64, 0) },
        { "s25sl12801", INFO(0x012018, 0x0301,  64 * 1024, 256, 0) },
linux-2.6.34-fixed/drivers/mtd/devices/m25p80.c
          Spansion S25SL, SST 25VF, ST M25P, and Winbond W25X.  Other chips
linux-2.6.34-fixed/drivers/mtd/devices/Kconfig


============= /arch/powerpc/boot/dts/p2020rdb_camp_core0.dts ============
                      linux,modalias = "fsl_m25p80";
                      modal = "s25sl128b";
                      spi-max-frequency = <50000000>;
                      mode = <0>;

On Fri, Jul 16, 2010 at 11:32, Hoyler, Gernot wrote:
>> you will need to verify all platform resources in board files are updated as well -mike
>
> I had run a recursive grep through the original kernel source tree, see below.
> In this output, I do not see any directly matching board driver references...
> except some refs to s25sl128b which seems to be declared by some derived Freescale
> driver (fsl_m25p80). I assume we cannot fix that derivative (because it only comes
> with the Freescale BSPs), so we should be clean!

mmm, why do you assume that ?  dts files are compiled into device
trees which are bundled into the kernel image.  you will need to
change those dts files to use the updated name.  otherwise the spi
flash will not be detected/probed for those boards anymore.
-mike

On Fri, Jul 16, 2010 at 7:08 AM, Hoyler, Gernot
<Gernot.Hoyler@spansion.com> wrote:
> Can we fix the Spansion SPI flash device names in drivers/mtd/devices/m25p80.c?

> +       { "s25fl128p0", INFO(0x012018, 0x0300, 256 * 1024,  64, 0) },
> +       { "s25fl128p1", INFO(0x012018, 0x0301,  64 * 1024, 256, 0) },
>        { "s25fl129p0", INFO(0x012018, 0x4d00, 256 * 1024,  64, 0) },
>        { "s25fl129p1", INFO(0x012018, 0x4d01,  64 * 1024, 256, 0) },

After rereading the datasheets I suspect that I used incorrect
suffixes for the s25fl129* devices.  Would you mind reviewing these 4
entries to ensure that they line up with each chip's markings?

Thanks.

> +       { "s25fl128p0", INFO(0x012018, 0x0300, 256 * 1024,  64, 0) },

> +       { "s25fl128p1", INFO(0x012018, 0x0301,  64 * 1024, 256, 0) },

>        { "s25fl129p0", INFO(0x012018, 0x4d00, 256 * 1024,  64, 0) },

>        { "s25fl129p1", INFO(0x012018, 0x4d01,  64 * 1024, 256, 0) },


> After rereading the datasheets I suspect that I used incorrect

> suffixes for the s25fl129* devices.  Would you mind reviewing these 4

> entries to ensure that they line up with each chip's markings?


You mean the trailing '0' and '1'? Well, the correct OPNs for these devices are s25fl128pxxxxx00, s25fl128pxxxxx01, s25fl129pxxxxx00 and s25fl128pxxxxx01, respectively, where a trailing '00' denotes the 64kB sector devices and a tailing '01' denotes the 256kB sector devices. The laser markings on the packages typically only include the 1st portion of the OPN, e.g. FL128PIF. So, yes, if you want to align the naming scheme with the OPNs then you might change the names to:

        { "s25fl128p-01", INFO(0x012018, 0x0300, 256 * 1024,  64, 0) },
        { "s25fl128p-00", INFO(0x012018, 0x0301,  64 * 1024, 256, 0) },
        { "s25fl129p-01", INFO(0x012018, 0x4d00, 256 * 1024,  64, 0) },
        { "s25fl129p-00", INFO(0x012018, 0x4d01,  64 * 1024, 256, 0) },

On the other side, if you want to align the trailing '0' or '1' with the 5th device ID byte then you can stick with the first proposal.