* [PATCH v5 08/19] mtd: spi-nor: sfdp: get command opcode extension type from BFPT
From: Pratyush Yadav @ 2020-05-19 14:26 UTC (permalink / raw)
To: Tudor Ambarus, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Mark Brown, Nicolas Ferre, Alexandre Belloni,
Ludovic Desroches, Matthias Brugger, linux-mtd, linux-kernel,
linux-spi, linux-arm-kernel, linux-mediatek
Cc: Mason Yang, Boris Brezillon, Sekhar Nori, Pratyush Yadav
In-Reply-To: <20200519142642.24131-1-p.yadav@ti.com>
Some devices in DTR mode expect an extra command byte called the
extension. The extension can either be same as the opcode, bitwise
inverse of the opcode, or another additional byte forming a 16-byte
opcode. Get the extension type from the BFPT. For now, only flashes with
"repeat" and "inverse" extensions are supported.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
---
drivers/mtd/spi-nor/sfdp.c | 17 +++++++++++++++++
drivers/mtd/spi-nor/sfdp.h | 6 ++++++
2 files changed, 23 insertions(+)
diff --git a/drivers/mtd/spi-nor/sfdp.c b/drivers/mtd/spi-nor/sfdp.c
index 96960f2f3d7a..ab086aa4746f 100644
--- a/drivers/mtd/spi-nor/sfdp.c
+++ b/drivers/mtd/spi-nor/sfdp.c
@@ -609,6 +609,23 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,
if (bfpt_header->length == BFPT_DWORD_MAX_JESD216B)
return spi_nor_post_bfpt_fixups(nor, bfpt_header, &bfpt,
params);
+ /* 8D-8D-8D command extension. */
+ switch (bfpt.dwords[BFPT_DWORD(18)] & BFPT_DWORD18_CMD_EXT_MASK) {
+ case BFPT_DWORD18_CMD_EXT_REP:
+ nor->cmd_ext_type = SPI_NOR_EXT_REPEAT;
+ break;
+
+ case BFPT_DWORD18_CMD_EXT_INV:
+ nor->cmd_ext_type = SPI_NOR_EXT_INVERT;
+ break;
+
+ case BFPT_DWORD18_CMD_EXT_RES:
+ return -EINVAL;
+
+ case BFPT_DWORD18_CMD_EXT_16B:
+ dev_err(nor->dev, "16-bit opcodes not supported\n");
+ return -ENOTSUPP;
+ }
return spi_nor_post_bfpt_fixups(nor, bfpt_header, &bfpt, params);
}
diff --git a/drivers/mtd/spi-nor/sfdp.h b/drivers/mtd/spi-nor/sfdp.h
index f8198af43a63..e15e30796d62 100644
--- a/drivers/mtd/spi-nor/sfdp.h
+++ b/drivers/mtd/spi-nor/sfdp.h
@@ -84,6 +84,12 @@ struct sfdp_bfpt {
#define BFPT_DWORD15_QER_SR2_BIT1_NO_RD (0x4UL << 20)
#define BFPT_DWORD15_QER_SR2_BIT1 (0x5UL << 20) /* Spansion */
+#define BFPT_DWORD18_CMD_EXT_MASK GENMASK(30, 29)
+#define BFPT_DWORD18_CMD_EXT_REP (0x0UL << 29) /* Repeat */
+#define BFPT_DWORD18_CMD_EXT_INV (0x1UL << 29) /* Invert */
+#define BFPT_DWORD18_CMD_EXT_RES (0x2UL << 29) /* Reserved */
+#define BFPT_DWORD18_CMD_EXT_16B (0x3UL << 29) /* 16-bit opcode */
+
struct sfdp_parameter_header {
u8 id_lsb;
u8 minor;
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 09/19] mtd: spi-nor: sfdp: parse xSPI Profile 1.0 table
From: Pratyush Yadav @ 2020-05-19 14:26 UTC (permalink / raw)
To: Tudor Ambarus, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Mark Brown, Nicolas Ferre, Alexandre Belloni,
Ludovic Desroches, Matthias Brugger, linux-mtd, linux-kernel,
linux-spi, linux-arm-kernel, linux-mediatek
Cc: Mason Yang, Boris Brezillon, Sekhar Nori, Pratyush Yadav
In-Reply-To: <20200519142642.24131-1-p.yadav@ti.com>
This table is indication that the flash is xSPI compliant and hence
supports octal DTR mode. Extract information like the fast read opcode,
the number of dummy cycles needed for a Read Status Register command,
and the number of address bytes needed for a Read Status Register
command.
The default dummy cycles for a fast octal DTR read are set to 20. Since
there is no simple way of determining the dummy cycles needed for the
fast read command, flashes that use a different value should update it
in their flash-specific hooks.
Since we want to set read settings, expose spi_nor_set_read_settings()
in core.h.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
---
drivers/mtd/spi-nor/core.c | 2 +-
drivers/mtd/spi-nor/core.h | 10 ++++++
drivers/mtd/spi-nor/sfdp.c | 73 ++++++++++++++++++++++++++++++++++++++
3 files changed, 84 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index 388e695e763f..642e3c07acf9 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -2355,7 +2355,7 @@ static int spi_nor_check(struct spi_nor *nor)
return 0;
}
-static void
+void
spi_nor_set_read_settings(struct spi_nor_read_command *read,
u8 num_mode_clocks,
u8 num_wait_states,
diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
index de1e3917889f..7e6df8322da0 100644
--- a/drivers/mtd/spi-nor/core.h
+++ b/drivers/mtd/spi-nor/core.h
@@ -192,6 +192,9 @@ struct spi_nor_locking_ops {
*
* @size: the flash memory density in bytes.
* @page_size: the page size of the SPI NOR flash memory.
+ * @rdsr_dummy: dummy cycles needed for Read Status Register command.
+ * @rdsr_addr_nbytes: dummy address bytes needed for Read Status Register
+ * command.
* @hwcaps: describes the read and page program hardware
* capabilities.
* @reads: read capabilities ordered by priority: the higher index
@@ -214,6 +217,8 @@ struct spi_nor_locking_ops {
struct spi_nor_flash_parameter {
u64 size;
u32 page_size;
+ u8 rdsr_dummy;
+ u8 rdsr_addr_nbytes;
struct spi_nor_hwcaps hwcaps;
struct spi_nor_read_command reads[SNOR_CMD_READ_MAX];
@@ -424,6 +429,11 @@ ssize_t spi_nor_write_data(struct spi_nor *nor, loff_t to, size_t len,
int spi_nor_hwcaps_read2cmd(u32 hwcaps);
u8 spi_nor_convert_3to4_read(u8 opcode);
+void spi_nor_set_read_settings(struct spi_nor_read_command *read,
+ u8 num_mode_clocks,
+ u8 num_wait_states,
+ u8 opcode,
+ enum spi_nor_protocol proto);
void spi_nor_set_pp_settings(struct spi_nor_pp_command *pp, u8 opcode,
enum spi_nor_protocol proto);
diff --git a/drivers/mtd/spi-nor/sfdp.c b/drivers/mtd/spi-nor/sfdp.c
index ab086aa4746f..4e5e0eabe2d9 100644
--- a/drivers/mtd/spi-nor/sfdp.c
+++ b/drivers/mtd/spi-nor/sfdp.c
@@ -4,6 +4,7 @@
* Copyright (C) 2014, Freescale Semiconductor, Inc.
*/
+#include <linux/bitfield.h>
#include <linux/slab.h>
#include <linux/sort.h>
#include <linux/mtd/spi-nor.h>
@@ -19,12 +20,14 @@
#define SFDP_BFPT_ID 0xff00 /* Basic Flash Parameter Table */
#define SFDP_SECTOR_MAP_ID 0xff81 /* Sector Map Table */
#define SFDP_4BAIT_ID 0xff84 /* 4-byte Address Instruction Table */
+#define SFDP_PROFILE1_ID 0xff05 /* xSPI Profile 1.0 table. */
#define SFDP_SIGNATURE 0x50444653U
#define SFDP_JESD216_MAJOR 1
#define SFDP_JESD216_MINOR 0
#define SFDP_JESD216A_MINOR 5
#define SFDP_JESD216B_MINOR 6
+#define SFDP_JESD216D_MINOR 8
struct sfdp_header {
u32 signature; /* Ox50444653U <=> "SFDP" */
@@ -70,6 +73,11 @@ struct sfdp_bfpt_erase {
u32 shift;
};
+/* xSPI Profile 1.0 table (from JESD216D.01). */
+#define PROFILE1_DWORD1_RD_FAST_CMD GENMASK(15, 8)
+#define PROFILE1_DWORD1_RDSR_DUMMY BIT(28)
+#define PROFILE1_DWORD1_RDSR_ADDR_BYTES BIT(29)
+
#define SMPT_CMD_ADDRESS_LEN_MASK GENMASK(23, 22)
#define SMPT_CMD_ADDRESS_LEN_0 (0x0UL << 22)
#define SMPT_CMD_ADDRESS_LEN_3 (0x1UL << 22)
@@ -1110,6 +1118,67 @@ static int spi_nor_parse_4bait(struct spi_nor *nor,
return ret;
}
+/**
+ * spi_nor_parse_profile1() - parse the xSPI Profile 1.0 table
+ * @nor: pointer to a 'struct spi_nor'
+ * @param_header: pointer to the 'struct sfdp_parameter_header' describing
+ * the 4-Byte Address Instruction Table length and version.
+ * @params: pointer to the 'struct spi_nor_flash_parameter' to be.
+ *
+ * Return: 0 on success, -errno otherwise.
+ */
+static int spi_nor_parse_profile1(struct spi_nor *nor,
+ const struct sfdp_parameter_header *profile1_header,
+ struct spi_nor_flash_parameter *params)
+{
+ u32 *table, opcode, addr;
+ size_t len;
+ int ret, i;
+
+ len = profile1_header->length * sizeof(*table);
+ table = kmalloc(len, GFP_KERNEL);
+ if (!table)
+ return -ENOMEM;
+
+ addr = SFDP_PARAM_HEADER_PTP(profile1_header);
+ ret = spi_nor_read_sfdp(nor, addr, len, table);
+ if (ret)
+ goto out;
+
+ /* Fix endianness of the table DWORDs. */
+ for (i = 0; i < profile1_header->length; i++)
+ table[i] = le32_to_cpu(table[i]);
+
+ /* Get 8D-8D-8D fast read opcode and dummy cycles. */
+ opcode = FIELD_GET(PROFILE1_DWORD1_RD_FAST_CMD, table[0]);
+
+ /*
+ * Update the fast read settings. We set the default dummy cycles to 20
+ * here. Flashes can change this value if they need to when enabling
+ * octal mode.
+ */
+ spi_nor_set_read_settings(¶ms->reads[SNOR_CMD_READ_8_8_8_DTR],
+ 0, 20, opcode,
+ SNOR_PROTO_8_8_8_DTR);
+
+ /*
+ * Set the Read Status Register dummy cycles and dummy address bytes.
+ */
+ if (table[0] & PROFILE1_DWORD1_RDSR_DUMMY)
+ params->rdsr_dummy = 8;
+ else
+ params->rdsr_dummy = 4;
+
+ if (table[0] & PROFILE1_DWORD1_RDSR_ADDR_BYTES)
+ params->rdsr_addr_nbytes = 4;
+ else
+ params->rdsr_addr_nbytes = 0;
+
+out:
+ kfree(table);
+ return ret;
+}
+
/**
* spi_nor_parse_sfdp() - parse the Serial Flash Discoverable Parameters.
* @nor: pointer to a 'struct spi_nor'
@@ -1211,6 +1280,10 @@ int spi_nor_parse_sfdp(struct spi_nor *nor,
err = spi_nor_parse_4bait(nor, param_header, params);
break;
+ case SFDP_PROFILE1_ID:
+ err = spi_nor_parse_profile1(nor, param_header, params);
+ break;
+
default:
break;
}
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 10/19] mtd: spi-nor: core: use dummy cycle and address width info from SFDP
From: Pratyush Yadav @ 2020-05-19 14:26 UTC (permalink / raw)
To: Tudor Ambarus, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Mark Brown, Nicolas Ferre, Alexandre Belloni,
Ludovic Desroches, Matthias Brugger, linux-mtd, linux-kernel,
linux-spi, linux-arm-kernel, linux-mediatek
Cc: Mason Yang, Boris Brezillon, Sekhar Nori, Pratyush Yadav
In-Reply-To: <20200519142642.24131-1-p.yadav@ti.com>
The xSPI Profile 1.0 table specifies how many dummy cycles and address
bytes are needed for the Read Status Register command in octal DTR mode.
Use that information to send the correct Read SR command.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
---
drivers/mtd/spi-nor/core.c | 25 +++++++++++++++++++++++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index 642e3c07acf9..2ad248140b6c 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -357,6 +357,8 @@ int spi_nor_write_disable(struct spi_nor *nor)
static int spi_nor_read_sr(struct spi_nor *nor, u8 *sr)
{
int ret;
+ u8 addr_bytes = nor->params->rdsr_addr_nbytes;
+ u8 dummy = nor->params->rdsr_dummy;
if (nor->spimem) {
struct spi_mem_op op =
@@ -365,10 +367,21 @@ static int spi_nor_read_sr(struct spi_nor *nor, u8 *sr)
SPI_MEM_OP_NO_DUMMY,
SPI_MEM_OP_DATA_IN(1, sr, 1));
+ if (spi_nor_protocol_is_dtr(nor->reg_proto)) {
+ op.addr.nbytes = addr_bytes;
+ op.addr.val = 0;
+ op.dummy.nbytes = dummy;
+ }
+
+ spi_nor_spimem_setup_op(nor, &op, nor->reg_proto);
+
ret = spi_mem_exec_op(nor->spimem, &op);
} else {
- ret = nor->controller_ops->read_reg(nor, SPINOR_OP_RDSR,
- sr, 1);
+ if (spi_nor_protocol_is_dtr(nor->reg_proto))
+ ret = -ENOTSUPP;
+ else
+ ret = nor->controller_ops->read_reg(nor, SPINOR_OP_RDSR,
+ sr, 1);
}
if (ret)
@@ -388,6 +401,8 @@ static int spi_nor_read_sr(struct spi_nor *nor, u8 *sr)
static int spi_nor_read_fsr(struct spi_nor *nor, u8 *fsr)
{
int ret;
+ u8 addr_bytes = nor->params->rdsr_addr_nbytes;
+ u8 dummy = nor->params->rdsr_dummy;
if (nor->spimem) {
struct spi_mem_op op =
@@ -396,6 +411,12 @@ static int spi_nor_read_fsr(struct spi_nor *nor, u8 *fsr)
SPI_MEM_OP_NO_DUMMY,
SPI_MEM_OP_DATA_IN(1, fsr, 1));
+ if (spi_nor_protocol_is_dtr(nor->reg_proto)) {
+ op.addr.nbytes = addr_bytes;
+ op.addr.val = 0;
+ op.dummy.nbytes = dummy;
+ }
+
spi_nor_spimem_setup_op(nor, &op, nor->reg_proto);
ret = spi_mem_exec_op(nor->spimem, &op);
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 11/19] mtd: spi-nor: core: do 2 byte reads for SR and FSR in DTR mode
From: Pratyush Yadav @ 2020-05-19 14:26 UTC (permalink / raw)
To: Tudor Ambarus, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Mark Brown, Nicolas Ferre, Alexandre Belloni,
Ludovic Desroches, Matthias Brugger, linux-mtd, linux-kernel,
linux-spi, linux-arm-kernel, linux-mediatek
Cc: Mason Yang, Boris Brezillon, Sekhar Nori, Pratyush Yadav
In-Reply-To: <20200519142642.24131-1-p.yadav@ti.com>
Some controllers, like the cadence qspi controller, have trouble reading
only 1 byte in DTR mode. So, do 2 byte reads for SR and FSR commands in
DTR mode, and then discard the second byte.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
---
drivers/mtd/spi-nor/core.c | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index 2ad248140b6c..5cb7e391cd29 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -350,7 +350,7 @@ int spi_nor_write_disable(struct spi_nor *nor)
* spi_nor_read_sr() - Read the Status Register.
* @nor: pointer to 'struct spi_nor'.
* @sr: pointer to a DMA-able buffer where the value of the
- * Status Register will be written.
+ * Status Register will be written. Should be at least 2 bytes.
*
* Return: 0 on success, -errno otherwise.
*/
@@ -371,6 +371,11 @@ static int spi_nor_read_sr(struct spi_nor *nor, u8 *sr)
op.addr.nbytes = addr_bytes;
op.addr.val = 0;
op.dummy.nbytes = dummy;
+ /*
+ * We don't want to read only one byte in DTR mode. So,
+ * read 2 and then discard the second byte.
+ */
+ op.data.nbytes = 2;
}
spi_nor_spimem_setup_op(nor, &op, nor->reg_proto);
@@ -394,7 +399,8 @@ static int spi_nor_read_sr(struct spi_nor *nor, u8 *sr)
* spi_nor_read_fsr() - Read the Flag Status Register.
* @nor: pointer to 'struct spi_nor'
* @fsr: pointer to a DMA-able buffer where the value of the
- * Flag Status Register will be written.
+ * Flag Status Register will be written. Should be at least 2
+ * bytes.
*
* Return: 0 on success, -errno otherwise.
*/
@@ -415,6 +421,11 @@ static int spi_nor_read_fsr(struct spi_nor *nor, u8 *fsr)
op.addr.nbytes = addr_bytes;
op.addr.val = 0;
op.dummy.nbytes = dummy;
+ /*
+ * We don't want to read only one byte in DTR mode. So,
+ * read 2 and then discard the second byte.
+ */
+ op.data.nbytes = 2;
}
spi_nor_spimem_setup_op(nor, &op, nor->reg_proto);
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 12/19] mtd: spi-nor: core: enable octal DTR mode when possible
From: Pratyush Yadav @ 2020-05-19 14:26 UTC (permalink / raw)
To: Tudor Ambarus, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Mark Brown, Nicolas Ferre, Alexandre Belloni,
Ludovic Desroches, Matthias Brugger, linux-mtd, linux-kernel,
linux-spi, linux-arm-kernel, linux-mediatek
Cc: Mason Yang, Boris Brezillon, Sekhar Nori, Pratyush Yadav
In-Reply-To: <20200519142642.24131-1-p.yadav@ti.com>
Allow flashes to specify a hook to enable octal DTR mode. Use this hook
whenever possible to get optimal transfer speeds.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
---
drivers/mtd/spi-nor/core.c | 35 +++++++++++++++++++++++++++++++++++
drivers/mtd/spi-nor/core.h | 2 ++
2 files changed, 37 insertions(+)
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index 5cb7e391cd29..a94376344be5 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -3097,6 +3097,35 @@ static int spi_nor_init_params(struct spi_nor *nor)
return 0;
}
+/** spi_nor_octal_dtr_enable() - enable Octal DTR I/O if needed
+ * @nor: pointer to a 'struct spi_nor'
+ * @enable: whether to enable or disable Octal DTR
+ *
+ * Return: 0 on success, -errno otherwise.
+ */
+static int spi_nor_octal_dtr_enable(struct spi_nor *nor, bool enable)
+{
+ int ret;
+
+ if (!nor->params->octal_dtr_enable)
+ return 0;
+
+ if (!(nor->read_proto == SNOR_PROTO_8_8_8_DTR &&
+ nor->write_proto == SNOR_PROTO_8_8_8_DTR))
+ return 0;
+
+ ret = nor->params->octal_dtr_enable(nor, enable);
+ if (ret)
+ return ret;
+
+ if (enable)
+ nor->reg_proto = SNOR_PROTO_8_8_8_DTR;
+ else
+ nor->reg_proto = SNOR_PROTO_1_1_1;
+
+ return 0;
+}
+
/**
* spi_nor_quad_enable() - enable Quad I/O if needed.
* @nor: pointer to a 'struct spi_nor'
@@ -3136,6 +3165,12 @@ static int spi_nor_init(struct spi_nor *nor)
{
int err;
+ err = spi_nor_octal_dtr_enable(nor, true);
+ if (err) {
+ dev_dbg(nor->dev, "octal mode not supported\n");
+ return err;
+ }
+
err = spi_nor_quad_enable(nor);
if (err) {
dev_dbg(nor->dev, "quad mode not supported\n");
diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
index 7e6df8322da0..6338d32a0d77 100644
--- a/drivers/mtd/spi-nor/core.h
+++ b/drivers/mtd/spi-nor/core.h
@@ -203,6 +203,7 @@ struct spi_nor_locking_ops {
* higher index in the array, the higher priority.
* @erase_map: the erase map parsed from the SFDP Sector Map Parameter
* Table.
+ * @octal_dtr_enable: enables SPI NOR octal DTR mode.
* @quad_enable: enables SPI NOR quad mode.
* @set_4byte_addr_mode: puts the SPI NOR in 4 byte addressing mode.
* @convert_addr: converts an absolute address into something the flash
@@ -226,6 +227,7 @@ struct spi_nor_flash_parameter {
struct spi_nor_erase_map erase_map;
+ int (*octal_dtr_enable)(struct spi_nor *nor, bool enable);
int (*quad_enable)(struct spi_nor *nor);
int (*set_4byte_addr_mode)(struct spi_nor *nor, bool enable);
u32 (*convert_addr)(struct spi_nor *nor, u32 addr);
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 13/19] mtd: spi-nor: sfdp: do not make invalid quad enable fatal
From: Pratyush Yadav @ 2020-05-19 14:26 UTC (permalink / raw)
To: Tudor Ambarus, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Mark Brown, Nicolas Ferre, Alexandre Belloni,
Ludovic Desroches, Matthias Brugger, linux-mtd, linux-kernel,
linux-spi, linux-arm-kernel, linux-mediatek
Cc: Mason Yang, Boris Brezillon, Sekhar Nori, Pratyush Yadav
In-Reply-To: <20200519142642.24131-1-p.yadav@ti.com>
The Micron MT35XU512ABA flash does not support the quad enable bit. But
instead of programming the Quad Enable Require field to 000b ("Device
does not have a QE bit"), it is programmed to 111b ("Reserved").
While this is technically incorrect, it is not reason enough to abort
BFPT parsing. Instead, continue BFPT parsing assuming there is no quad
enable bit present.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
---
drivers/mtd/spi-nor/sfdp.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/mtd/spi-nor/sfdp.c b/drivers/mtd/spi-nor/sfdp.c
index 4e5e0eabe2d9..be9c6c3d6590 100644
--- a/drivers/mtd/spi-nor/sfdp.c
+++ b/drivers/mtd/spi-nor/sfdp.c
@@ -569,10 +569,6 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,
/* Quad Enable Requirements. */
switch (bfpt.dwords[BFPT_DWORD(15)] & BFPT_DWORD15_QER_MASK) {
- case BFPT_DWORD15_QER_NONE:
- params->quad_enable = NULL;
- break;
-
case BFPT_DWORD15_QER_SR2_BIT1_BUGGY:
/*
* Writing only one byte to the Status Register has the
@@ -609,8 +605,10 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,
params->quad_enable = spi_nor_sr2_bit1_quad_enable;
break;
+ case BFPT_DWORD15_QER_NONE:
default:
- return -EINVAL;
+ params->quad_enable = NULL;
+ break;
}
/* Stop here if JESD216 rev B. */
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 14/19] mtd: spi-nor: sfdp: detect Soft Reset sequence support from BFPT
From: Pratyush Yadav @ 2020-05-19 14:26 UTC (permalink / raw)
To: Tudor Ambarus, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Mark Brown, Nicolas Ferre, Alexandre Belloni,
Ludovic Desroches, Matthias Brugger, linux-mtd, linux-kernel,
linux-spi, linux-arm-kernel, linux-mediatek
Cc: Mason Yang, Boris Brezillon, Sekhar Nori, Pratyush Yadav
In-Reply-To: <20200519142642.24131-1-p.yadav@ti.com>
A Soft Reset sequence will return the flash to Power-on-Reset (POR)
state. It consists of two commands: Soft Reset Enable and Soft Reset.
Find out if the sequence is supported from BFPT DWORD 16.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
---
drivers/mtd/spi-nor/core.h | 1 +
drivers/mtd/spi-nor/sfdp.c | 4 ++++
drivers/mtd/spi-nor/sfdp.h | 2 ++
3 files changed, 7 insertions(+)
diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
index 6338d32a0d77..79ce952c0539 100644
--- a/drivers/mtd/spi-nor/core.h
+++ b/drivers/mtd/spi-nor/core.h
@@ -26,6 +26,7 @@ enum spi_nor_option_flags {
SNOR_F_HAS_SR_TB_BIT6 = BIT(11),
SNOR_F_HAS_4BIT_BP = BIT(12),
SNOR_F_HAS_SR_BP3_BIT6 = BIT(13),
+ SNOR_F_SOFT_RESET = BIT(14),
};
struct spi_nor_read_command {
diff --git a/drivers/mtd/spi-nor/sfdp.c b/drivers/mtd/spi-nor/sfdp.c
index be9c6c3d6590..490ece7b3d33 100644
--- a/drivers/mtd/spi-nor/sfdp.c
+++ b/drivers/mtd/spi-nor/sfdp.c
@@ -611,6 +611,10 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,
break;
}
+ /* Soft Reset support. */
+ if (bfpt.dwords[BFPT_DWORD(16)] & BFPT_DWORD16_SOFT_RST)
+ nor->flags |= SNOR_F_SOFT_RESET;
+
/* Stop here if JESD216 rev B. */
if (bfpt_header->length == BFPT_DWORD_MAX_JESD216B)
return spi_nor_post_bfpt_fixups(nor, bfpt_header, &bfpt,
diff --git a/drivers/mtd/spi-nor/sfdp.h b/drivers/mtd/spi-nor/sfdp.h
index e15e30796d62..d1d43ee09a0a 100644
--- a/drivers/mtd/spi-nor/sfdp.h
+++ b/drivers/mtd/spi-nor/sfdp.h
@@ -84,6 +84,8 @@ struct sfdp_bfpt {
#define BFPT_DWORD15_QER_SR2_BIT1_NO_RD (0x4UL << 20)
#define BFPT_DWORD15_QER_SR2_BIT1 (0x5UL << 20) /* Spansion */
+#define BFPT_DWORD16_SOFT_RST BIT(12)
+
#define BFPT_DWORD18_CMD_EXT_MASK GENMASK(30, 29)
#define BFPT_DWORD18_CMD_EXT_REP (0x0UL << 29) /* Repeat */
#define BFPT_DWORD18_CMD_EXT_INV (0x1UL << 29) /* Invert */
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 15/19] mtd: spi-nor: core: perform a Soft Reset on shutdown
From: Pratyush Yadav @ 2020-05-19 14:26 UTC (permalink / raw)
To: Tudor Ambarus, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Mark Brown, Nicolas Ferre, Alexandre Belloni,
Ludovic Desroches, Matthias Brugger, linux-mtd, linux-kernel,
linux-spi, linux-arm-kernel, linux-mediatek
Cc: Mason Yang, Boris Brezillon, Sekhar Nori, Pratyush Yadav
In-Reply-To: <20200519142642.24131-1-p.yadav@ti.com>
Perform a Soft Reset on shutdown on flashes that support it so that the
flash can be reset to its initial state and any configurations made by
spi-nor (given that they're only done in volatile registers) will be
reset. This will hand back the flash in pristine state for any further
operations on it.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
---
drivers/mtd/spi-nor/core.c | 42 +++++++++++++++++++++++++++++++++++++
include/linux/mtd/spi-nor.h | 2 ++
2 files changed, 44 insertions(+)
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index a94376344be5..68559386f6f8 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -40,6 +40,9 @@
#define SPI_NOR_MAX_ADDR_WIDTH 4
+#define SPI_NOR_SRST_SLEEP_MIN 200
+#define SPI_NOR_SRST_SLEEP_MAX 400
+
/**
* spi_nor_get_cmd_ext() - Get the command opcode extension based on the
* extension type.
@@ -3201,6 +3204,41 @@ static int spi_nor_init(struct spi_nor *nor)
return 0;
}
+static void spi_nor_soft_reset(struct spi_nor *nor)
+{
+ struct spi_mem_op op;
+ int ret;
+
+ op = (struct spi_mem_op)SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_SRSTEN, 8),
+ SPI_MEM_OP_NO_DUMMY,
+ SPI_MEM_OP_NO_ADDR,
+ SPI_MEM_OP_NO_DATA);
+ spi_nor_spimem_setup_op(nor, &op, SNOR_PROTO_8_8_8_DTR);
+ ret = spi_mem_exec_op(nor->spimem, &op);
+ if (ret) {
+ dev_warn(nor->dev, "Software reset failed: %d\n", ret);
+ return;
+ }
+
+ op = (struct spi_mem_op)SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_SRST, 8),
+ SPI_MEM_OP_NO_DUMMY,
+ SPI_MEM_OP_NO_ADDR,
+ SPI_MEM_OP_NO_DATA);
+ spi_nor_spimem_setup_op(nor, &op, SNOR_PROTO_8_8_8_DTR);
+ ret = spi_mem_exec_op(nor->spimem, &op);
+ if (ret) {
+ dev_warn(nor->dev, "Software reset failed: %d\n", ret);
+ return;
+ }
+
+ /*
+ * Software Reset is not instant, and the delay varies from flash to
+ * flash. Looking at a few flashes, most range somewhere below 100
+ * microseconds. So, sleep for a range of 200-400 us.
+ */
+ usleep_range(SPI_NOR_SRST_SLEEP_MIN, SPI_NOR_SRST_SLEEP_MAX);
+}
+
/* mtd resume handler */
static void spi_nor_resume(struct mtd_info *mtd)
{
@@ -3220,6 +3258,10 @@ void spi_nor_restore(struct spi_nor *nor)
if (nor->addr_width == 4 && !(nor->flags & SNOR_F_4B_OPCODES) &&
nor->flags & SNOR_F_BROKEN_RESET)
nor->params->set_4byte_addr_mode(nor, false);
+
+ if (nor->info->flags & SPI_NOR_OCTAL_DTR_READ &&
+ nor->flags & SNOR_F_SOFT_RESET)
+ spi_nor_soft_reset(nor);
}
EXPORT_SYMBOL_GPL(spi_nor_restore);
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index d251a5d02be2..06884a188315 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -51,6 +51,8 @@
#define SPINOR_OP_CLFSR 0x50 /* Clear flag status register */
#define SPINOR_OP_RDEAR 0xc8 /* Read Extended Address Register */
#define SPINOR_OP_WREAR 0xc5 /* Write Extended Address Register */
+#define SPINOR_OP_SRSTEN 0x66 /* Software Reset Enable */
+#define SPINOR_OP_SRST 0x99 /* Software Reset */
/* 4-byte address opcodes - used on Spansion and some Macronix flashes. */
#define SPINOR_OP_READ_4B 0x13 /* Read data bytes (low frequency) */
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 16/19] mtd: spi-nor: core: disable Octal DTR mode on suspend.
From: Pratyush Yadav @ 2020-05-19 14:26 UTC (permalink / raw)
To: Tudor Ambarus, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Mark Brown, Nicolas Ferre, Alexandre Belloni,
Ludovic Desroches, Matthias Brugger, linux-mtd, linux-kernel,
linux-spi, linux-arm-kernel, linux-mediatek
Cc: Mason Yang, Boris Brezillon, Sekhar Nori, Pratyush Yadav
In-Reply-To: <20200519142642.24131-1-p.yadav@ti.com>
On resume, the init procedure will be run that will re-enable it.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
---
drivers/mtd/spi-nor/core.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index 68559386f6f8..63ab588299f4 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -3239,6 +3239,23 @@ static void spi_nor_soft_reset(struct spi_nor *nor)
usleep_range(SPI_NOR_SRST_SLEEP_MIN, SPI_NOR_SRST_SLEEP_MAX);
}
+/* mtd suspend handler */
+static int spi_nor_suspend(struct mtd_info *mtd)
+{
+ struct spi_nor *nor = mtd_to_spi_nor(mtd);
+ struct device *dev = nor->dev;
+ int ret;
+
+ /* Disable octal DTR mode if we enabled it. */
+ ret = spi_nor_octal_dtr_enable(nor, false);
+ if (ret) {
+ dev_err(dev, "suspend() failed\n");
+ return ret;
+ }
+
+ return 0;
+}
+
/* mtd resume handler */
static void spi_nor_resume(struct mtd_info *mtd)
{
@@ -3432,6 +3449,7 @@ int spi_nor_scan(struct spi_nor *nor, const char *name,
mtd->size = nor->params->size;
mtd->_erase = spi_nor_erase;
mtd->_read = spi_nor_read;
+ mtd->_suspend = spi_nor_suspend;
mtd->_resume = spi_nor_resume;
if (nor->params->locking_ops) {
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 17/19] mtd: spi-nor: core: expose spi_nor_default_setup() in core.h
From: Pratyush Yadav @ 2020-05-19 14:26 UTC (permalink / raw)
To: Tudor Ambarus, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Mark Brown, Nicolas Ferre, Alexandre Belloni,
Ludovic Desroches, Matthias Brugger, linux-mtd, linux-kernel,
linux-spi, linux-arm-kernel, linux-mediatek
Cc: Mason Yang, Boris Brezillon, Sekhar Nori, Pratyush Yadav
In-Reply-To: <20200519142642.24131-1-p.yadav@ti.com>
Flashes might want to add a custom setup hook to configure the flash in
the proper mode for operation. But after that, they would still want to
run the default setup hook because it selects the read, program, and
erase operations. Since there is little point in repeating all that
code, expose the spi_nor_default_setup() in core.h to
manufacturer-specific files.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
---
drivers/mtd/spi-nor/core.c | 4 ++--
drivers/mtd/spi-nor/core.h | 3 +++
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index 63ab588299f4..30d9149fd17b 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -2790,8 +2790,8 @@ static int spi_nor_select_erase(struct spi_nor *nor)
return 0;
}
-static int spi_nor_default_setup(struct spi_nor *nor,
- const struct spi_nor_hwcaps *hwcaps)
+int spi_nor_default_setup(struct spi_nor *nor,
+ const struct spi_nor_hwcaps *hwcaps)
{
struct spi_nor_flash_parameter *params = nor->params;
u32 ignored_mask, shared_mask;
diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
index 79ce952c0539..d37a9b1d111f 100644
--- a/drivers/mtd/spi-nor/core.h
+++ b/drivers/mtd/spi-nor/core.h
@@ -452,6 +452,9 @@ int spi_nor_post_bfpt_fixups(struct spi_nor *nor,
const struct sfdp_bfpt *bfpt,
struct spi_nor_flash_parameter *params);
+int spi_nor_default_setup(struct spi_nor *nor,
+ const struct spi_nor_hwcaps *hwcaps);
+
static struct spi_nor __maybe_unused *mtd_to_spi_nor(struct mtd_info *mtd)
{
return mtd->priv;
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 18/19] mtd: spi-nor: spansion: add support for Cypress Semper flash
From: Pratyush Yadav @ 2020-05-19 14:26 UTC (permalink / raw)
To: Tudor Ambarus, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Mark Brown, Nicolas Ferre, Alexandre Belloni,
Ludovic Desroches, Matthias Brugger, linux-mtd, linux-kernel,
linux-spi, linux-arm-kernel, linux-mediatek
Cc: Mason Yang, Boris Brezillon, Sekhar Nori, Pratyush Yadav
In-Reply-To: <20200519142642.24131-1-p.yadav@ti.com>
The Cypress Semper flash is an xSPI compliant octal DTR flash. Add
support for using it in octal DTR mode.
The flash by default boots in a hybrid sector mode. But the sector map
table on the part I had was programmed incorrectly and the SMPT values
on the flash don't match the public datasheet. Specifically, in some
places erase type 3 was used instead of 4. In addition, the region sizes
were incorrect in some places. So, for testing I set CFR3N[3] to enable
uniform sector sizes. Since the uniform sector mode bit is a
non-volatile bit, this series does not change it to avoid making any
permanent changes to the flash configuration. The correct data to
implement a fixup is not available right now and will be done in a
follow-up patch if needed.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
---
drivers/mtd/spi-nor/spansion.c | 167 +++++++++++++++++++++++++++++++++
1 file changed, 167 insertions(+)
diff --git a/drivers/mtd/spi-nor/spansion.c b/drivers/mtd/spi-nor/spansion.c
index 88183eba8ac1..e5dc36b70e4e 100644
--- a/drivers/mtd/spi-nor/spansion.c
+++ b/drivers/mtd/spi-nor/spansion.c
@@ -8,6 +8,169 @@
#include "core.h"
+/* For Cypress flash. */
+#define SPINOR_OP_RD_ANY_REG 0x65 /* Read any register */
+#define SPINOR_OP_WR_ANY_REG 0x71 /* Write any register */
+#define SPINOR_REG_CYPRESS_CFR2V 0x00800003
+#define SPINOR_REG_CYPRESS_CFR2V_MEMLAT_11_24 0xb
+#define SPINOR_REG_CYPRESS_CFR3V 0x00800004
+#define SPINOR_REG_CYPRESS_CFR3V_PGSZ BIT(4) /* Page size. */
+#define SPINOR_REG_CYPRESS_CFR5V 0x00800006
+#define SPINOR_REG_CYPRESS_CFR5V_OCT_DTR_EN 0x3
+#define SPINOR_REG_CYPRESS_CFR5V_OCT_DTR_DS 0
+#define SPINOR_OP_CYPRESS_RD_FAST 0xee
+
+/**
+ * spi_nor_cypress_octal_dtr_enable() - Enable octal DTR on Cypress flashes.
+ * @nor: pointer to a 'struct spi_nor'
+ *
+ * This also sets the memory access latency cycles to 24 to allow the flash to
+ * run at up to 200MHz.
+ *
+ * Return: 0 on success, -errno otherwise.
+ */
+static int spi_nor_cypress_octal_dtr_enable(struct spi_nor *nor, bool enable)
+{
+ struct spi_mem_op op;
+ u8 *buf = nor->bouncebuf;
+ u8 addr_width;
+ int ret;
+
+ if (enable)
+ addr_width = 3;
+ else
+ addr_width = 4;
+
+ if (enable) {
+ /* Use 24 dummy cycles for memory array reads. */
+ ret = spi_nor_write_enable(nor);
+ if (ret)
+ return ret;
+
+ *buf = SPINOR_REG_CYPRESS_CFR2V_MEMLAT_11_24;
+ op = (struct spi_mem_op)
+ SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_WR_ANY_REG, 1),
+ SPI_MEM_OP_ADDR(addr_width,
+ SPINOR_REG_CYPRESS_CFR2V,
+ 1),
+ SPI_MEM_OP_NO_DUMMY,
+ SPI_MEM_OP_DATA_OUT(1, buf, 1));
+ ret = spi_mem_exec_op(nor->spimem, &op);
+ if (ret) {
+ dev_warn(nor->dev,
+ "failed to set default memory latency value: %d\n",
+ ret);
+ return ret;
+ }
+ ret = spi_nor_wait_till_ready(nor);
+ if (ret)
+ return ret;
+
+ nor->read_dummy = 24;
+ }
+
+ /* Set/unset the octal and DTR enable bits. */
+ ret = spi_nor_write_enable(nor);
+ if (ret)
+ return ret;
+
+ if (enable)
+ *buf = SPINOR_REG_CYPRESS_CFR5V_OCT_DTR_EN;
+ else
+ *buf = SPINOR_REG_CYPRESS_CFR5V_OCT_DTR_DS;
+ op = (struct spi_mem_op)
+ SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_WR_ANY_REG, 1),
+ SPI_MEM_OP_ADDR(addr_width,
+ SPINOR_REG_CYPRESS_CFR5V,
+ 1),
+ SPI_MEM_OP_NO_DUMMY,
+ SPI_MEM_OP_DATA_OUT(1, buf, 1));
+
+ if (!enable)
+ spi_nor_spimem_setup_op(nor, &op, SNOR_PROTO_8_8_8_DTR);
+
+ ret = spi_mem_exec_op(nor->spimem, &op);
+ if (ret) {
+ dev_warn(nor->dev, "Failed to enable octal DTR mode\n");
+ return ret;
+ }
+
+ return 0;
+}
+
+static void s28hs512t_default_init(struct spi_nor *nor)
+{
+ nor->params->octal_dtr_enable = spi_nor_cypress_octal_dtr_enable;
+}
+
+static void s28hs512t_post_sfdp_fixup(struct spi_nor *nor)
+{
+ /*
+ * On older versions of the flash the xSPI Profile 1.0 table has the
+ * 8D-8D-8D Fast Read opcode as 0x00. But it actually should be 0xEE.
+ */
+ if (nor->params->reads[SNOR_CMD_READ_8_8_8_DTR].opcode == 0)
+ nor->params->reads[SNOR_CMD_READ_8_8_8_DTR].opcode =
+ SPINOR_OP_CYPRESS_RD_FAST;
+
+ nor->params->hwcaps.mask |= SNOR_HWCAPS_PP_8_8_8_DTR;
+
+ /* This flash is also missing the 4-byte Page Program opcode bit. */
+ spi_nor_set_pp_settings(&nor->params->page_programs[SNOR_CMD_PP],
+ SPINOR_OP_PP_4B, SNOR_PROTO_1_1_1);
+ /*
+ * Since xSPI Page Program opcode is backward compatible with
+ * Legacy SPI, use Legacy SPI opcode there as well.
+ */
+ spi_nor_set_pp_settings(&nor->params->page_programs[SNOR_CMD_PP_8_8_8_DTR],
+ SPINOR_OP_PP_4B, SNOR_PROTO_8_8_8_DTR);
+
+ /*
+ * The xSPI Profile 1.0 table advertises the number of additional
+ * address bytes needed for Read Status Register command as 0 but the
+ * actual value for that is 4.
+ */
+ nor->params->rdsr_addr_nbytes = 4;
+}
+
+static int s28hs512t_post_bfpt_fixup(struct spi_nor *nor,
+ const struct sfdp_parameter_header *bfpt_header,
+ const struct sfdp_bfpt *bfpt,
+ struct spi_nor_flash_parameter *params)
+{
+ struct spi_mem_op op;
+ u8 *buf = nor->bouncebuf;
+ u8 addr_width = 3;
+ int ret;
+
+ /*
+ * The BFPT table advertises a 512B page size but the page size is
+ * actually configurable (with the default being 256B). Read from
+ * CFR3V[4] and set the correct size.
+ */
+ op = (struct spi_mem_op)
+ SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_RD_ANY_REG, 1),
+ SPI_MEM_OP_ADDR(addr_width, SPINOR_REG_CYPRESS_CFR3V, 1),
+ SPI_MEM_OP_NO_DUMMY,
+ SPI_MEM_OP_DATA_IN(1, buf, 1));
+ ret = spi_mem_exec_op(nor->spimem, &op);
+ if (ret)
+ return ret;
+
+ if (*buf & SPINOR_REG_CYPRESS_CFR3V_PGSZ)
+ params->page_size = 512;
+ else
+ params->page_size = 256;
+
+ return 0;
+}
+
+static struct spi_nor_fixups s28hs512t_fixups = {
+ .default_init = s28hs512t_default_init,
+ .post_sfdp = s28hs512t_post_sfdp_fixup,
+ .post_bfpt = s28hs512t_post_bfpt_fixup,
+};
+
static const struct flash_info spansion_parts[] = {
/* Spansion/Cypress -- single (large) sector size only, at least
* for the chips listed here (without boot sectors).
@@ -72,6 +235,10 @@ static const struct flash_info spansion_parts[] = {
{ "s25fl256l", INFO(0x016019, 0, 64 * 1024, 512,
SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
SPI_NOR_4B_OPCODES) },
+ { "s28hs512t", INFO(0x345b1a, 0, 256 * 1024, 256,
+ SECT_4K | SPI_NOR_OCTAL_DTR_READ)
+ .fixups = &s28hs512t_fixups,
+ },
};
static void spansion_post_sfdp_fixups(struct spi_nor *nor)
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 19/19] mtd: spi-nor: micron-st: allow using MT35XU512ABA in Octal DTR mode
From: Pratyush Yadav @ 2020-05-19 14:26 UTC (permalink / raw)
To: Tudor Ambarus, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Mark Brown, Nicolas Ferre, Alexandre Belloni,
Ludovic Desroches, Matthias Brugger, linux-mtd, linux-kernel,
linux-spi, linux-arm-kernel, linux-mediatek
Cc: Mason Yang, Boris Brezillon, Sekhar Nori, Pratyush Yadav
In-Reply-To: <20200519142642.24131-1-p.yadav@ti.com>
Since this flash doesn't have a Profile 1.0 table, the Octal DTR
capabilities are enabled in the post SFDP fixup, along with the 8D-8D-8D
fast read settings.
Enable Octal DTR mode with 20 dummy cycles to allow running at the
maximum supported frequency of 200Mhz.
The flash supports the soft reset sequence. So, add the flag in the
flash's info.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
---
drivers/mtd/spi-nor/micron-st.c | 112 +++++++++++++++++++++++++++++++-
1 file changed, 111 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/spi-nor/micron-st.c b/drivers/mtd/spi-nor/micron-st.c
index 3dca5b9af3b6..3414c44a5c96 100644
--- a/drivers/mtd/spi-nor/micron-st.c
+++ b/drivers/mtd/spi-nor/micron-st.c
@@ -8,10 +8,120 @@
#include "core.h"
+#define SPINOR_OP_MT_DTR_RD 0xfd /* Fast Read opcode in DTR mode */
+#define SPINOR_OP_MT_RD_ANY_REG 0x85 /* Read volatile register */
+#define SPINOR_OP_MT_WR_ANY_REG 0x81 /* Write volatile register */
+#define SPINOR_REG_MT_CFR0V 0x00 /* For setting octal DTR mode */
+#define SPINOR_REG_MT_CFR1V 0x01 /* For setting dummy cycles */
+#define SPINOR_MT_DTR_NO_DQS 0xc7 /* Enable Octal DTR without DQS. */
+#define SPINOR_MT_EXSPI 0xff /* Enable Extended SPI (default) */
+
+static int spi_nor_micron_octal_dtr_enable(struct spi_nor *nor, bool enable)
+{
+ struct spi_mem_op op;
+ u8 *buf = nor->bouncebuf;
+ u8 addr_width;
+ int ret;
+
+ if (enable)
+ addr_width = 3;
+ else
+ addr_width = 4;
+
+ ret = spi_nor_write_enable(nor);
+ if (ret)
+ return ret;
+
+ if (enable)
+ *buf = SPINOR_MT_DTR_NO_DQS;
+ else
+ *buf = SPINOR_MT_EXSPI;
+ op = (struct spi_mem_op)
+ SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_MT_WR_ANY_REG, 1),
+ SPI_MEM_OP_ADDR(addr_width, SPINOR_REG_MT_CFR0V, 1),
+ SPI_MEM_OP_NO_DUMMY,
+ SPI_MEM_OP_DATA_OUT(1, buf, 1));
+
+ if (!enable)
+ spi_nor_spimem_setup_op(nor, &op, SNOR_PROTO_8_8_8_DTR);
+
+ ret = spi_mem_exec_op(nor->spimem, &op);
+ if (ret) {
+ dev_err(nor->dev, "Failed to enable octal DTR mode\n");
+ return ret;
+ }
+
+ return 0;
+}
+
+static int mt35xu512aba_setup(struct spi_nor *nor,
+ const struct spi_nor_hwcaps *hwcaps)
+{
+ struct spi_mem_op op;
+ u8 *buf = nor->bouncebuf;
+ u8 addr_width = 3;
+ int ret;
+
+ if (!nor->spimem) {
+ dev_err(nor->dev,
+ "operation not supported for non-spimem drivers\n");
+ return -ENOTSUPP;
+ }
+
+ /* Set dummy cycles for Fast Read to the default of 20. */
+ ret = spi_nor_write_enable(nor);
+ if (ret)
+ return ret;
+
+ *buf = 20;
+ op = (struct spi_mem_op)
+ SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_MT_WR_ANY_REG, 1),
+ SPI_MEM_OP_ADDR(addr_width, SPINOR_REG_MT_CFR1V, 1),
+ SPI_MEM_OP_NO_DUMMY,
+ SPI_MEM_OP_DATA_OUT(1, buf, 1));
+ ret = spi_mem_exec_op(nor->spimem, &op);
+ if (ret)
+ return ret;
+
+ ret = spi_nor_wait_till_ready(nor);
+ if (ret)
+ return ret;
+
+
+ return spi_nor_default_setup(nor, hwcaps);
+}
+
+static void mt35xu512aba_default_init(struct spi_nor *nor)
+{
+ nor->params->octal_dtr_enable = spi_nor_micron_octal_dtr_enable;
+ nor->params->setup = mt35xu512aba_setup;
+}
+
+static void mt35xu512aba_post_sfdp_fixup(struct spi_nor *nor)
+{
+ /* Set the Fast Read settings. */
+ nor->params->hwcaps.mask |= SNOR_HWCAPS_READ_8_8_8_DTR;
+ spi_nor_set_read_settings(&nor->params->reads[SNOR_CMD_READ_8_8_8_DTR],
+ 0, 20, SPINOR_OP_MT_DTR_RD,
+ SNOR_PROTO_8_8_8_DTR);
+
+ nor->params->hwcaps.mask |= SNOR_HWCAPS_PP_8_8_8_DTR;
+
+ nor->cmd_ext_type = SPI_NOR_EXT_REPEAT;
+ nor->params->rdsr_dummy = 8;
+ nor->params->rdsr_addr_nbytes = 0;
+}
+
+static struct spi_nor_fixups mt35xu512aba_fixups = {
+ .default_init = mt35xu512aba_default_init,
+ .post_sfdp = mt35xu512aba_post_sfdp_fixup,
+};
+
static const struct flash_info micron_parts[] = {
{ "mt35xu512aba", INFO(0x2c5b1a, 0, 128 * 1024, 512,
SECT_4K | USE_FSR | SPI_NOR_OCTAL_READ |
- SPI_NOR_4B_OPCODES) },
+ SPI_NOR_4B_OPCODES | SPI_NOR_OCTAL_DTR_READ)
+ .fixups = &mt35xu512aba_fixups},
{ "mt35xu02g", INFO(0x2c5b1c, 0, 128 * 1024, 2048,
SECT_4K | USE_FSR | SPI_NOR_OCTAL_READ |
SPI_NOR_4B_OPCODES) },
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v6] ARM: boot: Obtain start of physical memory from DTB
From: Russell King - ARM Linux admin @ 2020-05-19 14:28 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Grant Likely, Arnd Bergmann, Nicolas Pitre, Masahiro Yamada,
Bartlomiej Zolnierkiewicz, Lukasz Stelmach,
Linux Kernel Mailing List, Linux-Renesas, Chris Brandt,
Rob Herring, Geert Uytterhoeven, Uwe Kleine-König, Eric Miao,
Dmitry Osipenko, Linux ARM, Marek Szyprowski
In-Reply-To: <CAMj1kXH_s4qjDfTO03PkGNaiwfjmfkrZ-FE8vTm74QSrgoVt0A@mail.gmail.com>
On Tue, May 19, 2020 at 03:56:59PM +0200, Ard Biesheuvel wrote:
> On Tue, 19 May 2020 at 13:21, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> >
> > Hi Russell,
> >
> > CC devicetree
> >
> > On Tue, May 19, 2020 at 11:46 AM Russell King - ARM Linux admin
> > <linux@armlinux.org.uk> wrote:
> > > On Tue, May 19, 2020 at 11:44:17AM +0200, Geert Uytterhoeven wrote:
> > > > On Tue, May 19, 2020 at 10:54 AM Lukasz Stelmach <l.stelmach@samsung.com> wrote:
> > > > > It was <2020-04-29 śro 10:21>, when Geert Uytterhoeven wrote:
> > > > > > Currently, the start address of physical memory is obtained by masking
> > > > > > the program counter with a fixed mask of 0xf8000000. This mask value
> > > > > > was chosen as a balance between the requirements of different platforms.
> > > > > > However, this does require that the start address of physical memory is
> > > > > > a multiple of 128 MiB, precluding booting Linux on platforms where this
> > > > > > requirement is not fulfilled.
> > > > > >
> > > > > > Fix this limitation by obtaining the start address from the DTB instead,
> > > > > > if available (either explicitly passed, or appended to the kernel).
> > > > > > Fall back to the traditional method when needed.
> > > > > >
> > > > > > This allows to boot Linux on r7s9210/rza2mevb using the 64 MiB of SDRAM
> > > > > > on the RZA2MEVB sub board, which is located at 0x0C000000 (CS3 space),
> > > > > > i.e. not at a multiple of 128 MiB.
> > > > > >
> > > > > > Suggested-by: Nicolas Pitre <nico@fluxnic.net>
> > > > > > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > > > > > Reviewed-by: Nicolas Pitre <nico@fluxnic.net>
> > > > > > Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
> > > > > > Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
> > > > > > Tested-by: Dmitry Osipenko <digetx@gmail.com>
> > > > > > ---
> > > > >
> > > > > [...]
> > > > >
> > > > > Apparently reading physical memory layout from DTB breaks crashdump
> > > > > kernels. A crashdump kernel is loaded into a region of memory, that is
> > > > > reserved in the original (i.e. to be crashed) kernel. The reserved
> > > > > region is large enough for the crashdump kernel to run completely inside
> > > > > it and don't modify anything outside it, just read and dump the remains
> > > > > of the crashed kernel. Using the information from DTB makes the
> > > > > decompressor place the kernel outside of the dedicated region.
> > > > >
> > > > > The log below shows that a zImage and DTB are loaded at 0x18eb8000 and
> > > > > 0x193f6000 (physical). The kernel is expected to run at 0x18008000, but
> > > > > it is decompressed to 0x00008000 (see r4 reported before jumping from
> > > > > within __enter_kernel). If I were to suggest something, there need to be
> > > > > one more bit of information passed in the DTB telling the decompressor
> > > > > to use the old masking technique to determain kernel address. It would
> > > > > be set in the DTB loaded along with the crashdump kernel.
> > > >
> > > > Shouldn't the DTB passed to the crashkernel describe which region of
> > > > memory is to be used instead?
> > >
> > > Definitely not. The crashkernel needs to know where the RAM in the
> > > machine is, so that it can create a coredump of the crashed kernel.
> >
> > So the DTB should describe both ;-)
> >
> > > > Describing "to use the old masking technique" sounds a bit hackish to me.
> > > > I guess it cannot just restrict the /memory node to the reserved region,
> > > > as the crashkernel needs to be able to dump the remains of the crashed
> > > > kernel, which lie outside this region.
> > >
> > > Correct.
> > >
> > > > However, something under /chosen should work.
> > >
> > > Yet another sticky plaster...
> >
> > IMHO the old masking technique is the hacky solution covered by
> > plasters.
> >
>
> I think debating which solution is the hacky one will not get us anywhere.
>
> The simple reality is that the existing solution works fine for
> existing platforms, and so any changes in the logic will have to be
> opt-in in one way or the other.
>
> Since U-boot supports EFI boot these days, one potential option is to
> rely on that. I have some changes implementing this that go on top of
> this patch, but they don't actually rely on it - it was just to
> prevent lexical conflicts.
>
> The only remaining options imo are a kernel command line option, or a
> DT property that tells the decompressor to look at the memory nodes.
> But using the DT memory nodes on all platforms like this patch does is
> obviously just too risky.
>
> On another note, I do think the usable-memory-region property should
> be implemented for ARM as well - relying on this rounding to ensure
> that the decompressor does the right thing is too fragile.
What is "too fragile" is trying to change this and expecting everything
to continue working as it did before.
How will switching to EFI help? Won't the crashdump kernel detect EFI
and try to get the memory map from EFI, whereby it runs into exactly
the same issue that the DT approach does?
The current crashkernel situation works precisely because of the 128M
masking that is being done.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] ARM: Implement functions for HAVE_FUNCTION_ARG_ACCESS_API
From: Andrew Jeffery @ 2020-05-19 14:31 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: linux-kernel, linux, oleg
This allows extraction of kernel function arguments via kprobes on ARM.
Based on the arm64 implementation and adapted for the 32-bit AAPCS.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
---
The description for HAVE_FUNCTION_ARG_ACCESS_API was pretty vague on what was
required. I've implemented enough to enable argument extraction for kprobes; is
there anything else needed to satisfy HAVE_FUNCTION_ARG_ACCESS_API?
arch/arm/Kconfig | 1 +
arch/arm/include/asm/ptrace.h | 24 ++++++++++++++++++++++++
2 files changed, 25 insertions(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index c77c93c485a0..d82f80845e03 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -82,6 +82,7 @@ config ARM
select HAVE_EXIT_THREAD
select HAVE_FAST_GUP if ARM_LPAE
select HAVE_FTRACE_MCOUNT_RECORD if !XIP_KERNEL
+ select HAVE_FUNCTION_ARG_ACCESS_API
select HAVE_FUNCTION_GRAPH_TRACER if !THUMB2_KERNEL && !CC_IS_CLANG
select HAVE_FUNCTION_TRACER if !XIP_KERNEL && (CC_IS_GCC || CLANG_VERSION >= 100000)
select HAVE_GCC_PLUGINS
diff --git a/arch/arm/include/asm/ptrace.h b/arch/arm/include/asm/ptrace.h
index 91d6b7856be4..71e7649deac9 100644
--- a/arch/arm/include/asm/ptrace.h
+++ b/arch/arm/include/asm/ptrace.h
@@ -149,6 +149,30 @@ static inline unsigned long regs_get_register(struct pt_regs *regs,
return *(unsigned long *)((unsigned long)regs + offset);
}
+/*
+ * Read a register given an architectural register index r.
+ */
+static inline unsigned long pt_regs_read_reg(const struct pt_regs *regs, int r)
+{
+ return regs->uregs[r];
+}
+
+/**
+ * regs_get_kernel_argument() - get Nth function argument in kernel
+ * @regs: pt_regs of that context
+ * @n: function argument number (start from 0)
+ *
+ * regs_get_argument() returns @n th argument of the function call.
+ */
+static inline unsigned long regs_get_kernel_argument(struct pt_regs *regs,
+ unsigned int n)
+{
+#define NR_REG_ARGUMENTS 4
+ if (n < NR_REG_ARGUMENTS)
+ return pt_regs_read_reg(regs, n);
+ return 0;
+}
+
/* Valid only for Kernel mode traps. */
static inline unsigned long kernel_stack_pointer(struct pt_regs *regs)
{
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v6] ARM: boot: Obtain start of physical memory from DTB
From: Ard Biesheuvel @ 2020-05-19 14:32 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Grant Likely, Arnd Bergmann, Nicolas Pitre, Masahiro Yamada,
Bartlomiej Zolnierkiewicz, Lukasz Stelmach,
Linux Kernel Mailing List, Linux-Renesas, Chris Brandt,
Rob Herring, Geert Uytterhoeven, Uwe Kleine-König, Eric Miao,
Dmitry Osipenko, Linux ARM, Marek Szyprowski
In-Reply-To: <20200519142854.GF1551@shell.armlinux.org.uk>
On Tue, 19 May 2020 at 16:29, Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
>
> On Tue, May 19, 2020 at 03:56:59PM +0200, Ard Biesheuvel wrote:
> > On Tue, 19 May 2020 at 13:21, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > >
> > > Hi Russell,
> > >
> > > CC devicetree
> > >
> > > On Tue, May 19, 2020 at 11:46 AM Russell King - ARM Linux admin
> > > <linux@armlinux.org.uk> wrote:
> > > > On Tue, May 19, 2020 at 11:44:17AM +0200, Geert Uytterhoeven wrote:
> > > > > On Tue, May 19, 2020 at 10:54 AM Lukasz Stelmach <l.stelmach@samsung.com> wrote:
> > > > > > It was <2020-04-29 śro 10:21>, when Geert Uytterhoeven wrote:
> > > > > > > Currently, the start address of physical memory is obtained by masking
> > > > > > > the program counter with a fixed mask of 0xf8000000. This mask value
> > > > > > > was chosen as a balance between the requirements of different platforms.
> > > > > > > However, this does require that the start address of physical memory is
> > > > > > > a multiple of 128 MiB, precluding booting Linux on platforms where this
> > > > > > > requirement is not fulfilled.
> > > > > > >
> > > > > > > Fix this limitation by obtaining the start address from the DTB instead,
> > > > > > > if available (either explicitly passed, or appended to the kernel).
> > > > > > > Fall back to the traditional method when needed.
> > > > > > >
> > > > > > > This allows to boot Linux on r7s9210/rza2mevb using the 64 MiB of SDRAM
> > > > > > > on the RZA2MEVB sub board, which is located at 0x0C000000 (CS3 space),
> > > > > > > i.e. not at a multiple of 128 MiB.
> > > > > > >
> > > > > > > Suggested-by: Nicolas Pitre <nico@fluxnic.net>
> > > > > > > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > > > > > > Reviewed-by: Nicolas Pitre <nico@fluxnic.net>
> > > > > > > Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
> > > > > > > Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
> > > > > > > Tested-by: Dmitry Osipenko <digetx@gmail.com>
> > > > > > > ---
> > > > > >
> > > > > > [...]
> > > > > >
> > > > > > Apparently reading physical memory layout from DTB breaks crashdump
> > > > > > kernels. A crashdump kernel is loaded into a region of memory, that is
> > > > > > reserved in the original (i.e. to be crashed) kernel. The reserved
> > > > > > region is large enough for the crashdump kernel to run completely inside
> > > > > > it and don't modify anything outside it, just read and dump the remains
> > > > > > of the crashed kernel. Using the information from DTB makes the
> > > > > > decompressor place the kernel outside of the dedicated region.
> > > > > >
> > > > > > The log below shows that a zImage and DTB are loaded at 0x18eb8000 and
> > > > > > 0x193f6000 (physical). The kernel is expected to run at 0x18008000, but
> > > > > > it is decompressed to 0x00008000 (see r4 reported before jumping from
> > > > > > within __enter_kernel). If I were to suggest something, there need to be
> > > > > > one more bit of information passed in the DTB telling the decompressor
> > > > > > to use the old masking technique to determain kernel address. It would
> > > > > > be set in the DTB loaded along with the crashdump kernel.
> > > > >
> > > > > Shouldn't the DTB passed to the crashkernel describe which region of
> > > > > memory is to be used instead?
> > > >
> > > > Definitely not. The crashkernel needs to know where the RAM in the
> > > > machine is, so that it can create a coredump of the crashed kernel.
> > >
> > > So the DTB should describe both ;-)
> > >
> > > > > Describing "to use the old masking technique" sounds a bit hackish to me.
> > > > > I guess it cannot just restrict the /memory node to the reserved region,
> > > > > as the crashkernel needs to be able to dump the remains of the crashed
> > > > > kernel, which lie outside this region.
> > > >
> > > > Correct.
> > > >
> > > > > However, something under /chosen should work.
> > > >
> > > > Yet another sticky plaster...
> > >
> > > IMHO the old masking technique is the hacky solution covered by
> > > plasters.
> > >
> >
> > I think debating which solution is the hacky one will not get us anywhere.
> >
> > The simple reality is that the existing solution works fine for
> > existing platforms, and so any changes in the logic will have to be
> > opt-in in one way or the other.
> >
> > Since U-boot supports EFI boot these days, one potential option is to
> > rely on that. I have some changes implementing this that go on top of
> > this patch, but they don't actually rely on it - it was just to
> > prevent lexical conflicts.
> >
> > The only remaining options imo are a kernel command line option, or a
> > DT property that tells the decompressor to look at the memory nodes.
> > But using the DT memory nodes on all platforms like this patch does is
> > obviously just too risky.
> >
> > On another note, I do think the usable-memory-region property should
> > be implemented for ARM as well - relying on this rounding to ensure
> > that the decompressor does the right thing is too fragile.
>
> What is "too fragile" is trying to change this and expecting everything
> to continue working as it did before.
>
That is my point.
> How will switching to EFI help? Won't the crashdump kernel detect EFI
> and try to get the memory map from EFI, whereby it runs into exactly
> the same issue that the DT approach does?
>
No. If you boot from kexec, then the EFI stub is completely
circumvented, and things work as before.
> The current crashkernel situation works precisely because of the 128M
> masking that is being done.
>
Indeed. That is precisely my point.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 21/23] coresight: etm4x: Fix use-after-free of per-cpu etm drvdata
From: Greg KH @ 2020-05-19 14:32 UTC (permalink / raw)
To: Mathieu Poirier; +Cc: linux-arm-kernel
In-Reply-To: <20200518180242.7916-22-mathieu.poirier@linaro.org>
On Mon, May 18, 2020 at 12:02:40PM -0600, Mathieu Poirier wrote:
> From: Suzuki K Poulose <suzuki.poulose@arm.com>
>
> etm probe could be deferred due to the dependency in the trace
> path chain and may be retried. We need to clear the per-cpu
> etmdrvdata entry for the etm in case of a failure to avoid
> use-after-free cases as reported below:
>
> KASAN use-after-free bug in etm4_cpu_pm_notify():
>
> [ 8.574566] coresight etm0: CPU0: ETM v4.2 initialized
> [ 8.581920] BUG: KASAN: use-after-free in etm4_cpu_pm_notify+0x580/0x2024
> [ 8.581925] Read of size 8 at addr ffffff813304f8c8 by task swapper/3/0
> [ 8.581927]
> [ 8.581934] CPU: 3 PID: 0 Comm: swapper/3 Tainted: G S W 5.4.28 #314
> [ 8.587775] coresight etm1: CPU1: ETM v4.2 initialized
> [ 8.594195] Call trace:
> [ 8.594205] dump_backtrace+0x0/0x188
> [ 8.594209] show_stack+0x20/0x2c
> [ 8.594216] dump_stack+0xdc/0x144
> [ 8.594227] print_address_description+0x3c/0x494
> [ 8.594232] __kasan_report+0x144/0x168
> [ 8.601598] coresight etm2: CPU2: ETM v4.2 initialized
> [ 8.602563] kasan_report+0x10/0x18
> [ 8.602568] check_memory_region+0x1a4/0x1b4
> [ 8.602572] __kasan_check_read+0x18/0x24
> [ 8.602577] etm4_cpu_pm_notify+0x580/0x2024
> [ 8.665945] notifier_call_chain+0x5c/0x90
> [ 8.670166] __atomic_notifier_call_chain+0x90/0xf8
> [ 8.675182] cpu_pm_notify+0x40/0x6c
> [ 8.678858] cpu_pm_enter+0x38/0x80
> [ 8.682451] psci_enter_idle_state+0x34/0x70
> [ 8.686844] cpuidle_enter_state+0xb8/0x20c
> [ 8.691143] cpuidle_enter+0x38/0x4c
> [ 8.694820] call_cpuidle+0x3c/0x68
> [ 8.698408] do_idle+0x1a0/0x280
> [ 8.701729] cpu_startup_entry+0x24/0x28
> [ 8.705768] secondary_start_kernel+0x15c/0x170
> [ 8.710423]
> [ 8.711972] Allocated by task 242:
> [ 8.715473] __kasan_kmalloc+0xf0/0x1ac
> [ 8.719426] kasan_slab_alloc+0x14/0x1c
> [ 8.723375] __kmalloc_track_caller+0x23c/0x388
> [ 8.728040] devm_kmalloc+0x38/0x94
> [ 8.731632] etm4_probe+0x48/0x3c8
> [ 8.735140] amba_probe+0xbc/0x158
> [ 8.738645] really_probe+0x144/0x408
> [ 8.742412] driver_probe_device+0x70/0x140
> [ 8.746716] __device_attach_driver+0x9c/0x110
> [ 8.751287] bus_for_each_drv+0x90/0xd8
> [ 8.755236] __device_attach+0xb4/0x164
> [ 8.759188] device_initial_probe+0x20/0x2c
> [ 8.763490] bus_probe_device+0x34/0x94
> [ 8.767436] device_add+0x34c/0x3e0
> [ 8.771029] amba_device_try_add+0x68/0x440
> [ 8.775332] amba_deferred_retry_func+0x48/0xc8
> [ 8.779997] process_one_work+0x344/0x648
> [ 8.784127] worker_thread+0x2ac/0x47c
> [ 8.787987] kthread+0x128/0x138
> [ 8.791313] ret_from_fork+0x10/0x18
> [ 8.794993]
> [ 8.796532] Freed by task 242:
> [ 8.799684] __kasan_slab_free+0x15c/0x22c
> [ 8.803897] kasan_slab_free+0x10/0x1c
> [ 8.807761] kfree+0x25c/0x4bc
> [ 8.810913] release_nodes+0x240/0x2b0
> [ 8.814767] devres_release_all+0x3c/0x54
> [ 8.818887] really_probe+0x178/0x408
> [ 8.822661] driver_probe_device+0x70/0x140
> [ 8.826963] __device_attach_driver+0x9c/0x110
> [ 8.831539] bus_for_each_drv+0x90/0xd8
> [ 8.835487] __device_attach+0xb4/0x164
> [ 8.839431] device_initial_probe+0x20/0x2c
> [ 8.843732] bus_probe_device+0x34/0x94
> [ 8.847678] device_add+0x34c/0x3e0
> [ 8.851274] amba_device_try_add+0x68/0x440
> [ 8.855576] amba_deferred_retry_func+0x48/0xc8
> [ 8.860240] process_one_work+0x344/0x648
> [ 8.864366] worker_thread+0x2ac/0x47c
> [ 8.868228] kthread+0x128/0x138
> [ 8.871557] ret_from_fork+0x10/0x18
> [ 8.875231]
> [ 8.876782] The buggy address belongs to the object at ffffff813304f800
> [ 8.876782] which belongs to the cache kmalloc-1k of size 1024
> [ 8.889632] The buggy address is located 200 bytes inside of
> [ 8.889632] 1024-byte region [ffffff813304f800, ffffff813304fc00)
> [ 8.901761] The buggy address belongs to the page:
> [ 8.906695] page:ffffffff04ac1200 refcount:1 mapcount:0 mapping:ffffff8146c03800 index:0x0 compound_mapcount: 0
> [ 8.917047] flags: 0x4000000000010200(slab|head)
> [ 8.921799] raw: 4000000000010200 dead000000000100 dead000000000122 ffffff8146c03800
> [ 8.929753] raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000
> [ 8.937703] page dumped because: kasan: bad access detected
> [ 8.943433]
> [ 8.944974] Memory state around the buggy address:
> [ 8.949903] ffffff813304f780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> [ 8.957320] ffffff813304f800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> [ 8.964742] >ffffff813304f880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> [ 8.972157] ^
> [ 8.977886] ffffff813304f900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> [ 8.985298] ffffff813304f980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> [ 8.992713] ==================================================================
>
> Fixes: f188b5e76aae9 ( "coresight: etm4x: Save/restore state across CPU low power states ")
Nit, this should be:
Fixes: f188b5e76aae ("coresight: etm4x: Save/restore state across CPU low power states")
The extra ' ' characters messed with my script checks :(
I'll fix it up by hand...
greg k-h
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/3] arm64: vdso: Don't prefix sigreturn trampoline with a BTI C instruction
From: Mark Brown @ 2020-05-19 14:35 UTC (permalink / raw)
To: Dave Martin
Cc: Tamas Zsoldos, kernel-team, Will Deacon, linux-arm-kernel,
Daniel Kiss
In-Reply-To: <20200519132538.GE5031@arm.com>
[-- Attachment #1.1: Type: text/plain, Size: 490 bytes --]
On Tue, May 19, 2020 at 02:25:38PM +0100, Dave Martin wrote:
> Rather, the "ret lr" that jumps here is supposed to be authenticated via
> pointer auth in the caller.
In which case there was an issue anyway...
> If BTI {nothing} allows this while disallowing all BR/BLR then we could
> use that (I can't remember what BTI {nothing} is useful for, if anything).
> Otherwise, it's less clear what we should have here.
I can't remember anything that distinguishes it from an explicit NOP.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/2] ARM: Allow either FLATMEM or SPARSEMEM on the multiplatform build
From: Mike Rapoport @ 2020-05-19 14:43 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Doug Berger, Stephen Boyd, Kevin Cernekee, Russell King,
Florian Fainelli, Gregory Fong, Linux ARM
In-Reply-To: <CAK8P3a1hd2uKsncgd=eyY1VHBbB8fPBDCWsyHpHT7q9eJp-URw@mail.gmail.com>
On Tue, May 19, 2020 at 09:59:48AM +0200, Arnd Bergmann wrote:
> On Mon, May 18, 2020 at 9:45 PM Mike Rapoport <rppt@linux.ibm.com> wrote:
> > On Mon, May 18, 2020 at 08:58:36AM -0700, Florian Fainelli wrote:
> > > On 5/7/2020 1:11 PM, Florian Fainelli wrote:
> > > > On 5/7/2020 12:27 AM, Mike Rapoport wrote:
> > > >> On Wed, May 06, 2020 at 04:50:09PM -0700, Florian Fainelli wrote:
> > > >>> From: Gregory Fong <gregory.0xf0@gmail.com>
> > > >>>
> > > >>> ARMv7 chips with LPAE can often benefit from SPARSEMEM, as portions of
> > > >>> system memory can be located deep in the 36-bit address space. Allow
> > > >>> FLATMEM or SPARSEMEM to be selectable at compile time; FLATMEM remains
> > > >>> the default.
> > > >>>
> > > >>> This is based on Kevin's "[PATCH 3/3] ARM: Allow either FLATMEM or
> > > >>> SPARSEMEM on the multi-v7 build" from [1] and shamelessly rips off his
> > > >>> commit message text above. As Arnd pointed out at [2] there doesn't
> > > >>> seem to be any reason to tie this specifically to ARMv7, so this has
> > > >>> been changed to apply to all multiplatform kernels.
> > > >>>
> > > >>> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/286837.html
> > > >>> [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/298950.html
> > > >>>
> > > >>> Cc: Kevin Cernekee <cernekee@gmail.com>
> > > >>> Tested-by: Stephen Boyd <sboyd@codeaurora.org>
> > > >>> Signed-off-by: Gregory Fong <gregory.0xf0@gmail.com>
> > > >>> Signed-off-by: Doug Berger <opendmb@gmail.com>
> > > >>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> > > >>> ---
> > > >>> arch/arm/Kconfig | 5 +++++
> > > >>> 1 file changed, 5 insertions(+)
> > > >>>
> > > >>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > > >>> index 5986277296c3..7bb5264a9c3a 100644
> > > >>> --- a/arch/arm/Kconfig
> > > >>> +++ b/arch/arm/Kconfig
> > > >>> @@ -312,6 +312,8 @@ choice
> > > >>> config ARCH_MULTIPLATFORM
> > > >>> bool "Allow multiple platforms to be selected"
> > > >>> depends on MMU
> > > >>> + select ARCH_FLATMEM_ENABLE
> > > >>> + select ARCH_SPARSEMEM_ENABLE
> > > >>
> > > >> The logic in mm/Kconfig is quite convoluted, so selecting
> > > >> ARCH_SPARSEMEM_ENABLE will automatically make SPARSEMEM the only option.
> > > >>
> > > >> On top of this you would need to enable ARCH_SELECT_MEMORY_MODEL, e.g.
> > > >> something like:
> > > >
> > > > Yes indeed, thanks that does allow me to select between flatmem and
> > > > sparsemem from menuconfig correctly now.
> > >
> > > Mike, do you want to make a formal submission to Russell's patch
> > > tracker? If so, feel free to add:
> >
> > I actually hoped to hear from people what do they think about switching
> > over to SPARSEMEM for the multiplatform builds. I think at least v7 CPUs
> > it would make sense.
>
> It seems that at least s5p/exynos and clps711x (armv4) used to default to
> sparsemem, and that got lost in the multiplatform conversion.
>
> I also see discontiguous memory ranges in multiple broadcom chips,
> on TI dm8168, ecx-2000 and imx.
>
> > Russel, Arnd, can you comment please?
>
> I see no problem with giving users the choice for all multiplatform
> builds. No idea on what the default should be really, i.e. whether
> only v7 configurations should make it the default, or rather none of
> them or all of them.
Me neither :)
I'd say let's move forward with letting user select the memory model for
all multiplaform builds and keep flatmem the default.
Enabling sparsemem (with SPARSEMEM_STATIC) for defconfig build increases
the kernel nearly by 8k and most probably will make things slower.
> Maybe lets leave the default unchanged with flatmem but enable it in
> multi_v7_defconfig and the configurations for chips that are known
> to have discontiguous memory (clps, bcm, imx, exynos, ...).
>
> Arnd
--
Sincerely yours,
Mike.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC Patch v1 2/4] irqchip/gic-v3: Add support to handle SGI as pseudo NMI
From: Marc Zyngier @ 2020-05-19 14:51 UTC (permalink / raw)
To: Sumit Garg
Cc: Daniel Thompson, Jason Cooper, Catalin Marinas,
Linux Kernel Mailing List, Douglas Anderson, julien.thierry.kdev,
Jason Wessel, kgdb-bugreport, Thomas Gleixner, Will Deacon,
linux-arm-kernel
In-Reply-To: <CAFA6WYO3=BHX1exF+J=93ECnQFe3S5O4HrT4t14euw3t9PXE7A@mail.gmail.com>
On 2020-05-13 11:02, Sumit Garg wrote:
> Hi Marc,
>
> On Tue, 5 May 2020 at 17:03, Sumit Garg <sumit.garg@linaro.org> wrote:
>>
>> On Tue, 5 May 2020 at 15:38, Marc Zyngier <maz@kernel.org> wrote:
>> >
>> > On 2020-05-05 05:09, Sumit Garg wrote:
>> > > On Fri, 1 May 2020 at 18:33, Sumit Garg <sumit.garg@linaro.org> wrote:
>> >
>> > [...]
>> >
>> > > In case there are no major objections to this approach, I will post
>> > > complete v2 patch-set (alongwith Marc's patches) for detailed review.
>> >
>> > As this is still a work in progress (I'm currently wrestling with
>> > the stupid RPi driver), whatever you have is unlikely to apply on
>> > top of the final series.
>> >
>> > I'm not going to stop you from posting the patches, it is just that
>> > they will be obsolete by the end of the week...
>>
>> Thanks for the heads up. Will wait for your final series.
>>
>
> Were you able to give a final shape to your SGIs related patch-set?
See
https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=irq/ipi-as-irq
Thanks,
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 1/4] rcu/kasan: record and print call_rcu() call stack
From: Andrey Konovalov @ 2020-05-19 14:52 UTC (permalink / raw)
To: Walter Wu
Cc: wsd_upstream, Paul E . McKenney, Linux Memory Management List,
Lai Jiangshan, Josh Triplett, kasan-dev, LKML, Joel Fernandes,
linux-mediatek, Alexander Potapenko, Linux ARM, Matthias Brugger,
Andrey Ryabinin, Andrew Morton, Dmitry Vyukov, Mathieu Desnoyers
In-Reply-To: <20200519022359.24115-1-walter-zh.wu@mediatek.com>
On Tue, May 19, 2020 at 4:24 AM Walter Wu <walter-zh.wu@mediatek.com> wrote:
>
> This feature will record the last two call_rcu() call stacks and
> prints up to 2 call_rcu() call stacks in KASAN report.
>
> When call_rcu() is called, we store the call_rcu() call stack into
> slub alloc meta-data, so that the KASAN report can print rcu stack.
>
> [1]https://bugzilla.kernel.org/show_bug.cgi?id=198437
> [2]https://groups.google.com/forum/#!searchin/kasan-dev/better$20stack$20traces$20for$20rcu%7Csort:date/kasan-dev/KQsjT_88hDE/7rNUZprRBgAJ
>
> Signed-off-by: Walter Wu <walter-zh.wu@mediatek.com>
> Suggested-by: Dmitry Vyukov <dvyukov@google.com>
> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
> Cc: Dmitry Vyukov <dvyukov@google.com>
> Cc: Alexander Potapenko <glider@google.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Paul E. McKenney <paulmck@kernel.org>
> Cc: Josh Triplett <josh@joshtriplett.org>
> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
> Cc: Lai Jiangshan <jiangshanlai@gmail.com>
> Cc: Joel Fernandes <joel@joelfernandes.org>
> ---
> include/linux/kasan.h | 2 ++
> kernel/rcu/tree.c | 2 ++
> lib/Kconfig.kasan | 2 ++
> mm/kasan/common.c | 4 ++--
> mm/kasan/generic.c | 19 +++++++++++++++++++
> mm/kasan/kasan.h | 10 ++++++++++
> mm/kasan/report.c | 24 ++++++++++++++++++++++++
> 7 files changed, 61 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/kasan.h b/include/linux/kasan.h
> index 31314ca7c635..23b7ee00572d 100644
> --- a/include/linux/kasan.h
> +++ b/include/linux/kasan.h
> @@ -174,11 +174,13 @@ static inline size_t kasan_metadata_size(struct kmem_cache *cache) { return 0; }
>
> void kasan_cache_shrink(struct kmem_cache *cache);
> void kasan_cache_shutdown(struct kmem_cache *cache);
> +void kasan_record_aux_stack(void *ptr);
>
> #else /* CONFIG_KASAN_GENERIC */
>
> static inline void kasan_cache_shrink(struct kmem_cache *cache) {}
> static inline void kasan_cache_shutdown(struct kmem_cache *cache) {}
> +static inline void kasan_record_aux_stack(void *ptr) {}
>
> #endif /* CONFIG_KASAN_GENERIC */
>
> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> index 06548e2ebb72..36a4ff7f320b 100644
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c
> @@ -57,6 +57,7 @@
> #include <linux/slab.h>
> #include <linux/sched/isolation.h>
> #include <linux/sched/clock.h>
> +#include <linux/kasan.h>
> #include "../time/tick-internal.h"
>
> #include "tree.h"
> @@ -2668,6 +2669,7 @@ __call_rcu(struct rcu_head *head, rcu_callback_t func)
> head->func = func;
> head->next = NULL;
> local_irq_save(flags);
> + kasan_record_aux_stack(head);
> rdp = this_cpu_ptr(&rcu_data);
>
> /* Add the callback to our list. */
> diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
> index 81f5464ea9e1..4e83cf6e3caa 100644
> --- a/lib/Kconfig.kasan
> +++ b/lib/Kconfig.kasan
> @@ -58,6 +58,8 @@ config KASAN_GENERIC
> For better error detection enable CONFIG_STACKTRACE.
> Currently CONFIG_KASAN_GENERIC doesn't work with CONFIG_DEBUG_SLAB
> (the resulting kernel does not boot).
> + In generic mode KASAN prints the last two call_rcu() call stacks in
> + reports.
I don't think we need this here, mentioning this in the documentation is fine.
>
> config KASAN_SW_TAGS
> bool "Software tag-based mode"
> diff --git a/mm/kasan/common.c b/mm/kasan/common.c
> index 2906358e42f0..8bc618289bb1 100644
> --- a/mm/kasan/common.c
> +++ b/mm/kasan/common.c
> @@ -41,7 +41,7 @@
> #include "kasan.h"
> #include "../slab.h"
>
> -static inline depot_stack_handle_t save_stack(gfp_t flags)
> +depot_stack_handle_t kasan_save_stack(gfp_t flags)
> {
> unsigned long entries[KASAN_STACK_DEPTH];
> unsigned int nr_entries;
> @@ -54,7 +54,7 @@ static inline depot_stack_handle_t save_stack(gfp_t flags)
> static inline void set_track(struct kasan_track *track, gfp_t flags)
> {
> track->pid = current->pid;
> - track->stack = save_stack(flags);
> + track->stack = kasan_save_stack(flags);
> }
>
> void kasan_enable_current(void)
> diff --git a/mm/kasan/generic.c b/mm/kasan/generic.c
> index 56ff8885fe2e..3372bdcaf92a 100644
> --- a/mm/kasan/generic.c
> +++ b/mm/kasan/generic.c
> @@ -325,3 +325,22 @@ DEFINE_ASAN_SET_SHADOW(f2);
> DEFINE_ASAN_SET_SHADOW(f3);
> DEFINE_ASAN_SET_SHADOW(f5);
> DEFINE_ASAN_SET_SHADOW(f8);
> +
> +void kasan_record_aux_stack(void *addr)
> +{
> + struct page *page = kasan_addr_to_page(addr);
> + struct kmem_cache *cache;
> + struct kasan_alloc_meta *alloc_info;
> + void *object;
> +
> + if (!(page && PageSlab(page)))
> + return;
> +
> + cache = page->slab_cache;
> + object = nearest_obj(cache, page, addr);
> + alloc_info = get_alloc_info(cache, object);
> +
> + /* record the last two call_rcu() call stacks */
> + alloc_info->aux_stack[1] = alloc_info->aux_stack[0];
> + alloc_info->aux_stack[0] = kasan_save_stack(GFP_NOWAIT);
> +}
> diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h
> index e8f37199d885..a7391bc83070 100644
> --- a/mm/kasan/kasan.h
> +++ b/mm/kasan/kasan.h
> @@ -104,7 +104,15 @@ struct kasan_track {
>
> struct kasan_alloc_meta {
> struct kasan_track alloc_track;
> +#ifdef CONFIG_KASAN_GENERIC
> + /*
> + * call_rcu() call stack is stored into struct kasan_alloc_meta.
> + * The free stack is stored into struct kasan_free_meta.
> + */
> + depot_stack_handle_t aux_stack[2];
> +#else
> struct kasan_track free_track[KASAN_NR_FREE_STACKS];
> +#endif
> #ifdef CONFIG_KASAN_SW_TAGS_IDENTIFY
> u8 free_pointer_tag[KASAN_NR_FREE_STACKS];
> u8 free_track_idx;
> @@ -159,6 +167,8 @@ void kasan_report_invalid_free(void *object, unsigned long ip);
>
> struct page *kasan_addr_to_page(const void *addr);
>
> +depot_stack_handle_t kasan_save_stack(gfp_t flags);
> +
> #if defined(CONFIG_KASAN_GENERIC) && \
> (defined(CONFIG_SLAB) || defined(CONFIG_SLUB))
> void quarantine_put(struct kasan_free_meta *info, struct kmem_cache *cache);
> diff --git a/mm/kasan/report.c b/mm/kasan/report.c
> index 80f23c9da6b0..6f8f2bf8f53b 100644
> --- a/mm/kasan/report.c
> +++ b/mm/kasan/report.c
> @@ -179,6 +179,17 @@ static struct kasan_track *kasan_get_free_track(struct kmem_cache *cache,
> return &alloc_meta->free_track[i];
> }
>
> +#ifdef CONFIG_KASAN_GENERIC
> +static void print_stack(depot_stack_handle_t stack)
Let's put this function just before print_track() and reuse there.
> +{
> + unsigned long *entries;
> + unsigned int nr_entries;
> +
> + nr_entries = stack_depot_fetch(stack, &entries);
> + stack_trace_print(entries, nr_entries, 0);
> +}
> +#endif
> +
> static void describe_object(struct kmem_cache *cache, void *object,
> const void *addr, u8 tag)
> {
> @@ -192,6 +203,19 @@ static void describe_object(struct kmem_cache *cache, void *object,
> free_track = kasan_get_free_track(cache, object, tag);
> print_track(free_track, "Freed");
> pr_err("\n");
> +
> +#ifdef CONFIG_KASAN_GENERIC
> + if (alloc_info->aux_stack[0]) {
> + pr_err("Last one call_rcu() call stack:\n");
Could you change this to "Last call_rcu():\n",
> + print_stack(alloc_info->aux_stack[0]);
> + pr_err("\n");
> + }
> + if (alloc_info->aux_stack[1]) {
> + pr_err("Second to last call_rcu() call stack:\n");
and this to "Second to last call_rcu():\n"?
It's shorter, but provides the same info.
> + print_stack(alloc_info->aux_stack[1]);
> + pr_err("\n");
> + }
> +#endif
> }
>
> describe_object_addr(cache, object, addr);
> --
> 2.18.0
>
> --
> You received this message because you are subscribed to the Google Groups "kasan-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to kasan-dev+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/kasan-dev/20200519022359.24115-1-walter-zh.wu%40mediatek.com.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/3] arm64: vdso: Don't prefix sigreturn trampoline with a BTI C instruction
From: Dave Martin @ 2020-05-19 14:55 UTC (permalink / raw)
To: Mark Brown
Cc: Tamas Zsoldos, Will Deacon, kernel-team, linux-arm-kernel,
Daniel Kiss
In-Reply-To: <20200519143500.GK4611@sirena.org.uk>
On Tue, May 19, 2020 at 03:35:00PM +0100, Mark Brown wrote:
> On Tue, May 19, 2020 at 02:25:38PM +0100, Dave Martin wrote:
>
> > Rather, the "ret lr" that jumps here is supposed to be authenticated via
> > pointer auth in the caller.
>
> In which case there was an issue anyway...
What issue?
> > If BTI {nothing} allows this while disallowing all BR/BLR then we could
> > use that (I can't remember what BTI {nothing} is useful for, if anything).
>
> > Otherwise, it's less clear what we should have here.
>
> I can't remember anything that distinguishes it from an explicit NOP.
I think it rejects everything other then fallthrough execution
(BTYPE==0, which includes RET). I might have misunderstood something
somewhere, but sort of feels like the right thing here. I never put a
lot of effort into trying to understand BTI {nothing} though. It
seemed a weird, possibly useless special case.
Of course, if gdb's unwinder does rely on recognising magic instruction
sequences in the sigreturn trampoline even when the vdso has valid
unwind information, we're probably doomed to stick for the current code
forever.
Cheers
---Dave
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ARM: Implement functions for HAVE_FUNCTION_ARG_ACCESS_API
From: Russell King - ARM Linux admin @ 2020-05-19 15:02 UTC (permalink / raw)
To: Andrew Jeffery; +Cc: oleg, linux-arm-kernel, linux-kernel
In-Reply-To: <20200519143132.603579-1-andrew@aj.id.au>
On Wed, May 20, 2020 at 12:01:32AM +0930, Andrew Jeffery wrote:
> This allows extraction of kernel function arguments via kprobes on ARM.
> Based on the arm64 implementation and adapted for the 32-bit AAPCS.
>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> ---
> The description for HAVE_FUNCTION_ARG_ACCESS_API was pretty vague on what was
> required. I've implemented enough to enable argument extraction for kprobes; is
> there anything else needed to satisfy HAVE_FUNCTION_ARG_ACCESS_API?
What about 64-bit arguments? How do they get handled?
regs_get_kernel_argument() talks about 'n' being the argument number,
and maps this directly to a register. If a function argument
prototype is:
(something *foo, long long bar, int baz)
The foo is in r0, bar is in r2/r3 on EABI, and baz is on the stack.
n=0 will return foo. n=1 will be undefined. n=2 will return part of
bar, and n=3 will return the other half. Is this what is expected?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/2] ARM: Allow either FLATMEM or SPARSEMEM on the multiplatform build
From: Russell King - ARM Linux admin @ 2020-05-19 15:04 UTC (permalink / raw)
To: Mike Rapoport
Cc: Doug Berger, Arnd Bergmann, Stephen Boyd, Kevin Cernekee,
Florian Fainelli, Gregory Fong, Linux ARM
In-Reply-To: <20200519144306.GE1059226@linux.ibm.com>
On Tue, May 19, 2020 at 05:43:06PM +0300, Mike Rapoport wrote:
> On Tue, May 19, 2020 at 09:59:48AM +0200, Arnd Bergmann wrote:
> > On Mon, May 18, 2020 at 9:45 PM Mike Rapoport <rppt@linux.ibm.com> wrote:
> > > On Mon, May 18, 2020 at 08:58:36AM -0700, Florian Fainelli wrote:
> > > > On 5/7/2020 1:11 PM, Florian Fainelli wrote:
> > > > > On 5/7/2020 12:27 AM, Mike Rapoport wrote:
> > > > >> On Wed, May 06, 2020 at 04:50:09PM -0700, Florian Fainelli wrote:
> > > > >>> From: Gregory Fong <gregory.0xf0@gmail.com>
> > > > >>>
> > > > >>> ARMv7 chips with LPAE can often benefit from SPARSEMEM, as portions of
> > > > >>> system memory can be located deep in the 36-bit address space. Allow
> > > > >>> FLATMEM or SPARSEMEM to be selectable at compile time; FLATMEM remains
> > > > >>> the default.
> > > > >>>
> > > > >>> This is based on Kevin's "[PATCH 3/3] ARM: Allow either FLATMEM or
> > > > >>> SPARSEMEM on the multi-v7 build" from [1] and shamelessly rips off his
> > > > >>> commit message text above. As Arnd pointed out at [2] there doesn't
> > > > >>> seem to be any reason to tie this specifically to ARMv7, so this has
> > > > >>> been changed to apply to all multiplatform kernels.
> > > > >>>
> > > > >>> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/286837.html
> > > > >>> [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/298950.html
> > > > >>>
> > > > >>> Cc: Kevin Cernekee <cernekee@gmail.com>
> > > > >>> Tested-by: Stephen Boyd <sboyd@codeaurora.org>
> > > > >>> Signed-off-by: Gregory Fong <gregory.0xf0@gmail.com>
> > > > >>> Signed-off-by: Doug Berger <opendmb@gmail.com>
> > > > >>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> > > > >>> ---
> > > > >>> arch/arm/Kconfig | 5 +++++
> > > > >>> 1 file changed, 5 insertions(+)
> > > > >>>
> > > > >>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > > > >>> index 5986277296c3..7bb5264a9c3a 100644
> > > > >>> --- a/arch/arm/Kconfig
> > > > >>> +++ b/arch/arm/Kconfig
> > > > >>> @@ -312,6 +312,8 @@ choice
> > > > >>> config ARCH_MULTIPLATFORM
> > > > >>> bool "Allow multiple platforms to be selected"
> > > > >>> depends on MMU
> > > > >>> + select ARCH_FLATMEM_ENABLE
> > > > >>> + select ARCH_SPARSEMEM_ENABLE
> > > > >>
> > > > >> The logic in mm/Kconfig is quite convoluted, so selecting
> > > > >> ARCH_SPARSEMEM_ENABLE will automatically make SPARSEMEM the only option.
> > > > >>
> > > > >> On top of this you would need to enable ARCH_SELECT_MEMORY_MODEL, e.g.
> > > > >> something like:
> > > > >
> > > > > Yes indeed, thanks that does allow me to select between flatmem and
> > > > > sparsemem from menuconfig correctly now.
> > > >
> > > > Mike, do you want to make a formal submission to Russell's patch
> > > > tracker? If so, feel free to add:
> > >
> > > I actually hoped to hear from people what do they think about switching
> > > over to SPARSEMEM for the multiplatform builds. I think at least v7 CPUs
> > > it would make sense.
> >
> > It seems that at least s5p/exynos and clps711x (armv4) used to default to
> > sparsemem, and that got lost in the multiplatform conversion.
> >
> > I also see discontiguous memory ranges in multiple broadcom chips,
> > on TI dm8168, ecx-2000 and imx.
> >
> > > Russel, Arnd, can you comment please?
> >
> > I see no problem with giving users the choice for all multiplatform
> > builds. No idea on what the default should be really, i.e. whether
> > only v7 configurations should make it the default, or rather none of
> > them or all of them.
>
> Me neither :)
>
> I'd say let's move forward with letting user select the memory model for
> all multiplaform builds and keep flatmem the default.
>
> Enabling sparsemem (with SPARSEMEM_STATIC) for defconfig build increases
> the kernel nearly by 8k and most probably will make things slower.
I think when selecting the default, you need to consider whether
platforms can boot with that default configuration or not.
There are cases where the reason to use sparsemem is not an optional
one but is out of necessity - they require the page array to be split
up in order to boot successfully.
With that in mind, flatmem becomes an "optimisation" over sparsemem.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 4/4] arm64: dts: mt6797: Fix mmsys node name
From: Chun-Kuang Hu @ 2020-05-19 15:06 UTC (permalink / raw)
To: matthias.bgg
Cc: Kate Stewart, devicetree, Stephen Boyd, Greg Kroah-Hartman,
Michael Turquette, linux-kernel, Rob Herring,
moderated list:ARM/Mediatek SoC support, Allison Randal,
Matthias Brugger, mtk01761, Thomas Gleixner, linux-clk, Linux ARM
In-Reply-To: <20200518113156.25009-4-matthias.bgg@kernel.org>
Hi, Matthias:
<matthias.bgg@kernel.org> 於 2020年5月18日 週一 下午7:33寫道：
>
> From: Matthias Brugger <matthias.bgg@gmail.com>
>
> Node names are supposed to match the class of the device. The
> mmsys node is a syscon as it provides more then just a clock controller.
> Update the name.
Reviewed-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
>
> Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
>
> ---
>
> arch/arm64/boot/dts/mediatek/mt6797.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt6797.dtsi b/arch/arm64/boot/dts/mediatek/mt6797.dtsi
> index 136ef9527a0d..3efd032481ce 100644
> --- a/arch/arm64/boot/dts/mediatek/mt6797.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt6797.dtsi
> @@ -233,7 +233,7 @@ uart3: serial@11005000 {
> status = "disabled";
> };
>
> - mmsys: mmsys_config@14000000 {
> + mmsys: syscon@14000000 {
> compatible = "mediatek,mt6797-mmsys", "syscon";
> reg = <0 0x14000000 0 0x1000>;
> #clock-cells = <1>;
> --
> 2.26.2
>
>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/4] clk/soc: mediatek: mt6779: Bind clock driver from platform device
From: Chun-Kuang Hu @ 2020-05-19 15:10 UTC (permalink / raw)
To: matthias.bgg
Cc: Kate Stewart, devicetree, Stephen Boyd, Greg Kroah-Hartman,
Michael Turquette, linux-kernel, Rob Herring,
moderated list:ARM/Mediatek SoC support, Allison Randal,
Matthias Brugger, mtk01761, Thomas Gleixner, linux-clk, Linux ARM
In-Reply-To: <20200518113156.25009-3-matthias.bgg@kernel.org>
Hi, Matthias:
<matthias.bgg@kernel.org> 於 2020年5月18日 週一 下午7:33寫道：
>
> From: Matthias Brugger <matthias.bgg@gmail.com>
>
> The mmsys driver is now the top level entry point for the multimedia
> system (mmsys), we bind the clock driver by creating a platform device.
> We also bind the MediaTek DRM driver which is not yet implement and
> therefor will errror out for now.
>
> Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
> ---
>
> drivers/clk/mediatek/clk-mt6779-mm.c | 9 ++-------
> drivers/soc/mediatek/mtk-mmsys.c | 8 ++++++++
> 2 files changed, 10 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/clk/mediatek/clk-mt6779-mm.c b/drivers/clk/mediatek/clk-mt6779-mm.c
> index fb5fbb8e3e41..059c1a41ac7a 100644
> --- a/drivers/clk/mediatek/clk-mt6779-mm.c
> +++ b/drivers/clk/mediatek/clk-mt6779-mm.c
> @@ -84,15 +84,11 @@ static const struct mtk_gate mm_clks[] = {
> GATE_MM1(CLK_MM_DISP_OVL_FBDC, "mm_disp_ovl_fbdc", "mm_sel", 16),
> };
>
> -static const struct of_device_id of_match_clk_mt6779_mm[] = {
> - { .compatible = "mediatek,mt6779-mmsys", },
> - {}
> -};
> -
> static int clk_mt6779_mm_probe(struct platform_device *pdev)
> {
> + struct device *dev = &pdev->dev;
> + struct device_node *node = dev->parent->of_node;
> struct clk_onecell_data *clk_data;
> - struct device_node *node = pdev->dev.of_node;
>
> clk_data = mtk_alloc_clk_data(CLK_MM_NR_CLK);
>
> @@ -106,7 +102,6 @@ static struct platform_driver clk_mt6779_mm_drv = {
> .probe = clk_mt6779_mm_probe,
> .driver = {
> .name = "clk-mt6779-mm",
> - .of_match_table = of_match_clk_mt6779_mm,
> },
> };
>
> diff --git a/drivers/soc/mediatek/mtk-mmsys.c b/drivers/soc/mediatek/mtk-mmsys.c
> index fee64c8d3020..dc15808cf3a3 100644
> --- a/drivers/soc/mediatek/mtk-mmsys.c
> +++ b/drivers/soc/mediatek/mtk-mmsys.c
> @@ -88,6 +88,10 @@ static const struct mtk_mmsys_driver_data mt2712_mmsys_driver_data = {
> .clk_driver = "clk-mt2712-mm",
> };
>
> +static const struct mtk_mmsys_driver_data mt6779_mmsys_driver_data = {
> + .clk_driver = "clk-mt6779-mm",
This patch looks good to me, but I've one question: why drm driver
just use single "mediatek-drm" for sub driver name, but clock driver
has different name for each SoC?
Could we just use single name for clock driver such as "mediatek-clk-mm"?
Regards,
Chun-Kuang.
> +};
> +
> static const struct mtk_mmsys_driver_data mt6797_mmsys_driver_data = {
> .clk_driver = "clk-mt6797-mm",
> };
> @@ -343,6 +347,10 @@ static const struct of_device_id of_match_mtk_mmsys[] = {
> .compatible = "mediatek,mt2712-mmsys",
> .data = &mt2712_mmsys_driver_data,
> },
> + {
> + .compatible = "mediatek,mt6779-mmsys",
> + .data = &mt6779_mmsys_driver_data,
> + },
> {
> .compatible = "mediatek,mt6797-mmsys",
> .data = &mt6797_mmsys_driver_data,
> --
> 2.26.2
>
>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox