Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 30 9月, 2015 2 次提交
    • F
      mtd: spi-nor: scale up timeout for full-chip erase · 09b6a377
      由 Furquan Shaikh 提交于 
      This patch fixes timeout issues seen on large NOR flash (e.g., 16MB
w25q128fw) when using ioctl(MEMERASE) with offset=0 and length=16M. The
input parameters matter because spi_nor_erase() uses a different code
path for full-chip erase, where we use the SPINOR_OP_CHIP_ERASE (0xc7)
opcode.

Fix: use a different timeout for full-chip erase than for other
commands.

While most operations can be expected to perform relatively similarly
across a variety of NOR flash types and sizes (and therefore might as
well use a similar timeout to keep things simple), full-chip erase is
unique, because the time it typically takes to complete:
(1) is much larger than most operations and
(2) scales with the size of the flash.

Let's base our timeout on the original comments stuck here -- that a 2MB
flash requires max 40s to erase.

Small survey of a few flash datasheets I have lying around:

  Chip         Size (MB)   Max chip erase (seconds)
  ----         --------    ------------------------
  w25q32fw     4           50
  w25q64cv     8           30
  w25q64fw     8           100
  w25q128fw    16          200
  s25fl128s    16          ~256
  s25fl256s    32          ~512

From this data, it seems plenty sufficient to say we need to wait for
40 seconds for each 2MB of flash.

After this change, it might make some sense to decrease the timeout for
everything else, as even the most extreme operations (single block
erase?) shouldn't take more than a handful of seconds. But for safety,
let's leave it as-is. It's only an error case, after all, so we don't
exactly need to optimize it.
Signed-off-by: NFurquan Shaikh <furquan@google.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      09b6a377
    • Y
      mtd: spi-nor: Add support for sst25wf040b · c887be71
      由 Yao Yuan 提交于 
      It is a 512KiB flash with 4 KiB erase sectors.
Signed-off-by: NYuan Yao <yao.yuan@freescale.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      c887be71
  3. 29 9月, 2015 1 次提交
  5. 12 9月, 2015 3 次提交
    • J
      mtd: spi-nor: Zap unneeded write_enable from write_reg · f9f3ce83
      由 Jagan Teki 提交于 
      The 'write_enable' argument is unused and unneeded, so remove it from
the API.
Signed-off-by: NJagan Teki <jteki@openedev.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Han Xu <han.xu@freescale.com>
[Brian: fixed for nxp-spifi.c]
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      f9f3ce83
    • J
      mtd: spi-nor: Use write_sr for write status · fd725234
      由 Jagan Teki 提交于 
      Use existing write_sr() call instead of decoding and
calling nor->write_reg separately.
Signed-off-by: NJagan Teki <jteki@openedev.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      fd725234
    • M
      mtd: spi-nor: Decouple SPI NOR's device_node from controller device · 11bff0b7
      由 Marek Vasut 提交于 
      The problem this patch is trying to address is such, that SPI NOR flash
devices attached to a dedicated SPI NOR controller cannot read their
properties from the associated struct device_node.

A couple of facts first:
1) Each SPI NOR flash has a struct spi_nor associated with it.
2) Each SPI NOR flash has certain device properties associated
   with it, for example the OF property 'm25p,fast-read' is a
   good pick. These properties are used by the SPI NOR core to
   select which opcodes are sent to such SPI NOR flash. These
   properties are coming from spi_nor .dev->of_node .

The problem is, that for SPI NOR controllers, the struct spi_nor .dev
element points to the struct device of the SPI NOR controller, not the
SPI NOR flash. Therefore, the associated dev->of_node also is the
one of the controller and therefore the SPI NOR core code is trying to
parse the SPI NOR controller's properties, not the properties of the
SPI NOR flash.

Note: The m25p80 driver is not affected, because the controller and
      the flash are the same device, so the associated device_node
      of the controller and the flash are the same.

This patch adjusts the SPI NOR core such that the device_node is not
picked from spi_nor .dev directly, but from a new separate spi_nor
.flash_node element. This let's the SPI NOR controller drivers set up
a different spi_nor .flash_node element for each SPI NOR flash.

This patch also fixes the controller drivers to be compatible with
this modification and correctly set the spi_nor .flash_node element.

This patch is inspired by 5844feea
mtd: nand: add common DT init code
Signed-off-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      11bff0b7
  7. 03 9月, 2015 7 次提交
    • B
      mtd: spi-nor: fix NULL dereference when no match found in spi_nor_ids[] · 2ff46e6f
      由 Brian Norris 提交于 
      Commit 06bb6f5a ("mtd: spi-nor: stop (ab)using struct
spi_device_id") converted an array into a pointer, which means that
we should be checking if the pointer goes anywhere, not whether the C
string is empty. To do the latter means we dereference a NULL pointer
when we reach the terminating entry, for which 'name' is now NULL
instead of an array { 0, 0, ... }.

Sample crash:

[    1.101371] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[    1.109457] pgd = c0004000
[    1.112157] [00000000] *pgd=00000000
[    1.115736] Internal error: Oops: 5 [#1] SMP ARM
[    1.120345] Modules linked in:
[    1.123405] CPU: 3 PID: 1 Comm: swapper/0 Not tainted 4.2.0-next-20150902+ #61
[    1.130611] Hardware name: Rockchip (Device Tree)
[    1.135306] task: ee0b8d40 ti: ee0ba000 task.ti: ee0ba000
[    1.140697] PC is at spi_nor_scan+0x90/0x8c4
[    1.144958] LR is at spi_nor_scan+0xa4/0x8c4
...
[    1.504112] [<c03cc2e0>] (spi_nor_scan) from [<c03cb188>] (m25p_probe+0xc8/0x11c)
[    1.511583] [<c03cb188>] (m25p_probe) from [<c03cd9d8>] (spi_drv_probe+0x60/0x7c)
[    1.519055] [<c03cd9d8>] (spi_drv_probe) from [<c037faa0>] (driver_probe_device+0x1a0/0x444)
[    1.527478] [<c037faa0>] (driver_probe_device) from [<c037fec8>] (__device_attach_driver+0x94/0xa0)
[    1.536507] [<c037fec8>] (__device_attach_driver) from [<c037db3c>] (bus_for_each_drv+0x94/0xa4)
[    1.545277] [<c037db3c>] (bus_for_each_drv) from [<c037f7e4>] (__device_attach+0xa4/0x144)
[    1.553526] [<c037f7e4>] (__device_attach) from [<c0380058>] (device_initial_probe+0x1c/0x20)
[    1.562035] [<c0380058>] (device_initial_probe) from [<c037ec88>] (bus_probe_device+0x38/0x94)
[    1.570631] [<c037ec88>] (bus_probe_device) from [<c037ccf4>] (device_add+0x430/0x558)
[    1.578534] [<c037ccf4>] (device_add) from [<c03d0240>] (spi_add_device+0xe4/0x174)
[    1.586178] [<c03d0240>] (spi_add_device) from [<c03d0a24>] (spi_register_master+0x698/0x7d4)
[    1.594688] [<c03d0a24>] (spi_register_master) from [<c03d0ba0>] (devm_spi_register_master+0x40/0x7c)
[    1.603892] [<c03d0ba0>] (devm_spi_register_master) from [<c03d2fb4>] (rockchip_spi_probe+0x360/0x3f4)
[    1.613182] [<c03d2fb4>] (rockchip_spi_probe) from [<c0381e34>] (platform_drv_probe+0x58/0xa8)
[    1.621779] [<c0381e34>] (platform_drv_probe) from [<c037faa0>] (driver_probe_device+0x1a0/0x444)
[    1.630635] [<c037faa0>] (driver_probe_device) from [<c037fdc4>] (__driver_attach+0x80/0xa4)
[    1.639058] [<c037fdc4>] (__driver_attach) from [<c037e850>] (bus_for_each_dev+0x98/0xac)
[    1.647221] [<c037e850>] (bus_for_each_dev) from [<c037f448>] (driver_attach+0x28/0x30)
[    1.655210] [<c037f448>] (driver_attach) from [<c037ef74>] (bus_add_driver+0x128/0x250)
[    1.663200] [<c037ef74>] (bus_add_driver) from [<c0380c40>] (driver_register+0xac/0xf0)
[    1.671191] [<c0380c40>] (driver_register) from [<c0381d50>] (__platform_driver_register+0x58/0x6c)
[    1.680221] [<c0381d50>] (__platform_driver_register) from [<c0a467c8>] (rockchip_spi_driver_init+0x18/0x20)
[    1.690033] [<c0a467c8>] (rockchip_spi_driver_init) from [<c00098a4>] (do_one_initcall+0x124/0x1dc)
[    1.699063] [<c00098a4>] (do_one_initcall) from [<c0a19f84>] (kernel_init_freeable+0x218/0x2ec)
[    1.707748] [<c0a19f84>] (kernel_init_freeable) from [<c0719ed8>] (kernel_init+0x1c/0xf4)
[    1.715912] [<c0719ed8>] (kernel_init) from [<c000fe50>] (ret_from_fork+0x14/0x24)
[    1.723460] Code: e3510000 159f67c0 0a00000c e5961000 (e5d13000)
[    1.729564] ---[ end trace 95baa6b3b861ce25 ]---

Fixes: 06bb6f5a ("mtd: spi-nor: stop (ab)using struct spi_device_id")
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Cc: Rafał Miłecki <zajec5@gmail.com>
      2ff46e6f
    • B
      mtd: spi-nor: embed struct mtd_info within struct spi_nor · 19763671
      由 Brian Norris 提交于 
      This reflects the proper layering, so let's do it.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Tested-by: NJoachim Eastwood <manabian@gmail.com>
      19763671
    • B
      mtd: spi-nor: assign mtd->priv in spi_nor_scan() · c9ec3900
      由 Brian Norris 提交于 
      Layering suggests that the SPI NOR layer (not the hardware driver)
should be initializing the MTD layer.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Tested-by: NJoachim Eastwood <manabian@gmail.com>
      c9ec3900
    • J
      mtd: spi-nor: s25sl064p supports both dual and quad I/O · 0f12a27b
      由 Joachim Eastwood 提交于 
      This chip can be found on Hitex LPC4350 Evaluation Board.
Signed-off-by: NJoachim Eastwood <manabian@gmail.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      0f12a27b
    • J
      mtd: spi-nor: allow dual/quad reads on S25FL129P · c1752086
      由 Jonas Gorski 提交于 
      According to the datasheet[1], both S25FL129P0 (256kB sectors) and
S25FL129P1 (64kB sectors) support dual read, quad read, dual i/o read
and quad i/o read.

I have verified dual read to be working for S25FL129P1 on a dual
capable spi controller. Quad as well as S25FL129P0 is untested, lacking
hardware to verify.

[1] http://www.spansion.com/Support/Datasheets/S25FL129P_00.pdfSigned-off-by: NJonas Gorski <jogo@openwrt.org>
Reviewed-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      c1752086
    • A
      mtd: spi-nor: Add support for sst25wf020a · a1d97ef9
      由 Alexis Ballier 提交于 
      It is a 256KiB flash with 4 KiB erase sectors
and 64KiB overlay blocks.

This is the one available on Hardkernel's Odroid U3 shield.
Signed-off-by: NAlexis Ballier <aballier@gentoo.org>
[Brian: seems like this does NOT require the usual SST_WRITE hacks]
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      a1d97ef9
    • M
      mtd: spi-nor: Add support for Micron n25q064a serial flash · 2a06c7b1
      由 Mika Westerberg 提交于 
      Add Micron (n25q064a) 8MB flash to the list of supported chips.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: NJagan Teki <jteki@openedev.com>
[Brian: fixup context]
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      2a06c7b1
  9. 26 8月, 2015 1 次提交
  11. 15 8月, 2015 1 次提交
  13. 22 7月, 2015 1 次提交
    • B
      mtd: m25p80: allow arbitrary OF matching for "jedec,spi-nor" · 43163022
      由 Brian Norris 提交于 
      When we added the "jedec,spi-nor" compatible string for use in this
driver, we added it as a modalias option. The modalias can be derived in
different ways for platform devices vs. device tree (of_*) matching. But
for device tree matching (the primary target of this identifier string),
the modalias is determined from the first entry in the 'compatible'
property. IOW, the following properties would bind to this driver:

	// Option (a), modalias = "spi-nor"
	compatible = "jedec,spi-nor";

	// Option (b), modalias = "spi-nor"
	compatible = "idontknowwhatimdoing,spi-nor";

But the following would not:

	// Option (c), modalias = "shinynewdevice"
	compatible = "myvendor,shinynewdevice", "jedec,spi-nor";

So, we'd like to match (a) and (c) (even when we don't have an explicit
entry for "shinynewdevice"), and we'd rather not allow (b).

To do this, we
  (1) always (for devices without specific platform data) pass the
      modalias to the spi-nor library;
  (2) rework the spi-nor library to not reject "bad" names, and
      instead just fall back to autodetection; and
  (3) add the .of_match_table to properly catch all "jedec,spi-nor".

This allows (a) and (c) without warnings, and rejects (b).
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      43163022
  15. 21 7月, 2015 1 次提交
  17. 21 5月, 2015 2 次提交
  19. 07 5月, 2015 2 次提交
  21. 06 4月, 2015 4 次提交
  23. 28 3月, 2015 1 次提交
  25. 21 1月, 2015 1 次提交
  27. 08 1月, 2015 1 次提交
    • B
      mtd: spi-nor: Add quad I/O support for Micron SPI NOR · 548cd3ab
      由 Bean Huo 霍斌斌 (beanhuo) 提交于 
      This patch adds code which enables Quad I/O mode on Micron SPI NOR flashes.

For Micron SPI NOR flash, enabling or disabling quad I/O protocol can be
done By two methods, which are to use EVCR (Enhanced Volatile
Configuration Register) and the ENTER QUAD I/O MODE command. There is no
difference between these two methods. Unfortunately, for some Micron SPI
NOR flashes, there no ENTER Quad I/O command (35h), such as n25q064. But
for all current Micron SPI NOR, if it support quad I/O mode, using EVCR
definitely be supported. It is a recommended method to enable Quad I/O
mode by EVCR, Quad I/O protocol bit 7. When EVCR bit 7 is reset to 0,
the SPI NOR flash will operate in quad I/O mode.

This patch has been tested on N25Q512A and MT25TL256BAA1ESF. Micron SPI
NOR of spi_nor_ids[] table all support this method.
Signed-off-by: NBean Huo <beanhuo@micron.com>
Acked-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      548cd3ab
  29. 02 12月, 2014 1 次提交
  31. 01 12月, 2014 4 次提交
  33. 26 11月, 2014 2 次提交
  35. 06 11月, 2014 3 次提交
  37. 05 11月, 2014 2 次提交