* [PATCH v3 3/3] dmaengine: imx-sdma: allocate max 20 bds for one transfer
From: Robin Gong @ 2018-07-23 17:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1532367972-29707-1-git-send-email-yibin.gong@nxp.com>
If multi-bds used in one transfer, all bds should be consisten
memory.To easily follow it, enlarge the dma pool size into 20 bds,
and it will report error if the number of bds is over than 20. For
dmatest, the max count for single transfer is NUM_BD *
SDMA_BD_MAX_CNT = 20 * 65535 = ~1.28MB.
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
---
drivers/dma/imx-sdma.c | 17 ++++++++++++++++-
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index b4ec2d2..5973489 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -298,6 +298,15 @@ struct sdma_context_data {
u32 scratch7;
} __attribute__ ((packed));
+/*
+ * All bds in one transfer should be consitent on SDMA. To easily follow it,just
+ * set the dma pool size as the enough bds. For example, in dmatest case, the
+ * max 20 bds means the max for single transfer is NUM_BD * SDMA_BD_MAX_CNT = 20
+ * * 65535 = ~1.28MB. 20 bds supposed to be enough basically.If it's still not
+ * enough in some specific cases, enlarge it here.Warning message would also
+ * appear if the bd numbers is over than 20.
+ */
+#define NUM_BD 20
struct sdma_engine;
@@ -1273,7 +1282,7 @@ static int sdma_alloc_chan_resources(struct dma_chan *chan)
goto disable_clk_ahb;
sdmac->bd_pool = dma_pool_create("bd_pool", chan->device->dev,
- sizeof(struct sdma_buffer_descriptor),
+ NUM_BD * sizeof(struct sdma_buffer_descriptor),
32, 0);
return 0;
@@ -1314,6 +1323,12 @@ static struct sdma_desc *sdma_transfer_init(struct sdma_channel *sdmac,
{
struct sdma_desc *desc;
+ if (bds > NUM_BD) {
+ dev_err(sdmac->sdma->dev, "%d bds exceed the max %d\n",
+ bds, NUM_BD);
+ goto err_out;
+ }
+
desc = kzalloc((sizeof(*desc)), GFP_NOWAIT);
if (!desc)
goto err_out;
--
2.7.4
^ permalink raw reply related
* [v3,3/3] dmaengine: imx-sdma: allocate max 20 bds for one transfer
From: Robin Gong @ 2018-07-23 17:46 UTC (permalink / raw)
To: vkoul, dan.j.williams, s.hauer, linux
Cc: linux-arm-kernel, kernel, dmaengine, linux-kernel, linux-imx
If multi-bds used in one transfer, all bds should be consisten
memory.To easily follow it, enlarge the dma pool size into 20 bds,
and it will report error if the number of bds is over than 20. For
dmatest, the max count for single transfer is NUM_BD *
SDMA_BD_MAX_CNT = 20 * 65535 = ~1.28MB.
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
---
drivers/dma/imx-sdma.c | 17 ++++++++++++++++-
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index b4ec2d2..5973489 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -298,6 +298,15 @@ struct sdma_context_data {
u32 scratch7;
} __attribute__ ((packed));
+/*
+ * All bds in one transfer should be consitent on SDMA. To easily follow it,just
+ * set the dma pool size as the enough bds. For example, in dmatest case, the
+ * max 20 bds means the max for single transfer is NUM_BD * SDMA_BD_MAX_CNT = 20
+ * * 65535 = ~1.28MB. 20 bds supposed to be enough basically.If it's still not
+ * enough in some specific cases, enlarge it here.Warning message would also
+ * appear if the bd numbers is over than 20.
+ */
+#define NUM_BD 20
struct sdma_engine;
@@ -1273,7 +1282,7 @@ static int sdma_alloc_chan_resources(struct dma_chan *chan)
goto disable_clk_ahb;
sdmac->bd_pool = dma_pool_create("bd_pool", chan->device->dev,
- sizeof(struct sdma_buffer_descriptor),
+ NUM_BD * sizeof(struct sdma_buffer_descriptor),
32, 0);
return 0;
@@ -1314,6 +1323,12 @@ static struct sdma_desc *sdma_transfer_init(struct sdma_channel *sdmac,
{
struct sdma_desc *desc;
+ if (bds > NUM_BD) {
+ dev_err(sdmac->sdma->dev, "%d bds exceed the max %d\n",
+ bds, NUM_BD);
+ goto err_out;
+ }
+
desc = kzalloc((sizeof(*desc)), GFP_NOWAIT);
if (!desc)
goto err_out;
^ permalink raw reply related
* [PATCH v3 2/3] dmaengine: imx-sdma: add memcpy interface
From: Robin Gong @ 2018-07-23 17:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1532367972-29707-1-git-send-email-yibin.gong@nxp.com>
Add MEMCPY capability for imx-sdma driver.
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
---
drivers/dma/imx-sdma.c | 93 ++++++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 90 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index e3d5e73..b4ec2d2 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -342,6 +342,7 @@ struct sdma_desc {
* @pc_from_device: script address for those device_2_memory
* @pc_to_device: script address for those memory_2_device
* @device_to_device: script address for those device_2_device
+ * @pc_to_pc: script address for those memory_2_memory
* @flags: loop mode or not
* @per_address: peripheral source or destination address in common case
* destination address in p_2_p case
@@ -367,6 +368,7 @@ struct sdma_channel {
enum dma_slave_buswidth word_size;
unsigned int pc_from_device, pc_to_device;
unsigned int device_to_device;
+ unsigned int pc_to_pc;
unsigned long flags;
dma_addr_t per_address, per_address2;
unsigned long event_mask[2];
@@ -869,14 +871,16 @@ static void sdma_get_pc(struct sdma_channel *sdmac,
* These are needed once we start to support transfers between
* two peripherals or memory-to-memory transfers
*/
- int per_2_per = 0;
+ int per_2_per = 0, emi_2_emi = 0;
sdmac->pc_from_device = 0;
sdmac->pc_to_device = 0;
sdmac->device_to_device = 0;
+ sdmac->pc_to_pc = 0;
switch (peripheral_type) {
case IMX_DMATYPE_MEMORY:
+ emi_2_emi = sdma->script_addrs->ap_2_ap_addr;
break;
case IMX_DMATYPE_DSP:
emi_2_per = sdma->script_addrs->bp_2_ap_addr;
@@ -949,6 +953,7 @@ static void sdma_get_pc(struct sdma_channel *sdmac,
sdmac->pc_from_device = per_2_emi;
sdmac->pc_to_device = emi_2_per;
sdmac->device_to_device = per_2_per;
+ sdmac->pc_to_pc = emi_2_emi;
}
static int sdma_load_context(struct sdma_channel *sdmac)
@@ -965,6 +970,8 @@ static int sdma_load_context(struct sdma_channel *sdmac)
load_address = sdmac->pc_from_device;
else if (sdmac->direction == DMA_DEV_TO_DEV)
load_address = sdmac->device_to_device;
+ else if (sdmac->direction == DMA_MEM_TO_MEM)
+ load_address = sdmac->pc_to_pc;
else
load_address = sdmac->pc_to_device;
@@ -1214,10 +1221,28 @@ static int sdma_alloc_chan_resources(struct dma_chan *chan)
{
struct sdma_channel *sdmac = to_sdma_chan(chan);
struct imx_dma_data *data = chan->private;
+ struct imx_dma_data mem_data;
int prio, ret;
- if (!data)
- return -EINVAL;
+ /*
+ * MEMCPY may never setup chan->private by filter function such as
+ * dmatest, thus create 'struct imx_dma_data mem_data' for this case.
+ * Please note in any other slave case, you have to setup chan->private
+ * with 'struct imx_dma_data' in your own filter function if you want to
+ * request dma channel by dma_request_channel() rather than
+ * dma_request_slave_channel(). Othwise, 'MEMCPY in case?' will appear
+ * to warn you to correct your filter function.
+ */
+ if (!data) {
+ dev_dbg(sdmac->sdma->dev, "MEMCPY in case?\n");
+ mem_data.priority = 2;
+ mem_data.peripheral_type = IMX_DMATYPE_MEMORY;
+ mem_data.dma_request = 0;
+ mem_data.dma_request2 = 0;
+ data = &mem_data;
+
+ sdma_get_pc(sdmac, IMX_DMATYPE_MEMORY);
+ }
switch (data->priority) {
case DMA_PRIO_HIGH:
@@ -1307,6 +1332,10 @@ static struct sdma_desc *sdma_transfer_init(struct sdma_channel *sdmac,
if (sdma_alloc_bd(desc))
goto err_desc_out;
+ /* No slave_config called in MEMCPY case, so do here */
+ if (direction == DMA_MEM_TO_MEM)
+ sdma_config_ownership(sdmac, false, true, false);
+
if (sdma_load_context(sdmac))
goto err_desc_out;
@@ -1318,6 +1347,62 @@ static struct sdma_desc *sdma_transfer_init(struct sdma_channel *sdmac,
return NULL;
}
+static struct dma_async_tx_descriptor *sdma_prep_memcpy(
+ struct dma_chan *chan, dma_addr_t dma_dst,
+ dma_addr_t dma_src, size_t len, unsigned long flags)
+{
+ struct sdma_channel *sdmac = to_sdma_chan(chan);
+ struct sdma_engine *sdma = sdmac->sdma;
+ int channel = sdmac->channel;
+ size_t count;
+ int i = 0, param;
+ struct sdma_buffer_descriptor *bd;
+ struct sdma_desc *desc;
+
+ if (!chan || !len)
+ return NULL;
+
+ dev_dbg(sdma->dev, "memcpy: %pad->%pad, len=%zu, channel=%d.\n",
+ &dma_src, &dma_dst, len, channel);
+
+ desc = sdma_transfer_init(sdmac, DMA_MEM_TO_MEM,
+ len / SDMA_BD_MAX_CNT + 1);
+ if (!desc)
+ return NULL;
+
+ do {
+ count = min_t(size_t, len, SDMA_BD_MAX_CNT);
+ bd = &desc->bd[i];
+ bd->buffer_addr = dma_src;
+ bd->ext_buffer_addr = dma_dst;
+ bd->mode.count = count;
+ desc->chn_count += count;
+ bd->mode.command = 0;
+
+ dma_src += count;
+ dma_dst += count;
+ len -= count;
+ i++;
+
+ param = BD_DONE | BD_EXTD | BD_CONT;
+ /* last bd */
+ if (!len) {
+ param |= BD_INTR;
+ param |= BD_LAST;
+ param &= ~BD_CONT;
+ }
+
+ dev_dbg(sdma->dev, "entry %d: count: %zd dma: 0x%x %s%s\n",
+ i, count, bd->buffer_addr,
+ param & BD_WRAP ? "wrap" : "",
+ param & BD_INTR ? " intr" : "");
+
+ bd->mode.status = param;
+ } while (len);
+
+ return vchan_tx_prep(&sdmac->vc, &desc->vd, flags);
+}
+
static struct dma_async_tx_descriptor *sdma_prep_slave_sg(
struct dma_chan *chan, struct scatterlist *sgl,
unsigned int sg_len, enum dma_transfer_direction direction,
@@ -1903,6 +1988,7 @@ static int sdma_probe(struct platform_device *pdev)
dma_cap_set(DMA_SLAVE, sdma->dma_device.cap_mask);
dma_cap_set(DMA_CYCLIC, sdma->dma_device.cap_mask);
+ dma_cap_set(DMA_MEMCPY, sdma->dma_device.cap_mask);
INIT_LIST_HEAD(&sdma->dma_device.channels);
/* Initialize channel parameters */
@@ -1969,6 +2055,7 @@ static int sdma_probe(struct platform_device *pdev)
sdma->dma_device.dst_addr_widths = SDMA_DMA_BUSWIDTHS;
sdma->dma_device.directions = SDMA_DMA_DIRECTIONS;
sdma->dma_device.residue_granularity = DMA_RESIDUE_GRANULARITY_SEGMENT;
+ sdma->dma_device.device_prep_dma_memcpy = sdma_prep_memcpy;
sdma->dma_device.device_issue_pending = sdma_issue_pending;
sdma->dma_device.dev->dma_parms = &sdma->dma_parms;
dma_set_max_seg_size(sdma->dma_device.dev, SDMA_BD_MAX_CNT);
--
2.7.4
^ permalink raw reply related
* [v3,2/3] dmaengine: imx-sdma: add memcpy interface
From: Robin Gong @ 2018-07-23 17:46 UTC (permalink / raw)
To: vkoul, dan.j.williams, s.hauer, linux
Cc: linux-arm-kernel, kernel, dmaengine, linux-kernel, linux-imx
Add MEMCPY capability for imx-sdma driver.
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
---
drivers/dma/imx-sdma.c | 93 ++++++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 90 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index e3d5e73..b4ec2d2 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -342,6 +342,7 @@ struct sdma_desc {
* @pc_from_device: script address for those device_2_memory
* @pc_to_device: script address for those memory_2_device
* @device_to_device: script address for those device_2_device
+ * @pc_to_pc: script address for those memory_2_memory
* @flags: loop mode or not
* @per_address: peripheral source or destination address in common case
* destination address in p_2_p case
@@ -367,6 +368,7 @@ struct sdma_channel {
enum dma_slave_buswidth word_size;
unsigned int pc_from_device, pc_to_device;
unsigned int device_to_device;
+ unsigned int pc_to_pc;
unsigned long flags;
dma_addr_t per_address, per_address2;
unsigned long event_mask[2];
@@ -869,14 +871,16 @@ static void sdma_get_pc(struct sdma_channel *sdmac,
* These are needed once we start to support transfers between
* two peripherals or memory-to-memory transfers
*/
- int per_2_per = 0;
+ int per_2_per = 0, emi_2_emi = 0;
sdmac->pc_from_device = 0;
sdmac->pc_to_device = 0;
sdmac->device_to_device = 0;
+ sdmac->pc_to_pc = 0;
switch (peripheral_type) {
case IMX_DMATYPE_MEMORY:
+ emi_2_emi = sdma->script_addrs->ap_2_ap_addr;
break;
case IMX_DMATYPE_DSP:
emi_2_per = sdma->script_addrs->bp_2_ap_addr;
@@ -949,6 +953,7 @@ static void sdma_get_pc(struct sdma_channel *sdmac,
sdmac->pc_from_device = per_2_emi;
sdmac->pc_to_device = emi_2_per;
sdmac->device_to_device = per_2_per;
+ sdmac->pc_to_pc = emi_2_emi;
}
static int sdma_load_context(struct sdma_channel *sdmac)
@@ -965,6 +970,8 @@ static int sdma_load_context(struct sdma_channel *sdmac)
load_address = sdmac->pc_from_device;
else if (sdmac->direction == DMA_DEV_TO_DEV)
load_address = sdmac->device_to_device;
+ else if (sdmac->direction == DMA_MEM_TO_MEM)
+ load_address = sdmac->pc_to_pc;
else
load_address = sdmac->pc_to_device;
@@ -1214,10 +1221,28 @@ static int sdma_alloc_chan_resources(struct dma_chan *chan)
{
struct sdma_channel *sdmac = to_sdma_chan(chan);
struct imx_dma_data *data = chan->private;
+ struct imx_dma_data mem_data;
int prio, ret;
- if (!data)
- return -EINVAL;
+ /*
+ * MEMCPY may never setup chan->private by filter function such as
+ * dmatest, thus create 'struct imx_dma_data mem_data' for this case.
+ * Please note in any other slave case, you have to setup chan->private
+ * with 'struct imx_dma_data' in your own filter function if you want to
+ * request dma channel by dma_request_channel() rather than
+ * dma_request_slave_channel(). Othwise, 'MEMCPY in case?' will appear
+ * to warn you to correct your filter function.
+ */
+ if (!data) {
+ dev_dbg(sdmac->sdma->dev, "MEMCPY in case?\n");
+ mem_data.priority = 2;
+ mem_data.peripheral_type = IMX_DMATYPE_MEMORY;
+ mem_data.dma_request = 0;
+ mem_data.dma_request2 = 0;
+ data = &mem_data;
+
+ sdma_get_pc(sdmac, IMX_DMATYPE_MEMORY);
+ }
switch (data->priority) {
case DMA_PRIO_HIGH:
@@ -1307,6 +1332,10 @@ static struct sdma_desc *sdma_transfer_init(struct sdma_channel *sdmac,
if (sdma_alloc_bd(desc))
goto err_desc_out;
+ /* No slave_config called in MEMCPY case, so do here */
+ if (direction == DMA_MEM_TO_MEM)
+ sdma_config_ownership(sdmac, false, true, false);
+
if (sdma_load_context(sdmac))
goto err_desc_out;
@@ -1318,6 +1347,62 @@ static struct sdma_desc *sdma_transfer_init(struct sdma_channel *sdmac,
return NULL;
}
+static struct dma_async_tx_descriptor *sdma_prep_memcpy(
+ struct dma_chan *chan, dma_addr_t dma_dst,
+ dma_addr_t dma_src, size_t len, unsigned long flags)
+{
+ struct sdma_channel *sdmac = to_sdma_chan(chan);
+ struct sdma_engine *sdma = sdmac->sdma;
+ int channel = sdmac->channel;
+ size_t count;
+ int i = 0, param;
+ struct sdma_buffer_descriptor *bd;
+ struct sdma_desc *desc;
+
+ if (!chan || !len)
+ return NULL;
+
+ dev_dbg(sdma->dev, "memcpy: %pad->%pad, len=%zu, channel=%d.\n",
+ &dma_src, &dma_dst, len, channel);
+
+ desc = sdma_transfer_init(sdmac, DMA_MEM_TO_MEM,
+ len / SDMA_BD_MAX_CNT + 1);
+ if (!desc)
+ return NULL;
+
+ do {
+ count = min_t(size_t, len, SDMA_BD_MAX_CNT);
+ bd = &desc->bd[i];
+ bd->buffer_addr = dma_src;
+ bd->ext_buffer_addr = dma_dst;
+ bd->mode.count = count;
+ desc->chn_count += count;
+ bd->mode.command = 0;
+
+ dma_src += count;
+ dma_dst += count;
+ len -= count;
+ i++;
+
+ param = BD_DONE | BD_EXTD | BD_CONT;
+ /* last bd */
+ if (!len) {
+ param |= BD_INTR;
+ param |= BD_LAST;
+ param &= ~BD_CONT;
+ }
+
+ dev_dbg(sdma->dev, "entry %d: count: %zd dma: 0x%x %s%s\n",
+ i, count, bd->buffer_addr,
+ param & BD_WRAP ? "wrap" : "",
+ param & BD_INTR ? " intr" : "");
+
+ bd->mode.status = param;
+ } while (len);
+
+ return vchan_tx_prep(&sdmac->vc, &desc->vd, flags);
+}
+
static struct dma_async_tx_descriptor *sdma_prep_slave_sg(
struct dma_chan *chan, struct scatterlist *sgl,
unsigned int sg_len, enum dma_transfer_direction direction,
@@ -1903,6 +1988,7 @@ static int sdma_probe(struct platform_device *pdev)
dma_cap_set(DMA_SLAVE, sdma->dma_device.cap_mask);
dma_cap_set(DMA_CYCLIC, sdma->dma_device.cap_mask);
+ dma_cap_set(DMA_MEMCPY, sdma->dma_device.cap_mask);
INIT_LIST_HEAD(&sdma->dma_device.channels);
/* Initialize channel parameters */
@@ -1969,6 +2055,7 @@ static int sdma_probe(struct platform_device *pdev)
sdma->dma_device.dst_addr_widths = SDMA_DMA_BUSWIDTHS;
sdma->dma_device.directions = SDMA_DMA_DIRECTIONS;
sdma->dma_device.residue_granularity = DMA_RESIDUE_GRANULARITY_SEGMENT;
+ sdma->dma_device.device_prep_dma_memcpy = sdma_prep_memcpy;
sdma->dma_device.device_issue_pending = sdma_issue_pending;
sdma->dma_device.dev->dma_parms = &sdma->dma_parms;
dma_set_max_seg_size(sdma->dma_device.dev, SDMA_BD_MAX_CNT);
^ permalink raw reply related
* [PATCH v3 1/3] dmaengine: imx-sdma: add SDMA_BD_MAX_CNT to replace '0xffff'
From: Robin Gong @ 2018-07-23 17:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1532367972-29707-1-git-send-email-yibin.gong@nxp.com>
Add macro SDMA_BD_MAX_CNT to replace '0xffff'.
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
---
drivers/dma/imx-sdma.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 3b622d6..e3d5e73 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -185,6 +185,7 @@
* Mode/Count of data node descriptors - IPCv2
*/
struct sdma_mode_count {
+#define SDMA_BD_MAX_CNT 0xffff
u32 count : 16; /* size of the buffer pointed by this BD */
u32 status : 8; /* E,R,I,C,W,D status bits stored here */
u32 command : 8; /* command mostly used for channel 0 */
@@ -1344,9 +1345,9 @@ static struct dma_async_tx_descriptor *sdma_prep_slave_sg(
count = sg_dma_len(sg);
- if (count > 0xffff) {
+ if (count > SDMA_BD_MAX_CNT) {
dev_err(sdma->dev, "SDMA channel %d: maximum bytes for sg entry exceeded: %d > %d\n",
- channel, count, 0xffff);
+ channel, count, SDMA_BD_MAX_CNT);
goto err_bd_out;
}
@@ -1421,9 +1422,9 @@ static struct dma_async_tx_descriptor *sdma_prep_dma_cyclic(
sdmac->flags |= IMX_DMA_SG_LOOP;
- if (period_len > 0xffff) {
+ if (period_len > SDMA_BD_MAX_CNT) {
dev_err(sdma->dev, "SDMA channel %d: maximum period size exceeded: %zu > %d\n",
- channel, period_len, 0xffff);
+ channel, period_len, SDMA_BD_MAX_CNT);
goto err_bd_out;
}
@@ -1970,7 +1971,7 @@ static int sdma_probe(struct platform_device *pdev)
sdma->dma_device.residue_granularity = DMA_RESIDUE_GRANULARITY_SEGMENT;
sdma->dma_device.device_issue_pending = sdma_issue_pending;
sdma->dma_device.dev->dma_parms = &sdma->dma_parms;
- dma_set_max_seg_size(sdma->dma_device.dev, 65535);
+ dma_set_max_seg_size(sdma->dma_device.dev, SDMA_BD_MAX_CNT);
platform_set_drvdata(pdev, sdma);
--
2.7.4
^ permalink raw reply related
* [v3,1/3] dmaengine: imx-sdma: add SDMA_BD_MAX_CNT to replace '0xffff'
From: Robin Gong @ 2018-07-23 17:46 UTC (permalink / raw)
To: vkoul, dan.j.williams, s.hauer, linux
Cc: linux-arm-kernel, kernel, dmaengine, linux-kernel, linux-imx
Add macro SDMA_BD_MAX_CNT to replace '0xffff'.
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
---
drivers/dma/imx-sdma.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 3b622d6..e3d5e73 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -185,6 +185,7 @@
* Mode/Count of data node descriptors - IPCv2
*/
struct sdma_mode_count {
+#define SDMA_BD_MAX_CNT 0xffff
u32 count : 16; /* size of the buffer pointed by this BD */
u32 status : 8; /* E,R,I,C,W,D status bits stored here */
u32 command : 8; /* command mostly used for channel 0 */
@@ -1344,9 +1345,9 @@ static struct dma_async_tx_descriptor *sdma_prep_slave_sg(
count = sg_dma_len(sg);
- if (count > 0xffff) {
+ if (count > SDMA_BD_MAX_CNT) {
dev_err(sdma->dev, "SDMA channel %d: maximum bytes for sg entry exceeded: %d > %d\n",
- channel, count, 0xffff);
+ channel, count, SDMA_BD_MAX_CNT);
goto err_bd_out;
}
@@ -1421,9 +1422,9 @@ static struct dma_async_tx_descriptor *sdma_prep_dma_cyclic(
sdmac->flags |= IMX_DMA_SG_LOOP;
- if (period_len > 0xffff) {
+ if (period_len > SDMA_BD_MAX_CNT) {
dev_err(sdma->dev, "SDMA channel %d: maximum period size exceeded: %zu > %d\n",
- channel, period_len, 0xffff);
+ channel, period_len, SDMA_BD_MAX_CNT);
goto err_bd_out;
}
@@ -1970,7 +1971,7 @@ static int sdma_probe(struct platform_device *pdev)
sdma->dma_device.residue_granularity = DMA_RESIDUE_GRANULARITY_SEGMENT;
sdma->dma_device.device_issue_pending = sdma_issue_pending;
sdma->dma_device.dev->dma_parms = &sdma->dma_parms;
- dma_set_max_seg_size(sdma->dma_device.dev, 65535);
+ dma_set_max_seg_size(sdma->dma_device.dev, SDMA_BD_MAX_CNT);
platform_set_drvdata(pdev, sdma);
^ permalink raw reply related
* [PATCH v3 0/3] add memcpy support for sdma
From: Robin Gong @ 2018-07-23 17:46 UTC (permalink / raw)
To: linux-arm-kernel
This patchset is to add memcpy interface for imx-sdma, besides,to
support dmatest and enable config by default, so that could test dma
easily without any other device support such as uart/audio/spi...
Change from v2:
1. remove 'copy_align' since sdma script for memory_2_memory will handle
such align issue. No such align limitation. Also remove bus width
description in bd.
2. for multi bds case such as in dmatest, should make sure all bds of
single transfer should be consistent, so enlarge allocated size for
dma pool to max bds, 20 bds/1.28MB should be enough for all case.Report
error if the bd number exceed 20.
Change from v1:
1. remove bus_width check for memcpy since only max bus width needed for
memcpy case to speedup copy.
2. remove DMATEST support patch, since DMATEST is a common memcpy case.
3. split to single patch for SDMA_BD_MAX_CNT instead of '0xffff'
4. move sdma_config_ownership() from alloc_chan into sdma_prep_memcpy.
5. address some minor review comments.
Robin Gong (3):
dmaengine: imx-sdma: add SDMA_BD_MAX_CNT to replace '0xffff'
dmaengine: imx-sdma: add memcpy interface
dmaengine: imx-sdma: allocate max 20 bds for one transfer
drivers/dma/imx-sdma.c | 121 +++++++++++++++++++++++++++++++++++++++++++++----
1 file changed, 112 insertions(+), 9 deletions(-)
--
2.7.4
^ permalink raw reply
* Synaptics Driver Problem
From: valdis.kletnieks at vt.edu @ 2018-07-23 17:44 UTC (permalink / raw)
To: kernelnewbies
In-Reply-To: <38724011532359757@iva4-031ea4da33a1.qloud-c.yandex.net>
On Mon, 23 Jul 2018 19:29:17 +0400, o at goosey.org said:
> So synaptics is not working, I want to write a driver for synaptics.
> Can I modify a generic synaptics driver?
Step 0 should be to figure out *why* the generic driver isn't working,
because you'll need that information to fix the existing driver or
writing a new one.
When you say "not working", how exactly does it fail? Does it not
even get seen by the operating system? Does it get seen, but not
as a HID input device? Does it get registered as a HID, but touches
and taps don't get detected?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 486 bytes
Desc: not available
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20180723/50b9952f/attachment.sig>
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v3 32/40] elf: Add nanoMIPS specific variations in ELF header fields
From: Aleksandar Markovic @ 2018-07-23 17:43 UTC (permalink / raw)
To: Richard Henderson, Stefan Markovic, qemu-devel@nongnu.org
Cc: laurent@vivier.eu, riku.voipio@iki.fi,
philippe.mathieu.daude@gmail.com, aurelien@aurel32.net,
Stefan Markovic, Petar Jovanovic, Paul Burton
In-Reply-To: <BN7PR08MB4868FFAE6CA4BF4074D7F87AC6560@BN7PR08MB4868.namprd08.prod.outlook.com>
> From: Aleksandar Markovic
> Sent: Monday, July 23, 2018 7:39 PM
>
> > From: Richard Henderson <richard.henderson@linaro.org>
> > Sent: Monday, July 23, 2018 6:59 PM
> > On 07/19/2018 05:55 AM, Stefan Markovic wrote:
> > > From: Aleksandar Markovic <amarkovic@wavecomp.com>
> > >
> > > Add nanoMIPS-related values in ELF header fields as specified in
> > > nanoMIPS' "ELF ABI Supplement".
> > >
> > > Signed-off-by: Aleksandar Markovic <amarkovic@wavecomp.com>
> > > Signed-off-by: Stefan Markovic <smarkovic@wavecomp.com>
> > > ---
> > > include/elf.h | 20 ++++++++++++++++++++
> > > 1 file changed, 20 insertions(+)
> >
> > None of these values have made it upstream to binutils yet,
> > so I can't double-check them. However,
> >
> > Acked-by: Richard Henderson <richard.henderson@linaro.org>
> >
> >
> > r~
>
> Hi, Richard.
>
> True, binutils headers were not updated with these ELF-related values. However, there is a publicly-available > document at https://codescape.mips.com/components/toolchain/nanomips/2018.04-02/releasenotes.html that should be > the source of information for binutils headers, or any other related header in similar tools. Specifically, see > Section 5.1 of that document.
>
> Regards,
> Aleksandar
I meant to link here to "nanoMIPS ABI Supplement":
https://codescape.mips.com/components/toolchain/nanomips/2018.04-02/docs/MIPS_nanoMIPS_ABI_supplement_01_02_DN00179.pdf
^ permalink raw reply
* [Buildroot] [PATCH 1/1] ncmpc: bump to version 0.30
From: Fabrice Fontaine @ 2018-07-23 17:43 UTC (permalink / raw)
To: buildroot
Since this version, ncmpc depends on C++14:
https://github.com/MusicPlayerDaemon/ncmpc/commit/aea91692b05e7c2cd2e1b09cf10b0196e3527807
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
---
package/ncmpc/Config.in | 7 +++++--
package/ncmpc/ncmpc.hash | 2 +-
package/ncmpc/ncmpc.mk | 2 +-
3 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/package/ncmpc/Config.in b/package/ncmpc/Config.in
index 324d8f7c2a..d22ea368b4 100644
--- a/package/ncmpc/Config.in
+++ b/package/ncmpc/Config.in
@@ -1,8 +1,10 @@
config BR2_PACKAGE_NCMPC
bool "ncmpc"
depends on BR2_USE_MMU # fork()
+ depends on BR2_INSTALL_LIBSTDCPP
depends on BR2_USE_WCHAR # libglib2 -> gettext
depends on BR2_TOOLCHAIN_HAS_THREADS # libglib2
+ depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_9 # C++14
select BR2_PACKAGE_LIBGLIB2
select BR2_PACKAGE_LIBMPDCLIENT
select BR2_PACKAGE_NCURSES
@@ -13,6 +15,7 @@ config BR2_PACKAGE_NCMPC
http://www.musicpd.org/clients/ncmpc/
-comment "ncmpc needs a toolchain w/ wchar, threads"
+comment "ncmpc needs a toolchain w/ C++, wchar, threads, gcc >= 4.9"
depends on BR2_USE_MMU
- depends on !BR2_USE_WCHAR || !BR2_TOOLCHAIN_HAS_THREADS
+ depends on !BR2_INSTALL_LIBSTDCPP || !BR2_USE_WCHAR || \
+ !BR2_TOOLCHAIN_HAS_THREADS || !BR2_TOOLCHAIN_GCC_AT_LEAST_4_9
diff --git a/package/ncmpc/ncmpc.hash b/package/ncmpc/ncmpc.hash
index 0e9a4a903c..021b532c83 100644
--- a/package/ncmpc/ncmpc.hash
+++ b/package/ncmpc/ncmpc.hash
@@ -1,5 +1,5 @@
# Locally calculated after checking pgp signature
-sha256 ef68a9b67172383ea80ee46579015109433fa058728812d2b0ebede660d85f12 ncmpc-0.29.tar.xz
+sha256 e3fe0cb58b8a77f63fb1645c2f974b334f1614efdc834ec698ee7d861f1b12a3 ncmpc-0.30.tar.xz
# Hash for license file:
sha256 ab15fd526bd8dd18a9e77ebc139656bf4d33e97fc7238cd11bf60e2b9b8666c6 COPYING
diff --git a/package/ncmpc/ncmpc.mk b/package/ncmpc/ncmpc.mk
index d70ed46ea9..296fce12d2 100644
--- a/package/ncmpc/ncmpc.mk
+++ b/package/ncmpc/ncmpc.mk
@@ -5,7 +5,7 @@
################################################################################
NCMPC_VERSION_MAJOR = 0
-NCMPC_VERSION = $(NCMPC_VERSION_MAJOR).29
+NCMPC_VERSION = $(NCMPC_VERSION_MAJOR).30
NCMPC_SOURCE = ncmpc-$(NCMPC_VERSION).tar.xz
NCMPC_SITE = http://www.musicpd.org/download/ncmpc/$(NCMPC_VERSION_MAJOR)
NCMPC_DEPENDENCIES = host-pkgconf libglib2 libmpdclient ncurses
--
2.14.1
^ permalink raw reply related
* Re: [PATCH V2 0/2] firmware: ti_sci: Add host-id as an optional parameter
From: Santosh Shilimkar @ 2018-07-23 17:42 UTC (permalink / raw)
To: Nishanth Menon, Mark Rutland, Rob Herring, Santosh Shilimkar,
Tero Kristo
Cc: linux-kernel, devicetree, linux-arm-kernel, geert
In-Reply-To: <20180723133303.ijekyffgnmesrhhv@kahuna>
On 7/23/2018 6:33 AM, Nishanth Menon wrote:
> On 17:13-20180716, Nishanth Menon wrote:
>> Please find attached series to enable host-id as an optional dt property.
>>
>> This is a minor update to V1 -> Mostly to pick up Greet's feedback and Rob's Ack.
>>
>> V1: https://patchwork.ozlabs.org/cover/931822/
>>
>> The series is based on v4.18-rc1 and is available here:
>> https://github.com/nmenon/linux-2.6-playground/commits/upstream/v4.18-rc1/k3-1-am6-tisci
>>
>> Consolidated all patches (including all series) are available here:
>> https://github.com/nmenon/linux-2.6-playground/commits/upstream/v4.18-rc1/k3-am6-integ
>>
>> Full Boot log (integrated of all series for AM654) is available here:
>> https://pastebin.ubuntu.com/p/bBFmnzYtCd/
>>
>> Nishanth Menon (2):
>> Documentation: dt: keystone: ti-sci: Add optional host-id parameter
>> firmware: ti_sci: Provide host-id as an optional dt parameter
>>
>> .../devicetree/bindings/arm/keystone/ti,sci.txt | 4 ++++
>> drivers/firmware/ti_sci.c | 24 ++++++++++++++++++----
>> 2 files changed, 24 insertions(+), 4 deletions(-)
>
> Santosh,
>
> Apologies, I see you have already send your PR for v4.19. Was
> just wondering if this is something we can consider for rc
> cycle OR if you'd consider a followup PR for the same.
>
NP. Patch(s) doesn't look RC material so don't plan to send
it as part of RC. Please let me know if its o.w
This will have to wait for next cycle. Will merge this
early once v4.19-rc1 comes out.
Regards,
Santosh
^ permalink raw reply
* [PATCH V2 0/2] firmware: ti_sci: Add host-id as an optional parameter
From: Santosh Shilimkar @ 2018-07-23 17:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180723133303.ijekyffgnmesrhhv@kahuna>
On 7/23/2018 6:33 AM, Nishanth Menon wrote:
> On 17:13-20180716, Nishanth Menon wrote:
>> Please find attached series to enable host-id as an optional dt property.
>>
>> This is a minor update to V1 -> Mostly to pick up Greet's feedback and Rob's Ack.
>>
>> V1: https://patchwork.ozlabs.org/cover/931822/
>>
>> The series is based on v4.18-rc1 and is available here:
>> https://github.com/nmenon/linux-2.6-playground/commits/upstream/v4.18-rc1/k3-1-am6-tisci
>>
>> Consolidated all patches (including all series) are available here:
>> https://github.com/nmenon/linux-2.6-playground/commits/upstream/v4.18-rc1/k3-am6-integ
>>
>> Full Boot log (integrated of all series for AM654) is available here:
>> https://pastebin.ubuntu.com/p/bBFmnzYtCd/
>>
>> Nishanth Menon (2):
>> Documentation: dt: keystone: ti-sci: Add optional host-id parameter
>> firmware: ti_sci: Provide host-id as an optional dt parameter
>>
>> .../devicetree/bindings/arm/keystone/ti,sci.txt | 4 ++++
>> drivers/firmware/ti_sci.c | 24 ++++++++++++++++++----
>> 2 files changed, 24 insertions(+), 4 deletions(-)
>
> Santosh,
>
> Apologies, I see you have already send your PR for v4.19. Was
> just wondering if this is something we can consider for rc
> cycle OR if you'd consider a followup PR for the same.
>
NP. Patch(s) doesn't look RC material so don't plan to send
it as part of RC. Please let me know if its o.w
This will have to wait for next cycle. Will merge this
early once v4.19-rc1 comes out.
Regards,
Santosh
^ permalink raw reply
* Re: [PATCH v07 1/9] hotplug/cpu: Conditionally acquire/release DRC index
From: Nathan Fontenot @ 2018-07-23 17:42 UTC (permalink / raw)
To: Michael Bringmann, linuxppc-dev; +Cc: John Allen, Tyrel Datwyler, Thomas Falcon
In-Reply-To: <a7e202c1-177f-db1b-912f-8773a551feec@linux.vnet.ibm.com>
On 07/13/2018 03:17 PM, Michael Bringmann wrote:
> powerpc/cpu: Modify dlpar_cpu_add and dlpar_cpu_remove to allow the
> skipping of DRC index acquire or release operations during the CPU
> add or remove operations. This is intended to support subsequent
> changes to provide a 'CPU readd' operation.
>
> Signed-off-by: Michael Bringmann <mwb@linux.vnet.ibm.com>
> ---
> Changes in patch:
> -- Move new validity check added to pseries_smp_notifier
> to another patch
> -- Revise one of checks for 'acquire_drc' in dlpar_cpu_add.
> -- Revise one of checks for 'release_drc' in dlpar_cpu_remove.
> ---
> arch/powerpc/platforms/pseries/hotplug-cpu.c | 71 +++++++++++++++-----------
> 1 file changed, 40 insertions(+), 31 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c b/arch/powerpc/platforms/pseries/hotplug-cpu.c
> index 6ef77ca..7ede3b0 100644
> --- a/arch/powerpc/platforms/pseries/hotplug-cpu.c
> +++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c
> @@ -432,7 +432,7 @@ static bool valid_cpu_drc_index(struct device_node *parent, u32 drc_index)
> return found;
> }
>
> -static ssize_t dlpar_cpu_add(u32 drc_index)
> +static ssize_t dlpar_cpu_add(u32 drc_index, bool acquire_drc)
> {
> struct device_node *dn, *parent;
> int rc, saved_rc;
> @@ -457,19 +457,22 @@ static ssize_t dlpar_cpu_add(u32 drc_index)
> return -EINVAL;
> }
>
> - rc = dlpar_acquire_drc(drc_index);
> - if (rc) {
> - pr_warn("Failed to acquire DRC, rc: %d, drc index: %x\n",
> - rc, drc_index);
> - of_node_put(parent);
> - return -EINVAL;
> + if (acquire_drc) {
> + rc = dlpar_acquire_drc(drc_index);
> + if (rc) {
> + pr_warn("Failed to acquire DRC, rc: %d, drc index: %x\n",
> + rc, drc_index);
> + of_node_put(parent);
> + return -EINVAL;
> + }
> }
>
> dn = dlpar_configure_connector(cpu_to_be32(drc_index), parent);
> if (!dn) {
> pr_warn("Failed call to configure-connector, drc index: %x\n",
> drc_index);
> - dlpar_release_drc(drc_index);
> + if (acquire_drc)
> + dlpar_release_drc(drc_index);
> of_node_put(parent);
> return -EINVAL;
> }
> @@ -484,9 +487,11 @@ static ssize_t dlpar_cpu_add(u32 drc_index)
> pr_warn("Failed to attach node %s, rc: %d, drc index: %x\n",
> dn->name, rc, drc_index);
>
> - rc = dlpar_release_drc(drc_index);
> - if (!rc)
> - dlpar_free_cc_nodes(dn);
> + if (acquire_drc) {
> + rc = dlpar_release_drc(drc_index);
> + if (!rc)
> + dlpar_free_cc_nodes(dn);
> + }
>
> return saved_rc;
> }
> @@ -498,7 +503,7 @@ static ssize_t dlpar_cpu_add(u32 drc_index)
> dn->name, rc, drc_index);
>
> rc = dlpar_detach_node(dn);
> - if (!rc)
> + if (!rc && acquire_drc)
> dlpar_release_drc(drc_index);
>
> return saved_rc;
> @@ -566,7 +571,8 @@ static int dlpar_offline_cpu(struct device_node *dn)
>
> }
>
> -static ssize_t dlpar_cpu_remove(struct device_node *dn, u32 drc_index)
> +static ssize_t dlpar_cpu_remove(struct device_node *dn, u32 drc_index,
> + bool release_drc)
> {
> int rc;
>
> @@ -579,12 +585,14 @@ static ssize_t dlpar_cpu_remove(struct device_node *dn, u32 drc_index)
> return -EINVAL;
> }
>
> - rc = dlpar_release_drc(drc_index);
> - if (rc) {
> - pr_warn("Failed to release drc (%x) for CPU %s, rc: %d\n",
> - drc_index, dn->name, rc);
> - dlpar_online_cpu(dn);
> - return rc;
> + if (release_drc) {
> + rc = dlpar_release_drc(drc_index);
> + if (rc) {
> + pr_warn("Failed to release drc (%x) for CPU %s, rc: %d\n",
> + drc_index, dn->name, rc);
> + dlpar_online_cpu(dn);
> + return rc;
> + }
> }
>
> rc = dlpar_detach_node(dn);
> @@ -593,8 +601,9 @@ static ssize_t dlpar_cpu_remove(struct device_node *dn, u32 drc_index)
>
> pr_warn("Failed to detach CPU %s, rc: %d", dn->name, rc);
>
> - rc = dlpar_acquire_drc(drc_index);
> - if (!rc)
> + if (release_drc)
> + rc = dlpar_acquire_drc(drc_index);
> + if (!release_drc || !rc)
> dlpar_online_cpu(dn);
This is likely wrong. At this point you're in a if (rc) so rc is already
non-zero. If release_drc is false this checks an invalid rc state.
-Nathan
>
> return saved_rc;
> @@ -622,7 +631,7 @@ static struct device_node *cpu_drc_index_to_dn(u32 drc_index)
> return dn;
> }
>
> -static int dlpar_cpu_remove_by_index(u32 drc_index)
> +static int dlpar_cpu_remove_by_index(u32 drc_index, bool release_drc)
> {
> struct device_node *dn;
> int rc;
> @@ -634,7 +643,7 @@ static int dlpar_cpu_remove_by_index(u32 drc_index)
> return -ENODEV;
> }
>
> - rc = dlpar_cpu_remove(dn, drc_index);
> + rc = dlpar_cpu_remove(dn, drc_index, release_drc);
> of_node_put(dn);
> return rc;
> }
> @@ -699,7 +708,7 @@ static int dlpar_cpu_remove_by_count(u32 cpus_to_remove)
> }
>
> for (i = 0; i < cpus_to_remove; i++) {
> - rc = dlpar_cpu_remove_by_index(cpu_drcs[i]);
> + rc = dlpar_cpu_remove_by_index(cpu_drcs[i], true);
> if (rc)
> break;
>
> @@ -710,7 +719,7 @@ static int dlpar_cpu_remove_by_count(u32 cpus_to_remove)
> pr_warn("CPU hot-remove failed, adding back removed CPUs\n");
>
> for (i = 0; i < cpus_removed; i++)
> - dlpar_cpu_add(cpu_drcs[i]);
> + dlpar_cpu_add(cpu_drcs[i], true);
>
> rc = -EINVAL;
> } else {
> @@ -780,7 +789,7 @@ static int dlpar_cpu_add_by_count(u32 cpus_to_add)
> }
>
> for (i = 0; i < cpus_to_add; i++) {
> - rc = dlpar_cpu_add(cpu_drcs[i]);
> + rc = dlpar_cpu_add(cpu_drcs[i], true);
> if (rc)
> break;
>
> @@ -791,7 +800,7 @@ static int dlpar_cpu_add_by_count(u32 cpus_to_add)
> pr_warn("CPU hot-add failed, removing any added CPUs\n");
>
> for (i = 0; i < cpus_added; i++)
> - dlpar_cpu_remove_by_index(cpu_drcs[i]);
> + dlpar_cpu_remove_by_index(cpu_drcs[i], true);
>
> rc = -EINVAL;
> } else {
> @@ -817,7 +826,7 @@ int dlpar_cpu(struct pseries_hp_errorlog *hp_elog)
> if (hp_elog->id_type == PSERIES_HP_ELOG_ID_DRC_COUNT)
> rc = dlpar_cpu_remove_by_count(count);
> else if (hp_elog->id_type == PSERIES_HP_ELOG_ID_DRC_INDEX)
> - rc = dlpar_cpu_remove_by_index(drc_index);
> + rc = dlpar_cpu_remove_by_index(drc_index, true);
> else
> rc = -EINVAL;
> break;
> @@ -825,7 +834,7 @@ int dlpar_cpu(struct pseries_hp_errorlog *hp_elog)
> if (hp_elog->id_type == PSERIES_HP_ELOG_ID_DRC_COUNT)
> rc = dlpar_cpu_add_by_count(count);
> else if (hp_elog->id_type == PSERIES_HP_ELOG_ID_DRC_INDEX)
> - rc = dlpar_cpu_add(drc_index);
> + rc = dlpar_cpu_add(drc_index, true);
> else
> rc = -EINVAL;
> break;
> @@ -850,7 +859,7 @@ static ssize_t dlpar_cpu_probe(const char *buf, size_t count)
> if (rc)
> return -EINVAL;
>
> - rc = dlpar_cpu_add(drc_index);
> + rc = dlpar_cpu_add(drc_index, true);
>
> return rc ? rc : count;
> }
> @@ -871,7 +880,7 @@ static ssize_t dlpar_cpu_release(const char *buf, size_t count)
> return -EINVAL;
> }
>
> - rc = dlpar_cpu_remove(dn, drc_index);
> + rc = dlpar_cpu_remove(dn, drc_index, true);
> of_node_put(dn);
>
> return rc ? rc : count;
>
^ permalink raw reply
* [Intel-wired-lan] [jkirsher-net-queue:dev-queue] BUILD SUCCESS 8ede258c4dbc567d01e559467c2c5c27667e24cf
From: kbuild test robot @ 2018-07-23 17:42 UTC (permalink / raw)
To: intel-wired-lan
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-queue.git dev-queue
branch HEAD: 8ede258c4dbc567d01e559467c2c5c27667e24cf fq_codel: fix NULL pointer deref in fq_codel_reset
elapsed time: 208m
configs tested: 166
The following configs have been built successfully.
More configs may be tested in the coming days.
x86_64 allmodconfig
powerpc mpc8560_ads_defconfig
x86_64 randconfig-a0-07232124
x86_64 acpi-redef
x86_64 allyesdebian
x86_64 nfsroot
alpha allmodconfig
arm em_x270_defconfig
i386 randconfig-c0-07231120
arm multi_v4t_defconfig
m68k multi_defconfig
i386 tinyconfig
i386 randconfig-x010-201829
i386 randconfig-x011-201829
i386 randconfig-x012-201829
i386 randconfig-x013-201829
i386 randconfig-x014-201829
i386 randconfig-x015-201829
i386 randconfig-x016-201829
i386 randconfig-x017-201829
i386 randconfig-x018-201829
i386 randconfig-x019-201829
x86_64 lkp
x86_64 rhel
x86_64 rhel-7.2
x86_64 fedora-25
microblaze mmu_defconfig
microblaze nommu_defconfig
i386 randconfig-n0-201829
x86_64 randconfig-x007-201829
x86_64 randconfig-x003-201829
x86_64 randconfig-x000-201829
x86_64 randconfig-x005-201829
x86_64 randconfig-x004-201829
x86_64 randconfig-x008-201829
x86_64 randconfig-x001-201829
x86_64 randconfig-x009-201829
x86_64 randconfig-x002-201829
x86_64 randconfig-x006-201829
ia64 alldefconfig
ia64 allnoconfig
ia64 defconfig
powerpc allnoconfig
powerpc defconfig
powerpc ppc64_defconfig
s390 default_defconfig
i386 randconfig-i0-201829
i386 randconfig-i1-201829
i386 defconfig
arm vf610m4_defconfig
arm allnoconfig
arm at91_dt_defconfig
arm efm32_defconfig
arm exynos_defconfig
arm multi_v5_defconfig
arm multi_v7_defconfig
arm shmobile_defconfig
arm sunxi_defconfig
arm64 allnoconfig
arm64 defconfig
alpha alldefconfig
arm iop32x_defconfig
x86_64 randconfig-g0-07231324
openrisc or1ksim_defconfig
um i386_defconfig
um x86_64_defconfig
i386 allmodconfig
x86_64 randconfig-x018-201829
x86_64 randconfig-x011-201829
x86_64 randconfig-x015-201829
x86_64 randconfig-x019-201829
x86_64 randconfig-x014-201829
x86_64 randconfig-x010-201829
x86_64 randconfig-x013-201829
x86_64 randconfig-x016-201829
x86_64 randconfig-x017-201829
x86_64 randconfig-x012-201829
arm omap2plus_defconfig
arm allmodconfig
arm mvebu_v7_defconfig
arm ixp4xx_defconfig
arm imx_v6_v7_defconfig
arm64 allmodconfig
arm tegra_defconfig
arm64 alldefconfig
i386 randconfig-a0-201829
i386 randconfig-a1-201829
x86_64 randconfig-s0-07231842
x86_64 randconfig-s1-07231842
x86_64 randconfig-s2-07231842
c6x evmc6678_defconfig
h8300 h8300h-sim_defconfig
nios2 10m50_defconfig
xtensa common_defconfig
xtensa iss_defconfig
alpha defconfig
parisc allnoconfig
parisc b180_defconfig
parisc c3000_defconfig
parisc defconfig
arm lpd270_defconfig
arm vexpress_defconfig
arm zeus_defconfig
mips fuloong2e_defconfig
arm mps2_defconfig
powerpc mpc5200_defconfig
sh allmodconfig
sparc sparc64_defconfig
i386 alldefconfig
i386 allnoconfig
m68k m5475evb_defconfig
m68k sun3_defconfig
i386 randconfig-s1-201829
i386 randconfig-s0-201829
x86_64 randconfig-s3-07232252
x86_64 randconfig-s4-07232252
x86_64 randconfig-s5-07232252
mips 32r2_defconfig
mips 64r6el_defconfig
mips allnoconfig
mips jz4740
mips malta_kvm_defconfig
mips txx9
x86_64 randconfig-i0-201829
powerpc pcm030_defconfig
powerpc tqm8548_defconfig
sh hp6xx_defconfig
x86_64 randconfig-u0-07232125
s390 performance_defconfig
sh allyesconfig
x86_64 randconfig-ne0-07232115
i386 randconfig-x070-201829
i386 randconfig-x071-201829
i386 randconfig-x072-201829
i386 randconfig-x073-201829
i386 randconfig-x074-201829
i386 randconfig-x075-201829
i386 randconfig-x076-201829
i386 randconfig-x077-201829
i386 randconfig-x078-201829
i386 randconfig-x079-201829
mips tb0287_defconfig
sh allnoconfig
sh rsk7269_defconfig
sh sh7785lcr_32bit_defconfig
sh titan_defconfig
i386 randconfig-sb0-07231305
i386 randconfig-x008-201829
i386 randconfig-x009-201829
i386 randconfig-x005-201829
i386 randconfig-x000-201829
i386 randconfig-x003-201829
i386 randconfig-x001-201829
i386 randconfig-x004-201829
i386 randconfig-x006-201829
i386 randconfig-x007-201829
i386 randconfig-x002-201829
sparc defconfig
sparc64 allnoconfig
sparc64 defconfig
m68k mac_defconfig
mips rt305x_defconfig
x86_64 randconfig-ws0-07231124
powerpc mpc836x_mds_defconfig
x86_64 kexec
x86_64 randconfig-r0-07231315
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* [PATCH v4 00/11] hugetlb: Factorize hugetlb architecture primitives
From: Alex Ghiti @ 2018-07-23 17:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87d0vehx16.fsf@concordia.ellerman.id.au>
Ok will do and report when done.
Thanks for your feedback,
Alex
On 07/23/2018 02:00 PM, Michael Ellerman wrote:
> Alex Ghiti <alex@ghiti.fr> writes:
>
>> Does anyone have any suggestion about those patches ?
> Cross compiling it for some non-x86 arches would be a good start :)
>
> There are cross compilers available here:
>
> https://mirrors.edge.kernel.org/pub/tools/crosstool/
>
>
> cheers
>
>> On 07/09/2018 02:16 PM, Michal Hocko wrote:
>>> [CC hugetlb guys - http://lkml.kernel.org/r/20180705110716.3919-1-alex at ghiti.fr]
>>>
>>> On Thu 05-07-18 11:07:05, Alexandre Ghiti wrote:
>>>> In order to reduce copy/paste of functions across architectures and then
>>>> make riscv hugetlb port (and future ports) simpler and smaller, this
>>>> patchset intends to factorize the numerous hugetlb primitives that are
>>>> defined across all the architectures.
>>>>
>>>> Except for prepare_hugepage_range, this patchset moves the versions that
>>>> are just pass-through to standard pte primitives into
>>>> asm-generic/hugetlb.h by using the same #ifdef semantic that can be
>>>> found in asm-generic/pgtable.h, i.e. __HAVE_ARCH_***.
>>>>
>>>> s390 architecture has not been tackled in this serie since it does not
>>>> use asm-generic/hugetlb.h at all.
>>>> powerpc could be factorized a bit more (cf huge_ptep_set_wrprotect).
>>>>
>>>> This patchset has been compiled on x86 only.
>>>>
>>>> Changelog:
>>>>
>>>> v4:
>>>> Fix powerpc build error due to misplacing of #include
>>>> <asm-generic/hugetlb.h> outside of #ifdef CONFIG_HUGETLB_PAGE, as
>>>> pointed by Christophe Leroy.
>>>>
>>>> v1, v2, v3:
>>>> Same version, just problems with email provider and misuse of
>>>> --batch-size option of git send-email
>>>>
>>>> Alexandre Ghiti (11):
>>>> hugetlb: Harmonize hugetlb.h arch specific defines with pgtable.h
>>>> hugetlb: Introduce generic version of hugetlb_free_pgd_range
>>>> hugetlb: Introduce generic version of set_huge_pte_at
>>>> hugetlb: Introduce generic version of huge_ptep_get_and_clear
>>>> hugetlb: Introduce generic version of huge_ptep_clear_flush
>>>> hugetlb: Introduce generic version of huge_pte_none
>>>> hugetlb: Introduce generic version of huge_pte_wrprotect
>>>> hugetlb: Introduce generic version of prepare_hugepage_range
>>>> hugetlb: Introduce generic version of huge_ptep_set_wrprotect
>>>> hugetlb: Introduce generic version of huge_ptep_set_access_flags
>>>> hugetlb: Introduce generic version of huge_ptep_get
>>>>
>>>> arch/arm/include/asm/hugetlb-3level.h | 32 +---------
>>>> arch/arm/include/asm/hugetlb.h | 33 +----------
>>>> arch/arm64/include/asm/hugetlb.h | 39 +++---------
>>>> arch/ia64/include/asm/hugetlb.h | 47 ++-------------
>>>> arch/mips/include/asm/hugetlb.h | 40 +++----------
>>>> arch/parisc/include/asm/hugetlb.h | 33 +++--------
>>>> arch/powerpc/include/asm/book3s/32/pgtable.h | 2 +
>>>> arch/powerpc/include/asm/book3s/64/pgtable.h | 1 +
>>>> arch/powerpc/include/asm/hugetlb.h | 43 ++------------
>>>> arch/powerpc/include/asm/nohash/32/pgtable.h | 2 +
>>>> arch/powerpc/include/asm/nohash/64/pgtable.h | 1 +
>>>> arch/sh/include/asm/hugetlb.h | 54 ++---------------
>>>> arch/sparc/include/asm/hugetlb.h | 40 +++----------
>>>> arch/x86/include/asm/hugetlb.h | 72 +----------------------
>>>> include/asm-generic/hugetlb.h | 88 +++++++++++++++++++++++++++-
>>>> 15 files changed, 143 insertions(+), 384 deletions(-)
>>>>
>>>> --
>>>> 2.16.2
^ permalink raw reply
* Re: [PATCH v4 00/11] hugetlb: Factorize hugetlb architecture primitives
From: Alex Ghiti @ 2018-07-23 17:41 UTC (permalink / raw)
To: Michael Ellerman
Cc: linux, catalin.marinas, will.deacon, tony.luck, fenghua.yu, ralf,
paul.burton, jhogan, jejb, deller, benh, paulus, ysato, dalias,
davem, tglx, mingo, hpa, x86, arnd, linux-arm-kernel,
linux-kernel, linux-ia64, linux-mips, linux-parisc, linuxppc-dev,
linux-sh, sparclinux, linux-arch, Naoya Horiguchi, Mike Kravetz,
Michal Hocko
In-Reply-To: <87d0vehx16.fsf@concordia.ellerman.id.au>
Ok will do and report when done.
Thanks for your feedback,
Alex
On 07/23/2018 02:00 PM, Michael Ellerman wrote:
> Alex Ghiti <alex@ghiti.fr> writes:
>
>> Does anyone have any suggestion about those patches ?
> Cross compiling it for some non-x86 arches would be a good start :)
>
> There are cross compilers available here:
>
> https://mirrors.edge.kernel.org/pub/tools/crosstool/
>
>
> cheers
>
>> On 07/09/2018 02:16 PM, Michal Hocko wrote:
>>> [CC hugetlb guys - http://lkml.kernel.org/r/20180705110716.3919-1-alex@ghiti.fr]
>>>
>>> On Thu 05-07-18 11:07:05, Alexandre Ghiti wrote:
>>>> In order to reduce copy/paste of functions across architectures and then
>>>> make riscv hugetlb port (and future ports) simpler and smaller, this
>>>> patchset intends to factorize the numerous hugetlb primitives that are
>>>> defined across all the architectures.
>>>>
>>>> Except for prepare_hugepage_range, this patchset moves the versions that
>>>> are just pass-through to standard pte primitives into
>>>> asm-generic/hugetlb.h by using the same #ifdef semantic that can be
>>>> found in asm-generic/pgtable.h, i.e. __HAVE_ARCH_***.
>>>>
>>>> s390 architecture has not been tackled in this serie since it does not
>>>> use asm-generic/hugetlb.h at all.
>>>> powerpc could be factorized a bit more (cf huge_ptep_set_wrprotect).
>>>>
>>>> This patchset has been compiled on x86 only.
>>>>
>>>> Changelog:
>>>>
>>>> v4:
>>>> Fix powerpc build error due to misplacing of #include
>>>> <asm-generic/hugetlb.h> outside of #ifdef CONFIG_HUGETLB_PAGE, as
>>>> pointed by Christophe Leroy.
>>>>
>>>> v1, v2, v3:
>>>> Same version, just problems with email provider and misuse of
>>>> --batch-size option of git send-email
>>>>
>>>> Alexandre Ghiti (11):
>>>> hugetlb: Harmonize hugetlb.h arch specific defines with pgtable.h
>>>> hugetlb: Introduce generic version of hugetlb_free_pgd_range
>>>> hugetlb: Introduce generic version of set_huge_pte_at
>>>> hugetlb: Introduce generic version of huge_ptep_get_and_clear
>>>> hugetlb: Introduce generic version of huge_ptep_clear_flush
>>>> hugetlb: Introduce generic version of huge_pte_none
>>>> hugetlb: Introduce generic version of huge_pte_wrprotect
>>>> hugetlb: Introduce generic version of prepare_hugepage_range
>>>> hugetlb: Introduce generic version of huge_ptep_set_wrprotect
>>>> hugetlb: Introduce generic version of huge_ptep_set_access_flags
>>>> hugetlb: Introduce generic version of huge_ptep_get
>>>>
>>>> arch/arm/include/asm/hugetlb-3level.h | 32 +---------
>>>> arch/arm/include/asm/hugetlb.h | 33 +----------
>>>> arch/arm64/include/asm/hugetlb.h | 39 +++---------
>>>> arch/ia64/include/asm/hugetlb.h | 47 ++-------------
>>>> arch/mips/include/asm/hugetlb.h | 40 +++----------
>>>> arch/parisc/include/asm/hugetlb.h | 33 +++--------
>>>> arch/powerpc/include/asm/book3s/32/pgtable.h | 2 +
>>>> arch/powerpc/include/asm/book3s/64/pgtable.h | 1 +
>>>> arch/powerpc/include/asm/hugetlb.h | 43 ++------------
>>>> arch/powerpc/include/asm/nohash/32/pgtable.h | 2 +
>>>> arch/powerpc/include/asm/nohash/64/pgtable.h | 1 +
>>>> arch/sh/include/asm/hugetlb.h | 54 ++---------------
>>>> arch/sparc/include/asm/hugetlb.h | 40 +++----------
>>>> arch/x86/include/asm/hugetlb.h | 72 +----------------------
>>>> include/asm-generic/hugetlb.h | 88 +++++++++++++++++++++++++++-
>>>> 15 files changed, 143 insertions(+), 384 deletions(-)
>>>>
>>>> --
>>>> 2.16.2
^ permalink raw reply
* Re: [PATCH v4 00/11] hugetlb: Factorize hugetlb architecture primitives
From: Alex Ghiti @ 2018-07-23 17:41 UTC (permalink / raw)
To: Michael Ellerman
Cc: linux, catalin.marinas, will.deacon, tony.luck, fenghua.yu, ralf,
paul.burton, jhogan, jejb, deller, benh, paulus, ysato, dalias,
davem, tglx, mingo, hpa, x86, arnd, linux-arm-kernel,
linux-kernel, linux-ia64, linux-mips, linux-parisc, linuxppc-dev,
linux-sh, sparclinux, linux-arch, Naoya Horiguchi, Mike Kravetz,
Michal Hocko
In-Reply-To: <87d0vehx16.fsf@concordia.ellerman.id.au>
Ok will do and report when done.
Thanks for your feedback,
Alex
On 07/23/2018 02:00 PM, Michael Ellerman wrote:
> Alex Ghiti <alex@ghiti.fr> writes:
>
>> Does anyone have any suggestion about those patches ?
> Cross compiling it for some non-x86 arches would be a good start :)
>
> There are cross compilers available here:
>
> https://mirrors.edge.kernel.org/pub/tools/crosstool/
>
>
> cheers
>
>> On 07/09/2018 02:16 PM, Michal Hocko wrote:
>>> [CC hugetlb guys - http://lkml.kernel.org/r/20180705110716.3919-1-alex@ghiti.fr]
>>>
>>> On Thu 05-07-18 11:07:05, Alexandre Ghiti wrote:
>>>> In order to reduce copy/paste of functions across architectures and then
>>>> make riscv hugetlb port (and future ports) simpler and smaller, this
>>>> patchset intends to factorize the numerous hugetlb primitives that are
>>>> defined across all the architectures.
>>>>
>>>> Except for prepare_hugepage_range, this patchset moves the versions that
>>>> are just pass-through to standard pte primitives into
>>>> asm-generic/hugetlb.h by using the same #ifdef semantic that can be
>>>> found in asm-generic/pgtable.h, i.e. __HAVE_ARCH_***.
>>>>
>>>> s390 architecture has not been tackled in this serie since it does not
>>>> use asm-generic/hugetlb.h at all.
>>>> powerpc could be factorized a bit more (cf huge_ptep_set_wrprotect).
>>>>
>>>> This patchset has been compiled on x86 only.
>>>>
>>>> Changelog:
>>>>
>>>> v4:
>>>> Fix powerpc build error due to misplacing of #include
>>>> <asm-generic/hugetlb.h> outside of #ifdef CONFIG_HUGETLB_PAGE, as
>>>> pointed by Christophe Leroy.
>>>>
>>>> v1, v2, v3:
>>>> Same version, just problems with email provider and misuse of
>>>> --batch-size option of git send-email
>>>>
>>>> Alexandre Ghiti (11):
>>>> hugetlb: Harmonize hugetlb.h arch specific defines with pgtable.h
>>>> hugetlb: Introduce generic version of hugetlb_free_pgd_range
>>>> hugetlb: Introduce generic version of set_huge_pte_at
>>>> hugetlb: Introduce generic version of huge_ptep_get_and_clear
>>>> hugetlb: Introduce generic version of huge_ptep_clear_flush
>>>> hugetlb: Introduce generic version of huge_pte_none
>>>> hugetlb: Introduce generic version of huge_pte_wrprotect
>>>> hugetlb: Introduce generic version of prepare_hugepage_range
>>>> hugetlb: Introduce generic version of huge_ptep_set_wrprotect
>>>> hugetlb: Introduce generic version of huge_ptep_set_access_flags
>>>> hugetlb: Introduce generic version of huge_ptep_get
>>>>
>>>> arch/arm/include/asm/hugetlb-3level.h | 32 +---------
>>>> arch/arm/include/asm/hugetlb.h | 33 +----------
>>>> arch/arm64/include/asm/hugetlb.h | 39 +++---------
>>>> arch/ia64/include/asm/hugetlb.h | 47 ++-------------
>>>> arch/mips/include/asm/hugetlb.h | 40 +++----------
>>>> arch/parisc/include/asm/hugetlb.h | 33 +++--------
>>>> arch/powerpc/include/asm/book3s/32/pgtable.h | 2 +
>>>> arch/powerpc/include/asm/book3s/64/pgtable.h | 1 +
>>>> arch/powerpc/include/asm/hugetlb.h | 43 ++------------
>>>> arch/powerpc/include/asm/nohash/32/pgtable.h | 2 +
>>>> arch/powerpc/include/asm/nohash/64/pgtable.h | 1 +
>>>> arch/sh/include/asm/hugetlb.h | 54 ++---------------
>>>> arch/sparc/include/asm/hugetlb.h | 40 +++----------
>>>> arch/x86/include/asm/hugetlb.h | 72 +----------------------
>>>> include/asm-generic/hugetlb.h | 88 +++++++++++++++++++++++++++-
>>>> 15 files changed, 143 insertions(+), 384 deletions(-)
>>>>
>>>> --
>>>> 2.16.2
^ permalink raw reply
* undefined reference to `__divdi3'
From: valdis.kletnieks at vt.edu @ 2018-07-23 17:41 UTC (permalink / raw)
To: kernelnewbies
In-Reply-To: <20180722121820.GA15392@himanshu-Vostro-3559>
On Sun, 22 Jul 2018 17:48:21 +0530, Himanshu Jha said:
> I am currently working on my GSoC project and while testing through
> 0-day test service, I hit the following error:
> 424 static u32 bme680_compensate_gas(struct bme680_data *data, u16 gas_res_adc,
> 425 u8 gas_range)
> 426 {
> 427 struct bme680_calib *calib = &data->bme680;
> 428 s64 var1;
> 429 u64 var2;
> 430 s64 var3;
> 431 u32 calc_gas_res;
> 432
> 433 /* Look up table 1 for the possible gas range values */
> 434 u32 lookupTable1[16] = {2147483647u, 2147483647u, 2147483647u,
> 435 2147483647u, 2147483647u, 2126008810u,
> 436 2147483647u, 2130303777u, 2147483647u,
> 437 2147483647u, 2143188679u, 2136746228u,
> 438 2147483647u, 2126008810u, 2147483647u,
> 439 2147483647u};
As an aside, making this a 'static u32' will get rid of the mess of mov and movabs
instructions each time. 'static const u32' would be even better, as then the
compiler knows it can optimize assuming it never changes any of the values...
(In addition, with all that initialization out of the picture, figuring out
which assembler code does what should be easier...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 486 bytes
Desc: not available
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20180723/27536e06/attachment.sig>
^ permalink raw reply
* Re: [PATCH 2/9] vscode: hard-code a couple defines
From: Jonathan Nieder @ 2018-07-23 17:41 UTC (permalink / raw)
To: Johannes Schindelin via GitGitGadget
Cc: git, Junio C Hamano, Johannes Schindelin
In-Reply-To: <3770bd855c6f3e69acfe418ea7fe5b40454e4dfb.1532353966.git.gitgitgadget@gmail.com>
Hi,
Johannes Schindelin via GitGitGadget wrote:
> From: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> Sadly, we do not get all of the definitions via ALL_CFLAGS. Some defines
> are passed to GCC *only* when compiling specific files, such as git.o.
>
> Let's just hard-code them into the script for the time being.
Could we move these to ALL_CFLAGS? Is there any downside other than
increased rebuilds when options change?
Thanks,
Jonathan
^ permalink raw reply
* Re: Incorrect name of PCM
From: Takashi Iwai @ 2018-07-23 17:40 UTC (permalink / raw)
To: Christopher Head; +Cc: alsa-devel
In-Reply-To: <56F88318-0461-4587-AE9D-A885BB121ADC@chead.ca>
On Mon, 23 Jul 2018 18:21:59 +0200,
Christopher Head wrote:
>
> On July 23, 2018 9:15:59 AM PDT, Takashi Iwai <tiwai@suse.de> wrote:
> >Just ignore this entry. alsa-lib tries to parse the all possible
> >outputs that are provided from the kernel interface. Due to
> >historical reasons, this digital output might be either SPDIF or HDMI,
> >and alsa-lib has no knowledge to distinguish easily, hence both spdif
> >and hdmi device names are provided equally for such a case.
>
> Not here, they aren’t. There is no PCM named “spdif” at all: it isn’t in the list, and if I type it, I can’t play to it for a reason that looks a lot like it doesn’t exist.
OK, then another possibility is a BIOS bug. BIOS declares the pin as
HDMI incorrectly although it's a SPDIF.
Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply
* Re: [PATCH v10 3/7] Bluetooth: btqca: Redefine qca_uart_setup() to generic function.
From: Matthias Kaehlcke @ 2018-07-23 17:40 UTC (permalink / raw)
To: Balakrishna Godavarthi
Cc: marcel, johan.hedberg, linux-kernel, devicetree, linux-bluetooth,
thierry.escande, rtatiya, hemantg, linux-arm-msm
In-Reply-To: <20180720133243.6851-4-bgodavar@codeaurora.org>
On Fri, Jul 20, 2018 at 07:02:39PM +0530, Balakrishna Godavarthi wrote:
> Redefinition of qca_uart_setup will help future Qualcomm Bluetooth
> SoC, to use the same function instead of duplicating the function.
> Added new arguments soc_type and soc_ver to the functions.
>
> These arguments will help to decide type of firmware files
> to be loaded into Bluetooth chip.
> soc_type holds the Bluetooth chip connected to APPS processor.
> soc_ver holds the Bluetooth chip version.
>
> Signed-off-by: Balakrishna Godavarthi <bgodavar@codeaurora.org>
> Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
> ---
> drivers/bluetooth/btqca.c | 20 +++++++-------------
> drivers/bluetooth/btqca.h | 13 +++++++++++--
> drivers/bluetooth/hci_qca.c | 10 +++++++++-
> 3 files changed, 27 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/bluetooth/btqca.c b/drivers/bluetooth/btqca.c
> index c5cf9cab438a..b556710ee1bd 100644
> --- a/drivers/bluetooth/btqca.c
> +++ b/drivers/bluetooth/btqca.c
> @@ -85,6 +85,9 @@ int qca_read_soc_version(struct hci_dev *hdev, u32 *soc_version)
> out:
> kfree_skb(skb);
>
> + if (err < 0 || *soc_version == 0)
> + bt_dev_err(hdev, "QCA Failed to get version (%d)", err);
You also have to set 'err' if soc_version is 0, so the caller can skip
the check for soc_version == 0
I'd suggest:
// directly after setting soc_version
if (*soc_version == 0)
err = -EILSEQ; // or should it be a different error code?
...
if (err)
bt_dev_err(hdev, "QCA Failed to get version (%d)", err);
You could also limit the error log to the 'if (*soc_version == 0)'
branch, for all other errors there will already be a more specific log
entry.
> +
> return err;
> }
Cheers
Matthias
^ permalink raw reply
* [Intel-wired-lan] [RFC 00/13] Bug fixes for ice
From: Shannon Nelson @ 2018-07-23 17:39 UTC (permalink / raw)
To: intel-wired-lan
In-Reply-To: <e2f9442bda931f8e813c9b4f9841ff0c404eafbe.camel@intel.com>
On 7/23/2018 10:39 AM, Jeff Kirsher wrote:
> On Mon, 2018-07-23 at 09:57 -0700, Shannon Nelson wrote:
>> On 7/20/2018 12:54 PM, Anirudh Venkataramanan wrote:
>>> This patch set fixes multiple bugs for the ice driver.
>>
>> Since the ice driver original patches are still under review and not
>> yet
>> upstream, why are these bug fixes not rolled into the original patch
>> set? Put these into the initial patch set and have a clearer
>> upstream
>> submission.
>
> Ah, the ice driver was submitted (and accepted) into 4.17 kernel. Not
> sure why you think the initial driver submission is still under review
> and not upstream. :-)
>
Hmmm... perhaps I'm confusing this with igc early this Monday morning?
My apologies. I'll go refresh my coffee.
sln
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v3 32/40] elf: Add nanoMIPS specific variations in ELF header fields
From: Aleksandar Markovic @ 2018-07-23 17:39 UTC (permalink / raw)
To: Richard Henderson, Stefan Markovic, qemu-devel@nongnu.org
Cc: laurent@vivier.eu, riku.voipio@iki.fi,
philippe.mathieu.daude@gmail.com, aurelien@aurel32.net,
Stefan Markovic, Petar Jovanovic, Paul Burton
In-Reply-To: <8d1a14bf-8cc5-91cb-5aed-cefeb8d97962@linaro.org>
> From: Richard Henderson <richard.henderson@linaro.org>
> Sent: Monday, July 23, 2018 6:59 PM
> On 07/19/2018 05:55 AM, Stefan Markovic wrote:
> > From: Aleksandar Markovic <amarkovic@wavecomp.com>
> >
> > Add nanoMIPS-related values in ELF header fields as specified in
> > nanoMIPS' "ELF ABI Supplement".
> >
> > Signed-off-by: Aleksandar Markovic <amarkovic@wavecomp.com>
> > Signed-off-by: Stefan Markovic <smarkovic@wavecomp.com>
> > ---
> > include/elf.h | 20 ++++++++++++++++++++
> > 1 file changed, 20 insertions(+)
>
> None of these values have made it upstream to binutils yet,
> so I can't double-check them. However,
>
> Acked-by: Richard Henderson <richard.henderson@linaro.org>
>
>
> r~
Hi, Richard.
True, binutils headers were not updated with these ELF-related values. However, there is a publicly-available document at https://codescape.mips.com/components/toolchain/nanomips/2018.04-02/releasenotes.html that should be the source of information for binutils headers, or any other related header in similar tools. Specifically, see Section 5.1 of that document.
Regards,
Aleksandar
^ permalink raw reply
* [Intel-wired-lan] [RFC 00/13] Bug fixes for ice
From: Jeff Kirsher @ 2018-07-23 17:39 UTC (permalink / raw)
To: intel-wired-lan
In-Reply-To: <b28588b5-6024-8e90-18b7-bade5264f885@oracle.com>
On Mon, 2018-07-23 at 09:57 -0700, Shannon Nelson wrote:
> On 7/20/2018 12:54 PM, Anirudh Venkataramanan wrote:
> > This patch set fixes multiple bugs for the ice driver.
>
> Since the ice driver original patches are still under review and not
> yet
> upstream, why are these bug fixes not rolled into the original patch
> set? Put these into the initial patch set and have a clearer
> upstream
> submission.
Ah, the ice driver was submitted (and accepted) into 4.17 kernel. Not
sure why you think the initial driver submission is still under review
and not upstream. :-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.osuosl.org/pipermail/intel-wired-lan/attachments/20180723/7dc02b1d/attachment.asc>
^ permalink raw reply
* Re: KASAN: use-after-free Read in rds_cong_queue_updates (2)
From: Santosh Shilimkar @ 2018-07-23 17:38 UTC (permalink / raw)
To: syzbot, davem, linux-kernel, linux-rdma, netdev, rds-devel,
syzkaller-bugs
In-Reply-To: <000000000000cdb5450571adfe40@google.com>
On 7/23/2018 10:30 AM, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: fcf4793e278e tls: check RCV_SHUTDOWN in tls_wait_data
> git tree: net
> console output: https://syzkaller.appspot.com/x/log.txt?x=1738cb2c400000
> kernel config: https://syzkaller.appspot.com/x/.config?x=c0bdc4175608181c
> dashboard link:
> https://syzkaller.appspot.com/bug?extid=470ae97a39f16146af45
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>
> Unfortunately, I don't have any reproducer for this crash yet.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+470ae97a39f16146af45@syzkaller.appspotmail.com
>
dup: syzbot+4c20b3866171ce8441d2@syzkaller.appspotmail.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.