* Re: [dpdk-dev] [PATCH v2 02/10] meson: add BUILDING_RTE_SDK
From: Bruce Richardson @ 2019-06-20 10:21 UTC (permalink / raw)
To: Neil Horman; +Cc: dev, Jerin Jacob Kollanukkaran, Thomas Monjalon
In-Reply-To: <20190613142344.9188-3-nhorman@tuxdriver.com>
On Thu, Jun 13, 2019 at 10:23:36AM -0400, Neil Horman wrote:
> The __rte_internal macro is defined dependent on the value of the build
> environment variable BUILDING_RTE_SDK. This variable was set in the
> Makefile environment but not the meson environment, so lets reconcile
> the two by defining it for meson in the lib and drivers directories, but
> not the examples/apps directories, which should be treated as they are
> not part of the core DPDK library
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> CC: Jerin Jacob Kollanukkaran <jerinj@marvell.com>
> CC: Bruce Richardson <bruce.richardson@intel.com>
> CC: Thomas Monjalon <thomas@monjalon.net>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
^ permalink raw reply
* Re: [dpdk-dev] [PATCH v3 2/3] net/ice: add generic flow API
From: Wang, Xiao W @ 2019-06-20 10:21 UTC (permalink / raw)
To: Yang, Qiming, dev@dpdk.org; +Cc: Zhang, Qi Z, Xing, Beilei
In-Reply-To: <20190620053449.32959-3-qiming.yang@intel.com>
Hi,
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Qiming Yang
> Sent: Thursday, June 20, 2019 1:35 PM
> To: dev@dpdk.org
> Cc: Yang, Qiming <qiming.yang@intel.com>
> Subject: [dpdk-dev] [PATCH v3 2/3] net/ice: add generic flow API
>
> This patch adds ice_flow_create, ice_flow_destroy,
> ice_flow_flush and ice_flow_validate support,
> these are used to handle all the generic filters.
>
> Signed-off-by: Qiming Yang <qiming.yang@intel.com>
> ---
> drivers/net/ice/Makefile | 1 +
> drivers/net/ice/ice_ethdev.c | 44 +++
> drivers/net/ice/ice_ethdev.h | 5 +
> drivers/net/ice/ice_generic_flow.c | 682
> +++++++++++++++++++++++++++++++++++++
> drivers/net/ice/ice_generic_flow.h | 654
> +++++++++++++++++++++++++++++++++++
> drivers/net/ice/meson.build | 1 +
> 6 files changed, 1387 insertions(+)
> create mode 100644 drivers/net/ice/ice_generic_flow.c
> create mode 100644 drivers/net/ice/ice_generic_flow.h
>
[...]
> + case RTE_FLOW_ITEM_TYPE_ETH:
> + eth_spec = item->spec;
> + eth_mask = item->mask;
> +
> + if (eth_spec && eth_mask) {
> + if (rte_is_broadcast_ether_addr(ð_mask-
> >src))
> + input_set |= ICE_INSET_SMAC;
> + if (rte_is_broadcast_ether_addr(ð_mask-
> >dst))
> + input_set |= ICE_INSET_DMAC;
> + if (eth_mask->type == RTE_BE16(0xffff))
> + input_set |= ICE_INSET_ETHERTYPE;
> + }
> + break;
> + case RTE_FLOW_ITEM_TYPE_IPV4:
> + ipv4_spec = item->spec;
> + ipv4_mask = item->mask;
> +
> + if (!(ipv4_spec && ipv4_mask)) {
> + rte_flow_error_set(error, EINVAL,
> + RTE_FLOW_ERROR_TYPE_ITEM,
> + item,
> + "Invalid IPv4 spec or mask.");
> + return 0;
> + }
> +
> + /* Check IPv4 mask and update input set */
> + if (ipv4_mask->hdr.version_ihl ||
> + ipv4_mask->hdr.total_length ||
> + ipv4_mask->hdr.packet_id ||
> + ipv4_mask->hdr.hdr_checksum) {
> + rte_flow_error_set(error, EINVAL,
> + RTE_FLOW_ERROR_TYPE_ITEM,
> + item,
> + "Invalid IPv4 mask.");
> + return 0;
> + }
> +
> + if (outer_ip) {
> + if (ipv4_mask->hdr.src_addr == UINT32_MAX)
> + input_set |= ICE_INSET_IPV4_SRC;
> + if (ipv4_mask->hdr.dst_addr == UINT32_MAX)
> + input_set |= ICE_INSET_IPV4_DST;
> + if (ipv4_mask->hdr.type_of_service ==
> UINT8_MAX)
> + input_set |= ICE_INSET_IPV4_TOS;
> + if (ipv4_mask->hdr.time_to_live ==
> UINT8_MAX)
> + input_set |= ICE_INSET_IPV4_TTL;
> + if (ipv4_mask->hdr.fragment_offset == 0)
Seems a typo. fragment_offset --> next_proto_id == UINT8_MAX.
> + input_set |= ICE_INSET_IPV4_PROTO;
> + outer_ip = false;
> + } else {
> + if (ipv4_mask->hdr.src_addr == UINT32_MAX)
> + input_set |=
> ICE_INSET_TUN_IPV4_SRC;
> + if (ipv4_mask->hdr.dst_addr == UINT32_MAX)
> + input_set |=
> ICE_INSET_TUN_IPV4_DST;
> + if (ipv4_mask->hdr.time_to_live ==
> UINT8_MAX)
> + input_set |=
> ICE_INSET_TUN_IPV4_TTL;
> + if (ipv4_mask->hdr.next_proto_id ==
> UINT8_MAX)
> + input_set |=
> ICE_INSET_TUN_IPV4_PROTO;
> + }
> + break;
> + case RTE_FLOW_ITEM_TYPE_IPV6:
> + ipv6_spec = item->spec;
> + ipv6_mask = item->mask;
> +
> + if (!(ipv6_spec && ipv6_mask)) {
> + rte_flow_error_set(error, EINVAL,
> + RTE_FLOW_ERROR_TYPE_ITEM,
> + item, "Invalid IPv6 spec or mask");
> + return 0;
> + }
[...]
> +/* bit 16 ~ bit 31 */
> +#define ICE_INSET_IPV4_TOS 0x0000000000010000ULL
> +#define ICE_INSET_IPV4_PROTO 0x0000000000020000ULL
> +#define ICE_INSET_IPV4_TTL 0x0000000000040000ULL
> +#define ICE_INSET_IPV6_NEXT_HDR 0x0000000000200000ULL
It's better to align the name to "ICE_INSET_IPV6_PROTO".
> +#define ICE_INSET_IPV6_HOP_LIMIT 0x0000000000400000ULL
> +#define ICE_INSET_ICMP 0x0000000001000000ULL
> +#define ICE_INSET_ICMP6 0x0000000002000000ULL
> +
BRs,
Xiao
^ permalink raw reply
* [Qemu-devel] [PATCH v3 4/4] target/mips: Fix if-else-switch-case arms checkpatch errors in translate.c
From: Aleksandar Markovic @ 2019-06-20 10:02 UTC (permalink / raw)
To: qemu-devel; +Cc: arikalo, amarkovic
In-Reply-To: <1561024929-26004-1-git-send-email-aleksandar.markovic@rt-rk.com>
From: Aleksandar Markovic <amarkovic@wavecomp.com>
Remove if-else-switch-case-arms-related checkpatch errors.
Signed-off-by: Aleksandar Markovic <amarkovic@wavecomp.com>
---
target/mips/translate.c | 205 +++++++++++++++++++++++++++++++-----------------
1 file changed, 133 insertions(+), 72 deletions(-)
diff --git a/target/mips/translate.c b/target/mips/translate.c
index 54e0160..d489148 100644
--- a/target/mips/translate.c
+++ b/target/mips/translate.c
@@ -2619,16 +2619,18 @@ static const char * const mxuregnames[] = {
/* General purpose registers moves. */
static inline void gen_load_gpr(TCGv t, int reg)
{
- if (reg == 0)
+ if (reg == 0) {
tcg_gen_movi_tl(t, 0);
- else
+ } else {
tcg_gen_mov_tl(t, cpu_gpr[reg]);
+ }
}
static inline void gen_store_gpr(TCGv t, int reg)
{
- if (reg != 0)
+ if (reg != 0) {
tcg_gen_mov_tl(cpu_gpr[reg], t);
+ }
}
/* Moves to/from shadow registers. */
@@ -2636,9 +2638,9 @@ static inline void gen_load_srsgpr(int from, int to)
{
TCGv t0 = tcg_temp_new();
- if (from == 0)
+ if (from == 0) {
tcg_gen_movi_tl(t0, 0);
- else {
+ } else {
TCGv_i32 t2 = tcg_temp_new_i32();
TCGv_ptr addr = tcg_temp_new_ptr();
@@ -2841,10 +2843,11 @@ static void gen_store_fpr64(DisasContext *ctx, TCGv_i64 t, int reg)
static inline int get_fp_bit(int cc)
{
- if (cc)
+ if (cc) {
return 24 + cc;
- else
+ } else {
return 23;
+ }
}
/* Addresses computation */
@@ -2908,14 +2911,16 @@ static inline void gen_move_high32(TCGv ret, TCGv_i64 arg)
static inline void check_cp0_enabled(DisasContext *ctx)
{
- if (unlikely(!(ctx->hflags & MIPS_HFLAG_CP0)))
+ if (unlikely(!(ctx->hflags & MIPS_HFLAG_CP0))) {
generate_exception_err(ctx, EXCP_CpU, 0);
+ }
}
static inline void check_cp1_enabled(DisasContext *ctx)
{
- if (unlikely(!(ctx->hflags & MIPS_HFLAG_FPU)))
+ if (unlikely(!(ctx->hflags & MIPS_HFLAG_FPU))) {
generate_exception_err(ctx, EXCP_CpU, 1);
+ }
}
/* Verify that the processor is running with COP1X instructions enabled.
@@ -2924,8 +2929,9 @@ static inline void check_cp1_enabled(DisasContext *ctx)
static inline void check_cop1x(DisasContext *ctx)
{
- if (unlikely(!(ctx->hflags & MIPS_HFLAG_COP1X)))
+ if (unlikely(!(ctx->hflags & MIPS_HFLAG_COP1X))) {
generate_exception_end(ctx, EXCP_RI);
+ }
}
/* Verify that the processor is running with 64-bit floating-point
@@ -2933,8 +2939,9 @@ static inline void check_cop1x(DisasContext *ctx)
static inline void check_cp1_64bitmode(DisasContext *ctx)
{
- if (unlikely(~ctx->hflags & (MIPS_HFLAG_F64 | MIPS_HFLAG_COP1X)))
+ if (unlikely(~ctx->hflags & (MIPS_HFLAG_F64 | MIPS_HFLAG_COP1X))) {
generate_exception_end(ctx, EXCP_RI);
+ }
}
/*
@@ -2950,8 +2957,9 @@ static inline void check_cp1_64bitmode(DisasContext *ctx)
*/
static inline void check_cp1_registers(DisasContext *ctx, int regs)
{
- if (unlikely(!(ctx->hflags & MIPS_HFLAG_F64) && (regs & 1)))
+ if (unlikely(!(ctx->hflags & MIPS_HFLAG_F64) && (regs & 1))) {
generate_exception_end(ctx, EXCP_RI);
+ }
}
/* Verify that the processor is running with DSP instructions enabled.
@@ -3040,8 +3048,9 @@ static inline void check_ps(DisasContext *ctx)
instructions are not enabled. */
static inline void check_mips_64(DisasContext *ctx)
{
- if (unlikely(!(ctx->hflags & MIPS_HFLAG_64)))
+ if (unlikely(!(ctx->hflags & MIPS_HFLAG_64))) {
generate_exception_end(ctx, EXCP_RI);
+ }
}
#endif
@@ -3126,13 +3135,12 @@ static inline void check_nms(DisasContext *ctx)
*/
static inline void check_nms_dl_il_sl_tl_l2c(DisasContext *ctx)
{
- if (unlikely(ctx->CP0_Config5 & (1 << CP0C5_NMS)) &&
- !(ctx->CP0_Config1 & (1 << CP0C1_DL)) &&
- !(ctx->CP0_Config1 & (1 << CP0C1_IL)) &&
- !(ctx->CP0_Config2 & (1 << CP0C2_SL)) &&
- !(ctx->CP0_Config2 & (1 << CP0C2_TL)) &&
- !(ctx->CP0_Config5 & (1 << CP0C5_L2C)))
- {
+ if (unlikely( (ctx->CP0_Config5 & (1 << CP0C5_NMS)) &&
+ !(ctx->CP0_Config1 & (1 << CP0C1_DL )) &&
+ !(ctx->CP0_Config1 & (1 << CP0C1_IL )) &&
+ !(ctx->CP0_Config2 & (1 << CP0C2_SL )) &&
+ !(ctx->CP0_Config2 & (1 << CP0C2_TL )) &&
+ !(ctx->CP0_Config5 & (1 << CP0C5_L2C)) ) ) {
generate_exception_end(ctx, EXCP_RI);
}
}
@@ -3180,23 +3188,56 @@ static inline void gen_cmp ## type ## _ ## fmt(DisasContext *ctx, int n, \
gen_ldcmp_fpr##bits (ctx, fp0, fs); \
gen_ldcmp_fpr##bits (ctx, fp1, ft); \
switch (n) { \
- case 0: gen_helper_0e2i(cmp ## type ## _ ## fmt ## _f, fp0, fp1, cc); break;\
- case 1: gen_helper_0e2i(cmp ## type ## _ ## fmt ## _un, fp0, fp1, cc); break;\
- case 2: gen_helper_0e2i(cmp ## type ## _ ## fmt ## _eq, fp0, fp1, cc); break;\
- case 3: gen_helper_0e2i(cmp ## type ## _ ## fmt ## _ueq, fp0, fp1, cc); break;\
- case 4: gen_helper_0e2i(cmp ## type ## _ ## fmt ## _olt, fp0, fp1, cc); break;\
- case 5: gen_helper_0e2i(cmp ## type ## _ ## fmt ## _ult, fp0, fp1, cc); break;\
- case 6: gen_helper_0e2i(cmp ## type ## _ ## fmt ## _ole, fp0, fp1, cc); break;\
- case 7: gen_helper_0e2i(cmp ## type ## _ ## fmt ## _ule, fp0, fp1, cc); break;\
- case 8: gen_helper_0e2i(cmp ## type ## _ ## fmt ## _sf, fp0, fp1, cc); break;\
- case 9: gen_helper_0e2i(cmp ## type ## _ ## fmt ## _ngle, fp0, fp1, cc); break;\
- case 10: gen_helper_0e2i(cmp ## type ## _ ## fmt ## _seq, fp0, fp1, cc); break;\
- case 11: gen_helper_0e2i(cmp ## type ## _ ## fmt ## _ngl, fp0, fp1, cc); break;\
- case 12: gen_helper_0e2i(cmp ## type ## _ ## fmt ## _lt, fp0, fp1, cc); break;\
- case 13: gen_helper_0e2i(cmp ## type ## _ ## fmt ## _nge, fp0, fp1, cc); break;\
- case 14: gen_helper_0e2i(cmp ## type ## _ ## fmt ## _le, fp0, fp1, cc); break;\
- case 15: gen_helper_0e2i(cmp ## type ## _ ## fmt ## _ngt, fp0, fp1, cc); break;\
- default: abort(); \
+ case 0: \
+ gen_helper_0e2i(cmp ## type ## _ ## fmt ## _f, fp0, fp1, cc); \
+ break; \
+ case 1: \
+ gen_helper_0e2i(cmp ## type ## _ ## fmt ## _un, fp0, fp1, cc); \
+ break; \
+ case 2: \
+ gen_helper_0e2i(cmp ## type ## _ ## fmt ## _eq, fp0, fp1, cc); \
+ break; \
+ case 3: \
+ gen_helper_0e2i(cmp ## type ## _ ## fmt ## _ueq, fp0, fp1, cc); \
+ break; \
+ case 4: \
+ gen_helper_0e2i(cmp ## type ## _ ## fmt ## _olt, fp0, fp1, cc); \
+ break; \
+ case 5: \
+ gen_helper_0e2i(cmp ## type ## _ ## fmt ## _ult, fp0, fp1, cc); \
+ break; \
+ case 6: \
+ gen_helper_0e2i(cmp ## type ## _ ## fmt ## _ole, fp0, fp1, cc); \
+ break; \
+ case 7: \
+ gen_helper_0e2i(cmp ## type ## _ ## fmt ## _ule, fp0, fp1, cc); \
+ break; \
+ case 8: \
+ gen_helper_0e2i(cmp ## type ## _ ## fmt ## _sf, fp0, fp1, cc); \
+ break; \
+ case 9: \
+ gen_helper_0e2i(cmp ## type ## _ ## fmt ## _ngle, fp0, fp1, cc); \
+ break; \
+ case 10: \
+ gen_helper_0e2i(cmp ## type ## _ ## fmt ## _seq, fp0, fp1, cc); \
+ break; \
+ case 11: \
+ gen_helper_0e2i(cmp ## type ## _ ## fmt ## _ngl, fp0, fp1, cc); \
+ break; \
+ case 12: \
+ gen_helper_0e2i(cmp ## type ## _ ## fmt ## _lt, fp0, fp1, cc); \
+ break; \
+ case 13: \
+ gen_helper_0e2i(cmp ## type ## _ ## fmt ## _nge, fp0, fp1, cc); \
+ break; \
+ case 14: \
+ gen_helper_0e2i(cmp ## type ## _ ## fmt ## _le, fp0, fp1, cc); \
+ break; \
+ case 15: \
+ gen_helper_0e2i(cmp ## type ## _ ## fmt ## _ngt, fp0, fp1, cc); \
+ break; \
+ default: \
+ abort(); \
} \
tcg_temp_free_i##bits (fp0); \
tcg_temp_free_i##bits (fp1); \
@@ -3882,22 +3923,25 @@ static void gen_logic_imm(DisasContext *ctx, uint32_t opc,
uimm = (uint16_t)imm;
switch (opc) {
case OPC_ANDI:
- if (likely(rs != 0))
+ if (likely(rs != 0)) {
tcg_gen_andi_tl(cpu_gpr[rt], cpu_gpr[rs], uimm);
- else
+ } else {
tcg_gen_movi_tl(cpu_gpr[rt], 0);
+ }
break;
case OPC_ORI:
- if (rs != 0)
+ if (rs != 0) {
tcg_gen_ori_tl(cpu_gpr[rt], cpu_gpr[rs], uimm);
- else
+ } else {
tcg_gen_movi_tl(cpu_gpr[rt], uimm);
+ }
break;
case OPC_XORI:
- if (likely(rs != 0))
+ if (likely(rs != 0)) {
tcg_gen_xori_tl(cpu_gpr[rt], cpu_gpr[rs], uimm);
- else
+ } else {
tcg_gen_movi_tl(cpu_gpr[rt], uimm);
+ }
break;
case OPC_LUI:
if (rs != 0 && (ctx->insn_flags & ISA_MIPS32R6)) {
@@ -6060,8 +6104,9 @@ static void gen_compute_branch (DisasContext *ctx, uint32_t opc,
}
out:
- if (insn_bytes == 2)
+ if (insn_bytes == 2) {
ctx->hflags |= MIPS_HFLAG_B16;
+ }
tcg_temp_free(t0);
tcg_temp_free(t1);
}
@@ -6708,8 +6753,9 @@ static void gen_mfc0(DisasContext *ctx, TCGv arg, int reg, int sel)
{
const char *register_name = "invalid";
- if (sel != 0)
+ if (sel != 0) {
check_insn(ctx, ISA_MIPS32);
+ }
switch (reg) {
case CP0_REGISTER_00:
@@ -7464,8 +7510,9 @@ static void gen_mtc0(DisasContext *ctx, TCGv arg, int reg, int sel)
{
const char *register_name = "invalid";
- if (sel != 0)
+ if (sel != 0) {
check_insn(ctx, ISA_MIPS32);
+ }
if (tb_cflags(ctx->base.tb) & CF_USE_ICOUNT) {
gen_io_start();
@@ -8210,8 +8257,9 @@ static void gen_dmfc0(DisasContext *ctx, TCGv arg, int reg, int sel)
{
const char *register_name = "invalid";
- if (sel != 0)
+ if (sel != 0) {
check_insn(ctx, ISA_MIPS64);
+ }
switch (reg) {
case CP0_REGISTER_00:
@@ -8920,8 +8968,9 @@ static void gen_dmtc0(DisasContext *ctx, TCGv arg, int reg, int sel)
{
const char *register_name = "invalid";
- if (sel != 0)
+ if (sel != 0) {
check_insn(ctx, ISA_MIPS64);
+ }
if (tb_cflags(ctx->base.tb) & CF_USE_ICOUNT) {
gen_io_start();
@@ -9658,12 +9707,12 @@ static void gen_mftr(CPUMIPSState *env, DisasContext *ctx, int rt, int rd,
if ((env->CP0_VPEConf0 & (1 << CP0VPEC0_MVP)) == 0 &&
((env->tcs[other_tc].CP0_TCBind & (0xf << CP0TCBd_CurVPE)) !=
- (env->active_tc.CP0_TCBind & (0xf << CP0TCBd_CurVPE))))
+ (env->active_tc.CP0_TCBind & (0xf << CP0TCBd_CurVPE)))) {
tcg_gen_movi_tl(t0, -1);
- else if ((env->CP0_VPEControl & (0xff << CP0VPECo_TargTC)) >
- (env->mvp->CP0_MVPConf0 & (0xff << CP0MVPC0_PTC)))
+ } else if ((env->CP0_VPEControl & (0xff << CP0VPECo_TargTC)) >
+ (env->mvp->CP0_MVPConf0 & (0xff << CP0MVPC0_PTC))) {
tcg_gen_movi_tl(t0, -1);
- else if (u == 0) {
+ } else if (u == 0) {
switch (rt) {
case 1:
switch (sel) {
@@ -9883,12 +9932,12 @@ static void gen_mttr(CPUMIPSState *env, DisasContext *ctx, int rd, int rt,
gen_load_gpr(t0, rt);
if ((env->CP0_VPEConf0 & (1 << CP0VPEC0_MVP)) == 0 &&
((env->tcs[other_tc].CP0_TCBind & (0xf << CP0TCBd_CurVPE)) !=
- (env->active_tc.CP0_TCBind & (0xf << CP0TCBd_CurVPE))))
+ (env->active_tc.CP0_TCBind & (0xf << CP0TCBd_CurVPE)))) {
/* NOP */ ;
- else if ((env->CP0_VPEControl & (0xff << CP0VPECo_TargTC)) >
- (env->mvp->CP0_MVPConf0 & (0xff << CP0MVPC0_PTC)))
+ } else if ((env->CP0_VPEControl & (0xff << CP0VPECo_TargTC)) >
+ (env->mvp->CP0_MVPConf0 & (0xff << CP0MVPC0_PTC))) {
/* NOP */ ;
- else if (u == 0) {
+ } else if (u == 0) {
switch (rd) {
case 1:
switch (sel) {
@@ -10162,8 +10211,9 @@ static void gen_cp0(CPUMIPSState *env, DisasContext *ctx, uint32_t opc,
break;
case OPC_TLBWI:
opn = "tlbwi";
- if (!env->tlb->helper_tlbwi)
+ if (!env->tlb->helper_tlbwi) {
goto die;
+ }
gen_helper_tlbwi(cpu_env);
break;
case OPC_TLBINV:
@@ -10186,20 +10236,23 @@ static void gen_cp0(CPUMIPSState *env, DisasContext *ctx, uint32_t opc,
break;
case OPC_TLBWR:
opn = "tlbwr";
- if (!env->tlb->helper_tlbwr)
+ if (!env->tlb->helper_tlbwr) {
goto die;
+ }
gen_helper_tlbwr(cpu_env);
break;
case OPC_TLBP:
opn = "tlbp";
- if (!env->tlb->helper_tlbp)
+ if (!env->tlb->helper_tlbp) {
goto die;
+ }
gen_helper_tlbp(cpu_env);
break;
case OPC_TLBR:
opn = "tlbr";
- if (!env->tlb->helper_tlbr)
+ if (!env->tlb->helper_tlbr) {
goto die;
+ }
gen_helper_tlbr(cpu_env);
break;
case OPC_ERET: /* OPC_ERETNC */
@@ -10273,8 +10326,9 @@ static void gen_compute_branch1(DisasContext *ctx, uint32_t op,
goto out;
}
- if (cc != 0)
+ if (cc != 0) {
check_insn(ctx, ISA_MIPS4 | ISA_MIPS32);
+ }
btarget = ctx->base.pc_next + 4 + offset;
@@ -10728,10 +10782,11 @@ static void gen_movci(DisasContext *ctx, int rd, int rs, int cc, int tf)
return;
}
- if (tf)
+ if (tf) {
cond = TCG_COND_EQ;
- else
+ } else {
cond = TCG_COND_NE;
+ }
l1 = gen_new_label();
t0 = tcg_temp_new_i32();
@@ -10753,10 +10808,11 @@ static inline void gen_movcf_s(DisasContext *ctx, int fs, int fd, int cc,
TCGv_i32 t0 = tcg_temp_new_i32();
TCGLabel *l1 = gen_new_label();
- if (tf)
+ if (tf) {
cond = TCG_COND_EQ;
- else
+ } else {
cond = TCG_COND_NE;
+ }
tcg_gen_andi_i32(t0, fpu_fcr31, 1 << get_fp_bit(cc));
tcg_gen_brcondi_i32(cond, t0, 0, l1);
@@ -10774,10 +10830,11 @@ static inline void gen_movcf_d(DisasContext *ctx, int fs, int fd, int cc,
TCGv_i64 fp0;
TCGLabel *l1 = gen_new_label();
- if (tf)
+ if (tf) {
cond = TCG_COND_EQ;
- else
+ } else {
cond = TCG_COND_NE;
+ }
tcg_gen_andi_i32(t0, fpu_fcr31, 1 << get_fp_bit(cc));
tcg_gen_brcondi_i32(cond, t0, 0, l1);
@@ -10797,10 +10854,11 @@ static inline void gen_movcf_ps(DisasContext *ctx, int fs, int fd,
TCGLabel *l1 = gen_new_label();
TCGLabel *l2 = gen_new_label();
- if (tf)
+ if (tf) {
cond = TCG_COND_EQ;
- else
+ } else {
cond = TCG_COND_NE;
+ }
tcg_gen_andi_i32(t0, fpu_fcr31, 1 << get_fp_bit(cc));
tcg_gen_brcondi_i32(cond, t0, 0, l1);
@@ -12096,8 +12154,9 @@ static void gen_farith(DisasContext *ctx, enum fopcode op1,
TCGLabel *l1 = gen_new_label();
TCGv_i64 fp0;
- if (ft != 0)
+ if (ft != 0) {
tcg_gen_brcondi_tl(TCG_COND_NE, cpu_gpr[ft], 0, l1);
+ }
fp0 = tcg_temp_new_i64();
gen_load_fpr64(ctx, fp0, fs);
gen_store_fpr64(ctx, fp0, fd);
@@ -29991,12 +30050,14 @@ void mips_cpu_dump_state(CPUState *cs, FILE *f, int flags)
env->active_tc.PC, env->active_tc.HI[0], env->active_tc.LO[0],
env->hflags, env->btarget, env->bcond);
for (i = 0; i < 32; i++) {
- if ((i & 3) == 0)
+ if ((i & 3) == 0) {
qemu_fprintf(f, "GPR%02d:", i);
+ }
qemu_fprintf(f, " %s " TARGET_FMT_lx,
regnames[i], env->active_tc.gpr[i]);
- if ((i & 3) == 3)
+ if ((i & 3) == 3) {
qemu_fprintf(f, "\n");
+ }
}
qemu_fprintf(f, "CP0 Status 0x%08x Cause 0x%08x EPC 0x" TARGET_FMT_lx "\n",
--
2.7.4
^ permalink raw reply related
* [Qemu-devel] [PATCH v3 2/4] MAINTAINERS: Consolidate MIPS disassembler-related items
From: Aleksandar Markovic @ 2019-06-20 10:02 UTC (permalink / raw)
To: qemu-devel; +Cc: arikalo, amarkovic
In-Reply-To: <1561024929-26004-1-git-send-email-aleksandar.markovic@rt-rk.com>
From: Aleksandar Markovic <amarkovic@wavecomp.com>
Eliminate duplicate MIPS disassembler-related items in the
MAINTAINERS file, and use wildcards to shorten the list of
involved files.
Signed-off-by: Aleksandar Markovic <amarkovic@wavecomp.com>
---
MAINTAINERS | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 869e87b..f9f66e5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -212,9 +212,7 @@ R: Aleksandar Rikalo <arikalo@wavecomp.com>
S: Maintained
F: target/mips/
F: default-configs/*mips*
-F: disas/mips.c
-F: disas/nanomips.cpp
-F: disas/nanomips.h
+F: disas/*mips*
F: hw/intc/mips_gic.c
F: hw/mips/
F: hw/misc/mips_*
@@ -2321,7 +2319,6 @@ M: Aurelien Jarno <aurelien@aurel32.net>
R: Aleksandar Rikalo <arikalo@wavecomp.com>
S: Maintained
F: tcg/mips/
-F: disas/mips.c
PPC TCG target
M: Richard Henderson <rth@twiddle.net>
--
2.7.4
^ permalink raw reply related
* RE: [PATCH V2 2/2] mailbox: introduce ARM SMC based mailbox
From: Peng Fan @ 2019-06-20 10:21 UTC (permalink / raw)
To: Sudeep Holla
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
f.fainelli@gmail.com, festevam@gmail.com,
jassisinghbrar@gmail.com, linux-kernel@vger.kernel.org,
robh+dt@kernel.org, dl-linux-imx, kernel@pengutronix.de,
andre.przywara@arm.com, van.freenix@gmail.com,
shawnguo@kernel.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190620092301.GD1248@e107155-lin>
Hi Sudeep,
> Subject: Re: [PATCH V2 2/2] mailbox: introduce ARM SMC based mailbox
>
> On Mon, Jun 03, 2019 at 04:30:05PM +0800, peng.fan@nxp.com wrote:
> > From: Peng Fan <peng.fan@nxp.com>
> >
> > This mailbox driver implements a mailbox which signals transmitted
> > data via an ARM smc (secure monitor call) instruction. The mailbox
> > receiver is implemented in firmware and can synchronously return data
> > when it returns execution to the non-secure world again.
> > An asynchronous receive path is not implemented.
> > This allows the usage of a mailbox to trigger firmware actions on SoCs
> > which either don't have a separate management processor or on which
> > such a core is not available. A user of this mailbox could be the SCP
> > interface.
> >
> > Modified from Andre Przywara's v2 patch
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
> > .kernel.org%2Fpatchwork%2Fpatch%2F812999%2F&data=02%7C01%7
> Cpeng.fa
> >
> n%40nxp.com%7C6b37f78032e446be750e08d6f560e707%7C686ea1d3bc2b4
> c6fa92cd
> >
> 99c5c301635%7C0%7C0%7C636966193913988679&sdata=UNM4MTPs
> brqoMqWStEy
> > YzzwMEWTmX7hHO3TeNEz%2BOAw%3D&reserved=0
> >
> > Cc: Andre Przywara <andre.przywara@arm.com>
> > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > ---
> >
> > V2:
> > Add interrupts notification support.
> >
> > drivers/mailbox/Kconfig | 7 ++
> > drivers/mailbox/Makefile | 2 +
> > drivers/mailbox/arm-smc-mailbox.c | 190
> ++++++++++++++++++++++++++++++++
> > include/linux/mailbox/arm-smc-mailbox.h | 10 ++
> > 4 files changed, 209 insertions(+)
> > create mode 100644 drivers/mailbox/arm-smc-mailbox.c create mode
> > 100644 include/linux/mailbox/arm-smc-mailbox.h
> >
> > diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig index
> > 595542bfae85..c3bd0f1ddcd8 100644
> > --- a/drivers/mailbox/Kconfig
> > +++ b/drivers/mailbox/Kconfig
> > @@ -15,6 +15,13 @@ config ARM_MHU
> > The controller has 3 mailbox channels, the last of which can be
> > used in Secure mode only.
> >
> > +config ARM_SMC_MBOX
> > + tristate "Generic ARM smc mailbox"
> > + depends on OF && HAVE_ARM_SMCCC
> > + help
> > + Generic mailbox driver which uses ARM smc calls to call into
> > + firmware for triggering mailboxes.
> > +
> > config IMX_MBOX
> > tristate "i.MX Mailbox"
> > depends on ARCH_MXC || COMPILE_TEST
> > diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile index
> > c22fad6f696b..93918a84c91b 100644
> > --- a/drivers/mailbox/Makefile
> > +++ b/drivers/mailbox/Makefile
> > @@ -7,6 +7,8 @@ obj-$(CONFIG_MAILBOX_TEST) += mailbox-test.o
> >
> > obj-$(CONFIG_ARM_MHU) += arm_mhu.o
> >
> > +obj-$(CONFIG_ARM_SMC_MBOX) += arm-smc-mailbox.o
> > +
> > obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o
> >
> > obj-$(CONFIG_ARMADA_37XX_RWTM_MBOX) +=
> armada-37xx-rwtm-mailbox.o
> > diff --git a/drivers/mailbox/arm-smc-mailbox.c
> > b/drivers/mailbox/arm-smc-mailbox.c
> > new file mode 100644
> > index 000000000000..fef6e38d8b98
> > --- /dev/null
> > +++ b/drivers/mailbox/arm-smc-mailbox.c
> > @@ -0,0 +1,190 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2016,2017 ARM Ltd.
> > + * Copyright 2019 NXP
> > + */
> > +
> > +#include <linux/arm-smccc.h>
> > +#include <linux/device.h>
> > +#include <linux/kernel.h>
> > +#include <linux/interrupt.h>
> > +#include <linux/mailbox_controller.h> #include
> > +<linux/mailbox/arm-smc-mailbox.h>
> > +#include <linux/module.h>
> > +#include <linux/platform_device.h>
> > +
> > +#define ARM_SMC_MBOX_USE_HVC BIT(0)
> > +#define ARM_SMC_MBOX_USB_IRQ BIT(1)
> > +
> > +struct arm_smc_chan_data {
> > + u32 function_id;
> > + u32 flags;
> > + int irq;
> > +};
> > +
> > +static int arm_smc_send_data(struct mbox_chan *link, void *data) {
> > + struct arm_smc_chan_data *chan_data = link->con_priv;
> > + struct arm_smccc_mbox_cmd *cmd = data;
> > + struct arm_smccc_res res;
> > + u32 function_id;
> > +
> > + if (chan_data->function_id != UINT_MAX)
> > + function_id = chan_data->function_id;
> > + else
> > + function_id = cmd->a0;
> > +
> > + if (chan_data->flags & ARM_SMC_MBOX_USE_HVC)
> > + arm_smccc_hvc(function_id, cmd->a1, cmd->a2, cmd->a3,
> cmd->a4,
> > + cmd->a5, cmd->a6, cmd->a7, &res);
> > + else
> > + arm_smccc_smc(function_id, cmd->a1, cmd->a2, cmd->a3,
> cmd->a4,
> > + cmd->a5, cmd->a6, cmd->a7, &res);
> > +
>
> So how will the SMC/HVC handler in EL3/2 find which mailbox is being
> referred with this command ? I prefer 2nd argument to be the mailbox
> number.
You mean channel number as following?
@@ -37,10 +38,10 @@ static int arm_smc_send_data(struct mbox_chan *link, void *data)
function_id = cmd->a0;
if (chan_data->flags & ARM_SMC_MBOX_USE_HVC)
- arm_smccc_hvc(function_id, cmd->a1, cmd->a2, cmd->a3, cmd->a4,
+ arm_smccc_hvc(function_id, chan_data->chan_id, cmd->a2, cmd->a3, cmd->a4,
cmd->a5, cmd->a6, cmd->a7, &res);
else
- arm_smccc_smc(function_id, cmd->a1, cmd->a2, cmd->a3, cmd->a4,
+ arm_smccc_smc(function_id, chan_data->chan_id, cmd->a2, cmd->a3, cmd->a4,
cmd->a5, cmd->a6, cmd->a7, &res);
Or should that be passed from firmware driver?
If not from firmware driver, just as above, I do not have a good idea which should be passed to smc,
from cmd->a1 to a5 or from cmd->a2 to a6.
Thanks,
Peng.
>
> --
> Regards,
> Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH V2 2/2] mailbox: introduce ARM SMC based mailbox
From: Peng Fan @ 2019-06-20 10:21 UTC (permalink / raw)
To: Sudeep Holla
Cc: robh+dt@kernel.org, mark.rutland@arm.com,
jassisinghbrar@gmail.com, f.fainelli@gmail.com,
kernel@pengutronix.de, dl-linux-imx, shawnguo@kernel.org,
festevam@gmail.com, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, andre.przywara@arm.com,
van.freenix@gmail.com
In-Reply-To: <20190620092301.GD1248@e107155-lin>
Hi Sudeep,
> Subject: Re: [PATCH V2 2/2] mailbox: introduce ARM SMC based mailbox
>
> On Mon, Jun 03, 2019 at 04:30:05PM +0800, peng.fan@nxp.com wrote:
> > From: Peng Fan <peng.fan@nxp.com>
> >
> > This mailbox driver implements a mailbox which signals transmitted
> > data via an ARM smc (secure monitor call) instruction. The mailbox
> > receiver is implemented in firmware and can synchronously return data
> > when it returns execution to the non-secure world again.
> > An asynchronous receive path is not implemented.
> > This allows the usage of a mailbox to trigger firmware actions on SoCs
> > which either don't have a separate management processor or on which
> > such a core is not available. A user of this mailbox could be the SCP
> > interface.
> >
> > Modified from Andre Przywara's v2 patch
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
> > .kernel.org%2Fpatchwork%2Fpatch%2F812999%2F&data=02%7C01%7
> Cpeng.fa
> >
> n%40nxp.com%7C6b37f78032e446be750e08d6f560e707%7C686ea1d3bc2b4
> c6fa92cd
> >
> 99c5c301635%7C0%7C0%7C636966193913988679&sdata=UNM4MTPs
> brqoMqWStEy
> > YzzwMEWTmX7hHO3TeNEz%2BOAw%3D&reserved=0
> >
> > Cc: Andre Przywara <andre.przywara@arm.com>
> > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > ---
> >
> > V2:
> > Add interrupts notification support.
> >
> > drivers/mailbox/Kconfig | 7 ++
> > drivers/mailbox/Makefile | 2 +
> > drivers/mailbox/arm-smc-mailbox.c | 190
> ++++++++++++++++++++++++++++++++
> > include/linux/mailbox/arm-smc-mailbox.h | 10 ++
> > 4 files changed, 209 insertions(+)
> > create mode 100644 drivers/mailbox/arm-smc-mailbox.c create mode
> > 100644 include/linux/mailbox/arm-smc-mailbox.h
> >
> > diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig index
> > 595542bfae85..c3bd0f1ddcd8 100644
> > --- a/drivers/mailbox/Kconfig
> > +++ b/drivers/mailbox/Kconfig
> > @@ -15,6 +15,13 @@ config ARM_MHU
> > The controller has 3 mailbox channels, the last of which can be
> > used in Secure mode only.
> >
> > +config ARM_SMC_MBOX
> > + tristate "Generic ARM smc mailbox"
> > + depends on OF && HAVE_ARM_SMCCC
> > + help
> > + Generic mailbox driver which uses ARM smc calls to call into
> > + firmware for triggering mailboxes.
> > +
> > config IMX_MBOX
> > tristate "i.MX Mailbox"
> > depends on ARCH_MXC || COMPILE_TEST
> > diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile index
> > c22fad6f696b..93918a84c91b 100644
> > --- a/drivers/mailbox/Makefile
> > +++ b/drivers/mailbox/Makefile
> > @@ -7,6 +7,8 @@ obj-$(CONFIG_MAILBOX_TEST) += mailbox-test.o
> >
> > obj-$(CONFIG_ARM_MHU) += arm_mhu.o
> >
> > +obj-$(CONFIG_ARM_SMC_MBOX) += arm-smc-mailbox.o
> > +
> > obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o
> >
> > obj-$(CONFIG_ARMADA_37XX_RWTM_MBOX) +=
> armada-37xx-rwtm-mailbox.o
> > diff --git a/drivers/mailbox/arm-smc-mailbox.c
> > b/drivers/mailbox/arm-smc-mailbox.c
> > new file mode 100644
> > index 000000000000..fef6e38d8b98
> > --- /dev/null
> > +++ b/drivers/mailbox/arm-smc-mailbox.c
> > @@ -0,0 +1,190 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2016,2017 ARM Ltd.
> > + * Copyright 2019 NXP
> > + */
> > +
> > +#include <linux/arm-smccc.h>
> > +#include <linux/device.h>
> > +#include <linux/kernel.h>
> > +#include <linux/interrupt.h>
> > +#include <linux/mailbox_controller.h> #include
> > +<linux/mailbox/arm-smc-mailbox.h>
> > +#include <linux/module.h>
> > +#include <linux/platform_device.h>
> > +
> > +#define ARM_SMC_MBOX_USE_HVC BIT(0)
> > +#define ARM_SMC_MBOX_USB_IRQ BIT(1)
> > +
> > +struct arm_smc_chan_data {
> > + u32 function_id;
> > + u32 flags;
> > + int irq;
> > +};
> > +
> > +static int arm_smc_send_data(struct mbox_chan *link, void *data) {
> > + struct arm_smc_chan_data *chan_data = link->con_priv;
> > + struct arm_smccc_mbox_cmd *cmd = data;
> > + struct arm_smccc_res res;
> > + u32 function_id;
> > +
> > + if (chan_data->function_id != UINT_MAX)
> > + function_id = chan_data->function_id;
> > + else
> > + function_id = cmd->a0;
> > +
> > + if (chan_data->flags & ARM_SMC_MBOX_USE_HVC)
> > + arm_smccc_hvc(function_id, cmd->a1, cmd->a2, cmd->a3,
> cmd->a4,
> > + cmd->a5, cmd->a6, cmd->a7, &res);
> > + else
> > + arm_smccc_smc(function_id, cmd->a1, cmd->a2, cmd->a3,
> cmd->a4,
> > + cmd->a5, cmd->a6, cmd->a7, &res);
> > +
>
> So how will the SMC/HVC handler in EL3/2 find which mailbox is being
> referred with this command ? I prefer 2nd argument to be the mailbox
> number.
You mean channel number as following?
@@ -37,10 +38,10 @@ static int arm_smc_send_data(struct mbox_chan *link, void *data)
function_id = cmd->a0;
if (chan_data->flags & ARM_SMC_MBOX_USE_HVC)
- arm_smccc_hvc(function_id, cmd->a1, cmd->a2, cmd->a3, cmd->a4,
+ arm_smccc_hvc(function_id, chan_data->chan_id, cmd->a2, cmd->a3, cmd->a4,
cmd->a5, cmd->a6, cmd->a7, &res);
else
- arm_smccc_smc(function_id, cmd->a1, cmd->a2, cmd->a3, cmd->a4,
+ arm_smccc_smc(function_id, chan_data->chan_id, cmd->a2, cmd->a3, cmd->a4,
cmd->a5, cmd->a6, cmd->a7, &res);
Or should that be passed from firmware driver?
If not from firmware driver, just as above, I do not have a good idea which should be passed to smc,
from cmd->a1 to a5 or from cmd->a2 to a6.
Thanks,
Peng.
>
> --
> Regards,
> Sudeep
^ permalink raw reply
* Re: [PATCH] fetch: only run 'gc' once when fetching multiple remotes
From: Jeff King @ 2019-06-20 10:21 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Git Mailing List
In-Reply-To: <CACsJy8A5K4hNKy1LupQJ8is4AgTAyzfW+qhMYkcBmS_kvnE23Q@mail.gmail.com>
On Thu, Jun 20, 2019 at 05:11:03PM +0700, Duy Nguyen wrote:
> > Another option would be to just pass "-c gc.auto=0" to the child
> > processes to inhibit auto-gc. But maybe it makes sense to have a nicer
> > interface (after all, somebody else could be doing the same "let's do a
> > bunch of fetches in a row" without using the multi-fetch code).
>
> Nah to me -c is much nicer (and flexible too). The only thing I'm not
> sure about is whether a user could override it. If fetch.c adds -c
> gc.auto=0 automatically, and the user wants auto gc back, will "git -c
> gc.auto=non-zero fetch --multiple" still work?
>
> I haven't checked git_config_push_parameter() carefully, but I have an
> impression that the parameter order there is "wrong", at least in this
> case.
It depends what you're trying to get it to do.
I'd expect that command to turn on auto-gc for just the outer fetch
(i.e., overriding any on-disk disabling of auto-gc), but keep it off for
the child fetches. And I think that is how it would behave: the outer
fetch only sees the config you provided. The inner ones see
"gc.auto=non-zero gc.auto=0-zero" because git_config_push_parameter()
appends. And they accept the latter under last-one-wins rules.
If you expect to be able to re-enable auto-gc in the child fetches, then
I don't think there would be a way to do that.
> > Though there I kind of wonder if this would apply to other scripted
> > uses, too. E.g., if I'm doing a bunch of commits, I might want to
> > inhibit auto-gc and then run it myself at the end. Should we support
> > "GIT_AUTO_GC=0" in the environment (and a matching "git --no-auto-gc
> > ..." option that could be used here)?
>
> export GIT_CONFIG=gc.auto=0 ?
Almost. The parser for GIT_CONFIG_PARAMETERS is very picky about seeing
single quotes around each item, which makes it a little unfriendly to
use manually. Plus there may be existing values if your script was
invoked as "git -c whatever my-script".
It's probably not that big a deal for a script to just use "git -c
gc.auto" to inhibit auto-gc for each command that needs it.
-Peff
^ permalink raw reply
* Re: [dpdk-dev] [PATCH v2 02/10] meson: add BUILDING_RTE_SDK
From: Bruce Richardson @ 2019-06-20 10:20 UTC (permalink / raw)
To: Neil Horman; +Cc: dev, Jerin Jacob Kollanukkaran, Thomas Monjalon
In-Reply-To: <20190619183443.GC19712@hmswarspite.think-freely.org>
On Wed, Jun 19, 2019 at 02:34:43PM -0400, Neil Horman wrote:
> On Wed, Jun 19, 2019 at 11:46:12AM +0100, Bruce Richardson wrote:
> > On Wed, Jun 19, 2019 at 06:39:00AM -0400, Neil Horman wrote:
> > > On Thu, Jun 13, 2019 at 03:44:02PM +0100, Bruce Richardson wrote:
> > > > On Thu, Jun 13, 2019 at 10:23:36AM -0400, Neil Horman wrote:
> > > > > The __rte_internal macro is defined dependent on the value of the build
> > > > > environment variable BUILDING_RTE_SDK. This variable was set in the
> > > > > Makefile environment but not the meson environment, so lets reconcile
> > > > > the two by defining it for meson in the lib and drivers directories, but
> > > > > not the examples/apps directories, which should be treated as they are
> > > > > not part of the core DPDK library
> > > > >
> > > > > Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> > > > > CC: Jerin Jacob Kollanukkaran <jerinj@marvell.com>
> > > > > CC: Bruce Richardson <bruce.richardson@intel.com>
> > > > > CC: Thomas Monjalon <thomas@monjalon.net>
> > > > > ---
> > > > > drivers/meson.build | 1 +
> > > > > lib/meson.build | 1 +
> > > > > 2 files changed, 2 insertions(+)
> > > > >
> > > > > diff --git a/drivers/meson.build b/drivers/meson.build
> > > > > index 4c444f495..a312277d1 100644
> > > > > --- a/drivers/meson.build
> > > > > +++ b/drivers/meson.build
> > > > > @@ -23,6 +23,7 @@ endif
> > > > >
> > > > > # specify -D_GNU_SOURCE unconditionally
> > > > > default_cflags += '-D_GNU_SOURCE'
> > > > > +default_cflags += '-DBUILDING_RTE_SDK'
> > > > >
> > > > > foreach class:dpdk_driver_classes
> > > > > drivers = []
> > > > > diff --git a/lib/meson.build b/lib/meson.build
> > > > > index e067ce5ea..0e398d534 100644
> > > > > --- a/lib/meson.build
> > > > > +++ b/lib/meson.build
> > > > > @@ -35,6 +35,7 @@ if is_windows
> > > > > endif
> > > > >
> > > > > default_cflags = machine_args
> > > > > +default_cflags += '-DBUILDING_RTE_SDK'
> > > > > if cc.has_argument('-Wno-format-truncation')
> > > > > default_cflags += '-Wno-format-truncation'
> > > > > endif
> > > >
> > > > While this will work, it's not something that individual components should
> > > > ever need to override so I think using "add_project_arguments()" function
> > > > is a better way to add this to the C builds.
> > > >
> > > That sounds like it makes sense to me, but reading the documentation for meson,
> > > I'm not sure I see the behavioral difference. Can you elaborate on how
> > > add_project_arguments behaves differently here?
> > >
> > The end result should be the same. The key differences are:
> > 1. Only ever needs to be set in one place
> > 2. Cannot be overridden by the individual objects in the build.
> >
> > So it's just slightly cleaner. If you prefer your existing approach, I'm ok
> > with that.
> >
>
> No, I like the aspect of item 2, though, just for clarification, do we really
> only need to set it at the top level? I ask because it seems that
> BUILDING_RTE_SDK should be set for the lib and drivers subtrees, but not the app
> subtree, as that tree, being the location of our example code, should be treated
> as non-core dpdk libraries, and so should throw an error if any code there
> attempts to use a dpdk internal only function. Or is there some other magic
> afoot in that subtree?
>
Good point. Keep your original patch as-is so.
/Bruce
^ permalink raw reply
* Re: [PATCH net-next] br_netfilter: prevent UAF in brnf_exit_net()
From: Pablo Neira Ayuso @ 2019-06-20 10:20 UTC (permalink / raw)
To: Christian Brauner
Cc: syzbot+43a3fa52c0d9c5c94f41, netdev, netfilter-devel,
linux-kernel, a.hajda, airlied, airlied, alexander.deucher,
bridge, christian.koenig, coreteam, daniel, davem, dri-devel,
enric.balletbo, fw, harry.wentland, heiko, intel-gfx, jani.nikula,
jerry.zhang, jonas, joonas.lahtinen, kadlec, laurent.pinchart,
maarten.lankhorst, marc.zyngier, maxime.ripard, narmstrong,
nikolay, patrik.r.jakobsson, rodrigo.vivi, roopa, sam, sean, sfr,
syzkaller-bugs
In-Reply-To: <20190619170547.6290-1-christian@brauner.io>
On Wed, Jun 19, 2019 at 07:05:47PM +0200, Christian Brauner wrote:
> Prevent a UAF in brnf_exit_net().
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] br_netfilter: prevent UAF in brnf_exit_net()
From: Pablo Neira Ayuso @ 2019-06-20 10:20 UTC (permalink / raw)
To: Christian Brauner
Cc: syzbot+43a3fa52c0d9c5c94f41, netdev, netfilter-devel,
linux-kernel, a.hajda, airlied, airlied, alexander.deucher,
bridge, christian.koenig, coreteam, daniel, davem, dri-devel,
enric.balletbo, fw, harry.wentland, heiko, intel-gfx, jani.nikula,
jerry.zhang, jonas, joonas.lahtinen, kadlec, laurent.pinchart,
maarten.lankhorst, marc.zyngier, maxime.ripard, narmstrong,
nikolay
In-Reply-To: <20190619170547.6290-1-christian@brauner.io>
On Wed, Jun 19, 2019 at 07:05:47PM +0200, Christian Brauner wrote:
> Prevent a UAF in brnf_exit_net().
Applied, thanks.
^ permalink raw reply
* Re: [Bridge] [PATCH net-next] br_netfilter: prevent UAF in brnf_exit_net()
From: Pablo Neira Ayuso @ 2019-06-20 10:20 UTC (permalink / raw)
To: Christian Brauner
Cc: heiko, narmstrong, airlied, joonas.lahtinen, dri-devel, a.hajda,
laurent.pinchart, sam, sfr, nikolay, bridge, patrik.r.jakobsson,
kadlec, maxime.ripard, coreteam, airlied, harry.wentland, roopa,
jonas, marc.zyngier, syzkaller-bugs, intel-gfx, maarten.lankhorst,
jani.nikula, alexander.deucher, rodrigo.vivi, jerry.zhang, sean,
netdev, fw, linux-kernel, christian.koenig,
syzbot+43a3fa52c0d9c5c94f41, netfilter-devel, daniel,
enric.balletbo, davem
In-Reply-To: <20190619170547.6290-1-christian@brauner.io>
On Wed, Jun 19, 2019 at 07:05:47PM +0200, Christian Brauner wrote:
> Prevent a UAF in brnf_exit_net().
Applied, thanks.
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v10] ssh: switch from libssh2 to libssh
From: Daniel P. Berrangé @ 2019-06-20 10:11 UTC (permalink / raw)
To: Max Reitz
Cc: kwolf, fam, qemu-block, rjones, sw, qemu-devel, Pino Toscano,
alex.bennee, philmd
In-Reply-To: <ca41c9ef-aa6d-2e17-42a0-3a1beb42e208@redhat.com>
On Tue, Jun 18, 2019 at 03:14:30PM +0200, Max Reitz wrote:
> On 18.06.19 11:24, Pino Toscano wrote:
> > Rewrite the implementation of the ssh block driver to use libssh instead
> > of libssh2. The libssh library has various advantages over libssh2:
> > - easier API for authentication (for example for using ssh-agent)
> > - easier API for known_hosts handling
> > - supports newer types of keys in known_hosts
> >
> > Use APIs/features available in libssh 0.8 conditionally, to support
> > older versions (which are not recommended though).
> >
> > Adjust the tests according to the different error message, and to the
> > newer host keys (ed25519) that are used by default with OpenSSH >= 6.7
> > and libssh >= 0.7.0.
> >
> > Adjust the various Docker/Travis scripts to use libssh when available
> > instead of libssh2. The mingw/mxe testing is dropped for now, as there
> > are no packages for it.
> >
> > Signed-off-by: Pino Toscano <ptoscano@redhat.com>
> > Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
> > Acked-by: Alex Bennée <alex.bennee@linaro.org>
> > ---
> >
> > Changes from v9:
> > - restored "default" case in the server status switch for libssh < 0.8.0
> > - print the host key type & fingerprint on mismatch with known_hosts
> > - improve/fix message for failed socket_set_nodelay()
> > - reset s->sock properly
> >
> > Changes from v8:
> > - use a newer key type in iotest 207
> > - improve the commit message
> >
> > Changes from v7:
> > - #if HAVE_LIBSSH_0_8 -> #ifdef HAVE_LIBSSH_0_8
> > - ptrdiff_t -> size_t
> >
> > Changes from v6:
> > - fixed few checkpatch style issues
> > - detect libssh 0.8 via symbol detection
> > - adjust travis/docker test material
> > - remove dead "default" case in a switch
> > - use variables for storing MIN() results
> > - adapt a documentation bit
> >
> > Changes from v5:
> > - adapt to newer tracing APIs
> > - disable ssh compression (mimic what libssh2 does by default)
> > - use build time checks for libssh 0.8, and use newer APIs directly
> >
> > Changes from v4:
> > - fix wrong usages of error_setg/session_error_setg/sftp_error_setg
> > - fix few return code checks
> > - remove now-unused parameters in few internal functions
> > - allow authentication with "none" method
> > - switch to unsigned int for the port number
> > - enable TCP_NODELAY on the socket
> > - fix one reference error message in iotest 207
> >
> > Changes from v3:
> > - fix socket cleanup in connect_to_ssh()
> > - add comments about the socket cleanup
> > - improve the error reporting (closer to what was with libssh2)
> > - improve EOF detection on sftp_read()
> >
> > Changes from v2:
> > - used again an own fd
> > - fixed co_yield() implementation
> >
> > Changes from v1:
> > - fixed jumbo packets writing
> > - fixed missing 'err' assignment
> > - fixed commit message
> >
> > .travis.yml | 4 +-
> > block/Makefile.objs | 6 +-
> > block/ssh.c | 665 ++++++++++--------
> > block/trace-events | 14 +-
> > configure | 65 +-
> > docs/qemu-block-drivers.texi | 2 +-
> > .../dockerfiles/debian-win32-cross.docker | 1 -
> > .../dockerfiles/debian-win64-cross.docker | 1 -
> > tests/docker/dockerfiles/fedora.docker | 4 +-
> > tests/docker/dockerfiles/ubuntu.docker | 2 +-
> > tests/docker/dockerfiles/ubuntu1804.docker | 2 +-
> > tests/qemu-iotests/207 | 4 +-
> > tests/qemu-iotests/207.out | 2 +-
> > 13 files changed, 423 insertions(+), 349 deletions(-)
>
> [...]
>
> > diff --git a/block/ssh.c b/block/ssh.c
> > index 6da7b9cbfe..644ae8b82c 100644
> > --- a/block/ssh.c
> > +++ b/block/ssh.c
>
> [...]
>
> > + case SSH_SERVER_KNOWN_CHANGED:
> > + ret = -EINVAL;
> > + r = ssh_get_publickey(s->session, &pubkey);
> > + if (r == 0) {
> > + r = ssh_get_publickey_hash(pubkey, SSH_PUBLICKEY_HASH_SHA1,
> > + &server_hash, &server_hash_len);
> > + pubkey_type = ssh_key_type(pubkey);
> > + ssh_key_free(pubkey);
> > + }
> > + if (r == 0) {
> > + fingerprint = ssh_get_fingerprint_hash(SSH_PUBLICKEY_HASH_SHA1,
> > + server_hash,
> > + server_hash_len);
> > + ssh_clean_pubkey_hash(&server_hash);
> > + }
> > + if (fingerprint) {
> > + error_setg(errp,
> > + "host key (%s key with fingerprint %s) does not match "
> > + "the one in known_hosts",
> > + ssh_key_type_to_char(pubkey_type), fingerprint);
> > + ssh_string_free_char(fingerprint);
> > + } else {
> > + error_setg(errp, "host key does not match the one in known_hosts");
> > + }
>
> Usually I’d say that more information can’t be bad. But here I don’t
> see how this additional information is useful. known_hosts contains
> base64-encoded full public keys. This only prints the SHA-1 digest.
> The user cannot add that to known_hosts, or easily scan known_hosts to
> see whether it perhaps belongs to some other hosts (maybe because DHCP
> scrambled something).
>
> Actually, even if this printed the base64 representation of the full
> key, the user probably wouldn’t just add that to known_hosts or do
> anything with it. They’ll debug the problem with other tools.
>
> So I don’t think this new information is really useful...?
>
>
> (Hmm, I don’t know if this is a response to my “But the specification
> requires a warning!!1!”, but if so, I was actually not referring to more
> information but to this:
>
> $ ssh 192.168.0.12
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
> Someone could be eavesdropping on you right now (man-in-the-middle attack)!
> It is also possible that a host key has just been changed.
>
>
> I mean, I was also only half-serious. I should be serious because the
> libssh specification requires us to print some warning like that, but,
> well. Yes, I’ll stop mumbling about this stuff now.)
Those giant messages are targetted at humans though so I'm not so
convinced it is useful for apps managing QEMU. IMHO it is sufficient
to just report a simple error that the host ident check failed as
the patch does now. It gives enough info to then investigate further
to identify the root cause problems.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
^ permalink raw reply
* Re: [PATCH] netfilter: synproxy: fix building syncookie calls
From: Pablo Neira Ayuso @ 2019-06-20 10:20 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Jozsef Kadlecsik, Florian Westphal, David S. Miller,
Alexey Kuznetsov, Hideaki YOSHIFUJI, Fernando Fernandez Mancera,
wenxu, netfilter-devel, coreteam, linux-kernel, netdev
In-Reply-To: <20190619125500.1054426-1-arnd@arndb.de>
On Wed, Jun 19, 2019 at 02:54:36PM +0200, Arnd Bergmann wrote:
> When either CONFIG_IPV6 or CONFIG_SYN_COOKIES are disabled, the kernel
> fails to build:
>
> include/linux/netfilter_ipv6.h:180:9: error: implicit declaration of function '__cookie_v6_init_sequence'
> [-Werror,-Wimplicit-function-declaration]
> return __cookie_v6_init_sequence(iph, th, mssp);
> include/linux/netfilter_ipv6.h:194:9: error: implicit declaration of function '__cookie_v6_check'
> [-Werror,-Wimplicit-function-declaration]
> return __cookie_v6_check(iph, th, cookie);
> net/ipv6/netfilter.c:237:26: error: use of undeclared identifier '__cookie_v6_init_sequence'; did you mean 'cookie_init_sequence'?
> net/ipv6/netfilter.c:238:21: error: use of undeclared identifier '__cookie_v6_check'; did you mean '__cookie_v4_check'?
>
> Fix the IS_ENABLED() checks to match the function declaration
> and definitions for these.
Applied, thanks Arnd.
^ permalink raw reply
* [Bug 203923] Running a nested freedos on AMD Athlon i686-pae results in NULL pointer dereference in L0 (kvm_mmu_load)
From: bugzilla-daemon @ 2019-06-20 10:19 UTC (permalink / raw)
To: kvm
In-Reply-To: <bug-203923-28872@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=203923
Paolo Bonzini (bonzini@gnu.org) changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |bonzini@gnu.org
--- Comment #2 from Paolo Bonzini (bonzini@gnu.org) ---
A patch for this is on its way to Linus.
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* Re: [Qemu-riscv] TLB refresh issue
From: Quentin Mundell @ 2019-06-20 9:32 UTC (permalink / raw)
To: qemu-riscv@nongnu.org
In-Reply-To: <CANnJOVEAbK1Bc+TTE9xGozDcxTt6ezpdDnpQ+LRafgV-1gy=ug@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2413 bytes --]
Sorry, there was a typo in the commit hash, here is the good one: https://github.com/qemu/qemu/commit/c7b951718815694284501ed01fec7acb8654db7b#diff-f5f017ee174677b23830531cab545e78L531
I have double checked my vma fences and I think the logic behind is correct (I only flush when needed with regard to ASIDs).
As a test, I have added a full `sfence.vma` barrier after every `satp` write: I still have the same random crashes.
QM.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, June 19, 2019 7:30 PM, Jonathan Behrens <fintelia@gmail.com> wrote:
> I wasn't able to find the commit you bisected to, but is your code executing a `sfence.vma` instruction after every instance that it changes satp? Until recently this wasn't necessary with QEMU because QEMU flushed the TLB more aggressively than required by the spec, but [the behavior was chayou are referringnged in a recent commit](https://github.com/qemu/qemu/commit/1e0d985fa9136a563168a3da66f3d17820404ee2#diff-243969738b77de10c014622a3d749a44).
>
> Jonathan
>
> On Wed, Jun 19, 2019 at 11:46 AM Quentin Mundell via Qemu-riscv <qemu-riscv@nongnu.org> wrote:
>
>> Hello,
>>
>> I have updated my QEMU version (from 3.x to today's master).
>> I now get all sort of weird and not easily reproducible exceptions triggered in my risc-v guest, happening from both user and supervisor mode.
>>
>> The command I use is roughly `qemu-system-riscv64 -machine sifive_u -m 1024 -kernel mybinary.elf` (sorry, I cannot share the elf).
>>
>> I have bisected this issue back to commit c7b95171881569284501ed01fec7acb8654db7b.
>> Some TLB flushes were removed in the following places:
>> target/riscv/cpu_helper.c: `csr_write_helper(env, s, CSR_MSTATUS);` -> `env->mstatus = s;` (twice)
>> target/riscv/op_helper.c: `csr_write_helper(env, s, CSR_MSTATUS);` -> `env->mstatus = s;` (twice)
>> These are the places where the privileged mode is switched.
>>
>> If I add them back (`tlb_flush(env_cpu(env));`), everything is fine again.
>>
>> However, in the `riscv_cpu_set_mode` function, I see the following comment:
>>> tlb_flush is unnecessary as mode is contained in mmu_idx
>> It would suggest adding back TLB flushes is not the way to go...
>>
>> Does someone with better knowledge of the codebase can tell me how to proceed here?
>> - Should I submit a patch adding back the TLB flushes?
>> - Is it an issue somewhere else?
>>
>> Regards
>> QM
[-- Attachment #2: Type: text/html, Size: 3444 bytes --]
^ permalink raw reply
* Re: [PATCH v2 43/52] powerpc/64s/exception: machine check early only runs in HV mode
From: Nicholas Piggin @ 2019-06-20 10:16 UTC (permalink / raw)
To: mahesh; +Cc: linuxppc-dev
In-Reply-To: <20190620095329.rvrwxgtjsgkc4k5t@in.ibm.com>
Mahesh J Salgaonkar's on June 20, 2019 7:53 pm:
> On 2019-06-20 15:14:50 Thu, Nicholas Piggin wrote:
>> machine_check_common_early and machine_check_handle_early only run in
>> HVMODE. Remove dead code.
>
> That's not true. For pseries guest with FWNMI enabled hypervisor,
> machine_check_common_early gets called in non-HV mode as well.
>
> machine_check_fwnmi
> machine_check_common_early
> machine_check_handle_early
> machine_check_early
> pseries_machine_check_realmode
Yep, yep I was confused by the earlier patch. So we're only doing the
early machine check path for the FWNMI case?
Thanks,
Nick
^ permalink raw reply
* [U-Boot] [PATCH 1/1] efi_loader: move efi_query_variable_info()
From: Heinrich Schuchardt @ 2019-06-20 10:18 UTC (permalink / raw)
To: u-boot
Let's keep similar things together.
Move efi_query_variable_info() to lib/efi_loader/efi_variable.c
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
---
include/efi_loader.h | 5 +++++
lib/efi_loader/efi_runtime.c | 27 ---------------------------
lib/efi_loader/efi_variable.c | 27 +++++++++++++++++++++++++++
3 files changed, 32 insertions(+), 27 deletions(-)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index b07155cecb..de1e67fd40 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -618,6 +618,11 @@ efi_status_t EFIAPI efi_set_variable(u16 *variable_name,
const efi_guid_t *vendor, u32 attributes,
efi_uintn_t data_size, const void *data);
+efi_status_t EFIAPI efi_query_variable_info(
+ u32 attributes, u64 *maximum_variable_storage_size,
+ u64 *remaining_variable_storage_size,
+ u64 *maximum_variable_size);
+
/*
* See section 3.1.3 in the v2.7 UEFI spec for more details on
* the layout of EFI_LOAD_OPTION. In short it is:
diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
index 40fdc0ea92..dd91880ad6 100644
--- a/lib/efi_loader/efi_runtime.c
+++ b/lib/efi_loader/efi_runtime.c
@@ -782,33 +782,6 @@ efi_status_t __efi_runtime EFIAPI efi_query_capsule_caps(
return EFI_UNSUPPORTED;
}
-/**
- * efi_query_variable_info() - get information about EFI variables
- *
- * This function implements the QueryVariableInfo() runtime service.
- *
- * See the Unified Extensible Firmware Interface (UEFI) specification for
- * details.
- *
- * @attributes: bitmask to select variables to be
- * queried
- * @maximum_variable_storage_size: maximum size of storage area for the
- * selected variable types
- * @remaining_variable_storage_size: remaining size of storage are for the
- * selected variable types
- * @maximum_variable_size: maximum size of a variable of the
- * selected type
- * Returns: status code
- */
-efi_status_t __efi_runtime EFIAPI efi_query_variable_info(
- u32 attributes,
- u64 *maximum_variable_storage_size,
- u64 *remaining_variable_storage_size,
- u64 *maximum_variable_size)
-{
- return EFI_UNSUPPORTED;
-}
-
struct efi_runtime_services __efi_runtime_data efi_runtime_services = {
.hdr = {
.signature = EFI_RUNTIME_SERVICES_SIGNATURE,
diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c
index d6b75ca02e..f71dc29ee9 100644
--- a/lib/efi_loader/efi_variable.c
+++ b/lib/efi_loader/efi_variable.c
@@ -520,3 +520,30 @@ out:
return EFI_EXIT(ret);
}
+
+/**
+ * efi_query_variable_info() - get information about EFI variables
+ *
+ * This function implements the QueryVariableInfo() runtime service.
+ *
+ * See the Unified Extensible Firmware Interface (UEFI) specification for
+ * details.
+ *
+ * @attributes: bitmask to select variables to be
+ * queried
+ * @maximum_variable_storage_size: maximum size of storage area for the
+ * selected variable types
+ * @remaining_variable_storage_size: remaining size of storage are for the
+ * selected variable types
+ * @maximum_variable_size: maximum size of a variable of the
+ * selected type
+ * Returns: status code
+ */
+efi_status_t __efi_runtime EFIAPI efi_query_variable_info(
+ u32 attributes,
+ u64 *maximum_variable_storage_size,
+ u64 *remaining_variable_storage_size,
+ u64 *maximum_variable_size)
+{
+ return EFI_UNSUPPORTED;
+}
--
2.20.1
^ permalink raw reply related
* qmimodems: netreg properties CellId and LocationAreaCode sometimes not present
From: Christophe Ronco @ 2019-06-20 10:18 UTC (permalink / raw)
To: ofono
[-- Attachment #1: Type: text/plain, Size: 5625 bytes --]
Hi,
With qmi modems I am using (quectel EG25, sierra MC7304), sometimes I
don't have CellId and LocationAreaCode properties in netreg properties
while I am registered. Example:
root(a)klk-wiis-020001:~ # dbus-send --system --type=method_call
--print-reply --dest=org.ofono /quectelqmi_0
org.ofono.NetworkRegistration.GetProperties
method return time=1561022820.781396 sender=:1.8 -> destination=:1.25
serial=96 reply_serial=2
array [
dict entry(
string "Status"
variant string "registered"
)
dict entry(
string "Mode"
variant string "auto"
)
dict entry(
string "Technology"
variant string "lte"
)
dict entry(
string "MobileCountryCode"
variant string "208"
)
dict entry(
string "MobileNetworkCode"
variant string "10"
)
dict entry(
string "Name"
variant string "SFR"
)
dict entry(
string "Strength"
variant byte 40
)
]
CellId and LocationAreaCode come from Current serving system info
indication in QMI protocol. These indications contains many parameters
and most of them are optional. What's happening here is:
- first serving system info indication indicates modem is registered,
gives CellId and LAC
- another serving system info indication indicates modem is
registered,and give no information on CellId and LAC
When the second indication is processed, ofono_netreg_status_notify is
called with lac and cellid equal to -1. As a consequence, corresponding
NetworkRegistration properties are removed.
Here are traces from ofono when problem occurs:
2019-06-20T09:22:43.709727+00:00 klk-wiis-020001 ofonod[736]: oFono
version 1.24
2019-06-20T09:22:45.683101+00:00 klk-wiis-020001 ofonod[736]:
ofono_sim_register /quectelqmi_0 isPresent:0
2019-06-20T09:22:45.684212+00:00 klk-wiis-020001 ofonod[736]:
sim_inserted_update modem /quectelqmi_0 isPresent:1
2019-06-20T09:22:45.685682+00:00 klk-wiis-020001 ofonod[736]: Interface
org.ofono.AllowedAccessPoints not found on the interface_list
2019-06-20T09:22:45.778324+00:00 klk-wiis-020001 ofonod[736]: Requested
file structure differs from SIM: 6fb7
2019-06-20T09:22:46.258948+00:00 klk-wiis-020001 ofonod[736]:
sim_inserted_update modem /quectelqmi_0 isPresent:0
2019-06-20T09:22:46.260482+00:00 klk-wiis-020001 ofonod[736]: Interface
org.ofono.AllowedAccessPoints not found on the interface_list
2019-06-20T09:22:46.898106+00:00 klk-wiis-020001 ofonod[736]:
sim_inserted_update modem /quectelqmi_0 isPresent:1
2019-06-20T09:22:46.899788+00:00 klk-wiis-020001 ofonod[736]: Interface
org.ofono.AllowedAccessPoints not found on the interface_list
2019-06-20T09:22:47.155130+00:00 klk-wiis-020001 ofonod[736]: Requested
file structure differs from SIM: 6fb7
2019-06-20T09:22:48.626979+00:00 klk-wiis-020001 ofonod[736]: Unable to
read waiting messages numbers from SIM
2019-06-20T09:22:48.818950+00:00 klk-wiis-020001 ofonod[736]: Unable to
read mailbox identifies from SIM
2019-06-20T09:22:48.915000+00:00 klk-wiis-020001 ofonod[736]:
ofono_netreg_status_notify modem /quectelqmi_0 status 2 lac -1 cellid -1
tech -1
2019-06-20T09:22:48.947207+00:00 klk-wiis-020001 ofonod[736]:
ofono_gprs_status_notify modem /quectelqmi_0 status 0
2019-06-20T09:22:49.010982+00:00 klk-wiis-020001 ofonod[736]:
ofono_netreg_status_notify modem /quectelqmi_0 status 2 lac -1 cellid -1
tech 7
2019-06-20T09:22:49.714986+00:00 klk-wiis-020001 ofonod[736]:
ofono_netreg_status_notify modem /quectelqmi_0 status 1 lac 65534 cellid
1076227 tech 7
2019-06-20T09:22:49.717442+00:00 klk-wiis-020001 ofonod[736]: CRO
set_registration_cellid netreg->cellid: -1 ci: 1076227
2019-06-20T09:22:49.721963+00:00 klk-wiis-020001 ofonod[736]:
ofono_gprs_status_notify modem /quectelqmi_0 status 1
2019-06-20T09:22:49.724312+00:00 klk-wiis-020001 ofonod[736]: CRO
network_get_properties netreg->cellid: 1076227
2019-06-20T09:22:49.779005+00:00 klk-wiis-020001 ofonod[736]:
ofono_netreg_status_notify modem /quectelqmi_0 status 1 lac -1 cellid -1
tech 7
2019-06-20T09:22:49.779508+00:00 klk-wiis-020001 ofonod[736]: CRO
set_registration_cellid netreg->cellid: 1076227 ci: -1
2019-06-20T09:26:46.610671+00:00 klk-wiis-020001 ofonod[736]: CRO
network_get_properties netreg->cellid: -1
I see two ways to fix this problem:
1) modify QMI modem driver to remember LAC and CellId inside the driver.
When a notification arrives without CellId or LAC information, use
remembered information. The drawback of this solution is that these
information are remembered twice: in driver and in core.
2) modify core to add a way for drivers to say that these parameters are
not modified. The drawback of this solution is that it is a change in
core (even a change in core interface with drivers)
I assume that solution 1 is better of this problem is for QMI modems
only. I assume that solution 2 is better if some other drivers can have
the same kind of problems.
What do you think? How should I fix this problem? Will a change in
driver/core interface be helpful?
Best Regards,
Christophe Ronco
^ permalink raw reply
* Re: [PATCH] media: mt9m111: fix fw-node refactoring
From: Sakari Ailus @ 2019-06-20 10:17 UTC (permalink / raw)
To: Robert Jarzmik
Cc: Mauro Carvalho Chehab, Enrico Scholz, linux-media, linux-kernel
In-Reply-To: <20190603200155.24358-1-robert.jarzmik@free.fr>
Hi Robert,
On Mon, Jun 03, 2019 at 10:01:55PM +0200, Robert Jarzmik wrote:
> In the patch refactoring the fw-node, the mt9m111 was broken for all
> platform_data based platforms, which were the first aim of this
> driver. Only the devicetree platform are still functional, probably
> because the testing was done on these.
>
> The result is that -EINVAL is systematically return for such platforms,
> what this patch fixes.
>
> Fixes: 98480d65c48c ("media: mt9m111: allow to setup pixclk polarity")
> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
> ---
> drivers/media/i2c/mt9m111.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/i2c/mt9m111.c b/drivers/media/i2c/mt9m111.c
> index 168a5c74f368..d65c23301498 100644
> --- a/drivers/media/i2c/mt9m111.c
> +++ b/drivers/media/i2c/mt9m111.c
> @@ -1209,7 +1209,7 @@ static int mt9m111_probe(struct i2c_client *client,
> {
> struct mt9m111 *mt9m111;
> struct i2c_adapter *adapter = to_i2c_adapter(client->dev.parent);
> - int ret;
> + int ret = 0;
>
> if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_WORD_DATA)) {
> dev_warn(&adapter->dev,
> @@ -1221,7 +1221,8 @@ static int mt9m111_probe(struct i2c_client *client,
> if (!mt9m111)
> return -ENOMEM;
>
> - ret = mt9m111_probe_fw(client, mt9m111);
> + if (client->dev.of_node)
> + ret = mt9m111_probe_fw(client, mt9m111);
> if (ret)
> return ret;
>
This didn't quite apply with the i2c adapter cleanups. I applied it,
reworking the ret check, and the patch became:
diff --git a/drivers/media/i2c/mt9m111.c b/drivers/media/i2c/mt9m111.c
index bd3a51c3b081..9761a6105407 100644
--- a/drivers/media/i2c/mt9m111.c
+++ b/drivers/media/i2c/mt9m111.c
@@ -1263,9 +1263,11 @@ static int mt9m111_probe(struct i2c_client *client,
if (!mt9m111)
return -ENOMEM;
- ret = mt9m111_probe_fw(client, mt9m111);
- if (ret)
- return ret;
+ if (dev_fwnode(client->dev)) {
+ ret = mt9m111_probe_fw(client, mt9m111);
+ if (ret)
+ return ret;
+ }
mt9m111->clk = v4l2_clk_get(&client->dev, "mclk");
if (IS_ERR(mt9m111->clk))
I hope this is fine.
--
Kind regards,
Sakari Ailus
^ permalink raw reply related
* Re: linux-next: build failure after merge of the akpm-current tree
From: David Hildenbrand @ 2019-06-20 10:17 UTC (permalink / raw)
To: Stephen Rothwell, Andrew Morton
Cc: Linux Next Mailing List, Linux Kernel Mailing List
In-Reply-To: <20190620194244.474a83e8@canb.auug.org.au>
On 20.06.19 11:42, Stephen Rothwell wrote:
> Hi all,
>
> After merging the akpm-current tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> drivers/base/memory.c: In function 'find_memory_block':
> drivers/base/memory.c:621:43: error: 'hint' undeclared (first use in this function); did you mean 'uint'?
> return find_memory_block_by_id(block_id, hint);
> ^~~~
> uint
> drivers/base/memory.c:621:43: note: each undeclared identifier is reported only once for each function it appears in
> drivers/base/memory.c:622:1: warning: control reaches end of non-void function [-Wreturn-type]
> }
> ^
>
> Caused by commit
>
> 29be27f12cc8 ("drivers/base/memory.c: Get rid of find_memory_block_hinted()")
>
> I have reverted that commit for today.
>
Uh, how did that happen. "hint" -> "NULL". But we can drop the hint
completely. Will send a new patch. Grml.
Sorry for the noise.
--
Thanks,
David / dhildenb
^ permalink raw reply
* Re: [PATCH 1/3] arm64 defconfig: enable LVM support
From: Marcin Juszkiewicz @ 2019-06-20 10:17 UTC (permalink / raw)
To: Olof Johansson; +Cc: arm, linux-arm-kernel
In-Reply-To: <20190619142142.52stwnyucxa7g3rz@localhost>
[-- Attachment #1: Type: text/plain, Size: 383 bytes --]
W dniu 19.06.2019 o 16:21, Olof Johansson pisze:
> On Mon, Jun 17, 2019 at 06:04:09PM +0200, Marcin Juszkiewicz wrote:
>> Follow x86-64 defconfig on enabling basic LVM support.
>>
>> Signed-off-by: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org>
>
> Do you need this to be =y? If you use LVM, you usually boot with a ramdisk that
> will hold modules.
Right. Forgot to change.
[-- Attachment #2: 0001-arm64-defconfig-enable-LVM-support.patch --]
[-- Type: text/x-patch, Size: 881 bytes --]
From 63003d0047062949a1231f67e1efdcb96b54323a Mon Sep 17 00:00:00 2001
From: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org>
Date: Mon, 27 May 2019 20:14:34 +0200
Subject: [PATCH 1/3] arm64 defconfig: enable LVM support
Follow x86-64 defconfig on enabling basic LVM support.
Signed-off-by: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org>
---
arch/arm64/configs/defconfig | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 4d583514258c..864800307e2f 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -230,6 +230,11 @@ CONFIG_SATA_SIL24=y
CONFIG_SATA_RCAR=y
CONFIG_PATA_PLATFORM=y
CONFIG_PATA_OF_PLATFORM=y
+CONFIG_MD=y
+CONFIG_BLK_DEV_MD=m
+CONFIG_BLK_DEV_DM=m
+CONFIG_DM_MIRROR=m
+CONFIG_DM_ZERO=m
CONFIG_NETDEVICES=y
CONFIG_MACVLAN=m
CONFIG_MACVTAP=m
--
2.21.0
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] cmake: Clarify comment in cmake toolchain file
From: Richard Purdie @ 2019-06-20 10:17 UTC (permalink / raw)
To: openembedded-core
The comment is misleading and there was confusion in a bug report. In the native
case STAGING_DATADIR would be equal to the native value so there isn't any issue
but tweak the comment.
[YOCTO #12761]
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
meta/classes/cmake.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index f80a7e2f1d6..2b317c832fe 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -119,7 +119,7 @@ set( ENV{QT_CONF_PATH} ${WORKDIR}/qt.conf )
# directory as rpath by default
set( CMAKE_INSTALL_RPATH ${OECMAKE_RPATH} )
-# Use native cmake modules
+# Use our cmake modules
list(APPEND CMAKE_MODULE_PATH "${STAGING_DATADIR}/cmake/Modules/")
# add for non /usr/lib libdir, e.g. /usr/lib64
--
2.20.1
^ permalink raw reply related
* Re: [PATCH V6 23/27] arm64: tegra: Add PEX DPD states as pinctrl properties
From: Thierry Reding @ 2019-06-20 10:14 UTC (permalink / raw)
To: Manikanta Maddireddy
Cc: bhelgaas, robh+dt, mark.rutland, jonathanh, lorenzo.pieralisi,
vidyas, linux-tegra, linux-pci, devicetree
In-Reply-To: <20190618180206.4908-24-mmaddireddy@nvidia.com>
[-- Attachment #1: Type: text/plain, Size: 695 bytes --]
On Tue, Jun 18, 2019 at 11:32:02PM +0530, Manikanta Maddireddy wrote:
> Add PEX deep power down states as pinctrl properties to set in PCIe driver.
> In Tegra210, BIAS pads are not in power down mode when clamps are applied.
> To set the pads in DPD, pass the PEX DPD states as pinctrl properties to
> PCIe driver.
>
> Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
> ---
> V6: No change
>
> V5: No change
>
> V4: No change
>
> V3: No change
>
> V2: Using standard pinctrl names, default and idle
>
> arch/arm64/boot/dts/nvidia/tegra210.dtsi | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
Applied to for-5.3/arm64/dt, thanks.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [igt-dev] ✓ Fi.CI.IGT: success for Add Arm drivers as supported drivers by igt. (rev2)
From: Patchwork @ 2019-06-20 10:13 UTC (permalink / raw)
To: Liviu Dudau; +Cc: igt-dev
In-Reply-To: <20190617151841.31868-1-liviu.dudau@arm.com>
== Series Details ==
Series: Add Arm drivers as supported drivers by igt. (rev2)
URL : https://patchwork.freedesktop.org/series/62227/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6308_full -> IGTPW_3177_full
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://patchwork.freedesktop.org/api/1.0/series/62227/revisions/2/mbox/
Known issues
------------
Here are the changes found in IGTPW_3177_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_eio@wait-wedge-10ms:
- shard-kbl: [PASS][1] -> [DMESG-WARN][2] ([fdo#110913 ]) +1 similar issue
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6308/shard-kbl1/igt@gem_eio@wait-wedge-10ms.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3177/shard-kbl6/igt@gem_eio@wait-wedge-10ms.html
* igt@gem_exec_schedule@smoketest-all:
- shard-glk: [PASS][3] -> [FAIL][4] ([fdo#110946])
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6308/shard-glk1/igt@gem_exec_schedule@smoketest-all.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3177/shard-glk2/igt@gem_exec_schedule@smoketest-all.html
* igt@gem_userptr_blits@sync-unmap-cycles:
- shard-snb: [PASS][5] -> [DMESG-WARN][6] ([fdo#110913 ]) +1 similar issue
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6308/shard-snb1/igt@gem_userptr_blits@sync-unmap-cycles.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3177/shard-snb6/igt@gem_userptr_blits@sync-unmap-cycles.html
- shard-apl: [PASS][7] -> [DMESG-WARN][8] ([fdo#110913 ]) +3 similar issues
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6308/shard-apl2/igt@gem_userptr_blits@sync-unmap-cycles.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3177/shard-apl2/igt@gem_userptr_blits@sync-unmap-cycles.html
* igt@gem_workarounds@suspend-resume:
- shard-apl: [PASS][9] -> [DMESG-WARN][10] ([fdo#108566]) +4 similar issues
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6308/shard-apl3/igt@gem_workarounds@suspend-resume.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3177/shard-apl1/igt@gem_workarounds@suspend-resume.html
* igt@i915_pm_rc6_residency@rc6-accuracy:
- shard-snb: [PASS][11] -> [SKIP][12] ([fdo#109271]) +1 similar issue
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6308/shard-snb4/igt@i915_pm_rc6_residency@rc6-accuracy.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3177/shard-snb4/igt@i915_pm_rc6_residency@rc6-accuracy.html
* igt@kms_flip@2x-flip-vs-expired-vblank-interruptible:
- shard-glk: [PASS][13] -> [FAIL][14] ([fdo#102887])
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6308/shard-glk4/igt@kms_flip@2x-flip-vs-expired-vblank-interruptible.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3177/shard-glk2/igt@kms_flip@2x-flip-vs-expired-vblank-interruptible.html
* igt@kms_flip@flip-vs-modeset-vs-hang-interruptible:
- shard-snb: [PASS][15] -> [DMESG-WARN][16] ([fdo#110789] / [fdo#110913 ])
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6308/shard-snb6/igt@kms_flip@flip-vs-modeset-vs-hang-interruptible.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3177/shard-snb1/igt@kms_flip@flip-vs-modeset-vs-hang-interruptible.html
* igt@kms_flip@flip-vs-suspend-interruptible:
- shard-glk: [PASS][17] -> [INCOMPLETE][18] ([fdo#103359] / [k.org#198133])
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6308/shard-glk1/igt@kms_flip@flip-vs-suspend-interruptible.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3177/shard-glk3/igt@kms_flip@flip-vs-suspend-interruptible.html
* igt@kms_setmode@basic:
- shard-kbl: [PASS][19] -> [FAIL][20] ([fdo#99912])
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6308/shard-kbl6/igt@kms_setmode@basic.html
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3177/shard-kbl7/igt@kms_setmode@basic.html
#### Possible fixes ####
* igt@gem_ctx_shared@exec-shared-gtt-bsd:
- shard-glk: [FAIL][21] -> [PASS][22]
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6308/shard-glk4/igt@gem_ctx_shared@exec-shared-gtt-bsd.html
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3177/shard-glk3/igt@gem_ctx_shared@exec-shared-gtt-bsd.html
* igt@gem_persistent_relocs@forked-interruptible-thrashing:
- shard-snb: [DMESG-WARN][23] ([fdo#110789] / [fdo#110913 ]) -> [PASS][24]
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6308/shard-snb6/igt@gem_persistent_relocs@forked-interruptible-thrashing.html
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3177/shard-snb5/igt@gem_persistent_relocs@forked-interruptible-thrashing.html
* igt@gem_tiled_swapping@non-threaded:
- shard-kbl: [DMESG-WARN][25] ([fdo#108686]) -> [PASS][26]
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6308/shard-kbl4/igt@gem_tiled_swapping@non-threaded.html
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3177/shard-kbl1/igt@gem_tiled_swapping@non-threaded.html
* igt@gem_userptr_blits@map-fixed-invalidate-busy-gup:
- shard-apl: [DMESG-WARN][27] ([fdo#110913 ]) -> [PASS][28] +2 similar issues
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6308/shard-apl7/igt@gem_userptr_blits@map-fixed-invalidate-busy-gup.html
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3177/shard-apl8/igt@gem_userptr_blits@map-fixed-invalidate-busy-gup.html
- shard-snb: [DMESG-WARN][29] ([fdo#110913 ]) -> [PASS][30]
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6308/shard-snb1/igt@gem_userptr_blits@map-fixed-invalidate-busy-gup.html
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3177/shard-snb1/igt@gem_userptr_blits@map-fixed-invalidate-busy-gup.html
* igt@gem_userptr_blits@sync-unmap-cycles:
- shard-kbl: [DMESG-WARN][31] ([fdo#110913 ]) -> [PASS][32] +1 similar issue
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6308/shard-kbl7/igt@gem_userptr_blits@sync-unmap-cycles.html
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3177/shard-kbl7/igt@gem_userptr_blits@sync-unmap-cycles.html
* igt@i915_suspend@sysfs-reader:
- shard-kbl: [INCOMPLETE][33] ([fdo#103665] / [fdo#108767]) -> [PASS][34]
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6308/shard-kbl4/igt@i915_suspend@sysfs-reader.html
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3177/shard-kbl7/igt@i915_suspend@sysfs-reader.html
* igt@kms_flip@2x-plain-flip:
- shard-hsw: [SKIP][35] ([fdo#109271]) -> [PASS][36] +15 similar issues
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6308/shard-hsw1/igt@kms_flip@2x-plain-flip.html
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3177/shard-hsw6/igt@kms_flip@2x-plain-flip.html
* igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes:
- shard-kbl: [INCOMPLETE][37] ([fdo#103665]) -> [PASS][38]
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6308/shard-kbl4/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes.html
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3177/shard-kbl1/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes.html
* igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes:
- shard-apl: [DMESG-WARN][39] ([fdo#108566]) -> [PASS][40] +3 similar issues
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6308/shard-apl6/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes.html
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3177/shard-apl4/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes.html
[fdo#102887]: https://bugs.freedesktop.org/show_bug.cgi?id=102887
[fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359
[fdo#103665]: https://bugs.freedesktop.org/show_bug.cgi?id=103665
[fdo#108566]: https://bugs.freedesktop.org/show_bug.cgi?id=108566
[fdo#108686]: https://bugs.freedesktop.org/show_bug.cgi?id=108686
[fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#110789]: https://bugs.freedesktop.org/show_bug.cgi?id=110789
[fdo#110913 ]: https://bugs.freedesktop.org/show_bug.cgi?id=110913
[fdo#110946]: https://bugs.freedesktop.org/show_bug.cgi?id=110946
[fdo#99912]: https://bugs.freedesktop.org/show_bug.cgi?id=99912
[k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133
Participating hosts (8 -> 5)
------------------------------
Missing (3): shard-skl pig-hsw-4770r pig-glk-j5005
Build changes
-------------
* IGT: IGT_5061 -> IGTPW_3177
* Piglit: piglit_4509 -> None
CI_DRM_6308: 73f0a22ad1085881cf50f7866ddf885bf6229b9b @ git://anongit.freedesktop.org/gfx-ci/linux
IGTPW_3177: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3177/
IGT_5061: c88ced79a7b71aec58f1d9c5c599ac2f431bcf7a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3177/
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply
* Re: [PATCH net-next v2] ipv6: Error when route does not have any valid nexthops
From: Ido Schimmel @ 2019-06-20 10:12 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, davem, dsahern, mlxsw, Ido Schimmel
In-Reply-To: <20190620092202.GC2504@nanopsycho>
On Thu, Jun 20, 2019 at 11:22:03AM +0200, Jiri Pirko wrote:
> Thu, Jun 20, 2019 at 11:10:21AM CEST, idosch@idosch.org wrote:
> >+ if (list_empty(&rt6_nh_list)) {
> >+ NL_SET_ERR_MSG(extack,
> >+ "Invalid nexthop configuration - no valid nexthops");
>
> No need for a line wrap.
I wanted to be consistent with the rest of the extack usage in this
function.
^ 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.