* Re: pull-request: can 2018-07-23
From: David Miller @ 2018-07-23 18:02 UTC (permalink / raw)
To: mkl; +Cc: netdev, linux-can, kernel
In-Reply-To: <20180723125843.391-1-mkl@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Mon, 23 Jul 2018 14:58:31 +0200
> this is a pull request of 12 patches for net/master.
>
> The patch by Stephane Grosjean for the peak_canfd CAN driver fixes a problem
> with older firmware. The next patch is by Roman Fietze and fixes the setup of
> the CCCR register in the m_can driver. Nicholas Mc Guire's patch for the
> mpc5xxx_can driver adds missing error checking. The two patches by Faiz Abbas
> fix the runtime resume and clean up the probe function in the m_can driver. The
> last 7 patches by Anssi Hannula fix several problem in the xilinx_can driver.
Pulled, thanks Marc.
^ permalink raw reply
* [PATCH 10/10] drm/vmwgfx: Use __drm_atomic_helper_plane_reset instead of copying the logic
From: Sinclair Yeh @ 2018-07-23 18:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180720211509.23605-11-alexandru-cosmin.gheorghe@arm.com>
Hello Alex,
other than adding a brief commit message to this patch,
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
On Fri, Jul 20, 2018 at 10:15:09PM +0100, Alexandru Gheorghe wrote:
> Signed-off-by: Alexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com>
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> index 466336b34fff..1e0fb3c79b50 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> @@ -720,9 +720,7 @@ void vmw_du_plane_reset(struct drm_plane *plane)
> return;
> }
>
> - plane->state = &vps->base;
> - plane->state->plane = plane;
> - plane->state->rotation = DRM_MODE_ROTATE_0;
> + __drm_atomic_helper_plane_reset(plane, &vps->base);
> }
>
>
> --
> 2.18.0
>
^ permalink raw reply
* Re: [PATCH 10/10] drm/vmwgfx: Use __drm_atomic_helper_plane_reset instead of copying the logic
From: Sinclair Yeh @ 2018-07-23 18:02 UTC (permalink / raw)
To: Alexandru Gheorghe
Cc: alexandre.belloni, airlied, liviu.dudau, dri-devel,
laurent.pinchart, thellstrom, krzk, maxime.ripard, wens, kgene,
malidp, linux-graphics-maintainer, sunpeng.li, boris.brezillon,
linux-samsung-soc, nd, Tony.Cheng, linux-arm-kernel, sw0312.kim,
nicolas.ferre, shirish.s, kyungmin.park, alexander.deucher,
christian.koenig
In-Reply-To: <20180720211509.23605-11-alexandru-cosmin.gheorghe@arm.com>
Hello Alex,
other than adding a brief commit message to this patch,
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
On Fri, Jul 20, 2018 at 10:15:09PM +0100, Alexandru Gheorghe wrote:
> Signed-off-by: Alexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com>
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> index 466336b34fff..1e0fb3c79b50 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> @@ -720,9 +720,7 @@ void vmw_du_plane_reset(struct drm_plane *plane)
> return;
> }
>
> - plane->state = &vps->base;
> - plane->state->plane = plane;
> - plane->state->rotation = DRM_MODE_ROTATE_0;
> + __drm_atomic_helper_plane_reset(plane, &vps->base);
> }
>
>
> --
> 2.18.0
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v2 02/21] xen/arm: make allocate_memory work for non 1:1 mapped guests
From: Andrii Anisov @ 2018-07-23 18:01 UTC (permalink / raw)
To: Stefano Stabellini, julien.grall; +Cc: Stefano Stabellini, xen-devel
In-Reply-To: <1530918736-13965-2-git-send-email-sstabellini@kernel.org>
Hello Stefano,
On 07.07.18 02:11, Stefano Stabellini wrote:
> Extend allocate_memory to work for non 1:1 mapped domUs. Specifically,
> memory allocated for domU will be mapped into the domU pseudo-physical
> address space at the appropriate addresses according to the guest memory
> map: GUEST_RAM0_BASE and GUEST_RAM1_BASE.
I would speculate about GUEST_RAMx_BASE and GUEST_RAMx_SIZE macros.
Those values might not fit the real SoC memory map. And it becomes a
problem once we decided to assign some peripheral directly to the guest
because a RAM space specified to VM would overlap with IO range of the
assigned device.
In my practice, we always align those macros with the SoC memory map.
This becomes more convenient and practical than IO remapping.
It might be the moment to get those values configurable for the guests.
At least for those, which are configured from the device tree. Here
naturally fit making `memory` property similar to `reg` - the list of
<base, size> values.
--
*Andrii Anisov*
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH v4 5/5] doc: add ZLIB PMD guide
From: Verma, Shally @ 2018-07-23 18:00 UTC (permalink / raw)
To: De Lara Guarch, Pablo
Cc: dev@dpdk.org, Athreya, Narayana Prasad, Challa, Mahipal,
Sahu, Sunila, Gupta, Ashish
In-Reply-To: <E115CCD9D858EF4F90C690B0DCB4D8977F8FFA99@IRSMSX107.ger.corp.intel.com>
>-----Original Message-----
>From: De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
>Sent: 23 July 2018 23:28
>To: Verma, Shally <Shally.Verma@cavium.com>
>Cc: dev@dpdk.org; Athreya, Narayana Prasad <NarayanaPrasad.Athreya@cavium.com>; Challa, Mahipal
><Mahipal.Challa@cavium.com>; Sahu, Sunila <Sunila.Sahu@cavium.com>; Gupta, Ashish <Ashish.Gupta@cavium.com>
>Subject: RE: [dpdk-dev] [PATCH v4 5/5] doc: add ZLIB PMD guide
>
>External Email
>
>> -----Original Message-----
>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Shally Verma
>> Sent: Monday, July 23, 2018 3:51 PM
>> To: De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
>> Cc: dev@dpdk.org; pathreya@caviumnetworks.com;
>> mchalla@caviumnetworks.com; Sunila Sahu
>> <sunila.sahu@caviumnetworks.com>; Ashish Gupta
>> <ashish.gupta@caviumnetworks.com>
>> Subject: [dpdk-dev] [PATCH v4 5/5] doc: add ZLIB PMD guide
>>
>> Add zlib pmd feature support and user guide with build and run instructions
>>
>> Signed-off-by: Sunila Sahu <sunila.sahu@caviumnetworks.com>
>> Signed-off-by: Shally Verma <shally.verma@caviumnetworks.com>
>> Signed-off-by: Ashish Gupta <ashish.gupta@caviumnetworks.com>
>> ---
>> MAINTAINERS | 2 +
>> doc/guides/compressdevs/features/zlib.ini | 11 +++++
>> doc/guides/compressdevs/index.rst | 1 +
>> doc/guides/compressdevs/zlib.rst | 69
>> +++++++++++++++++++++++++++++++
>> 4 files changed, 83 insertions(+)
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index ca27c6f..7e3c450 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -875,6 +875,8 @@ F: drivers/common/qat/ ZLIB
>> M: Sunila Sahu <sunila.sahu@caviumnetworks.com>
>> F: drivers/compress/zlib/
>> +F: doc/guides/compressdevs/zlib.rst
>> +F: doc/guides/compressdevs/features/zlib.ini
>>
>> Eventdev Drivers
>> ----------------
>> diff --git a/doc/guides/compressdevs/features/zlib.ini
>> b/doc/guides/compressdevs/features/zlib.ini
>> new file mode 100644
>> index 0000000..c794643
>> --- /dev/null
>> +++ b/doc/guides/compressdevs/features/zlib.ini
>> @@ -0,0 +1,11 @@
>> +;
>> +; Refer to default.ini for the full list of available PMD features.
>> +;
>> +; Supported features of 'ZLIB' compression driver.
>> +;
>> +[Features]
>> +Pass-through = Y
>> +Deflate = Y
>> +Fixed = Y
>> +Dynamic = Y
>> +OOP SGL In SGL Out = Y
>
>I assume that you support also "OOP SGL In LB Out" and "OOP LB In SGL Out", right?
yes, but untested thus not claiming.
Thanks
Shally
^ permalink raw reply
* [PATCH] net/mlx5: fix assert for Tx completion queue count
From: Yongseok Koh @ 2018-07-23 18:00 UTC (permalink / raw)
To: shahafs; +Cc: dev, Yongseok Koh, stable
There should be at least one Tx CQE remained if Tx WQ and txq->elts[] have
available slots to send a packet because the size of Tx CQ is exactly
calculated from the size of other resources. As it is guaranteed, it is
checked by an assertion.
max_elts is checked after the assertion for Tx CQ. If no slot is available
in txq->elts[], the assertion would be wrong.
Fixes: 2eefbec531c7 ("net/mlx5: add missing sanity checks for Tx completion queue")
Fixes: 6ce84bd88919 ("net/mlx5: add enhanced multi-packet send for ConnectX-5")
Cc: stable@dpdk.org
Signed-off-by: Yongseok Koh <yskoh@mellanox.com>
Acked-by: Xueming Li <xuemingl@mellanox.com>
---
drivers/net/mlx5/mlx5_rxtx.c | 28 ++++++++--------------------
drivers/net/mlx5/mlx5_rxtx_vec_neon.h | 14 ++++----------
drivers/net/mlx5/mlx5_rxtx_vec_sse.h | 14 ++++----------
3 files changed, 16 insertions(+), 40 deletions(-)
diff --git a/drivers/net/mlx5/mlx5_rxtx.c b/drivers/net/mlx5/mlx5_rxtx.c
index 52a1074a8..2d14f8a6e 100644
--- a/drivers/net/mlx5/mlx5_rxtx.c
+++ b/drivers/net/mlx5/mlx5_rxtx.c
@@ -504,8 +504,6 @@ mlx5_tx_burst(void *dpdk_txq, struct rte_mbuf **pkts, uint16_t pkts_n)
/* Start processing. */
mlx5_tx_complete(txq);
max_elts = (elts_n - (elts_head - txq->elts_tail));
- /* A CQE slot must always be available. */
- assert((1u << txq->cqe_n) - (txq->cq_pi - txq->cq_ci));
max_wqe = (1u << txq->wqe_n) - (txq->wqe_ci - txq->wqe_pi);
if (unlikely(!max_wqe))
return 0;
@@ -817,14 +815,13 @@ mlx5_tx_burst(void *dpdk_txq, struct rte_mbuf **pkts, uint16_t pkts_n)
/* Check whether completion threshold has been reached. */
comp = txq->elts_comp + i + j + k;
if (comp >= MLX5_TX_COMP_THRESH) {
+ /* A CQE slot must always be available. */
+ assert((1u << txq->cqe_n) - (txq->cq_pi++ - txq->cq_ci));
/* Request completion on last WQE. */
last_wqe->ctrl2 = rte_cpu_to_be_32(8);
/* Save elts_head in unused "immediate" field of WQE. */
last_wqe->ctrl3 = txq->elts_head;
txq->elts_comp = 0;
-#ifndef NDEBUG
- ++txq->cq_pi;
-#endif
} else {
txq->elts_comp = comp;
}
@@ -943,8 +940,6 @@ mlx5_tx_burst_mpw(void *dpdk_txq, struct rte_mbuf **pkts, uint16_t pkts_n)
/* Start processing. */
mlx5_tx_complete(txq);
max_elts = (elts_n - (elts_head - txq->elts_tail));
- /* A CQE slot must always be available. */
- assert((1u << txq->cqe_n) - (txq->cq_pi - txq->cq_ci));
max_wqe = (1u << txq->wqe_n) - (txq->wqe_ci - txq->wqe_pi);
if (unlikely(!max_wqe))
return 0;
@@ -1033,14 +1028,13 @@ mlx5_tx_burst_mpw(void *dpdk_txq, struct rte_mbuf **pkts, uint16_t pkts_n)
if (comp >= MLX5_TX_COMP_THRESH) {
volatile struct mlx5_wqe *wqe = mpw.wqe;
+ /* A CQE slot must always be available. */
+ assert((1u << txq->cqe_n) - (txq->cq_pi++ - txq->cq_ci));
/* Request completion on last WQE. */
wqe->ctrl[2] = rte_cpu_to_be_32(8);
/* Save elts_head in unused "immediate" field of WQE. */
wqe->ctrl[3] = elts_head;
txq->elts_comp = 0;
-#ifndef NDEBUG
- ++txq->cq_pi;
-#endif
} else {
txq->elts_comp = comp;
}
@@ -1172,8 +1166,6 @@ mlx5_tx_burst_mpw_inline(void *dpdk_txq, struct rte_mbuf **pkts,
/* Start processing. */
mlx5_tx_complete(txq);
max_elts = (elts_n - (elts_head - txq->elts_tail));
- /* A CQE slot must always be available. */
- assert((1u << txq->cqe_n) - (txq->cq_pi - txq->cq_ci));
do {
struct rte_mbuf *buf = *(pkts++);
uintptr_t addr;
@@ -1330,14 +1322,13 @@ mlx5_tx_burst_mpw_inline(void *dpdk_txq, struct rte_mbuf **pkts,
if (comp >= MLX5_TX_COMP_THRESH) {
volatile struct mlx5_wqe *wqe = mpw.wqe;
+ /* A CQE slot must always be available. */
+ assert((1u << txq->cqe_n) - (txq->cq_pi++ - txq->cq_ci));
/* Request completion on last WQE. */
wqe->ctrl[2] = rte_cpu_to_be_32(8);
/* Save elts_head in unused "immediate" field of WQE. */
wqe->ctrl[3] = elts_head;
txq->elts_comp = 0;
-#ifndef NDEBUG
- ++txq->cq_pi;
-#endif
} else {
txq->elts_comp = comp;
}
@@ -1461,8 +1452,6 @@ txq_burst_empw(struct mlx5_txq_data *txq, struct rte_mbuf **pkts,
/* Start processing. */
mlx5_tx_complete(txq);
max_elts = (elts_n - (elts_head - txq->elts_tail));
- /* A CQE slot must always be available. */
- assert((1u << txq->cqe_n) - (txq->cq_pi - txq->cq_ci));
max_wqe = (1u << txq->wqe_n) - (txq->wqe_ci - txq->wqe_pi);
if (unlikely(!max_wqe))
return 0;
@@ -1618,15 +1607,14 @@ txq_burst_empw(struct mlx5_txq_data *txq, struct rte_mbuf **pkts,
(1 << txq->wqe_n) / MLX5_TX_COMP_THRESH_INLINE_DIV) {
volatile struct mlx5_wqe *wqe = mpw.wqe;
+ /* A CQE slot must always be available. */
+ assert((1u << txq->cqe_n) - (txq->cq_pi++ - txq->cq_ci));
/* Request completion on last WQE. */
wqe->ctrl[2] = rte_cpu_to_be_32(8);
/* Save elts_head in unused "immediate" field of WQE. */
wqe->ctrl[3] = elts_head;
txq->elts_comp = 0;
txq->mpw_comp = txq->wqe_ci;
-#ifndef NDEBUG
- ++txq->cq_pi;
-#endif
} else {
txq->elts_comp += j;
}
diff --git a/drivers/net/mlx5/mlx5_rxtx_vec_neon.h b/drivers/net/mlx5/mlx5_rxtx_vec_neon.h
index 3ebf34823..b37b7381c 100644
--- a/drivers/net/mlx5/mlx5_rxtx_vec_neon.h
+++ b/drivers/net/mlx5/mlx5_rxtx_vec_neon.h
@@ -107,8 +107,6 @@ txq_scatter_v(struct mlx5_txq_data *txq, struct rte_mbuf **pkts,
assert(elts_n > pkts_n);
mlx5_tx_complete(txq);
- /* A CQE slot must always be available. */
- assert((1u << txq->cqe_n) - (txq->cq_pi - txq->cq_ci));
if (unlikely(!pkts_n))
return 0;
for (n = 0; n < pkts_n; ++n) {
@@ -176,12 +174,11 @@ txq_scatter_v(struct mlx5_txq_data *txq, struct rte_mbuf **pkts,
txq->elts_comp += (uint16_t)(elts_head - txq->elts_head);
txq->elts_head = elts_head;
if (txq->elts_comp >= MLX5_TX_COMP_THRESH) {
+ /* A CQE slot must always be available. */
+ assert((1u << txq->cqe_n) - (txq->cq_pi++ - txq->cq_ci));
wqe->ctrl[2] = rte_cpu_to_be_32(8);
wqe->ctrl[3] = txq->elts_head;
txq->elts_comp = 0;
-#ifndef NDEBUG
- ++txq->cq_pi;
-#endif
}
#ifdef MLX5_PMD_SOFT_COUNTERS
txq->stats.opackets += n;
@@ -245,8 +242,6 @@ txq_burst_v(struct mlx5_txq_data *txq, struct rte_mbuf **pkts, uint16_t pkts_n,
assert(elts_n > pkts_n);
mlx5_tx_complete(txq);
max_elts = (elts_n - (elts_head - txq->elts_tail));
- /* A CQE slot must always be available. */
- assert((1u << txq->cqe_n) - (txq->cq_pi - txq->cq_ci));
max_wqe = (1u << txq->wqe_n) - (txq->wqe_ci - txq->wqe_pi);
pkts_n = RTE_MIN((unsigned int)RTE_MIN(pkts_n, max_wqe), max_elts);
if (unlikely(!pkts_n))
@@ -282,11 +277,10 @@ txq_burst_v(struct mlx5_txq_data *txq, struct rte_mbuf **pkts, uint16_t pkts_n,
if (txq->elts_comp + pkts_n < MLX5_TX_COMP_THRESH) {
txq->elts_comp += pkts_n;
} else {
+ /* A CQE slot must always be available. */
+ assert((1u << txq->cqe_n) - (txq->cq_pi++ - txq->cq_ci));
/* Request a completion. */
txq->elts_comp = 0;
-#ifndef NDEBUG
- ++txq->cq_pi;
-#endif
comp_req = 8;
}
/* Fill CTRL in the header. */
diff --git a/drivers/net/mlx5/mlx5_rxtx_vec_sse.h b/drivers/net/mlx5/mlx5_rxtx_vec_sse.h
index f0d888831..54b3783cf 100644
--- a/drivers/net/mlx5/mlx5_rxtx_vec_sse.h
+++ b/drivers/net/mlx5/mlx5_rxtx_vec_sse.h
@@ -107,8 +107,6 @@ txq_scatter_v(struct mlx5_txq_data *txq, struct rte_mbuf **pkts,
assert(elts_n > pkts_n);
mlx5_tx_complete(txq);
- /* A CQE slot must always be available. */
- assert((1u << txq->cqe_n) - (txq->cq_pi - txq->cq_ci));
if (unlikely(!pkts_n))
return 0;
for (n = 0; n < pkts_n; ++n) {
@@ -177,12 +175,11 @@ txq_scatter_v(struct mlx5_txq_data *txq, struct rte_mbuf **pkts,
txq->elts_comp += (uint16_t)(elts_head - txq->elts_head);
txq->elts_head = elts_head;
if (txq->elts_comp >= MLX5_TX_COMP_THRESH) {
+ /* A CQE slot must always be available. */
+ assert((1u << txq->cqe_n) - (txq->cq_pi++ - txq->cq_ci));
wqe->ctrl[2] = rte_cpu_to_be_32(8);
wqe->ctrl[3] = txq->elts_head;
txq->elts_comp = 0;
-#ifndef NDEBUG
- ++txq->cq_pi;
-#endif
}
#ifdef MLX5_PMD_SOFT_COUNTERS
txq->stats.opackets += n;
@@ -244,8 +241,6 @@ txq_burst_v(struct mlx5_txq_data *txq, struct rte_mbuf **pkts, uint16_t pkts_n,
assert(elts_n > pkts_n);
mlx5_tx_complete(txq);
max_elts = (elts_n - (elts_head - txq->elts_tail));
- /* A CQE slot must always be available. */
- assert((1u << txq->cqe_n) - (txq->cq_pi - txq->cq_ci));
max_wqe = (1u << txq->wqe_n) - (txq->wqe_ci - txq->wqe_pi);
pkts_n = RTE_MIN((unsigned int)RTE_MIN(pkts_n, max_wqe), max_elts);
assert(pkts_n <= MLX5_DSEG_MAX - nb_dword_in_hdr);
@@ -283,11 +278,10 @@ txq_burst_v(struct mlx5_txq_data *txq, struct rte_mbuf **pkts, uint16_t pkts_n,
if (txq->elts_comp + pkts_n < MLX5_TX_COMP_THRESH) {
txq->elts_comp += pkts_n;
} else {
+ /* A CQE slot must always be available. */
+ assert((1u << txq->cqe_n) - (txq->cq_pi++ - txq->cq_ci));
/* Request a completion. */
txq->elts_comp = 0;
-#ifndef NDEBUG
- ++txq->cq_pi;
-#endif
comp_req = 8;
}
/* Fill CTRL in the header. */
--
2.11.0
^ permalink raw reply related
* [qemu-mainline test] 125503: regressions - FAIL
From: osstest service owner @ 2018-07-23 17:59 UTC (permalink / raw)
To: xen-devel, osstest-admin
flight 125503 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125503/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-credit2 <job status> broken in 125485
test-arm64-arm64-libvirt-xsm <job status> broken in 125485
test-amd64-amd64-xl 10 debian-install fail REGR. vs. 125169
Tests which are failing intermittently (not blocking):
test-arm64-arm64-xl-credit2 4 host-install(4) broken in 125485 pass in 125503
test-arm64-arm64-libvirt-xsm 4 host-install(4) broken in 125485 pass in 125503
test-amd64-i386-freebsd10-amd64 10 freebsd-install fail in 125485 pass in 125503
test-armhf-armhf-libvirt 5 host-ping-check-native fail in 125485 pass in 125503
test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail pass in 125485
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 125169
test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 125169
test-armhf-armhf-libvirt 14 saverestore-support-check fail like 125169
test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 125169
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 125169
test-amd64-i386-xl-pvshim 12 guest-start fail never pass
test-amd64-i386-libvirt 13 migrate-support-check fail never pass
test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass
test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass
test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass
test-arm64-arm64-xl 13 migrate-support-check fail never pass
test-arm64-arm64-xl 14 saverestore-support-check fail never pass
test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass
test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass
test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass
test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass
test-amd64-amd64-libvirt 13 migrate-support-check fail never pass
test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass
test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass
test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass
test-armhf-armhf-xl 13 migrate-support-check fail never pass
test-armhf-armhf-xl 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass
test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass
test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass
test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass
test-armhf-armhf-libvirt 13 migrate-support-check fail never pass
test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass
test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass
test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass
test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass
test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass
test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
test-amd64-amd64-xl-qemuu-win10-i386 10 windows-install fail never pass
test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
version targeted for testing:
qemuu 5b3ecd3d941a0ae8a8cfbba5ab8139b2bf104822
baseline version:
qemuu 9277d81f5c2c6f4d0b5e47c8476eb7ee7e5c0beb
Last test of basis 125169 2018-07-14 20:30:43 Z 8 days
Failing since 125246 2018-07-16 15:53:25 Z 7 days 5 attempts
Testing same since 125485 2018-07-20 21:12:02 Z 2 days 2 attempts
------------------------------------------------------------
People who touched revisions under test:
Alex Bennée <alex.bennee@linaro.org>
Alistair Francis <alistair.francis@wdc.com>
Andrew Jeffery <andrew@aj.id.au>
BALATON Zoltan <balaton@eik.bme.hu>
Calvin Lee <cyrus296@gmail.com>
Christian Borntraeger <borntraeger@de.ibm.com>
Cornelia Huck <cohuck@redhat.com>
Daniel P. Berrangé <berrange@redhat.com>
David Gibson <david@gibson.dropbear.id.au>
David Hildenbrand <david@redhat.com>
Eduardo Habkost <ehabkost@redhat.com>
Emanuele Giuseppe Esposito <e.emanuelegiuseppe@gmail.com>
Greg Kurz <groug@kaod.org>
Guenter Roeck <linux@roeck-us.net>
Igor Mammedov <imammedo@redhat.com>
Jan Kiszka <jan.kiszka@siemens.com>
Jason Wang <jasowang@redhat.com>
Jonas Schievink <jonasschievink@gmail.com>
Laurent Vivier <laurent@vivier.eu>
Marc-André Lureau <marcandre.lureau@redhat.com>
Marc-André Lureau <marcandre.lureau@redhat.com>
Markus Armbruster <armbru@redhat.com>
Michael Davidsaver <mdavidsaver@gmail.com>
Michael Roth <mdroth@linux.vnet.ibm.com>
Paolo Bonzini <pbonzini@redhat.com>
Peter Maydell <peter.maydell@linaro.org>
Philippe Mathieu-Daudé <f4bug@amsat.org>
Richard Henderson <richard.henderson@linaro.org>
Roman Kagan <rkagan@virtuozzo.com>
Shivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
Stefan Hajnoczi <stefanha@redhat.com>
Stefan Weil <sw@weilnetz.de>
Thomas Huth <thuth@redhat.com>
Viktor Prutyanov <viktor.prutyanov@virtuozzo.com>
Yaowei Bai <baiyaowei@cmss.chinamobile.com>
Yunjian Wang <wangyunjian@huawei.com>
jobs:
build-amd64-xsm pass
build-arm64-xsm pass
build-i386-xsm pass
build-amd64 pass
build-arm64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-arm64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-pvops pass
build-arm64-pvops pass
build-armhf-pvops pass
build-i386-pvops pass
test-amd64-amd64-xl fail
test-arm64-arm64-xl pass
test-armhf-armhf-xl pass
test-amd64-i386-xl pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-libvirt-xsm pass
test-arm64-arm64-libvirt-xsm pass
test-amd64-i386-libvirt-xsm pass
test-amd64-amd64-xl-xsm pass
test-arm64-arm64-xl-xsm pass
test-amd64-i386-xl-xsm pass
test-amd64-amd64-qemuu-nested-amd fail
test-amd64-amd64-xl-pvhv2-amd pass
test-amd64-i386-qemuu-rhel6hvm-amd fail
test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-freebsd10-amd64 pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
test-amd64-amd64-xl-qemuu-win7-amd64 fail
test-amd64-i386-xl-qemuu-win7-amd64 fail
test-amd64-amd64-xl-qemuu-ws16-amd64 fail
test-amd64-i386-xl-qemuu-ws16-amd64 fail
test-armhf-armhf-xl-arndale pass
test-amd64-amd64-xl-credit2 pass
test-arm64-arm64-xl-credit2 pass
test-armhf-armhf-xl-credit2 pass
test-armhf-armhf-xl-cubietruck pass
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass
test-amd64-i386-freebsd10-i386 pass
test-amd64-amd64-xl-qemuu-win10-i386 fail
test-amd64-i386-xl-qemuu-win10-i386 fail
test-amd64-amd64-qemuu-nested-intel pass
test-amd64-amd64-xl-pvhv2-intel pass
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-amd64-libvirt pass
test-armhf-armhf-libvirt pass
test-amd64-i386-libvirt pass
test-amd64-amd64-xl-multivcpu pass
test-armhf-armhf-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-amd64-amd64-libvirt-pair pass
test-amd64-i386-libvirt-pair pass
test-amd64-amd64-amd64-pvgrub pass
test-amd64-amd64-i386-pvgrub pass
test-amd64-amd64-xl-pvshim pass
test-amd64-i386-xl-pvshim fail
test-amd64-amd64-pygrub pass
test-amd64-amd64-xl-qcow2 pass
test-armhf-armhf-libvirt-raw pass
test-amd64-i386-xl-raw pass
test-amd64-amd64-xl-rtds pass
test-armhf-armhf-xl-rtds pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass
test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass
test-amd64-amd64-xl-shadow pass
test-amd64-i386-xl-shadow pass
test-amd64-amd64-libvirt-vhd pass
test-armhf-armhf-xl-vhd pass
------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
broken-job test-arm64-arm64-xl-credit2 broken
broken-job test-arm64-arm64-libvirt-xsm broken
Not pushing.
(No revision log; it would be 1904 lines long.)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* ✓ Fi.CI.BAT: success for drm/i915: Skip repeated calls to i915_gem_set_wedged() (rev2)
From: Patchwork @ 2018-07-23 17:59 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx
In-Reply-To: <20180723145335.24579-1-chris@chris-wilson.co.uk>
== Series Details ==
Series: drm/i915: Skip repeated calls to i915_gem_set_wedged() (rev2)
URL : https://patchwork.freedesktop.org/series/47067/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4529 -> Patchwork_9749 =
== Summary - WARNING ==
Minor unknown changes coming with Patchwork_9749 need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_9749, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL: https://patchwork.freedesktop.org/api/1.0/series/47067/revisions/2/mbox/
== Possible new issues ==
Here are the unknown changes that may have been introduced in Patchwork_9749:
=== IGT changes ===
==== Warnings ====
igt@drv_selftest@live_execlists:
fi-kbl-7500u: SKIP -> PASS +1
== Known issues ==
Here are the changes found in Patchwork_9749 that come from known issues:
=== IGT changes ===
==== Issues hit ====
igt@drv_selftest@mock_sanitycheck:
fi-glk-j4005: PASS -> DMESG-WARN (fdo#107344)
igt@gem_exec_fence@nb-await-default:
fi-glk-j4005: PASS -> DMESG-WARN (fdo#105719)
igt@kms_flip@basic-flip-vs-modeset:
fi-glk-j4005: PASS -> DMESG-WARN (fdo#106000)
==== Possible fixes ====
igt@drv_selftest@live_hangcheck:
fi-kbl-7500u: DMESG-FAIL (fdo#106947) -> PASS
fi-skl-guc: DMESG-FAIL (fdo#107174) -> PASS
igt@drv_selftest@live_workarounds:
fi-skl-6700hq: DMESG-FAIL (fdo#107292) -> PASS
igt@gem_exec_gttfill@basic:
fi-glk-j4005: DMESG-WARN (fdo#106097) -> PASS
fdo#105719 https://bugs.freedesktop.org/show_bug.cgi?id=105719
fdo#106000 https://bugs.freedesktop.org/show_bug.cgi?id=106000
fdo#106097 https://bugs.freedesktop.org/show_bug.cgi?id=106097
fdo#106947 https://bugs.freedesktop.org/show_bug.cgi?id=106947
fdo#107174 https://bugs.freedesktop.org/show_bug.cgi?id=107174
fdo#107292 https://bugs.freedesktop.org/show_bug.cgi?id=107292
fdo#107344 https://bugs.freedesktop.org/show_bug.cgi?id=107344
== Participating hosts (50 -> 43) ==
Missing (7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-skl-caroline fi-byt-clapper
== Build changes ==
* Linux: CI_DRM_4529 -> Patchwork_9749
CI_DRM_4529: f44f476c6bb735cb4067af0c4417c49d105bf419 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_4571: 65fccc149b85968cdce4737266b056059c1510f3 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9749: 9b348bfd231b38751c4d528a89d795745484c760 @ git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
9b348bfd231b drm/i915: Skip repeated calls to i915_gem_set_wedged()
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9749/issues.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH v3 00/18] JZ4780 DMA patchset v3
From: Paul Burton @ 2018-07-23 17:58 UTC (permalink / raw)
To: Paul Cercueil, Vinod Koul
Cc: Rob Herring, Mark Rutland, Ralf Baechle, James Hogan,
Zubair Lutfullah Kakakhel, Mathieu Malaterre, Daniel Silsby,
dmaengine, devicetree, linux-kernel, linux-mips
In-Reply-To: <20180721110643.19624-1-paul@crapouillou.net>
Hi Paul & Vinod,
On Sat, Jul 21, 2018 at 01:06:25PM +0200, Paul Cercueil wrote:
> This is the version 3 of my jz4780-dma driver update patchset.
>
> Apologies to the DMA people, the v2 of this patchset did not make it to
> their mailing-list; see the bottom of this email for a description of
> what happened in v2.
>
> Changelog from v2 to v3:
>
> - Modified the devicetree bindings to comply with the specification
>
> - New patch [06/18] allows the JZ4780 DMA driver to be compiled within a
> generic MIPS kernel.
Would you prefer to take the MIPS .dts changes in patches 16-18 through
the DMA tree with the rest of the series?
If so then for patches 16-18:
Acked-by: Paul Burton <paul.burton@mips.com>
Thanks,
Paul
^ permalink raw reply
* [PATCH 2/2] Add support for CPCAP regulators on Tegra devices.
From: Peter Geis @ 2018-07-23 17:58 UTC (permalink / raw)
To: lgirdwood
Cc: broonie, robh+dt, mark.rutland, linux-kernel, devicetree,
linux-tegra
Added support for the CPCAP power management regulator functions on
Tegra devices.
Added sw2_sw4 value tables, which provide power to the Tegra core and
aux devices.
Added the Tegra init tables and device tree compatibility match.
Signed-off-by: Peter Geis <pgwipeout@gmail.com>
---
.../bindings/regulator/cpcap-regulator.txt | 1 +
drivers/regulator/cpcap-regulator.c | 80 +++++++++++++++++++
2 files changed, 81 insertions(+)
diff --git
a/Documentation/devicetree/bindings/regulator/cpcap-regulator.txt
b/Documentation/devicetree/bindings/regulator/cpcap-regulator.txt
index 675f4437ce92..3e2d33ab1731 100644
--- a/Documentation/devicetree/bindings/regulator/cpcap-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/cpcap-regulator.txt
@@ -4,6 +4,7 @@ Motorola CPCAP PMIC voltage regulators
Requires node properties:
- "compatible" value one of:
"motorola,cpcap-regulator"
+ "motorola,tegra-cpcap-regulator"
"motorola,mapphone-cpcap-regulator"
Required regulator properties:
diff --git a/drivers/regulator/cpcap-regulator.c
b/drivers/regulator/cpcap-regulator.c
index c0b1e04bd90f..cb3774be445d 100644
--- a/drivers/regulator/cpcap-regulator.c
+++ b/drivers/regulator/cpcap-regulator.c
@@ -412,6 +412,82 @@ static struct cpcap_regulator omap4_regulators[] = {
{ /* sentinel */ },
};
+static struct cpcap_regulator tegra_regulators[] = {
+ CPCAP_REG(SW1, CPCAP_REG_S1C1, CPCAP_REG_ASSIGN2,
+ CPCAP_BIT_SW1_SEL, unknown_val_tbl,
+ 0, 0, 0, 0, 0, 0),
+ CPCAP_REG(SW2, CPCAP_REG_S2C1, CPCAP_REG_ASSIGN2,
+ CPCAP_BIT_SW2_SEL, sw2_sw4_val_tbl,
+ 0xf00, 0x7f, 0, 0x800, 0, 120),
+ CPCAP_REG(SW3, CPCAP_REG_S3C, CPCAP_REG_ASSIGN2,
+ CPCAP_BIT_SW3_SEL, unknown_val_tbl,
+ 0, 0, 0, 0, 0, 0),
+ CPCAP_REG(SW4, CPCAP_REG_S4C1, CPCAP_REG_ASSIGN2,
+ CPCAP_BIT_SW4_SEL, sw2_sw4_val_tbl,
+ 0xf00, 0x7f, 0, 0x900, 0, 100),
+ CPCAP_REG(SW5, CPCAP_REG_S5C, CPCAP_REG_ASSIGN2,
+ CPCAP_BIT_SW5_SEL, sw5_val_tbl,
+ 0x2a, 0, 0, 0x22, 0, 0),
+ CPCAP_REG(SW6, CPCAP_REG_S6C, CPCAP_REG_ASSIGN2,
+ CPCAP_BIT_SW6_SEL, unknown_val_tbl,
+ 0, 0, 0, 0, 0, 0),
+ CPCAP_REG(VCAM, CPCAP_REG_VCAMC, CPCAP_REG_ASSIGN2,
+ CPCAP_BIT_VCAM_SEL, vcam_val_tbl,
+ 0x87, 0x30, 4, 0x7, 0, 420),
+ CPCAP_REG(VCSI, CPCAP_REG_VCSIC, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VCSI_SEL, vcsi_val_tbl,
+ 0x47, 0x10, 4, 0x7, 0, 350),
+ CPCAP_REG(VDAC, CPCAP_REG_VDACC, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VDAC_SEL, vdac_val_tbl,
+ 0x87, 0x30, 4, 0x3, 0, 420),
+ CPCAP_REG(VDIG, CPCAP_REG_VDIGC, CPCAP_REG_ASSIGN2,
+ CPCAP_BIT_VDIG_SEL, vdig_val_tbl,
+ 0x87, 0x30, 4, 0x5, 0, 420),
+ CPCAP_REG(VFUSE, CPCAP_REG_VFUSEC, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VFUSE_SEL, vfuse_val_tbl,
+ 0x80, 0xf, 0, 0x80, 0, 420),
+ CPCAP_REG(VHVIO, CPCAP_REG_VHVIOC, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VHVIO_SEL, vhvio_val_tbl,
+ 0x17, 0, 0, 0x2, 0, 0),
+ CPCAP_REG(VSDIO, CPCAP_REG_VSDIOC, CPCAP_REG_ASSIGN2,
+ CPCAP_BIT_VSDIO_SEL, vsdio_val_tbl,
+ 0x87, 0x38, 3, 0x2, 0, 420),
+ CPCAP_REG(VPLL, CPCAP_REG_VPLLC, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VPLL_SEL, vpll_val_tbl,
+ 0x43, 0x18, 3, 0x1, 0, 420),
+ CPCAP_REG(VRF1, CPCAP_REG_VRF1C, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VRF1_SEL, vrf1_val_tbl,
+ 0xac, 0x2, 1, 0xc, 0, 10),
+ CPCAP_REG(VRF2, CPCAP_REG_VRF2C, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VRF2_SEL, vrf2_val_tbl,
+ 0x23, 0x8, 3, 0x3, 0, 10),
+ CPCAP_REG(VRFREF, CPCAP_REG_VRFREFC, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VRFREF_SEL, vrfref_val_tbl,
+ 0x23, 0x8, 3, 0x3, 0, 420),
+ CPCAP_REG(VWLAN1, CPCAP_REG_VWLAN1C, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VWLAN1_SEL, vwlan1_val_tbl,
+ 0x47, 0x10, 4, 0x5, 0, 420),
+ CPCAP_REG(VWLAN2, CPCAP_REG_VWLAN2C, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VWLAN2_SEL, vwlan2_val_tbl,
+ 0x20c, 0xc0, 6, 0x8, 0, 420),
+ CPCAP_REG(VSIM, CPCAP_REG_VSIMC, CPCAP_REG_ASSIGN3,
+ 0xffff, vsim_val_tbl,
+ 0x23, 0x8, 3, 0x3, 0, 420),
+ CPCAP_REG(VSIMCARD, CPCAP_REG_VSIMC, CPCAP_REG_ASSIGN3,
+ 0xffff, vsimcard_val_tbl,
+ 0x1e80, 0x8, 3, 0x1e00, 0, 420),
+ CPCAP_REG(VVIB, CPCAP_REG_VVIBC, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VVIB_SEL, vvib_val_tbl,
+ 0x1, 0xc, 2, 0, 0x1, 500),
+ CPCAP_REG(VUSB, CPCAP_REG_VUSBC, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VUSB_SEL, vusb_val_tbl,
+ 0x11c, 0x40, 6, 0xc, 0, 0),
+ CPCAP_REG(VAUDIO, CPCAP_REG_VAUDIOC, CPCAP_REG_ASSIGN4,
+ CPCAP_BIT_VAUDIO_SEL, vaudio_val_tbl,
+ 0x16, 0x1, 0, 0x4, 0, 0),
+ { /* sentinel */ },
+};
+
static const struct of_device_id cpcap_regulator_id_table[] = {
{
.compatible = "motorola,cpcap-regulator",
@@ -420,6 +496,10 @@ static const struct of_device_id
cpcap_regulator_id_table[] = {
.compatible = "motorola,mapphone-cpcap-regulator",
.data = omap4_regulators,
},
+ {
+ .compatible = "motorola,tegra-cpcap-regulator",
+ .data = tegra_regulators,
+ },
{},
};
MODULE_DEVICE_TABLE(of, cpcap_regulator_id_table);
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v4 5/5] doc: add ZLIB PMD guide
From: De Lara Guarch, Pablo @ 2018-07-23 17:58 UTC (permalink / raw)
To: Shally Verma
Cc: dev@dpdk.org, pathreya@caviumnetworks.com,
mchalla@caviumnetworks.com, Sunila Sahu, Ashish Gupta
In-Reply-To: <1532357474-9544-6-git-send-email-shally.verma@caviumnetworks.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Shally Verma
> Sent: Monday, July 23, 2018 3:51 PM
> To: De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
> Cc: dev@dpdk.org; pathreya@caviumnetworks.com;
> mchalla@caviumnetworks.com; Sunila Sahu
> <sunila.sahu@caviumnetworks.com>; Ashish Gupta
> <ashish.gupta@caviumnetworks.com>
> Subject: [dpdk-dev] [PATCH v4 5/5] doc: add ZLIB PMD guide
>
> Add zlib pmd feature support and user guide with build and run instructions
>
> Signed-off-by: Sunila Sahu <sunila.sahu@caviumnetworks.com>
> Signed-off-by: Shally Verma <shally.verma@caviumnetworks.com>
> Signed-off-by: Ashish Gupta <ashish.gupta@caviumnetworks.com>
> ---
> MAINTAINERS | 2 +
> doc/guides/compressdevs/features/zlib.ini | 11 +++++
> doc/guides/compressdevs/index.rst | 1 +
> doc/guides/compressdevs/zlib.rst | 69
> +++++++++++++++++++++++++++++++
> 4 files changed, 83 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ca27c6f..7e3c450 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -875,6 +875,8 @@ F: drivers/common/qat/ ZLIB
> M: Sunila Sahu <sunila.sahu@caviumnetworks.com>
> F: drivers/compress/zlib/
> +F: doc/guides/compressdevs/zlib.rst
> +F: doc/guides/compressdevs/features/zlib.ini
>
> Eventdev Drivers
> ----------------
> diff --git a/doc/guides/compressdevs/features/zlib.ini
> b/doc/guides/compressdevs/features/zlib.ini
> new file mode 100644
> index 0000000..c794643
> --- /dev/null
> +++ b/doc/guides/compressdevs/features/zlib.ini
> @@ -0,0 +1,11 @@
> +;
> +; Refer to default.ini for the full list of available PMD features.
> +;
> +; Supported features of 'ZLIB' compression driver.
> +;
> +[Features]
> +Pass-through = Y
> +Deflate = Y
> +Fixed = Y
> +Dynamic = Y
> +OOP SGL In SGL Out = Y
I assume that you support also "OOP SGL In LB Out" and "OOP LB In SGL Out", right?
^ permalink raw reply
* [PATCH 1/2] Add sw2_sw4 voltage table to cpcap regulator.
From: Peter Geis @ 2018-07-23 17:58 UTC (permalink / raw)
To: lgirdwood, broonie
Cc: robh+dt, mark.rutland, linux-kernel, devicetree, linux-tegra
SW2 and SW4 use a shared table to provide voltage to the cpu core and
devices on Tegra hardware.
Added this table to the cpcap regulator driver as the first step to
supporting this device on Tegra.
Signed-off-by: Peter Geis <pgwipeout@gmail.com>
---
drivers/regulator/cpcap-regulator.c | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/drivers/regulator/cpcap-regulator.c
b/drivers/regulator/cpcap-regulator.c
index bd910fe123d9..c0b1e04bd90f 100644
--- a/drivers/regulator/cpcap-regulator.c
+++ b/drivers/regulator/cpcap-regulator.c
@@ -271,6 +271,29 @@ static struct regulator_ops cpcap_regulator_ops = {
};
static const unsigned int unknown_val_tbl[] = { 0, };
+static const unsigned int sw2_sw4_val_tbl[] = { 612500, 625000, 637500,
+ 650000, 662500, 675000,
+ 687500, 700000, 712500,
+ 725000, 737500, 750000,
+ 762500, 775000, 787500,
+ 800000, 812500, 825000,
+ 837500, 850000, 862500,
+ 875000, 887500, 900000,
+ 912500, 925000, 937500,
+ 950000, 962500, 975000,
+ 987500, 1000000, 1012500,
+ 1025000, 1037500, 1050000,
+ 1062500, 1075000, 1087500,
+ 1100000, 1112500, 1125000,
+ 1137500, 1150000, 1162500,
+ 1175000, 1187500, 1200000,
+ 1212500, 1225000, 1237500,
+ 1250000, 1262500, 1275000,
+ 1287500, 1300000, 1312500,
+ 1325000, 1337500, 1350000,
+ 1362500, 1375000, 1387500,
+ 1400000, 1412500, 1425000,
+ 1437500, 1450000, 1462500, };
static const unsigned int sw5_val_tbl[] = { 0, 5050000, };
static const unsigned int vcam_val_tbl[] = { 2600000, 2700000, 2800000,
2900000, };
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v2 0/4] iio: vcnl4000: add support for vcnl4200
From: Tomas Novotny @ 2018-07-23 17:58 UTC (permalink / raw)
To: Jonathan Cameron
Cc: linux-iio, Hartmut Knaack, Lars-Peter Clausen,
Peter Meerwald-Stadler
In-Reply-To: <20180721182526.6d29a6d9@archlinux>
Hi Jonathan,
On Sat, 21 Jul 2018 18:25:26 +0100
Jonathan Cameron <jic23@kernel.org> wrote:
> On Tue, 17 Jul 2018 18:46:51 +0200
> Tomas Novotny <tomas@novotny.cz> wrote:
>
> > This is the second iteration of vcnl4200 support. The first one was posted
> > on February, sorry for the long delay. I've implemented all notes from
> > reviews (thanks to Peter and Jonathan) and nothing more.
> >
> > Changes in v2:
> > - reading light and proximity values for vcnl4200 is blocking (if you
> > request new value too early)
> > - patches 2 and 3 were added; original patch 2 is now patch 4
> > - vcnl4010 id is handled (patch 2)
> > - warn user on incorrect usage of vcnl40{0,1}0 id (patch 3)
> > - minor stuff (add parenthesis, switch instead of if, rename sensors to
> > channels, fix return)
> >
> > Please note that I'm not sure if it is still good idea to have same driver
> > for vcnl4000 and vcnl4200. The amount of different parts in v2 is even
> > bigger. Just see below for differences and add the blocking read which is
> > added in v2 for vcnl4200.
>
> Definitely marginal. My view is it's your choice as the person doing
> the work! Which would you prefer?
Well, I was thinking about different driver in the first place. But the reason
was quite selfish (and not the technical one), as I'm interested only in
vcnl4200. But I've seen general attitude to combine similar drivers so I've
tried that way and I'm fine with the result. The only ugly part are some chip
specific things in a shared data structure.
> I'm pretty happy with these patches if you want to go this way, but
> given I assume you might add the support for other features, if you
> think that is going to get even worse, then now is the time to make
> the decision to not have a unified driver.
I will probably add some settings, but this should be handled easily. I don't
see anything problematic in the future (well, maybe interrupts or
thresholds?), as both variants are more or less simple light and proximity
chips.
> Sadly it might be a case of doing a 'hatchet' job on the code to
> make a separate driver and see what it looks like. If it's really
> short and clean (which it probably is) then go with separate drivers.
The separate vcnl4200 would be indeed short and clean. The structure and
size would be very similar to current vcnl4000.
Anyway, I don't have enough experience to judge what is better. I'm ok to do
any variant.
Thanks for the review,
Tomas
> Jonathan
>
> >
> > Cover letter from v1:
> >
> > VCNL4200 is another proximity and ambient light sensor from Vishay. I'm
> > adding support for that sensor to vcnl4000 driver, which currently supports
> > VCNL4000/10/20.
> >
> > The VCNL4200 is a bit different from VCNL4000/10/20. Common things are:
> > - integrated proximity and ambient light sensor
> > - SMBus compatible I2C interface
> > - Vishay VCNL4xxx series...
> >
> > Different things are:
> > - totally different register map
> > - 8-bit vs. 16-bit registers. The 16-bit values are in two 8-bit registers
> > on VCNL4000. 16-bit value is in one register on VCNL4200.
> > - VCNL4000 has flags when the measurement is finished
> >
> > The first patch generalizes the driver to support differencies. The second
> > patch adds the support for VCNL4200.
> >
> > It is tested on VCNL4020 and VCNL4200.
> >
> > Tomas Novotny (4):
> > iio: vcnl4000: make the driver extendable
> > iio: vcnl4000: add VCNL4010 device id
> > iio: vcnl4000: warn on incorrectly specified device id
> > iio: vcnl4000: add support for VCNL4200
> >
> > drivers/iio/light/Kconfig | 5 +-
> > drivers/iio/light/vcnl4000.c | 219 ++++++++++++++++++++++++++++++++++++++-----
> > 2 files changed, 196 insertions(+), 28 deletions(-)
> >
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH 0/2 V1] Add support for cpcap regulators on Tegra devices.
From: Peter Geis @ 2018-07-23 17:58 UTC (permalink / raw)
To: lgirdwood, broonie
Cc: robh+dt, mark.rutland, linux-kernel, devicetree, linux-tegra
Good Afternoon,
I am re-sending the whole patch set due to my error of accidentally
converting the tabulation to spaces.
The CPCAP regulator driver can support various devices, but currently
only supports Omap4 devices.
Adds the sw2 and sw4 voltage tables, which power the Tegra core, and a
DT match for the Tegra device.
Tested on the Motorola Xoom MZ602.
v1:
Fix conversion of tabulation to spaces.
Peter Geis (2):
Add sw2_sw4 voltage table to cpcap regulator.
Add support for CPCAP regulators on Tegra devices.
.../bindings/regulator/cpcap-regulator.txt | 1 +
drivers/regulator/cpcap-regulator.c | 103 ++++++++++++++++++
2 files changed, 104 insertions(+)
--
2.17.1
^ permalink raw reply
* Re: Hash algorithm analysis
From: Stefan Beller @ 2018-07-23 17:57 UTC (permalink / raw)
To: demerphq
Cc: brian m. carlson, Johannes Schindelin, Jonathan Nieder, git,
Linus Torvalds, Adam Langley, keccak
In-Reply-To: <CANgJU+X39NoEoMyLu+FX38=x19LrRqatz_dUpUAc+WFV+Uw+=A@mail.gmail.com>
On Mon, Jul 23, 2018 at 5:41 AM demerphq <demerphq@gmail.com> wrote:
>
> On Sun, 22 Jul 2018 at 01:59, brian m. carlson
> <sandals@crustytoothpaste.net> wrote:
> > I will admit that I don't love making this decision by myself, because
> > right now, whatever I pick, somebody is going to be unhappy. I want to
> > state, unambiguously, that I'm trying to make a decision that is in the
> > interests of the Git Project, the community, and our users.
> >
> > I'm happy to wait a few more days to see if a consensus develops; if so,
> > I'll follow it. If we haven't come to one by, say, Wednesday, I'll make
> > a decision and write my patches accordingly. The community is free, as
> > always, to reject my patches if taking them is not in the interest of
> > the project.
>
> Hi Brian.
>
> I do not envy you this decision.
>
> Personally I would aim towards pushing this decision out to the git
> user base and facilitating things so we can choose whatever hash
> function (and config) we wish, including ones not invented yet.
By Git user base you actually mean millions of people?
(And they'll have different opinions and needs)
One of the goals of the hash transition is to pick a hash function
such that git repositories are compatible.
If users were to pick their own hashes, we would need to not just give
a SHA-1 -> <newhash> transition plan, but we'd have to make sure the
full matrix of possible hashes is interchangeable as we have no idea
of what the user would think of "safer". For example one server operator
might decide to settle on SHA2 and another would settle on blake2,
whereas a user that uses both servers as remotes settles with k12.
Then there would be a whole lot of conversion going on (you cannot talk
natively to a remote with a different hash; checking pgp signatures is
also harder as you have an abstraction layer in between).
I would rather just have the discussion now and then provide only one
conversion tool which might be easy to adapt, but after the majority
converted, it is rather left to bitrot instead of needing to support ongoing
conversions.
On the other hand, even if we'd provide a "different hashes are fine"
solution, I would think the network effect would make sure that eventually
most people end up with one hash.
One example of using different hashes successfully are transports,
like TLS, SSH. The difference there is that it is a point-to-point communication
whereas a git repository needs to be read by many parties involved; also
a communication over TLS/SSH is ephemeral unlike objects in Git.
> Failing that I would aim towards a hashing strategy which has the most
> flexibility. Keccak for instance has the interesting property that its
> security level is tunable, and that it can produce aribitrarily long
> hashes. Leaving aside other concerns raised elsewhere in this thread,
> these two features alone seem to make it a superior choice for an
> initial implementation. You can find bugs by selecting unusual hash
> sizes, including very long ones, and you can provide ways to tune the
> function to peoples security and speed preferences. Someone really
> paranoid can specify an unusually large round count and a very long
> hash.
I do not object to this in theory, but I would rather not want to burden
the need to write code for this on the community.
> I am not a cryptographer.
Same here. My personal preference would be blake2b
as that is the fastest IIRC.
Re-reading brians initial mail, I think we should settle on
SHA-256, as that is a conservative choice for security and
the winner in HW accelerated setups, and not to shabby in
a software implementation; it is also widely available.
Stefan
^ permalink raw reply
* Re: [PATCH] NTB: fix debugfs_simple_attr.cocci warnings
From: Logan Gunthorpe @ 2018-07-23 17:57 UTC (permalink / raw)
To: Julia Lawall
Cc: Jon Mason, Dave Jiang, Allen Hubbe, linux-ntb, linux-kernel,
kbuild-all
In-Reply-To: <alpine.DEB.2.20.1807210845090.2381@hadrien>
On 21/07/18 12:47 AM, Julia Lawall wrote:
> From: kbuild test robot <fengguang.wu@intel.com>
>
> Use DEFINE_DEBUGFS_ATTRIBUTE rather than DEFINE_SIMPLE_ATTRIBUTE
> for debugfs files.
>
> Rationale: DEFINE_SIMPLE_ATTRIBUTE + debugfs_create_file()
> imposes some significant overhead as compared to
> DEFINE_DEBUGFS_ATTRIBUTE + debugfs_create_file_unsafe().
>
> Generated by: scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci
>
> Fixes: c75153197d20 ("NTB: Introduce NTB MSI Test Client")
> Signed-off-by: kbuild test robot <fengguang.wu@intel.com>
> Signed-off-by: Julia Lawall <julia.lawall@lip6.fr>
> ---
>
> I don't know much about this issue, beyondwhat is explained by the
> semantic patch. Please check if the changes can be relevant.
Oops, this work wasn't meant for public consumption yet. Everyone
pretend you didn't see that ;). I must have pushed it to my repo that
kbuild tests by accident.
Though, I'm glad to have learned about the more efficient use of debugfs
attributes.
Logan
^ permalink raw reply
* Re: [PATCH 1/2] Add sw2_sw4 voltage table to cpcap regulator.
From: Peter Geis @ 2018-07-23 17:57 UTC (permalink / raw)
To: Mark Brown
Cc: lgirdwood, robh+dt, mark.rutland, linux-kernel, devicetree,
linux-tegra
In-Reply-To: <20180723170157.GD13981@sirena.org.uk>
On 07/23/2018 01:01 PM, Mark Brown wrote:
> On Fri, Jul 20, 2018 at 08:43:49PM -0400, Peter Geis wrote:
>> SW2 and SW4 use a shared table to provide voltage to the cpu core and
>> devices on Tegra hardware.
>> Added this table to the cpcap regulator driver as the first step to
>> supporting this device on Tegra.
>
> This fails to apply with:
>
> Applying: Add sw2_sw4 voltage table to cpcap regulator.
> .git/rebase-apply/patch:37: trailing whitespace.
> 1437500, 1450000,
> error: corrupt patch at line 38
> Patch failed at 0001 Add sw2_sw4 voltage table to cpcap regulator.
>
> Please check and resend.
>
Apologies, I accidentally converted all of the tabs to spaces.
Re-sending both patches with tabulation intact.
^ permalink raw reply
* Re: [PATCH net-next 0/5] net/smc: patches 2018-07-23
From: David Miller @ 2018-07-23 17:57 UTC (permalink / raw)
To: ubraun; +Cc: netdev, linux-s390, schwidefsky, heiko.carstens, raspl,
linux-kernel
In-Reply-To: <20180723115312.54694-1-ubraun@linux.ibm.com>
From: Ursula Braun <ubraun@linux.ibm.com>
Date: Mon, 23 Jul 2018 13:53:07 +0200
> here are some small patches for SMC: Just the first patch contains a
> functional change. It allows to differ between the modes SMCR and SMCD
> on s390 when monitoring SMC sockets. The remaining patches are cleanups
> without functional changes.
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH v4 net-next 3/3] rds: Extend RDS API for IPv6 support
From: Santosh Shilimkar @ 2018-07-23 16:55 UTC (permalink / raw)
To: Ka-Cheong Poon, netdev; +Cc: davem, rds-devel, sowmini.varadhan
In-Reply-To: <98e6f366f2c9cca7ac25f535070a336d633d3d5a.1532318752.git.ka-cheong.poon@oracle.com>
On 7/23/2018 7:16 AM, Ka-Cheong Poon wrote:
> There are many data structures (RDS socket options) used by RDS apps
> which use a 32 bit integer to store IP address. To support IPv6,
> struct in6_addr needs to be used. To ensure backward compatibility, a
> new data structure is introduced for each of those data structures
> which use a 32 bit integer to represent an IP address. And new socket
> options are introduced to use those new structures. This means that
> existing apps should work without a problem with the new RDS module.
> For apps which want to use IPv6, those new data structures and socket
> options can be used. IPv4 mapped address is used to represent IPv4
> address in the new data structures.
>
> v4: Revert changes to SO_RDS_TRANSPORT
>
> Signed-off-by: Ka-Cheong Poon <ka-cheong.poon@oracle.com>
> ---
Looks good to me now. Thanks !!
Acked-by: Santosh Shilimkar <sanstosh.shilimkar@oracle.com>
^ permalink raw reply
* Re: [PATCH v4 net-next 2/3] rds: Enable RDS IPv6 support
From: Santosh Shilimkar @ 2018-07-23 16:55 UTC (permalink / raw)
To: Ka-Cheong Poon, netdev; +Cc: davem, rds-devel, sowmini.varadhan
In-Reply-To: <4dc7ee44840f6166cec8847aefc2bc51e072a7ac.1532318752.git.ka-cheong.poon@oracle.com>
On 7/23/2018 7:16 AM, Ka-Cheong Poon wrote:
> This patch enables RDS to use IPv6 addresses. For RDS/TCP, the
> listener is now an IPv6 endpoint which accepts both IPv4 and IPv6
> connection requests. RDS/RDMA/IB uses a private data (struct
> rds_ib_connect_private) exchange between endpoints at RDS connection
> establishment time to support RDMA. This private data exchange uses a
> 32 bit integer to represent an IP address. This needs to be changed in
> order to support IPv6. A new private data struct
> rds6_ib_connect_private is introduced to handle this. To ensure
> backward compatibility, an IPv6 capable RDS stack uses another RDMA
> listener port (RDS_CM_PORT) to accept IPv6 connection. And it
> continues to use the original RDS_PORT for IPv4 RDS connections. When
> it needs to communicate with an IPv6 peer, it uses the RDS_CM_PORT to
> send the connection set up request.
>
> v4: Changed port history comments in rds.h (Sowmini Varadhan).
>
> v3: Added support to set up IPv4 connection using mapped address
> (David Miller).
> Added support to set up connection between link local and non-link
> addresses.
> Various review comments from Santosh Shilimkar and Sowmini Varadhan.
>
> v2: Fixed bound and peer address scope mismatched issue.
> Added back rds_connect() IPv6 changes.
>
> Signed-off-by: Ka-Cheong Poon <ka-cheong.poon@oracle.com>
> ---
Looks good to me now. Thanks !!
Acked-by: Santosh Shilimkar <sanstosh.shilimkar@oracle.com>
^ permalink raw reply
* Re: [PATCH v4 net-next 1/3] rds: Changing IP address internal representation to struct in6_addr
From: Santosh Shilimkar @ 2018-07-23 16:54 UTC (permalink / raw)
To: Ka-Cheong Poon, netdev; +Cc: davem, rds-devel, sowmini.varadhan
In-Reply-To: <fb4069712ff1eca2988a002defa5d1b917f6853b.1532318752.git.ka-cheong.poon@oracle.com>
On 7/23/2018 7:16 AM, Ka-Cheong Poon wrote:
> This patch changes the internal representation of an IP address to use
> struct in6_addr. IPv4 address is stored as an IPv4 mapped address.
> All the functions which take an IP address as argument are also
> changed to use struct in6_addr. But RDS socket layer is not modified
> such that it still does not accept IPv6 address from an application.
> And RDS layer does not accept nor initiate IPv6 connections.
>
> v2: Fixed sparse warnings.
>
> Signed-off-by: Ka-Cheong Poon <ka-cheong.poon@oracle.com>
> ---
Looks good to me now. Thanks !!
Acked-by: Santosh Shilimkar <sanstosh.shilimkar@oracle.com>
^ permalink raw reply
* Re: [PATCH 16/16] media: imx: add mem2mem device
From: Steve Longerbeam @ 2018-07-23 16:54 UTC (permalink / raw)
To: Philipp Zabel, Steve Longerbeam, linux-media; +Cc: kernel
In-Reply-To: <1532331117.3501.2.camel@pengutronix.de>
On 07/23/2018 12:31 AM, Philipp Zabel wrote:
>>>
>>> ipu_image_convert_adjust tries to adjust both input and output image at
>>> the same time, here we just have the format of either input or output
>>> image. Do you suggest to split this function into an input and an output
>>> version?
>> See b4362162c0 ("media: imx: mem2mem: Use ipu_image_convert_adjust
>> in try format")
> Alright, this looks fine to me. I was worried about inter-format
> limitations, but the only one seems to be the output size lower bound to
> 1/4 of the input size. Should S_FMT(OUT) also update the capture format
> if adjustments were made to keep a consistent state?
That's a good question, I don't know if the mem2mem API allows for
that, but if it does we should do that for consistent state as you said.
In b4362162c0, the current capture format is used to adjust output
format during S_FMT(OUT) but any capture format changes are
dropped, and vice-versa.
Steve
^ permalink raw reply
* [PATCH] fetch-pack: mark die strings for translation
From: Brandon Williams @ 2018-07-23 17:56 UTC (permalink / raw)
To: git; +Cc: Brandon Williams
In-Reply-To: <CACsJy8CJG5RCL40vCbNnQMHmtjQmch9qntxeh_Pt6ZUfnRN9uA@mail.gmail.com>
Signed-off-by: Brandon Williams <bmwill@google.com>
---
fetch-pack.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/fetch-pack.c b/fetch-pack.c
index 0b4a9f288f..51abee6181 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -1245,13 +1245,13 @@ static int process_section_header(struct packet_reader *reader,
int ret;
if (packet_reader_peek(reader) != PACKET_READ_NORMAL)
- die("error reading section header '%s'", section);
+ die(_("error reading section header '%s'"), section);
ret = !strcmp(reader->line, section);
if (!peek) {
if (!ret)
- die("expected '%s', received '%s'",
+ die(_("expected '%s', received '%s'"),
section, reader->line);
packet_reader_read(reader);
}
@@ -1289,12 +1289,12 @@ static int process_acks(struct packet_reader *reader, struct oidset *common)
continue;
}
- die("unexpected acknowledgment line: '%s'", reader->line);
+ die(_("unexpected acknowledgment line: '%s'"), reader->line);
}
if (reader->status != PACKET_READ_FLUSH &&
reader->status != PACKET_READ_DELIM)
- die("error processing acks: %d", reader->status);
+ die(_("error processing acks: %d"), reader->status);
/* return 0 if no common, 1 if there are common, or 2 if ready */
return received_ready ? 2 : (received_ack ? 1 : 0);
@@ -1331,7 +1331,7 @@ static void receive_shallow_info(struct fetch_pack_args *args,
if (reader->status != PACKET_READ_FLUSH &&
reader->status != PACKET_READ_DELIM)
- die("error processing shallow info: %d", reader->status);
+ die(_("error processing shallow info: %d"), reader->status);
setup_alternate_shallow(&shallow_lock, &alternate_shallow_file, NULL);
args->deepen = 1;
@@ -1346,7 +1346,7 @@ static void receive_wanted_refs(struct packet_reader *reader, struct ref *refs)
struct ref *r = NULL;
if (parse_oid_hex(reader->line, &oid, &end) || *end++ != ' ')
- die("expected wanted-ref, got '%s'", reader->line);
+ die(_("expected wanted-ref, got '%s'"), reader->line);
for (r = refs; r; r = r->next) {
if (!strcmp(end, r->name)) {
@@ -1356,11 +1356,11 @@ static void receive_wanted_refs(struct packet_reader *reader, struct ref *refs)
}
if (!r)
- die("unexpected wanted-ref: '%s'", reader->line);
+ die(_("unexpected wanted-ref: '%s'"), reader->line);
}
if (reader->status != PACKET_READ_DELIM)
- die("error processing wanted refs: %d", reader->status);
+ die(_("error processing wanted refs: %d"), reader->status);
}
enum fetch_state {
--
2.18.0.233.g985f88cf7e-goog
^ permalink raw reply related
* HID: intel_ish-hid: tx_buf memory leak on probe/remove
From: Anton Vasilyev @ 2018-07-23 17:56 UTC (permalink / raw)
To: Srinivas Pandruvada
Cc: Jiri Kosina, Benjamin Tissoires, Even Xu, linux-input,
linux-kernel, ldv-project, Anton Vasilyev
ish_dev_init() allocates 512*176 bytes memory for tx_buf and stores it at
&dev->wr_free_list_head.link list on ish_probe().
But there is no deallocation of this memory in ish_remove() and in
ish_probe()
error path.
So current intel-ish-ipc provides 88 KB memory leak for each probe/release.
I have two ideas 1) to replace kzalloc allocation by devm_kzalloc,
or 2) release memory stored at &dev->wr_free_list_head.link list (and
may be at
&dev->wr_processing_list_head.link) in all driver exits.
But I do not know which way is preferable for this case.
Found by Linux Driver Verification project (linuxtesting.org).
--
Anton Vasilyev
Linux Verification Center, ISPRAS
web: http://linuxtesting.org
e-mail: vasilyev@ispras.ru
^ permalink raw reply
* Re: [PATCH v10 4/7] Bluetooth: hci_qca: Add wrapper functions for setting UART speed
From: Matthias Kaehlcke @ 2018-07-23 17:56 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-5-bgodavar@codeaurora.org>
On Fri, Jul 20, 2018 at 07:02:40PM +0530, Balakrishna Godavarthi wrote:
> In function qca_setup, we set initial and operating speeds for Qualcomm
> Bluetooth SoC's. This block of code is common across different
> Qualcomm Bluetooth SoC's. Instead of duplicating the code, created
> a wrapper function to set the speeds. So that future coming SoC's
> can use these wrapper functions to set speeds.
>
> Signed-off-by: Balakrishna Godavarthi <bgodavar@codeaurora.org>
> Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
> ---
> drivers/bluetooth/hci_qca.c | 93 ++++++++++++++++++++++++++++---------
> 1 file changed, 70 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
> index 5f1c0a8fd5cd..5f8a74d65bec 100644
> --- a/drivers/bluetooth/hci_qca.c
> +++ b/drivers/bluetooth/hci_qca.c
> @@ -119,6 +119,11 @@ struct qca_data {
> u64 votes_off;
> };
>
> +enum qca_speed_type {
> + QCA_INIT_SPEED = 1,
> + QCA_OPER_SPEED
> +};
> +
> struct qca_serdev {
> struct hci_uart serdev_hu;
> struct gpio_desc *bt_en;
> @@ -923,6 +928,61 @@ static inline void host_set_baudrate(struct hci_uart *hu, unsigned int speed)
> hci_uart_set_baudrate(hu, speed);
> }
>
> +static unsigned int qca_get_speed(struct hci_uart *hu,
> + enum qca_speed_type speed_type)
> +{
> + unsigned int speed = 0;
> +
> + if (speed_type == QCA_INIT_SPEED) {
> + if (hu->init_speed)
> + speed = hu->init_speed;
> + else if (hu->proto->init_speed)
> + speed = hu->proto->init_speed;
> + } else {
> + if (hu->oper_speed)
> + speed = hu->oper_speed;
> + else if (hu->proto->oper_speed)
> + speed = hu->proto->oper_speed;
> + }
> +
> + return speed;
> +}
> +
> +static int qca_check_speeds(struct hci_uart *hu)
> +{
> + if (!qca_get_speed(hu, QCA_INIT_SPEED) ||
> + !qca_get_speed(hu, QCA_OPER_SPEED))
> + return -EINVAL;
You changed this from:
/* One or the other speeds should be non zero. */
if (!qca_get_speed(hu, QCA_INIT_SPEED) &&
!qca_get_speed(hu, QCA_OPER_SPEED))
return -EINVAL;
There is no entry in the change log. What is the reason for this
change?
^ 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.