On Thu, Sep 19, 2013 at 11:46 AM, Simon Glass sjg@chromium.org wrote:
Hi,
On Sun, Sep 15, 2013 at 12:15 PM, Jagannadha Sutradharudu Teki < jagannadha.sutradharudu-teki@xilinx.com> wrote:
Added new spi_flash_probe support, currently added N25Q* flash part attributes support.
Updated the sector_size attributes as per the flash parts. Looks fine for with this sector_size for computing the size of flash.
Defined CONFIG_SPI_FLASH_LEGACY for old probing style which is available on spi_flash_probe_legacy.c, this will removed soon once all flashes are supported in new spi_flash_probe.
Signed-off-by: Jagannadha Sutradharudu Teki jaganna@xilinx.com
Changes for v3: - Fix warning issue. Changes for v2: - Removed CONFIG_SPI_FLASH_NEW, add CONFIG_SPI_FLASH_LEGACY - Enable CONFIG_SPI_FLASH_STMICRO in spi_flash_params table - Updated few structure members
drivers/mtd/spi/Makefile | 1 + drivers/mtd/spi/spi_flash_probe.c | 229 ++++++++++++------------- drivers/mtd/spi/spi_flash_probe_legacy.c | 276 +++++++++++++++++++++++++++++++ 3 files changed, 385 insertions(+), 121 deletions(-) create mode 100644 drivers/mtd/spi/spi_flash_probe_legacy.c
...
+/*
- The following table holds all device probe functions
- shift: number of continuation bytes before the ID
- idcode: the expected IDCODE or 0xff for non JEDEC devices
- probe: the function to call
- Non JEDEC devices should be ordered in the table such that
- the probe functions with best detection algorithms come first.
- Several matching entries are permitted, they will be tried
- in sequence until a probe function returns non NULL.
- IDCODE_CONT_LEN may be redefined if a device needs to declare a
- larger "shift" value. IDCODE_PART_LEN generally shouldn't be
- changed. This is the max number of bytes probe functions may
- examine when looking up part-specific identification info.
- Probe functions will be given the idcode buffer starting at their
- manu id byte (the "idcode" in the table below). In other words,
- all of the continuation bytes will be skipped (the "shift" below).
- */
+#define IDCODE_CONT_LEN 0 +#define IDCODE_PART_LEN 5 +static const struct {
const u8 shift;const u8 idcode;struct spi_flash *(*probe) (struct spi_slave *spi, u8 *idcode);+} flashes[] = {
/* Keep it sorted by define name */+#ifdef CONFIG_SPI_FLASH_ATMEL
{ 0, 0x1f, spi_flash_probe_atmel, },+#endif +#ifdef CONFIG_SPI_FLASH_EON
{ 0, 0x1c, spi_flash_probe_eon, },+#endif +#ifdef CONFIG_SPI_FLASH_GIGADEVICE
{ 0, 0xc8, spi_flash_probe_gigadevice, },+#endif +#ifdef CONFIG_SPI_FLASH_MACRONIX
{ 0, 0xc2, spi_flash_probe_macronix, },+#endif +#ifdef CONFIG_SPI_FLASH_SPANSION
{ 0, 0x01, spi_flash_probe_spansion, },+#endif +#ifdef CONFIG_SPI_FLASH_SST
{ 0, 0xbf, spi_flash_probe_sst, },+#endif +#ifdef CONFIG_SPI_FLASH_STMICRO
{ 0, 0x20, spi_flash_probe_stmicro, },+#endif +#ifdef CONFIG_SPI_FLASH_WINBOND
{ 0, 0xef, spi_flash_probe_winbond, },+#endif +#ifdef CONFIG_SPI_FRAM_RAMTRON
{ 6, 0xc2, spi_fram_probe_ramtron, },+# undef IDCODE_CONT_LEN +# define IDCODE_CONT_LEN 6 +#endif
/* Keep it sorted by best detection */+#ifdef CONFIG_SPI_FLASH_STMICRO
{ 0, 0xff, spi_flash_probe_stmicro, },+#endif +#ifdef CONFIG_SPI_FRAM_RAMTRON_NON_JEDEC
{ 0, 0xff, spi_fram_probe_ramtron, },+#endif
Do you think it is worth using a linker list for this?
I didn't understand what do you means by this? Can you please elaborate.