* [Qemu-devel] [PATCH 91/99] migration/block-dirty-bitmap: fix dirty_bitmap_load
From: Michael Roth @ 2018-07-23 20:17 UTC (permalink / raw)
To: qemu-devel
Cc: qemu-stable, Vladimir Sementsov-Ogievskiy,
Dr . David Alan Gilbert
In-Reply-To: <20180723201748.25573-1-mdroth@linux.vnet.ibm.com>
From: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
dirty_bitmap_load_header return code is obtained but not handled. Fix
this.
Bug was introduced in b35ebdf076d697bc
"migration: add postcopy migration of dirty bitmaps" with the whole
function.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20180530112424.204835-1-vsementsov@virtuozzo.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: John Snow <jsnow@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
(cherry picked from commit a36f6ff46f115672cf86d0e1e7cdb1c2fa4d304b)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
---
migration/block-dirty-bitmap.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/migration/block-dirty-bitmap.c b/migration/block-dirty-bitmap.c
index 8819aabe3a..2c541c985d 100644
--- a/migration/block-dirty-bitmap.c
+++ b/migration/block-dirty-bitmap.c
@@ -672,6 +672,9 @@ static int dirty_bitmap_load(QEMUFile *f, void *opaque, int version_id)
do {
ret = dirty_bitmap_load_header(f, &s);
+ if (ret < 0) {
+ return ret;
+ }
if (s.flags & DIRTY_BITMAP_MIG_FLAG_START) {
ret = dirty_bitmap_load_start(f, &s);
--
2.17.1
^ permalink raw reply related
* [Qemu-devel] [PATCH 08/99] target/ppc: always set PPC_MEM_TLBIE in pre 2.8 migration hack
From: Michael Roth @ 2018-07-23 20:16 UTC (permalink / raw)
To: qemu-devel; +Cc: qemu-stable, Greg Kurz, David Gibson
In-Reply-To: <20180723201748.25573-1-mdroth@linux.vnet.ibm.com>
From: Greg Kurz <groug@kaod.org>
The pseries-2.7 and older machine types require CPUPPCState::insns_flags
to be strictly equal between source and destination. This checking is
abusive and breaks migration of KVM guests when the host CPU models
are different, even if they are compatible enough to allow the guest
to run transparently. This buggy behaviour was fixed for pseries-2.8
and we added some hacks to allow backward migration of older machine
types. These hacks assume that the CPU belongs to the POWER8 family,
which was true for most KVM based setup we cared about at the time.
But now POWER9 systems are coming, and backward migration of pre 2.8
guests running in POWER8 architected mode from a POWER9 host to a
POWER8 host is broken:
qemu-system-ppc64: error while loading state for instance 0x0 of device
'cpu'
qemu-system-ppc64: load of migration failed: Invalid argument
This happens because POWER9 doesn't set PPC_MEM_TLBIE in insns_flags,
while POWER8 does. Let's force PPC_MEM_TLBIE in the migration hack to
fix the issue. This is an acceptable hack because these old machine
types only support CPU models that do set PPC_MEM_TLBIE.
Signed-off-by: Greg Kurz <groug@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
(cherry picked from commit bce009645b9f1d59195518e35747c8ea30f985f7)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
---
target/ppc/machine.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/target/ppc/machine.c b/target/ppc/machine.c
index 0634cdb295..cf44b97ced 100644
--- a/target/ppc/machine.c
+++ b/target/ppc/machine.c
@@ -200,6 +200,11 @@ static int cpu_pre_save(void *opaque)
;
cpu->mig_msr_mask = env->msr_mask & ~metamask;
cpu->mig_insns_flags = env->insns_flags & insns_compat_mask;
+ /* CPU models supported by old machines all have PPC_MEM_TLBIE,
+ * so we set it unconditionally to allow backward migration from
+ * a POWER9 host to a POWER8 host.
+ */
+ cpu->mig_insns_flags |= PPC_MEM_TLBIE;
cpu->mig_insns_flags2 = env->insns_flags2 & insns_compat_mask2;
cpu->mig_nb_BATs = env->nb_BATs;
}
--
2.17.1
^ permalink raw reply related
* [Qemu-devel] [PATCH 92/99] tcg: Reduce max TB opcode count
From: Michael Roth @ 2018-07-23 20:17 UTC (permalink / raw)
To: qemu-devel; +Cc: qemu-stable, Richard Henderson
In-Reply-To: <20180723201748.25573-1-mdroth@linux.vnet.ibm.com>
From: Richard Henderson <richard.henderson@linaro.org>
Also, assert that we don't overflow any of two different offsets into
the TB. Both unwind and goto_tb both record a uint16_t for later use.
This fixes an arm-softmmu test case utilizing NEON in which there is
a TB generated that runs to 7800 opcodes, and compiles to 96k on an
x86_64 host. This overflows the 16-bit offset in which we record the
goto_tb reset offset. Because of that overflow, we install a jump
destination that goes to neverland. Boom.
With this reduced op count, the same TB compiles to about 48k for
aarch64, ppc64le, and x86_64 hosts, and neither assertion fires.
Cc: qemu-stable@nongnu.org
Reported-by: "Jason A. Donenfeld" <Jason@zx2c4.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
(cherry picked from commit 9f754620651d3432114f4bb89c7f12cbea814b3e)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
---
tcg/aarch64/tcg-target.inc.c | 2 +-
tcg/arm/tcg-target.inc.c | 2 +-
tcg/i386/tcg-target.inc.c | 2 +-
tcg/mips/tcg-target.inc.c | 2 +-
tcg/ppc/tcg-target.inc.c | 4 ++--
tcg/s390/tcg-target.inc.c | 2 +-
tcg/sparc/tcg-target.inc.c | 4 ++--
tcg/tcg.c | 13 ++++++++++++-
tcg/tcg.h | 6 ++++--
tcg/tci/tcg-target.inc.c | 2 +-
10 files changed, 26 insertions(+), 13 deletions(-)
diff --git a/tcg/aarch64/tcg-target.inc.c b/tcg/aarch64/tcg-target.inc.c
index be3192078d..4562d36d1b 100644
--- a/tcg/aarch64/tcg-target.inc.c
+++ b/tcg/aarch64/tcg-target.inc.c
@@ -1733,7 +1733,7 @@ static void tcg_out_op(TCGContext *s, TCGOpcode opc,
tcg_out_insn(s, 3305, LDR, offset, TCG_REG_TMP);
}
tcg_out_insn(s, 3207, BR, TCG_REG_TMP);
- s->tb_jmp_reset_offset[a0] = tcg_current_code_size(s);
+ set_jmp_reset_offset(s, a0);
break;
case INDEX_op_goto_ptr:
diff --git a/tcg/arm/tcg-target.inc.c b/tcg/arm/tcg-target.inc.c
index 56a32a470f..e1fbf465cb 100644
--- a/tcg/arm/tcg-target.inc.c
+++ b/tcg/arm/tcg-target.inc.c
@@ -1822,7 +1822,7 @@ static inline void tcg_out_op(TCGContext *s, TCGOpcode opc,
tcg_out_movi32(s, COND_AL, base, ptr - dil);
}
tcg_out_ld32_12(s, COND_AL, TCG_REG_PC, base, dil);
- s->tb_jmp_reset_offset[args[0]] = tcg_current_code_size(s);
+ set_jmp_reset_offset(s, args[0]);
}
break;
case INDEX_op_goto_ptr:
diff --git a/tcg/i386/tcg-target.inc.c b/tcg/i386/tcg-target.inc.c
index 5357909fff..ccde8801a5 100644
--- a/tcg/i386/tcg-target.inc.c
+++ b/tcg/i386/tcg-target.inc.c
@@ -2245,7 +2245,7 @@ static inline void tcg_out_op(TCGContext *s, TCGOpcode opc,
tcg_out_modrm_offset(s, OPC_GRP5, EXT5_JMPN_Ev, -1,
(intptr_t)(s->tb_jmp_target_addr + a0));
}
- s->tb_jmp_reset_offset[a0] = tcg_current_code_size(s);
+ set_jmp_reset_offset(s, a0);
break;
case INDEX_op_goto_ptr:
/* jmp to the given host address (could be epilogue) */
diff --git a/tcg/mips/tcg-target.inc.c b/tcg/mips/tcg-target.inc.c
index ca5f1d4894..cff525373b 100644
--- a/tcg/mips/tcg-target.inc.c
+++ b/tcg/mips/tcg-target.inc.c
@@ -1744,7 +1744,7 @@ static inline void tcg_out_op(TCGContext *s, TCGOpcode opc,
tcg_out_opc_reg(s, OPC_JR, 0, TCG_TMP0, 0);
}
tcg_out_nop(s);
- s->tb_jmp_reset_offset[a0] = tcg_current_code_size(s);
+ set_jmp_reset_offset(s, a0);
break;
case INDEX_op_goto_ptr:
/* jmp to the given host address (could be epilogue) */
diff --git a/tcg/ppc/tcg-target.inc.c b/tcg/ppc/tcg-target.inc.c
index 86f7de5f7e..c2f729ee8f 100644
--- a/tcg/ppc/tcg-target.inc.c
+++ b/tcg/ppc/tcg-target.inc.c
@@ -2025,10 +2025,10 @@ static void tcg_out_op(TCGContext *s, TCGOpcode opc, const TCGArg *args,
}
tcg_out32(s, MTSPR | RS(TCG_REG_TB) | CTR);
tcg_out32(s, BCCTR | BO_ALWAYS);
- s->tb_jmp_reset_offset[args[0]] = c = tcg_current_code_size(s);
+ set_jmp_reset_offset(s, args[0]);
if (USE_REG_TB) {
/* For the unlinked case, need to reset TCG_REG_TB. */
- c = -c;
+ c = -tcg_current_code_size(s);
assert(c == (int16_t)c);
tcg_out32(s, ADDI | TAI(TCG_REG_TB, TCG_REG_TB, c));
}
diff --git a/tcg/s390/tcg-target.inc.c b/tcg/s390/tcg-target.inc.c
index 9af6dcef05..17c435ade5 100644
--- a/tcg/s390/tcg-target.inc.c
+++ b/tcg/s390/tcg-target.inc.c
@@ -1783,7 +1783,7 @@ static inline void tcg_out_op(TCGContext *s, TCGOpcode opc,
/* and go there */
tcg_out_insn(s, RR, BCR, S390_CC_ALWAYS, TCG_REG_TB);
}
- s->tb_jmp_reset_offset[a0] = tcg_current_code_size(s);
+ set_jmp_reset_offset(s, a0);
/* For the unlinked path of goto_tb, we need to reset
TCG_REG_TB to the beginning of this TB. */
diff --git a/tcg/sparc/tcg-target.inc.c b/tcg/sparc/tcg-target.inc.c
index bc673bd8c6..04bdc3df5e 100644
--- a/tcg/sparc/tcg-target.inc.c
+++ b/tcg/sparc/tcg-target.inc.c
@@ -1388,12 +1388,12 @@ static void tcg_out_op(TCGContext *s, TCGOpcode opc,
tcg_out_arithi(s, TCG_REG_G0, TCG_REG_TB, 0, JMPL);
tcg_out_nop(s);
}
- s->tb_jmp_reset_offset[a0] = c = tcg_current_code_size(s);
+ set_jmp_reset_offset(s, a0);
/* For the unlinked path of goto_tb, we need to reset
TCG_REG_TB to the beginning of this TB. */
if (USE_REG_TB) {
- c = -c;
+ c = -tcg_current_code_size(s);
if (check_fit_i32(c, 13)) {
tcg_out_arithi(s, TCG_REG_TB, TCG_REG_TB, c, ARITH_ADD);
} else {
diff --git a/tcg/tcg.c b/tcg/tcg.c
index 66997cc653..9c1de541d6 100644
--- a/tcg/tcg.c
+++ b/tcg/tcg.c
@@ -293,6 +293,14 @@ TCGLabel *gen_new_label(void)
return l;
}
+static void set_jmp_reset_offset(TCGContext *s, int which)
+{
+ size_t off = tcg_current_code_size(s);
+ s->tb_jmp_reset_offset[which] = off;
+ /* Make sure that we didn't overflow the stored offset. */
+ assert(s->tb_jmp_reset_offset[which] == off);
+}
+
#include "tcg-target.inc.c"
static void tcg_region_bounds(size_t curr_region, void **pstart, void **pend)
@@ -3354,7 +3362,10 @@ int tcg_gen_code(TCGContext *s, TranslationBlock *tb)
break;
case INDEX_op_insn_start:
if (num_insns >= 0) {
- s->gen_insn_end_off[num_insns] = tcg_current_code_size(s);
+ size_t off = tcg_current_code_size(s);
+ s->gen_insn_end_off[num_insns] = off;
+ /* Assert that we do not overflow our stored offset. */
+ assert(s->gen_insn_end_off[num_insns] == off);
}
num_insns++;
for (i = 0; i < TARGET_INSN_START_WORDS; ++i) {
diff --git a/tcg/tcg.h b/tcg/tcg.h
index 17cf764565..755860e50d 100644
--- a/tcg/tcg.h
+++ b/tcg/tcg.h
@@ -848,9 +848,11 @@ static inline bool tcg_op_buf_full(void)
/* This is not a hard limit, it merely stops translation when
* we have produced "enough" opcodes. We want to limit TB size
* such that a RISC host can reasonably use a 16-bit signed
- * branch within the TB.
+ * branch within the TB. We also need to be mindful of the
+ * 16-bit unsigned offsets, TranslationBlock.jmp_reset_offset[]
+ * and TCGContext.gen_insn_end_off[].
*/
- return tcg_ctx->nb_ops >= 8000;
+ return tcg_ctx->nb_ops >= 4000;
}
/* pool based memory allocation */
diff --git a/tcg/tci/tcg-target.inc.c b/tcg/tci/tcg-target.inc.c
index cc949bea85..62ed097254 100644
--- a/tcg/tci/tcg-target.inc.c
+++ b/tcg/tci/tcg-target.inc.c
@@ -574,7 +574,7 @@ static void tcg_out_op(TCGContext *s, TCGOpcode opc, const TCGArg *args,
/* Indirect jump method. */
TODO();
}
- s->tb_jmp_reset_offset[args[0]] = tcg_current_code_size(s);
+ set_jmp_reset_offset(s, args[0]);
break;
case INDEX_op_br:
tci_out_label(s, arg_label(args[0]));
--
2.17.1
^ permalink raw reply related
* [Qemu-devel] [PATCH 94/99] iscsi: Avoid potential for get_status overflow
From: Michael Roth @ 2018-07-23 20:17 UTC (permalink / raw)
To: qemu-devel; +Cc: qemu-stable, Eric Blake
In-Reply-To: <20180723201748.25573-1-mdroth@linux.vnet.ibm.com>
From: Eric Blake <eblake@redhat.com>
Detected by Coverity: Multiplying two 32-bit int and assigning
the result to a 64-bit number is a risk of overflow. Prior to
the conversion to byte-based interfaces, the block layer took
care of ensuring that a status request never exceeded 2G in
the driver; but after that conversion, the block layer expects
drivers to deal with any size request (the driver can always
truncate the request size back down, as long as it makes
progress). So, in the off-chance that someone makes a large
request, we are at the mercy of whether iscsi_get_lba_status_task()
will cap things to at most INT_MAX / iscsilun->block_size when
it populates lbasd->num_blocks; since I could not easily audit
that, it's better to be safe than sorry by just forcing a 64-bit
multiply.
Fixes: 92809c36
CC: qemu-stable@nongnu.org
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20180508212718.1482663-1-eblake@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
(cherry picked from commit 8ee1cef4593a7bda076891470c0620e79333c0d0)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
---
block/iscsi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block/iscsi.c b/block/iscsi.c
index f5aecfc883..871947feae 100644
--- a/block/iscsi.c
+++ b/block/iscsi.c
@@ -732,7 +732,7 @@ retry:
goto out_unlock;
}
- *pnum = lbasd->num_blocks * iscsilun->block_size;
+ *pnum = (int64_t) lbasd->num_blocks * iscsilun->block_size;
if (lbasd->provisioning == SCSI_PROVISIONING_TYPE_DEALLOCATED ||
lbasd->provisioning == SCSI_PROVISIONING_TYPE_ANCHORED) {
--
2.17.1
^ permalink raw reply related
* [Qemu-devel] [PATCH 93/99] nbd/server: Reject 0-length block status request
From: Michael Roth @ 2018-07-23 20:17 UTC (permalink / raw)
To: qemu-devel; +Cc: qemu-stable, Eric Blake
In-Reply-To: <20180723201748.25573-1-mdroth@linux.vnet.ibm.com>
From: Eric Blake <eblake@redhat.com>
The NBD spec says that behavior is unspecified if the client
requests 0 length for block status; but since the structured
reply is documenting as returning a non-zero length, it's
easier to just diagnose this with an EINVAL error than to
figure out what to return.
CC: qemu-stable@nongnu.org
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20180621124937.166549-1-eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
(cherry picked from commit d8b20291cba6aa9bb295885a34f2b5f05d59d1b2)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
---
nbd/server.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/nbd/server.c b/nbd/server.c
index 9e1f227178..493a926e06 100644
--- a/nbd/server.c
+++ b/nbd/server.c
@@ -2007,6 +2007,10 @@ static coroutine_fn int nbd_handle_request(NBDClient *client,
"discard failed", errp);
case NBD_CMD_BLOCK_STATUS:
+ if (!request->len) {
+ return nbd_send_generic_reply(client, request->handle, -EINVAL,
+ "need non-zero length", errp);
+ }
if (client->export_meta.valid && client->export_meta.base_allocation) {
return nbd_co_send_block_status(client, request->handle,
blk_bs(exp->blk), request->from,
--
2.17.1
^ permalink raw reply related
* [Qemu-devel] [PATCH 95/99] virtio-rng: process pending requests on DRIVER_OK
From: Michael Roth @ 2018-07-23 20:17 UTC (permalink / raw)
To: qemu-devel
Cc: qemu-stable, Pankaj Gupta, Stefan Hajnoczi, Michael S . Tsirkin
In-Reply-To: <20180723201748.25573-1-mdroth@linux.vnet.ibm.com>
From: Pankaj Gupta <pagupta@redhat.com>
virtio-rng device causes old guest kernels(2.6.32) to hang on latest qemu.
The driver attempts to read from the virtio-rng device too early in it's
initialization. Qemu detects guest is not ready and returns, resulting in
hang.
To fix handle pending requests when guest is running and driver status is
set to 'VIRTIO_CONFIG_S_DRIVER_OK'.
CC: qemu-stable@nongnu.org
Reported-by: Sergio lopez <slopezpa@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Pankaj Gupta <pagupta@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 5d9c9ea22ab4f3b3ee497523e34b6f4d3281f62d)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
---
hw/virtio/virtio-rng.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/hw/virtio/virtio-rng.c b/hw/virtio/virtio-rng.c
index 289bbcac03..855f1b41d1 100644
--- a/hw/virtio/virtio-rng.c
+++ b/hw/virtio/virtio-rng.c
@@ -156,6 +156,19 @@ static void check_rate_limit(void *opaque)
vrng->activate_timer = true;
}
+static void virtio_rng_set_status(VirtIODevice *vdev, uint8_t status)
+{
+ VirtIORNG *vrng = VIRTIO_RNG(vdev);
+
+ if (!vdev->vm_running) {
+ return;
+ }
+ vdev->status = status;
+
+ /* Something changed, try to process buffers */
+ virtio_rng_process(vrng);
+}
+
static void virtio_rng_device_realize(DeviceState *dev, Error **errp)
{
VirtIODevice *vdev = VIRTIO_DEVICE(dev);
@@ -261,6 +274,7 @@ static void virtio_rng_class_init(ObjectClass *klass, void *data)
vdc->realize = virtio_rng_device_realize;
vdc->unrealize = virtio_rng_device_unrealize;
vdc->get_features = get_features;
+ vdc->set_status = virtio_rng_set_status;
}
static const TypeInfo virtio_rng_info = {
--
2.17.1
^ permalink raw reply related
* [Qemu-devel] [PATCH 96/99] target/ppc: set is_jmp on ppc_tr_breakpoint_check
From: Michael Roth @ 2018-07-23 20:17 UTC (permalink / raw)
To: qemu-devel; +Cc: qemu-stable, Emilio G. Cota, David Gibson
In-Reply-To: <20180723201748.25573-1-mdroth@linux.vnet.ibm.com>
From: "Emilio G. Cota" <cota@braap.org>
The use of GDB breakpoints was broken by b0c2d52 ("target/ppc: convert
to TranslatorOps", 2018-02-16).
Fix it by setting is_jmp, so that we break from the translation loop
as originally intended.
Tested-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reported-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Signed-off-by: Emilio G. Cota <cota@braap.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
(cherry picked from commit 2a8ceefca23bc2aaafe711f8afd7585be3c27064)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
---
target/ppc/translate.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/target/ppc/translate.c b/target/ppc/translate.c
index 3457d29f8e..c535cd76f2 100644
--- a/target/ppc/translate.c
+++ b/target/ppc/translate.c
@@ -7296,6 +7296,7 @@ static bool ppc_tr_breakpoint_check(DisasContextBase *dcbase, CPUState *cs,
DisasContext *ctx = container_of(dcbase, DisasContext, base);
gen_debug_exception(ctx);
+ dcbase->is_jmp = DISAS_NORETURN;
/* The address covered by the breakpoint must be included in
[tb->pc, tb->pc + tb->size) in order to for it to be
properly cleared -- thus we increment the PC here so that
--
2.17.1
^ permalink raw reply related
* [Qemu-devel] [PATCH 97/99] tap: fix memory leak on success to create a tap device
From: Michael Roth @ 2018-07-23 20:17 UTC (permalink / raw)
To: qemu-devel; +Cc: qemu-stable, Yunjian Wang, Jason Wang
In-Reply-To: <20180723201748.25573-1-mdroth@linux.vnet.ibm.com>
From: Yunjian Wang <wangyunjian@huawei.com>
The memory leak on success to create a tap device. And the nfds and
nvhosts may not be the same and need to be processed separately.
Fixes: 07825977 ("tap: fix memory leak on failure to create a multiqueue tap device")
Fixes: 264986e2 ("tap: multiqueue support")
Cc: qemu-stable@nongnu.org
Signed-off-by: Yunjian Wang <wangyunjian@huawei.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit 323e7c117754e4d4ce6b4282d74ad01c99d67714)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
---
net/tap.c | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/net/tap.c b/net/tap.c
index 89c4e19162..e807e0ea2f 100644
--- a/net/tap.c
+++ b/net/tap.c
@@ -805,7 +805,8 @@ int net_init_tap(const Netdev *netdev, const char *name,
} else if (tap->has_fds) {
char **fds;
char **vhost_fds;
- int nfds, nvhosts;
+ int nfds = 0, nvhosts = 0;
+ int ret = 0;
if (tap->has_ifname || tap->has_script || tap->has_downscript ||
tap->has_vnet_hdr || tap->has_helper || tap->has_queues ||
@@ -825,6 +826,7 @@ int net_init_tap(const Netdev *netdev, const char *name,
if (nfds != nvhosts) {
error_setg(errp, "The number of fds passed does not match "
"the number of vhostfds passed");
+ ret = -1;
goto free_fail;
}
}
@@ -833,6 +835,7 @@ int net_init_tap(const Netdev *netdev, const char *name,
fd = monitor_fd_param(cur_mon, fds[i], &err);
if (fd == -1) {
error_propagate(errp, err);
+ ret = -1;
goto free_fail;
}
@@ -843,6 +846,7 @@ int net_init_tap(const Netdev *netdev, const char *name,
} else if (vnet_hdr != tap_probe_vnet_hdr(fd)) {
error_setg(errp,
"vnet_hdr not consistent across given tap fds");
+ ret = -1;
goto free_fail;
}
@@ -852,21 +856,21 @@ int net_init_tap(const Netdev *netdev, const char *name,
vnet_hdr, fd, &err);
if (err) {
error_propagate(errp, err);
+ ret = -1;
goto free_fail;
}
}
- g_free(fds);
- g_free(vhost_fds);
- return 0;
free_fail:
+ for (i = 0; i < nvhosts; i++) {
+ g_free(vhost_fds[i]);
+ }
for (i = 0; i < nfds; i++) {
g_free(fds[i]);
- g_free(vhost_fds[i]);
}
g_free(fds);
g_free(vhost_fds);
- return -1;
+ return ret;
} else if (tap->has_helper) {
if (tap->has_ifname || tap->has_script || tap->has_downscript ||
tap->has_vnet_hdr || tap->has_queues || tap->has_vhostfds) {
--
2.17.1
^ permalink raw reply related
* [Qemu-devel] [PATCH 98/99] qemu-img: avoid overflow of min_sparse parameter
From: Michael Roth @ 2018-07-23 20:17 UTC (permalink / raw)
To: qemu-devel; +Cc: qemu-stable, Peter Lieven, Kevin Wolf
In-Reply-To: <20180723201748.25573-1-mdroth@linux.vnet.ibm.com>
From: Peter Lieven <pl@kamp.de>
the min_sparse convert parameter can overflow (e.g. -S 1024G)
in the conversion from int64_t to int resulting in a negative
min_sparse parameter. Avoid this by limiting the valid parameters
to sane values. In fact anything exceeding the convert buffer size
is also pointless. While at it also forbid values that are non
multiple of 512 to avoid undesired behaviour. For instance, values
between 1 and 511 were legal, but resulted in full allocation.
Cc: qemu-stable@nongnu.org
Signed-off-by: Peter Lieven <pl@kamp.de>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 6360ab278cc1ac3e1235e0755e4cba1f918e6f3c)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
---
qemu-img.c | 16 +++++++++++-----
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/qemu-img.c b/qemu-img.c
index a8e2b53dc6..1a055b4424 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -1912,6 +1912,8 @@ static int convert_do_copy(ImgConvertState *s)
return s->ret;
}
+#define MAX_BUF_SECTORS 32768
+
static int img_convert(int argc, char **argv)
{
int c, bs_i, flags, src_flags = 0;
@@ -2008,8 +2010,12 @@ static int img_convert(int argc, char **argv)
int64_t sval;
sval = cvtnum(optarg);
- if (sval < 0) {
- error_report("Invalid minimum zero buffer size for sparse output specified");
+ if (sval < 0 || sval & (BDRV_SECTOR_SIZE - 1) ||
+ sval / BDRV_SECTOR_SIZE > MAX_BUF_SECTORS) {
+ error_report("Invalid buffer size for sparse output specified. "
+ "Valid sizes are multiples of %llu up to %llu. Select "
+ "0 to disable sparse detection (fully allocates output).",
+ BDRV_SECTOR_SIZE, MAX_BUF_SECTORS * BDRV_SECTOR_SIZE);
goto fail_getopt;
}
@@ -2297,9 +2303,9 @@ static int img_convert(int argc, char **argv)
}
/* increase bufsectors from the default 4096 (2M) if opt_transfer
- * or discard_alignment of the out_bs is greater. Limit to 32768 (16MB)
- * as maximum. */
- s.buf_sectors = MIN(32768,
+ * or discard_alignment of the out_bs is greater. Limit to
+ * MAX_BUF_SECTORS as maximum which is currently 32768 (16MB). */
+ s.buf_sectors = MIN(MAX_BUF_SECTORS,
MAX(s.buf_sectors,
MAX(out_bs->bl.opt_transfer >> BDRV_SECTOR_BITS,
out_bs->bl.pdiscard_alignment >>
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] dd: Invoke one probe retry cycle after every initcall level
From: rishabhb @ 2018-07-23 20:22 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Greg Kroah-Hartman, Linux Kernel Mailing List, ckadabi, tsoni,
Vikram Mulukutla, rjwysocki
In-Reply-To: <CAJZ5v0gWqx5Op-Bbg7bAYALCyBPsc=-+homAYj2Q1qd3WsqmDw@mail.gmail.com>
On 2018-07-23 04:17, Rafael J. Wysocki wrote:
> On Thu, Jul 19, 2018 at 11:24 PM, Rishabh Bhatnagar
> <rishabhb@codeaurora.org> wrote:
>> Drivers that are registered at an initcall level may have to
>> wait until late_init before the probe deferral mechanism can
>> retry their probe functions. It is possible that their
>> dependencies were resolved much earlier, in some cases even
>> before the next initcall level. Invoke one probe retry cycle
>> at every _sync initcall level, allowing these drivers to be
>> probed earlier.
>
> Can you please say something about the actual use case this is
> expected to address?
We have a display driver that depends 3 other devices to be
probed so that it can bring-up the display. Because of dependencies
not being met the deferral mechanism defers the probes for a later time,
even though the dependencies might be met earlier. With this change
display can be brought up much earlier.
>
>> Signed-off-by: Vikram Mulukutla <markivx@codeaurora.org>
>> Signed-off-by: Rishabh Bhatnagar <rishabhb@codeaurora.org>
>> ---
>> drivers/base/dd.c | 33 +++++++++++++++++++++++++++------
>> 1 file changed, 27 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
>> index 1435d72..e6a6821 100644
>> --- a/drivers/base/dd.c
>> +++ b/drivers/base/dd.c
>> @@ -224,23 +224,44 @@ void device_unblock_probing(void)
>> driver_deferred_probe_trigger();
>> }
>>
>> +static void enable_trigger_defer_cycle(void)
>> +{
>> + driver_deferred_probe_enable = true;
>> + driver_deferred_probe_trigger();
>> + /*
>> + * Sort as many dependencies as possible before the next
>> initcall
>> + * level
>> + */
>> + flush_work(&deferred_probe_work);
>> +}
>> +
>> /**
>> * deferred_probe_initcall() - Enable probing of deferred devices
>> *
>> * We don't want to get in the way when the bulk of drivers are
>> getting probed.
>> * Instead, this initcall makes sure that deferred probing is delayed
>> until
>> - * late_initcall time.
>> + * all the registered initcall functions at a particular level are
>> completed.
>> + * This function is invoked at every *_initcall_sync level.
>> */
>> static int deferred_probe_initcall(void)
>> {
>> - driver_deferred_probe_enable = true;
>> - driver_deferred_probe_trigger();
>> - /* Sort as many dependencies as possible before exiting
>> initcalls */
>> - flush_work(&deferred_probe_work);
>> + enable_trigger_defer_cycle();
>> + driver_deferred_probe_enable = false;
>> + return 0;
>> +}
>> +arch_initcall_sync(deferred_probe_initcall);
>> +subsys_initcall_sync(deferred_probe_initcall);
>> +fs_initcall_sync(deferred_probe_initcall);
>> +device_initcall_sync(deferred_probe_initcall);
>> +
>> +static int deferred_probe_enable_fn(void)
>> +{
>> + /* Enable deferred probing for all time */
>> + enable_trigger_defer_cycle();
>> initcalls_done = true;
>> return 0;
>> }
>> -late_initcall(deferred_probe_initcall);
>> +late_initcall(deferred_probe_enable_fn);
>>
>> /**
>> * device_is_bound() - Check if device is bound to a driver
>> --
>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
>> Forum,
>> a Linux Foundation Collaborative Project
^ permalink raw reply
* [igt-dev] ✓ Fi.CI.IGT: success for tests/kms_rotation_crc: Move platform checks to one place for non exhaust fence cases (rev5)
From: Patchwork @ 2018-07-23 20:23 UTC (permalink / raw)
To: Radhakrishna Sripada; +Cc: igt-dev
In-Reply-To: <20180723182545.19461-1-radhakrishna.sripada@intel.com>
== Series Details ==
Series: tests/kms_rotation_crc: Move platform checks to one place for non exhaust fence cases (rev5)
URL : https://patchwork.freedesktop.org/series/40553/
State : success
== Summary ==
= CI Bug Log - changes from IGT_4570_full -> IGTPW_1632_full =
== Summary - WARNING ==
Minor unknown changes coming with IGTPW_1632_full need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in IGTPW_1632_full, 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/40553/revisions/5/mbox/
== Possible new issues ==
Here are the unknown changes that may have been introduced in IGTPW_1632_full:
=== IGT changes ===
==== Warnings ====
igt@gem_exec_schedule@deep-blt:
shard-kbl: PASS -> SKIP
igt@kms_atomic_interruptible@legacy-pageflip:
shard-snb: SKIP -> PASS +1
igt@pm_rc6_residency@rc6-accuracy:
shard-kbl: SKIP -> PASS +1
== Known issues ==
Here are the changes found in IGTPW_1632_full that come from known issues:
=== IGT changes ===
==== Issues hit ====
igt@gem_exec_schedule@pi-ringfull-vebox:
shard-glk: NOTRUN -> FAIL (fdo#103158)
igt@kms_flip@2x-plain-flip-fb-recreate-interruptible:
shard-hsw: PASS -> FAIL (fdo#100368)
shard-glk: PASS -> FAIL (fdo#100368)
igt@kms_flip@flip-vs-expired-vblank:
shard-glk: PASS -> FAIL (fdo#105189)
igt@kms_setmode@basic:
shard-apl: PASS -> FAIL (fdo#99912)
igt@perf_pmu@busy-idle-check-all-vcs0:
shard-snb: PASS -> INCOMPLETE (fdo#105411)
==== Possible fixes ====
igt@gem_mmap_gtt@coherency:
shard-glk: FAIL (fdo#100587) -> SKIP +1
igt@gem_ppgtt@blt-vs-render-ctxn:
shard-kbl: INCOMPLETE (fdo#103665, fdo#106023) -> PASS
igt@kms_flip@plain-flip-ts-check-interruptible:
shard-glk: FAIL (fdo#100368) -> PASS
igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-pwrite:
shard-glk: FAIL (fdo#103167) -> PASS
igt@kms_plane_multiple@atomic-pipe-a-tiling-x:
shard-snb: FAIL (fdo#103166) -> PASS
igt@kms_setmode@basic:
shard-kbl: FAIL (fdo#99912) -> PASS
igt@perf_pmu@multi-client-vcs1:
shard-snb: INCOMPLETE (fdo#105411) -> SKIP
igt@prime_vgem@coherency-gtt:
shard-apl: FAIL (fdo#100587) -> SKIP +1
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#100587 https://bugs.freedesktop.org/show_bug.cgi?id=100587
fdo#103158 https://bugs.freedesktop.org/show_bug.cgi?id=103158
fdo#103166 https://bugs.freedesktop.org/show_bug.cgi?id=103166
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
fdo#105189 https://bugs.freedesktop.org/show_bug.cgi?id=105189
fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411
fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
== Participating hosts (5 -> 5) ==
No changes in participating hosts
== Build changes ==
* IGT: IGT_4570 -> IGTPW_1632
* Linux: CI_DRM_4519 -> CI_DRM_4521
CI_DRM_4519: f14c0ec8fe9acce6fd1be84766f854ab8874eb33 @ git://anongit.freedesktop.org/gfx-ci/linux
CI_DRM_4521: a4ebbd84c682fd30edbde6ac0e48d150d4c5c066 @ git://anongit.freedesktop.org/gfx-ci/linux
IGTPW_1632: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_1632/
IGT_4570: 65cdccdc7bcbb791d791aeeeecb784a382110a3c @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_1632/shards.html
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply
* Re: Consolidating RCU-bh, RCU-preempt, and RCU-sched
From: Paul E. McKenney @ 2018-07-23 20:25 UTC (permalink / raw)
To: Steven Rostedt
Cc: Lai Jiangshan, Josh Triplett, Mathieu Desnoyers, LKML,
Ingo Molnar, Linus Torvalds, Peter Zijlstra, oleg, Eric Dumazet,
davem, Thomas Gleixner
In-Reply-To: <20180723161041.5375b54f@gandalf.local.home>
On Mon, Jul 23, 2018 at 04:10:41PM -0400, Steven Rostedt wrote:
>
> Sorry for the late reply, just came back from the Caribbean :-) :-) :-)
Welcome back, and I hope that the Caribbean trip was a good one!
> On Fri, 13 Jul 2018 11:47:18 +0800
> Lai Jiangshan <jiangshanlai@gmail.com> wrote:
>
> > On Fri, Jul 13, 2018 at 8:02 AM, Paul E. McKenney
> > <paulmck@linux.vnet.ibm.com> wrote:
> > > Hello!
> > >
> > > I now have a semi-reasonable prototype of changes consolidating the
> > > RCU-bh, RCU-preempt, and RCU-sched update-side APIs in my -rcu tree.
> > > There are likely still bugs to be fixed and probably other issues as well,
> > > but a prototype does exist.
>
> What's the rational for all this churn? Linus's complaining that there
> are too many RCU variants?
A CVE stemming from someone getting confused between the different flavors
of RCU. The churn is large, as you say, but it does have the benefit of
making RCU a bit smaller.
Not necessarily simpler, but smaller.
> > > Assuming continued good rcutorture results and no objections, I am
> > > thinking in terms of this timeline:
> > >
> > > o Preparatory work and cleanups are slated for the v4.19 merge window.
> > >
> > > o The actual consolidation and post-consolidation cleanup is slated
> > > for the merge window after v4.19 (v5.0?). These cleanups include
> > > the replacements called out below within the RCU implementation
> > > itself (but excluding kernel/rcu/sync.c, see question below).
> > >
> > > o Replacement of now-obsolete update APIs is slated for the second
> > > merge window after v4.19 (v5.1?). The replacements are currently
> > > expected to be as follows:
> > >
> > > synchronize_rcu_bh() -> synchronize_rcu()
> > > synchronize_rcu_bh_expedited() -> synchronize_rcu_expedited()
> > > call_rcu_bh() -> call_rcu()
> > > rcu_barrier_bh() -> rcu_barrier()
> > > synchronize_sched() -> synchronize_rcu()
> > > synchronize_sched_expedited() -> synchronize_rcu_expedited()
> > > call_rcu_sched() -> call_rcu()
> > > rcu_barrier_sched() -> rcu_barrier()
> > > get_state_synchronize_sched() -> get_state_synchronize_rcu()
> > > cond_synchronize_sched() -> cond_synchronize_rcu()
> > > synchronize_rcu_mult() -> synchronize_rcu()
> > >
> > > I have done light testing of these replacements with good results.
> > >
> > > Any objections to this timeline?
> > >
> > > I also have some questions on the ultimate end point. I have default
> > > choices, which I will likely take if there is no discussion.
> > >
> > > o
> > > Currently, I am thinking in terms of keeping the per-flavor
> > > read-side functions. For example, rcu_read_lock_bh() would
> > > continue to disable softirq, and would also continue to tell
> > > lockdep about the RCU-bh read-side critical section. However,
> > > synchronize_rcu() will wait for all flavors of read-side critical
> > > sections, including those introduced by (say) preempt_disable(),
> > > so there will no longer be any possibility of mismatching (say)
> > > RCU-bh readers with RCU-sched updaters.
> > >
> > > I could imagine other ways of handling this, including:
> > >
> > > a. Eliminate rcu_read_lock_bh() in favor of
> > > local_bh_disable() and so on. Rely on lockdep
> > > instrumentation of these other functions to identify RCU
> > > readers, introducing such instrumentation as needed. I am
> > > not a fan of this approach because of the large number of
> > > places in the Linux kernel where interrupts, preemption,
> > > and softirqs are enabled or disabled "behind the scenes".
> > >
> > > b. Eliminate rcu_read_lock_bh() in favor of rcu_read_lock(),
> > > and required callers to also disable softirqs, preemption,
> > > or whatever as needed. I am not a fan of this approach
> > > because it seems a lot less convenient to users of RCU-bh
> > > and RCU-sched.
> > >
> > > At the moment, I therefore favor keeping the RCU-bh and RCU-sched
> > > read-side APIs. But are there better approaches?
> >
> > Hello, Paul
> >
> > Since local_bh_disable() will be guaranteed to be protected by RCU
> > and more general. I'm afraid it will be preferred over
> > rcu_read_lock_bh() which will be gradually being phased out.
> >
> > In other words, keeping the RCU-bh read-side APIs will be a slower
> > version of the option A. So will the same approach for the RCU-sched.
> > But it'll still be better than the hurrying option A, IMHO.
>
> Now when all this gets done, is synchronize_rcu() going to just wait
> for everything to pass? (scheduling, RCU readers, softirqs, etc) Is
> there any worry about lengthening the time of synchronize_rcu?
Yes, when all is said and done, synchronize_rcu() will wait for everything
to get done. I am not too worried about PREEMPT=y synchronize_rcu()'s
latency because the kernel usually doesn't spend that large a fraction
of its time disabled. I am not worried at all about PREEMPT=n
synchronize_rcu()'s latency because it will if anything be slightly
faster due to being able to take advantage of some softirq transitions.
But one reason for feeding this in over three successive merge windows
is to get more time on it before it all goes in.
Thanx, Paul
> -- Steve
>
>
> > >
> > > o How should kernel/rcu/sync.c be handled? Here are some
> > > possibilities:
> > >
> > > a. Leave the full gp_ops[] array and simply translate
> > > the obsolete update-side functions to their RCU
> > > equivalents.
> > >
> > > b. Leave the current gp_ops[] array, but only have
> > > the RCU_SYNC entry. The __INIT_HELD field would
> > > be set to a function that was OK with being in an
> > > RCU read-side critical section, an interrupt-disabled
> > > section, etc.
> > >
> > > This allows for possible addition of SRCU functionality.
> > > It is also a trivial change. Note that the sole user
> > > of sync.c uses RCU_SCHED_SYNC, and this would need to
> > > be changed to RCU_SYNC.
> > >
> > > But is it likely that we will ever add SRCU?
> > >
> > > c. Eliminate that gp_ops[] array, hard-coding the function
> > > pointers into their call sites.
> > >
> > > I don't really have a preference. Left to myself, I will be lazy
> > > and take option #a. Are there better approaches?
> > >
> > > o Currently, if a lock related to the scheduler's rq or pi locks is
> > > held across rcu_read_unlock(), that lock must be held across the
> > > entire read-side critical section in order to avoid deadlock.
> > > Now that the end of the RCU read-side critical section is
> > > deferred until sometime after interrupts are re-enabled, this
> > > requirement could be lifted. However, because the end of the RCU
> > > read-side critical section is detected sometime after interrupts
> > > are re-enabled, this means that a low-priority RCU reader might
> > > remain priority-boosted longer than need be, which could be a
> > > problem when running real-time workloads.
> > >
> > > My current thought is therefore to leave this constraint in
> > > place. Thoughts?
> > >
> > > Anything else that I should be worried about? ;-)
> > >
> > > Thanx, Paul
> > >
>
^ permalink raw reply
* [PATCH 00/12] i2c: quirks: add zero length checks and update drivers
From: Wolfram Sang @ 2018-07-23 20:26 UTC (permalink / raw)
To: linux-i2c
Cc: linux-arm-msm, linux-kernel, linux-renesas-soc, Wolfram Sang,
linux-tegra, linux-omap, linux-soc, linux-arm-kernel
I had this idea for quite some time on my todo list but a soon to be
implemented refactoring in the i2c-rcar driver now finally made me do it. Add a
'can't do 0 length messages' quirk to the quirk infrastructure for and remove
the manual handling from the drivers. This makes the quirk much more visible.
(Quite some prominent vendors in that list) We also have a centralized place to
handle updates to the quirk detection if that is ever needed.
I have tested this with the i2c-rcar and i2c-sh_mobile driver on a Renesas
SalvatorXS board equipped with M3-N (r8a77965).
A git branch can be found here:
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/quirk-no-zero-len
Looking forward to comments, reviews, tests...
Thanks,
Wolfram
Wolfram Sang (12):
i2c: quirks: add zero length checks
i2c: designware-master: use core to detect 'no zero length' quirk
i2c: mxs: use core to detect 'no zero length' quirk
i2c: omap: use core to detect 'no zero length' quirk
i2c: pmcmsp: use core to detect 'no zero length' quirk
i2c: qup: use core to detect 'no zero length' quirk
i2c: stu300: use core to detect 'no zero length' quirk
i2c: tegra: use core to detect 'no zero length' quirk
i2c: zx2967: use core to detect 'no zero length' quirk
i2c: rcar: use core to detect 'no zero length' quirk
i2c: xlr: use core to detect 'no zero length' quirk
i2c: sh_mobile: use core to detect 'no zero length read' quirk
drivers/i2c/busses/i2c-designware-master.c | 12 +++++-------
drivers/i2c/busses/i2c-mxs.c | 8 +++++---
drivers/i2c/busses/i2c-omap.c | 8 +++++---
drivers/i2c/busses/i2c-pmcmsp.c | 17 +----------------
drivers/i2c/busses/i2c-qup.c | 14 ++++++--------
drivers/i2c/busses/i2c-rcar.c | 13 ++++++-------
drivers/i2c/busses/i2c-sh_mobile.c | 10 +++++-----
drivers/i2c/busses/i2c-stu300.c | 12 ++++++------
drivers/i2c/busses/i2c-tegra.c | 4 +---
drivers/i2c/busses/i2c-xlr.c | 11 +++++------
drivers/i2c/busses/i2c-zx2967.c | 8 +++++---
drivers/i2c/i2c-core-base.c | 6 ++++++
include/linux/i2c.h | 4 ++++
13 files changed, 60 insertions(+), 67 deletions(-)
--
2.11.0
^ permalink raw reply
* [PATCH 00/12] i2c: quirks: add zero length checks and update drivers
From: Wolfram Sang @ 2018-07-23 20:26 UTC (permalink / raw)
To: linux-arm-kernel
I had this idea for quite some time on my todo list but a soon to be
implemented refactoring in the i2c-rcar driver now finally made me do it. Add a
'can't do 0 length messages' quirk to the quirk infrastructure for and remove
the manual handling from the drivers. This makes the quirk much more visible.
(Quite some prominent vendors in that list) We also have a centralized place to
handle updates to the quirk detection if that is ever needed.
I have tested this with the i2c-rcar and i2c-sh_mobile driver on a Renesas
SalvatorXS board equipped with M3-N (r8a77965).
A git branch can be found here:
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/quirk-no-zero-len
Looking forward to comments, reviews, tests...
Thanks,
Wolfram
Wolfram Sang (12):
i2c: quirks: add zero length checks
i2c: designware-master: use core to detect 'no zero length' quirk
i2c: mxs: use core to detect 'no zero length' quirk
i2c: omap: use core to detect 'no zero length' quirk
i2c: pmcmsp: use core to detect 'no zero length' quirk
i2c: qup: use core to detect 'no zero length' quirk
i2c: stu300: use core to detect 'no zero length' quirk
i2c: tegra: use core to detect 'no zero length' quirk
i2c: zx2967: use core to detect 'no zero length' quirk
i2c: rcar: use core to detect 'no zero length' quirk
i2c: xlr: use core to detect 'no zero length' quirk
i2c: sh_mobile: use core to detect 'no zero length read' quirk
drivers/i2c/busses/i2c-designware-master.c | 12 +++++-------
drivers/i2c/busses/i2c-mxs.c | 8 +++++---
drivers/i2c/busses/i2c-omap.c | 8 +++++---
drivers/i2c/busses/i2c-pmcmsp.c | 17 +----------------
drivers/i2c/busses/i2c-qup.c | 14 ++++++--------
drivers/i2c/busses/i2c-rcar.c | 13 ++++++-------
drivers/i2c/busses/i2c-sh_mobile.c | 10 +++++-----
drivers/i2c/busses/i2c-stu300.c | 12 ++++++------
drivers/i2c/busses/i2c-tegra.c | 4 +---
drivers/i2c/busses/i2c-xlr.c | 11 +++++------
drivers/i2c/busses/i2c-zx2967.c | 8 +++++---
drivers/i2c/i2c-core-base.c | 6 ++++++
include/linux/i2c.h | 4 ++++
13 files changed, 60 insertions(+), 67 deletions(-)
--
2.11.0
^ permalink raw reply
* [PATCH 01/12] i2c: quirks: add zero length checks
From: Wolfram Sang @ 2018-07-23 20:26 UTC (permalink / raw)
To: linux-i2c; +Cc: linux-renesas-soc, Wolfram Sang, Wolfram Sang, linux-kernel
In-Reply-To: <20180723202617.15230-1-wsa+renesas@sang-engineering.com>
Some adapters do not support a message length of 0. Add this as a quirk
so drivers don't have to open code it.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
Only build tested.
drivers/i2c/i2c-core-base.c | 6 ++++++
include/linux/i2c.h | 4 ++++
2 files changed, 10 insertions(+)
diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index 02d6f27b19e4..a26b3e9cc441 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -1839,9 +1839,15 @@ static int i2c_check_for_quirks(struct i2c_adapter *adap, struct i2c_msg *msgs,
if (msgs[i].flags & I2C_M_RD) {
if (do_len_check && i2c_quirk_exceeded(len, q->max_read_len))
return i2c_quirk_error(adap, &msgs[i], "msg too long");
+
+ if (q->flags & I2C_AQ_NO_ZERO_LEN_READ && len == 0)
+ return i2c_quirk_error(adap, &msgs[i], "no zero length");
} else {
if (do_len_check && i2c_quirk_exceeded(len, q->max_write_len))
return i2c_quirk_error(adap, &msgs[i], "msg too long");
+
+ if (q->flags & I2C_AQ_NO_ZERO_LEN_WRITE && len == 0)
+ return i2c_quirk_error(adap, &msgs[i], "no zero length");
}
}
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index bc8d42f8544f..2a98d0886d2e 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -661,6 +661,10 @@ struct i2c_adapter_quirks {
I2C_AQ_COMB_READ_SECOND | I2C_AQ_COMB_SAME_ADDR)
/* clock stretching is not supported */
#define I2C_AQ_NO_CLK_STRETCH BIT(4)
+/* message cannot have length of 0 */
+#define I2C_AQ_NO_ZERO_LEN_READ BIT(5)
+#define I2C_AQ_NO_ZERO_LEN_WRITE BIT(6)
+#define I2C_AQ_NO_ZERO_LEN (I2C_AQ_NO_ZERO_LEN_READ | I2C_AQ_NO_ZERO_LEN_WRITE)
/*
* i2c_adapter is the structure used to identify a physical i2c bus along
--
2.11.0
^ permalink raw reply related
* [PATCH 02/12] i2c: designware-master: use core to detect 'no zero length' quirk
From: Wolfram Sang @ 2018-07-23 20:26 UTC (permalink / raw)
To: linux-i2c
Cc: linux-renesas-soc, Wolfram Sang, Jarkko Nikula, Andy Shevchenko,
Mika Westerberg, linux-kernel
In-Reply-To: <20180723202617.15230-1-wsa+renesas@sang-engineering.com>
And don't reimplement in the driver.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
Only build tested.
drivers/i2c/busses/i2c-designware-master.c | 12 +++++-------
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/i2c/busses/i2c-designware-master.c b/drivers/i2c/busses/i2c-designware-master.c
index fc7c255c80af..a1717bff06a8 100644
--- a/drivers/i2c/busses/i2c-designware-master.c
+++ b/drivers/i2c/busses/i2c-designware-master.c
@@ -274,13 +274,6 @@ i2c_dw_xfer_msg(struct dw_i2c_dev *dev)
break;
}
- if (msgs[dev->msg_write_idx].len == 0) {
- dev_err(dev->dev,
- "%s: invalid message length\n", __func__);
- dev->msg_err = -EINVAL;
- break;
- }
-
if (!(dev->status & STATUS_WRITE_IN_PROGRESS)) {
/* new i2c_msg */
buf = msgs[dev->msg_write_idx].buf;
@@ -523,6 +516,10 @@ static const struct i2c_algorithm i2c_dw_algo = {
.functionality = i2c_dw_func,
};
+static const struct i2c_adapter_quirks i2c_dw_quirks = {
+ .flags = I2C_AQ_NO_ZERO_LEN,
+};
+
static u32 i2c_dw_read_clear_intrbits(struct dw_i2c_dev *dev)
{
u32 stat;
@@ -718,6 +715,7 @@ int i2c_dw_probe(struct dw_i2c_dev *dev)
"Synopsys DesignWare I2C adapter");
adap->retries = 3;
adap->algo = &i2c_dw_algo;
+ adap->quirks = &i2c_dw_quirks;
adap->dev.parent = dev->dev;
i2c_set_adapdata(adap, dev);
--
2.11.0
^ permalink raw reply related
* [PATCH 03/12] i2c: mxs: use core to detect 'no zero length' quirk
From: Wolfram Sang @ 2018-07-23 20:26 UTC (permalink / raw)
To: linux-i2c; +Cc: linux-renesas-soc, Wolfram Sang, linux-kernel
In-Reply-To: <20180723202617.15230-1-wsa+renesas@sang-engineering.com>
And don't reimplement in the driver.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
Only build tested.
drivers/i2c/busses/i2c-mxs.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mxs.c b/drivers/i2c/busses/i2c-mxs.c
index 642c58946d8d..7d79317a1046 100644
--- a/drivers/i2c/busses/i2c-mxs.c
+++ b/drivers/i2c/busses/i2c-mxs.c
@@ -567,9 +567,6 @@ static int mxs_i2c_xfer_msg(struct i2c_adapter *adap, struct i2c_msg *msg,
dev_dbg(i2c->dev, "addr: 0x%04x, len: %d, flags: 0x%x, stop: %d\n",
msg->addr, msg->len, msg->flags, stop);
- if (msg->len == 0)
- return -EINVAL;
-
/*
* The MX28 I2C IP block can only do PIO READ for transfer of to up
* 4 bytes of length. The write transfer is not limited as it can use
@@ -683,6 +680,10 @@ static const struct i2c_algorithm mxs_i2c_algo = {
.functionality = mxs_i2c_func,
};
+static const struct i2c_adapter_quirks mxs_i2c_quirks = {
+ .flags = I2C_AQ_NO_ZERO_LEN,
+};
+
static void mxs_i2c_derive_timing(struct mxs_i2c_dev *i2c, uint32_t speed)
{
/* The I2C block clock runs at 24MHz */
@@ -854,6 +855,7 @@ static int mxs_i2c_probe(struct platform_device *pdev)
strlcpy(adap->name, "MXS I2C adapter", sizeof(adap->name));
adap->owner = THIS_MODULE;
adap->algo = &mxs_i2c_algo;
+ adap->quirks = &mxs_i2c_quirks;
adap->dev.parent = dev;
adap->nr = pdev->id;
adap->dev.of_node = pdev->dev.of_node;
--
2.11.0
^ permalink raw reply related
* [PATCH 04/12] i2c: omap: use core to detect 'no zero length' quirk
From: Wolfram Sang @ 2018-07-23 20:26 UTC (permalink / raw)
To: linux-i2c
Cc: linux-renesas-soc, Wolfram Sang, Tony Lindgren, Aaro Koskinen,
linux-omap, linux-kernel
In-Reply-To: <20180723202617.15230-1-wsa+renesas@sang-engineering.com>
And don't reimplement in the driver.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
Only build tested.
drivers/i2c/busses/i2c-omap.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 65d06a819307..b1086bfb0465 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -661,9 +661,6 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
dev_dbg(omap->dev, "addr: 0x%04x, len: %d, flags: 0x%x, stop: %d\n",
msg->addr, msg->len, msg->flags, stop);
- if (msg->len == 0)
- return -EINVAL;
-
omap->receiver = !!(msg->flags & I2C_M_RD);
omap_i2c_resize_fifo(omap, msg->len, omap->receiver);
@@ -1179,6 +1176,10 @@ static const struct i2c_algorithm omap_i2c_algo = {
.functionality = omap_i2c_func,
};
+static const struct i2c_adapter_quirks omap_i2c_quirks = {
+ .flags = I2C_AQ_NO_ZERO_LEN,
+};
+
#ifdef CONFIG_OF
static struct omap_i2c_bus_platform_data omap2420_pdata = {
.rev = OMAP_I2C_IP_VERSION_1,
@@ -1453,6 +1454,7 @@ omap_i2c_probe(struct platform_device *pdev)
adap->class = I2C_CLASS_DEPRECATED;
strlcpy(adap->name, "OMAP I2C adapter", sizeof(adap->name));
adap->algo = &omap_i2c_algo;
+ adap->quirks = &omap_i2c_quirks;
adap->dev.parent = &pdev->dev;
adap->dev.of_node = pdev->dev.of_node;
adap->bus_recovery_info = &omap_i2c_bus_recovery_info;
--
2.11.0
^ permalink raw reply related
* [PATCH 05/12] i2c: pmcmsp: use core to detect 'no zero length' quirk
From: Wolfram Sang @ 2018-07-23 20:26 UTC (permalink / raw)
To: linux-i2c; +Cc: linux-renesas-soc, Wolfram Sang, linux-kernel
In-Reply-To: <20180723202617.15230-1-wsa+renesas@sang-engineering.com>
And don't reimplement in the driver.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
Only build tested.
drivers/i2c/busses/i2c-pmcmsp.c | 17 +----------------
1 file changed, 1 insertion(+), 16 deletions(-)
diff --git a/drivers/i2c/busses/i2c-pmcmsp.c b/drivers/i2c/busses/i2c-pmcmsp.c
index dae8ac618a52..0829cb696d9d 100644
--- a/drivers/i2c/busses/i2c-pmcmsp.c
+++ b/drivers/i2c/busses/i2c-pmcmsp.c
@@ -444,16 +444,6 @@ static enum pmcmsptwi_xfer_result pmcmsptwi_xfer_cmd(
{
enum pmcmsptwi_xfer_result retval;
- if ((cmd->type == MSP_TWI_CMD_WRITE && cmd->write_len == 0) ||
- (cmd->type == MSP_TWI_CMD_READ && cmd->read_len == 0) ||
- (cmd->type == MSP_TWI_CMD_WRITE_READ &&
- (cmd->read_len == 0 || cmd->write_len == 0))) {
- dev_err(&pmcmsptwi_adapter.dev,
- "%s: Cannot transfer less than 1 byte\n",
- __func__);
- return -EINVAL;
- }
-
mutex_lock(&data->lock);
dev_dbg(&pmcmsptwi_adapter.dev,
"Setting address to 0x%04x\n", cmd->addr);
@@ -532,11 +522,6 @@ static int pmcmsptwi_master_xfer(struct i2c_adapter *adap,
cmd.write_data = msg->buf;
}
- if (msg->len == 0) {
- dev_err(&adap->dev, "Zero-byte messages unsupported\n");
- return -EINVAL;
- }
-
cmd.addr = msg->addr;
if (msg->flags & I2C_M_TEN) {
@@ -578,7 +563,7 @@ static u32 pmcmsptwi_i2c_func(struct i2c_adapter *adapter)
}
static const struct i2c_adapter_quirks pmcmsptwi_i2c_quirks = {
- .flags = I2C_AQ_COMB_WRITE_THEN_READ,
+ .flags = I2C_AQ_COMB_WRITE_THEN_READ | I2C_AQ_NO_ZERO_LEN,
.max_write_len = MSP_MAX_BYTES_PER_RW,
.max_read_len = MSP_MAX_BYTES_PER_RW,
.max_comb_1st_msg_len = MSP_MAX_BYTES_PER_RW,
--
2.11.0
^ permalink raw reply related
* [PATCH 06/12] i2c: qup: use core to detect 'no zero length' quirk
From: Wolfram Sang @ 2018-07-23 20:26 UTC (permalink / raw)
To: linux-i2c
Cc: linux-renesas-soc, Wolfram Sang, Andy Gross, David Brown,
linux-arm-msm, linux-soc, linux-kernel
In-Reply-To: <20180723202617.15230-1-wsa+renesas@sang-engineering.com>
And don't reimplement in the driver.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
Only build tested.
drivers/i2c/busses/i2c-qup.c | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c
index c86c3ae1318f..e09cd0775ae9 100644
--- a/drivers/i2c/busses/i2c-qup.c
+++ b/drivers/i2c/busses/i2c-qup.c
@@ -1088,11 +1088,6 @@ static int qup_i2c_xfer(struct i2c_adapter *adap,
writel(I2C_MINI_CORE | I2C_N_VAL, qup->base + QUP_CONFIG);
for (idx = 0; idx < num; idx++) {
- if (msgs[idx].len == 0) {
- ret = -EINVAL;
- goto out;
- }
-
if (qup_i2c_poll_state_i2c_master(qup)) {
ret = -EIO;
goto out;
@@ -1520,9 +1515,6 @@ qup_i2c_determine_mode_v2(struct qup_i2c_dev *qup,
/* All i2c_msgs should be transferred using either dma or cpu */
for (idx = 0; idx < num; idx++) {
- if (msgs[idx].len == 0)
- return -EINVAL;
-
if (msgs[idx].flags & I2C_M_RD)
max_rx_len = max_t(unsigned int, max_rx_len,
msgs[idx].len);
@@ -1636,9 +1628,14 @@ static const struct i2c_algorithm qup_i2c_algo_v2 = {
* which limits the possible read to 256 (QUP_READ_LIMIT) bytes.
*/
static const struct i2c_adapter_quirks qup_i2c_quirks = {
+ .flags = I2C_AQ_NO_ZERO_LEN,
.max_read_len = QUP_READ_LIMIT,
};
+static const struct i2c_adapter_quirks qup_i2c_quirks_v2 = {
+ .flags = I2C_AQ_NO_ZERO_LEN,
+};
+
static void qup_i2c_enable_clocks(struct qup_i2c_dev *qup)
{
clk_prepare_enable(qup->clk);
@@ -1701,6 +1698,7 @@ static int qup_i2c_probe(struct platform_device *pdev)
is_qup_v1 = true;
} else {
qup->adap.algo = &qup_i2c_algo_v2;
+ qup->adap.quirks = &qup_i2c_quirks_v2;
is_qup_v1 = false;
if (acpi_match_device(qup_i2c_acpi_match, qup->dev))
goto nodma;
--
2.11.0
^ permalink raw reply related
* [PATCH 07/12] i2c: stu300: use core to detect 'no zero length' quirk
From: Wolfram Sang @ 2018-07-23 20:26 UTC (permalink / raw)
To: linux-i2c
Cc: linux-renesas-soc, Wolfram Sang, Linus Walleij, linux-arm-kernel,
linux-kernel
In-Reply-To: <20180723202617.15230-1-wsa+renesas@sang-engineering.com>
And don't reimplement in the driver.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
Only build tested.
drivers/i2c/busses/i2c-stu300.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-stu300.c b/drivers/i2c/busses/i2c-stu300.c
index fce52bdab2b7..5503fa171df0 100644
--- a/drivers/i2c/busses/i2c-stu300.c
+++ b/drivers/i2c/busses/i2c-stu300.c
@@ -673,12 +673,6 @@ static int stu300_xfer_msg(struct i2c_adapter *adap,
msg->addr, msg->len, msg->flags, stop);
}
- /* Zero-length messages are not supported by this hardware */
- if (msg->len == 0) {
- ret = -EINVAL;
- goto exit_disable;
- }
-
/*
* For some reason, sending the address sometimes fails when running
* on the 13 MHz clock. No interrupt arrives. This is a work around,
@@ -863,6 +857,10 @@ static const struct i2c_algorithm stu300_algo = {
.functionality = stu300_func,
};
+static const struct i2c_adapter_quirks stu300_quirks = {
+ .flags = I2C_AQ_NO_ZERO_LEN,
+};
+
static int stu300_probe(struct platform_device *pdev)
{
struct stu300_dev *dev;
@@ -920,6 +918,8 @@ static int stu300_probe(struct platform_device *pdev)
adap->algo = &stu300_algo;
adap->dev.parent = &pdev->dev;
adap->dev.of_node = pdev->dev.of_node;
+ adap->quirks = &stu300_quirks;
+
i2c_set_adapdata(adap, dev);
/* i2c device drivers may be active on return from add_adapter() */
--
2.11.0
^ permalink raw reply related
* [PATCH 07/12] i2c: stu300: use core to detect 'no zero length' quirk
From: Wolfram Sang @ 2018-07-23 20:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180723202617.15230-1-wsa+renesas@sang-engineering.com>
And don't reimplement in the driver.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
Only build tested.
drivers/i2c/busses/i2c-stu300.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-stu300.c b/drivers/i2c/busses/i2c-stu300.c
index fce52bdab2b7..5503fa171df0 100644
--- a/drivers/i2c/busses/i2c-stu300.c
+++ b/drivers/i2c/busses/i2c-stu300.c
@@ -673,12 +673,6 @@ static int stu300_xfer_msg(struct i2c_adapter *adap,
msg->addr, msg->len, msg->flags, stop);
}
- /* Zero-length messages are not supported by this hardware */
- if (msg->len == 0) {
- ret = -EINVAL;
- goto exit_disable;
- }
-
/*
* For some reason, sending the address sometimes fails when running
* on the 13 MHz clock. No interrupt arrives. This is a work around,
@@ -863,6 +857,10 @@ static const struct i2c_algorithm stu300_algo = {
.functionality = stu300_func,
};
+static const struct i2c_adapter_quirks stu300_quirks = {
+ .flags = I2C_AQ_NO_ZERO_LEN,
+};
+
static int stu300_probe(struct platform_device *pdev)
{
struct stu300_dev *dev;
@@ -920,6 +918,8 @@ static int stu300_probe(struct platform_device *pdev)
adap->algo = &stu300_algo;
adap->dev.parent = &pdev->dev;
adap->dev.of_node = pdev->dev.of_node;
+ adap->quirks = &stu300_quirks;
+
i2c_set_adapdata(adap, dev);
/* i2c device drivers may be active on return from add_adapter() */
--
2.11.0
^ permalink raw reply related
* [PATCH 08/12] i2c: tegra: use core to detect 'no zero length' quirk
From: Wolfram Sang @ 2018-07-23 20:26 UTC (permalink / raw)
To: linux-i2c
Cc: linux-renesas-soc, Wolfram Sang, Laxman Dewangan, Thierry Reding,
Jonathan Hunter, linux-tegra, linux-kernel
In-Reply-To: <20180723202617.15230-1-wsa+renesas@sang-engineering.com>
And don't reimplement in the driver.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
Only build tested.
drivers/i2c/busses/i2c-tegra.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
index 60c8561fbe65..437294ea2f0a 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -684,9 +684,6 @@ static int tegra_i2c_xfer_msg(struct tegra_i2c_dev *i2c_dev,
tegra_i2c_flush_fifos(i2c_dev);
- if (msg->len == 0)
- return -EINVAL;
-
i2c_dev->msg_buf = msg->buf;
i2c_dev->msg_buf_remaining = msg->len;
i2c_dev->msg_err = I2C_ERR_NONE;
@@ -831,6 +828,7 @@ static const struct i2c_algorithm tegra_i2c_algo = {
/* payload size is only 12 bit */
static const struct i2c_adapter_quirks tegra_i2c_quirks = {
+ .flags = I2C_AQ_NO_ZERO_LEN,
.max_read_len = 4096,
.max_write_len = 4096,
};
--
2.11.0
^ permalink raw reply related
* [PATCH 09/12] i2c: zx2967: use core to detect 'no zero length' quirk
From: Wolfram Sang @ 2018-07-23 20:26 UTC (permalink / raw)
To: linux-i2c
Cc: linux-kernel, linux-renesas-soc, Wolfram Sang, Jun Nie,
Baoyou Xie, Shawn Guo, linux-arm-kernel
In-Reply-To: <20180723202617.15230-1-wsa+renesas@sang-engineering.com>
And don't reimplement in the driver.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
Only build tested.
drivers/i2c/busses/i2c-zx2967.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-zx2967.c b/drivers/i2c/busses/i2c-zx2967.c
index 48281c1b30c6..b8f9e020d80e 100644
--- a/drivers/i2c/busses/i2c-zx2967.c
+++ b/drivers/i2c/busses/i2c-zx2967.c
@@ -281,9 +281,6 @@ static int zx2967_i2c_xfer_msg(struct zx2967_i2c *i2c,
int ret;
int i;
- if (msg->len == 0)
- return -EINVAL;
-
zx2967_i2c_flush_fifos(i2c);
i2c->cur_trans = msg->buf;
@@ -498,6 +495,10 @@ static const struct i2c_algorithm zx2967_i2c_algo = {
.functionality = zx2967_i2c_func,
};
+static const struct i2c_adapter_quirks zx2967_i2c_quirks = {
+ .flags = I2C_AQ_NO_ZERO_LEN,
+};
+
static const struct of_device_id zx2967_i2c_of_match[] = {
{ .compatible = "zte,zx296718-i2c", },
{ },
@@ -568,6 +569,7 @@ static int zx2967_i2c_probe(struct platform_device *pdev)
strlcpy(i2c->adap.name, "zx2967 i2c adapter",
sizeof(i2c->adap.name));
i2c->adap.algo = &zx2967_i2c_algo;
+ i2c->adap.quirks = &zx2967_i2c_quirks;
i2c->adap.nr = pdev->id;
i2c->adap.dev.parent = &pdev->dev;
i2c->adap.dev.of_node = pdev->dev.of_node;
--
2.11.0
^ permalink raw reply related
* [PATCH 09/12] i2c: zx2967: use core to detect 'no zero length' quirk
From: Wolfram Sang @ 2018-07-23 20:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180723202617.15230-1-wsa+renesas@sang-engineering.com>
And don't reimplement in the driver.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
Only build tested.
drivers/i2c/busses/i2c-zx2967.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-zx2967.c b/drivers/i2c/busses/i2c-zx2967.c
index 48281c1b30c6..b8f9e020d80e 100644
--- a/drivers/i2c/busses/i2c-zx2967.c
+++ b/drivers/i2c/busses/i2c-zx2967.c
@@ -281,9 +281,6 @@ static int zx2967_i2c_xfer_msg(struct zx2967_i2c *i2c,
int ret;
int i;
- if (msg->len == 0)
- return -EINVAL;
-
zx2967_i2c_flush_fifos(i2c);
i2c->cur_trans = msg->buf;
@@ -498,6 +495,10 @@ static const struct i2c_algorithm zx2967_i2c_algo = {
.functionality = zx2967_i2c_func,
};
+static const struct i2c_adapter_quirks zx2967_i2c_quirks = {
+ .flags = I2C_AQ_NO_ZERO_LEN,
+};
+
static const struct of_device_id zx2967_i2c_of_match[] = {
{ .compatible = "zte,zx296718-i2c", },
{ },
@@ -568,6 +569,7 @@ static int zx2967_i2c_probe(struct platform_device *pdev)
strlcpy(i2c->adap.name, "zx2967 i2c adapter",
sizeof(i2c->adap.name));
i2c->adap.algo = &zx2967_i2c_algo;
+ i2c->adap.quirks = &zx2967_i2c_quirks;
i2c->adap.nr = pdev->id;
i2c->adap.dev.parent = &pdev->dev;
i2c->adap.dev.of_node = pdev->dev.of_node;
--
2.11.0
^ permalink raw reply related
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.