- Add opcodes for octal I/O commands
* Read : 1-1-8 and 1-8-8 protocol
* Write : 1-1-8 and 1-8-8 protocol
* opcodes for 4-byte address mode command
- Entry of macros in _convert_3to4_xxx function
- Add flag SPI_NOR_OCTAL_READ specifying flash support octal read
commands. This flag is required for flashes which didn't provides
support for auto detection of Octal mode capabilities i.e. not
seems to support newer JESD216C standard.
Signed-off-by: Vignesh R <vigneshr@ti.com>
Signed-off-by: Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com>
Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Signed-off-by: Boris Brezillon <bbrezillon@kernel.org>
Add support for SFDP (JESD216B) 4-byte Address Instruction Table. This
table is optional but when available, we parse it to get the 4-byte
address op codes supported by the memory.
Using these op codes is stateless as opposed to entering the 4-byte
address mode or setting the Base Address Register (BAR).
Flashes that have the 4BAIT table declared can now support
SPINOR_OP_PP_1_1_4_4B and SPINOR_OP_PP_1_4_4_4B opcodes.
Tested on MX25L25673G.
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@microchip.com>
[tudor.ambarus@microchip.com:
- rework erase and page program logic,
- pass DMA-able buffer to spi_nor_read_sfdp(),
- introduce SPI_NOR_HAS_4BAIT
- various minor updates.]
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
Add SPDX tags to replace the license boiler-plate and fix the
MODULE_LICENSE() definition in spi-nor.c to match the license text
(GPL v2).
Interestingly, spi-nor.h and spi-nor.c do not use the same license
(GPL v2+ for spi-nor.h, GPL v2 for spi-nor.c).
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Some flash_info entries have the SPI_NOR_4B_OPCODES flag set to let the
core know that the flash supports 4B opcode. While this solution works
fine for id-based caps detection, it doesn't work that well when relying
on SFDP-based caps detection. Let's add an SNOR_F_4B_OPCODES flag so
that the SFDP parsing code can set it when appropriate.
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Some MICRON related macros in spi-nor domain were ST.
Rename entries related to STMicroelectronics under macro SNOR_MFR_ST.
Added entry of MFR Id for Micron flashes, 0x002C.
Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com>
Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
Add support for the SFDP (JESD216B) Sector Map Parameter Table. This
table is optional, but when available, we parse it to identify the
location and size of sectors within the main data array of the
flash memory device and to identify which Erase Types are supported by
each sector.
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Reviewed-by: Marek Vasut <marek.vasut@gmail.com>
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
Based on Cyrille Pitchen's patch https://lkml.org/lkml/2017/3/22/935.
This patch is a transitional patch in introducing the support of
SFDP SPI memories with non-uniform erase sizes like Spansion s25fs512s.
Non-uniform erase maps will be used later when initialized based on the
SFDP data.
Introduce the memory erase map which splits the memory array into one
or many erase regions. Each erase region supports up to 4 erase types,
as defined by the JEDEC JESD216B (SFDP) specification.
To be backward compatible, the erase map of uniform SPI NOR flash memories
is initialized so it contains only one erase region and this erase region
supports only one erase command. Hence a single size is used to erase any
sector/block of the memory.
Besides, since the algorithm used to erase sectors on non-uniform SPI NOR
flash memories is quite expensive, when possible, the erase map is tuned
to come back to the uniform case.
The 'erase with the best command, move forward and repeat' approach was
suggested by Cristian Birsan in a brainstorm session, so:
Suggested-by: Cristian Birsan <cristian.birsan@microchip.com>
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Reviewed-by: Marek Vasut <marek.vasut@gmail.com>
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
Commit 59b356ffd0 ("mtd: m25p80: restore the status of SPI flash when
exiting") is the latest from a long history of attempts to add reboot
handling to handle stateful addressing modes on SPI flash. Some prior
mostly-related discussions:
http://lists.infradead.org/pipermail/linux-mtd/2013-March/046343.html
[PATCH 1/3] mtd: m25p80: utilize dedicated 4-byte addressing commands
http://lists.infradead.org/pipermail/barebox/2014-September/020682.html
[RFC] MTD m25p80 3-byte addressing and boot problem
http://lists.infradead.org/pipermail/linux-mtd/2015-February/057683.html
[PATCH 2/2] m25p80: if supported put chip to deep power down if not used
Previously, attempts to add reboot-time software reset handling were
rejected, but the latest attempt was not.
Quick summary of the problem:
Some systems (e.g., boot ROM or bootloader) assume that they can read
initial boot code from their SPI flash using 3-byte addressing. If the
flash is left in 4-byte mode after reset, these systems won't boot. The
above patch provided a shutdown/remove hook to attempt to reset the
addressing mode before we reboot. Notably, this patch misses out on
huge classes of unexpected reboots (e.g., crashes, watchdog resets).
Unfortunately, it is essentially impossible to solve this problem 100%:
if your system doesn't know how to reset the SPI flash to power-on
defaults at initialization time, no amount of software can really rescue
you -- there will always be a chance of some unexpected reset that
leaves your flash in an addressing mode that your boot sequence didn't
expect.
While it is not directly harmful to perform hacks like the
aforementioned commit on all 4-byte addressing flash, a
properly-designed system should not need the hack -- and in fact,
providing this hack may mask the fact that a given system is indeed
broken. So this patch attempts to apply this unsound hack more narrowly,
providing a strong suggestion to developers and system designers that
this is truly a hack. With luck, system designers can catch their errors
early on in their development cycle, rather than applying this hack long
term. But apparently enough systems are out in the wild that we still
have to provide this hack.
Document a new device tree property to denote systems that do not have a
proper hardware (or software) reset mechanism, and apply the hack (with
a loud warning) only in this case.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
Winbond spi-nor flash 32MB and larger have an 'Extended Address
Register' as one option for addressing beyond 16MB (Macronix
has the same concept, Spansion has EXTADD bits in the Bank Address
Register).
According to section
8.2.7 Write Extended Address Register (C5h)
of the Winbond W25Q256FV data sheet (256M-BIT SPI flash)
The Extended Address Register is only effective when the device is
in the 3-Byte Address Mode. When the device operates in the 4-Byte
Address Mode (ADS=1), any command with address input of A31-A24
will replace the Extended Address Register values. It is
recommended to check and update the Extended Address Register if
necessary when the device is switched from 4-Byte to 3-Byte Address
Mode.
So the documentation suggests clearing the EAR after switching to
3-byte mode. Experimentation shows that the EAR is *always* one after
the switch to 3-byte mode, so clearing the EAR is mandatory at
shutdown for a subsequent 3-byte-addressed reboot to work.
Note that some SOCs (e.g. MT7621) do not assert a reset line at normal
reboot, so we cannot rely on hardware reset. The MT7621 does assert a
reset line at watchdog-reset.
Acked-by: Marek Vasut <marek.vasut@gmail.com>
Signed-off-by: NeilBrown <neil@brown.name>
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
Add this API to restore the status of SPI flash chip to the default
such as addressing mode, whenever detach the driver from device or
reboot the system.
Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@wedev4u.fr>
For Micron spi nor device, when erase/program operation
fails, especially the failure results from intending to
modify protected space, spi-nor upper layers still get
the return which shows the operation succeeds. This is
because current spi_nor_fsr_ready() only uses FSR bit.7
(flag status register) to check device whether ready.
This patch fixes this issue by checking relevant error
bits in FSR.
The FSR is a powerful tool to investigate the status of
device, checking information regarding what the memory is
actually doing and detecting possible error conditions.
Signed-off-by: beanhuo <beanhuo@micron.com>
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@wedev4u.fr>
This patch extracts some chunks from spi_nor_init_params and spi_nor_scan()
and moves them into a new spi_nor_init() function.
Indeed, spi_nor_init() regroups all the required SPI flash commands to be
sent to the SPI flash memory before performing any runtime operations
(Fast Read, Page Program, Sector Erase, ...). Hence spi_nor_init():
1) removes the flash protection if applicable for certain vendors.
2) sets the Quad Enable bit, if needed, before using Quad SPI protocols.
3) makes the memory enter its (stateful) 4-byte address mode, if needed,
for SPI flash memory > 128Mbits not supporting the 4-byte address
instruction set.
spi_nor_scan() now ends by calling spi_nor_init() once the probe phase has
completed. Further patches could also use spi_nor_init() to implement the
mtd->_resume() handler for the spi-nor framework.
Signed-off-by: Kamal Dasu <kdasu.kdev@gmail.com>
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@wedev4u.fr>
S25FL{128|256|512}S datasheets say:
"When P_ERR or E_ERR bits are set to one, the WIP bit will remain set to
one indicating the device remains busy and unable to receive new operation
commands. A Clear Status Register (CLSR) command must be received to return
the device to standby mode."
Current spi-nor code works until first error occurs, but write/erase errors
are not just rare hardware failures, they also occur if user tries to flash
write-protected areas. After such attempt no SPI command can be executed
any more and even read fails. This patch adds support for P_ERR and E_ERR
bits in Status Register 1 (so that operation fails immediately and not
after a long timeout) and proper recovery from the error condition.
Tested on Spansion S25FS128S, which is supported by S25FL129P entry.
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com>
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@wedev4u.fr>
This patch adds support to the JESD216 rev B standard and parses the SFDP
tables to dynamically initialize the 'struct spi_nor_flash_parameter'.
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@microchip.com>
Reviewed-by: Marek Vasut <marek.vasut@gmail.com>
This patch starts adding support to Octo SPI protocols (SPI x-y-8).
Op codes for Fast Read and/or Page Program operations using Octo SPI
protocols are not known yet (no JEDEC specification has defined them yet)
but we'd rather introduce the Octo SPI protocols now so it's done as it
should be.
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
Reviewed-by: Marek Vasut <marek.vasut@gmail.com>
This patch introduces support to Double Transfer Rate (DTR) SPI protocols.
DTR is used only for Fast Read operations.
According to manufacturer datasheets, whatever the number of I/O lines
used during instruction (x) and address/mode/dummy (y) clock cycles, DTR
is used only during data (z) clock cycles of SPI x-y-z protocols.
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
Reviewed-by: Marek Vasut <marek.vasut@gmail.com>
This patch changes the prototype of spi_nor_scan(): its 3rd parameter
is replaced by a 'struct spi_nor_hwcaps' pointer, which tells the spi-nor
framework about the actual hardware capabilities supported by the SPI
controller and its driver.
Besides, this patch also introduces a new 'struct spi_nor_flash_parameter'
telling the spi-nor framework about the hardware capabilities supported by
the SPI flash memory and the associated settings required to use those
hardware caps.
Then, to improve the readability of spi_nor_scan(), the discovery of the
memory settings and the memory initialization are now split into two
dedicated functions.
1 - spi_nor_init_params()
The spi_nor_init_params() function is responsible for initializing the
'struct spi_nor_flash_parameter'. Currently this structure is filled with
legacy values but further patches will allow to override some parameter
values dynamically, for instance by reading the JESD216 Serial Flash
Discoverable Parameter (SFDP) tables from the SPI memory.
The spi_nor_init_params() function only deals with the hardware
capabilities of the SPI flash memory: especially it doesn't care about
the hardware capabilities supported by the SPI controller.
2 - spi_nor_setup()
The second function is called once the 'struct spi_nor_flash_parameter'
has been initialized by spi_nor_init_params().
With both 'struct spi_nor_flash_parameter' and 'struct spi_nor_hwcaps',
the new argument of spi_nor_scan(), spi_nor_setup() computes the best
match between hardware caps supported by both the (Q)SPI memory and
controller hence selecting the relevant settings for (Fast) Read and Page
Program operations.
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
Reviewed-by: Marek Vasut <marek.vasut@gmail.com>
This patch renames the SPINOR_OP_* macros of the 4-byte address
instruction set so the new names all share a common pattern: the 4-byte
address name is built from the 3-byte address name appending the "_4B"
suffix.
The patch also introduces new op codes to support other SPI protocols such
as SPI 1-4-4 and SPI 1-2-2.
This is a transitional patch and will help a later patch of spi-nor.c
to automate the translation from the 3-byte address op codes into their
4-byte address version.
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Marek Vasut <marek.vasut@gmail.com>
Xilinx Spartan-3AN FPGAs contain an In-System Flash where they keep
their configuration data and (optionally) some user data.
The protocol of this flash follows most of the spi-nor standard. With
the following differences:
- Page size might not be a power of two.
- The address calculation (default addressing mode).
- The spi nor commands used.
Protocol is described on Xilinx User Guide UG333
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Cc: Boris Brezillon <boris.brezillon@free-electrons.com>
Cc: Brian Norris <computersforpeace@gmail.com>
Cc: Marek Vasut <marek.vasut@gmail.com>
Reviewed-by: Marek Vasut <marek.vasut@gmail.com>
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
Do not pass retlen to hardware driver read/write functions. Update it in
spi-nor generic driver instead.
Signed-off-by: Michal Suchanek <hramrach@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Tested-by Cyrille Pitchen <cyrille.pitchen@atmel.com>
Acked-by: Michal Suchanek <hramrach@gmail.com>
Tested-by: Michal Suchanek <hramrach@gmail.com>
Change the return value of spi-nor device read and write methods to
allow returning amount of data transferred and errors as
read(2)/write(2) does.
Also, start handling positive returns in spi_nor_read(), since we want
to convert drivers to start returning the read-length both via *retlen
and the return code. (We don't need to do the same transition process
for spi_nor_write(), since ->write() didn't used to have a return code
at all.)
Signed-off-by: Michal Suchanek <hramrach@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Tested-by Cyrille Pitchen <cyrille.pitchen@atmel.com>
Acked-by: Michal Suchanek <hramrach@gmail.com>
Tested-by: Michal Suchanek <hramrach@gmail.com>
Also note the GigaDevice JEDEC ID.
No write-protect support yet, since this flash uses a different status
register layout.
Cc: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Acked-by: Marek Vasut <marex@denx.de>
Some flash support a bit in the status register that inverts protection
so that it applies to the bottom of the flash, not the top. This yields
additions to the protection range table, as noted in the comments.
Because this feature is not universal to all flash that support
lock/unlock, control it via a new flag.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Tested-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Spansion and Winbond have occasionally used the same manufacturer ID,
and they don't support the same features. Particularly, writing SR=0
seems to break read access for Spansion's s25fl064k. Unfortunately, we
don't currently have a way to differentiate these Spansion and Winbond
parts, so rather than regressing support for these Spansion flash, let's
drop the new Winbond lock/unlock support for now. We can try to address
Winbond support during the next release cycle.
Original discussion:
http://patchwork.ozlabs.org/patch/549173/http://patchwork.ozlabs.org/patch/553683/
Fixes: 357ca38d47 ("mtd: spi-nor: support lock/unlock/is_locked for Winbond")
Fixes: c6fc2171b2 ("mtd: spi-nor: disable protection for Winbond flash at startup")
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Reported-by: Felix Fietkau <nbd@openwrt.org>
Cc: Felix Fietkau <nbd@openwrt.org>
So far struct spi_nor was using just a pointer to struct mtd_info so it
wasn't needed to have it fully defined there. After recent change we
embed whole struct so we need to include a proper header.
Fixes: 1976367173 ("mtd: spi-nor: embed struct mtd_info within struct spi_nor")
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Some spi-nor drivers perform sector erase by duplicating their
write_reg() command. Let's not require that the driver fill this out,
and provide a default instead.
Tested on m25p80.c and Medatek's MT8173 SPI NOR flash driver.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
We can just alias to the MTD of_node.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
We are going to begin using the mtd->dev.of_node field for MTD device
nodes, so let's add helpers for it. Also, we'll be making some
conversions on spi_nor (and nand_chip eventually) too, so get that ready
with their own helpers.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
This enables ioctl(MEMISLOCKED). Status can now be reported in the
mtdinfo or flash_lock utilities found in mtd-utils.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
These are often similar for CFI (parallel NOR) and for SPI NOR, but they
aren't always the same, for various reasons (different namespaces,
company acquisitions and renames, etc.). And some don't have CFI_MFR_*
entries at all.
So let's make a proper place to list the SPI NOR IDs, with all the SPI
NOR specific assumptions and comments.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
These status bits use different ways of representing similar integer
constants -- some are decimal, some are hex. Make them more consistent.
At the same time, impose my own preference, since IMO it's clearer what
these are when using the BIT() macro.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
struct spi_nor_xfer_cfg and read_xfer/write_xfer hooks were never used by
any driver. Do some cleanup by removing them.
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
The 'write_enable' argument is unused and unneeded, so remove it from
the API.
Signed-off-by: Jagan 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: Brian Norris <computersforpeace@gmail.com>
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 5844feeaa4
mtd: nand: add common DT init code
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
This reflects the proper layering, so let's do it.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Tested-by: Joachim Eastwood <manabian@gmail.com>
This header can't actually stand alone, as it relies on the declaration
(but not definition) of struct mtd_info. Let's fix that.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Tested-by: Joachim Eastwood <manabian@gmail.com>
Flash lock/unlock is a flash-specific operations. Factor out a callback
for it to more readily support other vendors.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Tested-by: VIET NGA DAO <vndao@altera.com>
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: Bean Huo <beanhuo@micron.com>
Acked-by: Marek Vasut <marex@denx.de>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
We don't need to expose a 'wait-till-ready' interface to drivers. Status
register polling should be handled by the core spi-nor.c library, and as
of now, I see no need to provide a special driver-specific hook for it.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Reviewed-by: Marek Vasut <marex@denx.de>
There is currently no useful way to override the default
implementation of this operation. The returned struct spi_device_id
must have a pointer to struct flash_info in its private data, but this
structure is defined inside spi-nor.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
m25p80's device ID table is now spi_nor_ids, defined in spi-nor. The
MODULE_DEVICE_TABLE() macro doesn't work with extern definitions, but
its use was also removed at the same time. Now if m25p80 is built as
a module it doesn't get the necessary aliases to be loaded
automatically.
A clean solution to this will involve defining the list of device
IDs in spi-nor.h and removing struct spi_device_id from the spi-nor
API, but this is quite a large change.
As a quick fix suitable for stable, copy the device IDs back into
m25p80.
Fixes: 03e296f613 ("mtd: m25p80: use the SPI nor framework")
Cc: <stable@vger.kernel.org> # 3.16.x: 32f1b7c835: mtd: move support for struct flash_platform_data into m25p80
Cc: <stable@vger.kernel.org> # 3.16.x: 90e55b3812: mtd: m25p80: get rid of spi_get_device_id
Cc: <stable@vger.kernel.org> # 3.16.x: 70f3ce0510: mtd: spi-nor: make spi_nor_scan() take a chip type name, not spi_device_id
Cc: <stable@vger.kernel.org> # 3.16.x
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Drivers currently call spi_nor_match_id() and then spi_nor_scan().
This adds a dependency on struct spi_device_id which we want to
avoid. Make spi_nor_scan() do it for them.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Some new Micron flash chips require reading the flag status register to
determine when operations have completed.
Furthermore, chips with multi-die stacks of the 65nm 256Mb QSPI also
require reading the status register before reading the flag status
register.
This patch adds support for the flag status register in the n25q512ax3
and n25q00 Micron QSPI flash chips.
Signed-off-by: Graham Moore <grmoore@altera.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
serial_flash_cmds.h defines our opcodes a little differently. Let's
borrow its naming, since it's borrowed from the SFDP standard, and it's
more extensible.
This prepares us for merging serial_flash_cmds.h and spi-nor.h opcode
listing.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Acked-by: Huang Shijie <b32955@freescale.com>
Qualify these with a better namespace, and prepare them for use in more
drivers.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Acked-by: Huang Shijie <b32955@freescale.com>
