lwn.git/drivers/mtd/spi-nor/intel-spi.c, branch header-removal

mtd: spi-nor: Prepare core / manufacturer code split

2020-03-16T16:28:53+00:00

Move all SPI NOR controller drivers to a controllers/ sub-directory so that we only have SPI NOR related source files under drivers/mtd/spi-nor/. Rename spi-nor.c into core.c, we are about to split this file in multiple source files (one per manufacturer, plus one for the SFDP parsing logic). Signed-off-by: Boris Brezillon Signed-off-by: Tudor Ambarus Reviewed-by: Vignesh Raghavendra

mtd: spi-nor: Introduce 'struct spi_nor_controller_ops'

2019-10-23T06:27:21+00:00

Move all SPI NOR controller driver specific ops in a dedicated structure. 'struct spi_nor' becomes lighter. Use size_t for lengths in 'int (*write_reg)()' and 'int (*read_reg)()'. Rename wite/read_buf to buf, the name of the functions are suggestive enough. Constify buf in int (*write_reg). Comply with these changes in the SPI NOR controller drivers. Suggested-by: Boris Brezillon Signed-off-by: Tudor Ambarus Reviewed-by: Boris Brezillon

mtd: spi-nor: intel-spi: add support for Intel Cannon Lake SPI flash

2019-10-23T06:27:18+00:00

Now that SPI flash controllers without a software sequencer are supported, it's trivial to add support for CNL and its PCI ID. Values from https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/300-series-chipset-pch-datasheet-vol-2.pdf Signed-off-by: Jethro Beekman Reviewed-by: Mika Westerberg Signed-off-by: Tudor Ambarus

mtd: spi-nor: intel-spi: support chips without software sequencer

2019-10-23T06:27:15+00:00

Some flash controllers don't have a software sequencer. Avoid configuring the register addresses for it, and double check everywhere that its not accidentally trying to be used. Every use of `sregs` is now guarded by a check of `sregs` or `swseq_reg`. The check might be done in the calling function. Signed-off-by: Jethro Beekman Signed-off-by: Tudor Ambarus

mtd: spi-nor: intel-spi: Whitelist 4B read commands

2019-08-21T08:09:46+00:00

spi-nor.c issues 4B commands for some Flash chips bigger than 16Mbytes. Xeon(R) D-1500 documentation mentions its Integrated PCH Logic supports Flash chips up to 64Mbytes. D-1500 Integrated PCH documenation however has inconsistencies regarding FADDR register width and says nothing about particular commands issued to support 64Mbytes of Flash. Nevetheless the tests on Xeon(R) CPU D-1548 with 512Mbit Flash chips Macronix MX25L51245G and Micron MT25QL512A showed that erase, write and read operations work just fine after SPINOR_OP_READ_4B and SPINOR_OP_READ_FAST_4B are white-listed (currently only SPINOR_OP_READ_FAST_4B is used and only for Macronix). Signed-off-by: Alexander Sverdlin Reviewed-by: Mika Westerberg Signed-off-by: Tudor Ambarus

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500

2019-06-19T15:09:55+00:00

Based on 2 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation # extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 4122 file(s). Signed-off-by: Thomas Gleixner Reviewed-by: Enrico Weigelt Reviewed-by: Kate Stewart Reviewed-by: Allison Randal Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de Signed-off-by: Greg Kroah-Hartman

mtd: spi-nor: intel-spi: Avoid crossing 4K address boundary on read/write

2019-04-01T12:36:23+00:00

It was observed that reads crossing 4K address boundary are failing. This limitation is mentioned in Intel documents: Intel(R) 9 Series Chipset Family Platform Controller Hub (PCH) Datasheet: "5.26.3 Flash Access Program Register Access: * Program Register Accesses are not allowed to cross a 4 KB boundary..." Enhanced Serial Peripheral Interface (eSPI) Interface Base Specification (for Client and Server Platforms): "5.1.4 Address For other memory transactions, the address may start or end at any byte boundary. However, the address and payload length combination must not cross the naturally aligned address boundary of the corresponding Maximum Payload Size. It must not cross a 4 KB address boundary." Avoid this by splitting an operation crossing the boundary into two operations. Fixes: 8afda8b26d01 ("spi-nor: Add support for Intel SPI serial flash controller") Cc: stable@vger.kernel.org Reported-by: Romain Porte Tested-by: Pascal Fabreges Signed-off-by: Alexander Sverdlin Reviewed-by: Tudor Ambarus Acked-by: Mika Westerberg Signed-off-by: Miquel Raynal

mtd: spi-nor: intel-spi: use mtd_device_register()

2018-08-01T07:18:55+00:00

This driver doesn't specify parsers so it can use that little helper. Signed-off-by: Rafał Miłecki Signed-off-by: Boris Brezillon

mtd: spi-nor: intel: provide a range for poll_timout

2018-05-18T10:53:33+00:00

The overall poll time here is INTEL_SPI_TIMEOUT * 1000 which is 5000 * 1000 - so 5seconds and it is coded as a tight loop here delay_us to readl_poll_timeout() is set to 0. As this is never called in an atomic context sleeping should be no issue and there is no reasons for the tight-loop here. Signed-off-by: Nicholas Mc Guire Acked-by: Mika Westerberg Signed-off-by: Boris Brezillon

mtd: spi-nor: intel-spi: Fix atomic sequence handling

2018-05-18T10:53:05+00:00

On many older systems using SW sequencer the PREOP_OPTYPE register contains two preopcodes as following: PREOP_OPTYPE=0xf2785006 The last two bytes are the opcodes decoded to: 0x50 - Write enable for volatile status register 0x06 - Write enable The former is used to modify volatile bits in the status register. For non-volatile bits the latter is needed. Preopcodes are used in SW sequencer to send one command "atomically" without anything else interfering the transfer. The sequence that gets executed is: - Send preopcode (write enable) from PREOP_OPTYPE register - Send the actual SPI command - Poll busy bit in the status register (0x05, RDSR) Commit 8c473dd61bb5 ("spi-nor: intel-spi: Don't assume OPMENU0/1 to be programmed by BIOS") enabled atomic sequence handling but because both preopcodes are programmed, the following happens: if (preop >> 8) val |= SSFSTS_CTL_SPOP; Since on these systems preop >> 8 == 0x50 we end up picking volatile write enable instead. Because of this the actual write command is pretty much NOP unless there is a WREN latched in the chip already. Furthermore we should not really just assume that WREN was issued in previous call to intel_spi_write_reg() because that might not be the case. This updates driver to first check that the opcode is actually available in PREOP_OPTYPE register and if not return error back to the spi-nor core (if the controller is not locked we program it now). In addition we save the opcode to ispi->atomic_preopcode field which is checked in next call to intel_spi_sw_cycle() to actually enable atomic sequence using the requested preopcode. Fixes: 8c473dd61bb5 ("spi-nor: intel-spi: Don't assume OPMENU0/1 to be programmed by BIOS") Signed-off-by: Mika Westerberg Cc: stable@vger.kernel.org Reviewed-by: Marek Vasut Signed-off-by: Boris Brezillon