[PATCH v3 5/9] mtd: rawnand: denali: use bool type instead of int where appropriate
Use 'bool' type for the following boolean parameters.
- write (write or read?)
- raw (raw access or not?)
- dma_avail (DMA engine available or not?)
Signed-off-by: Masahiro Yamada
---
Changes in v3: None
Changes in v2:
- Use bool for dma_avail as well
drivers/mtd/nand/raw/denali.c | 27 ++-
drivers/mtd/nand/raw/denali.h | 4 ++--
2 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/drivers/mtd/nand/raw/denali.c b/drivers/mtd/nand/raw/denali.c
index 2c7dc9b..05fbe8f 100644
--- a/drivers/mtd/nand/raw/denali.c
+++ b/drivers/mtd/nand/raw/denali.c
@@ -357,7 +357,7 @@ static int denali_sw_ecc_fixup(struct nand_chip *chip,
}
static void denali_setup_dma64(struct denali_nand_info *denali,
- dma_addr_t dma_addr, int page, int write)
+ dma_addr_t dma_addr, int page, bool write)
{
uint32_t mode;
const int page_count = 1;
@@ -371,7 +371,8 @@ static void denali_setup_dma64(struct denali_nand_info
*denali,
*burst len = 64 bytes, the number of pages
*/
denali->host_write(denali, mode,
- 0x01002000 | (64 << 16) | (write << 8) | page_count);
+ 0x01002000 | (64 << 16) |
+ (write ? BIT(8) : 0) | page_count);
/* 2. set memory low address */
denali->host_write(denali, mode, lower_32_bits(dma_addr));
@@ -381,7 +382,7 @@ static void denali_setup_dma64(struct denali_nand_info
*denali,
}
static void denali_setup_dma32(struct denali_nand_info *denali,
- dma_addr_t dma_addr, int page, int write)
+ dma_addr_t dma_addr, int page, bool write)
{
uint32_t mode;
const int page_count = 1;
@@ -392,7 +393,7 @@ static void denali_setup_dma32(struct denali_nand_info
*denali,
/* 1. setup transfer type and # of pages */
denali->host_write(denali, mode | page,
- 0x2000 | (write << 8) | page_count);
+ 0x2000 | (write ? BIT(8) : 0) | page_count);
/* 2. set memory high address bits 23:8 */
denali->host_write(denali, mode | ((dma_addr >> 16) << 8), 0x2200);
@@ -452,7 +453,7 @@ static int denali_pio_write(struct denali_nand_info
*denali, const u32 *buf,
}
static int denali_pio_xfer(struct denali_nand_info *denali, void *buf,
- size_t size, int page, int write)
+ size_t size, int page, bool write)
{
if (write)
return denali_pio_write(denali, buf, size, page);
@@ -461,7 +462,7 @@ static int denali_pio_xfer(struct denali_nand_info *denali,
void *buf,
}
static int denali_dma_xfer(struct denali_nand_info *denali, void *buf,
- size_t size, int page, int write)
+ size_t size, int page, bool write)
{
dma_addr_t dma_addr;
uint32_t irq_mask, irq_status, ecc_err_mask;
@@ -518,7 +519,7 @@ static int denali_dma_xfer(struct denali_nand_info *denali,
void *buf,
}
static int denali_data_xfer(struct nand_chip *chip, void *buf, size_t size,
- int page, int raw, int write)
+ int page, bool raw, bool write)
{
struct denali_nand_info *denali = to_denali(chip);
@@ -669,7 +670,7 @@ static int denali_read_page_raw(struct nand_chip *chip,
uint8_t *buf,
if (!buf)
return -EINVAL;
- ret = denali_data_xfer(chip, tmp_buf, size, page, 1, 0);
+ ret = denali_data_xfer(chip, tmp_buf, size, page, true, false);
if (ret)
return ret;
@@ -725,7 +726,7 @@ static int denali_write_page_raw(struct nand_chip *chip,
const uint8_t *buf,
return ret;
}
- return denali_data_xfer(chip, tmp_buf, size, page, 1, 1);
+ return denali_data_xfer(chip, tmp_buf, size, page, true, true);
}
static int denali_change_read_column_op(void *buf, unsigned int offset,
@@ -777,7 +778,7 @@ static int denali_read_page(struct nand_chip *chip, uint8_t
*buf,
int stat = 0;
int ret;
- ret = denali_data_xfer(chip, buf, mtd->writesize, page, 0, 0);
+ ret = denali_data_xfer(chip, buf, mtd->writesize, page, false, false);
if (ret && ret != -EBADMSG)
return ret;
@@ -807,7 +808,7 @@ static int denali_write_page(struct nand_chip *chip, const
uint8_t *buf,
struct mtd_info *mtd = nand_to_mtd(chip);
return denali_data_xfer(chip, (void *)buf, mtd->writesize, page,
- 0, 1);
+ false, true);
}
static int denali_setup_data_interface(struct nand_chip *chip, int chipnr,
@@ -1063,7 +1064,7 @@ static int denali_attach_chip(struct nand_chip *chip)
int ret;
if (ioread32(denali->reg + FEATURES) & FEATURES__DMA)
- denali->dma_avail = 1;
+
[PATCH v3 2/9] mtd: rawnand: denali: refactor syndrome layout handling for raw access
The Denali IP adopts the syndrome page layout (payload and ECC are
interleaved). The *_page_raw() and *_oob() callbacks are complicated
because they must hide the underlying layout used by the hardware,
and always return contiguous in-band and out-of-band data.
Currently, similar code is duplicated to reorganize the data layout.
For example, denali_read_page_raw() and denali_write_page_raw() look
almost the same.
The idea for refactoring is to split the code into two parts:
[1] conversion of page layout
[2] what to do at every ECC chunk boundary
For [1], I wrote denali_raw_payload_op() and denali_raw_oob_op().
They manipulate data for the Denali controller's specific page layout
of in-band, out-of-band, respectively.
The difference between write and read is just the operation at
ECC chunk boundaries. For example, denali_read_oob() calls
nand_change_read_column_op(), whereas denali_write_oob() calls
nand_change_write_column_op(). So, I implemented [2] as a callback
passed into [1].
Signed-off-by: Masahiro Yamada
---
Changes in v3:
- Add comments to denali_raw_payload_op() and denali_oob_payload_op()
Changes in v2: None
drivers/mtd/nand/raw/denali.c | 380 +-
1 file changed, 189 insertions(+), 191 deletions(-)
diff --git a/drivers/mtd/nand/raw/denali.c b/drivers/mtd/nand/raw/denali.c
index 4ac1314..ebeedbd 100644
--- a/drivers/mtd/nand/raw/denali.c
+++ b/drivers/mtd/nand/raw/denali.c
@@ -608,159 +608,236 @@ static int denali_data_xfer(struct nand_chip *chip,
void *buf, size_t size,
return denali_pio_xfer(denali, buf, size, page, write);
}
-static void denali_oob_xfer(struct mtd_info *mtd, struct nand_chip *chip,
- int page, int write)
+typedef int denali_change_column_callback(void *buf, unsigned int offset,
+ unsigned int len, void *priv);
+
+/**
+ * denali_raw_payload_op() - arrange the payload data for syndrome layout
+ *
+ * The NAND framework passes the payload and ECC separately, but the Denali ECC
+ * engine cannot handle it directly because it writes/reads page data in the
+ * syndrome layout (payload and ECC are interleaved). This helper is useful to
+ * convert the layout between the two formats.
+ *
+ * @chip: NAND chip structure
+ * @buf: buffer passed from the NAND framework
+ * @cb: callback invoked whenever the column address is changed
+ * @priv: private data passed to @cb
+ */
+static int denali_raw_payload_op(struct nand_chip *chip, void *buf,
+denali_change_column_callback *cb, void *priv)
{
- struct denali_nand_info *denali = mtd_to_denali(mtd);
+ struct denali_nand_info *denali = to_denali(chip);
+ struct mtd_info *mtd = nand_to_mtd(chip);
+ struct nand_ecc_ctrl *ecc = &chip->ecc;
+ int writesize = mtd->writesize;
+ int oob_skip = denali->oob_skip_bytes;
+ int ret, i, pos, len;
+
+ for (i = 0; i < ecc->steps; i++) {
+ pos = i * (ecc->size + ecc->bytes);
+ len = ecc->size;
+
+ if (pos >= writesize) {
+ pos += oob_skip;
+ } else if (pos + len > writesize) {
+ /* This chunk overwraps the BBM area. Must be split */
+ ret = cb(buf, pos, writesize - pos, priv);
+ if (ret)
+ return ret;
+
+ buf += writesize - pos;
+ len -= writesize - pos;
+ pos = writesize + oob_skip;
+ }
+
+ ret = cb(buf, pos, len, priv);
+ if (ret)
+ return ret;
+
+ buf += len;
+ }
+
+ return 0;
+}
+
+/**
+ * denali_raw_oob_op() - arrange the oob data for syndrome layout
+ *
+ * The NAND framework passes the payload and ECC separately, but the Denali ECC
+ * engine cannot handle it directly because it writes/reads page data in the
+ * syndrome layout (payload and ECC are interleaved). This helper is useful to
+ * convert the layout between the two formats.
+ *
+ * @chip: NAND chip structure
+ * @buf: buffer passed from the NAND framework
+ * @cb: callback invoked whenever the column address is changed
+ * @priv: private data passed to @cb
+ */
+static int denali_raw_oob_op(struct nand_chip *chip, void *buf,
+denali_change_column_callback *cb, void *priv)
+{
+ struct denali_nand_info *denali = to_denali(chip);
+ struct mtd_info *mtd = nand_to_mtd(chip);
+ struct nand_ecc_ctrl *ecc = &chip->ecc;
int writesize = mtd->writesize;
int oobsize = mtd->oobsize;
- uint8_t *bufpoi = chip->oob_poi;
- int ecc_steps = chip->ecc.steps;
- int ecc_size = chip->ecc.size;
- int ecc_bytes = chip->ecc.bytes;
int oob_skip = denali->oob_skip_bytes;
- size_t size = writesize + oobsize;
- int i,
[PATCH v3 6/9] mtd: rawnand: denali_pci: rename goto labels
As Documentation/process/coding-style.rst says, choose label names
which say what the goto does. The out_ label style is already
used in denali_dt.c. Rename likewise for denali_pci.c
Signed-off-by: Masahiro Yamada
---
Changes in v3: None
Changes in v2: None
drivers/mtd/nand/raw/denali_pci.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/nand/raw/denali_pci.c
b/drivers/mtd/nand/raw/denali_pci.c
index 48e9ac5..02eb599 100644
--- a/drivers/mtd/nand/raw/denali_pci.c
+++ b/drivers/mtd/nand/raw/denali_pci.c
@@ -84,20 +84,20 @@ static int denali_pci_probe(struct pci_dev *dev, const
struct pci_device_id *id)
if (!denali->host) {
dev_err(&dev->dev, "Spectra: ioremap_nocache failed!");
ret = -ENOMEM;
- goto failed_remap_reg;
+ goto out_unmap_reg;
}
ret = denali_init(denali);
if (ret)
- goto failed_remap_mem;
+ goto out_unmap_host;
pci_set_drvdata(dev, denali);
return 0;
-failed_remap_mem:
+out_unmap_host:
iounmap(denali->host);
-failed_remap_reg:
+out_unmap_reg:
iounmap(denali->reg);
return ret;
}
--
2.7.4
[PATCH v3 3/9] mtd: rawnand: denali: remove unneeded casts in denali_{read,write}_pio
Since (u32 *) can accept an opaque pointer, the explicit casting
from (void *) to (u32 *) is redundant. Change the function argument type
to remove the casts.
Signed-off-by: Masahiro Yamada
---
Changes in v3: None
Changes in v2: None
drivers/mtd/nand/raw/denali.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/mtd/nand/raw/denali.c b/drivers/mtd/nand/raw/denali.c
index ebeedbd..d2040b7 100644
--- a/drivers/mtd/nand/raw/denali.c
+++ b/drivers/mtd/nand/raw/denali.c
@@ -478,11 +478,10 @@ static void denali_setup_dma32(struct denali_nand_info
*denali,
denali->host_write(denali, mode | 0x14000, 0x2400);
}
-static int denali_pio_read(struct denali_nand_info *denali, void *buf,
+static int denali_pio_read(struct denali_nand_info *denali, u32 *buf,
size_t size, int page)
{
u32 addr = DENALI_MAP01 | DENALI_BANK(denali) | page;
- uint32_t *buf32 = (uint32_t *)buf;
uint32_t irq_status, ecc_err_mask;
int i;
@@ -494,7 +493,7 @@ static int denali_pio_read(struct denali_nand_info *denali,
void *buf,
denali_reset_irq(denali);
for (i = 0; i < size / 4; i++)
- *buf32++ = denali->host_read(denali, addr);
+ buf[i] = denali->host_read(denali, addr);
irq_status = denali_wait_for_irq(denali, INTR__PAGE_XFER_INC);
if (!(irq_status & INTR__PAGE_XFER_INC))
@@ -506,18 +505,17 @@ static int denali_pio_read(struct denali_nand_info
*denali, void *buf,
return irq_status & ecc_err_mask ? -EBADMSG : 0;
}
-static int denali_pio_write(struct denali_nand_info *denali,
- const void *buf, size_t size, int page)
+static int denali_pio_write(struct denali_nand_info *denali, const u32 *buf,
+ size_t size, int page)
{
u32 addr = DENALI_MAP01 | DENALI_BANK(denali) | page;
- const uint32_t *buf32 = (uint32_t *)buf;
uint32_t irq_status;
int i;
denali_reset_irq(denali);
for (i = 0; i < size / 4; i++)
- denali->host_write(denali, addr, *buf32++);
+ denali->host_write(denali, addr, buf[i]);
irq_status = denali_wait_for_irq(denali,
INTR__PROGRAM_COMP | INTR__PROGRAM_FAIL);
--
2.7.4
[PATCH v3 0/9] mtd: rawnand: denali: exec_op(), controller/chip separation, and cleanups
I took time for the Denali driver to catch up with the latest framework.
- switch over to exec_op() and remove legacy hooks
- separate controller/chips
- various cleanups
Major changes in v3:
- Drop "mtd: rawnand: denali: use more precise timeout for
NAND_OP_WAITRDT_INSTR"
entirely according to the review comments in v2
- Add comments to helpers in 2/9
Masahiro Yamada (9):
mtd: rawnand: denali: use nand_chip pointer more for internal
functions
mtd: rawnand: denali: refactor syndrome layout handling for raw access
mtd: rawnand: denali: remove unneeded casts in denali_{read,write}_pio
mtd: rawnand: denali: switch over to ->exec_op() from legacy hooks
mtd: rawnand: denali: use bool type instead of int where appropriate
mtd: rawnand: denali_pci: rename goto labels
mtd: rawnand: denali: decouple controller and NAND chips
mtd: rawnand: denali: remove DENALI_NR_BANKS macro
mtd: rawnand: denali: clean up coding style
.../devicetree/bindings/mtd/denali-nand.txt| 39 +-
drivers/mtd/nand/raw/denali.c | 1141 +++-
drivers/mtd/nand/raw/denali.h | 119 +-
drivers/mtd/nand/raw/denali_dt.c | 98 +-
drivers/mtd/nand/raw/denali_pci.c | 38 +-
5 files changed, 852 insertions(+), 583 deletions(-)
--
2.7.4
[PATCH v3 4/9] mtd: rawnand: denali: switch over to ->exec_op() from legacy hooks
Implement ->exec_op(), and remove the deprecated hooks.
Signed-off-by: Masahiro Yamada
---
Changes in v3:
- Fix byte-swap in denali_exec_in16()
Changes in v2: None
drivers/mtd/nand/raw/denali.c | 234 +++---
1 file changed, 126 insertions(+), 108 deletions(-)
diff --git a/drivers/mtd/nand/raw/denali.c b/drivers/mtd/nand/raw/denali.c
index d2040b7..2c7dc9b 100644
--- a/drivers/mtd/nand/raw/denali.c
+++ b/drivers/mtd/nand/raw/denali.c
@@ -206,85 +206,11 @@ static uint32_t denali_wait_for_irq(struct
denali_nand_info *denali,
return denali->irq_status;
}
-static void denali_read_buf(struct nand_chip *chip, uint8_t *buf, int len)
+static void denali_select_target(struct nand_chip *chip, int cs)
{
- struct mtd_info *mtd = nand_to_mtd(chip);
- struct denali_nand_info *denali = mtd_to_denali(mtd);
- u32 addr = DENALI_MAP11_DATA | DENALI_BANK(denali);
- int i;
-
- for (i = 0; i < len; i++)
- buf[i] = denali->host_read(denali, addr);
-}
-
-static void denali_write_buf(struct nand_chip *chip, const uint8_t *buf,
-int len)
-{
- struct denali_nand_info *denali = mtd_to_denali(nand_to_mtd(chip));
- u32 addr = DENALI_MAP11_DATA | DENALI_BANK(denali);
- int i;
-
- for (i = 0; i < len; i++)
- denali->host_write(denali, addr, buf[i]);
-}
-
-static void denali_read_buf16(struct nand_chip *chip, uint8_t *buf, int len)
-{
- struct denali_nand_info *denali = mtd_to_denali(nand_to_mtd(chip));
- u32 addr = DENALI_MAP11_DATA | DENALI_BANK(denali);
- uint16_t *buf16 = (uint16_t *)buf;
- int i;
-
- for (i = 0; i < len / 2; i++)
- buf16[i] = denali->host_read(denali, addr);
-}
-
-static void denali_write_buf16(struct nand_chip *chip, const uint8_t *buf,
- int len)
-{
- struct denali_nand_info *denali = mtd_to_denali(nand_to_mtd(chip));
- u32 addr = DENALI_MAP11_DATA | DENALI_BANK(denali);
- const uint16_t *buf16 = (const uint16_t *)buf;
- int i;
-
- for (i = 0; i < len / 2; i++)
- denali->host_write(denali, addr, buf16[i]);
-}
-
-static uint8_t denali_read_byte(struct nand_chip *chip)
-{
- uint8_t byte;
-
- denali_read_buf(chip, &byte, 1);
-
- return byte;
-}
-
-static void denali_write_byte(struct nand_chip *chip, uint8_t byte)
-{
- denali_write_buf(chip, &byte, 1);
-}
-
-static void denali_cmd_ctrl(struct nand_chip *chip, int dat, unsigned int ctrl)
-{
- struct denali_nand_info *denali = mtd_to_denali(nand_to_mtd(chip));
- uint32_t type;
-
- if (ctrl & NAND_CLE)
- type = DENALI_MAP11_CMD;
- else if (ctrl & NAND_ALE)
- type = DENALI_MAP11_ADDR;
- else
- return;
-
- /*
-* Some commands are followed by chip->legacy.waitfunc.
-* irq_status must be cleared here to catch the R/B# interrupt later.
-*/
- if (ctrl & NAND_CTRL_CHANGE)
- denali_reset_irq(denali);
+ struct denali_nand_info *denali = to_denali(chip);
- denali->host_write(denali, DENALI_BANK(denali) | type, dat);
+ denali->active_bank = cs;
}
static int denali_check_erased_page(struct nand_chip *chip,
@@ -596,6 +522,8 @@ static int denali_data_xfer(struct nand_chip *chip, void
*buf, size_t size,
{
struct denali_nand_info *denali = to_denali(chip);
+ denali_select_target(chip, chip->cur_cs);
+
iowrite32(raw ? 0 : ECC_ENABLE__FLAG, denali->reg + ECC_ENABLE);
iowrite32(raw ? TRANSFER_SPARE_REG__FLAG : 0,
denali->reg + TRANSFER_SPARE_REG);
@@ -882,24 +810,6 @@ static int denali_write_page(struct nand_chip *chip, const
uint8_t *buf,
0, 1);
}
-static void denali_select_chip(struct nand_chip *chip, int cs)
-{
- struct denali_nand_info *denali = mtd_to_denali(nand_to_mtd(chip));
-
- denali->active_bank = cs;
-}
-
-static int denali_waitfunc(struct nand_chip *chip)
-{
- struct denali_nand_info *denali = mtd_to_denali(nand_to_mtd(chip));
- uint32_t irq_status;
-
- /* R/B# pin transitioned from low to high? */
- irq_status = denali_wait_for_irq(denali, INTR__INT_ACT);
-
- return irq_status & INTR__INT_ACT ? 0 : NAND_STATUS_FAIL;
-}
-
static int denali_setup_data_interface(struct nand_chip *chip, int chipnr,
const struct nand_data_interface *conf)
{
@@ -1211,13 +1121,6 @@ static int denali_attach_chip(struct nand_chip *chip)
mtd_set_ooblayout(mtd, &denali_ooblayout_ops);
- if (chip->options & NAND_BUSWIDTH_16) {
- chip->legacy.read_buf = denali_read_buf16;
- chip->legacy.write_buf = denali_write_buf16;
- } else {
- chip->legacy.read_buf = denali_read_buf;
- chip->legacy.write_buf = denali_write_buf
[PATCH v3 8/9] mtd: rawnand: denali: remove DENALI_NR_BANKS macro
Use the runtime-detected denali->nbanks instead of hard-coded
DENALI_NR_BANKS (=4).
The actual number of banks depends on the IP configuration, and
can be less than DENALI_NR_BANKS. It is pointless to touch
registers of unsupported banks.
Signed-off-by: Masahiro Yamada
---
Changes in v3: None
Changes in v2: None
drivers/mtd/nand/raw/denali.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/mtd/nand/raw/denali.c b/drivers/mtd/nand/raw/denali.c
index 0c47c56..b1a4d9c 100644
--- a/drivers/mtd/nand/raw/denali.c
+++ b/drivers/mtd/nand/raw/denali.c
@@ -40,7 +40,6 @@
#define DENALI_BANK(denali)((denali)->active_bank << 24)
#define DENALI_INVALID_BANK-1
-#define DENALI_NR_BANKS4
static struct denali_chip *to_denali_chip(struct nand_chip *chip)
{
@@ -92,7 +91,7 @@ static void denali_enable_irq(struct denali_controller
*denali)
{
int i;
- for (i = 0; i < DENALI_NR_BANKS; i++)
+ for (i = 0; i < denali->nbanks; i++)
iowrite32(U32_MAX, denali->reg + INTR_EN(i));
iowrite32(GLOBAL_INT_EN_FLAG, denali->reg + GLOBAL_INT_ENABLE);
}
@@ -101,7 +100,7 @@ static void denali_disable_irq(struct denali_controller
*denali)
{
int i;
- for (i = 0; i < DENALI_NR_BANKS; i++)
+ for (i = 0; i < denali->nbanks; i++)
iowrite32(0, denali->reg + INTR_EN(i));
iowrite32(0, denali->reg + GLOBAL_INT_ENABLE);
}
@@ -117,7 +116,7 @@ static void denali_clear_irq_all(struct denali_controller
*denali)
{
int i;
- for (i = 0; i < DENALI_NR_BANKS; i++)
+ for (i = 0; i < denali->nbanks; i++)
denali_clear_irq(denali, i, U32_MAX);
}
@@ -130,7 +129,7 @@ static irqreturn_t denali_isr(int irq, void *dev_id)
spin_lock(&denali->irq_lock);
- for (i = 0; i < DENALI_NR_BANKS; i++) {
+ for (i = 0; i < denali->nbanks; i++) {
irq_status = ioread32(denali->reg + INTR_STATUS(i));
if (irq_status)
ret = IRQ_HANDLED;
--
2.7.4
[PATCH v3 7/9] mtd: rawnand: denali: decouple controller and NAND chips
Currently, this driver sticks to the legacy NAND model because it was
upstreamed before commit 2d472aba15ff ("mtd: nand: document the NAND
controller/NAND chip DT representation"). However, relying on the
dummy_controller is already deprecated.
Switch over to the new controller/chip representation.
The struct denali_nand_info has been split into denali_controller
and denali_chip, to contain the controller data, per-chip data,
respectively.
One problem is, this commit changes the DT binding. So, as always,
the backward compatibility must be taken into consideration.
In the new binding, the controller node expects
#address-cells = <1>;
#size-cells = <0>;
... since the child nodes represent NAND chips.
In the old binding, the controller node may have subnodes, but they
are MTD partitions.
The denali_dt_is_legacy_binding() exploits it to distinguish old/new
platforms.
Going forward, the old binding is only allowed for existing DT files.
I updated the binding document.
Signed-off-by: Masahiro Yamada
Acked-by: Rob Herring
---
Changes in v3:
- simplify mtd->name fallback
- Add Rob's Ack
Changes in v2: None
.../devicetree/bindings/mtd/denali-nand.txt| 39 +-
drivers/mtd/nand/raw/denali.c | 441 -
drivers/mtd/nand/raw/denali.h | 117 +-
drivers/mtd/nand/raw/denali_dt.c | 98 -
drivers/mtd/nand/raw/denali_pci.c | 30 +-
5 files changed, 488 insertions(+), 237 deletions(-)
diff --git a/Documentation/devicetree/bindings/mtd/denali-nand.txt
b/Documentation/devicetree/bindings/mtd/denali-nand.txt
index f33da87..de4ddff 100644
--- a/Documentation/devicetree/bindings/mtd/denali-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/denali-nand.txt
@@ -7,34 +7,47 @@ Required properties:
"socionext,uniphier-denali-nand-v5b" - for Socionext UniPhier (v5b)
- reg : should contain registers location and length for data and reg.
- reg-names: Should contain the reg names "nand_data" and "denali_reg"
+ - #address-cells: should be 1. The cell encodes the chip select connection.
+ - #size-cells : should be 0.
- interrupts : The interrupt number.
- clocks: should contain phandle of the controller core clock, the bus
interface clock, and the ECC circuit clock.
- clock-names: should contain "nand", "nand_x", "ecc"
-Optional properties:
- - nand-ecc-step-size: see nand.txt for details. If present, the value must
be
- 512for "altr,socfpga-denali-nand"
- 1024 for "socionext,uniphier-denali-nand-v5a"
- 1024 for "socionext,uniphier-denali-nand-v5b"
- - nand-ecc-strength: see nand.txt for details. Valid values are:
- 8, 15 for "altr,socfpga-denali-nand"
- 8, 16, 24 for "socionext,uniphier-denali-nand-v5a"
- 8, 16 for "socionext,uniphier-denali-nand-v5b"
- - nand-ecc-maximize: see nand.txt for details
-
-The device tree may optionally contain sub-nodes describing partitions of the
+Sub-nodes:
+ Sub-nodes represent available NAND chips.
+
+ Required properties:
+- reg: should contain the bank ID of the controller to which each chip
+ select is connected.
+
+ Optional properties:
+- nand-ecc-step-size: see nand.txt for details. If present, the value
must be
+512for "altr,socfpga-denali-nand"
+1024 for "socionext,uniphier-denali-nand-v5a"
+1024 for "socionext,uniphier-denali-nand-v5b"
+- nand-ecc-strength: see nand.txt for details. Valid values are:
+8, 15 for "altr,socfpga-denali-nand"
+8, 16, 24 for "socionext,uniphier-denali-nand-v5a"
+8, 16 for "socionext,uniphier-denali-nand-v5b"
+- nand-ecc-maximize: see nand.txt for details
+
+The chip nodes may optionally contain sub-nodes describing partitions of the
address space. See partition.txt for more detail.
Examples:
nand: nand@ff90 {
#address-cells = <1>;
- #size-cells = <1>;
+ #size-cells = <0>;
compatible = "altr,socfpga-denali-nand";
reg = <0xff90 0x20>, <0xffb8 0x1000>;
reg-names = "nand_data", "denali_reg";
clocks = <&nand_clk>, <&nand_x_clk>, <&nand_ecc_clk>;
clock-names = "nand", "nand_x", "ecc";
interrupts = <0 144 4>;
+
+ nand@0 {
+ reg = <0>;
+ }
};
diff --git a/drivers/mtd/nand/raw/denali.c b/drivers/mtd/nand/raw/denali.c
index 05fbe8f..0c47c56 100644
--- a/drivers/mtd/nand/raw/denali.c
+++ b/drivers/mtd/nand/raw/denali.c
@@ -3,7 +3,7 @@
* NAND Flash Controller Device Driver
* Copyright © 2009-2010, Intel Corporation and its suppliers.
*
- * Copyright (c) 2017 Socionext Inc.
+ * Copyright (c) 2017-2019 Socionext Inc.
* Reworked by Masahiro Yamada
*/
@@ -42,14 +42,15 @@
#define DENALI_INVALID_BANK-1
#define DENALI_NR_BANKS4
-static inline struct denali_nand_info *mtd_to_denali(struct mtd_info *mtd
Re: New syscalls (was: Re: linux-next: manual merge of the pidfd tree with the y2038 tree (now block and tip trees))
On March 12, 2019 9:31:33 AM GMT+01:00, Arnd Bergmann wrote: >On Mon, Mar 11, 2019 at 10:43 PM Christian Brauner > wrote: >> On Mon, Mar 11, 2019 at 10:38:07PM +0100, Arnd Bergmann wrote: >> > On Mon, Mar 11, 2019 at 9:36 AM Geert Uytterhoeven > wrote: >> > > >> > > Shall each architcture maintainer take care of this hxxself, or >will >> > > this be done in >> > > a coordinated way? >> > >> > I was planning to send a patch for all architectures this time >> > (after all three sets are merged, which is now), and ask future >> >> Just to clarify, are you referring to your sets? I think Linus hasn't >> gotten around to reviewing the PR for pidfd_send_signal() yet. :) > >Ah, I thought he had already merged both, the confusion was on >my end. I think I'll do a GIT PULL RESEND later today since I sent the original pr last Tuesday. Christian > > Arnd
Re: [PATCH v2] drivers: gpio: sprd: use devm_platform_ioremap_resource()
On Tue, 12 Mar 2019 at 16:08, Enrico Weigelt, metux IT consult wrote: > > Use the new helper that wraps the calls to platform_get_resource() > and devm_ioremap_resource() together. > > Signed-off-by: Enrico Weigelt, metux IT consult > --- > drivers/gpio/gpio-eic-sprd.c | 9 ++--- > 1 file changed, 2 insertions(+), 7 deletions(-) > > diff --git a/drivers/gpio/gpio-eic-sprd.c b/drivers/gpio/gpio-eic-sprd.c > index f0223ce..462cdf4 100644 > --- a/drivers/gpio/gpio-eic-sprd.c > +++ b/drivers/gpio/gpio-eic-sprd.c > @@ -567,7 +567,6 @@ static int sprd_eic_probe(struct platform_device *pdev) > const struct sprd_eic_variant_data *pdata; > struct gpio_irq_chip *irq; > struct sprd_eic *sprd_eic; > - struct resource *res; > int ret, i; > > pdata = of_device_get_match_data(&pdev->dev); > @@ -596,13 +595,9 @@ static int sprd_eic_probe(struct platform_device *pdev) > * have one bank EIC, thus base[1] and base[2] can be > * optional. > */ > - res = platform_get_resource(pdev, IORESOURCE_MEM, i); > - if (!res) > - continue; > - > - sprd_eic->base[i] = devm_ioremap_resource(&pdev->dev, res); > + sprd_eic->base[i] = devm_platform_ioremap_resource(pdev, i); > if (IS_ERR(sprd_eic->base[i])) > - return PTR_ERR(sprd_eic->base[i]); > + continue; > } I still do not think the new API is suitable for this case. Since we can have optional multiple IO resources, so the original code will not return errors if we did not get the IO resources, but we must cast errors if we failed to do ioremap. But you ignore the errors of ioremap, which is not good. -- Baolin Wang Best Regards
Re: [PATCH] ARM: dts: rockchip: fix rk3288 cpu opp node reference
Am Sonntag, 24. Februar 2019, 22:51:22 CET schrieb Jonas Karlman:
> The following error can be seen during boot:
>
> of: /cpus/cpu@501: Couldn't find opp node
>
> Change cpu nodes to use operating-points-v2 in order to fix this.
>
> Fixes: ce76de984649 ("ARM: dts: rockchip: convert rk3288 to
> operating-points-v2")
> Signed-off-by: Jonas Karlman
added a Cc-stable tag and applied as fix for 5.1
Thanks for catching this
Heiko
[PATCH] kernel/trace/trace_probe.c - make variable static
sparse complains:
CHECK kernel/trace/trace_probe.c
kernel/trace/trace_probe.c:16:12: warning: symbol 'reserved_field_names' was
not declared. Should it be static?
Yes, it should be static.
Signed-off-by: Valdis Kletnieks
diff --git a/kernel/trace/trace_probe.c b/kernel/trace/trace_probe.c
index 89da34b326e3..cfcf77e6fb19 100644
--- a/kernel/trace/trace_probe.c
+++ b/kernel/trace/trace_probe.c
@@ -13,7 +13,7 @@
#include "trace_probe.h"
-const char *reserved_field_names[] = {
+static const char *reserved_field_names[] = {
"common_type",
"common_flags",
"common_preempt_count",
Re: [PATCH v9 9/9] gpio: uniphier: Utilize for_each_set_clump8 macro
On Tue, Mar 12, 2019 at 4:19 PM Andy Shevchenko wrote: > > On Tue, Mar 12, 2019 at 6:40 AM Masahiro Yamada > wrote: > > On Sun, Mar 3, 2019 at 4:51 PM William Breathitt Gray > > wrote: > > > > > > Replace verbose implementation in set_multiple callback with > > > for_each_set_clump8 macro to simplify code and improve clarity. An > > > improvement in this case is that banks that are not masked will now be > > > skipped. > > > Please do not do this. > > > > Nothing in this driver says the GPIO width is 8-bit. > > Huh? > > https://elixir.bootlin.com/linux/latest/source/include/dt-bindings/gpio/uniphier-gpio.h#L9 > > Isn't a hardcoding? Semi-hardcoding. I needed to factor out some magic numbers shared between DT and drivers. Then, dt-bindings is out of realm of operating system. If I am doing wrong, I take back my comments, though. -- Best Regards Masahiro Yamada
[PATCH] kernel/trace/trace_kprobe.c - fix comment format
CC kernel/trace/trace_kprobe.o
kernel/trace/trace_kprobe.c:41: warning: cannot understand function prototype:
'struct trace_kprobe '
The real problem is that a comment looked like kerneldoc when it shouldn't be...
Signed-off-by: Valdis Kletnieks
diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index 9eaf07f99212..c825c591553a 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -35,7 +35,7 @@ static struct dyn_event_operations trace_kprobe_ops = {
.match = trace_kprobe_match,
};
-/**
+/*
* Kprobe event core functions
*/
struct trace_kprobe {
Re: [PATCH] arm64: dts: meson-gxl-s905d-phicomm-n1: add status LED
Hi Chuanhong,
On 12/03/2019 09:33, Chuanhong Guo wrote:
> There is a white LED on the front panel behind the logo and the
> manufacturer uses that LED to indicate network and USB drive status.
>
> Signed-off-by: Chuanhong Guo
> ---
> .../boot/dts/amlogic/meson-gxl-s905d-phicomm-n1.dts| 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-phicomm-n1.dts
> b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-phicomm-n1.dts
> index 9a8a8a7e4b53..b5667f1fb2c8 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-phicomm-n1.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-phicomm-n1.dts
> @@ -14,6 +14,16 @@
> cvbs-connector {
> status = "disabled";
> };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + status {
> + label = "n1:white:status";
> + gpios = <&gpio_ao GPIOAO_9 GPIO_ACTIVE_HIGH>;
> + default-state = "on";
> + };
> + };
> };
>
> &cvbs_vdac_port {
>
Reviewed-by: Neil Armstrong
BTW, do you know if it's possible to have a sample of the Phicomm N1
in order to be added in kernelci ?
Neil
Re: WARN ON at kernel/sched/deadline.c task_non_contending
Hi all, On Tue, 12 Mar 2019 10:03:12 +0800 "chengjian (D)" wrote: > Hi. > > When looking to test SCHED_DEADLINE syzkaller report an warn in > task_non_contending(). I tested the mainline kernel with the C program > and captured the same call trace. [...] > diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c > index 31c050a0d0ce..d73cb033a06d 100644 > --- a/kernel/sched/deadline.c > +++ b/kernel/sched/deadline.c > @@ -252,7 +252,6 @@ static void task_non_contending(struct > task_struct *p) if (dl_entity_is_special(dl_se)) > return; > > - WARN_ON(hrtimer_active(&dl_se->inactive_timer)); > WARN_ON(dl_se->dl_non_contending); > > zerolag_time = dl_se->deadline - > @@ -287,7 +286,9 @@ static void task_non_contending(struct > task_struct *p) } > > dl_se->dl_non_contending = 1; > - get_task_struct(p); > + > + if (!hrtimer_active(&dl_se->inactive_timer)); > + get_task_struct(p); > hrtimer_start(timer, ns_to_ktime(zerolag_time), > HRTIMER_MODE_REL); } At a first glance, I think the patch is OK, but I need some more time to look at the details. I'll run some experiments with the reproducer, and I'll let you know my conclusions. > Did I miss something ? > > I saw it directly remove the hrtimer in hrtime_start() if hrtime is > queued, it may be unsafe here when the timer handler is running. This is probably why I added that WARN_ON()... I'll look at a possible solution. Thanks, Luca > > Help ? > > I put the syzkaller log and C demo in attachments. > > Thanks. > > >
Re: [PATCH v1] Bluetooth: hci_qca: Enable the ldisc for ROME for x86 platforms.
在 2019-03-09 02:52，Matthias Kaehlcke 写道：
On Fri, Mar 08, 2019 at 10:43:14AM +0530, Balakrishna Godavarthi wrote:
Hi Matthias,
On 2019-03-08 02:12, Matthias Kaehlcke wrote:
> Hi Balakrishna,
>
> On Thu, Mar 07, 2019 at 03:47:22PM +0530, Balakrishna Godavarthi wrote:
> > When using btattach to setup Rome over ldisc we observed a crash
> > in qca_setup as it will try to access the serdev which is not
> > available in the ldisc proto. This patch will fix the crash by
> > support both the ldisc and serdev way in the qca hci_uart driver.
> >
> > Signed-off-by: Balakrishna Godavarthi
>
> Oh, I wasn't aware of the instantiation through ldisc and was actually
> considering to *remove* some of the seemingly unnecessary serdev
> checks.
>
> > ---
> > drivers/bluetooth/hci_qca.c | 47
> > ++---
> > 1 file changed, 28 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
> > index 237aea34b69f..0a5c98d46864 100644
> > --- a/drivers/bluetooth/hci_qca.c
> > +++ b/drivers/bluetooth/hci_qca.c
> > @@ -963,7 +963,7 @@ static int qca_set_baudrate(struct hci_dev
> > *hdev, uint8_t baudrate)
> > {
> > struct hci_uart *hu = hci_get_drvdata(hdev);
> > struct qca_data *qca = hu->priv;
> > - struct qca_serdev *qcadev;
> > + struct qca_serdev *qcadev = NULL;
>
> In many cases the only field that is accessed is qcadev->btsoc_type. I
> think something like 'qca_get_soc_type(struct hci_dev *hdev / struct
> hci_uart *hu)' would make things more readable.
>
[Bala]: sure will update this in other patch once this change is
landed as
this has to
go in priority as we have crash coming.
That's not how things should work, especially for fairly trivial
changes. It requires reviewers to first spent time to review the patch
that adds clutter and later spend more time to review the one that
removes it. It's also easier to get a clean patch merged in the first
place, rather than a noisy one.
Anyway, here is my take at it:
https://lore.kernel.org/patchwork/patch/1049014/
Please help with testing for ROME, unless you disagree with the
approach.
Thanks
Matthias
Hi Matthias,
I will test your patch and update to you, and you are correct that
AR3002 is not part of Rome family, you should use QCA_ROME as the
default return of qca_soc_type. Could you also loop me in
https://lore.kernel.org/patchwork/patch/1049014/?
Thanks,
Rocky
Re: [PATCH v3 4/9] mtd: rawnand: denali: switch over to ->exec_op() from legacy hooks
On Tue, 12 Mar 2019 17:44:45 +0900
Masahiro Yamada wrote:
> +
> +static int denali_exec_instr(struct nand_chip *chip,
> + const struct nand_op_instr *instr)
> +{
> + struct denali_nand_info *denali = to_denali(chip);
> + bool width16 = chip->options & NAND_BUSWIDTH_16;
> +
> + switch (instr->type) {
> + case NAND_OP_CMD_INSTR:
> + denali_exec_out8(denali, DENALI_MAP11_CMD,
> + &instr->ctx.cmd.opcode, 1);
> + return 0;
> + case NAND_OP_ADDR_INSTR:
> + denali_exec_out8(denali, DENALI_MAP11_ADDR,
> + instr->ctx.addr.addrs,
> + instr->ctx.addr.naddrs);
> + return 0;
> + case NAND_OP_DATA_IN_INSTR:
> + (!instr->ctx.data.force_8bit && width16 ?
> + denali_exec_in16 :
> + denali_exec_in8)(denali, DENALI_MAP11_DATA,
> + instr->ctx.data.buf.in,
> + instr->ctx.data.len);
I agree with Miquel, this statement tends to obfuscate the code, and
it's not like an extra if will make a huge difference in term of LOC.
> + return 0;
> + case NAND_OP_DATA_OUT_INSTR:
> + (!instr->ctx.data.force_8bit && width16 ?
> + denali_exec_out16 :
> + denali_exec_out8)(denali, DENALI_MAP11_DATA,
> +instr->ctx.data.buf.out,
> +instr->ctx.data.len);
Ditto.
> + return 0;
> + case NAND_OP_WAITRDY_INSTR:
> + return denali_exec_waitrdy(denali);
> + default:
> + WARN_ONCE(1, "unsupported NAND instruction type: %d\n",
> + instr->type);
> +
> + return -EINVAL;
> + }
> +}
[GIT PULL] overlayfs update for 5.1
Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git tags/ovl-update-5.1 Fix copy up of security related xattrs. Thanks, Miklos Vivek Goyal (2): ovl: During copy up, first copy up data and then xattrs ovl: Do not lose security.capability xattr over metadata file copy-up --- fs/overlayfs/copy_up.c | 59 fs/overlayfs/overlayfs.h | 2 ++ fs/overlayfs/util.c | 55 3 files changed, 81 insertions(+), 35 deletions(-)
Re: [PATCH 1/2] PM / wakeup: Remove timer from wakeup_source_remove()
On Tue, Mar 12, 2019 at 4:28 AM Viresh Kumar wrote:
>
> On 11-03-19, 13:05, Rafael J. Wysocki wrote:
> > On Friday, March 8, 2019 10:53:11 AM CET Viresh Kumar wrote:
> > > wakeup_source_remove() is the counterpart of wakeup_source_add() helper
> > > and must undo the initializations done by wakeup_source_add(). Currently
> > > the timer is initialized by wakeup_source_add() but removed from
> > > wakeup_source_drop(), which doesn't look logically correct. Also it
> > > should be okay to call wakeup_source_add() right after calling
> > > wakeup_source_remove(), and in that case we may end up calling
> > > timer_setup() for a potentially scheduled timer which is surely
> > > incorrect.
> > >
> > > Move the timer removal part to wakeup_source_remove() instead.
> > >
> > > Signed-off-by: Viresh Kumar
> > > ---
> > > drivers/base/power/wakeup.c | 3 ++-
> > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/base/power/wakeup.c b/drivers/base/power/wakeup.c
> > > index f1fee72ed970..18333962e3da 100644
> > > --- a/drivers/base/power/wakeup.c
> > > +++ b/drivers/base/power/wakeup.c
> > > @@ -118,7 +118,6 @@ void wakeup_source_drop(struct wakeup_source *ws)
> > > if (!ws)
> > > return;
> > >
> > > - del_timer_sync(&ws->timer);
> > > __pm_relax(ws);
> > > }
> > > EXPORT_SYMBOL_GPL(wakeup_source_drop);
> > > @@ -205,6 +204,8 @@ void wakeup_source_remove(struct wakeup_source *ws)
> > > list_del_rcu(&ws->entry);
> > > raw_spin_unlock_irqrestore(&events_lock, flags);
> > > synchronize_srcu(&wakeup_srcu);
> > > +
> > > + del_timer_sync(&ws->timer);
> > > }
> > > EXPORT_SYMBOL_GPL(wakeup_source_remove);
> > >
> > >
> >
> > I've merged it with the [2/2], rewritten the subject and changelog and
> > queued the result as commit d856f39ac1cc ("PM / wakeup: Rework wakeup
> > source timer cancellation").
>
> Okay, thanks. We (Android guys) want this to be backported into 4.4+
> kernels via the stable tree. Can we mark this for stable in the commit
> itself ? Else I would be required to send this separately for all the
> kernels. I should have marked it for stable initially though, sorry
> about forgetting then.
Queued up with a CC-stable tag for 4.4 an later, thanks!
[PATCH 0/2] clk: keystone: Add new driver to handle syscon based clock
On TI's K2 and K3 SoCs, certain clocks can be gated/ungated by setting a single bit in SoC's System Control registers. Sometime more than one clock control can be in the same register. But these registers might also have bits to control other SoC functionalities. For example, Time Base clock(tbclk) enable bits for various EPWM IPs are all in EPWM_CTRL Syscon registers on K2G SoC. This series adds a new clk driver to support such clocks. Registers which control clocks will be grouped into a syscon DT node, thus enabling sharing of register across clk drivers and other drivers. Each clock node will be child of the syscon node describing offset and bit within the regmap that controls the clock output. Vignesh Raghavendra (2): dt-bindings: clock: Add binding documentation for TI syscon gate clock clk: keystone: Add new driver to handle syscon based clock .../bindings/clock/ti,syscon-gate-clock.txt | 35 + drivers/clk/keystone/Kconfig | 8 + drivers/clk/keystone/Makefile | 1 + drivers/clk/keystone/syscon-clk.c | 143 ++ 4 files changed, 187 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/ti,syscon-gate-clock.txt create mode 100644 drivers/clk/keystone/syscon-clk.c -- 2.21.0
Re: [PATCH 1/2] PM / wakeup: Remove timer from wakeup_source_remove()
On Tue 2019-03-12 08:58:02, Viresh Kumar wrote:
> On 11-03-19, 13:05, Rafael J. Wysocki wrote:
> > On Friday, March 8, 2019 10:53:11 AM CET Viresh Kumar wrote:
> > > wakeup_source_remove() is the counterpart of wakeup_source_add() helper
> > > and must undo the initializations done by wakeup_source_add(). Currently
> > > the timer is initialized by wakeup_source_add() but removed from
> > > wakeup_source_drop(), which doesn't look logically correct. Also it
> > > should be okay to call wakeup_source_add() right after calling
> > > wakeup_source_remove(), and in that case we may end up calling
> > > timer_setup() for a potentially scheduled timer which is surely
> > > incorrect.
> > >
> > > Move the timer removal part to wakeup_source_remove() instead.
> >
> > I've merged it with the [2/2], rewritten the subject and changelog and
> > queued the result as commit d856f39ac1cc ("PM / wakeup: Rework wakeup
> > source timer cancellation").
>
> Okay, thanks. We (Android guys) want this to be backported into 4.4+
> kernels via the stable tree. Can we mark this for stable in the commit
> itself ? Else I would be required to send this separately for all the
> kernels. I should have marked it for stable initially though, sorry
> about forgetting then.
Greg is normally pretty agressive about backporting everything
remotely looking like a fix...
But better changelog would help. How is the bug actually affecting
users?
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
[PATCH 2/2] clk: keystone: Add new driver to handle syscon based clock
On TI's K2 and K3 SoCs, certain clocks can be gated/ungated by setting a
single bit in SoC's System Control Module registers. Sometime more than
one clock control can be in the same register.
Add driver to support such clocks. Registers that control clocks will be
grouped into a syscon regmap. Each clock node will be child of the
syscon node.
Signed-off-by: Vignesh Raghavendra
---
drivers/clk/keystone/Kconfig | 8 ++
drivers/clk/keystone/Makefile | 1 +
drivers/clk/keystone/syscon-clk.c | 143 ++
3 files changed, 152 insertions(+)
create mode 100644 drivers/clk/keystone/syscon-clk.c
diff --git a/drivers/clk/keystone/Kconfig b/drivers/clk/keystone/Kconfig
index b04927d06cd1..6a7b80ee62c9 100644
--- a/drivers/clk/keystone/Kconfig
+++ b/drivers/clk/keystone/Kconfig
@@ -14,3 +14,11 @@ config TI_SCI_CLK
This adds the clock driver support over TI System Control Interface.
If you wish to use clock resources from the PMMC firmware, say Y.
Otherwise, say N.
+
+config TI_SYSCON_CLK
+ tristate "Syscon based clock driver for K2/K3 SoCs"
+ depends on (ARCH_KEYSTONE || ARCH_K3 || COMPILE_TEST) && OF
+ default (ARCH_KEYSTONE || ARCH_K3)
+ help
+ This adds clock driver support for syscon based gate
+ clocks on TI's K2 and K3 SoCs.
diff --git a/drivers/clk/keystone/Makefile b/drivers/clk/keystone/Makefile
index c12593966f9b..30e481386316 100644
--- a/drivers/clk/keystone/Makefile
+++ b/drivers/clk/keystone/Makefile
@@ -1,2 +1,3 @@
obj-$(CONFIG_COMMON_CLK_KEYSTONE) += pll.o gate.o
obj-$(CONFIG_TI_SCI_CLK) += sci-clk.o
+obj-$(CONFIG_TI_SYSCON_CLK)+= syscon-clk.o
diff --git a/drivers/clk/keystone/syscon-clk.c
b/drivers/clk/keystone/syscon-clk.c
new file mode 100644
index ..063a8e5df324
--- /dev/null
+++ b/drivers/clk/keystone/syscon-clk.c
@@ -0,0 +1,143 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
+//
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct ti_syscon_gate_clk_priv {
+ struct clk_hw hw;
+ struct regmap *regmap;
+ u32 reg;
+ u32 idx;
+};
+
+static struct
+ti_syscon_gate_clk_priv *to_ti_syscon_gate_clk_priv(struct clk_hw *hw)
+{
+ return container_of(hw, struct ti_syscon_gate_clk_priv, hw);
+}
+
+static int ti_syscon_gate_clk_enable(struct clk_hw *hw)
+{
+ struct ti_syscon_gate_clk_priv *priv = to_ti_syscon_gate_clk_priv(hw);
+
+ return regmap_write_bits(priv->regmap, priv->reg, priv->idx,
+priv->idx);
+}
+
+static void ti_syscon_gate_clk_disable(struct clk_hw *hw)
+{
+ struct ti_syscon_gate_clk_priv *priv = to_ti_syscon_gate_clk_priv(hw);
+
+ regmap_write_bits(priv->regmap, priv->reg, priv->idx, 0);
+}
+
+static int ti_syscon_gate_clk_is_enabled(struct clk_hw *hw)
+{
+ unsigned int val;
+ struct ti_syscon_gate_clk_priv *priv = to_ti_syscon_gate_clk_priv(hw);
+
+ regmap_read(priv->regmap, priv->reg, &val);
+
+ return !!(val & priv->idx);
+}
+
+static const struct clk_ops ti_syscon_gate_clk_ops = {
+ .enable = ti_syscon_gate_clk_enable,
+ .disable= ti_syscon_gate_clk_disable,
+ .is_enabled = ti_syscon_gate_clk_is_enabled,
+};
+
+static int ti_syscon_gate_clk_probe(struct platform_device *pdev)
+{
+ struct device_node *node = pdev->dev.of_node;
+ struct ti_syscon_gate_clk_priv *priv;
+ struct device *dev = &pdev->dev;
+ struct clk_init_data init;
+ unsigned long flags = 0;
+ const char *parent_name;
+ struct clk *parent;
+ u32 idx;
+ int ret;
+
+ priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ priv->regmap = syscon_node_to_regmap(of_get_parent(node));
+ if (IS_ERR(priv->regmap)) {
+ if (PTR_ERR(priv->regmap) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+ dev_err(dev, "failed to find parent regmap\n");
+ return PTR_ERR(priv->regmap);
+ }
+
+ if (of_property_read_u32(node, "reg", &priv->reg)) {
+ dev_err(dev, "missing reg property\n");
+ return -EINVAL;
+ }
+
+ if (of_property_read_u32(node, "ti,clock-bit-idx", &idx)) {
+ dev_err(dev, "missing ti,bit-shift property\n");
+ return -EINVAL;
+ }
+ priv->idx = BIT(idx);
+
+ if (of_clk_get_parent_count(node) != 1) {
+ dev_err(dev, "must have clk parent\n");
+ return -EINVAL;
+ }
+
+ parent = devm_clk_get(dev, NULL);
+ if (IS_ERR(parent)) {
+ if (PTR_ERR(priv->regmap) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+ return PTR_ERR(parent);
+ }
+
+ parent_name = __clk_get_
[PATCH 1/2] dt-bindings: clock: Add binding documentation for TI syscon gate clock
Add dt bindings for TI syscon gate clock.
Signed-off-by: Vignesh Raghavendra
---
.../bindings/clock/ti,syscon-gate-clock.txt | 35 +++
1 file changed, 35 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/ti,syscon-gate-clock.txt
diff --git a/Documentation/devicetree/bindings/clock/ti,syscon-gate-clock.txt
b/Documentation/devicetree/bindings/clock/ti,syscon-gate-clock.txt
new file mode 100644
index ..f2bc4281ddba
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti,syscon-gate-clock.txt
@@ -0,0 +1,35 @@
+TI syscon gate clock
+
+The gate clock node must be provided inside a system controller node.
+
+Required:
+- comaptible: Must be "ti,syscon-gate-clock"
+- reg: Offset of register that controls the clock within syscon regmap
+- ti,clock-bit-idx: bit index that control gate/ungating of clock
+- clocks: phandle to the clock parent
+- #clock-cells: must be <0>
+
+Example:
+ ctrlmmr_epwm_ctrl: syscon@104140{
+ compatible = "syscon", "simple-bus";
+ reg = <0x0 0x104140 0x0 0x18>;
+ ranges = <0x0 0x0 0x104140>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ehrpwm0_tbclk: clk@0 {
+ compatible = "ti,syscon-gate-clock";
+ reg = <0x0>;
+ #clock-cells = <0>;
+ clocks = <&k3_clks 40 0>;
+ ti,clock-bit-idx = <0>;
+ };
+
+ ehrpwm1_tbclk: clk@4 {
+ compatible = "ti,syscon-gate-clock";
+ reg = <0x4>;
+ #clock-cells = <0>;
+ clocks = <&k3_clks 41 0>;
+ ti,clock-bit-idx = <0>;
+ };
+ };
--
2.21.0
Re: [RFC PATCH nand-next 0/2] meson-nand: support for older SoCs
Hi Martin and Miquel, On 2019/3/7 21:09, Miquel Raynal wrote: Hello, Martin Blumenstingl wrote on Tue, 5 Mar 2019 23:12:51 +0100: Hi Liang, On Mon, Mar 4, 2019 at 5:55 AM Liang Yang wrote: Hello Martin, On 2019/3/2 2:29, Martin Blumenstingl wrote: Hi Liang, I am trying to add support for older SoCs to the meson-nand driver. Back when the driver was in development I used an early revision (of your driver) and did some modifications to make it work on older SoCs. Now that the driver is upstream I wanted to give it another try and make a real patch out of it. Unfortunately it's not working anymore. As far as I know the NFC IP block revision on GXL is similar (or even the same?) as on all older SoCs. As far as I can tell only the clock setup is different on the older SoCs (which have a dedicated NAND clock): - we don't need the "amlogic,mmc-syscon" property on the older SoCs because we don't need to setup any muxing (common clock framework will do everything for us) - "rx" and "tx" clocks don't exist - I could not find any other differences between Meson8, Meson8b, Meson8m2, GXBB and GXL That is right. the serials NFC is almost the same except: 1) The clock control and source that M8-serials are not share with EMMC. 2) The base register address 3) DMA encryption option which we don't care on NFC driver. great, thank you for confirming this! In this series I'm sending two patches which add support for the older SoCs. Unfortunately these patches are currently not working for me (hence the "RFC" prefix). I get a (strange) crash which is triggered by the kzalloc() in meson_nfc_read_buf() - see below for more details. Can you please help me on this one? I'd like to know whether: - the meson-nand driver works for you on GXL or AXG on linux-next? (I was running these patches on top of next-20190301 on my M8S board which uses a 32-bit Meson8m2 SoC. I don't have any board using a GXL SoC which also has NAND) Yes, it works on AXG platform using a MXIC slc nand flash(MX30LF4G); but i an not sure it runs the same flow with yours. because i see the print "Counld not find a valid ONFI parameter page, " in yours. i will try to reproduce it on AXG(i don't have a M8 platform now). I'm looking forward to hear about the test results on your AXG boards for reference: my board has a SK Hynix H27UCG8T2B (ID bytes: 0xad 0xde 0x94 0xeb 0x74 0x44, 20nm MLC) I have another board (where I haven't tested the NFC driver yet) with a SK Hynix H27UCG8T2E (ID bytes: 0xad 0xde 0x14 0xa7 0x42 0x4a, 1Ynm MLC). if it helps with your analysis I can test on that board as well Liang, you just have to fake the output of the ONFI page detection and you will probably run into this error which will then be easy to reproduce. i don't reproduce it by using a SK Hynix nand flash H27UCG8T2E on gxl platform. it runs well. [..] [0.977127] loop: module loaded [0.998625] Could not find a valid ONFI parameter page, trying bit-wise majority to recover it [1.001619] ONFI parameter recovery failed, aborting [1.006684] Could not find valid JEDEC parameter page; aborting [1.012391] nand: device found, Manufacturer ID: 0xad, Chip ID: 0xde [1.018660] nand: Hynix NAND 8GiB 3,3V 8-bit [1.022885] nand: 8192 MiB, MLC, erase size: 4096 KiB, page size: 16384, OOB size: 1664 [1.047033] Bad block table not found for chip 0 [1.054950] Bad block table not found for chip 0 [1.054970] Scanning device for bad blocks [1.522664] random: fast init done [4.893731] Bad eraseblock 1985 at 0x0001f07fc000 [5.020637] Bad block table written to 0x0001ffc0, version 0x01 [5.028258] Bad block table written to 0x0001ff80, version 0x01 [5.029905] 5 fixed-partitions partitions found on MTD device d0074800.nfc [5.035714] Creating 5 MTD partitions on "d0074800.nfc": [..] Martin, Now i am not sure whether NFC driver leads to kernel panic when calling kmem_cache_alloc_trace. .
[PATCH] pwm: tiehrpwm: Update shadow register for disabling PWMs
From: Christoph Vogtländer
It must be made sure that immediate mode is not already set, when
modifying shadow register value in ehrpwm_pwm_disable(). Otherwise
modifications to the action-qualifier continuous S/W force
register(AQSFRC) will be done in the active register.
This may happen when both channels are being disabled. In this case,
only the first channel state will be recorded as disabled in the shadow
register. Later, when enabling the first channel again, the second
channel would be enabled as well. Setting RLDCSF to zero, first, ensures
that the shadow register is updated as desired.
Fixes: 38dabd91ff0b ("pwm: tiehrpwm: Fix disabling of output of PWMs")
Signed-off-by: Christoph Vogtländer
[vigne...@ti.com: Improve commit message]
Signed-off-by: Vignesh Raghavendra
---
drivers/pwm/pwm-tiehrpwm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/pwm/pwm-tiehrpwm.c b/drivers/pwm/pwm-tiehrpwm.c
index f7b8a86fa5c5..ad4a40c0f27c 100644
--- a/drivers/pwm/pwm-tiehrpwm.c
+++ b/drivers/pwm/pwm-tiehrpwm.c
@@ -382,6 +382,8 @@ static void ehrpwm_pwm_disable(struct pwm_chip *chip,
struct pwm_device *pwm)
}
/* Update shadow register first before modifying active register */
+ ehrpwm_modify(pc->mmio_base, AQSFRC, AQSFRC_RLDCSF_MASK,
+ AQSFRC_RLDCSF_ZRO);
ehrpwm_modify(pc->mmio_base, AQCSFRC, aqcsfrc_mask, aqcsfrc_val);
/*
* Changes to immediate action on Action Qualifier. This puts
--
2.21.0
Re: [PATCH v9 9/9] gpio: uniphier: Utilize for_each_set_clump8 macro
On Tue, Mar 12, 2019 at 10:58 AM Masahiro Yamada wrote: > On Tue, Mar 12, 2019 at 4:19 PM Andy Shevchenko > wrote: > > On Tue, Mar 12, 2019 at 6:40 AM Masahiro Yamada > > wrote: > > > On Sun, Mar 3, 2019 at 4:51 PM William Breathitt Gray > > > wrote: > > > > > > > > Replace verbose implementation in set_multiple callback with > > > > for_each_set_clump8 macro to simplify code and improve clarity. An > > > > improvement in this case is that banks that are not masked will now be > > > > skipped. > > > > > Please do not do this. > > > > > > Nothing in this driver says the GPIO width is 8-bit. > > > > Huh? > > > > https://elixir.bootlin.com/linux/latest/source/include/dt-bindings/gpio/uniphier-gpio.h#L9 > > > > Isn't a hardcoding? > > > Semi-hardcoding. > > I needed to factor out some magic numbers > shared between DT and drivers. Effectively means you introduced an ABI, which we are not supposed to change, where the number is carved in stone for all hardware covered by this driver + DT pair. If you would ever need another one it would require extending existing bindings without dropping them away. > Then, dt-bindings is out of realm of operating system. Exactly! > If I am doing wrong, I take back my comments, though. -- With Best Regards, Andy Shevchenko
[PATCH 0/4] Loongson-32 initial DeviceTree support
Hi More works should be done after rework on clk and other drivers accepted. Thanks.
[PATCH 1/2] dt-bindings: pwm: tiehrpwm: Add TI AM654 SoC specific compatible
Add a new compatible string "ti,am654-ehrpwm" to support EHRPWM IP on TI AM654 SoC. Signed-off-by: Vignesh Raghavendra --- Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt b/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt index 944fe356bb45..31c4577157dd 100644 --- a/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt +++ b/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt @@ -4,6 +4,7 @@ Required properties: - compatible: Must be "ti,-ehrpwm". for am33xx - compatible = "ti,am3352-ehrpwm", "ti,am33xx-ehrpwm"; for am4372 - compatible = "ti,am4372-ehrpwm", "ti-am3352-ehrpwm", "ti,am33xx-ehrpwm"; + for am654 - compatible = "ti,am654-ehrpwm", "ti-am3352-ehrpwm"; for da850 - compatible = "ti,da850-ehrpwm", "ti-am3352-ehrpwm", "ti,am33xx-ehrpwm"; for dra746 - compatible = "ti,dra746-ehrpwm", "ti-am3352-ehrpwm"; - #pwm-cells: should be 3. See pwm.txt in this directory for a description of -- 2.21.0
[PATCH 2/2] pwm: Kconfig: Enable ehrpwm driver to be compiled for ARCH_K3
K3 devices have the same EHRPWM IP as OMAP SoCs. Enable driver to be built for K3 devices. Also, drop reference to AM33xx in help text, as IP is found on multiple TI SoCs. Signed-off-by: Vignesh Raghavendra --- drivers/pwm/Kconfig | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig index 54f8238aac0d..c054bd1dba36 100644 --- a/drivers/pwm/Kconfig +++ b/drivers/pwm/Kconfig @@ -467,10 +467,9 @@ config PWM_TIECAP config PWM_TIEHRPWM tristate "EHRPWM PWM support" - depends on ARCH_OMAP2PLUS || ARCH_DAVINCI_DA8XX + depends on ARCH_OMAP2PLUS || ARCH_DAVINCI_DA8XX || ARCH_K3 help - PWM driver support for the EHRPWM controller found on AM33XX - TI SOC + PWM driver support for the EHRPWM controller found on TI SOCs To compile this driver as a module, choose M here: the module will be called pwm-tiehrpwm. -- 2.21.0
[PATCH 0/2] pwm: tiehrpwm: Enable EHRPWM for AM654 SoCs
This series adds support for EHRPWM IP on TI AM654 SoC Vignesh Raghavendra (2): dt-bindings: pwm: tiehrpwm: Add TI AM654 SoC specific compatible pwm: Kconfig: Enable ehrpwm driver to be compiled for ARCH_K3 Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt | 1 + drivers/pwm/Kconfig| 5 ++--- 2 files changed, 3 insertions(+), 3 deletions(-) -- 2.21.0
linux-kernel@vger.kernel.org
Loongson-1B&C have totally identical GS232 core, so merge them into same CPU config. Signed-off-by: Jiaxun Yang --- arch/mips/Kconfig| 38 +--- arch/mips/include/asm/cpu-type.h | 3 +-- arch/mips/loongson32/Kconfig | 4 ++-- 3 files changed, 14 insertions(+), 31 deletions(-) diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 15f8cc3c965f..ac0b93e57ca3 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -1429,26 +1429,22 @@ config CPU_LOONGSON2F have a similar programming interface with FPGA northbridge used in Loongson2E. -config CPU_LOONGSON1B - bool "Loongson 1B" - depends on SYS_HAS_CPU_LOONGSON1B - select CPU_LOONGSON1 +config CPU_LOONGSON1 + bool "Loongson 1" + depends on SYS_HAS_CPU_LOONGSON1 + select CPU_MIPS32 + select CPU_MIPSR2 + select CPU_HAS_PREFETCH + select CPU_HAS_LOAD_STORE_LR + select CPU_SUPPORTS_32BIT_KERNEL + select CPU_SUPPORTS_HIGHMEM + select CPU_SUPPORTS_CPUFREQ select LEDS_GPIO_REGISTER help The Loongson 1B is a 32-bit SoC, which implements the MIPS32 Release 1 instruction set and part of the MIPS32 Release 2 instruction set. -config CPU_LOONGSON1C - bool "Loongson 1C" - depends on SYS_HAS_CPU_LOONGSON1C - select CPU_LOONGSON1 - select LEDS_GPIO_REGISTER - help - The Loongson 1C is a 32-bit SoC, which implements the MIPS32 - Release 1 instruction set and part of the MIPS32 Release 2 - instruction set. - config CPU_MIPS32_R1 bool "MIPS32 Release 1" depends on SYS_HAS_CPU_MIPS32_R1 @@ -1866,15 +1862,6 @@ config CPU_LOONGSON2 select ARCH_HAS_PHYS_TO_DMA select CPU_HAS_LOAD_STORE_LR -config CPU_LOONGSON1 - bool - select CPU_MIPS32 - select CPU_MIPSR2 - select CPU_HAS_PREFETCH - select CPU_HAS_LOAD_STORE_LR - select CPU_SUPPORTS_32BIT_KERNEL - select CPU_SUPPORTS_HIGHMEM - select CPU_SUPPORTS_CPUFREQ config CPU_BMIPS32_3300 select SMP_UP if SMP @@ -1914,10 +1901,7 @@ config SYS_HAS_CPU_LOONGSON2F select CPU_SUPPORTS_ADDRWINCFG if 64BIT select CPU_SUPPORTS_UNCACHED_ACCELERATED -config SYS_HAS_CPU_LOONGSON1B - bool - -config SYS_HAS_CPU_LOONGSON1C +config SYS_HAS_CPU_LOONGSON1 bool config SYS_HAS_CPU_MIPS32_R1 diff --git a/arch/mips/include/asm/cpu-type.h b/arch/mips/include/asm/cpu-type.h index a45af3de075d..ee17f02419a3 100644 --- a/arch/mips/include/asm/cpu-type.h +++ b/arch/mips/include/asm/cpu-type.h @@ -24,8 +24,7 @@ static inline int __pure __get_cpu_type(const int cpu_type) case CPU_LOONGSON3: #endif -#if defined(CONFIG_SYS_HAS_CPU_LOONGSON1B) || \ -defined(CONFIG_SYS_HAS_CPU_LOONGSON1C) +#if defined(CONFIG_SYS_HAS_CPU_LOONGSON1) case CPU_LOONGSON1: #endif diff --git a/arch/mips/loongson32/Kconfig b/arch/mips/loongson32/Kconfig index 6dacc1438906..a0a00c3e2187 100644 --- a/arch/mips/loongson32/Kconfig +++ b/arch/mips/loongson32/Kconfig @@ -8,7 +8,7 @@ config LOONGSON1_LS1B bool "Loongson LS1B board" select CEVT_R4K if !MIPS_EXTERNAL_TIMER select CSRC_R4K if !MIPS_EXTERNAL_TIMER - select SYS_HAS_CPU_LOONGSON1B + select SYS_HAS_CPU_LOONGSON1 select DMA_NONCOHERENT select BOOT_ELF32 select IRQ_MIPS_CPU @@ -23,7 +23,7 @@ config LOONGSON1_LS1C bool "Loongson LS1C board" select CEVT_R4K if !MIPS_EXTERNAL_TIMER select CSRC_R4K if !MIPS_EXTERNAL_TIMER - select SYS_HAS_CPU_LOONGSON1C + select SYS_HAS_CPU_LOONGSON1 select DMA_NONCOHERENT select BOOT_ELF32 select IRQ_MIPS_CPU -- 2.20.1
[PATCH 1/4] MIPS: Loongson32: Remove ehci platform device
It's going to be enabled by DeviceTree
Signed-off-by: Jiaxun Yang
---
.../include/asm/mach-loongson32/platform.h| 1 -
arch/mips/loongson32/common/platform.c| 30 ---
arch/mips/loongson32/ls1b/board.c | 1 -
3 files changed, 32 deletions(-)
diff --git a/arch/mips/include/asm/mach-loongson32/platform.h
b/arch/mips/include/asm/mach-loongson32/platform.h
index 15d1de2300fe..f36c8d287b59 100644
--- a/arch/mips/include/asm/mach-loongson32/platform.h
+++ b/arch/mips/include/asm/mach-loongson32/platform.h
@@ -19,7 +19,6 @@ extern struct platform_device ls1x_uart_pdev;
extern struct platform_device ls1x_cpufreq_pdev;
extern struct platform_device ls1x_eth0_pdev;
extern struct platform_device ls1x_eth1_pdev;
-extern struct platform_device ls1x_ehci_pdev;
extern struct platform_device ls1x_gpio0_pdev;
extern struct platform_device ls1x_gpio1_pdev;
extern struct platform_device ls1x_rtc_pdev;
diff --git a/arch/mips/loongson32/common/platform.c
b/arch/mips/loongson32/common/platform.c
index 0bf355c8bcb2..4b35f49e9fcb 100644
--- a/arch/mips/loongson32/common/platform.c
+++ b/arch/mips/loongson32/common/platform.c
@@ -10,12 +10,10 @@
#include
#include
#include
-#include
#include
#include
#include
#include
-#include
#include
#include
@@ -255,34 +253,6 @@ struct platform_device ls1x_gpio1_pdev = {
.resource = ls1x_gpio1_resources,
};
-/* USB EHCI */
-static u64 ls1x_ehci_dmamask = DMA_BIT_MASK(32);
-
-static struct resource ls1x_ehci_resources[] = {
- [0] = {
- .start = LS1X_EHCI_BASE,
- .end= LS1X_EHCI_BASE + SZ_32K - 1,
- .flags = IORESOURCE_MEM,
- },
- [1] = {
- .start = LS1X_EHCI_IRQ,
- .flags = IORESOURCE_IRQ,
- },
-};
-
-static struct usb_ehci_pdata ls1x_ehci_pdata = {
-};
-
-struct platform_device ls1x_ehci_pdev = {
- .name = "ehci-platform",
- .id = -1,
- .num_resources = ARRAY_SIZE(ls1x_ehci_resources),
- .resource = ls1x_ehci_resources,
- .dev= {
- .dma_mask = &ls1x_ehci_dmamask,
- .platform_data = &ls1x_ehci_pdata,
- },
-};
/* Real Time Clock */
void __init ls1x_rtc_set_extclk(struct platform_device *pdev)
diff --git a/arch/mips/loongson32/ls1b/board.c
b/arch/mips/loongson32/ls1b/board.c
index 447b15fc0a2b..74f7b530d9b1 100644
--- a/arch/mips/loongson32/ls1b/board.c
+++ b/arch/mips/loongson32/ls1b/board.c
@@ -42,7 +42,6 @@ static struct platform_device *ls1b_platform_devices[]
__initdata = {
&ls1x_cpufreq_pdev,
&ls1x_eth0_pdev,
&ls1x_eth1_pdev,
- &ls1x_ehci_pdev,
&ls1x_gpio0_pdev,
&ls1x_gpio1_pdev,
&ls1x_rtc_pdev,
--
2.20.1
[PATCH 2/4] MIPS: Loongson32: Add DeviceTree support
Initial DeviceTree support for loongson32
Also remove the old IRQ driver since it have been replaced
by generic LS1X_IRQ.
Signed-off-by: Jiaxun Yang
---
arch/mips/Kconfig| 5 +-
arch/mips/loongson32/common/Makefile | 2 +-
arch/mips/loongson32/common/irq.c| 196 ---
arch/mips/loongson32/common/setup.c | 18 +++
4 files changed, 23 insertions(+), 198 deletions(-)
delete mode 100644 arch/mips/loongson32/common/irq.c
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index ddfb587c4744..15f8cc3c965f 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -437,6 +437,9 @@ config LASAT
config MACH_LOONGSON32
bool "Loongson-1 family of machines"
+ select USE_OF
+ select BUILTIN_DTB
+ select LS1X_IRQ
select SYS_SUPPORTS_ZBOOT
help
This enables support for the Loongson-1 family of machines.
@@ -3024,7 +3027,7 @@ endchoice
choice
prompt "Kernel command line type" if !CMDLINE_OVERRIDE
default MIPS_CMDLINE_FROM_DTB if USE_OF && !ATH79 && !MACH_INGENIC && \
-!MIPS_MALTA && \
+!MACH_LOONGSON32 && !MIPS_MALTA && \
!CAVIUM_OCTEON_SOC
default MIPS_CMDLINE_FROM_BOOTLOADER
diff --git a/arch/mips/loongson32/common/Makefile
b/arch/mips/loongson32/common/Makefile
index 723b4ce3b8f0..5b29badb0950 100644
--- a/arch/mips/loongson32/common/Makefile
+++ b/arch/mips/loongson32/common/Makefile
@@ -2,4 +2,4 @@
# Makefile for common code of loongson1 based machines.
#
-obj-y += time.o irq.o platform.o prom.o reset.o setup.o
+obj-y += time.o platform.o prom.o reset.o setup.o
diff --git a/arch/mips/loongson32/common/irq.c
b/arch/mips/loongson32/common/irq.c
deleted file mode 100644
index 635a4abe1f48..
--- a/arch/mips/loongson32/common/irq.c
+++ /dev/null
@@ -1,196 +0,0 @@
-/*
- * Copyright (c) 2011 Zhang, Keguang
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
- */
-
-#include
-#include
-#include
-
-#include
-#include
-
-#define LS1X_INTC_REG(n, x) \
- ((void __iomem *)KSEG1ADDR(LS1X_INTC_BASE + (n * 0x18) + (x)))
-
-#define LS1X_INTC_INTISR(n)LS1X_INTC_REG(n, 0x0)
-#define LS1X_INTC_INTIEN(n)LS1X_INTC_REG(n, 0x4)
-#define LS1X_INTC_INTSET(n)LS1X_INTC_REG(n, 0x8)
-#define LS1X_INTC_INTCLR(n)LS1X_INTC_REG(n, 0xc)
-#define LS1X_INTC_INTPOL(n)LS1X_INTC_REG(n, 0x10)
-#define LS1X_INTC_INTEDGE(n) LS1X_INTC_REG(n, 0x14)
-
-static void ls1x_irq_ack(struct irq_data *d)
-{
- unsigned int bit = (d->irq - LS1X_IRQ_BASE) & 0x1f;
- unsigned int n = (d->irq - LS1X_IRQ_BASE) >> 5;
-
- __raw_writel(__raw_readl(LS1X_INTC_INTCLR(n))
- | (1 << bit), LS1X_INTC_INTCLR(n));
-}
-
-static void ls1x_irq_mask(struct irq_data *d)
-{
- unsigned int bit = (d->irq - LS1X_IRQ_BASE) & 0x1f;
- unsigned int n = (d->irq - LS1X_IRQ_BASE) >> 5;
-
- __raw_writel(__raw_readl(LS1X_INTC_INTIEN(n))
- & ~(1 << bit), LS1X_INTC_INTIEN(n));
-}
-
-static void ls1x_irq_mask_ack(struct irq_data *d)
-{
- unsigned int bit = (d->irq - LS1X_IRQ_BASE) & 0x1f;
- unsigned int n = (d->irq - LS1X_IRQ_BASE) >> 5;
-
- __raw_writel(__raw_readl(LS1X_INTC_INTIEN(n))
- & ~(1 << bit), LS1X_INTC_INTIEN(n));
- __raw_writel(__raw_readl(LS1X_INTC_INTCLR(n))
- | (1 << bit), LS1X_INTC_INTCLR(n));
-}
-
-static void ls1x_irq_unmask(struct irq_data *d)
-{
- unsigned int bit = (d->irq - LS1X_IRQ_BASE) & 0x1f;
- unsigned int n = (d->irq - LS1X_IRQ_BASE) >> 5;
-
- __raw_writel(__raw_readl(LS1X_INTC_INTIEN(n))
- | (1 << bit), LS1X_INTC_INTIEN(n));
-}
-
-static int ls1x_irq_settype(struct irq_data *d, unsigned int type)
-{
- unsigned int bit = (d->irq - LS1X_IRQ_BASE) & 0x1f;
- unsigned int n = (d->irq - LS1X_IRQ_BASE) >> 5;
-
- switch (type) {
- case IRQ_TYPE_LEVEL_HIGH:
- __raw_writel(__raw_readl(LS1X_INTC_INTPOL(n))
- | (1 << bit), LS1X_INTC_INTPOL(n));
- __raw_writel(__raw_readl(LS1X_INTC_INTEDGE(n))
- & ~(1 << bit), LS1X_INTC_INTEDGE(n));
- break;
- case IRQ_TYPE_LEVEL_LOW:
- __raw_writel(__raw_readl(LS1X_INTC_INTPOL(n))
- & ~(1 << bit), LS1X_INTC_INTPOL(n));
- __raw_writel(__raw_readl(LS1X_INTC_INTEDGE(n))
- & ~(1 << bit), LS1X_INTC_INTEDGE(n));
- break;
- case IRQ_TYPE_EDGE_RISING:
- __raw_writel(__raw_readl(LS1X_INTC_INTPOL(n
[PATCH 4/4] MIPS: Loongson32: dts: add ls1b & ls1c
Add devicetree skeleton for ls1b and ls1c
Signed-off-by: Jiaxun Yang
---
arch/mips/boot/dts/loongson/Makefile | 6 ++
arch/mips/boot/dts/loongson/ls1b.dts | 21 +
arch/mips/boot/dts/loongson/ls1c.dts | 25 ++
arch/mips/boot/dts/loongson/ls1x.dtsi | 117 ++
4 files changed, 169 insertions(+)
create mode 100644 arch/mips/boot/dts/loongson/Makefile
create mode 100644 arch/mips/boot/dts/loongson/ls1b.dts
create mode 100644 arch/mips/boot/dts/loongson/ls1c.dts
create mode 100644 arch/mips/boot/dts/loongson/ls1x.dtsi
diff --git a/arch/mips/boot/dts/loongson/Makefile
b/arch/mips/boot/dts/loongson/Makefile
new file mode 100644
index ..447801568f33
--- /dev/null
+++ b/arch/mips/boot/dts/loongson/Makefile
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: GPL-2.0
+dtb-$(CONFIG_LOONGSON1_LS1B) += ls1b.dtb
+
+dtb-$(CONFIG_LOONGSON1_LS1B) += ls1c.dtb
+
+obj-$(CONFIG_BUILTIN_DTB) += $(addsuffix .o, $(dtb-y))
diff --git a/arch/mips/boot/dts/loongson/ls1b.dts
b/arch/mips/boot/dts/loongson/ls1b.dts
new file mode 100644
index ..6d40dc502acf
--- /dev/null
+++ b/arch/mips/boot/dts/loongson/ls1b.dts
@@ -0,0 +1,21 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 Jiaxun Yang
+ */
+
+/dts-v1/;
+#include
+
+/ {
+ model = "Loongson LS1B";
+ compatible = "loongson,ls1b";
+
+};
+
+&ehci0 {
+ status = "okay";
+};
+
+&ohci0 {
+ status = "okay";
+};
\ No newline at end of file
diff --git a/arch/mips/boot/dts/loongson/ls1c.dts
b/arch/mips/boot/dts/loongson/ls1c.dts
new file mode 100644
index ..778d205a586e
--- /dev/null
+++ b/arch/mips/boot/dts/loongson/ls1c.dts
@@ -0,0 +1,25 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 Jiaxun Yang
+ */
+
+/dts-v1/;
+#include
+
+/ {
+ model = "Loongson LS1C300A";
+ compatible = "loongson,ls1c300a";
+
+};
+
+&platintc4 {
+ status = "okay";
+};
+
+&ehci0 {
+ status = "okay";
+};
+
+&ohci0 {
+ status = "okay";
+};
\ No newline at end of file
diff --git a/arch/mips/boot/dts/loongson/ls1x.dtsi
b/arch/mips/boot/dts/loongson/ls1x.dtsi
new file mode 100644
index ..f808e4328fd8
--- /dev/null
+++ b/arch/mips/boot/dts/loongson/ls1x.dtsi
@@ -0,0 +1,117 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 Jiaxun Yang
+ */
+
+/dts-v1/;
+#include
+
+
+/ {
+#address-cells = <1>;
+ #size-cells = <1>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ device_type = "cpu";
+ reg = <0>;
+ };
+ };
+
+ cpu_intc: interrupt-controller {
+ #address-cells = <0>;
+ compatible = "mti,cpu-interrupt-controller";
+
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
+
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ compatible = "simple-bus";
+ ranges;
+
+
+ platintc0: interrupt-controller@1fd01040 {
+ compatible = "loongson,ls1x-intc";
+ reg = <0x1fd01040 0x18>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ interrupt-parent = <&cpu_intc>;
+ interrupts = <2>;
+ };
+
+ platintc1: interrupt-controller@1fd01058 {
+ compatible = "loongson,ls1x-intc";
+ reg = <0x1fd01058 0x18>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ interrupt-parent = <&cpu_intc>;
+ interrupts = <3>;
+ };
+
+ platintc2: interrupt-controller@1fd01070 {
+ compatible = "loongson,ls1x-intc";
+ reg = <0x1fd01070 0x18>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ interrupt-parent = <&cpu_intc>;
+ interrupts = <4>;
+ };
+
+ platintc3: interrupt-controller@1fd01088 {
+ compatible = "loongson,ls1x-intc";
+ reg = <0x1fd01088 0x18>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ interrupt-parent = <&cpu_intc>;
+ interrupts = <5>;
+ };
+
+ platintc4: interrupt-controller@1fd010a0 {
+ compatible = "loongson,ls1x-intc";
+ reg = <0x1fd010a0 0x18>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ interrupt-parent = <&cpu_intc>;
+ interrupts = <6>;
+
+ status = "disab
Re: [PATCH linux-next v2 1/2] ASoC: rsnd: src: Avoid a potential deadlock
Hi Jiada, Fabrizio,
On Thu, Mar 7, 2019 at 7:17 AM Jiada Wang wrote:
> lockdep warns us that priv->lock and k->k_lock can cause a
> deadlock when after acquire of k->k_lock, process is interrupted
> by src, while in another routine of src .init, k->k_lock is
> acquired with priv->lock held.
>
> This patch avoids a potential deadlock by not calling soc_device_match()
> in SRC .init callback, instead it adds new soc fields in priv->flags to
> differentiate SoCs.
>
> Fixes: linux-next commit 7674bec4fc09 ("ASoC: rsnd: update BSDSR/BSDISR
> handling")
> Signed-off-by: Jiada Wang
> ---
> sound/soc/sh/rcar/core.c | 2 ++
> sound/soc/sh/rcar/rsnd.h | 5 +
> sound/soc/sh/rcar/src.c | 9 +
> 3 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/sound/soc/sh/rcar/core.c b/sound/soc/sh/rcar/core.c
> index 022996d2db13..4fe83e611c01 100644
> --- a/sound/soc/sh/rcar/core.c
> +++ b/sound/soc/sh/rcar/core.c
> @@ -110,6 +110,8 @@ static const struct of_device_id rsnd_of_match[] = {
> { .compatible = "renesas,rcar_sound-gen1", .data = (void *)RSND_GEN1
> },
> { .compatible = "renesas,rcar_sound-gen2", .data = (void *)RSND_GEN2
> },
> { .compatible = "renesas,rcar_sound-gen3", .data = (void *)RSND_GEN3
> },
> + /* Special Handling */
> + { .compatible = "renesas,rcar_sound-r8a77990", .data = (void
> *)(RSND_GEN3 | RSND_SOC_E) },
I guess we need an entry for RZ/G2E, too?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH] ARM: dma-mapping: always clear allocated buffers in __alloc_from_pool
From: YueHaibing
Like commit 518a2f1925c3 ("dma-mapping: zero memory returned
from dma_alloc_*"), if we want to map memory from the DMA
allocator to userspace it must be zeroed at allocation time
to prevent stale data leaks. On arm platform, if the allocator
is pool_allocator in __dma_alloc, then the mem is alloced by
__alloc_from_pool, which also need be zeroed.
Signed-off-by: YueHaibing
---
arch/arm/mm/dma-mapping.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 8a90f29..28ad6d5 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -558,6 +558,7 @@ static void *__alloc_from_pool(size_t size, struct page
**ret_page)
*ret_page = phys_to_page(phys);
ptr = (void *)val;
+ memset(ptr, 0, size);
}
return ptr;
--
2.7.0
Re: [PATCH v5 1/8] clk: samsung: add needed IDs for DMC clocks in Exynos5420
Hi Rob, On 3/11/19 11:06 PM, Rob Herring wrote: > On Tue, 5 Mar 2019 11:19:04 +0100, Lukasz Luba wrote: >> Define new IDs for clocks used by Dynamic Memory Controller in >> Exynos5422 SoC. >> >> Signed-off-by: Lukasz Luba >> --- >> include/dt-bindings/clock/exynos5420.h | 18 +- >> 1 file changed, 17 insertions(+), 1 deletion(-) >> > > Please add Acked-by/Reviewed-by tags when posting new versions. However, > there's no need to repost patches *only* to add the tags. The upstream > maintainer will do that for acks received on the version they apply. > > If a tag was not added on purpose, please state why and what changed. I have skipped your ACK because of the hack which is implemented in v5 clocks. Chanwoo refused the driver code because it uses 2 registers from the clock register set without Common Clock Framework API. He said that he will not accept this code and I have to figure out new approach using CCF. Thus, I have modeled these two registers as 'gates', but these registers are for Dynamic Memory Controller PAUSE feature (which stops transactions) and the other is for switching between two set of registers with timings for the LPDDR3 memory (normal operation and alternative clock source operation aka 'bypass'). These registers should be (in my opinion) in the DMC registers and not in the clocks. Sylwester pointed out offline that it could be done using regmap. These are the problematic clocks added in v5: +#define CLK_CDREX_PAUSE531 +#define CLK_CDREX_TIMING_SET 532 I have mentioned about it in the cover letter, but you are right I could also add a comment for this particular patch that I have skipped your ACK. Thank you for sharing the information about the process. I will keep it in mind next time and will add a comment below the commit message for a particular patch and explicit information in cover letter that I am not including an ACK. Regards, Lukasz > >
Re: [PATCH v9 2/2] pwm: sifive: Add a driver for SiFive SoC PWM
Hello,
there are just a few minor things left I commented below.
On Tue, Mar 12, 2019 at 01:41:29PM +0530, Yash Shah wrote:
> +#define div_u64_round(a, b) \
> + ({typeof(b) __b = b; div_u64((a) + __b / 2, __b); })
Parenthesis around b please. I guess I didn't had them in my suggestion
either, sorry for that.
> +static int pwm_sifive_enable(struct pwm_chip *chip, bool enable)
> +{
> + struct pwm_sifive_ddata *pwm = pwm_sifive_chip_to_ddata(chip);
> + int ret;
> +
> + if (enable) {
> + ret = clk_enable(pwm->clk);
> + if (ret) {
> + dev_err(pwm->chip.dev, "Enable clk failed:%d\n", ret);
> + return ret;
> + }
> + }
> +
> + if (!enable)
> + clk_disable(pwm->clk);
> +
> + return 0;
> +}
There is only a single caller for this function. I wonder if it is
trivial enough to fold it into pwm_sifive_apply.
> +static int pwm_sifive_apply(struct pwm_chip *chip, struct pwm_device *dev,
> + struct pwm_state *state)
> +{
> + struct pwm_sifive_ddata *pwm = pwm_sifive_chip_to_ddata(chip);
> + unsigned int duty_cycle;
> + u32 frac;
> + struct pwm_state cur_state;
> + bool enabled;
> + int ret = 0;
> + unsigned long num;
> +
> + if (state->polarity != PWM_POLARITY_INVERSED)
> + return -EINVAL;
> +
> + ret = clk_enable(pwm->clk);
> + if (ret) {
> + dev_err(pwm->chip.dev, "Enable clk failed:%d\n", ret);
> + return ret;
> + }
> +
> + mutex_lock(&pwm->lock);
> + pwm_get_state(dev, &cur_state);
> +
> + enabled = cur_state.enabled;
> +
> + if (state->period != pwm->approx_period) {
> + if (pwm->user_count != 1) {
> + ret = -EBUSY;
> + goto exit;
> + }
> + pwm->approx_period = state->period;
> + pwm_sifive_update_clock(pwm, clk_get_rate(pwm->clk));
> + }
> +
> + duty_cycle = state->duty_cycle;
> + if (!state->enabled)
> + duty_cycle = 0;
> +
> + num = (u64)duty_cycle * (1U << PWM_SIFIVE_CMPWIDTH);
> + frac = div_u64_round(num, state->period);
> + /* The hardware cannot generate a 100% duty cycle */
> + frac = min(frac, (1U << PWM_SIFIVE_CMPWIDTH) - 1);
> +
> + writel(frac, pwm->regs + PWM_SIFIVE_PWMCMP0 +
> +dev->hwpwm * PWM_SIFIVE_SIZE_PWMCMP);
> +
> + if (state->enabled != enabled) {
> + ret = pwm_sifive_enable(chip, state->enabled);
> + if (ret)
> + goto exit;
This goto is a noop.
> + }
> +
> +exit:
> + clk_disable(pwm->clk);
> + mutex_unlock(&pwm->lock);
> + return ret;
> +}
There are a few other things that could be improved, but I think they
could be addressed later. For some of these I don't even know what to
suggest, for some Thierry might not agree it is worth fixing:
- rounding
how to round? When should a request declined, when is rounding ok?
There is still "if (state->period != pwm->approx_period) return -EBUSY"
in this driver. This is better than before, but if state-period ==
pwm->approx_period + 1 the result (if accepted) might be the same as
without the +1 and so returning -EBUSY for one case and accepting the
other is strange.
- don't call PWM API functions designed for consumers (here: pwm_get_state)
- Move div_u64_round to include/linux/math64.h
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
Re: [PATCH] printk: kmsg_dump: Mark registered flag as private
On Mon 2019-03-11 21:49:05, Sergey Senozhatsky wrote:
> On (03/10/19 21:03), Ahmed S. Darwish wrote:
> > The 'registered' flag is internally used by kmsg_dump_register()
> > and kmsg_dump_unregister() to track multiple registrations of the
> > same dumper.
> >
> > It's protected by printk's internal dump_list_lock, and must thus
> > be accessed only from there. Mark it as private.
> >
> > Signed-off-by: Ahmed S. Darwish
> > ---
> > include/linux/kmsg_dump.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/include/linux/kmsg_dump.h b/include/linux/kmsg_dump.h
> > index 2e7a1e032c71..7c08cb58259a 100644
> > --- a/include/linux/kmsg_dump.h
> > +++ b/include/linux/kmsg_dump.h
> > @@ -36,7 +36,7 @@ enum kmsg_dump_reason {
> > * @dump: Call into dumping code which will retrieve the data with
> > * through the record iterator
> > * @max_reason:filter for highest reason number that should be dumped
> > - * @registered:Flag that specifies if this is already registered
> > + * @registered:Flag that specifies if this is already registered
> > (private)
> > */
> > struct kmsg_dumper {
> > struct list_head list;
>
>
> Do we really do this thing?
Good question.
> $ git grep "(private)" include/linux/
> include/linux/kmsg_dump.h: * @list: Entry in the dumper list (private)
This is another field in the same structure. There are 4 other fields
that are described as private by extra comment. Thefore this patch
might make it more consistent.
Well, I am not sure if it is worth it. Andrew?
> include/linux/uwb.h: * specific (private) DevAddr (UWB_RSV_TARGET_DEVADDR).
Best Regards,
Petr
Re: [PATCH 16/42] drivers: gpio: janz-ttl: drop unneccessary temp variable dev
On 11/03/2019 18:54, Enrico Weigelt, metux IT consult wrote:
don't need the temporary variable "dev", directly use &pdev->dev
Signed-off-by: Enrico Weigelt, metux IT consult
This is quite usual to do, and I like it as it saves typing.
Personally I would say don't bother with this change.
---
drivers/gpio/gpio-janz-ttl.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpio/gpio-janz-ttl.c b/drivers/gpio/gpio-janz-ttl.c
index b97a911..91f91f6 100644
--- a/drivers/gpio/gpio-janz-ttl.c
+++ b/drivers/gpio/gpio-janz-ttl.c
@@ -144,18 +144,17 @@ static void ttl_setup_device(struct ttl_module *mod)
static int ttl_probe(struct platform_device *pdev)
{
struct janz_platform_data *pdata;
- struct device *dev = &pdev->dev;
struct ttl_module *mod;
struct gpio_chip *gpio;
int ret;
pdata = dev_get_platdata(&pdev->dev);
if (!pdata) {
- dev_err(dev, "no platform data\n");
+ dev_err(&pdev->dev, "no platform data\n");
return -ENXIO;
}
- mod = devm_kzalloc(dev, sizeof(*mod), GFP_KERNEL);
+ mod = devm_kzalloc(&pdev->dev, sizeof(*mod), GFP_KERNEL);
if (!mod)
return -ENOMEM;
@@ -181,9 +180,9 @@ static int ttl_probe(struct platform_device *pdev)
gpio->base = -1;
gpio->ngpio = 20;
- ret = devm_gpiochip_add_data(dev, gpio, NULL);
+ ret = devm_gpiochip_add_data(&pdev->dev, gpio, NULL);
if (ret) {
- dev_err(dev, "unable to add GPIO chip\n");
+ dev_err(&pdev->dev, "unable to add GPIO chip\n");
return ret;
}
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
https://www.codethink.co.uk/privacy.html
RE: [PATCHv4 11/28] PCI: mobiveil: only fix up the Class Code field
Hi Bjorn,
Thanks a lot for your comments!
> -Original Message-
> From: Bjorn Helgaas [mailto:helg...@kernel.org]
> Sent: 2019年3月11日 22:14
> To: Z.q. Hou
> Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> robh...@kernel.org; mark.rutl...@arm.com; l.subrahma...@mobiveil.co.in;
> shawn...@kernel.org; Leo Li ;
> lorenzo.pieral...@arm.com; catalin.mari...@arm.com;
> will.dea...@arm.com; Mingkai Hu ; M.h. Lian
> ; Xiaowei Bao
> Subject: Re: [PATCHv4 11/28] PCI: mobiveil: only fix up the Class Code field
>
> On Mon, Mar 11, 2019 at 09:31:23AM +, Z.q. Hou wrote:
> > From: Hou Zhiqiang
> >
> > Fix up the Class Code to PCI bridge, do not change the Revision ID.
> > And move the fixup to mobiveil_host_init function.
>
> Add parens after function name.
>
> Please explain why this change is needed. Does it fix a bug?
>
> Does this fix the problem that the PCI core didn't correctly identify the
> device
> as a bridge because it identified bridges by class code instead of header
> type?
>
> That problem *should* be fixed by b2fb5cc57469 ("PCI: Rely on config space
> header type, not class code"), which is now upstream.
>
> You might still want this class code change so that lspci shows the correct
> thing. That's fine, but the changelog should say why we're doing it.
>
Subrahmanya's original patch is to fixup 'Class Code' field, but it also fixed
the 'Revision ID' field. This patch is patch is to remove the fixup of
'Revision ID' field.
> > Fixes: 9af6bcb11e12 ("PCI: mobiveil: Add Mobiveil PCIe Host Bridge IP
> > driver")
>
> Make this "Fixes:" line a single line again.
>
> > Signed-off-by: Hou Zhiqiang
> > Reviewed-by: Minghuan Lian
> > Reviewed-by: Subrahmanya Lingappa
> > ---
> > V4:
> > - no change
> >
> > drivers/pci/controller/pcie-mobiveil.c | 9 ++---
> > 1 file changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/pci/controller/pcie-mobiveil.c
> > b/drivers/pci/controller/pcie-mobiveil.c
> > index 78e575e71f4d..8eee1ab7ee24 100644
> > --- a/drivers/pci/controller/pcie-mobiveil.c
> > +++ b/drivers/pci/controller/pcie-mobiveil.c
> > @@ -653,6 +653,12 @@ static int mobiveil_host_init(struct mobiveil_pcie
> *pcie)
> >type, resource_size(win->res));
> > }
> >
> > + /* fixup for PCIe class register */
> > + value = csr_readl(pcie, PAB_INTP_AXI_PIO_CLASS);
> > + value &= 0xff;
> > + value |= (PCI_CLASS_BRIDGE_PCI << 16);
> > + csr_writel(pcie, value, PAB_INTP_AXI_PIO_CLASS);
> > +
> > /* setup MSI hardware registers */
> > mobiveil_pcie_enable_msi(pcie);
> >
> > @@ -896,9 +902,6 @@ static int mobiveil_pcie_probe(struct
> platform_device *pdev)
> > goto error;
> > }
> >
> > - /* fixup for PCIe class register */
> > - csr_writel(pcie, 0x060402ab, PAB_INTP_AXI_PIO_CLASS);
> > -
> > /* initialize the IRQ domains */
> > ret = mobiveil_pcie_init_irq_domain(pcie);
> > if (ret) {
> > --
> > 2.17.1
> >
Thanks,
Zhiqiang
[PATCH 5/9] drivers: ata: libahci_platform: use devm_platform_ioremap_resource()
Use the new helper that wraps the calls to platform_get_resource()
and devm_ioremap_resource() together.
Signed-off-by: Enrico Weigelt, metux IT consult
---
drivers/ata/libahci_platform.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/ata/libahci_platform.c b/drivers/ata/libahci_platform.c
index 81b1a33..8dc8b9a 100644
--- a/drivers/ata/libahci_platform.c
+++ b/drivers/ata/libahci_platform.c
@@ -409,8 +409,7 @@ struct ahci_host_priv *ahci_platform_get_resources(struct
platform_device *pdev,
devres_add(dev, hpriv);
- hpriv->mmio = devm_ioremap_resource(dev,
- platform_get_resource(pdev, IORESOURCE_MEM, 0));
+ hpriv->mmio = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(hpriv->mmio)) {
dev_err(dev, "no mmio space\n");
rc = PTR_ERR(hpriv->mmio);
--
1.9.1
[PATCH 8/9] drivers: ata: sata_gemini: use devm_platform_ioremap_resource()
Use the new helper that wraps the calls to platform_get_resource() and devm_ioremap_resource() together. Signed-off-by: Enrico Weigelt, metux IT consult --- drivers/ata/sata_gemini.c | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/drivers/ata/sata_gemini.c b/drivers/ata/sata_gemini.c index 46950e0..96cca96 100644 --- a/drivers/ata/sata_gemini.c +++ b/drivers/ata/sata_gemini.c @@ -317,7 +317,6 @@ static int gemini_sata_probe(struct platform_device *pdev) struct device_node *np = dev->of_node; struct sata_gemini *sg; struct regmap *map; - struct resource *res; enum gemini_muxmode muxmode; u32 gmode; u32 gmask; @@ -328,11 +327,7 @@ static int gemini_sata_probe(struct platform_device *pdev) return -ENOMEM; sg->dev = dev; - res = platform_get_resource(pdev, IORESOURCE_MEM, 0); - if (!res) - return -ENODEV; - - sg->base = devm_ioremap_resource(dev, res); + sg->base = devm_platform_ioremap_resource(pdev, 0); if (IS_ERR(sg->base)) return PTR_ERR(sg->base); -- 1.9.1
[PATCH 1/9] drivers: ata: ahci_octeon: use devm_platform_ioremap_resource()
Use the new helper that wraps the calls to platform_get_resource()
and devm_ioremap_resource() together.
Signed-off-by: Enrico Weigelt, metux IT consult
---
drivers/ata/ahci_octeon.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/ata/ahci_octeon.c b/drivers/ata/ahci_octeon.c
index 5a44e08..2280180 100644
--- a/drivers/ata/ahci_octeon.c
+++ b/drivers/ata/ahci_octeon.c
@@ -32,13 +32,11 @@ static int ahci_octeon_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct device_node *node = dev->of_node;
- struct resource *res;
void __iomem *base;
u64 cfg;
int ret;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- base = devm_ioremap_resource(&pdev->dev, res);
+ base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(base))
return PTR_ERR(base);
--
1.9.1
[PATCH 7/9] drivers: ata: sata_dwc_460ex: use devm_platform_ioremap_resource()
Use the new helper that wraps the calls to platform_get_resource()
and devm_ioremap_resource() together.
Signed-off-by: Enrico Weigelt, metux IT consult
---
drivers/ata/sata_dwc_460ex.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/ata/sata_dwc_460ex.c b/drivers/ata/sata_dwc_460ex.c
index 6f142aa..c57b348 100644
--- a/drivers/ata/sata_dwc_460ex.c
+++ b/drivers/ata/sata_dwc_460ex.c
@@ -241,7 +241,6 @@ static int sata_dwc_dma_init_old(struct platform_device
*pdev,
struct sata_dwc_device *hsdev)
{
struct device_node *np = pdev->dev.of_node;
- struct resource *res;
hsdev->dma = devm_kzalloc(&pdev->dev, sizeof(*hsdev->dma), GFP_KERNEL);
if (!hsdev->dma)
@@ -258,8 +257,7 @@ static int sata_dwc_dma_init_old(struct platform_device
*pdev,
}
/* Get physical SATA DMA register base address */
- res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
- hsdev->dma->regs = devm_ioremap_resource(&pdev->dev, res);
+ hsdev->dma->regs = devm_platform_ioremap_resource(pdev, 1);
if (IS_ERR(hsdev->dma->regs))
return PTR_ERR(hsdev->dma->regs);
--
1.9.1
[PATCH 9/9] drivers: ata: sata_rcar: use devm_platform_ioremap_resource()
Use the new helper that wraps the calls to platform_get_resource()
and devm_ioremap_resource() together.
Signed-off-by: Enrico Weigelt, metux IT consult
---
drivers/ata/sata_rcar.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/ata/sata_rcar.c b/drivers/ata/sata_rcar.c
index 59b2317..293cc62 100644
--- a/drivers/ata/sata_rcar.c
+++ b/drivers/ata/sata_rcar.c
@@ -886,7 +886,6 @@ static int sata_rcar_probe(struct platform_device *pdev)
struct device *dev = &pdev->dev;
struct ata_host *host;
struct sata_rcar_priv *priv;
- struct resource *mem;
int irq;
int ret = 0;
@@ -916,8 +915,7 @@ static int sata_rcar_probe(struct platform_device *pdev)
host->private_data = priv;
- mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- priv->base = devm_ioremap_resource(dev, mem);
+ priv->base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(priv->base)) {
ret = PTR_ERR(priv->base);
goto err_pm_put;
--
1.9.1
[PATCH 6/9] drivers: ata: pata_bk3710: use devm_platform_ioremap_resource()
Use the new helper that wraps the calls to platform_get_resource()
and devm_ioremap_resource() together.
Signed-off-by: Enrico Weigelt, metux IT consult
---
drivers/ata/pata_bk3710.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/ata/pata_bk3710.c b/drivers/ata/pata_bk3710.c
index fad95cf..92b036d 100644
--- a/drivers/ata/pata_bk3710.c
+++ b/drivers/ata/pata_bk3710.c
@@ -291,7 +291,6 @@ static void pata_bk3710_chipinit(void __iomem *base)
static int __init pata_bk3710_probe(struct platform_device *pdev)
{
struct clk *clk;
- struct resource *mem;
struct ata_host *host;
struct ata_port *ap;
void __iomem *base;
@@ -310,15 +309,13 @@ static int __init pata_bk3710_probe(struct
platform_device *pdev)
/* NOTE: round *down* to meet minimum timings; we count in clocks */
ideclk_period = 10UL / rate;
- mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-
irq = platform_get_irq(pdev, 0);
if (irq < 0) {
pr_err(DRV_NAME ": failed to get IRQ resource\n");
return irq;
}
- base = devm_ioremap_resource(&pdev->dev, mem);
+ base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(base))
return PTR_ERR(base);
--
1.9.1
[PATCH 3/9] drivers: ata: ahci_tegra: use devm_platform_ioremap_resource()
Use the new helper that wraps the calls to platform_get_resource()
and devm_ioremap_resource() together.
Signed-off-by: Enrico Weigelt, metux IT consult
---
drivers/ata/ahci_tegra.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/ata/ahci_tegra.c b/drivers/ata/ahci_tegra.c
index 004f260..88748ca 100644
--- a/drivers/ata/ahci_tegra.c
+++ b/drivers/ata/ahci_tegra.c
@@ -490,7 +490,6 @@ static int tegra_ahci_probe(struct platform_device *pdev)
{
struct ahci_host_priv *hpriv;
struct tegra_ahci_priv *tegra;
- struct resource *res;
int ret;
unsigned int i;
@@ -507,19 +506,17 @@ static int tegra_ahci_probe(struct platform_device *pdev)
tegra->pdev = pdev;
tegra->soc = of_device_get_match_data(&pdev->dev);
- res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
- tegra->sata_regs = devm_ioremap_resource(&pdev->dev, res);
+ tegra->sata_regs = devm_platform_ioremap_resource(pdev, 1);
if (IS_ERR(tegra->sata_regs))
return PTR_ERR(tegra->sata_regs);
/*
* AUX registers is optional.
*/
- res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
- if (res) {
- tegra->sata_aux_regs = devm_ioremap_resource(&pdev->dev, res);
- if (IS_ERR(tegra->sata_aux_regs))
- return PTR_ERR(tegra->sata_aux_regs);
+ tegra->sata_aux_regs = devm_platform_ioremap_resource(pdev, 2);
+ if (IS_ERR(tegra->sata_aux_regs)) {
+ dev_info(&pdev->dev, "Cant get aux registers (optional)");
+ tegra->sata_aux_regs = NULL;
}
tegra->sata_rst = devm_reset_control_get(&pdev->dev, "sata");
--
1.9.1
[PATCH 4/9] drivers: ata: ahci_xgene: use devm_platform_ioremap_resource()
Use the new helper that wraps the calls to platform_get_resource()
and devm_ioremap_resource() together.
Signed-off-by: Enrico Weigelt, metux IT consult
---
drivers/ata/ahci_xgene.c | 21 +++--
1 file changed, 7 insertions(+), 14 deletions(-)
diff --git a/drivers/ata/ahci_xgene.c b/drivers/ata/ahci_xgene.c
index 7e157e1..99c622c 100644
--- a/drivers/ata/ahci_xgene.c
+++ b/drivers/ata/ahci_xgene.c
@@ -752,7 +752,6 @@ static int xgene_ahci_probe(struct platform_device *pdev)
struct device *dev = &pdev->dev;
struct ahci_host_priv *hpriv;
struct xgene_ahci_context *ctx;
- struct resource *res;
const struct of_device_id *of_devid;
enum xgene_ahci_version version = XGENE_AHCI_V1;
const struct ata_port_info *ppi[] = { &xgene_ahci_v1_port_info,
@@ -772,31 +771,25 @@ static int xgene_ahci_probe(struct platform_device *pdev)
ctx->dev = dev;
/* Retrieve the IP core resource */
- res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
- ctx->csr_core = devm_ioremap_resource(dev, res);
+ ctx->csr_core = devm_platform_ioremap_resource(pdev, 1);
if (IS_ERR(ctx->csr_core))
return PTR_ERR(ctx->csr_core);
/* Retrieve the IP diagnostic resource */
- res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
- ctx->csr_diag = devm_ioremap_resource(dev, res);
+ ctx->csr_diag = devm_platform_ioremap_resource(pdev, 2);
if (IS_ERR(ctx->csr_diag))
return PTR_ERR(ctx->csr_diag);
/* Retrieve the IP AXI resource */
- res = platform_get_resource(pdev, IORESOURCE_MEM, 3);
- ctx->csr_axi = devm_ioremap_resource(dev, res);
+ ctx->csr_axi = devm_platform_ioremap_resource(pdev, 3);
if (IS_ERR(ctx->csr_axi))
return PTR_ERR(ctx->csr_axi);
/* Retrieve the optional IP mux resource */
- res = platform_get_resource(pdev, IORESOURCE_MEM, 4);
- if (res) {
- void __iomem *csr = devm_ioremap_resource(dev, res);
- if (IS_ERR(csr))
- return PTR_ERR(csr);
-
- ctx->csr_mux = csr;
+ ctx->csr_mux = csr = devm_platform_ioremap_resource(pdev, 4);
+ if (IS_ERR(ctx->csr_mux)) {
+ dev_info(&pdev->dev, "cant get ip mux resource (optional)");
+ ctx->csr_mux = NULL;
}
of_devid = of_match_device(xgene_ahci_of_match, dev);
--
1.9.1
[PATCH 2/9] drivers: ata: ahci_seattle: use devm_platform_ioremap_resource()
Use the new helper that wraps the calls to platform_get_resource() and devm_ioremap_resource() together. Signed-off-by: Enrico Weigelt, metux IT consult --- drivers/ata/ahci_seattle.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/ata/ahci_seattle.c b/drivers/ata/ahci_seattle.c index e57b6f9..9a10d81 100644 --- a/drivers/ata/ahci_seattle.c +++ b/drivers/ata/ahci_seattle.c @@ -140,8 +140,7 @@ static const struct ata_port_info *ahci_seattle_get_port_info( if (!plat_data) return &ahci_port_info; - plat_data->sgpio_ctrl = devm_ioremap_resource(dev, - platform_get_resource(pdev, IORESOURCE_MEM, 1)); + plat_data->sgpio_ctrl = devm_platform_ioremap_resource(pdev, 1); if (IS_ERR(plat_data->sgpio_ctrl)) return &ahci_port_info; -- 1.9.1
[PATCH 0/2] L2 Cache EDAC Support for HiFive Unleashed
This patch series adds a L2 Cache EDAC driver and DT documentation for HiFive Unleashed board. Yash Shah (2): edac: sifive: Add DT documentation for SiFive L2 cache Controller sifive: edac: Add EDAC driver for Sifive l2 Cache Controller .../devicetree/bindings/edac/sifive-edac-l2.txt| 31 +++ arch/riscv/Kconfig | 1 + drivers/edac/Kconfig | 7 + drivers/edac/Makefile | 1 + drivers/edac/sifive_edac-l2.c | 292 + 5 files changed, 332 insertions(+) create mode 100644 Documentation/devicetree/bindings/edac/sifive-edac-l2.txt create mode 100644 drivers/edac/sifive_edac-l2.c -- 1.9.1
[PATCH 2/2] sifive: edac: Add EDAC driver for Sifive l2 Cache Controller
Add driver for the SiFive L2 cache controller
on the HiFive Unleashed board
Signed-off-by: Yash Shah
---
arch/riscv/Kconfig| 1 +
drivers/edac/Kconfig | 7 +
drivers/edac/Makefile | 1 +
drivers/edac/sifive_edac-l2.c | 292 ++
4 files changed, 301 insertions(+)
create mode 100644 drivers/edac/sifive_edac-l2.c
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 515fc3c..fede4b6 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -49,6 +49,7 @@ config RISCV
select RISCV_TIMER
select GENERIC_IRQ_MULTI_HANDLER
select ARCH_HAS_PTE_SPECIAL
+ select EDAC_SUPPORT
config MMU
def_bool y
diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
index e286b5b..63ccdf1 100644
--- a/drivers/edac/Kconfig
+++ b/drivers/edac/Kconfig
@@ -440,6 +440,13 @@ config EDAC_ALTERA_SDMMC
Support for error detection and correction on the
Altera SDMMC FIFO Memory for Altera SoCs.
+config EDAC_SIFIVE_L2
+ tristate "Sifive L2 Cache"
+ depends on RISCV
+ help
+ Support for error detection and correction on the SiFive L2
+ cache controller.
+
config EDAC_SYNOPSYS
tristate "Synopsys DDR Memory Controller"
depends on ARCH_ZYNQ || ARCH_ZYNQMP
diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile
index 716096d..ad9e3d3 100644
--- a/drivers/edac/Makefile
+++ b/drivers/edac/Makefile
@@ -74,6 +74,7 @@ obj-$(CONFIG_EDAC_OCTEON_PCI) += octeon_edac-pci.o
obj-$(CONFIG_EDAC_THUNDERX)+= thunderx_edac.o
obj-$(CONFIG_EDAC_ALTERA) += altera_edac.o
+obj-$(CONFIG_EDAC_SIFIVE_L2) += sifive_edac-l2.o
obj-$(CONFIG_EDAC_SYNOPSYS)+= synopsys_edac.o
obj-$(CONFIG_EDAC_XGENE) += xgene_edac.o
obj-$(CONFIG_EDAC_TI) += ti_edac.o
diff --git a/drivers/edac/sifive_edac-l2.c b/drivers/edac/sifive_edac-l2.c
new file mode 100644
index 000..124f43a
--- /dev/null
+++ b/drivers/edac/sifive_edac-l2.c
@@ -0,0 +1,292 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * SiFive L2 Cache EDAC Driver
+ *
+ * Copyright (C) 2018-2019 SiFive, Inc.
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+#include "edac_module.h"
+
+#define SIFIVE_EDAC_DIRFIX_LOW 0x100
+#define SIFIVE_EDAC_DIRFIX_HIGH 0x104
+#define SIFIVE_EDAC_DIRFIX_COUNT 0x108
+
+#define SIFIVE_EDAC_DIRFAIL_LOW 0x120
+#define SIFIVE_EDAC_DIRFAIL_HIGH 0x124
+#define SIFIVE_EDAC_DIRFAIL_COUNT 0x128
+
+#define SIFIVE_EDAC_DATFIX_LOW 0x140
+#define SIFIVE_EDAC_DATFIX_HIGH 0x144
+#define SIFIVE_EDAC_DATFIX_COUNT 0x148
+
+#define SIFIVE_EDAC_DATFAIL_LOW 0x160
+#define SIFIVE_EDAC_DATFAIL_HIGH 0x164
+#define SIFIVE_EDAC_DATFAIL_COUNT 0x168
+
+#define SIFIVE_EDAC_ECCINJECTERR 0x40
+#define SIFIVE_EDAC_CONFIG 0x00
+
+#define SIFIVE_EDAC_MAX_INTR 4
+
+/**
+ * struct sifive_edac_l2_priv - L2 cache controller private instance data
+ * @base: Base address of the controller
+ * @irq[]: Array of interrupt numbers
+ */
+struct sifive_edac_l2_priv {
+ void __iomem *base;
+ int irq[SIFIVE_EDAC_MAX_INTR];
+};
+
+enum {
+ dir_corr = 0,
+ dir_uncorr,
+ data_corr,
+ data_uncorr,
+};
+
+static struct dentry *sifive_edac_test;
+
+static ssize_t sifive_edac_l2_write(struct file *file, const char __user *data,
+ size_t count, loff_t *ppos)
+{
+ struct edac_device_ctl_info *dci = file->private_data;
+ struct sifive_edac_l2_priv *priv = dci->pvt_info;
+ unsigned int val;
+
+ if (kstrtouint_from_user(data, count, 0, &val))
+ return -EINVAL;
+ if ((val >= 0 && val < 0xFF) || (val >= 0x1 && val < 0x100FF))
+ writel(val, priv->base + SIFIVE_EDAC_ECCINJECTERR);
+ else
+ return -EINVAL;
+ return count;
+}
+
+static const struct file_operations sifive_edac_l2_fops = {
+ .owner = THIS_MODULE,
+ .open = simple_open,
+ .write = sifive_edac_l2_write
+};
+
+static void setup_sifive_debug(struct edac_device_ctl_info *edac_dev)
+{
+ sifive_edac_test = edac_debugfs_create_dir("sifive_edac_test");
+ edac_debugfs_create_file("sifive_debug_inject_error", 0200,
+sifive_edac_test, edac_dev,
+&sifive_edac_l2_fops);
+}
+
+static void teardown_sifive_debug(void)
+{
+ debugfs_remove_recursive(sifive_edac_test);
+}
+
+/**
+ * sifive_edac_l2_int_handler - ISR function for l2 cache controller
+ * @irq: Irq Number
+ * @device:Pointer to the edac device controller instance
+ *
+ * This routine is triggered whenever there is ECC error detected
+ *
+ * Return: Always returns IRQ_HANDLED
+ */
+static irqreturn_t sifive_edac_l2_int_handler(int irq, void *device)
+{
+ struct edac_device_ctl_info *dci =
+ (struct edac_device_ctl_info *)device
[PATCH 1/2] edac: sifive: Add DT documentation for SiFive L2 cache Controller
DT documentation for L2 cache controller added.
Signed-off-by: Yash Shah
---
.../devicetree/bindings/edac/sifive-edac-l2.txt| 31 ++
1 file changed, 31 insertions(+)
create mode 100644 Documentation/devicetree/bindings/edac/sifive-edac-l2.txt
diff --git a/Documentation/devicetree/bindings/edac/sifive-edac-l2.txt
b/Documentation/devicetree/bindings/edac/sifive-edac-l2.txt
new file mode 100644
index 000..abce09f
--- /dev/null
+++ b/Documentation/devicetree/bindings/edac/sifive-edac-l2.txt
@@ -0,0 +1,31 @@
+SiFive L2 Cache EDAC driver device tree bindings
+-
+This driver uses the EDAC framework to report L2 cache controller ECC errors.
+
+- compatible: Should be "sifive,-ccache" and "sifive,ccache".
+ Supported compatible strings are:
+ "sifive,fu540-c000-ccache" for the SiFive cache controller v0 as integrated
+ onto the SiFive FU540 chip, and "sifive,ccache0" for the SiFive
+ cache controller v0 IP block with no chip integration tweaks.
+ Please refer to sifive-blocks-ip-versioning.txt for details
+
+- interrupts: Must contain 3 entries for FU540 (DirError, DataError, and
+ DataFail signals) or 4 entries for other chips (DirError, DirFail, DataError,
+ and DataFail signals)
+
+- interrupt-parent: Must be core interrupt controller
+
+- reg: Physical base address and size of L2 cache controller registers map
+ A second range can indicate L2 Loosely Integrated Memory
+
+- reg-names: Names for the cells of reg, must contain "control" and "sideband"
+
+Example:
+
+cache-controller@201 {
+ compatible = "sifive,fu540-c000-ccache", "sifive,ccache0";
+ interrupt-parent = <&plic>;
+ interrupts = <1 2 3>;
+ reg = <0x0 0x201 0x0 0x1000 0x0 0x800 0x0 0x200>;
+ reg-names = "control", "sideband";
+};
--
1.9.1
Re: [PATCH 2/2] sifive: edac: Add EDAC driver for Sifive l2 Cache Controller
On Tue, Mar 12, 2019 at 02:51:01PM +0530, Yash Shah wrote: > Add driver for the SiFive L2 cache controller > on the HiFive Unleashed board > > Signed-off-by: Yash Shah > --- > arch/riscv/Kconfig| 1 + > drivers/edac/Kconfig | 7 + > drivers/edac/Makefile | 1 + > drivers/edac/sifive_edac-l2.c | 292 > ++ > 4 files changed, 301 insertions(+) > create mode 100644 drivers/edac/sifive_edac-l2.c > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig > index 515fc3c..fede4b6 100644 > --- a/arch/riscv/Kconfig > +++ b/arch/riscv/Kconfig > @@ -49,6 +49,7 @@ config RISCV > select RISCV_TIMER > select GENERIC_IRQ_MULTI_HANDLER > select ARCH_HAS_PTE_SPECIAL > + select EDAC_SUPPORT > > config MMU > def_bool y > diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig > index e286b5b..63ccdf1 100644 > --- a/drivers/edac/Kconfig > +++ b/drivers/edac/Kconfig > @@ -440,6 +440,13 @@ config EDAC_ALTERA_SDMMC > Support for error detection and correction on the > Altera SDMMC FIFO Memory for Altera SoCs. > > +config EDAC_SIFIVE_L2 > + tristate "Sifive L2 Cache" > + depends on RISCV > + help > + Support for error detection and correction on the SiFive L2 > + cache controller. Please no EDAC drivers for a single functional unit with RAS capabilities. Rather, a sifive_edac or riscv_edac driver which covers the whole platform or even architecture and contains support for all the RAS functionality there. See altera_edac, for example. HTH. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH 2/2] pwm: Kconfig: Enable ehrpwm driver to be compiled for ARCH_K3
On Tue, Mar 12, 2019 at 02:46:29PM +0530, Vignesh Raghavendra wrote: > K3 devices have the same EHRPWM IP as OMAP SoCs. Enable driver to be built > for K3 devices. Also, drop reference to AM33xx in help text, as IP is > found on multiple TI SoCs. > > Signed-off-by: Vignesh Raghavendra > --- > drivers/pwm/Kconfig | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig > index 54f8238aac0d..c054bd1dba36 100644 > --- a/drivers/pwm/Kconfig > +++ b/drivers/pwm/Kconfig > @@ -467,10 +467,9 @@ config PWM_TIECAP > > config PWM_TIEHRPWM > tristate "EHRPWM PWM support" > - depends on ARCH_OMAP2PLUS || ARCH_DAVINCI_DA8XX > + depends on ARCH_OMAP2PLUS || ARCH_DAVINCI_DA8XX || ARCH_K3 > help > - PWM driver support for the EHRPWM controller found on AM33XX > - TI SOC > + PWM driver support for the EHRPWM controller found on TI SOCs It would be great to be able to compile this driver with COMPILE_TEST. >From a quick look the following would be appropriate: depends on ARCH_OMAP2PLUS || ARCH_DAVINCI_DA8XX || ARCH_K3 || COMPILE_TEST depends on HAVE_CLK && HAS_IOMEM Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |
Re: [PATCH v2] drivers: gpio: sprd: use devm_platform_ioremap_resource()
On 12.03.19 09:49, Baolin Wang wrote: > I still do not think the new API is suitable for this case. Since we > can have optional multiple IO resources, so the original code will not > return errors if we did not get the IO resources, but we must cast > errors if we failed to do ioremap. But you ignore the errors of > ioremap, which is not good. hmm, maybe we can differenciate on the error code ? patch up devm_platform_ioremap_resource() so it returns -ENOENT if there's no such resource defined. I suppose, ioremap() doesn't have a valid case for -ENOENT (but haven't checked yet). --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287
[PATCH] ACPI: sysfs: Prevent get_status() from returning acpi_status
From: Rafael J. Wysocki
The return value of get_status() is passed to user space on errors,
so it should not return acpi_status values then. Make it return
error values that are meaningful for user space instead.
This also makes a Clang warning regarding the initialization of a
local variable in get_status() go away.
Reported-by: Nathan Chancellor
Reviewed-by: Nathan Chancellor
Signed-off-by: Rafael J. Wysocki
---
Resend with a proper changelog and tags from Nathan.
---
drivers/acpi/sysfs.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
Index: linux-pm/drivers/acpi/sysfs.c
===
--- linux-pm.orig/drivers/acpi/sysfs.c
+++ linux-pm/drivers/acpi/sysfs.c
@@ -648,26 +648,29 @@ static void acpi_global_event_handler(u3
}
}
-static int get_status(u32 index, acpi_event_status *status,
+static int get_status(u32 index, acpi_event_status *ret,
acpi_handle *handle)
{
- int result;
+ acpi_status status;
if (index >= num_gpes + ACPI_NUM_FIXED_EVENTS)
return -EINVAL;
if (index < num_gpes) {
- result = acpi_get_gpe_device(index, handle);
- if (result) {
+ status = acpi_get_gpe_device(index, handle);
+ if (ACPI_FAILURE(status)) {
ACPI_EXCEPTION((AE_INFO, AE_NOT_FOUND,
"Invalid GPE 0x%x", index));
- return result;
+ return -ENXIO;
}
- result = acpi_get_gpe_status(*handle, index, status);
- } else if (index < (num_gpes + ACPI_NUM_FIXED_EVENTS))
- result = acpi_get_event_status(index - num_gpes, status);
+ status = acpi_get_gpe_status(*handle, index, ret);
+ } else {
+ status = acpi_get_event_status(index - num_gpes, ret);
+ }
+ if (ACPI_FAILURE(status))
+ return -EIO;
- return result;
+ return 0;
}
static ssize_t counter_show(struct kobject *kobj,
[PATCH] kernel/watchdog.c - make variables static
sparse complains: CHECK kernel/watchdog.c kernel/watchdog.c:45:19: warning: symbol 'nmi_watchdog_available' was not declared. Should it be static? kernel/watchdog.c:47:16: warning: symbol 'watchdog_allowed_mask' was not declared. Should it be static? They're not referenced by name from anyplace else, make them static. Signed-off-by: Valdis Kletnieks diff --git a/kernel/watchdog.c b/kernel/watchdog.c index 8fbfda94a67b..403c9bd90413 100644 --- a/kernel/watchdog.c +++ b/kernel/watchdog.c @@ -42,9 +42,9 @@ int __read_mostly watchdog_user_enabled = 1; int __read_mostly nmi_watchdog_user_enabled = NMI_WATCHDOG_DEFAULT; int __read_mostly soft_watchdog_user_enabled = 1; int __read_mostly watchdog_thresh = 10; -int __read_mostly nmi_watchdog_available; +static int __read_mostly nmi_watchdog_available; -struct cpumask watchdog_allowed_mask __read_mostly; +static struct cpumask watchdog_allowed_mask __read_mostly; struct cpumask watchdog_cpumask __read_mostly; unsigned long *watchdog_cpumask_bits = cpumask_bits(&watchdog_cpumask);
Re: [PATCH] ACPI/PPTT: Simplify leaf node detection.
On Monday, March 4, 2019 11:02:08 AM CET Sudeep Holla wrote: > On Fri, Mar 01, 2019 at 12:52:21PM -0600, Jeremy Linton wrote: > > ACPI 6.3 bumps the PPTT table revision and adds a LEAF_NODE flag. > > This allows us to avoid a second pass through the table to assure > > that the node in question is a leaf. > > > > Reviewed-by:Sudeep Holla > > -- > Regards, > Sudeep > > > Signed-off-by: Jeremy Linton > > --- > > drivers/acpi/pptt.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c > > index ad31c50de3be..065c4fc245d1 100644 > > --- a/drivers/acpi/pptt.c > > +++ b/drivers/acpi/pptt.c > > @@ -209,6 +209,9 @@ static int acpi_pptt_leaf_node(struct acpi_table_header > > *table_hdr, > > struct acpi_pptt_processor *cpu_node; > > u32 proc_sz; > > > > + if (table_hdr->revision > 1) > > + return (node->flags & ACPI_PPTT_ACPI_LEAF_NODE); > > + > > table_end = (unsigned long)table_hdr + table_hdr->length; > > node_entry = ACPI_PTR_DIFF(node, table_hdr); > > entry = ACPI_ADD_PTR(struct acpi_subtable_header, table_hdr, > > -- Patch applied, thanks!
Re: [PATCH 16/42] drivers: gpio: janz-ttl: drop unneccessary temp variable dev
On 12.03.19 10:17, Ben Dooks wrote: > On 11/03/2019 18:54, Enrico Weigelt, metux IT consult wrote: >> don't need the temporary variable "dev", directly use &pdev->dev >> >> Signed-off-by: Enrico Weigelt, metux IT consult > > This is quite usual to do, and I like it as it saves typing. > Personally I would say don't bother with this change. hmm, both approaches have their valid arguments. I'm not particularily biased to one or another ay, but I'd prefer having it consistent everywhere. --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287
RE: [PATCHv4 26/28] PCI: mobiveil: ls_pcie_g4: add Workaround for A-011451
Hi Bjorn,
Thanks a lot for your comments!
> -Original Message-
> From: Bjorn Helgaas [mailto:helg...@kernel.org]
> Sent: 2019年3月12日 1:35
> To: Z.q. Hou
> Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> robh...@kernel.org; mark.rutl...@arm.com; l.subrahma...@mobiveil.co.in;
> shawn...@kernel.org; Leo Li ;
> lorenzo.pieral...@arm.com; catalin.mari...@arm.com;
> will.dea...@arm.com; Mingkai Hu ; M.h. Lian
> ; Xiaowei Bao
> Subject: Re: [PATCHv4 26/28] PCI: mobiveil: ls_pcie_g4: add Workaround for
> A-011451
>
> On Mon, Mar 11, 2019 at 09:33:32AM +, Z.q. Hou wrote:
> > From: Hou Zhiqiang
> >
> > When LX2 PCIe controller is sending multiple split completions and ACK
> > latency expires indicating that ACK should be send at priority.
> > But because of large number of split completions and FC update DLLP,
> > the controller does not give priority to ACK transmission. This
> > results into ACK latency timer timeout error at the link partner and
> > the pending TLPs are replayed by the link partner again.
> >
> > Workaround:
> > 1. Reduce the ACK latency timeout value to a very small value.
> > 2. Restrict the number of completions from the LX2 PCIe controller
> >to 1, by changing the Max Read Request Size (MRRS) of link partner
> >to the same value as Max Packet size (MPS).
> >
> > This patch implemented part 1, the part 2 can be set by kernel
> > parameter 'pci=pcie_bus_perf'
>
> If I understand correctly, you're saying that LX2160A Rev1.0 will only work
> correctly if you have this patch applied AND you boot with
> "pci=pcie_bus_perf".
>
Your understanding is correct.
> That might be OK if these rev 1.0 parts are only used in the lab and are never
> shipped to customers. But if these parts are ever shipped to customers, I
> don't think it's acceptable for them to have to figure out that they must boot
> with "pci=pcie_bus_perf". Yes, you can document that in release notes, but
> it's still a poor user experience, and users will forget, and they will see
> mysterious hard-to-debug issues.
>
> Maybe there's a way for you to automatically set that pcie_bus_perf mode?
> With a dmesg note to indicate that you're overriding any mode the user may
> have selected?
>
Actually we don't have a way to set the pcie_bus_perf automatically under
Linux, we give this parameter in kernel cmdline.
Do you have any advice about how to set this parameter automatically under
Linux?
> > This ERRATA is only for LX2160A Rev1.0, and it will be fixed in
> > Rev2.0.
> >
> > Signed-off-by: Hou Zhiqiang
> > ---
> > V4:
> > - no change
> >
> > .../pci/controller/mobiveil/pci-layerscape-gen4.c | 15 +++
> > drivers/pci/controller/mobiveil/pcie-mobiveil.h | 4
> > 2 files changed, 19 insertions(+)
> >
> > diff --git a/drivers/pci/controller/mobiveil/pci-layerscape-gen4.c
> > b/drivers/pci/controller/mobiveil/pci-layerscape-gen4.c
> > index d2c5dbbd5e3c..20ce146788ca 100644
> > --- a/drivers/pci/controller/mobiveil/pci-layerscape-gen4.c
> > +++ b/drivers/pci/controller/mobiveil/pci-layerscape-gen4.c
> > @@ -82,12 +82,27 @@ static bool ls_pcie_g4_is_bridge(struct ls_pcie_g4
> *pcie)
> > return header_type == PCI_HEADER_TYPE_BRIDGE; }
> >
> > +static void workaround_A011451(struct ls_pcie_g4 *pcie) {
> > + struct mobiveil_pcie *mv_pci = pcie->pci;
> > + u32 val;
> > +
> > + /* Set ACK latency timeout */
> > + val = csr_readl(mv_pci, GPEX_ACK_REPLAY_TO);
> > + val &= ~(ACK_LAT_TO_VAL_MASK << ACK_LAT_TO_VAL_SHIFT);
> > + val |= (4 << ACK_LAT_TO_VAL_SHIFT);
> > + csr_writel(mv_pci, val, GPEX_ACK_REPLAY_TO); }
> > +
> > static int ls_pcie_g4_host_init(struct mobiveil_pcie *pci) {
> > struct ls_pcie_g4 *pcie = to_ls_pcie_g4(pci);
> >
> > pcie->rev = csr_readb(pci, PCI_REVISION_ID);
> >
> > + if (pcie->rev == REV_1_0)
> > + workaround_A011451(pcie);
> > +
> > return 0;
> > }
> >
> > diff --git a/drivers/pci/controller/mobiveil/pcie-mobiveil.h
> > b/drivers/pci/controller/mobiveil/pcie-mobiveil.h
> > index ab43de5e4b2b..f0e2e4ae09b5 100644
> > --- a/drivers/pci/controller/mobiveil/pcie-mobiveil.h
> > +++ b/drivers/pci/controller/mobiveil/pcie-mobiveil.h
> > @@ -85,6 +85,10 @@
> > #define PAB_AXI_AMAP_PEX_WIN_H(win)PAB_REG_ADDR(0x0bac,
> win)
> > #define PAB_INTP_AXI_PIO_CLASS 0x474
> >
> > +#define GPEX_ACK_REPLAY_TO 0x438
> > +#define ACK_LAT_TO_VAL_MASK 0x1fff
> > +#define ACK_LAT_TO_VAL_SHIFT 0
> > +
> > #define PAB_PEX_AMAP_CTRL(win) PAB_REG_ADDR(0x4ba0,
> win)
> > #define AMAP_CTRL_EN_SHIFT0
> > #define AMAP_CTRL_TYPE_SHIFT 1
> > --
> > 2.17.1
> >
Thanks,
Zhiqiang
Re: [PATCH] printk: kmsg_dump: Mark registered flag as private
On (03/12/19 10:18), Petr Mladek wrote:
> > > * @max_reason: filter for highest reason number that should be dumped
> > > - * @registered: Flag that specifies if this is already registered
> > > + * @registered: Flag that specifies if this is already registered
> > > (private)
> > > */
> > > struct kmsg_dumper {
> > > struct list_head list;
> >
[..]
> This is another field in the same structure. There are 4 other fields
> that are described as private by extra comment. Thefore this patch
> might make it more consistent.
Well, no objections from my side. At the same time nothing in kmsg_dump.h
suggests that "(private)" stands for "protected by logbuf_lock". Even more,
that struct has another "private" members, which are protected by
logbuf_lock - cur_idx, next_idx, cur_srq, next_seq; except when they are
not (see kmsg_dump_get_line_nolock() and other _nolock() functions). So
"private" has conflicting meanings.
struct kmsg_dumper {
struct list_head list;
void (*dump)(struct kmsg_dumper *dumper, enum kmsg_dump_reason reason);
enum kmsg_dump_reason max_reason;
bool active;
bool registered;
/* private state of the kmsg iterator */
u32 cur_idx;
u32 next_idx;
u64 cur_seq;
u64 next_seq;
};
>
> Well, I am not sure if it is worth it. Andrew?
>
Agreed.
-ss
[PATCH] HID: core: move Usage Page concatenation to hid_parser_main()
As seen on some USB wireless keyboards manufactured by Primax, the HID
parser was using some assumptions that are not always true. In this case
it's s the fact that, inside the scope of a main item, an Usage Page
will always precede an Usage.
The spec is not pretty clear as 6.2.2.7 states "Any usage that follows
is interpreted as a Usage ID and concatenated with the Usage Page".
While 6.2.2.8 states "When the parser encounters a main item it
concatenates the last declared Usage Page with a Usage to form a
complete usage value." Being somewhat contradictory it was decided to
match Window's implementation, which follows 6.2.2.8.
In summary, the patch moves the Usage Page concatenation from the local
item parsing function to the main item parsing function.
Signed-off-by: Nicolas Saenz Julienne
---
Note: A PR in hid-tools shoud show up anytime soon
drivers/hid/hid-core.c | 30 ++
include/linux/hid.h| 1 +
2 files changed, 19 insertions(+), 12 deletions(-)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 9993b692598f..158468ef23a6 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -218,13 +218,14 @@ static unsigned hid_lookup_collection(struct hid_parser
*parser, unsigned type)
* Add a usage to the temporary parser table.
*/
-static int hid_add_usage(struct hid_parser *parser, unsigned usage)
+static int hid_add_usage(struct hid_parser *parser, unsigned usage, __u8 size)
{
if (parser->local.usage_index >= HID_MAX_USAGES) {
hid_err(parser->device, "usage index exceeded\n");
return -1;
}
parser->local.usage[parser->local.usage_index] = usage;
+ parser->local.usage_size[parser->local.usage_index] = size;
parser->local.collection_index[parser->local.usage_index] =
parser->collection_stack_ptr ?
parser->collection_stack[parser->collection_stack_ptr - 1] : 0;
@@ -486,10 +487,7 @@ static int hid_parser_local(struct hid_parser *parser,
struct hid_item *item)
return 0;
}
- if (item->size <= 2)
- data = (parser->global.usage_page << 16) + data;
-
- return hid_add_usage(parser, data);
+ return hid_add_usage(parser, data, item->size);
case HID_LOCAL_ITEM_TAG_USAGE_MINIMUM:
@@ -498,9 +496,6 @@ static int hid_parser_local(struct hid_parser *parser,
struct hid_item *item)
return 0;
}
- if (item->size <= 2)
- data = (parser->global.usage_page << 16) + data;
-
parser->local.usage_minimum = data;
return 0;
@@ -511,9 +506,6 @@ static int hid_parser_local(struct hid_parser *parser,
struct hid_item *item)
return 0;
}
- if (item->size <= 2)
- data = (parser->global.usage_page << 16) + data;
-
count = data - parser->local.usage_minimum;
if (count + parser->local.usage_index >= HID_MAX_USAGES) {
/*
@@ -533,7 +525,7 @@ static int hid_parser_local(struct hid_parser *parser,
struct hid_item *item)
}
for (n = parser->local.usage_minimum; n <= data; n++)
- if (hid_add_usage(parser, n)) {
+ if (hid_add_usage(parser, n, item->size)) {
dbg_hid("hid_add_usage failed\n");
return -1;
}
@@ -553,8 +545,22 @@ static int hid_parser_local(struct hid_parser *parser,
struct hid_item *item)
static int hid_parser_main(struct hid_parser *parser, struct hid_item *item)
{
+ unsigned int usages;
__u32 data;
int ret;
+ int i;
+
+ usages = max_t(unsigned, parser->local.usage_index,
+parser->global.report_count);
+
+ /*
+* As per specification, 6.2.2.8:
+* "When the parser encounters a main item it concatenates the last
+* declared Usage Page with a Usage to form a complete usage value."
+*/
+ for (i = 0; i < usages; i++)
+ if (parser->local.usage_size[i] <= 2)
+ parser->local.usage[i] += parser->global.usage_page <<
16;
data = item_udata(item);
diff --git a/include/linux/hid.h b/include/linux/hid.h
index f9707d1dcb58..d1fb4b678873 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -417,6 +417,7 @@ struct hid_global {
struct hid_local {
unsigned usage[HID_MAX_USAGES]; /* usage array */
+ __u8 usage_size[HID_MAX_USAGES]; /* usage size array */
unsigned collection_index[HID_MAX_USAGES]; /* collection index array */
unsigned usage_index;
unsigned usage_minimum;
--
2.21.0
Re: [PATCH 36/42] drivers: gpio: uniphier: use devm_platform_ioremap_resource()
On Tue, Mar 12, 2019 at 3:57 AM Enrico Weigelt, metux IT consult wrote: > > Use the new helper that wraps the calls to platform_get_resource() > and devm_ioremap_resource() together. > > Signed-off-by: Enrico Weigelt, metux IT consult > --- Acked-by: Masahiro Yamada > drivers/gpio/gpio-uniphier.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/drivers/gpio/gpio-uniphier.c b/drivers/gpio/gpio-uniphier.c > index 0f662b2..93cdcc4 100644 > --- a/drivers/gpio/gpio-uniphier.c > +++ b/drivers/gpio/gpio-uniphier.c > @@ -346,7 +346,6 @@ static int uniphier_gpio_probe(struct platform_device > *pdev) > struct uniphier_gpio_priv *priv; > struct gpio_chip *chip; > struct irq_chip *irq_chip; > - struct resource *regs; > unsigned int nregs; > u32 ngpios; > int ret; > @@ -370,8 +369,7 @@ static int uniphier_gpio_probe(struct platform_device > *pdev) > if (!priv) > return -ENOMEM; > > - regs = platform_get_resource(pdev, IORESOURCE_MEM, 0); > - priv->regs = devm_ioremap_resource(dev, regs); > + priv->regs = devm_platform_ioremap_resource(pdev, 0); > if (IS_ERR(priv->regs)) > return PTR_ERR(priv->regs); > > -- > 1.9.1 > -- Best Regards Masahiro Yamada
Re: [PATCH 1/4] elf: don't be afraid of overflow
On Mon 2019-03-11 20:10:06, Alexey Dobriyan wrote: > On Mon, Mar 11, 2019 at 12:04:23PM +0100, Pavel Machek wrote: > > On Mon 2019-02-04 23:27:15, Alexey Dobriyan wrote: > > > Number of ELF program headers is 16-bit by spec, so total size > > > comfortably fits into "unsigned int". > > > > If it can't overflow, gcc should know too, and optimize checks > > out... right? > > Turns out it doesn't. Tells me you are doing something wrong. > > > @@ -429,13 +430,9 @@ static struct elf_phdr *load_elf_phdrs(struct elfhdr > > > *elf_ex, > > > goto out; > > > > > > /* Sanity check the number of program headers... */ > > > - if (elf_ex->e_phnum < 1 || > > > - elf_ex->e_phnum > 65536U / sizeof(struct elf_phdr)) > > > - goto out; > > > - > > > /* ...and their total size. */ > > > > This is just wrong. You removed check for zero, and I'm pretty sure > > sizeof() is not 1, so this one can trigger, too. > > No. ->e_phnum is 65535 max. That does not invalidate my argument. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH] OPP: Fix handling of multiple power domains
On Friday, March 8, 2019 5:37:12 AM CET Viresh Kumar wrote:
> On 06-03-19, 09:37, Rajendra Nayak wrote:
> > We seem to rely on the number of phandles specified in the
> > 'required-opps' property to identify cases where a device is
> > associated with multiple power domains and hence would have
> > multiple virtual devices that have to be dealt with.
> >
> > In cases where we do have devices with multiple power domains
> > but with only one of them being scalable, this logic seems to
> > fail.
> >
> > Instead read the number of power domains from DT to identify
> > such cases.
> >
> > Signed-off-by: Rajendra Nayak
> > ---
> > drivers/opp/of.c | 16 ++--
> > 1 file changed, 14 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/opp/of.c b/drivers/opp/of.c
> > index 06f0f632ec47..443c305ae100 100644
> > --- a/drivers/opp/of.c
> > +++ b/drivers/opp/of.c
> > @@ -172,7 +172,7 @@ static void _opp_table_alloc_required_tables(struct
> > opp_table *opp_table,
> > struct opp_table **required_opp_tables;
> > struct device **genpd_virt_devs = NULL;
> > struct device_node *required_np, *np;
> > - int count, i;
> > + int count, count_pd, i;
> >
> > /* Traversing the first OPP node is all we need */
> > np = of_get_next_available_child(opp_np, NULL);
> > @@ -185,7 +185,19 @@ static void _opp_table_alloc_required_tables(struct
> > opp_table *opp_table,
> > if (!count)
> > goto put_np;
> >
> > - if (count > 1) {
> > + /*
> > +* Check the number of power-domains to know if we need to deal
> > +* with virtual devices. In some cases we have devices with multiple
> > +* power domains but with only one of them being scalable, hence
> > +* 'count' could be 1, but we still have to deal with multiple genpds
> > +* and virtual devices.
> > +*/
> > + count_pd = of_count_phandle_with_args(dev->of_node, "power-domains",
> > + "#power-domain-cells");
> > + if (!count_pd)
> > + goto put_np;
> > +
> > + if (count_pd > 1) {
> > genpd_virt_devs = kcalloc(count, sizeof(*genpd_virt_devs),
> > GFP_KERNEL);
> > if (!genpd_virt_devs)
>
> Acked-by: Viresh Kumar
>
> @Rafael, please pick this up for 5.1-rc2 directly. Thanks.
Done, thanks!
Re: [RFC PATCH v1 25/25] printk: remove unused code
On Mon 2019-03-11 09:18:26, Sebastian Andrzej Siewior wrote: > On 2019-03-11 11:46:00 [+0900], Sergey Senozhatsky wrote: > > On (03/08/19 15:02), Sebastian Andrzej Siewior wrote: > > > On 2019-02-12 15:30:03 [+0100], John Ogness wrote: > > > > > > you removed the whole `irq_work' thing. You can also remove the include > > > for linux/irq_work.h. > > > > It may be too early to remove the whole `irq_work' thing. > > printk()->call_console_driver() should take console_sem > > lock. > > I would be _very_ glad to see that irq_work thingy gone. I just stumbled > upon this irq_work and cursed a little while doing other things. Have you seen stalls causes by the irq work? Or was it just glancing over the printk code? > Checking John's series and seeing that it was gone, was a relief. > Printing the whole thing in irq context does not look sane. printing the > import things right away and printing the remaining things later in > kthread looks good to me. The irq_work was originally added to handle messages from the scheduler by printk_deferred(). It was later used also to handle messages from NMI and printk recursion. It means that the use is pretty limited. It is more reliable than a kthread, especially when the scheduler is reporting problems. IMHO, it is a reasonable solution as long as the amount of messages is low. The real time kernel is another story but it has special handling in many other situations. That said, the kthread might still make sense as a fallback. It would be nice to have a hard limit for handling messages in irq context. Best Regards, Petr
[PATCHv4 23/28] dt-bindings: pci: Add NXP Layerscape SoCs PCIe Gen4 controller
From: Hou Zhiqiang
Add PCIe Gen4 controller DT bindings of NXP Layerscape SoCs.
Signed-off-by: Hou Zhiqiang
Reviewed-by: Rob Herring
---
V4:
- no change
.../bindings/pci/layerscape-pci-gen4.txt | 52 +++
MAINTAINERS | 8 +++
2 files changed, 60 insertions(+)
create mode 100644
Documentation/devicetree/bindings/pci/layerscape-pci-gen4.txt
diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci-gen4.txt
b/Documentation/devicetree/bindings/pci/layerscape-pci-gen4.txt
new file mode 100644
index ..b40fb5d15d3d
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/layerscape-pci-gen4.txt
@@ -0,0 +1,52 @@
+NXP Layerscape PCIe Gen4 controller
+
+This PCIe controller is based on the Mobiveil PCIe IP and thus inherits all
+the common properties defined in mobiveil-pcie.txt.
+
+Required properties:
+- compatible: should contain the platform identifier such as:
+ "fsl,lx2160a-pcie"
+- reg: base addresses and lengths of the PCIe controller register blocks.
+ "csr_axi_slave": Bridge config registers
+ "config_axi_slave": PCIe controller registers
+- interrupts: A list of interrupt outputs of the controller. Must contain an
+ entry for each entry in the interrupt-names property.
+- interrupt-names: It could include the following entries:
+ "intr": The interrupt that is asserted for controller interrupts
+ "aer": Asserted for aer interrupt when chip support the aer interrupt with
+none MSI/MSI-X/INTx mode,but there is interrupt line for aer.
+ "pme": Asserted for pme interrupt when chip support the pme interrupt with
+none MSI/MSI-X/INTx mode,but there is interrupt line for pme.
+- dma-coherent: Indicates that the hardware IP block can ensure the coherency
+ of the data transferred from/to the IP block. This can avoid the software
+ cache flush/invalid actions, and improve the performance significantly.
+- msi-parent : See the generic MSI binding described in
+ Documentation/devicetree/bindings/interrupt-controller/msi.txt.
+
+Example:
+
+ pcie@340 {
+ compatible = "fsl,lx2160a-pcie";
+ reg = <0x00 0x0340 0x0 0x0010 /* controller registers
*/
+ 0x80 0x 0x0 0x1000>; /* configuration space
*/
+ reg-names = "csr_axi_slave", "config_axi_slave";
+ interrupts = , /* AER
interrupt */
+, /* PME
interrupt */
+; /* controller
interrupt */
+ interrupt-names = "aer", "pme", "intr";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ apio-wins = <8>;
+ ppio-wins = <8>;
+ dma-coherent;
+ bus-range = <0x0 0xff>;
+ msi-parent = <&its>;
+ ranges = <0x8200 0x0 0x4000 0x80 0x4000 0x0
0x4000>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = < 0 0 1 &gic 0 0 GIC_SPI 109
IRQ_TYPE_LEVEL_HIGH>,
+ < 0 0 2 &gic 0 0 GIC_SPI 110
IRQ_TYPE_LEVEL_HIGH>,
+ < 0 0 3 &gic 0 0 GIC_SPI 111
IRQ_TYPE_LEVEL_HIGH>,
+ < 0 0 4 &gic 0 0 GIC_SPI 112
IRQ_TYPE_LEVEL_HIGH>;
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 1013e74b14f2..2d18c7213991 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11835,6 +11835,14 @@ L: linux-arm-ker...@lists.infradead.org
S: Maintained
F: drivers/pci/controller/dwc/*layerscape*
+PCI DRIVER FOR NXP LAYERSCAPE GEN4 CONTROLLER
+M: Hou Zhiqiang
+L: linux-...@vger.kernel.org
+L: linux-arm-ker...@lists.infradead.org
+S: Maintained
+F: Documentation/devicetree/bindings/pci/layerscape-pci-gen4.txt
+F: drivers/pci/controller/mobibeil/pci-layerscape-gen4.c
+
PCI DRIVER FOR GENERIC OF HOSTS
M: Will Deacon
L: linux-...@vger.kernel.org
--
2.17.1
RE: [PATCHv4 23/28] dt-bindings: pci: Add NXP Layerscape SoCs PCIe Gen4 controller
Hi All,
Please ignore this, has re-sent it adding lost Reviewed-by tag.
Thanks,
Zhiqiang
> -Original Message-
> From: Z.q. Hou
> Sent: 2019年3月11日 17:33
> To: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com;
> l.subrahma...@mobiveil.co.in; shawn...@kernel.org; Leo Li
> ; lorenzo.pieral...@arm.com;
> catalin.mari...@arm.com; will.dea...@arm.com
> Cc: Mingkai Hu ; M.h. Lian
> ; Xiaowei Bao ; Z.q. Hou
>
> Subject: [PATCHv4 23/28] dt-bindings: pci: Add NXP Layerscape SoCs PCIe
> Gen4 controller
>
> From: Hou Zhiqiang
>
> Add PCIe Gen4 controller DT bindings of NXP Layerscape SoCs.
>
> Signed-off-by: Hou Zhiqiang
> ---
> V4:
> - no change
>
> .../bindings/pci/layerscape-pci-gen4.txt | 52 +++
> MAINTAINERS | 8 +++
> 2 files changed, 60 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/pci/layerscape-pci-gen4.txt
>
> diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci-gen4.txt
> b/Documentation/devicetree/bindings/pci/layerscape-pci-gen4.txt
> new file mode 100644
> index ..b40fb5d15d3d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/layerscape-pci-gen4.txt
> @@ -0,0 +1,52 @@
> +NXP Layerscape PCIe Gen4 controller
> +
> +This PCIe controller is based on the Mobiveil PCIe IP and thus inherits
> +all the common properties defined in mobiveil-pcie.txt.
> +
> +Required properties:
> +- compatible: should contain the platform identifier such as:
> + "fsl,lx2160a-pcie"
> +- reg: base addresses and lengths of the PCIe controller register blocks.
> + "csr_axi_slave": Bridge config registers
> + "config_axi_slave": PCIe controller registers
> +- interrupts: A list of interrupt outputs of the controller. Must
> +contain an
> + entry for each entry in the interrupt-names property.
> +- interrupt-names: It could include the following entries:
> + "intr": The interrupt that is asserted for controller interrupts
> + "aer": Asserted for aer interrupt when chip support the aer interrupt with
> + none MSI/MSI-X/INTx mode,but there is interrupt line for aer.
> + "pme": Asserted for pme interrupt when chip support the pme interrupt
> with
> + none MSI/MSI-X/INTx mode,but there is interrupt line for pme.
> +- dma-coherent: Indicates that the hardware IP block can ensure the
> +coherency
> + of the data transferred from/to the IP block. This can avoid the
> +software
> + cache flush/invalid actions, and improve the performance significantly.
> +- msi-parent : See the generic MSI binding described in
> + Documentation/devicetree/bindings/interrupt-controller/msi.txt.
> +
> +Example:
> +
> + pcie@340 {
> + compatible = "fsl,lx2160a-pcie";
> + reg = <0x00 0x0340 0x0 0x0010 /* controller registers
> */
> +0x80 0x 0x0 0x1000>; /* configuration space
> */
> + reg-names = "csr_axi_slave", "config_axi_slave";
> + interrupts = , /* AER
> interrupt */
> + , /* PME interrupt
> */
> + ; /* controller
> interrupt */
> + interrupt-names = "aer", "pme", "intr";
> + #address-cells = <3>;
> + #size-cells = <2>;
> + device_type = "pci";
> + apio-wins = <8>;
> + ppio-wins = <8>;
> + dma-coherent;
> + bus-range = <0x0 0xff>;
> + msi-parent = <&its>;
> + ranges = <0x8200 0x0 0x4000 0x80 0x4000 0x0
> 0x4000>;
> + #interrupt-cells = <1>;
> + interrupt-map-mask = <0 0 0 7>;
> + interrupt-map = < 0 0 1 &gic 0 0 GIC_SPI 109
> IRQ_TYPE_LEVEL_HIGH>,
> + < 0 0 2 &gic 0 0 GIC_SPI 110
> IRQ_TYPE_LEVEL_HIGH>,
> + < 0 0 3 &gic 0 0 GIC_SPI 111
> IRQ_TYPE_LEVEL_HIGH>,
> + < 0 0 4 &gic 0 0 GIC_SPI 112
> IRQ_TYPE_LEVEL_HIGH>;
> + };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1013e74b14f2..2d18c7213991 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11835,6 +11835,14 @@ L: linux-arm-ker...@lists.infradead.org
> S: Maintained
> F: drivers/pci/controller/dwc/*layerscape*
>
> +PCI DRIVER FOR NXP LAYERSCAPE GEN4 CONTROLLER
> +M: Hou Zhiqiang
> +L: linux-...@vger.kernel.org
> +L: linux-arm-ker...@lists.infradead.org
> +S: Maintained
> +F: Documentation/devicetree/bindings/pci/layerscape-pci-gen4.txt
> +F: drivers/pci/controller/mobibeil/pci-layerscape-gen4.c
> +
> PCI DRIVER FOR GENERIC OF HOSTS
> M: Will Deacon
> L: linux-...@vger.kernel.org
> --
> 2.17.1
Re: [PATCH 12/14] sparc64: rtrap: Remove unneeded need_resched() loop
Hi, On 11/03/2019 23:13, David Miller wrote: [...] > > We must re-evaluate the %tstate value stored in ptregs, you cannot > make this change. > That's the one I was the less sure about, thanks for clearing it up and sorry for the noise.
Re: [PATCH 14/14] xtensa: entry: Remove unneeded need_resched() loop
On 12/03/2019 01:10, Max Filippov wrote: [...] > > Acked-by: Max Filippov > Thanks!
Re: [PATCH v3 4/9] mtd: rawnand: denali: switch over to ->exec_op() from legacy hooks
On Tue, Mar 12, 2019 at 6:03 PM Boris Brezillon
wrote:
>
> On Tue, 12 Mar 2019 17:44:45 +0900
> Masahiro Yamada wrote:
>
>
> > +
> > +static int denali_exec_instr(struct nand_chip *chip,
> > + const struct nand_op_instr *instr)
> > +{
> > + struct denali_nand_info *denali = to_denali(chip);
> > + bool width16 = chip->options & NAND_BUSWIDTH_16;
> > +
> > + switch (instr->type) {
> > + case NAND_OP_CMD_INSTR:
> > + denali_exec_out8(denali, DENALI_MAP11_CMD,
> > + &instr->ctx.cmd.opcode, 1);
> > + return 0;
> > + case NAND_OP_ADDR_INSTR:
> > + denali_exec_out8(denali, DENALI_MAP11_ADDR,
> > + instr->ctx.addr.addrs,
> > + instr->ctx.addr.naddrs);
> > + return 0;
> > + case NAND_OP_DATA_IN_INSTR:
> > + (!instr->ctx.data.force_8bit && width16 ?
> > + denali_exec_in16 :
> > + denali_exec_in8)(denali, DENALI_MAP11_DATA,
> > + instr->ctx.data.buf.in,
> > + instr->ctx.data.len);
>
> I agree with Miquel, this statement tends to obfuscate the code, and
> it's not like an extra if will make a huge difference in term of LOC.
OK, I will add the following helpers. Before sending v4, I will wait
for more comments.
static void denali_exec_in(struct denali_controller *denali, u32 type,
u8 *buf, unsigned int len, bool width16)
{
if (width16)
denali_exec_in16(denali, type, buf, len);
else
denali_exec_in8(denali, type, buf, len);
}
static void denali_exec_out(struct denali_controller *denali, u32 type,
const u8 *buf, unsigned int len)
{
if (width16)
denali_exec_out16(denali, type, buf, len);
else
denali_exec_out8(denali, type, buf, len);
}
>
> > + return 0;
> > + case NAND_OP_DATA_OUT_INSTR:
> > + (!instr->ctx.data.force_8bit && width16 ?
> > + denali_exec_out16 :
> > + denali_exec_out8)(denali, DENALI_MAP11_DATA,
> > +instr->ctx.data.buf.out,
> > +instr->ctx.data.len);
>
> Ditto.
>
> > + return 0;
> > + case NAND_OP_WAITRDY_INSTR:
> > + return denali_exec_waitrdy(denali);
> > + default:
> > + WARN_ONCE(1, "unsupported NAND instruction type: %d\n",
> > + instr->type);
> > +
> > + return -EINVAL;
> > + }
> > +}
>
> __
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
--
Best Regards
Masahiro Yamada
Re: [PATCH v2 3/3] x86/kdump/64: Change the upper limit of crashkernel reservation
On Tue, Mar 12, 2019 at 08:50:04AM +0800, Baoquan He wrote: > Restrict kdump to only reserve crashkernel below 64TB. Since the kdump > jumping may be from 5-level to 4-level, and the kdump kernel is put > above 64TB in 5-level kernel, then the jumping will fail. And the > crashkernel reservation is done during the 1st kernel bootup, there's > no way to detect the paging mode of kdump kernel at that time. > > Hence change the upper limit of crashkernel reservation to 64TB > on x86_64. > > Signed-off-by: Baoquan He > --- > arch/x86/kernel/setup.c | 18 ++ > 1 file changed, 14 insertions(+), 4 deletions(-) > > diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c > index 3d872a527cd9..d4d1366738a4 100644 > --- a/arch/x86/kernel/setup.c > +++ b/arch/x86/kernel/setup.c > @@ -451,16 +451,26 @@ static void __init > memblock_x86_reserve_range_setup_data(void) > #define CRASH_ALIGN (16 << 20) > > /* > - * Keep the crash kernel below this limit. On 32 bits earlier kernels > - * would limit the kernel to the low 512 MiB due to mapping restrictions. > - * On 64bit, old kexec-tools need to under 896MiB. > + * Keep the crash kernel below this limit. > + * > + * On 32 bits earlier kernels would limit the kernel to the low > + * 512 MiB due to mapping restrictions. > + * > + * On 64bit, old kexec-tools need to be under 896MiB. The later > + * supports to put kernel above 4G, up to system RAM top. Here > + * kdump kernel need be restricted to be under 64TB, which is > + * the upper limit of system RAM in 4-level paing mode. Since > + * the kdump jumping could be from 5-level to 4-level, the jumping > + * will fail if kernel is put above 64TB, and there's no way to > + * detect the paging mode of the kernel which will be loaded for > + * dumping during the 1st kernel bootup. > */ > #ifdef CONFIG_X86_32 > # define CRASH_ADDR_LOW_MAX (512 << 20) > # define CRASH_ADDR_HIGH_MAX (512 << 20) > #else > # define CRASH_ADDR_LOW_MAX (896UL << 20) > -# define CRASH_ADDR_HIGH_MAX MAXMEM > +# define CRASH_ADDR_HIGH_MAX (1ULL < 46) Maybe # define CRASH_ADDR_HIGH_MAX (64UL << 40) to match the notation for the rest of defines? Otherwise the patchset look good to me. You can use my ack for all of them: Acked-by: Kirill A. Shutemov > #endif > > static int __init reserve_crashkernel_low(void) > -- > 2.17.2 > -- Kirill A. Shutemov
Re: [PATCH 5.0 30/46] x86/boot/compressed/64: Do not read legacy ROM on EFI system
On Sat, Mar 09, 2019 at 10:10:19PM -0800, h...@zytor.com wrote:
> >@@ -47,8 +50,18 @@ static unsigned long find_trampoline_pla
> > * This code is based on reserve_bios_regions().
> > */
> >
> >-ebda_start = *(unsigned short *)0x40e << 4;
> >-bios_start = *(unsigned short *)0x413 << 10;
> >+/*
> >+ * EFI systems may not provide legacy ROM. The memory may not be
> >mapped
> >+ * at all.
> >+ *
> >+ * Only look for values in the legacy ROM for non-EFI system.
> >+ */
> >+signature = (char *)&boot_params->efi_info.efi_loader_signature;
> >+if (strncmp(signature, EFI32_LOADER_SIGNATURE, 4) &&
> >+strncmp(signature, EFI64_LOADER_SIGNATURE, 4)) {
> >+ebda_start = *(unsigned short *)0x40e << 4;
> >+bios_start = *(unsigned short *)0x413 << 10;
> >+}
> >
> > if (bios_start < BIOS_START_MIN || bios_start > BIOS_START_MAX)
> > bios_start = BIOS_START_MAX;
>
> Only one objection: the explanation is nonsensical.
Well, that's the best explanation I've come up with :/
I would be glad for any insight here.
--
Kirill A. Shutemov
Re: [RFC PATCH v1 08/25] printk: add ring buffer and kthread
On (03/11/19 11:51), John Ogness wrote: > > In new printk design the tasks are still affected by printing floods. > > Tasks have to line up and (busy) wait for each other, regardless of > > contexts. > > They only line up and busy wait is to add the informational message to > the ring buffer. The current printk implementation is the same in this > respect. And as you've noted, the logbuf spinlock is not a source of > latencies. I was talking about prb_lock(). > > When I do ./a.out --loglevel=X I have a clear understanding that > > all messages which fall into [critical, X] range will be in the logs, > > because I told that application that those messages are important to > > me right now. And it used to be the same with the kernel loglevel. > > The loglevel is not related to logging. It specifies the amount of > console printing. But I will assume you are referring to creating log > files by having an external device store the console printing. Right. E.g. screenlog.0 > > But now the kernel will do its own thing: > > > > - what the kernel considers important will go into the logs > > - what the kernel doesn't consider important _maybe_ will end up > > in the logs (preemptible printk kthread). And this is where > > loglevel now. After the _maybe_ part. > > "what the kernel considers" is a configuration option of the > administrator. The administrator can increase the verbocity of the > console (loglevel) without having negative effects on the system > itself. Also, if the system were to suddenly crash, those crash messages > shouldn't be in jeopardy just because the verbocity of the console was > turned up. Right. I'm not very sure about yet another knob which everyone should figure out. I guess I won't be surprised to find out that people set it to loglevel value. -ss
[PATCH] selftests: cpu-hotplug: check hotplug dir for the CONFIG_HOTPLUG_CPU
When the CONFIG_HOTPLUG_CPU is not set, there won't be a "hotplug" directory in /sys/devices/system/cpu/. Make use of this fact to check if we need to skip this test. Signed-off-by: Po-Hsu Lin --- tools/testing/selftests/cpu-hotplug/cpu-on-off-test.sh | 5 + 1 file changed, 5 insertions(+) diff --git a/tools/testing/selftests/cpu-hotplug/cpu-on-off-test.sh b/tools/testing/selftests/cpu-hotplug/cpu-on-off-test.sh index 0d26b5e..27275a1 100755 --- a/tools/testing/selftests/cpu-hotplug/cpu-on-off-test.sh +++ b/tools/testing/selftests/cpu-hotplug/cpu-on-off-test.sh @@ -23,6 +23,11 @@ prerequisite() exit $ksft_skip fi + if [ ! -d $SYSFS/devices/system/cpu/hotplug/ ]; then + echo $msg CONFIG_HOTPLUG_CPU needs to be enabled >&2 + exit $ksft_skip + fi + if ! ls $SYSFS/devices/system/cpu/cpu* > /dev/null 2>&1; then echo $msg cpu hotplug is not supported >&2 exit $ksft_skip -- 2.7.4
Re: [PATCH 1/2] PM / Runtime: Consolidate code to get active/suspended time
On Mon, 11 Mar 2019 at 13:03, Rafael J. Wysocki wrote:
>
> On Tuesday, March 5, 2019 1:55:26 PM CET Ulf Hansson wrote:
> > In a step to consolidate code around fetching the runtime PM active/suspend
> > time for a device, let's re-factor the existing pm_runtime_suspended_time()
> > and add a new corresponding pm_runtime_active_time(). Make the latter
> > shared internally to the PM core, as in following changes it starts making
> > use of it.
> >
> > Signed-off-by: Ulf Hansson
> > ---
> > drivers/base/power/power.h | 1 +
> > drivers/base/power/runtime.c | 14 --
> > 2 files changed, 13 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/base/power/power.h b/drivers/base/power/power.h
> > index c511def48b48..ec33fbdb919b 100644
> > --- a/drivers/base/power/power.h
> > +++ b/drivers/base/power/power.h
> > @@ -21,6 +21,7 @@ static inline void pm_runtime_early_init(struct device
> > *dev)
> > extern void pm_runtime_init(struct device *dev);
> > extern void pm_runtime_reinit(struct device *dev);
> > extern void pm_runtime_remove(struct device *dev);
> > +extern u64 pm_runtime_active_time(struct device *dev);
> >
> > #define WAKE_IRQ_DEDICATED_ALLOCATED BIT(0)
> > #define WAKE_IRQ_DEDICATED_MANAGED BIT(1)
> > diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
> > index 78937c45278c..d1908fc422cc 100644
> > --- a/drivers/base/power/runtime.c
> > +++ b/drivers/base/power/runtime.c
> > @@ -98,7 +98,7 @@ static void __update_runtime_status(struct device *dev,
> > enum rpm_status status)
> > dev->power.runtime_status = status;
> > }
> >
> > -u64 pm_runtime_suspended_time(struct device *dev)
> > +static u64 rpm_account_time(struct device *dev, bool suspend)
> > {
> > u64 time;
> > unsigned long flags;
> > @@ -106,12 +106,22 @@ u64 pm_runtime_suspended_time(struct device *dev)
> > spin_lock_irqsave(&dev->power.lock, flags);
> >
> > update_pm_runtime_accounting(dev);
> > - time = dev->power.suspended_time;
> > + time = suspend ? dev->power.suspended_time : dev->power.active_time;
> >
> > spin_unlock_irqrestore(&dev->power.lock, flags);
> >
> > return time;
> > }
> > +
> > +u64 pm_runtime_active_time(struct device *dev)
> > +{
> > + return rpm_account_time(dev, false);
> > +}
> > +
> > +u64 pm_runtime_suspended_time(struct device *dev)
> > +{
> > + return rpm_account_time(dev, true);
> > +}
> > EXPORT_SYMBOL_GPL(pm_runtime_suspended_time);
> >
> > /**
> >
>
> Both [1-2/2] applied with some manual changes (please see linux-next
> tomorrow).
>
Looks good, thanks!
Kind regards
Uffe
Re: [PATCH 3/9] drivers: ata: ahci_tegra: use devm_platform_ioremap_resource()
On 12/03/2019 09:19, Enrico Weigelt, metux IT consult wrote:
> Use the new helper that wraps the calls to platform_get_resource()
> and devm_ioremap_resource() together.
>
> Signed-off-by: Enrico Weigelt, metux IT consult
> ---
> drivers/ata/ahci_tegra.c | 13 +
> 1 file changed, 5 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/ata/ahci_tegra.c b/drivers/ata/ahci_tegra.c
> index 004f260..88748ca 100644
> --- a/drivers/ata/ahci_tegra.c
> +++ b/drivers/ata/ahci_tegra.c
> @@ -490,7 +490,6 @@ static int tegra_ahci_probe(struct platform_device *pdev)
> {
> struct ahci_host_priv *hpriv;
> struct tegra_ahci_priv *tegra;
> - struct resource *res;
> int ret;
> unsigned int i;
>
> @@ -507,19 +506,17 @@ static int tegra_ahci_probe(struct platform_device
> *pdev)
> tegra->pdev = pdev;
> tegra->soc = of_device_get_match_data(&pdev->dev);
>
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> - tegra->sata_regs = devm_ioremap_resource(&pdev->dev, res);
> + tegra->sata_regs = devm_platform_ioremap_resource(pdev, 1);
> if (IS_ERR(tegra->sata_regs))
> return PTR_ERR(tegra->sata_regs);
>
> /*
>* AUX registers is optional.
>*/
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
> - if (res) {
> - tegra->sata_aux_regs = devm_ioremap_resource(&pdev->dev, res);
> - if (IS_ERR(tegra->sata_aux_regs))
> - return PTR_ERR(tegra->sata_aux_regs);
> + tegra->sata_aux_regs = devm_platform_ioremap_resource(pdev, 2);
> + if (IS_ERR(tegra->sata_aux_regs)) {
> + dev_info(&pdev->dev, "Cant get aux registers (optional)");
dev_err?
> + tegra->sata_aux_regs = NULL;
This bit does not look right, because although the AUX registers are
optional, now we don't know if it failed because they are not supported
for a given device or something else failed. So I am not sure we can do
this here.
Cheers
Jon
--
nvpublic
Re: [PATCH v2] arm64: dts: rockchip: Fix vcc_host1_5v GPIO polarity on rk3328-rock64
Am Samstag, 9. März 2019, 17:10:12 CET schrieb Tomohiro Mayama: > This patch makes USB ports functioning again. > > Suggested-by: Robin Murphy > Signed-off-by: Tomohiro Mayama > Tested-by: Katsuhiro Suzuki added Fixes and Cc-stable tags and applied as fix for 5.1 Thanks Heiko
[PATCH v2 0/1] spi: spi-fsl-qspi: call spi_unregister_controller
Changes since v1: * use devm_spi_register_controller() instead of calling spi_unregister_controller() in the remove function Thanks Volker Volker Haspel (1): spi: spi-fsl-qspi: use devm_spi_register_controller drivers/spi/spi-fsl-qspi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.11.0
[PATCH v2 1/1] spi: spi-fsl-qspi: use devm_spi_register_controller
The driver does not clearly unregister the spi controller. Therefore calling an unbind and bind again will end up in a Kernel crash. The function devm_spi_register_controller will automatically be unregister the SPI device. Signed-off-by: Volker Haspel Signed-off-by: John Ogness --- drivers/spi/spi-fsl-qspi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/spi/spi-fsl-qspi.c b/drivers/spi/spi-fsl-qspi.c index 6a713f78a62e..41a49b93ca60 100644 --- a/drivers/spi/spi-fsl-qspi.c +++ b/drivers/spi/spi-fsl-qspi.c @@ -882,7 +882,7 @@ static int fsl_qspi_probe(struct platform_device *pdev) ctlr->dev.of_node = np; - ret = spi_register_controller(ctlr); + ret = devm_spi_register_controller(dev, ctlr); if (ret) goto err_destroy_mutex; -- 2.11.0
Re: [PATCH v2 3/3] x86/kdump/64: Change the upper limit of crashkernel reservation
On 03/12/19 at 12:48pm, Kirill A. Shutemov wrote: > > #ifdef CONFIG_X86_32 > > # define CRASH_ADDR_LOW_MAX(512 << 20) > > # define CRASH_ADDR_HIGH_MAX (512 << 20) > > #else > > # define CRASH_ADDR_LOW_MAX(896UL << 20) > > -# define CRASH_ADDR_HIGH_MAX MAXMEM > > +# define CRASH_ADDR_HIGH_MAX (1ULL < 46) > > Maybe > > # define CRASH_ADDR_HIGH_MAX (64UL << 40) > > to match the notation for the rest of defines? > Sure, I will replace it, and repost a whole patchset with your ack added on each patch. Thanks for your careful reviewing and great suggestions. > > Otherwise the patchset look good to me. You can use my ack for all of > them: > > Acked-by: Kirill A. Shutemov > > > #endif > > > > static int __init reserve_crashkernel_low(void) > > -- > > 2.17.2 > > > > -- > Kirill A. Shutemov
Re: [PATCH v9 0/2] PWM support for HiFive Unleashed
On Mär 12 2019, Yash Shah wrote: > This patch series adds a PWM driver and DT documentation > for HiFive Unleashed board. The patches are mostly based on > Wesley's patch. Heartbeat trigger still doesn't work for me. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
[PATCH] fs/handle.c - fix up kerneldoc
CC fs/fhandle.o fs/fhandle.c:259: warning: Function parameter or member 'flags' not described in 'sys_open_by_handle_at' fs/fhandle.c:259: warning: Excess function parameter 'flag' description in 'sys_open_by_handle_at' Fix apparent typo in the kerneldoc Signed-off-by: Valdis Kletnieks diff --git a/fs/fhandle.c b/fs/fhandle.c index 0ee727485615..01263ffbc4c0 100644 --- a/fs/fhandle.c +++ b/fs/fhandle.c @@ -246,7 +246,7 @@ static long do_handle_open(int mountdirfd, struct file_handle __user *ufh, * sys_open_by_handle_at: Open the file handle * @mountdirfd: directory file descriptor * @handle: file handle to be opened - * @flag: open flags. + * @flags: open flags. * * @mountdirfd indicate the directory file descriptor * of the mount point. file handle is decoded relative
[PATCH] security/keys/request_key.c - fix kerneldoc
CC security/keys/request_key.o security/keys/request_key.c:35: warning: Function parameter or member 'authkey' not described in 'complete_request_key' security/keys/request_key.c:35: warning: Excess function parameter 'auth_key' description in 'complete_request_key' Fix it up to match the function Signed-off-by: Valdis Kletnieks
[PATCH] ARM: dts: Add stmpe-adc DT node to Toradex T30 modules
From: Philippe Schenker
Add the stmpe-adc DT node as found on Toradex T30 modules
Signed-off-by: Philippe Schenker
---
arch/arm/boot/dts/tegra30-apalis-v1.1.dtsi | 22 ++
arch/arm/boot/dts/tegra30-apalis.dtsi | 22 ++
arch/arm/boot/dts/tegra30-colibri.dtsi | 22 ++
3 files changed, 42 insertions(+), 24 deletions(-)
diff --git a/arch/arm/boot/dts/tegra30-apalis-v1.1.dtsi
b/arch/arm/boot/dts/tegra30-apalis-v1.1.dtsi
index 02f8126481a2..8b7a827d604d 100644
--- a/arch/arm/boot/dts/tegra30-apalis-v1.1.dtsi
+++ b/arch/arm/boot/dts/tegra30-apalis-v1.1.dtsi
@@ -994,11 +994,17 @@
id = <0>;
blocks = <0x5>;
irq-trigger = <0x1>;
+ /* 3.25 MHz ADC clock speed */
+ st,adc-freq = <1>;
+ /* 12-bit ADC */
+ st,mod-12b = <1>;
+ /* internal ADC reference */
+ st,ref-sel = <0>;
+ /* ADC converstion time: 80 clocks */
+ st,sample-time = <4>;
stmpe_touchscreen {
compatible = "st,stmpe-ts";
- /* 3.25 MHz ADC clock speed */
- st,adc-freq = <1>;
/* 8 sample average control */
st,ave-ctrl = <3>;
/* 7 length fractional part in z */
@@ -1008,17 +1014,17 @@
* current limit value
*/
st,i-drive = <1>;
- /* 12-bit ADC */
- st,mod-12b = <1>;
- /* internal ADC reference */
- st,ref-sel = <0>;
- /* ADC converstion time: 80 clocks */
- st,sample-time = <4>;
/* 1 ms panel driver settling time */
st,settling = <3>;
/* 5 ms touch detect interrupt delay */
st,touch-det-delay = <5>;
};
+
+ stmpe_adc {
+ compatible = "st,stmpe-adc";
+ /* forbid to use ADC channels 3-0 (touch) */
+ st,norequest-mask = <0x0F>;
+ };
};
/*
diff --git a/arch/arm/boot/dts/tegra30-apalis.dtsi
b/arch/arm/boot/dts/tegra30-apalis.dtsi
index 7f112f192fe9..c18f6f61d764 100644
--- a/arch/arm/boot/dts/tegra30-apalis.dtsi
+++ b/arch/arm/boot/dts/tegra30-apalis.dtsi
@@ -976,11 +976,17 @@
id = <0>;
blocks = <0x5>;
irq-trigger = <0x1>;
+ /* 3.25 MHz ADC clock speed */
+ st,adc-freq = <1>;
+ /* 12-bit ADC */
+ st,mod-12b = <1>;
+ /* internal ADC reference */
+ st,ref-sel = <0>;
+ /* ADC converstion time: 80 clocks */
+ st,sample-time = <4>;
stmpe_touchscreen {
compatible = "st,stmpe-ts";
- /* 3.25 MHz ADC clock speed */
- st,adc-freq = <1>;
/* 8 sample average control */
st,ave-ctrl = <3>;
/* 7 length fractional part in z */
@@ -990,17 +996,17 @@
* current limit value
*/
st,i-drive = <1>;
- /* 12-bit ADC */
- st,mod-12b = <1>;
- /* internal ADC reference */
- st,ref-sel = <0>;
- /* ADC converstion time: 80 clocks */
- st,sample-time = <4>;
/* 1 ms panel driver settling time */
st,settling = <3>;
/* 5 ms touch detect interrupt delay */
st,touch-det-delay = <5>;
};
+
+ stmpe_adc {
+ compatible = "st,stmpe-adc";
+ /* forbid to use ADC channels 3-0 (touch) */
+ st,norequest-mask = <0x0F>;
+ };
};
/*
diff --git a/arch/arm/boot/dts/tegra30-colibri.dtsi
b/arch/arm/boot/dts/tegra30-colibri.dtsi
index 35af03ca9e90..1f9198bb24ff 100644
Re: [PATCH v3 2/9] mtd: rawnand: denali: refactor syndrome layout handling for raw access
Hi Masahiro,
Masahiro Yamada wrote on Tue, 12 Mar
2019 17:44:43 +0900:
> The Denali IP adopts the syndrome page layout (payload and ECC are
> interleaved). The *_page_raw() and *_oob() callbacks are complicated
> because they must hide the underlying layout used by the hardware,
> and always return contiguous in-band and out-of-band data.
>
> Currently, similar code is duplicated to reorganize the data layout.
> For example, denali_read_page_raw() and denali_write_page_raw() look
> almost the same.
>
> The idea for refactoring is to split the code into two parts:
> [1] conversion of page layout
> [2] what to do at every ECC chunk boundary
>
> For [1], I wrote denali_raw_payload_op() and denali_raw_oob_op().
> They manipulate data for the Denali controller's specific page layout
> of in-band, out-of-band, respectively.
>
> The difference between write and read is just the operation at
> ECC chunk boundaries. For example, denali_read_oob() calls
> nand_change_read_column_op(), whereas denali_write_oob() calls
> nand_change_write_column_op(). So, I implemented [2] as a callback
> passed into [1].
>
> Signed-off-by: Masahiro Yamada
> ---
>
[...]
> static int denali_read_page_raw(struct nand_chip *chip, uint8_t *buf,
> int oob_required, int page)
> {
> + struct denali_nand_info *denali = to_denali(chip);
> struct mtd_info *mtd = nand_to_mtd(chip);
> - struct denali_nand_info *denali = mtd_to_denali(mtd);
> - int writesize = mtd->writesize;
> - int oobsize = mtd->oobsize;
> - int ecc_steps = chip->ecc.steps;
> - int ecc_size = chip->ecc.size;
> - int ecc_bytes = chip->ecc.bytes;
> void *tmp_buf = denali->buf;
> - int oob_skip = denali->oob_skip_bytes;
> - size_t size = writesize + oobsize;
> - int ret, i, pos, len;
> + size_t size = mtd->writesize + mtd->oobsize;
> + int ret;
> +
> + if (!buf)
> + return -EINVAL;
>
> ret = denali_data_xfer(chip, tmp_buf, size, page, 1, 0);
> if (ret)
> return ret;
>
> - /* Arrange the buffer for syndrome payload/ecc layout */
> - if (buf) {
> - for (i = 0; i < ecc_steps; i++) {
> - pos = i * (ecc_size + ecc_bytes);
> - len = ecc_size;
> -
> - if (pos >= writesize)
> - pos += oob_skip;
> - else if (pos + len > writesize)
> - len = writesize - pos;
> -
> - memcpy(buf, tmp_buf + pos, len);
> - buf += len;
> - if (len < ecc_size) {
> - len = ecc_size - len;
> - memcpy(buf, tmp_buf + writesize + oob_skip,
> -len);
> - buf += len;
> - }
> - }
> - }
> + ret = denali_raw_payload_op(chip, buf, denali_memcpy_in, tmp_buf);
Honestly, I still don't like passing denali_memcpy_in/out as parameter.
Besides that, once you'll have added helpers to avoid abusing the
ternary operator in 4/9, the rest looks fine by me.
Thanks,
Miquèl
Re: [PATCH] arm64: dts: meson-gxl-s905d-phicomm-n1: add status LED
Hi! On Tue, Mar 12, 2019 at 4:59 PM Neil Armstrong wrote: > [...] > BTW, do you know if it's possible to have a sample of the Phicomm N1 > in order to be added in kernelci ? It's easy to purchase one in China and second-handed ones are dirt cheap, but I don't think it's available worldwide. I'm not familiar with world-wide shipping or exporting stuff so I can't help much here. > > Neil
Re: [RFC PATCH v1 08/25] printk: add ring buffer and kthread
On Mon 2019-03-11 11:51:49, John Ogness wrote: > On 2019-03-07, Sergey Senozhatsky wrote: > > I don't really understand the role of loglevel anymore. > > "what the kernel considers" is a configuration option of the > administrator. The administrator can increase the verbocity of the > console (loglevel) without having negative effects on the system > itself. Where do you get the confidence that atomic console will not slow down the system? Have you tried it on real life workload when debugging a real life bug? Some benchmarks might help. Well, it would be needed to trigger some messages from them and see how the different approaches affect the overall system performance. > Also, if the system were to suddenly crash, those crash messages > shouldn't be in jeopardy just because the verbocity of the console was > turned up. This expects that the error messages will be enough to discover and fix the problem. > You (and Petr) talk about that _all_ console printing is for > emergencies. That if an administrator sets the loglevel to 7 it is > because the pr_info messages are just as important as the pr_emerg. It might be true when the messages with higher level (more critical) are not enough to understand the situation. > And if that is indeed the intention of console printing and loglevel, then > why is asynchronous printk calls for console messages even allowed > today? IMO that isn't taking the importance of the message very > seriously. Because it was working pretty well in the past. The amount of messages is still growing (code complexity, more CPUs, more devices, ...). Our customers have started reporting softlockups "only" 7 years ago or so. We currently have two level handling of messages: + all messages can be seen from userspace + messages below console_loglevel can be seen on the console You are introducing one more level of handling: + critical messages are printed on the console directly even before the queued less critical ones The third level would be acceptable when: + atomic consoles are reliable enough + the code complexity is worth the gain IMHO, we mix too many things here: + log buffer implementation + console offload + direct console handling using atomic consoles I see the potential in all areas: + lock less ring buffer helps to avoid deadlocks, and extra log buffers + console offload prevents too long stalls (softlockups) + direct console handling might help to avoid deadlocks and might make the output more reliable. I think that we are on the same page here. But we must use an incremental approach. It is not acceptable to replace everything by a single patch. And it is not acceptable to break important functionality and implement alternative solution several patches later. Also no solution is as ideal as it is sometimes presented in this thread. Best Regards, Petr
Re: [PATCH v1 04/10] perf, tools, record: Clarify help for --switch-output
On Mon, Mar 11, 2019 at 01:24:40PM -0700, Andi Kleen wrote:
> From: Andi Kleen
>
> The help description for --switch-output looks like there
> are multiple comma separated fields. But it's actually a choice
> of different options. Make it clear and less confusing.
>
> Before:
>
> % perf report -h
s/report/record/
> ...
> --switch-output[=]
> Switch output when receive SIGUSR2 or cross
> size,time threshold
>
> After:
>
> % perf report -h
ditto
jirka
> ...
>
> --switch-output[=]
> Switch output when receiving SIGUSR2 (signal) or
> cross a size or time threshold
>
> Signed-off-by: Andi Kleen
> ---
> tools/perf/builtin-record.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
> index 02d7c40b2d10..e7144a1c1c82 100644
> --- a/tools/perf/builtin-record.c
> +++ b/tools/perf/builtin-record.c
> @@ -1989,8 +1989,8 @@ static struct option __record_options[] = {
> OPT_BOOLEAN(0, "timestamp-boundary", &record.timestamp_boundary,
> "Record timestamp boundary (time of first/last samples)"),
> OPT_STRING_OPTARG_SET(0, "switch-output", &record.switch_output.str,
> - &record.switch_output.set, "signal,size,time",
> - "Switch output when receive SIGUSR2 or cross
> size,time threshold",
> + &record.switch_output.set, "signal or size[BKMG] or
> time[smhd]",
> + "Switch output when receiving SIGUSR2 (signal) or
> cross a size or time threshold",
> "signal"),
> OPT_INTEGER(0, "switch-max-files", &record.switch_output.num_files,
> "Limit number of switch output generated files"),
> --
> 2.20.1
>
Re: [PATCH v1 05/10] perf, report: Show all sort keys in help output
On Mon, Mar 11, 2019 at 01:24:41PM -0700, Andi Kleen wrote: > From: Andi Kleen > > Show all the supported sort keys in the command line help output, > so that it's not needed to refer to the manpage. > > The output is not line wrapped, so it can be fairly long. > > Before: > > % perf report -h > ... > -s, --sort > sort by key(s): pid, comm, dso, symbol, parent, > cpu, srcline, ... Please refer the man page for the complete list. > > After: > > % perf report -h > ... > -s, --sort > sort by key(s): overhead overhead_sys overhead_us > overhead_guest_sys overhead_guest_us overhead_children sample period pid comm > dso symbol parent cpu ... that line goes forever now, please provide some formating into multiple lines jirka
[PATCH v3 1/3] x86/boot: Add xloadflags bits for 5-level kernel checking
Add two bits XLF_5LEVEL and XLF_5LEVEL_ENABLED for 5-level kernel. Bit XLF_5LEVEL indicates if 5-level related code is contained in this kernel. Bit XLF_5LEVEL_ENABLED indicates if CONFIG_X86_5LEVEL=y is set. They are being used in later patch to check if kexec/kdump kernel is loaded in right place. Signed-off-by: Baoquan He Acked-by: Kirill A. Shutemov --- arch/x86/boot/header.S| 12 +++- arch/x86/include/uapi/asm/bootparam.h | 2 ++ 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S index 850b8762e889..be19f4199727 100644 --- a/arch/x86/boot/header.S +++ b/arch/x86/boot/header.S @@ -419,7 +419,17 @@ xloadflags: # define XLF4 0 #endif - .word XLF0 | XLF1 | XLF23 | XLF4 +#ifdef CONFIG_X86_64 +#ifdef CONFIG_X86_5LEVEL +#define XLF56 (XLF_5LEVEL|XLF_5LEVEL_ENABLED) +#else +#define XLF56 XLF_5LEVEL +#endif +#else +#define XLF56 0 +#endif + + .word XLF0 | XLF1 | XLF23 | XLF4 | XLF56 cmdline_size: .long COMMAND_LINE_SIZE-1 #length of the command line, #added with boot protocol diff --git a/arch/x86/include/uapi/asm/bootparam.h b/arch/x86/include/uapi/asm/bootparam.h index 60733f137e9a..c895df5482c5 100644 --- a/arch/x86/include/uapi/asm/bootparam.h +++ b/arch/x86/include/uapi/asm/bootparam.h @@ -29,6 +29,8 @@ #define XLF_EFI_HANDOVER_32(1<<2) #define XLF_EFI_HANDOVER_64(1<<3) #define XLF_EFI_KEXEC (1<<4) +#define XLF_5LEVEL (1<<5) +#define XLF_5LEVEL_ENABLED (1<<6) #ifndef __ASSEMBLY__ -- 2.17.2
[PATCH v3 0/3] Add restrictions for kexec/kdump jumping between 5-level and 4-level kernel
This is v3 post. The original v1 post can be found here: http://lkml.kernel.org/r/20180829141624.13985-1-...@redhat.com Later a v1 RESEND version: http://lkml.kernel.org/r/20190125022817.29506-1-...@redhat.com V2 post is here: http://lkml.kernel.org/r/20190312005004.19182-1-...@redhat.com This patchset is trying to fix several issues for kexec/kdump when dynamic switching of paging mode is enabled in x86_64. The current kernel supports 5-level paging mode, and supports dynamically choosing paging mode during bootup according to kernel image, hardware and kernel parameter setting. This flexibility brings several issues for kexec/kdump: Issues: 1) Dynamic switching between paging mode requires code change in target kernel. So we can't kexec jump from 5-level kernel to old 4-level kernel which lacks the code change. 2) Switching from 5-level paging to 4-level paging kernel would fail, if kexec() put kernel image above 64TiB of memory. 3) Kdump jumping has similar issue as 2). This require us to only reserve crashkernel below 64TB, otherwise jumping from 5-level to 4-level kernel will fail. Note: Since we have two interfaces kexec_load() and kexec_file_load() to load kexec/kdump kernel, handling for them is a little different. For kexec_load(), most of the loading job is done in user space utility kexec_tools. However, for kexec_file_load(), most of the loading codes have moved into kernel because of kernel image verification. Fixes: a) For issue 1), we need check if XLF_5LEVEL is set, otherwise error out a message. -This need be done in both kernel and kexec_tools utility. -Patch 2/3 is the handling of kernel part. -Will post user space patch to kexec mailing list later. b) For issue 2), we need check if both XLF_5LEVEL and XLF_5LEVEL_ENABLED are set, otherwise error out a message. -This only need be done in kexec_tools utility. Because for kexec_file_load(), the current code searches area to put kernel from bottom to up in system RAM, we usually can always find an area below 4 GB, no need to worry about 5-level kernel jumping to 4-level kernel. While for kexec_load(), it's top down seraching area for kernel loading, and implemented in user space. We need make sure that 5-level kernel find an area under 64 TB for a kexec-ed kernel of 4-level. -Will post user space patch to kexec mailing list later. c) For issues 3), just limit kernel to reserve crashkernel below 64 TB. -This only need be done in kernel. -It doesn't need to check bit XLF_5LEVEL or XLF_5LEVEL_ENABLED, we just simply limit it below 64 TB which should be enough. Because crashernel is reserved during the 1st kernel's bootup, we don't know what kernel will be loaded for kdump usage. -Patch 3/3 handles this. Concerns from reviewing comments: 1) In v1, hpa raised concern that why the paging mode checking is not done before kexec jumping, the discussion can be found here: http://lkml.kernel.org/r/alpine.deb.2.21.1809051002020.1...@nanos.tec.linutronix.de As tglx said, it might be not doable for kdump since kdump kernel's reserved crashkernel region only owns a portion of memory, may be above 4G; and might be not safer to do paging mode checking and switching thing after crash. 2) In v1 RESEND post, tglx asked why only bit XLF_5LEVEL is checked, even though two bits XLF_5LEVEL or XLF_5LEVEL_ENABLED added. So add more words to explain it in *Fixes* b). Changelog: v2->v3: Change the constant to match the notation for the rest of defines as Kirill suggested; v1->v2: Correct the subject of patch 1 according to tglx's comment; Add more information to cover-letter to address reviewers' concerns; Baoquan He (3): x86/boot: Add xloadflags bits for 5-level kernel checking x86/kexec/64: Error out if try to jump to old 4-level kernel from 5-level kernel x86/kdump/64: Change the upper limit of crashkernel reservation arch/x86/boot/header.S| 12 +++- arch/x86/include/uapi/asm/bootparam.h | 2 ++ arch/x86/kernel/kexec-bzimage64.c | 5 + arch/x86/kernel/setup.c | 18 ++ 4 files changed, 32 insertions(+), 5 deletions(-) -- 2.17.2
[PATCH v3 2/3] x86/kexec/64: Error out if try to jump to old 4-level kernel from 5-level kernel
In relocate_kernel() CR4.LA57 flag is set before kexec jumping if
the kernel has 5-level paging enabled. Then in boot/compressed/head_64.S,
it will check if the booting kernel is in 4-level or 5-level paging
mode, and handle accordingly. However, the old kernel which doesn't
contain the 5-level codes doesn't know how to cope with it, then #GP
triggered.
Instead of triggering #GP during kexec kernel boot, error out during
kexec loading if find out we are trying to jump to old 4-level kernel
from 5-level kernel.
Signed-off-by: Baoquan He
Acked-by: Kirill A. Shutemov
---
arch/x86/kernel/kexec-bzimage64.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/x86/kernel/kexec-bzimage64.c
b/arch/x86/kernel/kexec-bzimage64.c
index 1f3b77367948..4c9c079b5673 100644
--- a/arch/x86/kernel/kexec-bzimage64.c
+++ b/arch/x86/kernel/kexec-bzimage64.c
@@ -321,6 +321,11 @@ static int bzImage64_probe(const char *buf, unsigned long
len)
return ret;
}
+ if (!(header->xloadflags & XLF_5LEVEL) && pgtable_l5_enabled()) {
+ pr_err("Can not jump to old 4-level kernel from 5-level
kernel.\n");
+ return ret;
+ }
+
/* I've got a bzImage */
pr_debug("It's a relocatable bzImage64\n");
ret = 0;
--
2.17.2
Re: Misc improvements and bug fixes for perf
On Mon, Mar 11, 2019 at 01:24:36PM -0700, Andi Kleen wrote: > Mostly unrelated to each other, so can be picked'n'chosed. > > - Fix perf stat --no-scale > - Support --reltime in perf script > - Fix crashes with stat -r > - Handle JITed code better in perf report > - Allow to limit rotated perf.data files > - Filter metrics in perf list > - Show all sort keys in perf report help > - Fix multiplexing formula > > Also available in > git://git.kernel.org/pub/scm/linux/kernel/git/ak/linux-misc perf/misc-fixes-4 > apart from the 2 comments it all looks good to me Acked-by: Jiri Olsa thanks, jirka
[PATCH v3 3/3] x86/kdump/64: Change the upper limit of crashkernel reservation
Restrict kdump to only reserve crashkernel below 64TB. Since the kdump jumping may be from 5-level to 4-level, and the kdump kernel is put above 64TB in 5-level kernel, then the jumping will fail. And the crashkernel reservation is done during the 1st kernel bootup, there's no way to detect the paging mode of kdump kernel at that time. Hence change the upper limit of crashkernel reservation to 64TB on x86_64. Signed-off-by: Baoquan He Acked-by: Kirill A. Shutemov --- arch/x86/kernel/setup.c | 18 ++ 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c index 3d872a527cd9..5508b981f33d 100644 --- a/arch/x86/kernel/setup.c +++ b/arch/x86/kernel/setup.c @@ -451,16 +451,26 @@ static void __init memblock_x86_reserve_range_setup_data(void) #define CRASH_ALIGN(16 << 20) /* - * Keep the crash kernel below this limit. On 32 bits earlier kernels - * would limit the kernel to the low 512 MiB due to mapping restrictions. - * On 64bit, old kexec-tools need to under 896MiB. + * Keep the crash kernel below this limit. + * + * On 32 bits earlier kernels would limit the kernel to the low + * 512 MiB due to mapping restrictions. + * + * On 64bit, old kexec-tools need to be under 896MiB. The later + * supports to put kernel above 4G, up to system RAM top. Here + * kdump kernel need be restricted to be under 64TB, which is + * the upper limit of system RAM in 4-level paing mode. Since + * the kdump jumping could be from 5-level to 4-level, the jumping + * will fail if kernel is put above 64TB, and there's no way to + * detect the paging mode of the kernel which will be loaded for + * dumping during the 1st kernel bootup. */ #ifdef CONFIG_X86_32 # define CRASH_ADDR_LOW_MAX(512 << 20) # define CRASH_ADDR_HIGH_MAX (512 << 20) #else # define CRASH_ADDR_LOW_MAX(896UL << 20) -# define CRASH_ADDR_HIGH_MAX MAXMEM +# define CRASH_ADDR_HIGH_MAX (64UL << 40) #endif static int __init reserve_crashkernel_low(void) -- 2.17.2
[PATCH] clocksource/drivers/oxnas: Fix OX820 compatible
The OX820 compatible is wrong is the driver, fix it.
Fixes: 2ea3401e2a84 ("clocksource/drivers/oxnas: Add OX820 compatible")
Reported-by: Daniel Golle
Signed-off-by: Neil Armstrong
---
drivers/clocksource/timer-oxnas-rps.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clocksource/timer-oxnas-rps.c
b/drivers/clocksource/timer-oxnas-rps.c
index eed6feff8b5f..30c6f4ce672b 100644
--- a/drivers/clocksource/timer-oxnas-rps.c
+++ b/drivers/clocksource/timer-oxnas-rps.c
@@ -296,4 +296,4 @@ static int __init oxnas_rps_timer_init(struct device_node
*np)
TIMER_OF_DECLARE(ox810se_rps,
"oxsemi,ox810se-rps-timer", oxnas_rps_timer_init);
TIMER_OF_DECLARE(ox820_rps,
- "oxsemi,ox820se-rps-timer", oxnas_rps_timer_init);
+ "oxsemi,ox820-rps-timer", oxnas_rps_timer_init);
--
2.20.1
Re: [PATCH 1/3] arm64: dts: rockchip: rk3399: rock960: Rename vcc_sys into vcc5v0_sys
Am Montag, 11. März 2019, 16:03:30 CET schrieb Jagan Teki: > It is always better practice to follow regulator naming conventions > as per the schematics for future references. > > So, rename vcc_sys into vcc5v0_sys as per rk3399 power diagram of > rock960 schematics. > > Signed-off-by: Jagan Teki > Signed-off-by: Akash Gajjar I've double-checked both rock960 and ficus schematics to verify and applied both patch 1+2 for 5.2 Thanks Heiko
Re: [PATCH] ata: pata_oldpiix: Add missing device ID for INTEL_82371AB
On Mon, Dec 10, 2018 at 05:52:35PM +0300, Sergei Shtylyov wrote: > Hello! > > On 12/10/2018 04:46 PM, Corentin Labbe wrote: > > > When playing with a virtual SPARC machine with qemu, I found that the > > IDE emulated device was not probing with the ata/pata_oldpiix driver. > >Correctly, it should probe with ata_piix, > > > But with the old ide/piix, it was probed.> > > This is due to this PCI devid was not migrated from the old ide/piix. > >It wasn't on purpose -- the IDE driver supports the original PIIX > incorrectly. > Hello What about removing this old driver totally if it dont work ? Regards
