<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/mtd, branch v4.17.1</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.17.1</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.17.1'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2018-05-14T12:46:20+00:00</updated>
<entry>
<title>mtd: rawnand: marvell: Fix read logic for layouts with -&gt;nchunks &gt; 2</title>
<updated>2018-05-14T12:46:20+00:00</updated>
<author>
<name>Boris Brezillon</name>
<email>boris.brezillon@bootlin.com</email>
</author>
<published>2018-05-09T07:13:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=90d617633368ab97a2c7571c6e66dad54f39228d'/>
<id>urn:sha1:90d617633368ab97a2c7571c6e66dad54f39228d</id>
<content type='text'>
The code is doing monolithic reads for all chunks except the last one
which is wrong since a monolithic read will issue the
READ0+ADDRS+READ_START sequence. It not only takes longer because it
forces the NAND chip to reload the page content into its internal
cache, but by doing that we also reset the column pointer to 0, which
means we'll always read the first chunk instead of moving to the next
one.

Rework the code to do a monolithic read only for the first chunk,
then switch to naked reads for all intermediate chunks and finally
issue a last naked read for the last chunk.

Fixes: 02f26ecf8c77 mtd: nand: add reworked Marvell NAND controller driver
Cc: stable@vger.kernel.org
Reported-by: Chris Packham &lt;chris.packham@alliedtelesis.co.nz&gt;
Signed-off-by: Boris Brezillon &lt;boris.brezillon@bootlin.com&gt;
Tested-by: Chris Packham &lt;chris.packham@alliedtelesis.co.nz&gt;
Acked-by: Miquel Raynal &lt;miquel.raynal@bootlin.com&gt;
</content>
</entry>
<entry>
<title>mtd: rawnand: Make sure we wait tWB before polling the STATUS reg</title>
<updated>2018-05-10T06:40:39+00:00</updated>
<author>
<name>Boris Brezillon</name>
<email>boris.brezillon@bootlin.com</email>
</author>
<published>2018-05-04T19:24:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3057fcef385348fe85173f1b0c824d89f1176f72'/>
<id>urn:sha1:3057fcef385348fe85173f1b0c824d89f1176f72</id>
<content type='text'>
NAND chips require a bit of time to take the NAND operation into
account and set the BUSY bit in the STATUS reg. Make sure we don't poll
the STATUS reg too early in nand_soft_waitrdy().

Fixes: 8878b126df76 ("mtd: nand: add -&gt;exec_op() implementation")
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Boris Brezillon &lt;boris.brezillon@bootlin.com&gt;
Acked-by: Miquel Raynal &lt;miquel.raynal@bootlin.com&gt;
</content>
</entry>
<entry>
<title>mtd: rawnand: marvell: fix command xtype in BCH write hook</title>
<updated>2018-05-04T08:35:04+00:00</updated>
<author>
<name>Miquel Raynal</name>
<email>miquel.raynal@bootlin.com</email>
</author>
<published>2018-05-03T10:00:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a2ee41fd953e7c3ff6c55a3038c80354d191a318'/>
<id>urn:sha1:a2ee41fd953e7c3ff6c55a3038c80354d191a318</id>
<content type='text'>
One layout supported by the Marvell NAND controller supports NAND pages
of 2048 bytes, all handled in one single chunk when using BCH with a
strength of 4-bit per 512 bytes. In this case, instead of the generic
XTYPE_WRITE_DISPATCH/XTYPE_LAST_NAKED_RW couple, the controller expects
to receive XTYPE_MONOLITHIC_RW.

This fixes problems at boot like:

[    1.315475] Scanning device for bad blocks
[    3.203108] marvell-nfc f10d0000.flash: Timeout waiting for RB signal
[    3.209564] nand_bbt: error while writing BBT block -110
[    4.243106] marvell-nfc f10d0000.flash: Timeout waiting for RB signal
[    5.283106] marvell-nfc f10d0000.flash: Timeout waiting for RB signal
[    5.289562] nand_bbt: error -110 while marking block 2047 bad
[    6.323106] marvell-nfc f10d0000.flash: Timeout waiting for RB signal
[    6.329559] nand_bbt: error while writing BBT block -110
[    7.363106] marvell-nfc f10d0000.flash: Timeout waiting for RB signal
[    8.403105] marvell-nfc f10d0000.flash: Timeout waiting for RB signal
[    8.409559] nand_bbt: error -110 while marking block 2046 bad
...

Fixes: 02f26ecf8c772 ("mtd: nand: add reworked Marvell NAND controller driver")
Cc: stable@vger.kernel.org
Signed-off-by: Miquel Raynal &lt;miquel.raynal@bootlin.com&gt;
Tested-by: Chris Packham &lt;chris.packham@alliedtelesis.co.nz&gt;
Signed-off-by: Boris Brezillon &lt;boris.brezillon@bootlin.com&gt;
</content>
</entry>
<entry>
<title>mtd: rawnand: marvell: pass ms delay to wait_op</title>
<updated>2018-05-04T08:33:28+00:00</updated>
<author>
<name>Chris Packham</name>
<email>chris.packham@alliedtelesis.co.nz</email>
</author>
<published>2018-05-03T02:21:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b76401fc4ba720f0f38f7b1f9d54d5c2308bc18d'/>
<id>urn:sha1:b76401fc4ba720f0f38f7b1f9d54d5c2308bc18d</id>
<content type='text'>
marvell_nfc_wait_op() expects the delay to be expressed in milliseconds
but nand_sdr_timings uses picoseconds. Use PSEC_TO_MSEC when passing
tPROG_max to marvell_nfc_wait_op().

Fixes: 02f26ecf8c772 ("mtd: nand: add reworked Marvell NAND controller driver")
Cc: stable@vger.kernel.org
Signed-off-by: Chris Packham &lt;chris.packham@alliedtelesis.co.nz&gt;
Reviewed-by: Miquel Raynal &lt;miquel.raynal@bootlin.com&gt;
Signed-off-by: Boris Brezillon &lt;boris.brezillon@bootlin.com&gt;
</content>
</entry>
<entry>
<title>mtd: onenand: omap2: Disable DMA for HIGHMEM buffers</title>
<updated>2018-05-02T13:17:18+00:00</updated>
<author>
<name>Ladislav Michl</name>
<email>ladis@linux-mips.org</email>
</author>
<published>2018-05-02T10:41:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6732cfd4cac514b556f36b518670af91c8bdf19a'/>
<id>urn:sha1:6732cfd4cac514b556f36b518670af91c8bdf19a</id>
<content type='text'>
dma_map_single does not work for vmalloc-ed buffers,
so disable DMA in this case.

Signed-off-by: Ladislav Michl &lt;ladis@linux-mips.org&gt;
Reported-by: "H. Nikolaus Schaller" &lt;hns@goldelico.com&gt;
Tested-by: "H. Nikolaus Schaller" &lt;hns@goldelico.com&gt;
Reviewed-by: Peter Ujfalusi &lt;peter.ujfalusi@ti.com&gt;
Signed-off-by: Boris Brezillon &lt;boris.brezillon@bootlin.com&gt;
</content>
</entry>
<entry>
<title>mtd: rawnand: marvell: fix the chip-select DT parsing logic</title>
<updated>2018-04-26T17:06:42+00:00</updated>
<author>
<name>Miquel Raynal</name>
<email>miquel.raynal@bootlin.com</email>
</author>
<published>2018-04-25T14:16:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f6997bec6af43396ff530caee79e178d32774a49'/>
<id>urn:sha1:f6997bec6af43396ff530caee79e178d32774a49</id>
<content type='text'>
The block responsible of parsing the DT for the number of chip-select
lines uses an 'if/else if/else if' block. The content of the second and
third 'else if' conditions are:
        1/ the actual condition to enter the sub-block and
        2/ the operation to do in this sub-block.

        [...]
        else if (condition1_to_enter &amp;&amp; action1() == failed)
                raise_error();
        else if (condition2_to_enter &amp;&amp; action2() == failed)
                raise_error();
        [...]

In case of failure, the sub-block is entered and an error raised.
Otherwise, in case of success, the code would continue erroneously in
the next 'else if' statement because it did not failed (and did not
enter the first 'else if' sub-block).

The first 'else if' refers to legacy bindings while the second 'else if'
refers to new bindings. The second 'else if', which is entered
erroneously, checks for the 'reg' property, which, for old bindings,
does not mean anything because it would not be the number of CS
available, but the regular register map of almost any DT node. This
being said, the content of the 'reg' property being the register map
offset and length, it has '2' values, so the number of CS in this
situation is assumed to be '2'.

When running nand_scan_ident() with 2 CS, the core will check for an
array of chips. It will first issue a RESET and then a READ_ID. Of
course this will trigger two timeouts because there is no chip in front
of the second CS:

[    1.367460] marvell-nfc f2720000.nand: Timeout on CMDD (NDSR: 0x00000080)
[    1.474292] marvell-nfc f2720000.nand: Timeout on CMDD (NDSR: 0x00000280)

Indeed, this is harmless and the core will then assume there is only one
valid CS.

Fix the logic in the whole block by entering each sub-block just on the
'is legacy' condition, doing the action inside the sub-block. This way,
when the action succeeds, the whole block is left.

Furthermore, for both the old bindings and the new bindings the same
logic was applied to retrieve the number of CS lines:
using of_get_property() to get a size in bytes, converted in the actual
number of lines by dividing it per sizeof(u32) (4 bytes).

This is fine for the 'reg' property which is a list of the CS IDs but
not for the 'num-cs' property which is directly the value of the number
of CS.

Anyway, no existing DT uses another value than 'num-cs = &lt;1&gt;' and no
other value has ever been supported by the old driver (pxa3xx_nand.c).
Remove this condition and apply a number of 1 CS anyway, as already
described in the bindings.

Finally, the 'reg' property of a 'nand' node (with the new bindings)
gives the IDs of each CS line in use. marvell_nand.c driver first look
at the number of CS lines that are present in this property.

Better use of_property_count_elems_of_size() than dividing by 4 the size
of the number of bytes returned by of_get_property().

Fixes: 02f26ecf8c772 ("mtd: nand: add reworked Marvell NAND controller driver")
Cc: stable@vger.kernel.org
Signed-off-by: Miquel Raynal &lt;miquel.raynal@bootlin.com&gt;
Tested-by: Chris Packham &lt;chris.packham@alliedtelesis.co.nz&gt;
Signed-off-by: Boris Brezillon &lt;boris.brezillon@bootlin.com&gt;
</content>
</entry>
<entry>
<title>mtd: cfi: cmdset_0002: Do not allow read/write to suspend erase block.</title>
<updated>2018-04-24T15:42:15+00:00</updated>
<author>
<name>Joakim Tjernlund</name>
<email>joakim.tjernlund@infinera.com</email>
</author>
<published>2018-03-01T13:39:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7b70eb14392a7cf505f9b358d06c33b5af73d1e7'/>
<id>urn:sha1:7b70eb14392a7cf505f9b358d06c33b5af73d1e7</id>
<content type='text'>
Currently it is possible to read and/or write to suspend EB's.
Writing /dev/mtdX or /dev/mtdblockX from several processes may
break the flash state machine.

Taken from cfi_cmdset_0001 driver.

Signed-off-by: Joakim Tjernlund &lt;joakim.tjernlund@infinera.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Reviewed-by: Richard Weinberger &lt;richard@nod.at&gt;
Signed-off-by: Boris Brezillon &lt;boris.brezillon@bootlin.com&gt;
</content>
</entry>
<entry>
<title>mtd: cfi: cmdset_0001: Workaround Micron Erase suspend bug.</title>
<updated>2018-04-24T15:42:06+00:00</updated>
<author>
<name>Joakim Tjernlund</name>
<email>joakim.tjernlund@transmode.se</email>
</author>
<published>2018-03-01T13:39:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=46a16a2283f9e678a4e26829175e0c37a5191860'/>
<id>urn:sha1:46a16a2283f9e678a4e26829175e0c37a5191860</id>
<content type='text'>
Some Micron chips does not work well wrt Erase suspend for
boot blocks. This avoids the issue by not allowing Erase suspend
for the boot blocks for the 28F00AP30(1GBit) chip.

Signed-off-by: Joakim Tjernlund &lt;joakim.tjernlund@infinera.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Reviewed-by: Richard Weinberger &lt;richard@nod.at&gt;
Signed-off-by: Boris Brezillon &lt;boris.brezillon@bootlin.com&gt;
</content>
</entry>
<entry>
<title>mtd: cfi: cmdset_0001: Do not allow read/write to suspend erase block.</title>
<updated>2018-04-24T15:41:18+00:00</updated>
<author>
<name>Joakim Tjernlund</name>
<email>joakim.tjernlund@transmode.se</email>
</author>
<published>2018-03-01T13:39:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6510bbc88e3258631831ade49033537081950605'/>
<id>urn:sha1:6510bbc88e3258631831ade49033537081950605</id>
<content type='text'>
Currently it is possible to read and/or write to suspend EB's.
Writing /dev/mtdX or /dev/mtdblockX from several processes may
break the flash state machine.

Signed-off-by: Joakim Tjernlund &lt;joakim.tjernlund@infinera.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Reviewed-by: Richard Weinberger &lt;richard@nod.at&gt;
Signed-off-by: Boris Brezillon &lt;boris.brezillon@bootlin.com&gt;
</content>
</entry>
<entry>
<title>mtd: spi-nor: cadence-quadspi: Fix page fault kernel panic</title>
<updated>2018-04-23T19:42:56+00:00</updated>
<author>
<name>Thor Thayer</name>
<email>thor.thayer@linux.intel.com</email>
</author>
<published>2018-04-23T17:45:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=47016b341fc3b3fd4909e058c6fa38f165b53646'/>
<id>urn:sha1:47016b341fc3b3fd4909e058c6fa38f165b53646</id>
<content type='text'>
The current Cadence QSPI driver caused a kernel panic when loading
a Root Filesystem from QSPI. The problem was caused by reading more
bytes than needed because the QSPI operated on 4 bytes at a time.
&lt;snip&gt;
[    7.947754] spi_nor_read[1048]:from 0x037cad74, len 1 [bfe07fff]
[    7.956247] cqspi_read[910]:offset 0x58502516, buffer=bfe07fff
[    7.956247]
[    7.966046] Unable to handle kernel paging request at virtual
address bfe08002
[    7.973239] pgd = eebfc000
[    7.975931] [bfe08002] *pgd=2fffb811, *pte=00000000, *ppte=00000000
&lt;/snip&gt;
Notice above how only 1 byte needed to be read but by reading 4 bytes
into the end of a mapped page, an unrecoverable page fault occurred.

This patch uses a temporary buffer to hold the 4 bytes read and then
copies only the bytes required into the buffer. A min() function is
used to limit the length to prevent buffer overflows.

Request testing of this patch on other platforms. This was tested
on the Intel Arria10 SoCFPGA DevKit.

Fixes: 0cf1725676a97fc8 ("mtd: spi-nor: cqspi: Fix build on arches missing readsl/writesl")
Signed-off-by: Thor Thayer &lt;thor.thayer@linux.intel.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Reviewed-by: Marek Vasut &lt;marek.vasut@gmail.com&gt;
Signed-off-by: Boris Brezillon &lt;boris.brezillon@bootlin.com&gt;
</content>
</entry>
</feed>
