[PATCH 06/35] irqchip/gic-v3-its: Make is_v4 use a TYPER copy
Instead of caching the GICv4 compatibility in a discrete way, cache the
TYPER register instead, which can then be used to implement the same
functionnality. This will get used more extensively in subsequent patches.
Signed-off-by: Marc Zyngier
---
drivers/irqchip/irq-gic-v3-its.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 17b77a0b9d97..731726540efa 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -102,6 +102,7 @@ struct its_node {
struct its_collection *collections;
struct fwnode_handle*fwnode_handle;
u64 (*get_msi_base)(struct its_device *its_dev);
+ u64 typer;
u64 cbaser_save;
u32 ctlr_save;
struct list_headits_device_list;
@@ -112,10 +113,11 @@ struct its_node {
int numa_node;
unsigned intmsi_domain_flags;
u32 pre_its_base; /* for Socionext Synquacer */
- boolis_v4;
int vlpi_redist_offset;
};
+#define is_v4(its) (!!((its)->typer & GITS_TYPER_VLPIS))
+
#define ITS_ITT_ALIGN SZ_256
/* The maximum number of VPEID bits supported by VLPI commands */
@@ -1028,7 +1030,7 @@ static void its_send_vmovp(struct its_vpe *vpe)
/* Emit VMOVPs */
list_for_each_entry(its, &its_nodes, entry) {
- if (!its->is_v4)
+ if (!is_v4(its))
continue;
if (!vpe->its_vm->vlpi_count[its->list_nr])
@@ -1439,7 +1441,7 @@ static int its_irq_set_vcpu_affinity(struct irq_data *d,
void *vcpu_info)
struct its_cmd_info *info = vcpu_info;
/* Need a v4 ITS */
- if (!its_dev->its->is_v4)
+ if (!is_v4(its_dev->its))
return -EINVAL;
/* Unmap request? */
@@ -2403,7 +2405,7 @@ static bool its_alloc_vpe_table(u32 vpe_id)
list_for_each_entry(its, &its_nodes, entry) {
struct its_baser *baser;
- if (!its->is_v4)
+ if (!is_v4(its))
continue;
baser = its_get_baser(its, GITS_BASER_TYPE_VCPU);
@@ -2891,7 +2893,7 @@ static void its_vpe_invall(struct its_vpe *vpe)
struct its_node *its;
list_for_each_entry(its, &its_nodes, entry) {
- if (!its->is_v4)
+ if (!is_v4(its))
continue;
if (its_list_map && !vpe->its_vm->vlpi_count[its->list_nr])
@@ -3158,7 +3160,7 @@ static int its_vpe_irq_domain_activate(struct irq_domain
*domain,
vpe->col_idx = cpumask_first(cpu_online_mask);
list_for_each_entry(its, &its_nodes, entry) {
- if (!its->is_v4)
+ if (!is_v4(its))
continue;
its_send_vmapp(its, vpe, true);
@@ -3184,7 +3186,7 @@ static void its_vpe_irq_domain_deactivate(struct
irq_domain *domain,
return;
list_for_each_entry(its, &its_nodes, entry) {
- if (!its->is_v4)
+ if (!is_v4(its))
continue;
its_send_vmapp(its, vpe, false);
@@ -3622,12 +3624,12 @@ static int __init its_probe_one(struct resource *res,
INIT_LIST_HEAD(&its->entry);
INIT_LIST_HEAD(&its->its_device_list);
typer = gic_read_typer(its_base + GITS_TYPER);
+ its->typer = typer;
its->base = its_base;
its->phys_base = res->start;
its->ite_size = GITS_TYPER_ITT_ENTRY_SIZE(typer);
its->device_ids = GITS_TYPER_DEVBITS(typer);
- its->is_v4 = !!(typer & GITS_TYPER_VLPIS);
- if (its->is_v4) {
+ if (is_v4(its)) {
if (!(typer & GITS_TYPER_VMOVP)) {
err = its_compute_its_list_map(res, its_base);
if (err < 0)
@@ -3694,7 +3696,7 @@ static int __init its_probe_one(struct resource *res,
gits_write_cwriter(0, its->base + GITS_CWRITER);
ctlr = readl_relaxed(its->base + GITS_CTLR);
ctlr |= GITS_CTLR_ENABLE;
- if (its->is_v4)
+ if (is_v4(its))
ctlr |= GITS_CTLR_ImDe;
writel_relaxed(ctlr, its->base + GITS_CTLR);
@@ -4019,7 +4021,7 @@ int __init its_init(struct fwnode_handle *handle, struct
rdists *rdists,
return err;
list_for_each_entry(its, &its_nodes, entry)
- has_v4 |= its->is_v4;
+ has_v4 |= is_v4(its);
if (has_v4 & rdists->has_vlpis) {
if (its_init_vpe_domain() ||
--
2.20.1
[PATCH 10/35] irqchip/gic-v4.1: VPE table (aka GICR_VPROPBASER) allocation
GICv4.1 defines a new VPE table that is potentially shared between
both the ITSs and the redistributors, following complicated affinity
rules.
To make things more confusing, the programming of this table at
the redistributor level is reusing the GICv4.0 GICR_VPROPBASER register
for something completely different.
The code flow is somewhat complexified by the need to respect the
affinities required by the HW, meaning that tables can either be
inherited from a previously discovered ITS or redistributor.
Signed-off-by: Marc Zyngier
---
arch/arm/include/asm/arch_gicv3.h | 2 +
arch/arm64/include/asm/arch_gicv3.h | 1 +
drivers/irqchip/irq-gic-v3-its.c| 301 +++-
include/linux/irqchip/arm-gic-v3.h | 33 ++-
4 files changed, 330 insertions(+), 7 deletions(-)
diff --git a/arch/arm/include/asm/arch_gicv3.h
b/arch/arm/include/asm/arch_gicv3.h
index 0555f14cc8be..20bacab1d791 100644
--- a/arch/arm/include/asm/arch_gicv3.h
+++ b/arch/arm/include/asm/arch_gicv3.h
@@ -10,6 +10,7 @@
#ifndef __ASSEMBLY__
#include
+#include
#include
#include
#include
@@ -327,6 +328,7 @@ static inline u64 __gic_readq_nonatomic(const volatile void
__iomem *addr)
/*
* GITS_VPROPBASER - hi and lo bits may be accessed independently.
*/
+#define gits_read_vpropbaser(c)__gic_readq_nonatomic(c)
#define gits_write_vpropbaser(v, c)__gic_writeq_nonatomic(v, c)
/*
diff --git a/arch/arm64/include/asm/arch_gicv3.h
b/arch/arm64/include/asm/arch_gicv3.h
index 89e4c8b79349..4750fc8030c3 100644
--- a/arch/arm64/include/asm/arch_gicv3.h
+++ b/arch/arm64/include/asm/arch_gicv3.h
@@ -141,6 +141,7 @@ static inline u32 gic_read_rpr(void)
#define gicr_read_pendbaser(c) readq_relaxed(c)
#define gits_write_vpropbaser(v, c)writeq_relaxed(v, c)
+#define gits_read_vpropbaser(c)readq_relaxed(c)
#define gits_write_vpendbaser(v, c)writeq_relaxed(v, c)
#define gits_read_vpendbaser(c)readq_relaxed(c)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 9bad3887f6ce..58c7c40f5ad7 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -45,6 +45,7 @@
#define RDIST_FLAGS_PROPBASE_NEEDS_FLUSHING(1 << 0)
#define RDIST_FLAGS_RD_TABLES_PREALLOCATED (1 << 1)
+#define RDIST_FLAGS_VPE_INDIRECT (1 << 2)
static u32 lpi_id_bits;
@@ -106,6 +107,7 @@ struct its_node {
u64 typer;
u64 cbaser_save;
u32 ctlr_save;
+ u32 mpidr;
struct list_headits_device_list;
u64 flags;
unsigned long list_nr;
@@ -116,6 +118,7 @@ struct its_node {
};
#define is_v4(its) (!!((its)->typer & GITS_TYPER_VLPIS))
+#define is_v4_1(its) (!!((its)->typer & GITS_TYPER_VMAPP))
#define device_ids(its)(FIELD_GET(GITS_TYPER_DEVBITS,
(its)->typer) + 1)
#define ITS_ITT_ALIGN SZ_256
@@ -1962,6 +1965,65 @@ static bool its_parse_indirect_baser(struct its_node
*its,
return indirect;
}
+static u32 compute_common_aff(u64 val)
+{
+ u32 aff, clpiaff;
+
+ aff = FIELD_GET(GICR_TYPER_AFFINITY, val);
+ clpiaff = FIELD_GET(GICR_TYPER_COMMON_LPI_AFF, val);
+
+ return aff & ~(GENMASK(31, 0) >> (clpiaff * 8));
+}
+
+static u32 compute_its_aff(struct its_node *its)
+{
+ u64 val;
+ u32 svpet;
+
+ /*
+* Reencode the ITS SVPET and MPIDR as a GICR_TYPER, and compute
+* the resulting affinity. We then use that to see if this match
+* our own affinity.
+*/
+ svpet = FIELD_GET(GITS_TYPER_SVPET, its->typer);
+ val = FIELD_PREP(GICR_TYPER_COMMON_LPI_AFF, svpet);
+ val |= FIELD_PREP(GICR_TYPER_AFFINITY, its->mpidr);
+ return compute_common_aff(val);
+}
+
+static struct its_node *find_sibbling_its(struct its_node *cur_its)
+{
+ struct its_node *its;
+ u32 aff;
+
+ if (!FIELD_GET(GITS_TYPER_SVPET, cur_its->typer))
+ return NULL;
+
+ aff = compute_its_aff(cur_its);
+
+ list_for_each_entry(its, &its_nodes, entry) {
+ u64 baser;
+
+ if (!is_v4_1(its) || its == cur_its)
+ continue;
+
+ if (!FIELD_GET(GITS_TYPER_SVPET, its->typer))
+ continue;
+
+ if (aff != compute_its_aff(its))
+ continue;
+
+ /* GICv4.1 guarantees that the vPE table is GITS_BASER2 */
+ baser = its->tables[2].val;
+ if (!(baser & GITS_BASER_VALID))
+ continue;
+
+ return its;
+ }
+
+ return NULL;
+}
+
static void its_free_tables(struct its_node *its)
{
int i;
@@ -2004,6 +2066,15 @@ static int its_alloc_tables(struct its_node *its)
break;
[PATCH 16/35] irqchip/gic-v4.1: Add VPE residency callback
Making a VPE resident on GICv4.1 is pretty simple, as it is just a
single write to the local redistributor. We just need extra information
about which groups to enable, which the KVM code will have to provide.
Signed-off-by: Marc Zyngier
---
drivers/irqchip/irq-gic-v3-its.c | 17 +
include/linux/irqchip/arm-gic-v3.h | 9 +
include/linux/irqchip/arm-gic-v4.h | 5 +
3 files changed, 31 insertions(+)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 36653db372bc..72d80daa7230 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -3461,12 +3461,29 @@ static void its_vpe_4_1_unmask_irq(struct irq_data *d)
its_vpe_4_1_send_inv(d);
}
+static void its_vpe_4_1_schedule(struct its_vpe *vpe,
+struct its_cmd_info *info)
+{
+ void __iomem *vlpi_base = gic_data_rdist_vlpi_base();
+ u64 val = 0;
+
+ /* Schedule the VPE */
+ val |= GICR_VPENDBASER_Valid;
+ val |= info->g0en ? GICR_VPENDBASER_4_1_VGRP0EN : 0;
+ val |= info->g1en ? GICR_VPENDBASER_4_1_VGRP1EN : 0;
+ val |= FIELD_PREP(GICR_VPENDBASER_4_1_VPEID, vpe->vpe_id);
+
+ gits_write_vpendbaser(val, vlpi_base + GICR_VPENDBASER);
+}
+
static int its_vpe_4_1_set_vcpu_affinity(struct irq_data *d, void *vcpu_info)
{
+ struct its_vpe *vpe = irq_data_get_irq_chip_data(d);
struct its_cmd_info *info = vcpu_info;
switch (info->cmd_type) {
case SCHEDULE_VPE:
+ its_vpe_4_1_schedule(vpe, info);
return 0;
case DESCHEDULE_VPE:
diff --git a/include/linux/irqchip/arm-gic-v3.h
b/include/linux/irqchip/arm-gic-v3.h
index 8157737053e4..6fd89d77b2b2 100644
--- a/include/linux/irqchip/arm-gic-v3.h
+++ b/include/linux/irqchip/arm-gic-v3.h
@@ -327,6 +327,15 @@
#define GICR_VPENDBASER_IDAI (1ULL << 62)
#define GICR_VPENDBASER_Valid (1ULL << 63)
+/*
+ * GICv4.1 VPENDBASER, used for VPE residency. On top of these fields,
+ * also use the above Valid, PendingLast and Dirty.
+ */
+#define GICR_VPENDBASER_4_1_DB (1ULL << 62)
+#define GICR_VPENDBASER_4_1_VGRP0EN(1ULL << 59)
+#define GICR_VPENDBASER_4_1_VGRP1EN(1ULL << 58)
+#define GICR_VPENDBASER_4_1_VPEID GENMASK_ULL(15, 0)
+
/*
* ITS registers, offsets from ITS_base
*/
diff --git a/include/linux/irqchip/arm-gic-v4.h
b/include/linux/irqchip/arm-gic-v4.h
index 6213ced6f199..edbaa37fd3f1 100644
--- a/include/linux/irqchip/arm-gic-v4.h
+++ b/include/linux/irqchip/arm-gic-v4.h
@@ -98,6 +98,11 @@ struct its_cmd_info {
union {
struct its_vlpi_map *map;
u8 config;
+ boolreq_db;
+ struct {
+ boolg0en;
+ boolg1en;
+ };
};
};
--
2.20.1
[PATCH 17/35] irqchip/gic-v4.1: Add VPE eviction callback
When descheduling a VPE, special care must be taken to tell the GIC
about whether we want to receive a doorbell or not. This is a
major improvement on GICv4.0, where the doorbell had to be separately
enabled/disabled.
Signed-off-by: Marc Zyngier
---
drivers/irqchip/irq-gic-v3-its.c | 53 +---
1 file changed, 42 insertions(+), 11 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 72d80daa7230..3079ce74def6 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -2483,7 +2483,7 @@ static int __init allocate_lpi_tables(void)
return 0;
}
-static u64 its_clear_vpend_valid(void __iomem *vlpi_base)
+static u64 its_clear_vpend_valid(void __iomem *vlpi_base, u64 clr, u64 set)
{
u32 count = 100;/* 1s! */
bool clean;
@@ -2491,6 +2491,8 @@ static u64 its_clear_vpend_valid(void __iomem *vlpi_base)
val = gits_read_vpendbaser(vlpi_base + GICR_VPENDBASER);
val &= ~GICR_VPENDBASER_Valid;
+ val &= ~clr;
+ val |= set;
gits_write_vpendbaser(val, vlpi_base + GICR_VPENDBASER);
do {
@@ -2503,6 +2505,11 @@ static u64 its_clear_vpend_valid(void __iomem *vlpi_base)
}
} while (!clean && count);
+ if (unlikely(val & GICR_VPENDBASER_Dirty)) {
+ pr_err_ratelimited("ITS virtual pending table not cleaning\n");
+ val |= GICR_VPENDBASER_PendingLast;
+ }
+
return val;
}
@@ -2611,7 +2618,7 @@ static void its_cpu_init_lpis(void)
* ancient programming gets left in and has possibility of
* corrupting memory.
*/
- val = its_clear_vpend_valid(vlpi_base);
+ val = its_clear_vpend_valid(vlpi_base, 0, 0);
WARN_ON(val & GICR_VPENDBASER_Dirty);
}
@@ -3289,16 +3296,10 @@ static void its_vpe_deschedule(struct its_vpe *vpe)
void __iomem *vlpi_base = gic_data_rdist_vlpi_base();
u64 val;
- val = its_clear_vpend_valid(vlpi_base);
+ val = its_clear_vpend_valid(vlpi_base, 0, 0);
- if (unlikely(val & GICR_VPENDBASER_Dirty)) {
- pr_err_ratelimited("ITS virtual pending table not cleaning\n");
- vpe->idai = false;
- vpe->pending_last = true;
- } else {
- vpe->idai = !!(val & GICR_VPENDBASER_IDAI);
- vpe->pending_last = !!(val & GICR_VPENDBASER_PendingLast);
- }
+ vpe->idai = !!(val & GICR_VPENDBASER_IDAI);
+ vpe->pending_last = !!(val & GICR_VPENDBASER_PendingLast);
}
static void its_vpe_invall(struct its_vpe *vpe)
@@ -3476,6 +3477,35 @@ static void its_vpe_4_1_schedule(struct its_vpe *vpe,
gits_write_vpendbaser(val, vlpi_base + GICR_VPENDBASER);
}
+static void its_vpe_4_1_deschedule(struct its_vpe *vpe,
+ struct its_cmd_info *info)
+{
+ void __iomem *vlpi_base = gic_data_rdist_vlpi_base();
+ u64 val;
+
+ if (info->req_db) {
+ /*
+* vPE is going to block: make the vPE non-resident with
+* PendingLast clear and DB set. The GIC guarantees that if
+* we read-back PendingLast clear, then a doorbell will be
+* delivered when an interrupt comes.
+*/
+ val = its_clear_vpend_valid(vlpi_base,
+ GICR_VPENDBASER_PendingLast,
+ GICR_VPENDBASER_4_1_DB);
+ vpe->pending_last = !!(val & GICR_VPENDBASER_PendingLast);
+ } else {
+ /*
+* We're not blocking, so just make the vPE non-resident
+* with PendingLast set, indicating that we'll be back.
+*/
+ val = its_clear_vpend_valid(vlpi_base,
+ 0,
+ GICR_VPENDBASER_PendingLast);
+ vpe->pending_last = true;
+ }
+}
+
static int its_vpe_4_1_set_vcpu_affinity(struct irq_data *d, void *vcpu_info)
{
struct its_vpe *vpe = irq_data_get_irq_chip_data(d);
@@ -3487,6 +3517,7 @@ static int its_vpe_4_1_set_vcpu_affinity(struct irq_data
*d, void *vcpu_info)
return 0;
case DESCHEDULE_VPE:
+ its_vpe_4_1_deschedule(vpe, info);
return 0;
case INVALL_VPE:
--
2.20.1
[PATCH 15/35] irqchip/gic-v4.1: Add mask/unmask doorbell callbacks
masking/unmasking doorbells on GICv4.1 relies on a new INVDB command,
which broadcasts the invalidation to all RDs.
Implement the new command as well as the masking callbacks, and plug
the whole thing into the v4.1 VPE irqchip.
Signed-off-by: Marc Zyngier
---
drivers/irqchip/irq-gic-v3-its.c | 60 ++
include/linux/irqchip/arm-gic-v3.h | 3 +-
2 files changed, 62 insertions(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 4098ef6d030a..36653db372bc 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -309,6 +309,10 @@ struct its_cmd_desc {
u16 seq_num;
u16 its_list;
} its_vmovp_cmd;
+
+ struct {
+ struct its_vpe *vpe;
+ } its_invdb_cmd;
};
};
@@ -750,6 +754,21 @@ static struct its_vpe *its_build_vmovp_cmd(struct its_node
*its,
return valid_vpe(its, desc->its_vmovp_cmd.vpe);
}
+static struct its_vpe *its_build_invdb_cmd(struct its_node *its,
+ struct its_cmd_block *cmd,
+ struct its_cmd_desc *desc)
+{
+ if (WARN_ON(!is_v4_1(its)))
+ return NULL;
+
+ its_encode_cmd(cmd, GITS_CMD_INVDB);
+ its_encode_vpeid(cmd, desc->its_invdb_cmd.vpe->vpe_id);
+
+ its_fixup_cmd(cmd);
+
+ return valid_vpe(its, desc->its_invdb_cmd.vpe);
+}
+
static u64 its_cmd_ptr_to_offset(struct its_node *its,
struct its_cmd_block *ptr)
{
@@ -1117,6 +1136,14 @@ static void its_send_vinvall(struct its_node *its,
struct its_vpe *vpe)
its_send_single_vcommand(its, its_build_vinvall_cmd, &desc);
}
+static void its_send_invdb(struct its_node *its, struct its_vpe *vpe)
+{
+ struct its_cmd_desc desc;
+
+ desc.its_invdb_cmd.vpe = vpe;
+ its_send_single_vcommand(its, its_build_invdb_cmd, &desc);
+}
+
/*
* irqchip functions - assumes MSI, mostly.
*/
@@ -3403,6 +3430,37 @@ static struct irq_chip its_vpe_irq_chip = {
.irq_set_vcpu_affinity = its_vpe_set_vcpu_affinity,
};
+static void its_vpe_4_1_send_inv(struct irq_data *d)
+{
+ struct its_vpe *vpe = irq_data_get_irq_chip_data(d);
+ struct its_node *its;
+
+ /*
+* GICv4.1 wants doorbells to be invalidated using the
+* INVDB command in order to be broadcast to all RDs. Send
+* it to the first valid ITS, and let the HW do its magic.
+*/
+ list_for_each_entry(its, &its_nodes, entry) {
+ if (!is_v4_1(its))
+ continue;
+
+ its_send_invdb(its, vpe);
+ break;
+ }
+}
+
+static void its_vpe_4_1_mask_irq(struct irq_data *d)
+{
+ lpi_write_config(d->parent_data, LPI_PROP_ENABLED, 0);
+ its_vpe_4_1_send_inv(d);
+}
+
+static void its_vpe_4_1_unmask_irq(struct irq_data *d)
+{
+ lpi_write_config(d->parent_data, 0, LPI_PROP_ENABLED);
+ its_vpe_4_1_send_inv(d);
+}
+
static int its_vpe_4_1_set_vcpu_affinity(struct irq_data *d, void *vcpu_info)
{
struct its_cmd_info *info = vcpu_info;
@@ -3424,6 +3482,8 @@ static int its_vpe_4_1_set_vcpu_affinity(struct irq_data
*d, void *vcpu_info)
static struct irq_chip its_vpe_4_1_irq_chip = {
.name = "GICv4.1-vpe",
+ .irq_mask = its_vpe_4_1_mask_irq,
+ .irq_unmask = its_vpe_4_1_unmask_irq,
.irq_eoi= irq_chip_eoi_parent,
.irq_set_affinity = its_vpe_set_affinity,
.irq_set_vcpu_affinity = its_vpe_4_1_set_vcpu_affinity,
diff --git a/include/linux/irqchip/arm-gic-v3.h
b/include/linux/irqchip/arm-gic-v3.h
index f1d6de53e09b..8157737053e4 100644
--- a/include/linux/irqchip/arm-gic-v3.h
+++ b/include/linux/irqchip/arm-gic-v3.h
@@ -484,8 +484,9 @@
#define GITS_CMD_VMAPTIGITS_CMD_GICv4(GITS_CMD_MAPTI)
#define GITS_CMD_VMOVI GITS_CMD_GICv4(GITS_CMD_MOVI)
#define GITS_CMD_VSYNC GITS_CMD_GICv4(GITS_CMD_SYNC)
-/* VMOVP is the odd one, as it doesn't have a physical counterpart */
+/* VMOVP and INVDB are the odd ones, as they dont have a physical counterpart
*/
#define GITS_CMD_VMOVP GITS_CMD_GICv4(2)
+#define GITS_CMD_INVDB GITS_CMD_GICv4(0xe)
/*
* ITS error numbers
--
2.20.1
[PATCH 12/35] irqchip/gic-v4.1: Don't use the VPE proxy if RVPEID is set
The infamous VPE proxy device isn't used with GICv4.1 because:
- we can invalidate any LPI from the DirectLPI MMIO interface
- the ITS and redistributors understand the life cycle of
the doorbell, so we don't need to enable/disable it all
the time
So let's escape early from the proxy related functions.
Signed-off-by: Marc Zyngier
---
drivers/irqchip/irq-gic-v3-its.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 8d6deb75b973..a9976bc81d9a 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -3065,7 +3065,7 @@ static const struct irq_domain_ops its_domain_ops = {
/*
* This is insane.
*
- * If a GICv4 doesn't implement Direct LPIs (which is extremely
+ * If a GICv4.0 doesn't implement Direct LPIs (which is extremely
* likely), the only way to perform an invalidate is to use a fake
* device to issue an INV command, implying that the LPI has first
* been mapped to some event on that device. Since this is not exactly
@@ -3073,9 +3073,18 @@ static const struct irq_domain_ops its_domain_ops = {
* only issue an UNMAP if we're short on available slots.
*
* Broken by design(tm).
+ *
+ * GICv4.1 actually mandates that we're able to invalidate by writing to a
+ * MMIO register. It doesn't implement the whole of DirectLPI, but that's
+ * good enough. And most of the time, we don't even have to invalidate
+ * anything, so that's actually pretty good!
*/
static void its_vpe_db_proxy_unmap_locked(struct its_vpe *vpe)
{
+ /* GICv4.1 doesn't use a proxy, so nothing to do here */
+ if (gic_rdists->has_rvpeid)
+ return;
+
/* Already unmapped? */
if (vpe->vpe_proxy_event == -1)
return;
@@ -3098,6 +3107,10 @@ static void its_vpe_db_proxy_unmap_locked(struct its_vpe
*vpe)
static void its_vpe_db_proxy_unmap(struct its_vpe *vpe)
{
+ /* GICv4.1 doesn't use a proxy, so nothing to do here */
+ if (gic_rdists->has_rvpeid)
+ return;
+
if (!gic_rdists->has_direct_lpi) {
unsigned long flags;
@@ -3109,6 +3122,10 @@ static void its_vpe_db_proxy_unmap(struct its_vpe *vpe)
static void its_vpe_db_proxy_map_locked(struct its_vpe *vpe)
{
+ /* GICv4.1 doesn't use a proxy, so nothing to do here */
+ if (gic_rdists->has_rvpeid)
+ return;
+
/* Already mapped? */
if (vpe->vpe_proxy_event != -1)
return;
@@ -3131,6 +3148,10 @@ static void its_vpe_db_proxy_move(struct its_vpe *vpe,
int from, int to)
unsigned long flags;
struct its_collection *target_col;
+ /* GICv4.1 doesn't use a proxy, so nothing to do here */
+ if (gic_rdists->has_rvpeid)
+ return;
+
if (gic_rdists->has_direct_lpi) {
void __iomem *rdbase;
--
2.20.1
general protection fault in finish_writeback_work
Hello, syzbot found the following crash on: HEAD commit:24ccb0ab qede: qede_fp: simplify a bit 'qede_rx_build_skb()' git tree: net console output: https://syzkaller.appspot.com/x/log.txt?x=11a5b22960 kernel config: https://syzkaller.appspot.com/x/.config?x=dfcf592db22b9132 dashboard link: https://syzkaller.appspot.com/bug?extid=828abc56e48ada4b0195 compiler: gcc (GCC) 9.0.0 20181231 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+828abc56e48ada4b0...@syzkaller.appspotmail.com kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: [#1] PREEMPT SMP KASAN CPU: 1 PID: 8777 Comm: kworker/u4:5 Not tainted 5.3.0+ #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: writeback wb_workfn (flush-8:0) RIP: 0010:__lock_acquire+0x1265/0x4e70 kernel/locking/lockdep.c:3828 Code: 00 0f 85 0e 26 00 00 48 81 c4 e8 00 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1 ea 03 <80> 3c 02 00 0f 85 dd 2a 00 00 49 81 3e a0 25 06 8a 0f 84 4e ee ff RSP: 0018:88806930f938 EFLAGS: 00010007 RAX: dc00 RBX: RCX: RDX: 03fffe22022b47e2 RSI: RDI: 0001 RBP: 88806930fa48 R08: 0001 R09: 0001 R10: fbfff138cf90 R11: 8880693002c0 R12: 1110115a3f15 R13: R14: 1110115a3f15 R15: 0001 FS: () GS:8880ae90() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7f2136820ea0 CR3: 8ab86000 CR4: 001406e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: lock_acquire+0x190/0x410 kernel/locking/lockdep.c:4487 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x95/0xcd kernel/locking/spinlock.c:159 __wake_up_common_lock+0xc8/0x150 kernel/sched/wait.c:122 __wake_up+0xe/0x10 kernel/sched/wait.c:142 finish_writeback_work.isra.0+0xf6/0x120 fs/fs-writeback.c:168 wb_do_writeback fs/fs-writeback.c:2030 [inline] wb_workfn+0x34f/0x11e0 fs/fs-writeback.c:2070 process_one_work+0x9af/0x1740 kernel/workqueue.c:2269 worker_thread+0x98/0xe40 kernel/workqueue.c:2415 kthread+0x361/0x430 kernel/kthread.c:255 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352 Modules linked in: ---[ end trace b7a1091622454beb ]--- RIP: 0010:__lock_acquire+0x1265/0x4e70 kernel/locking/lockdep.c:3828 Code: 00 0f 85 0e 26 00 00 48 81 c4 e8 00 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1 ea 03 <80> 3c 02 00 0f 85 dd 2a 00 00 49 81 3e a0 25 06 8a 0f 84 4e ee ff RSP: 0018:88806930f938 EFLAGS: 00010007 RAX: dc00 RBX: RCX: RDX: 03fffe22022b47e2 RSI: RDI: 0001 RBP: 88806930fa48 R08: 0001 R09: 0001 R10: fbfff138cf90 R11: 8880693002c0 R12: 1110115a3f15 R13: R14: 1110115a3f15 R15: 0001 FS: () GS:8880ae90() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7f2136820ea0 CR3: 8ab86000 CR4: 001406e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
Re: [PATCH AUTOSEL 5.3 173/203] ASoC: es8316: support fixed and variable both clock rates
On Sun, Sep 22, 2019 at 02:43:19PM -0400, Sasha Levin wrote: > From: Katsuhiro Suzuki > > [ Upstream commit ebe02a5b9ef05e3b812af3d628cdf6206d9ba610 ] > > This patch supports some type of machine drivers that set 0 to mclk > when sound device goes to idle state. After applied this patch, > sysclk == 0 means there is no constraint of sound rate and other > values will set constraints which is derived by sysclk setting. This is a new feature and clearly out of scope for stable. signature.asc Description: PGP signature
Re: [PATCH] ARM: omap2plus_defconfig: Enable DRM_TI_TFP410
* Adam Ford [190911 10:47]:
> The TFP410 driver was removed but the replacement driver was
> never enabled. This patch enableds the DRM_TI_TFP410
>
> Fixes: be3143d8b27f ("drm/omap: Remove TFP410 and DVI connector drivers")
Applying into fixes thanks.
Tony
[PATCH v3] Added QUIRKs for ADATA XPG SX8200 Pro 512GB
Booting with default_ps_max_latency_us >6000 makes the device fail.
Also SUBNQN is NULL and gives a warning on each boot/resume.
$ nvme id-ctrl /dev/nvme0 | grep ^subnqn
subnqn: (null)
I use this device with an Acer Nitro 5 (AN515-43-R8BF) Laptop.
To be sure is not a Laptop issue only, I tested the device on
my server board with the same results.
( with 2x,4x link on the board and 4x link on a PCI-E card ).
Signed-off-by: Gabriel Craciunescu
Reviewed-by: Sagi Grimberg
---
drivers/nvme/host/pci.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index 6b4d7b064b38..f5767741838b 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -3088,6 +3088,9 @@ static const struct pci_device_id nvme_id_table[] = {
.driver_data = NVME_QUIRK_LIGHTNVM, },
{ PCI_DEVICE(0x10ec, 0x5762), /* ADATA SX6000LNP */
.driver_data = NVME_QUIRK_IGNORE_DEV_SUBNQN, },
+ { PCI_DEVICE(0x1cc1, 0x8201), /* ADATA SX8200PNP 512GB */
+ .driver_data = NVME_QUIRK_NO_DEEPEST_PS |
+ NVME_QUIRK_IGNORE_DEV_SUBNQN, },
{ PCI_DEVICE_CLASS(PCI_CLASS_STORAGE_EXPRESS, 0xff) },
{ PCI_DEVICE(PCI_VENDOR_ID_APPLE, 0x2001) },
{ PCI_DEVICE(PCI_VENDOR_ID_APPLE, 0x2003) },
--
2.23.0
Re: [PATCH AUTOSEL 5.3 087/203] ASoC: mediatek: mt6358: add delay after dmic clock on
On Sun, Sep 22, 2019 at 02:41:53PM -0400, Sasha Levin wrote: > From: Jiaxin Yu > > [ Upstream commit ccb1fa21ef58a2ac15519bb878470762e967e8b3 ] > > Most dmics produce a high level when they receive clock. The difference > between power-on and memory record time is about 10ms, but the dmic > needs 50ms to output normal data. > > This commit add 100ms delay after SoC output clock so that we can cut > off the pop noise at the beginning. This might mess up a production system, please don't backport it. In general delays to eliminate pops and clicks that are part of the PCM statup path (as opposed to DAPM) are not safe to backport. signature.asc Description: PGP signature
Re: [RFC patch 00/15] entry: Provide generic implementation for host and guest entry/exit work
On Thu, Sep 19, 2019 at 8:09 AM Thomas Gleixner wrote: > > When working on a way to move out the posix cpu timer expiry out of the > timer interrupt context, I noticed that KVM is not handling pending task > work before entering a guest. A quick hack was to add that to the x86 KVM > handling loop. The discussion ended with a request to make this a generic > infrastructure possible with also moving the per arch implementations of > the enter from and return to user space handling generic. > > > https://lore.kernel.org/r/89e42bcc-47a8-458b-b06a-d6a20d205...@amacapital.net > > You asked for it, so don't complain that you have to review it :) > > The series implements the syscall enter/exit and the general exit to > userspace work handling along with the pre guest enter functionality. > > The series converts x86 and ARM64. x86 is fully tested including selftests > etc. ARM64 is only compile tested for now as my only ARM64 testbox is not > available right now. Other than the comments I sent so far, I like this series.
Re: [GIT PULL] MIPS changes
On Mon, Sep 23, 2019 at 11:07 AM Paul Burton wrote: > > Another issue is that there are currently 'expected' warnings dotted > through the tree for various defconfigs This is why I refuse to have _any_ warnings at all in my tree during the merge window. If you have expected warnings, you will ignore the new and valid ones. So the only acceptable situation is "no warnings". In honesty, I actually do have one warning in my tree: samples/vfs/test-statx.c:24:15: warning: ‘struct foo’ declared inside parameter list will not be visible outside of this definition or declaration 24 | #define statx foo | ^~~ but because it's in the sample code, it pretty much never gets rebuilt for me unless I basically do a "git clean" to get rid of everything, so I don't normally see it for any normal pull. So I've ignored that one warning, although I've actually been tempted to just remove the sample because of it. Adding David and Al to the cc just in case they have some simple fixup for it that is likely to work across different user headers. I considered just adding a struct foo; declaration, but the whole thing is incredibly ugly. Linus
Re: [PATCH 0/2] intel-speed-select: Convert output to tables
On Mon, 2019-09-23 at 09:16 -0400, Prarit Bhargava wrote: > The turbo ratio limits and turbo frequencies add a large amount of > lines to the output. The output can be truncated into human and > machine readable tables to reduce the number of lines of output. > Unfortunately this breaks json output. The idea is that the software should be able to parse json output using available json libraries and consume information, without developing complex parser. For example: #intel-speed-select -o out.json -f json perf-profile info Copy paste contents of out.json in any online json editor/tools, itshouldn't give error. Thanks, Srinivas > Signed-off-by: Prarit Bhargava > Cc: Srinivas Pandruvada > > Prarit Bhargava (2): > intel-speed-select: Display turbo-ratio-limits as a table > intel-speed-select: Display turbo frequencies in a table > > .../x86/intel-speed-select/isst-display.c | 196 +--- > -- > 1 file changed, 94 insertions(+), 102 deletions(-) >
Re: [RFC patch 14/15] workpending: Provide infrastructure for work before entering a guest
On Thu, Sep 19, 2019 at 8:09 AM Thomas Gleixner wrote:
>
> Entering a guest is similar to exiting to user space. Pending work like
> handling signals, rescheduling, task work etc. needs to be handled before
> that.
>
> Provide generic infrastructure to avoid duplication of the same handling code
> all over the place.
>
> Update ARM64 struct kvm_vcpu_stat with a signal_exit member so the generic
> code compiles.
>
> Signed-off-by: Thomas Gleixner
> ---
> arch/arm64/include/asm/kvm_host.h |1
> include/linux/entry-common.h | 66
> ++
> kernel/entry/common.c | 44 +
> 3 files changed, 111 insertions(+)
>
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -409,6 +409,7 @@ struct kvm_vcpu_stat {
> u64 wfi_exit_stat;
> u64 mmio_exit_user;
> u64 mmio_exit_kernel;
> + u64 signal_exits;
> u64 exits;
> };
>
> --- a/include/linux/entry-common.h
> +++ b/include/linux/entry-common.h
> @@ -255,4 +255,70 @@ static inline void arch_syscall_exit_tra
> /* Common syscall exit function */
> void syscall_exit_to_usermode(struct pt_regs *regs, long syscall, long
> retval);
>
> +#if IS_ENABLED(CONFIG_KVM)
> +
> +#include
> +
> +#ifndef ARCH_EXIT_TO_GUESTMODE_WORK
> +# define ARCH_EXIT_TO_GUESTMODE_WORK (0)
> +#endif
> +
> +#define EXIT_TO_GUESTMODE_WORK \
> + (_TIF_NEED_RESCHED | _TIF_SIGPENDING | _TIF_NOTIFY_RESUME | \
> +ARCH_EXIT_TO_GUESTMODE_WORK)
> +
> +int core_exit_to_guestmode_work(struct kvm *kvm, struct kvm_vcpu *vcpu,
> + unsigned long ti_work);
> +
> +/**
> + * arch_exit_to_guestmode - Architecture specific exit to guest mode function
> + * @kvm: Pointer to the guest instance
> + * @vcpu: Pointer to current's VCPU data
> + * @ti_work: Cached TIF flags gathered in exit_to_guestmode()
> + *
> + * Invoked from core_exit_to_guestmode_work(). Can be replaced by
> + * architecture specific code.
> + */
> +static inline int arch_exit_to_guestmode(struct kvm *kvm, struct kvm_vcpu
> *vcpu,
> +unsigned long ti_work);
Can you add a comment about whether IRQs are supposed to be off (I
assume they are) and perhaps a lockdep assertion to verify it?
Re: [PATCH 15/17] KVM: retpolines: x86: eliminate retpoline from vmx.c exit handlers
On Mon, Sep 23, 2019 at 01:42:44PM -0400, Andrea Arcangeli wrote: > On Mon, Sep 23, 2019 at 06:53:10PM +0200, Paolo Bonzini wrote: > > On 23/09/19 18:37, Sean Christopherson wrote: > > >> Would it be too much if we get rid of > > >> kvm_vmx_exit_handlers completely replacing this code with one switch()? > > > Hmm, that'd require redirects for nVMX functions since they are set at > > > runtime. That isn't necessarily a bad thing. The approach could also be > > > used if Paolo's idea of making kvm_vmx_max_exit_handlers const allows the > > > compiler to avoid retpoline. > > > > But aren't switch statements also retpolin-ized if they use a jump table? > > See commit a9d57ef15cbe327fe54416dd194ee0ea66ae53a4. > > We disabled that feature or the kernel would potentially suffer the > downsides of the exit handlers through pointer to functions for every > switch statement in the kernel. > > In turn you can't make it run any faster by converting my "if" to a > "switch" at least the "if" can deterministic control the order of what > is more likely that we should also re-review, but the order of secondary > effect, the important thing is to reduce the retpolines to zero during > normal hrtimer guest runtime. On the flip side, using a switch for the fast-path handlers gives the compiler more flexibility to rearrange and combine checks. Of course that doesn't mean the compiler will actually generate faster code for our purposes :-) Anyways, getting rid of the retpolines is much more important.
[PATCH v2 2/2] x86/boot/64: round memory hole size up to next PMD page.
The kernel image map is created using PMD pages, which can include
some extra space beyond what's actually needed. Round the size of the
memory hole we search for up to the next PMD boundary, to be certain
all of the space to be mapped is usable RAM and includes no reserved
areas.
Signed-off-by: Steve Wahl
Cc: sta...@vger.kernel.org
---
Changes since v1:
* This patch is completely new to this verison.
arch/x86/boot/compressed/misc.c | 25 +++--
1 file changed, 19 insertions(+), 6 deletions(-)
diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
index 53ac0cb2396d..9652d5c2afda 100644
--- a/arch/x86/boot/compressed/misc.c
+++ b/arch/x86/boot/compressed/misc.c
@@ -345,6 +345,7 @@ asmlinkage __visible void *extract_kernel(void *rmode,
memptr heap,
{
const unsigned long kernel_total_size = VO__end - VO__text;
unsigned long virt_addr = LOAD_PHYSICAL_ADDR;
+ unsigned long needed_size;
/* Retain x86 boot parameters pointer passed from startup_32/64. */
boot_params = rmode;
@@ -379,26 +380,38 @@ asmlinkage __visible void *extract_kernel(void *rmode,
memptr heap,
free_mem_ptr = heap;/* Heap */
free_mem_end_ptr = heap + BOOT_HEAP_SIZE;
+ /*
+* The memory hole needed for the kernel is the larger of either
+* the entire decompressed kernel plus relocation table, or the
+* entire decompressed kernel plus .bss and .brk sections.
+*
+* On X86_64, the memory is mapped with PMD pages. Round the
+* size up so that the full extent of PMD pages mapped is
+* included in the check against the valid memory table
+* entries. This ensures the full mapped area is usable RAM
+* and doesn't include any reserved areas.
+*/
+ needed_size = max(output_len, kernel_total_size);
+#ifdef CONFIG_X86_64
+ needed_size = ALIGN(needed_size, MIN_KERNEL_ALIGN);
+#endif
+
/* Report initial kernel position details. */
debug_putaddr(input_data);
debug_putaddr(input_len);
debug_putaddr(output);
debug_putaddr(output_len);
debug_putaddr(kernel_total_size);
+ debug_putaddr(needed_size);
#ifdef CONFIG_X86_64
/* Report address of 32-bit trampoline */
debug_putaddr(trampoline_32bit);
#endif
- /*
-* The memory hole needed for the kernel is the larger of either
-* the entire decompressed kernel plus relocation table, or the
-* entire decompressed kernel plus .bss and .brk sections.
-*/
choose_random_location((unsigned long)input_data, input_len,
(unsigned long *)&output,
- max(output_len, kernel_total_size),
+ needed_size,
&virt_addr);
/* Validate memory location choices. */
--
2.21.0
--
Steve Wahl, Hewlett Packard Enterprise
[PATCH v2 1/2] x86/boot/64: Make level2_kernel_pgt pages invalid outside kernel area.
Our hardware (UV aka Superdome Flex) has address ranges marked
reserved by the BIOS. Access to these ranges is caught as an error,
causing the BIOS to halt the system.
Initial page tables mapped a large range of physical addresses that
were not checked against the list of BIOS reserved addresses, and
sometimes included reserved addresses in part of the mapped range.
Including the reserved range in the map allowed processor speculative
accesses to the reserved range, triggering a BIOS halt.
Used early in booting, the page table level2_kernel_pgt addresses 1
GiB divided into 2 MiB pages, and it was set up to linearly map a full
1 GiB of physical addresses that included the physical address range
of the kernel image, as chosen by KASLR. But this also included a
large range of unused addresses on either side of the kernel image.
And unlike the kernel image's physical address range, this extra
mapped space was not checked against the BIOS tables of usable RAM
addresses. So there were times when the addresses chosen by KASLR
would result in processor accessible mappings of BIOS reserved
physical addresses.
The kernel code did not directly access any of this extra mapped
space, but having it mapped allowed the processor to issue speculative
accesses into reserved memory, causing system halts.
This was encountered somewhat rarely on a normal system boot, and much
more often when starting the crash kernel if "crashkernel=512M,high"
was specified on the command line (this heavily restricts the physical
address of the crash kernel, in our case usually within 1 GiB of
reserved space).
The solution is to invalidate the pages of this table outside the
kernel image's space before the page table is activated. This patch
has been validated to fix this problem on our hardware.
Signed-off-by: Steve Wahl
Cc: sta...@vger.kernel.org
---
Changes since v1:
* Added comment.
* Reworked changelog text.
arch/x86/kernel/head64.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index 29ffa495bd1c..ee9d0e3e0c46 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -222,13 +222,27 @@ unsigned long __head __startup_64(unsigned long physaddr,
* we might write invalid pmds, when the kernel is relocated
* cleanup_highmap() fixes this up along with the mappings
* beyond _end.
+*
+* Only the region occupied by the kernel image has so far
+* been checked against the table of usable memory regions
+* provided by the firmware, so invalidate pages outside that
+* region. A page table entry that maps to a reserved area of
+* memory would allow processor speculation into that area,
+* and on some hardware (particularly the UV platform) even
+* speculative access to some reserved areas is caught as an
+* error, causing the BIOS to halt the system.
*/
pmd = fixup_pointer(level2_kernel_pgt, physaddr);
- for (i = 0; i < PTRS_PER_PMD; i++) {
+ for (i = 0; i < pmd_index((unsigned long)_text); i++)
+ pmd[i] &= ~_PAGE_PRESENT;
+
+ for (; i <= pmd_index((unsigned long)_end); i++)
if (pmd[i] & _PAGE_PRESENT)
pmd[i] += load_delta;
- }
+
+ for (; i < PTRS_PER_PMD; i++)
+ pmd[i] &= ~_PAGE_PRESENT;
/*
* Fixup phys_base - remove the memory encryption mask to obtain
--
2.21.0
--
Steve Wahl, Hewlett Packard Enterprise
[PATCH v2 0/2] x86/boot/64: Avoid mapping reserved ranges in early page tables.
This patch set narrows the valid space addressed by the page table level2_kernel_pgt to only contain ranges checked against the "usable RAM" list provided by the BIOS. Prior to this, some larger than needed mappings were occasionally crossing over into spaces marked reserved, allowing the processor to access these reserved spaces, which were caught by the hardware and caused BIOS to halt on our platform (UV). Changes since v1: * Cover letter added because there's now two patches. * Patch 1: Added comment and re-worked changelog text. * Patch 2: New change requested by Dave Hansen to handle the case that the mapping of the last PMD page for the kernel image could cross a reserved region boundary. Steve Wahl (2): x86/boot/64: Make level2_kernel_pgt pages invalid outside kernel area. x86/boot/64: round memory hole size up to next PMD page. arch/x86/boot/compressed/misc.c | 25 +++-- arch/x86/kernel/head64.c| 18 -- 2 files changed, 35 insertions(+), 8 deletions(-) -- 2.21.0 -- Steve Wahl, Hewlett Packard Enterprise
Re: [PATCH 1/3] regulator: core: fix boot-on regulators use_count usage
On Mon, Sep 23, 2019 at 11:02:26AM -0700, Doug Anderson wrote: > I will freely admit my ignorance here, but I've always been slightly > confused by the "always-on" vs. "boot-on" distinction... > The bindings say: > regulator-always-on: > description: boolean, regulator should never be disabled > regulator-boot-on: > description: bootloader/firmware enabled regulator > For 'boot-on' that's a bit ambiguous about what it means. The > constraints have a bit more details: Boot on means that it's powered on when the kernel starts, it's for regulators that we can't read back the status of. > ...but then that begs the question of why we have two attributes? > Maybe this has already been discussed before and someone can point me > to a previous discussion? We should probably make it more clear in > the bindings and/or the constraints. boot-on just refers to the status at boot, we can still turn those regulators off later on if we want to. signature.asc Description: PGP signature
Re: [PATCH] x86/mm/pti: Handle unaligned addr to PMD-mapped page in pti_clone_pgtable
On Mon, Sep 23, 2019 at 4:28 AM Peter Zijlstra wrote: > > I'm conflicted on this one... the only use of addr here is > pti_user_pagetable_walk_pmd() and that already masks things, so the > fixup is 'pointless'. No it's not. The *other* use of 'addr' is addr += PMD_SIZE; and then repeat the loop. And that repeat might then use it for the page-level case the next iteration. > Also the location is weird; we'd want to do alignment enforcement before > we commence the for-loop, methinks. No. See again. The alignment is different for the different cases inside the loop. Some do per-page stuff, some do per-pmd stuff, and some do per-pud stuff. And you don't know which you'll hit a-priori (because it's not limited to the 'level' testing). Linus
Re: [LTP] 12abeb544d: ltp.read_all_dev.fail
On Mon, Sep 23, 2019 at 8:39 AM Petr Vorel wrote:
>
> Hi,
>
> > > FYI, we noticed the following commit (built with gcc-7):
>
> > > commit: 12abeb544d548f55f56323fc6e5e6c0fb74f58e1 ("horrible test hack")
> > > https://kernel.googlesource.com/pub/scm/linux/kernel/git/luto/linux.git
> > > random/kill-it
>
> ...
> > > tst_test.c:1108: INFO: Timeout per run is 0h 05m 00s
> > > Test timeouted, sending SIGKILL!
> > > tst_test.c:1148: INFO: If you are running on slow machine, try exporting
> > > LTP_TIMEOUT_MUL > 1
> > > tst_test.c:1149: BROK: Test killed! (timeout?)
>
> > So perhaps this is caused by reads of /dev/random hanging?
>
> > At any rate,
> > I suppose this is intended to deliberately break something, so we can
> > ignore it.
> Yep, I'd ignore it, [1] really looks like the commit description "horrible
> test hack" :)
>
Indeed. I should have pushed this to my not-for-automated-testing tree.
--Andy
Re: [PATCH 19/73] libperf: Move system_wide from struct evsel to struct perf_evsel
Em Fri, Sep 13, 2019 at 03:23:01PM +0200, Jiri Olsa escreveu:
> diff --git a/tools/perf/lib/include/internal/evsel.h
> b/tools/perf/lib/include/internal/evsel.h
> index 8b854d1c9b45..220cb2e2b54e 100644
> --- a/tools/perf/lib/include/internal/evsel.h
> +++ b/tools/perf/lib/include/internal/evsel.h
> @@ -18,6 +18,7 @@ struct perf_evsel {
>
> /* parse modifier helper */
> int nr_members;
> + bool system_wide;
> };
Forgot to add:
#include
Added.
- Arnaldo
Re: [GIT PULL] MIPS changes
Hi Linus,
On Sun, Sep 22, 2019 at 11:35:36AM -0700, Linus Torvalds wrote:
> On Sat, Sep 21, 2019 at 4:10 PM Paul Burton wrote:
> >
> > Here are the main MIPS changes for v5.4; please pull.
>
> Hmm. I pulled and because initial tests didn't show any issues, I
> already pushed out.
>
> But some unrelated further testing then shows that this:
>
> > Florian Fainelli (2):
> > firmware: bcm47xx_nvram: Correct size_t printf format
> > firmware: bcm47xx_nvram: Allow COMPILE_TEST
>
> causes problems, and commit feb4eb060c3a ("firmware: bcm47xx_nvram:
> Correct size_t printf format") is buggy:
>
> drivers/firmware/broadcom/bcm47xx_nvram.c: In function ‘nvram_init’:
> drivers/firmware/broadcom/bcm47xx_nvram.c:151: warning: format ‘%zu’
> expects argument of type ‘size_t’, but argument 2 has type ‘u32’ {aka
> ‘unsigned int’} [-Wformat=]
>
> and the change to use %zu was completely wrong.
>
> It prints out 'header.len', which is an u32, not nvram_len which is a size_t.
>
> Tssk tssk.
Oopsie.
> I've fixed it in my tree, but this should have shown up in linux-next,
> or in MIPS testing. The process clearly failed.
Looking back I do see that the kbuild test robot reported an issue here,
so one aspect of the failure is squarely on my not having caught up on
email properly yet.
Another issue is that there are currently 'expected' warnings dotted
through the tree for various defconfigs, so whilst I do perform test
builds before submitting pull requests I generally don't pay too much
attention to warnings... So an improvement I'll look at is fixing up
those warnings & building with -Werror, or at least not ignoring
warnings.
My apologies and thanks for fixing this up,
Paul
Re: [PATCH v4 05/10] mm: Return faster for non-fatal signals in user mode faults
On Sun, Sep 22, 2019 at 9:26 PM Peter Xu wrote:
>
> This patch is a preparation of removing that special path by allowing
> the page fault to return even faster if we were interrupted by a
> non-fatal signal during a user-mode page fault handling routine.
So I really wish saome other vm person would also review these things,
but looking over this series once more, this is the patch I probably
like the least.
And the reason I like it the least is that I have a hard time
explaining to myself what the code does and why, and why it's so full
of this pattern:
> - if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current))
> + if ((fault & VM_FAULT_RETRY) &&
> + fault_should_check_signal(user_mode(regs)))
> return;
which isn't all that pretty.
Why isn't this just
static bool fault_signal_pending(unsigned int fault_flags, struct
pt_regs *regs)
{
return (fault_flags & VM_FAULT_RETRY) &&
(fatal_signal_pending(current) ||
(user_mode(regs) && signal_pending(current)));
}
and then most of the users would be something like
if (fault_signal_pending(fault, regs))
return;
and the exceptions could do their own thing.
Now the code is prettier and more understandable, I feel.
And if something doesn't follow this pattern, maybe it either _should_
follow that pattern or it should just not use the helper but explain
why it has an unusual pattern.
Linus
Re: [PATCH 1/3] regulator: core: fix boot-on regulators use_count usage
Hi,
On Tue, Sep 17, 2019 at 8:40 AM Marco Felsch wrote:
>
> Since commit 1fc12b05895e ("regulator: core: Avoid propagating to
> supplies when possible") regulators marked with boot-on can't be
> disabled anymore because the commit handles always-on and boot-on
> regulators the same way.
>
> Now commit 05f224ca6693 ("regulator: core: Clean enabling always-on
> regulators + their supplies") changed the regulator_resolve_supply()
> logic a bit by using 'use_count'. So we can't just skip the
> 'use_count++' during set_machine_constraints(). The easiest way I found
> is to correct the 'use_count' just before returning the rdev device
> during regulator_register().
>
> Signed-off-by: Marco Felsch
> ---
> drivers/regulator/core.c | 5 +
> 1 file changed, 5 insertions(+)
I will freely admit my ignorance here, but I've always been slightly
confused by the "always-on" vs. "boot-on" distinction...
The bindings say:
regulator-always-on:
description: boolean, regulator should never be disabled
regulator-boot-on:
description: bootloader/firmware enabled regulator
For 'boot-on' that's a bit ambiguous about what it means. The
constraints have a bit more details:
* @always_on: Set if the regulator should never be disabled.
* @boot_on: Set if the regulator is enabled when the system is initially
* started. If the regulator is not enabled by the hardware or
* bootloader then it will be enabled when the constraints are
* applied.
What I would take from that is that "boot_on" means that we expect
that the firmware probably turned this regulator on but if it didn't
then the kernel should turn it on (and presumably leave it on?). That
would mean that your patch is incorrect, I think?
...but then that begs the question of why we have two attributes?
Maybe this has already been discussed before and someone can point me
to a previous discussion? We should probably make it more clear in
the bindings and/or the constraints.
===
NOTE: I'm curious why you even have the "regulator-boot-on" attribute
in your case to begin with. Why not leave it off?
-Doug
Re: [PATCH] pinctrl: devicetree.c: remove orphan pinctrl_dt_has_hogs()
* Rasmus Villemoes [190923 14:20]: > The helper pinctrl_dt_has_hogs() was introduced in > 99e4f67508e1 (pinctrl: core: Use delayed work for hogs), but the sole > use then got removed shortly after in 950b0d91dc10 (pinctrl: core: Fix > regression caused by delayed work for hogs). Oops, thanks for catching it: Acked-by: Tony Lindgren
Re: [PATCH v2 linux-next 1/4] arm: configs: omap2plus_defconfig: Change CONFIG_REMOTEPROC from m to y
* Keerthy [190920 08:00]:
> Commit 6334150e9a36 ("remoteproc: don't allow modular build")
> changes CONFIG_REMOTEPROC to a boolean from a tristate config
> option which inhibits all defconfigs marking CONFIG_REMOTEPROC as
> a module in compiling the remoteproc and dependent config options.
>
> So fix the omap2plus_defconfig to have CONFIG_REMOTEPROC built in.
Acked-by: Tony Lindgren
[tip: x86/urgent] x86/purgatory: Disable the stackleak GCC plugin for the purgatory
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: ca14c996afe7228ff9b480cf225211cc17212688
Gitweb:
https://git.kernel.org/tip/ca14c996afe7228ff9b480cf225211cc17212688
Author:Arvind Sankar
AuthorDate:Mon, 23 Sep 2019 13:17:54 -04:00
Committer: Ingo Molnar
CommitterDate: Mon, 23 Sep 2019 19:48:02 +02:00
x86/purgatory: Disable the stackleak GCC plugin for the purgatory
Since commit:
b059f801a937 ("x86/purgatory: Use CFLAGS_REMOVE rather than reset
KBUILD_CFLAGS")
kexec breaks if GCC_PLUGIN_STACKLEAK=y is enabled, as the purgatory
contains undefined references to stackleak_track_stack.
Attempting to load a kexec kernel results in this failure:
kexec: Undefined symbol: stackleak_track_stack
kexec-bzImage64: Loading purgatory failed
Fix this by disabling the stackleak plugin for the purgatory.
Signed-off-by: Arvind Sankar
Reviewed-by: Nick Desaulniers
Cc: Borislav Petkov
Cc: H. Peter Anvin
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Fixes: b059f801a937 ("x86/purgatory: Use CFLAGS_REMOVE rather than reset
KBUILD_CFLAGS")
Link: https://lkml.kernel.org/r/20190923171753.ga2252...@rani.riverdale.lan
Signed-off-by: Ingo Molnar
---
arch/x86/purgatory/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/purgatory/Makefile b/arch/x86/purgatory/Makefile
index 10fb42d..b81b517 100644
--- a/arch/x86/purgatory/Makefile
+++ b/arch/x86/purgatory/Makefile
@@ -23,6 +23,7 @@ KCOV_INSTRUMENT := n
PURGATORY_CFLAGS_REMOVE := -mcmodel=kernel
PURGATORY_CFLAGS := -mcmodel=large -ffreestanding -fno-zero-initialized-in-bss
+PURGATORY_CFLAGS += $(DISABLE_STACKLEAK_PLUGIN)
# Default KBUILD_CFLAGS can have -pg option set when FTRACE is enabled. That
# in turn leaves some undefined symbols like __fentry__ in purgatory and not
Re: [PATCH 5/5] arm64: dts: imx8mq: add DCSS node
On Mon, Sep 23, 2019 at 2:01 PM Lucas Stach wrote: > No, they are not. Those are imx-irqsteer IRQs, this controller has 0 > irq cells, so the description in this patch is correct. Good point, thanks!
[tip: x86/urgent] x86/purgatory: Disable the stackleak GCC plugin for the purgatory
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: ca14c996afe7228ff9b480cf225211cc17212688
Gitweb:
https://git.kernel.org/tip/ca14c996afe7228ff9b480cf225211cc17212688
Author:Arvind Sankar
AuthorDate:Mon, 23 Sep 2019 13:17:54 -04:00
Committer: Ingo Molnar
CommitterDate: Mon, 23 Sep 2019 19:48:02 +02:00
x86/purgatory: Disable the stackleak GCC plugin for the purgatory
Since commit:
b059f801a937 ("x86/purgatory: Use CFLAGS_REMOVE rather than reset
KBUILD_CFLAGS")
kexec breaks if GCC_PLUGIN_STACKLEAK=y is enabled, as the purgatory
contains undefined references to stackleak_track_stack.
Attempting to load a kexec kernel results in this failure:
kexec: Undefined symbol: stackleak_track_stack
kexec-bzImage64: Loading purgatory failed
Fix this by disabling the stackleak plugin for the purgatory.
Signed-off-by: Arvind Sankar
Reviewed-by: Nick Desaulniers
Cc: Borislav Petkov
Cc: H. Peter Anvin
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Fixes: b059f801a937 ("x86/purgatory: Use CFLAGS_REMOVE rather than reset
KBUILD_CFLAGS")
Link: https://lkml.kernel.org/r/20190923171753.ga2252...@rani.riverdale.lan
Signed-off-by: Ingo Molnar
---
arch/x86/purgatory/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/purgatory/Makefile b/arch/x86/purgatory/Makefile
index 10fb42d..b81b517 100644
--- a/arch/x86/purgatory/Makefile
+++ b/arch/x86/purgatory/Makefile
@@ -23,6 +23,7 @@ KCOV_INSTRUMENT := n
PURGATORY_CFLAGS_REMOVE := -mcmodel=kernel
PURGATORY_CFLAGS := -mcmodel=large -ffreestanding -fno-zero-initialized-in-bss
+PURGATORY_CFLAGS += $(DISABLE_STACKLEAK_PLUGIN)
# Default KBUILD_CFLAGS can have -pg option set when FTRACE is enabled. That
# in turn leaves some undefined symbols like __fentry__ in purgatory and not
Re: [PATCH v8 8/9] leds: lp50xx: Add the LP50XX family of the RGB LED driver
Jacek On 9/21/19 10:11 AM, Jacek Anaszewski wrote: Dan, On 9/20/19 7:41 PM, Dan Murphy wrote: Introduce the LP5036/30/24/18/12/9 RGB LED driver. The difference in these parts are the number of LED outputs where the: LP5036 can control 36 LEDs LP5030 can control 30 LEDs LP5024 can control 24 LEDs LP5018 can control 18 LEDs LP5012 can control 12 LEDs LP509 can control 9 LEDs The device has the ability to group LED output into control banks so that multiple LED banks can be controlled with the same mixing and brightness. Inversely the LEDs can also be controlled independently. Signed-off-by: Dan Murphy --- drivers/leds/Kconfig | 7 + drivers/leds/Makefile | 1 + drivers/leds/leds-lp50xx.c | 785 + 3 files changed, 793 insertions(+) create mode 100644 drivers/leds/leds-lp50xx.c diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig index cfb1ebb6517f..1c0cacb100e6 100644 --- a/drivers/leds/Kconfig +++ b/drivers/leds/Kconfig @@ -363,6 +363,13 @@ config LEDS_LP3952 To compile this driver as a module, choose M here: the module will be called leds-lp3952. +config LEDS_LP50XX + tristate "LED Support for TI LP5036/30/24/18 LED driver chip" + depends on LEDS_CLASS && REGMAP_I2C && OF Not sure why I would add that since we are using fw_node calls not of_property calls. The fw_node calls are built in as default kernel so these should always be available. Unless this is a led_class has a dependency + help + If you say yes here you get support for the Texas Instruments + LP5036, LP5030, LP5024 and LP5018 LED driver. Please add also this standard sentence for a module. Ack + config LEDS_LP55XX_COMMON tristate "Common Driver for TI/National LP5521/5523/55231/5562/8501" depends on LEDS_LP5521 || LEDS_LP5523 || LEDS_LP5562 || LEDS_LP8501 diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile index 841038cfe35b..7a208a0f7b84 100644 --- a/drivers/leds/Makefile +++ b/drivers/leds/Makefile @@ -34,6 +34,7 @@ obj-$(CONFIG_LEDS_GPIO_REGISTER) += leds-gpio-register.o obj-$(CONFIG_LEDS_GPIO) += leds-gpio.o obj-$(CONFIG_LEDS_LP3944) += leds-lp3944.o obj-$(CONFIG_LEDS_LP3952) += leds-lp3952.o +obj-$(CONFIG_LEDS_LP50XX) += leds-lp50xx.o obj-$(CONFIG_LEDS_LP55XX_COMMON) += leds-lp55xx-common.o obj-$(CONFIG_LEDS_LP5521) += leds-lp5521.o obj-$(CONFIG_LEDS_LP5523) += leds-lp5523.o diff --git a/drivers/leds/leds-lp50xx.c b/drivers/leds/leds-lp50xx.c new file mode 100644 index ..3ddc14f53eae --- /dev/null +++ b/drivers/leds/leds-lp50xx.c @@ -0,0 +1,785 @@ +// SPDX-License-Identifier: GPL-2.0 +// TI LP50XX LED chip family driver +// Copyright (C) 2018 Texas Instruments Incorporated -http://www.ti.com/ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#define LP50XX_DEV_CFG00x00 +#define LP50XX_DEV_CFG10x01 +#define LP50XX_LED_CFG00x02 + +/* LP5009 and LP5012 registers */ +#define LP5012_BNK_BRT 0x03 +#define LP5012_BNKA_CLR0x04 +#define LP5012_BNKB_CLR0x05 +#define LP5012_BNKC_CLR0x06 +#define LP5012_LED0_BRT0x07 +#define LP5012_LED1_BRT0x08 +#define LP5012_LED2_BRT0x09 +#define LP5012_LED3_BRT0x0a +#define LP5012_OUT0_CLR0x0b +#define LP5012_OUT1_CLR0x0c +#define LP5012_OUT2_CLR0x0d +#define LP5012_OUT3_CLR0x0e +#define LP5012_OUT4_CLR0x0f +#define LP5012_OUT5_CLR0x10 +#define LP5012_OUT6_CLR0x11 +#define LP5012_OUT7_CLR0x12 +#define LP5012_OUT8_CLR0x13 +#define LP5012_OUT9_CLR0x14 +#define LP5012_OUT10_CLR 0x15 +#define LP5012_OUT11_CLR 0x16 +#define LP5012_RESET 0x17 + +/* LP5018 and LP5024 registers */ +#define LP5024_BNK_BRT 0x03 +#define LP5024_BNKA_CLR0x04 +#define LP5024_BNKB_CLR0x05 +#define LP5024_BNKC_CLR0x06 +#define LP5024_LED0_BRT0x07 +#define LP5024_LED1_BRT0x08 +#define LP5024_LED2_BRT0x09 +#define LP5024_LED3_BRT0x0a +#define LP5024_LED4_BRT0x0b +#define LP5024_LED5_BRT0x0c +#define LP5024_LED6_BRT0x0d +#define LP5024_LED7_BRT0x0e + +#define LP5024_OUT0_CLR0x0f +#define LP5024_OUT1_CLR0x10 +#define LP5024_OUT2_CLR0x11 +#define LP5024_OUT3_CLR0x12 +#define LP5024_OUT4_CLR0x13 +#define LP5024_OUT5_CLR0x14 +#define LP5024_OUT6_CLR
Re: [PATCH RT v3 3/5] sched: migrate_dis/enable: Use rt_invol_sleep
On 2019-09-23 11:59:23 [-0500], Scott Wood wrote: > On Tue, 2019-09-17 at 09:06 -0500, Scott Wood wrote: > > On Tue, 2019-09-17 at 09:59 +0200, Sebastian Andrzej Siewior wrote: > > > On 2019-09-11 17:57:27 [+0100], Scott Wood wrote: > > > > diff --git a/kernel/cpu.c b/kernel/cpu.c > > > > index 885a195dfbe0..32c6175b63b6 100644 > > > > --- a/kernel/cpu.c > > > > +++ b/kernel/cpu.c > > > > @@ -308,7 +308,9 @@ void pin_current_cpu(void) > > > > preempt_lazy_enable(); > > > > preempt_enable(); > > > > > > > > + rt_invol_sleep_inc(); > > > > __read_rt_lock(cpuhp_pin); > > > > + rt_invol_sleep_dec(); > > > > > > > > preempt_disable(); > > > > preempt_lazy_disable(); > > > > > > I understand the other one. But now looking at it, both end up in > > > rt_spin_lock_slowlock_locked() which would be the proper place to do > > > that annotation. Okay. > > > > FWIW, if my lazy migrate patchset is accepted, then there will be no users > > of __read_rt_lock() outside rwlock-rt.c and it'll be moot. > > I missed the "both" -- which is the "other one" that ends up in > rt_spin_lock_slowlock_locked()? stop_one_cpu() doesn't... That one used here: __read_rt_lock() -> rt_spin_lock_slowlock_locked() The official one (including the write part): rt_read_lock() (annotation) -> do_read_rt_lock() -> __read_rt_lock() -> rt_spin_lock_slowlock_locked() and the only missing to the party of sleeping locks is: rt_spin_lock() (annotation) -> rt_spin_lock_slowlock() -> rt_spin_lock_slowlock_locked() > -Scott Sebastian
[PATCH] dt-bindings: at24: convert the binding document to yaml
From: Bartosz Golaszewski
Convert the binding document for at24 EEPROMs from txt to yaml. The
compatible property uses a regex pattern to address all the possible
combinations of "vendor,model" strings.
Signed-off-by: Bartosz Golaszewski
---
.../devicetree/bindings/eeprom/at24.txt | 90 +--
.../devicetree/bindings/eeprom/at24.yaml | 107 ++
MAINTAINERS | 2 +-
3 files changed, 109 insertions(+), 90 deletions(-)
create mode 100644 Documentation/devicetree/bindings/eeprom/at24.yaml
diff --git a/Documentation/devicetree/bindings/eeprom/at24.txt
b/Documentation/devicetree/bindings/eeprom/at24.txt
index 22aead844d0f..c94acbb8cb0c 100644
--- a/Documentation/devicetree/bindings/eeprom/at24.txt
+++ b/Documentation/devicetree/bindings/eeprom/at24.txt
@@ -1,89 +1 @@
-EEPROMs (I2C)
-
-Required properties:
-
- - compatible: Must be a "," pair. The following
-values are supported (assuming "atmel" as manufacturer):
-
-"atmel,24c00",
-"atmel,24c01",
-"atmel,24cs01",
-"atmel,24c02",
-"atmel,24cs02",
-"atmel,24mac402",
-"atmel,24mac602",
-"atmel,spd",
-"atmel,24c04",
-"atmel,24cs04",
-"atmel,24c08",
-"atmel,24cs08",
-"atmel,24c16",
-"atmel,24cs16",
-"atmel,24c32",
-"atmel,24cs32",
-"atmel,24c64",
-"atmel,24cs64",
-"atmel,24c128",
-"atmel,24c256",
-"atmel,24c512",
-"atmel,24c1024",
-"atmel,24c2048",
-
-If is not "atmel", then a fallback must be used
-with the same and "atmel" as manufacturer.
-
-Example:
-compatible = "microchip,24c128", "atmel,24c128";
-
-Supported manufacturers are:
-
-"catalyst",
-"microchip",
-"nxp",
-"ramtron",
-"renesas",
-"rohm",
-"st",
-
-Some vendors use different model names for chips which are just
-variants of the above. Known such exceptions are listed below:
-
-"nxp,se97b" - the fallback is "atmel,24c02",
-"renesas,r1ex24002" - the fallback is "atmel,24c02"
-"renesas,r1ex24016" - the fallback is "atmel,24c16"
-"renesas,r1ex24128" - the fallback is "atmel,24c128"
-"rohm,br24t01" - the fallback is "atmel,24c01"
-
- - reg: The I2C address of the EEPROM.
-
-Optional properties:
-
- - pagesize: The length of the pagesize for writing. Please consult the
- manual of your device, that value varies a lot. A wrong value
- may result in data loss! If not specified, a safety value of
- '1' is used which will be very slow.
-
- - read-only: This parameterless property disables writes to the eeprom.
-
- - size: Total eeprom size in bytes.
-
- - no-read-rollover: This parameterless property indicates that the
- multi-address eeprom does not automatically roll over
- reads to the next slave address. Please consult the
- manual of your device.
-
- - wp-gpios: GPIO to which the write-protect pin of the chip is connected.
-
- - address-width: number of address bits (one of 8, 16).
-
- - num-addresses: total number of i2c slave addresses this device takes
-
-Example:
-
-eeprom@52 {
- compatible = "atmel,24c32";
- reg = <0x52>;
- pagesize = <32>;
- wp-gpios = <&gpio1 3 0>;
- num-addresses = <8>;
-};
+This file has been moved to at24.yaml.
diff --git a/Documentation/devicetree/bindings/eeprom/at24.yaml
b/Documentation/devicetree/bindings/eeprom/at24.yaml
new file mode 100644
index ..28c8b068c8a1
--- /dev/null
+++ b/Documentation/devicetree/bindings/eeprom/at24.yaml
@@ -0,0 +1,107 @@
+# SPDX-License-Identifier: GPL-2.0
+# Copyright 2019 BayLibre SAS
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/eeprom/at24.yaml#";
+$schema: "http://devicetree.org/meta-schemas/core.yaml#";
+
+title: I2C EEPROMs compatible with Atmel's AT24
+
+maintainers:
+ - Bartosz Golaszewski
+
+properties:
+ compatible:
+additionalItems: true
+maxItems: 2
+pattern:
"^(atmel|catalyst|microchip|nxp|ramtron|renesas|rohm|st),24(c|cs|mac)[0-9]+$"
+oneOf:
+ - const: nxp,se97b
+ - const: renesas,r1ex24002
+ - const: renesas,r1ex24016
+ - const: renesas,r1ex24128
+ - const: rohm,br24t01
+contains:
+ enum:
+- atmel,24c00
+- atmel,24c01
+- atmel,24cs01
+- atmel,24c02
+- atmel,24cs02
+- atmel,24mac402
+- atmel,24mac602
+
Re: [PATCH v5 0/7] hugetlb_cgroup: Add hugetlb_cgroup reservation limits
On 9/19/19 3:24 PM, Mina Almasry wrote: > Patch series implements hugetlb_cgroup reservation usage and limits, which > track hugetlb reservations rather than hugetlb memory faulted in. Details of > the approach is 1/7. Thanks for your continued efforts Mina. One thing that has bothered me with this approach from the beginning is that hugetlb reservations are related to, but somewhat distinct from hugetlb allocations. The original (existing) huegtlb cgroup implementation does not take reservations into account. This is an issue you are trying to address by adding a cgroup support for hugetlb reservations. However, this new reservation cgroup ignores hugetlb allocations at fault time. I 'think' the whole purpose of any hugetlb cgroup is to manage the allocation of hugetlb pages. Both the existing cgroup code and the reservation approach have what I think are some serious flaws. Consider a system with 100 hugetlb pages available. A sysadmin, has two groups A and B and wants to limit hugetlb usage to 50 pages each. With the existing implementation, a task in group A could create a mmap of 100 pages in size and reserve all 100 pages. Since the pages are 'reserved', nobody in group B can allocate ANY huge pages. This is true even though no pages have been allocated in A (or B). With the reservation implementation, a task in group A could use MAP_NORESERVE and allocate all 100 pages without taking any reservations. As mentioned in your documentation, it would be possible to use both the existing (allocation) and new reservation cgroups together. Perhaps if both are setup for the 50/50 split things would work a little better. However, instead of creating a new reservation crgoup how about adding reservation support to the existing allocation cgroup support. One could even argue that a reservation is an allocation as it sets aside huge pages that can only be used for a specific purpose. Here is something that may work. Starting with the existing allocation cgroup. - When hugetlb pages are reserved, the cgroup of the task making the reservations is charged. Tracking for the charged cgroup is done in the reservation map in the same way proposed by this patch set. - At page fault time, - If a reservation already exists for that specific area do not charge the faulting task. No tracking in page, just the reservation map. - If no reservation exists, charge the group of the faulting task. Tracking of this information is in the page itself as implemented today. - When the hugetlb object is removed, compare the reservation map with any allocated pages. If cgroup tracking information exists in page, uncharge that group. Otherwise, unharge the group (if any) in the reservation map. One of the advantages of a separate reservation cgroup is that the existing code is unmodified. Combining the two provides a more complete/accurate solution IMO. But, it has the potential to break existing users. I really would like to get feedback from anyone that knows how the existing hugetlb cgroup controller may be used today. Comments from Aneesh would be very welcome to know if reservations were considered in development of the existing code. -- Mike Kravetz
[PATCH] dt-bindings: iio: maxbotix,mb1232.yaml: transform to yaml
transform existing documentation of maxbotix,mb1232 ultrasonic ranger
from text documentation format into yaml.
Signed-off-by: Andreas Klinger
---
.../bindings/iio/proximity/maxbotix,mb1232.txt | 29 ---
.../bindings/iio/proximity/maxbotix,mb1232.yaml| 56 ++
2 files changed, 56 insertions(+), 29 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.txt
create mode 100644
Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.yaml
diff --git
a/Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.txt
b/Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.txt
deleted file mode 100644
index dd1058fbe9c3..
--- a/Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.txt
+++ /dev/null
@@ -1,29 +0,0 @@
-* MaxBotix I2CXL-MaxSonar ultrasonic distance sensor of type mb1202,
- mb1212, mb1222, mb1232, mb1242, mb7040 or mb7137 using the i2c interface
- for ranging
-
-Required properties:
- - compatible: "maxbotix,mb1202",
- "maxbotix,mb1212",
- "maxbotix,mb1222",
- "maxbotix,mb1232",
- "maxbotix,mb1242",
- "maxbotix,mb7040" or
- "maxbotix,mb7137"
-
- - reg:i2c address of the device, see also i2c/i2c.txt
-
-Optional properties:
- - interrupts: Interrupt used to announce the preceding reading
- request has finished and that data is available.
- If no interrupt is specified the device driver
- falls back to wait a fixed amount of time until
- data can be retrieved.
-
-Example:
-proximity@70 {
- compatible = "maxbotix,mb1232";
- reg = <0x70>;
- interrupt-parent = <&gpio2>;
- interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
-};
diff --git
a/Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.yaml
b/Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.yaml
new file mode 100644
index ..8301a1ad2a47
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/proximity/maxbotix,mb1232.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/proximity/maxbotix,mb1232.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MaxBotix I2CXL-MaxSonar ultrasonic distance sensor
+
+maintainers:
+ - Andreas Klinger
+
+description: |
+ MaxBotix I2CXL-MaxSonar ultrasonic distance sensor of type mb1202,
+ mb1212, mb1222, mb1232, mb1242, mb7040 or mb7137 using the i2c interface
+ for ranging
+
+ Specifications about the devices can be found at:
+ https://www.maxbotix.com/documents/I2CXL-MaxSonar-EZ_Datasheet.pdf
+
+properties:
+ compatible:
+enum:
+ - maxbotix,mb1202
+ - maxbotix,mb1212
+ - maxbotix,mb1222
+ - maxbotix,mb1232
+ - maxbotix,mb1242
+ - maxbotix,mb7040
+ - maxbotix,mb7137
+
+ reg:
+description:
+ i2c address of the device, see also i2c/i2c.txt
+maxItems: 1
+
+ interrupts:
+description:
+ Interrupt used to announce the preceding reading request has finished
+ and that data is available. If no interrupt is specified the device
+ driver falls back to wait a fixed amount of time until data can be
+ retrieved.
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+#include
+proximity@70 {
+ compatible = "maxbotix,mb1232";
+ reg = <0x70>;
+ interrupt-parent = <&gpio2>;
+ interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
+};
--
2.11.0
Re: [PATCH 15/17] KVM: retpolines: x86: eliminate retpoline from vmx.c exit handlers
On Mon, Sep 23, 2019 at 06:53:10PM +0200, Paolo Bonzini wrote: > On 23/09/19 18:37, Sean Christopherson wrote: > >> Would it be too much if we get rid of > >> kvm_vmx_exit_handlers completely replacing this code with one switch()? > > Hmm, that'd require redirects for nVMX functions since they are set at > > runtime. That isn't necessarily a bad thing. The approach could also be > > used if Paolo's idea of making kvm_vmx_max_exit_handlers const allows the > > compiler to avoid retpoline. > > But aren't switch statements also retpolin-ized if they use a jump table? See commit a9d57ef15cbe327fe54416dd194ee0ea66ae53a4. We disabled that feature or the kernel would potentially suffer the downsides of the exit handlers through pointer to functions for every switch statement in the kernel. In turn you can't make it run any faster by converting my "if" to a "switch" at least the "if" can deterministic control the order of what is more likely that we should also re-review, but the order of secondary effect, the important thing is to reduce the retpolines to zero during normal hrtimer guest runtime.
Re: [for-next][PATCH 7/8] tracing/probe: Reject exactly same probe event
> > I think we need something like this:
> >
> > list_for_each_entry(pos, &tpe->probes, list) {
> > orig = container_of(pos, struct trace_kprobe, tp);
> > if (strcmp(trace_kprobe_symbol(orig),
> >trace_kprobe_symbol(comp)) ||
> > trace_kprobe_offset(orig) != trace_kprobe_offset(comp))
> > continue;
> >
> > /*
> > * trace_probe_compare_arg_type() ensured that nr_args and
> > * each argument name and type are same. Let's compare comm.
> > */
> > for (i = 0; i < orig->tp.nr_args; i++) {
> > if (strcmp(orig->tp.args[i].comm,
> >comp->tp.args[i].comm))
> > goto outer_loop;
> >
> > }
> >
> > return true;
> > outer_loop:
> > }
>
> Correct, that's what I intended.
> Could you make a fix patch on top of it? (or do I?)
>
> Thank you,
Either way is fine. I can send out a patch tomorrow. But fine if you beat
me to it.
--
Thanks and Regards
Srikar Dronamraju
Re: [PATCH V8 2/2] arm64/mm: Enable memory hot remove
Hi Anshuman, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [cannot apply to v5.3 next-20190920] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system. BTW, we also suggest to use '--base' option to specify the base tree in git format-patch, please see https://stackoverflow.com/a/37406982] url: https://github.com/0day-ci/linux/commits/Anshuman-Khandual/arm64-mm-Hold-memory-hotplug-lock-while-walking-for-kernel-page-table-dump/20190923-134733 config: arm64-allmodconfig (attached as .config) compiler: aarch64-linux-gcc (GCC) 7.4.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree GCC_VERSION=7.4.0 make.cross ARCH=arm64 If you fix the issue, kindly add following tag Reported-by: kbuild test robot All warnings (new ones prefixed by >>): >> mm/memremap.c:16:0: warning: "SECTION_MASK" redefined #define SECTION_MASK ~((1UL << PA_SECTION_SHIFT) - 1) In file included from arch/arm64/include/asm/processor.h:34:0, from include/linux/mutex.h:19, from include/linux/kernfs.h:12, from include/linux/sysfs.h:16, from include/linux/kobject.h:20, from include/linux/device.h:16, from mm/memremap.c:3: arch/arm64/include/asm/pgtable-hwdef.h:79:0: note: this is the location of the previous definition #define SECTION_MASK (~(SECTION_SIZE-1)) >> mm/memremap.c:17:0: warning: "SECTION_SIZE" redefined #define SECTION_SIZE (1UL << PA_SECTION_SHIFT) In file included from arch/arm64/include/asm/processor.h:34:0, from include/linux/mutex.h:19, from include/linux/kernfs.h:12, from include/linux/sysfs.h:16, from include/linux/kobject.h:20, from include/linux/device.h:16, from mm/memremap.c:3: arch/arm64/include/asm/pgtable-hwdef.h:78:0: note: this is the location of the previous definition #define SECTION_SIZE (_AC(1, UL) << SECTION_SHIFT) vim +/SECTION_MASK +16 mm/memremap.c 7d3dcf26a6559f kernel/memremap.c Christoph Hellwig 2015-08-10 @3 #include 92281dee825f6d kernel/memremap.c Dan Williams 2015-08-10 4 #include 0207df4fa1a869 kernel/memremap.c Andrey Ryabinin 2018-08-17 5 #include 41e94a851304f7 kernel/memremap.c Christoph Hellwig 2015-08-17 6 #include bcfa4b72111c9a kernel/memremap.c Matthew Wilcox2018-08-15 7 #include bcfa4b72111c9a kernel/memremap.c Matthew Wilcox2018-08-15 8 #include 5042db43cc26f5 kernel/memremap.c Jérôme Glisse 2017-09-08 9 #include 5042db43cc26f5 kernel/memremap.c Jérôme Glisse 2017-09-08 10 #include bcfa4b72111c9a kernel/memremap.c Matthew Wilcox2018-08-15 11 #include e7638488434415 kernel/memremap.c Dan Williams 2018-05-16 12 #include bcfa4b72111c9a kernel/memremap.c Matthew Wilcox2018-08-15 13 #include 92281dee825f6d kernel/memremap.c Dan Williams 2015-08-10 14 bcfa4b72111c9a kernel/memremap.c Matthew Wilcox2018-08-15 15 static DEFINE_XARRAY(pgmap_array); 9476df7d80dfc4 kernel/memremap.c Dan Williams 2016-01-15 @16 #define SECTION_MASK ~((1UL << PA_SECTION_SHIFT) - 1) 9476df7d80dfc4 kernel/memremap.c Dan Williams 2016-01-15 @17 #define SECTION_SIZE (1UL << PA_SECTION_SHIFT) 9476df7d80dfc4 kernel/memremap.c Dan Williams 2016-01-15 18 :: The code at line 16 was first introduced by commit :: 9476df7d80dfc425b37bfecf1d89edf8ec81fcb6 mm: introduce find_dev_pagemap() :: TO: Dan Williams :: CC: Linus Torvalds --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH 0/6] tools/lib/traceevent: Man page updates and some file movement
Em Mon, Sep 23, 2019 at 11:59:29AM -0400, Steven Rostedt escreveu: > On Mon, 23 Sep 2019 11:12:48 -0400 > Steven Rostedt wrote: > > > Yeah. Let's not apply this one yet till we figure out what broke. I'll > > take a look at it too. > > Does this help? yeap, did the trick, I'm folding this one with the faulty one, thanks for the prompt reply. - Arnaldo > -- Steve > > diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf > index f9807d8c005b..7544166dd466 100644 > --- a/tools/perf/Makefile.perf > +++ b/tools/perf/Makefile.perf > @@ -292,7 +292,7 @@ endif > LIBTRACEEVENT = $(TE_PATH)libtraceevent.a > export LIBTRACEEVENT > > -LIBTRACEEVENT_DYNAMIC_LIST = $(TE_PATH)libtraceevent-dynamic-list > +LIBTRACEEVENT_DYNAMIC_LIST = $(TE_PATH)plugins/libtraceevent-dynamic-list > > # > # The static build has no dynsym table, so this does not work for > @@ -737,7 +737,7 @@ libtraceevent_plugins: FORCE > $(Q)$(MAKE) -C $(TRACE_EVENT_DIR) $(LIBTRACEEVENT_FLAGS) O=$(OUTPUT) > plugins > > $(LIBTRACEEVENT_DYNAMIC_LIST): libtraceevent_plugins > - $(Q)$(MAKE) -C $(TRACE_EVENT_DIR) $(LIBTRACEEVENT_FLAGS) O=$(OUTPUT) > $(OUTPUT)libtraceevent-dynamic-list > + $(Q)$(MAKE) -C $(TRACE_EVENT_DIR) $(LIBTRACEEVENT_FLAGS) O=$(OUTPUT) > $(OUTPUT)plugins/libtraceevent-dynamic-list > > $(LIBTRACEEVENT)-clean: > $(call QUIET_CLEAN, libtraceevent) -- - Arnaldo
Hello Dear Friend
Hello Dear Friend. I’m Mrs. Stellar Maoris a manger in HSBC bank of Spain Madrid, I am sending this brief letter to seek for your partnership and long term relationship, I have an important and urgent issue I want to discuss with you privately about Transaction fund worth the sum of $9.5m America dollars left by most of the greedy Asia Kuwait politician in our bank here in Spain Madrid A fund which suppose to have been use to develop the continent. If you know that you can invest this fund into profitable business in your country by the end we shall have 50%50 share each, kindly get back to me for more detail and procedures. Your urgent respond will be highly appreciated Awaiting to hear from you asap. My Regard. Stellar Maoris Email: stellerba...@barid.com Phone Number: +34(62) 768 5146
Re: [PATCH 01/17] x86: spec_ctrl: fix SPEC_CTRL initialization after kexec
Hello, On Mon, Sep 23, 2019 at 08:30:57AM -0700, Sean Christopherson wrote: > On Mon, Sep 23, 2019 at 12:22:23PM +0200, Paolo Bonzini wrote: > > On 20/09/19 23:24, Andrea Arcangeli wrote: > > > We can't assume the SPEC_CTRL msr is zero at boot because it could be > > > left enabled by a previous kernel booted with > > > spec_store_bypass_disable=on. > > > > > > Without this fix a boot with spec_store_bypass_disable=on followed by > > > a kexec boot with spec_store_bypass_disable=off would erroneously and > > > unexpectedly leave bit 2 set in SPEC_CTRL. > > > > > > Signed-off-by: Andrea Arcangeli > > > > Can you send this out separately, so that Thomas et al. can pick it up > > as a bug fix? As specified in the cover letter 1/17 was already intended to be merged separately. I just keep this included in case people had the idea of using kexec to benchmark this work, because I was bitten by that bug myself and it wasted a few days worth of benchmarks. > Can all off the patches that are not directly related to the monolithic > conversion be sent separately? AFAICT, patches 01, 03, 07, 08, 14, 15, 16 > and 17 are not required or dependent on the conversion to a monolithic > module. That's almost half the series... 03 07 08 are directly related to the monolithic conversion as the subject of the patch clarifies. In fact I should try to reorder 7/8 in front to make things more bisectable under all config options. Per subject of the patch, 14 is also an optimization that while not a strict requirement, is somewhat related to the monolithic conversion because in fact it may naturally disappear if I rename the vmx/svm functions directly. 15 16 17 don't have the monolithic tag in the subject of the patch and they're obviously unrelated to the monolithic conversion, but when I did the first research on this idea of dropping kvm.ko a couple of months ago, things didn't really work well until I got rid of those few last retpolines too. If felt as if the large retpoline regression wasn't linear with the number of retpolines executed for each vmexit, and that it was more linear with the percentage of vmexits that hit on any number of retpolines. So while they're not part of the monolithic conversion I assumed they're required to run any meaningful benchmark. I can drop 15 16 17 from further submits of course, after clarifying benchmark should be only run on the v1 full set I posted earlier, or they wouldn't be meaningful. Thanks, Andrea
Re: [PATCH v2] DTS: ARM: gta04: introduce legacy spi-cs-high to make display work again
* H. Nikolaus Schaller [190920 09:12]: > commit 6953c57ab172 "gpio: of: Handle SPI chipselect legacy bindings" > > did introduce logic to centrally handle the legacy spi-cs-high property > in combination with cs-gpios. This assumes that the polarity > of the CS has to be inverted if spi-cs-high is missing, even > and especially if non-legacy GPIO_ACTIVE_HIGH is specified. > > The DTS for the GTA04 was orginally introduced under the assumption > that there is no need for spi-cs-high if the gpio is defined with > proper polarity GPIO_ACTIVE_HIGH. > > This was not a problem until gpiolib changed the interpretation of > GPIO_ACTIVE_HIGH and missing spi-cs-high. > > The effect is that the missing spi-cs-high is now interpreted as CS being > low (despite GPIO_ACTIVE_HIGH) which turns off the SPI interface when the > panel is to be programmed by the panel driver. > > Therefore, we have to add the redundant and legacy spi-cs-high property > to properly activate CS. Thanks applying into fixes. Tony
Re: [PATCH V7 5/7] cpufreq: Register notifiers with the PM QoS framework
23.09.2019 16:56, Viresh Kumar пишет: > On 22-09-19, 23:12, Dmitry Osipenko wrote: >> This patch causes use-after-free on a cpufreq driver module reload. Please >> take a look, thanks in advance. >> >> >> [ 87.952369] >> == >> [ 87.953259] BUG: KASAN: use-after-free in >> notifier_chain_register+0x4f/0x9c >> [ 87.954031] Read of size 4 at addr e6abbd0c by task modprobe/243 >> >> [ 87.954901] CPU: 1 PID: 243 Comm: modprobe Tainted: GW >> 5.3.0-next-20190920-00185-gf61698eab956-dirty #2408 >> [ 87.956077] Hardware name: NVIDIA Tegra SoC (Flattened Device Tree) >> [ 87.956807] [] (unwind_backtrace) from [] >> (show_stack+0x11/0x14) >> [ 87.957709] [] (show_stack) from [] >> (dump_stack+0x89/0x98) >> [ 87.958616] [] (dump_stack) from [] >> (print_address_description.constprop.0+0x3d/0x340) >> [ 87.959785] [] (print_address_description.constprop.0) from >> [] >> (__kasan_report+0xe3/0x12c) >> [ 87.960907] [] (__kasan_report) from [] >> (notifier_chain_register+0x4f/0x9c) >> [ 87.962001] [] (notifier_chain_register) from [] >> (blocking_notifier_chain_register+0x29/0x3c) >> [ 87.963180] [] (blocking_notifier_chain_register) from >> [] >> (dev_pm_qos_add_notifier+0x79/0xf8) >> [ 87.964339] [] (dev_pm_qos_add_notifier) from [] >> (cpufreq_online+0x5e1/0x8a4) > > Hi Dmitry, > > Unfortunately I am traveling right now and can't test this stuff, though I may > have found the root cause here. Can you please test the below diff for me ? > > diff --git a/drivers/base/power/qos.c b/drivers/base/power/qos.c > index 6c90fd7e2ff8..9ac244ee05fe 100644 > --- a/drivers/base/power/qos.c > +++ b/drivers/base/power/qos.c > @@ -328,6 +328,8 @@ void dev_pm_qos_constraints_destroy(struct device *dev) > spin_unlock_irq(&dev->power.lock); > > kfree(qos->resume_latency.notifiers); > + kfree(qos->min_frequency.notifiers); > + kfree(qos->max_frequency.notifiers); > kfree(qos); > > out: > Doesn't help. The use-after-free bugs are usually caused by a missing NULL assignment after kfree(), like in this snippet: .. if (!a) a = kmalloc(); .. kfree(a); // a = NULL<-- missing! .. I briefly looked through the code and don't see anything obviously wrong. The bug isn't critical since unlikely that somebody reloads cpufreq module for a non-development purposes, so it's not a big deal and can wait. Please take your time. I also want to point out that kernel crashes after second module reload, hence the KASAN report should be valid.
Re: [PATCH v2 11/11] powerpc/mm/book3s64/pgtable: Uses counting method to skip serializing
On Fri, 2019-09-20 at 17:48 -0700, John Hubbard wrote:
>
[...]
> So it seems that full memory barriers (not just compiler barriers) are
> required.
> If the irq enable/disable somehow provides that, then your new code just goes
> along for the ride and Just Works. (You don't have any memory barriers in
> start_lockless_pgtbl_walk() / end_lockless_pgtbl_walk(), just the compiler
> barriers provided by the atomic inc/dec.)
>
> So it's really a pre-existing question about the correctness of the gup_fast()
> irq disabling approach.
I am not experienced in other archs, and I am still pretty new to
Power, but by what I could understand, this behavior is better
explained in serialize_against_pte_lookup.
What happens here is that, before doing a THP split/collapse, the
function does a update of the pmd and a serialize_against_pte_lookup,
in order do avoid a invalid output on a lockless pagetable walk.
Serialize basically runs a do_nothing in every cpu related to the
process, and wait for it to return.
This running depends on interrupt being enabled, so disabling it before
gup_pgd_range() and re-enabling after the end, makes the THP
split/collapse wait for gup_pgd_range() completion in every cpu before
continuing. (here happens the lock)
(As told before, every gup_pgd_range() that occurs after it uses a
updated pmd, so no problem.)
I am sure other archs may have a similar mechanism using
local_irq_{disable,enable}.
Did it answer your questions?
Best regards,
Leonardo Bras
signature.asc
Description: This is a digitally signed message part
Re: [PATCH] x86/purgatory: Add $(DISABLE_STACKLEAK_PLUGIN)
On Mon, Sep 23, 2019 at 10:17 AM Arvind Sankar wrote:
>
> Since commit b059f801a937 ("x86/purgatory: Use CFLAGS_REMOVE rather than
> reset KBUILD_CFLAGS") kexec breaks is GCC_PLUGIN_STACKLEAK is enabled, as
> the purgatory contains undefined references to stackleak_track_stack.
> Attempting to load a kexec kernel results in:
> kexec: Undefined symbol: stackleak_track_stack
> kexec-bzImage64: Loading purgatory failed
>
> Fix this by disabling the stackleak plugin for purgatory.
>
> Fixes: b059f801a937 ("x86/purgatory: Use CFLAGS_REMOVE rather than reset
> KBUILD_CFLAGS")
> Signed-off-by: Arvind Sankar
Reviewed-by: Nick Desaulniers
(Sorry for the fallout from b059f801a937, but this is giving us a
pretty good idea about what "runtime" requirements certain configs
have. It would be cool to eventually have some kind of kexec test
case that folks could run in QEMU).
> ---
> arch/x86/purgatory/Makefile | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/x86/purgatory/Makefile b/arch/x86/purgatory/Makefile
> index 527749066d31..fb4ee5444379 100644
> --- a/arch/x86/purgatory/Makefile
> +++ b/arch/x86/purgatory/Makefile
> @@ -25,6 +25,7 @@ KCOV_INSTRUMENT := n
>
> PURGATORY_CFLAGS_REMOVE := -mcmodel=kernel
> PURGATORY_CFLAGS := -mcmodel=large -ffreestanding
> -fno-zero-initialized-in-bss
> +PURGATORY_CFLAGS += $(DISABLE_STACKLEAK_PLUGIN)
>
> # Default KBUILD_CFLAGS can have -pg option set when FTRACE is enabled. That
> # in turn leaves some undefined symbols like __fentry__ in purgatory and not
> --
> 2.21.0
>
--
Thanks,
~Nick Desaulniers
[GIT PULL] Smack patches for v5.4
Hello Linus I have four patches for v5.4. Nothing is major. All but one are in response to mechanically detected potential issues. The remaining patch cleans up kernel-doc notations. This is my first direct pull request. I think I have followed process correctly, but if not I will attend to my error as required. The following changes since commit 0ecfebd2b52404ae0c54a878c872bb93363ada36: Linux 5.2 (2019-07-07 15:41:56 -0700) are available in the Git repository at: https://github.com/cschaufler/smack-next.git smack-for-5.4 for you to fetch changes up to e5bfad3d7acc5702f32aafeb388362994f4d7bd0: smack: use GFP_NOFS while holding inode_smack::smk_lock (2019-09-04 09:37:07 -0700) Eric Biggers (1): smack: use GFP_NOFS while holding inode_smack::smk_lock Jann Horn (1): Smack: Don't ignore other bprm->unsafe flags if LSM_UNSAFE_PTRACE is set Jia-Ju Bai (1): security: smack: Fix possible null-pointer dereferences in smack_socket_sock_rcv_skb() luanshi (1): smack: fix some kernel-doc notations security/smack/smack_access.c | 6 +++--- security/smack/smack_lsm.c| 40 2 files changed, 23 insertions(+), 23 deletions(-) signature.asc Description: OpenPGP digital signature
Re: [RFC patch 10/15] x86/entry: Move irq tracing to C code
On Mon, Sep 23, 2019 at 5:10 AM Peter Zijlstra wrote: > > On Mon, Sep 23, 2019 at 01:55:51PM +0200, Peter Zijlstra wrote: > > On Mon, Sep 23, 2019 at 01:49:20PM +0200, Peter Zijlstra wrote: > > > While walking the kids to school I wondered WTH we need to call > > > TRACE_IRQS_OFF in the first place. If this is the return from exception > > > path, interrupts had better be disabled already (in exception enter). > > > > > > For entry_64.S we have: > > > > > > - idtentry_part; which does TRACE_IRQS_OFF at the start and error_exit > > > at the end. > > > > > > - xen_do_hypervisor_callback, xen_failsafe_callback -- which are > > > confusing. > > > > > > So in the normal case, it appears we can simply do: > > > > > > diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S > > > index b7c3ea4cb19d..e9cf59ac554e 100644 > > > --- a/arch/x86/entry/entry_64.S > > > +++ b/arch/x86/entry/entry_64.S > > > @@ -1368,8 +1368,6 @@ END(error_entry) > > > > > > ENTRY(error_exit) > > > UNWIND_HINT_REGS > > > - DISABLE_INTERRUPTS(CLBR_ANY) > > > - TRACE_IRQS_OFF > > > testb $3, CS(%rsp) > > > jz retint_kernel > > > jmp retint_user > > > > > > and all should be well. This leaves Xen... > > > > > > For entry_32.S it looks like nothing uses 'resume_userspace' so that > > > ENTRY can go away. Which then leaves: > > > > > > * ret_from_intr: > > > - common_spurious: TRACE_IRQS_OFF > > > - common_interrupt: TRACE_IRQS_OFF > > > - BUILD_INTERRUPT3: TRACE_IRQS_OFF > > > - xen_do_upcall: ... > > > > > > * ret_from_exception: > > > - xen_failsafe_callback: ... > > > - common_exception_read_cr2: TRACE_IRQS_OFF > > > - common_exception: TRACE_IRQS_OFF > > > - int3: TRACE_IRQS_OFF > > > > > > Which again suggests: > > > > > > diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S > > > index f83ca5aa8b77..7a19e7413a8e 100644 > > > --- a/arch/x86/entry/entry_32.S > > > +++ b/arch/x86/entry/entry_32.S > > > @@ -825,9 +825,6 @@ END(ret_from_fork) > > > cmpl$USER_RPL, %eax > > > jb restore_all_kernel # not returning to v8086 or > > > userspace > > > > > > -ENTRY(resume_userspace) > > > - DISABLE_INTERRUPTS(CLBR_ANY) > > > - TRACE_IRQS_OFF > > > movl%esp, %eax > > > callprepare_exit_to_usermode > > > jmp restore_all > > > > > > with the notable exception (oh teh pun!) being Xen... _again_. > > > > > > With these patchlets on, we'd want prepare_exit_to_usermode() to > > > validate the IRQ state, but AFAICT it _should_ all just 'work' (famous > > > last words). > > > > > > Cc Juergen because Xen > > > > Arrgh.. faults!! they do local_irq_enable() but never disable them > > again. Arguably those functions should be symmetric and restore IF when > > they muck with it instead of relying on the exit path fixing things up. > > --- > diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S > index f83ca5aa8b77..7a19e7413a8e 100644 > --- a/arch/x86/entry/entry_32.S > +++ b/arch/x86/entry/entry_32.S > @@ -825,9 +825,6 @@ END(ret_from_fork) > cmpl$USER_RPL, %eax > jb restore_all_kernel # not returning to v8086 or > userspace ... Yes, please, but can you add an assertion under CONFIG_DEBUG_ENTRY that IRQs are actually off?
Re: [PATCH v2 1/2] rtc: wilco-ec: Remove yday and wday calculations
On Sun, Sep 22, 2019 at 1:05 PM Alexandre Belloni wrote: > > On 22/09/2019 18:13:06+0200, Pavel Machek wrote: > > On Mon 2019-09-16 12:12:15, Nick Crews wrote: > > > The tm_yday and tm_wday fields are not used by userspace, > > > so since they aren't needed within the driver, don't > > > bother calculating them. This is especially needed since > > > the rtc_year_days() call was crashing if the HW returned > > > an invalid time. > > > > > > Signed-off-by: Nick Crews > > > --- > > > drivers/rtc/rtc-wilco-ec.c | 4 > > > 1 file changed, 4 deletions(-) > > > > > > diff --git a/drivers/rtc/rtc-wilco-ec.c b/drivers/rtc/rtc-wilco-ec.c > > > index 8ad4c4e6d557..e84faa268caf 100644 > > > --- a/drivers/rtc/rtc-wilco-ec.c > > > +++ b/drivers/rtc/rtc-wilco-ec.c > > > @@ -110,10 +110,6 @@ static int wilco_ec_rtc_read(struct device *dev, > > > struct rtc_time *tm) > > > tm->tm_mday = rtc.day; > > > tm->tm_mon = rtc.month - 1; > > > tm->tm_year = rtc.year + (rtc.century * 100) - 1900; > > > - tm->tm_yday = rtc_year_days(tm->tm_mday, tm->tm_mon, tm->tm_year); > > > - > > > - /* Don't compute day of week, we don't need it. */ > > > - tm->tm_wday = -1; > > > > > > return 0; > > > > Are you sure? It would be bad to pass unititialized memory to userspace... > > > > This problem doesn't exist because userspace is passing the memory, not > the other way around. > > > If userspace does not need those fields, why are they there? > > > > This is coming from struct tm, it is part of C89 but I think I was not > born when this decision was made. man rtc properly reports that those > fields are unused and no userspace tools are actually making use of > them. Nobody cares about the broken down representation of the time. > What is done is use the ioctl then mktime to have a UNIX timestamp. > > "The mktime function ignores the specified contents of the tm_wday, > tm_yday, tm_gmtoff, and tm_zone members of the broken-down time > structure. It uses the values of the other components to determine the > calendar time; it’s permissible for these components to have > unnormalized values outside their normal ranges. The last thing that > mktime does is adjust the components of the brokentime structure, > including the members that were initially ignored." This is very non-obvious and I only knew this from talking to you, Alexandre. Perhaps we should add this note to the RTC core, such as in the description for rtc_class_ops? For this patch, do you want me to make any further changes? Thanks, Nick > > > -- > Alexandre Belloni, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com
[PATCH] RDMA/core: Fix an error handling path in 'res_get_common_doit()'
According to surrounding error paths, it is likely that 'goto err_get;' is
expected here. Otherwise, a call to 'rdma_restrack_put(res);' would be
missing.
Fixes: c5dfe0ea6ffa ("RDMA/nldev: Add resource tracker doit callback")
Signed-off-by: Christophe JAILLET
---
drivers/infiniband/core/nldev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/core/nldev.c b/drivers/infiniband/core/nldev.c
index e287b71a1cfd..03272791a5bf 100644
--- a/drivers/infiniband/core/nldev.c
+++ b/drivers/infiniband/core/nldev.c
@@ -1231,7 +1231,7 @@ static int res_get_common_doit(struct sk_buff *skb,
struct nlmsghdr *nlh,
msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
if (!msg) {
ret = -ENOMEM;
- goto err;
+ goto err_get;
}
nlh = nlmsg_put(msg, NETLINK_CB(skb).portid, nlh->nlmsg_seq,
--
2.20.1
[PATCH] x86/purgatory: Add $(DISABLE_STACKLEAK_PLUGIN)
Since commit b059f801a937 ("x86/purgatory: Use CFLAGS_REMOVE rather than
reset KBUILD_CFLAGS") kexec breaks is GCC_PLUGIN_STACKLEAK is enabled, as
the purgatory contains undefined references to stackleak_track_stack.
Attempting to load a kexec kernel results in:
kexec: Undefined symbol: stackleak_track_stack
kexec-bzImage64: Loading purgatory failed
Fix this by disabling the stackleak plugin for purgatory.
Fixes: b059f801a937 ("x86/purgatory: Use CFLAGS_REMOVE rather than reset
KBUILD_CFLAGS")
Signed-off-by: Arvind Sankar
---
arch/x86/purgatory/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/purgatory/Makefile b/arch/x86/purgatory/Makefile
index 527749066d31..fb4ee5444379 100644
--- a/arch/x86/purgatory/Makefile
+++ b/arch/x86/purgatory/Makefile
@@ -25,6 +25,7 @@ KCOV_INSTRUMENT := n
PURGATORY_CFLAGS_REMOVE := -mcmodel=kernel
PURGATORY_CFLAGS := -mcmodel=large -ffreestanding -fno-zero-initialized-in-bss
+PURGATORY_CFLAGS += $(DISABLE_STACKLEAK_PLUGIN)
# Default KBUILD_CFLAGS can have -pg option set when FTRACE is enabled. That
# in turn leaves some undefined symbols like __fentry__ in purgatory and not
--
2.21.0
Re: [for-next][PATCH 7/8] tracing/probe: Reject exactly same probe event
On Mon, 23 Sep 2019 16:12:53 +0530
Srikar Dronamraju wrote:
> Hey Masami, Steven
>
> >
> > +static bool trace_kprobe_has_same_kprobe(struct trace_kprobe *orig,
> > +struct trace_kprobe *comp)
> > +{
> > + struct trace_probe_event *tpe = orig->tp.event;
> > + struct trace_probe *pos;
> > + int i;
> > +
> > + list_for_each_entry(pos, &tpe->probes, list) {
> > + orig = container_of(pos, struct trace_kprobe, tp);
> > + if (strcmp(trace_kprobe_symbol(orig),
> > + trace_kprobe_symbol(comp)) ||
> > + trace_kprobe_offset(orig) != trace_kprobe_offset(comp))
> > + continue;
> > +
> > + /*
> > +* trace_probe_compare_arg_type() ensured that nr_args and
> > +* each argument name and type are same. Let's compare comm.
> > +*/
> > + for (i = 0; i < orig->tp.nr_args; i++) {
> > + if (strcmp(orig->tp.args[i].comm,
> > + comp->tp.args[i].comm))
> > + continue;
>
> In a nested loop, *continue* is going to continue iterating through the
> inner loop. In which case, continue is doing nothing here. I thought we
> should have used a goto instead. No? To me, continue as a last statement of
> a for loop always looks weird.
Oops, thanks for pointing it out!
>
> > + }
> > +
> > + return true;
> > + }
>
> I think we need something like this:
>
> list_for_each_entry(pos, &tpe->probes, list) {
> orig = container_of(pos, struct trace_kprobe, tp);
> if (strcmp(trace_kprobe_symbol(orig),
> trace_kprobe_symbol(comp)) ||
> trace_kprobe_offset(orig) != trace_kprobe_offset(comp))
> continue;
>
> /*
>* trace_probe_compare_arg_type() ensured that nr_args and
>* each argument name and type are same. Let's compare comm.
>*/
> for (i = 0; i < orig->tp.nr_args; i++) {
> if (strcmp(orig->tp.args[i].comm,
> comp->tp.args[i].comm))
> goto outer_loop;
>
> }
>
> return true;
> outer_loop:
> }
Correct, that's what I intended.
Could you make a fix patch on top of it? (or do I?)
Thank you,
>
>
> > +
> > + return false;
> > +}
> > +
> >
>
> ..
>
> > +static bool trace_uprobe_has_same_uprobe(struct trace_uprobe *orig,
> > +struct trace_uprobe *comp)
> > +{
> > + struct trace_probe_event *tpe = orig->tp.event;
> > + struct trace_probe *pos;
> > + struct inode *comp_inode = d_real_inode(comp->path.dentry);
> > + int i;
> > +
> > + list_for_each_entry(pos, &tpe->probes, list) {
> > + orig = container_of(pos, struct trace_uprobe, tp);
> > + if (comp_inode != d_real_inode(orig->path.dentry) ||
> > + comp->offset != orig->offset)
> > + continue;
> > +
> > + /*
> > +* trace_probe_compare_arg_type() ensured that nr_args and
> > +* each argument name and type are same. Let's compare comm.
> > +*/
> > + for (i = 0; i < orig->tp.nr_args; i++) {
> > + if (strcmp(orig->tp.args[i].comm,
> > + comp->tp.args[i].comm))
> > + continue;
>
> Same as above.
>
> > + }
> > +
> > + return true;
> > + }
> > +
> > + return false;
> > +}
> > +
>
> --
> Thanks and Regards
> Srikar Dronamraju
>
--
Masami Hiramatsu
Re: [PATCH v2 1/5] perf cs-etm: Refactor instruction size handling
Hi Suzuki,
On Mon, Sep 23, 2019 at 05:51:04PM +0100, Suzuki K Poulose wrote:
> Hi Leo,
>
> On 23/09/2019 17:07, Leo Yan wrote:
> > In cs-etm.c there have several functions need to know instruction size
> > based on address, e.g. cs_etm__instr_addr() and cs_etm__copy_insn()
> > these two functions both calculate the instruction size separately.
> > Furthermore, if we consider to add new features later which also might
> > require to calculate instruction size.
> >
> > For this reason, this patch refactors the code to introduce a new
> > function cs_etm__instr_size(), it will be a central place to calculate
> > the instruction size based on ISA type and instruction address.
> >
> > For a neat implementation, cs_etm__instr_addr() will always execute the
> > loop without checking ISA type, this allows cs_etm__instr_size() and
> > cs_etm__instr_addr() have no any duplicate code with each other and both
> > functions can be changed independently later without breaking anything.
> > As a side effect, cs_etm__instr_addr() will do a few more iterations for
> > A32/A64 instructions, this would be fine if consider perf tool runs in
> > the user space.
> >
> > Signed-off-by: Leo Yan
>
> Your changes look fine to me. However, please see my comment below.
>
> > ---
> > tools/perf/util/cs-etm.c | 48 +++-
> > 1 file changed, 28 insertions(+), 20 deletions(-)
> >
> > diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
> > index f87b9c1c9f9a..1de3f9361193 100644
> > --- a/tools/perf/util/cs-etm.c
> > +++ b/tools/perf/util/cs-etm.c
> > @@ -917,6 +917,26 @@ static inline int cs_etm__t32_instr_size(struct
> > cs_etm_queue *etmq,
> > return ((instrBytes[1] & 0xF8) >= 0xE8) ? 4 : 2;
> > }
> > +static inline int cs_etm__instr_size(struct cs_etm_queue *etmq,
> > +u8 trace_chan_id,
> > +enum cs_etm_isa isa,
> > +u64 addr)
> > +{
> > + int insn_len;
> > +
> > + /*
> > +* T32 instruction size might be 32-bit or 16-bit, decide by calling
> > +* cs_etm__t32_instr_size().
> > +*/
> > + if (isa == CS_ETM_ISA_T32)
> > + insn_len = cs_etm__t32_instr_size(etmq, trace_chan_id, addr);
> > + /* Otherwise, A64 and A32 instruction size are always 32-bit. */
> > + else
> > + insn_len = 4;
> > +
> > + return insn_len;
> > +}
> > +
> > static inline u64 cs_etm__first_executed_instr(struct cs_etm_packet
> > *packet)
> > {
> > /* Returns 0 for the CS_ETM_DISCONTINUITY packet */
> > @@ -941,19 +961,15 @@ static inline u64 cs_etm__instr_addr(struct
> > cs_etm_queue *etmq,
> > const struct cs_etm_packet *packet,
> > u64 offset)
> > {
> > - if (packet->isa == CS_ETM_ISA_T32) {
> > - u64 addr = packet->start_addr;
> > + u64 addr = packet->start_addr;
> > - while (offset > 0) {
> > - addr += cs_etm__t32_instr_size(etmq,
> > - trace_chan_id, addr);
> > - offset--;
> > - }
> > - return addr;
> > + while (offset > 0) {
>
> Given that offset is u64, the check above is not appropriate. You could either
> change it to :
> while (offset) // if you are sure (s64)offset always is a postive
> integer and we always reduce it by 1.
>
> Otherwise you may switch the offset to a signed type. I understand that this
> is not introduced by your changes. But you may fix that up in a separate
> patch.
Thanks a lot for the review. Seems to me the reliable fix is to change
to a signed type. Will add this fix in next spin.
Thanks,
Leo Yan
Re: [PATCH v2 2/2] rtc: wilco-ec: Fix license to GPL from GPLv2
Would you like me to change this patch at all? Perhaps reference
bf7fbeeae6db in the commit description? I probably should have
done that since the beginning, I just couldn't find bf7fbeeae6db at first.
Thanks,
Nick
On Sun, Sep 22, 2019 at 2:43 PM Alexandre Belloni
wrote:
>
> On 22/09/2019 22:29:48+0200, Pavel Machek wrote:
> > On Mon 2019-09-16 12:12:17, Nick Crews wrote:
> > > Signed-off-by: Nick Crews
> > > ---
> > > drivers/rtc/rtc-wilco-ec.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/rtc/rtc-wilco-ec.c b/drivers/rtc/rtc-wilco-ec.c
> > > index e84faa268caf..951268f5e690 100644
> > > --- a/drivers/rtc/rtc-wilco-ec.c
> > > +++ b/drivers/rtc/rtc-wilco-ec.c
> > > @@ -184,5 +184,5 @@ module_platform_driver(wilco_ec_rtc_driver);
> > >
> > > MODULE_ALIAS("platform:rtc-wilco-ec");
> > > MODULE_AUTHOR("Nick Crews ");
> > > -MODULE_LICENSE("GPL v2");
> > > +MODULE_LICENSE("GPL");
> > > MODULE_DESCRIPTION("Wilco EC RTC driver");
> >
> > File spdx header says GPL-2.0, this change would make it inconsistent with
> > that...
> >
>
> Commit bf7fbeeae6db ("module: Cure the MODULE_LICENSE "GPL" vs. "GPL v2"
> bogosity") doesn't agree with you (but I was surprised too).
>
>
> --
> Alexandre Belloni, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
Re: [Patch v2 5/7] media: i2c: ov2659: Add powerdown/reset gpio handling
On Mon, Sep 23, 2019 at 12:05:57PM -0500, Benoit Parrot wrote: > Sakari Ailus wrote on Mon [2019-Sep-23 > 09:17:32 +0300]: > > Hi Benoit, > > > > On Fri, Sep 20, 2019 at 11:55:29AM -0500, Benoit Parrot wrote: > > ... > > > > > @@ -1400,6 +1440,18 @@ static int ov2659_probe(struct i2c_client > > > > > *client) > > > > > ov2659->xvclk_frequency > 2700) > > > > > return -EINVAL; > > > > > > > > > > + /* Optional gpio don't fail if not present */ > > > > > + ov2659->pwdn_gpio = devm_gpiod_get_optional(&client->dev, > > > > > "powerdown", > > > > > + GPIOD_OUT_LOW); > > > > > + if (IS_ERR(ov2659->pwdn_gpio)) > > > > > + return PTR_ERR(ov2659->pwdn_gpio); > > > > > + > > > > > + /* Optional gpio don't fail if not present */ > > > > > + ov2659->resetb_gpio = devm_gpiod_get_optional(&client->dev, > > > > > "reset", > > > > > + GPIOD_OUT_HIGH); > > > > > + if (IS_ERR(ov2659->resetb_gpio)) > > > > > + return PTR_ERR(ov2659->resetb_gpio); > > > > > + > > > > > v4l2_ctrl_handler_init(&ov2659->ctrls, 2); > > > > > ov2659->link_frequency = > > > > > v4l2_ctrl_new_std(&ov2659->ctrls, > > > > > &ov2659_ctrl_ops, > > > > > @@ -1445,6 +1497,9 @@ static int ov2659_probe(struct i2c_client > > > > > *client) > > > > > ov2659->frame_size = &ov2659_framesizes[2]; > > > > > ov2659->format_ctrl_regs = ov2659_formats[0].format_ctrl_regs; > > > > > > > > > > + pm_runtime_enable(&client->dev); > > > > > + pm_runtime_get_sync(&client->dev); > > > > > > > > This makes the driver depend on runtime PM. > > > > > > Obviously. > > > Why? Is that bad? > > > > Well, if it is, then it should be listed in driver's dependencies in > > Kconfig. > > And I see that most camera driver using pm_runtime calls don't mark it as a > dependency in their own Kconfig. There is actually only one that does. Drivers should also work without runtime PM even if they can use it. > > > > > > > > > > > > > > See e.g. the smiapp driver for an example how to make it work without. > > > > It > > > > wasn't trivial. :I You won't need autosuspend. > > > > > > I took a look at that driver, but I don't get your reference to being able > > > to work without runtime pm! > > > > The driver didn't need runtime PM, so it'd be nice to continue work > > without. > > Ok. > > > > > What smiapp does is that it powers the sensor on first *without* runtime > > PM, and then proceeds to set up runtime PM if it's available. The sensor > > will only be powered off when the device is unbound with runtime PM > > disabled. > > In that case in your original reply you suggested that I move the content > of ov2659_set_power() into the pm_runtime callback, but based on this > comments then I should keep ov2659_set_power() as is as I would need to > use it for this specific purpose. No need to; you can call the same function elsewhere in the driver (just like the smiapp driver does). > > > > > Regarding the smiapp driver, you can replace pm_runtime_get_noresume() and > > all the autoidle lines with pm_runtime_idle() call after > > pm_runtime_enable() in the ov2659 driver. > > Ok, I'll study this mechanics a little more, as this is not immediately > clear. > > Benoit > > > > > > That driver looks pretty similar to ov7740.c which I used as a reference > > > for this. > > > > I guess in practice many sensor drivers don't work without it on DT-based > > systems I'm afraid. :-( They should be fixed. > > > > -- > > Kind regards, > > > > Sakari Ailus > > sakari.ai...@linux.intel.com -- Sakari Ailus sakari.ai...@linux.intel.com
Re: [PATCH v8 3/3] mm: fix double page fault on arm64 if PTE_AF is cleared
On Sat, Sep 21, 2019 at 09:50:54PM +0800, Jia He wrote:
> @@ -2151,21 +2163,53 @@ static inline void cow_user_page(struct page *dst,
> struct page *src, unsigned lo
>* fails, we just zero-fill it. Live with it.
>*/
> if (unlikely(!src)) {
> - void *kaddr = kmap_atomic(dst);
> - void __user *uaddr = (void __user *)(va & PAGE_MASK);
> + void *kaddr;
> + pte_t entry;
> + void __user *uaddr = (void __user *)(addr & PAGE_MASK);
>
> + /* On architectures with software "accessed" bits, we would
> + * take a double page fault, so mark it accessed here.
> + */
Nitpick: please follow the kernel coding style for multi-line comments
(above and the for the rest of the patch):
/*
* Your multi-line comment.
*/
> + if (arch_faults_on_old_pte() && !pte_young(vmf->orig_pte)) {
> + vmf->pte = pte_offset_map_lock(mm, vmf->pmd, addr,
> +&vmf->ptl);
> + if (likely(pte_same(*vmf->pte, vmf->orig_pte))) {
> + entry = pte_mkyoung(vmf->orig_pte);
> + if (ptep_set_access_flags(vma, addr,
> + vmf->pte, entry, 0))
> + update_mmu_cache(vma, addr, vmf->pte);
> + } else {
> + /* Other thread has already handled the fault
> + * and we don't need to do anything. If it's
> + * not the case, the fault will be triggered
> + * again on the same address.
> + */
> + pte_unmap_unlock(vmf->pte, vmf->ptl);
> + return false;
> + }
> + pte_unmap_unlock(vmf->pte, vmf->ptl);
> + }
Another nit, you could rewrite this block slightly to avoid too much
indentation. Something like (untested):
if (arch_faults_on_old_pte() && !pte_young(vmf->orig_pte)) {
vmf->pte = pte_offset_map_lock(mm, vmf->pmd, addr,
&vmf->ptl);
if (unlikely(!pte_same(*vmf->pte, vmf->orig_pte))) {
/*
* Other thread has already handled the fault
* and we don't need to do anything. If it's
* not the case, the fault will be triggered
* again on the same address.
*/
pte_unmap_unlock(vmf->pte, vmf->ptl);
return false;
}
entry = pte_mkyoung(vmf->orig_pte);
if (ptep_set_access_flags(vma, addr,
vmf->pte, entry, 0))
update_mmu_cache(vma, addr, vmf->pte);
pte_unmap_unlock(vmf->pte, vmf->ptl);
}
> +
> + kaddr = kmap_atomic(dst);
Since you moved the kmap_atomic() here, could the above
arch_faults_on_old_pte() run in a preemptible context? I suggested to
add a WARN_ON in patch 2 to be sure.
> /*
>* This really shouldn't fail, because the page is there
>* in the page tables. But it might just be unreadable,
>* in which case we just give up and fill the result with
>* zeroes.
>*/
> - if (__copy_from_user_inatomic(kaddr, uaddr, PAGE_SIZE))
> + if (__copy_from_user_inatomic(kaddr, uaddr, PAGE_SIZE)) {
> + /* Give a warn in case there can be some obscure
> + * use-case
> + */
> + WARN_ON_ONCE(1);
That's more of a question for the mm guys: at this point we do the
copying with the ptl released; is there anything else that could have
made the pte old in the meantime? I think unuse_pte() is only called on
anonymous vmas, so it shouldn't be the case here.
> clear_page(kaddr);
> + }
> kunmap_atomic(kaddr);
> flush_dcache_page(dst);
> } else
> - copy_user_highpage(dst, src, va, vma);
> + copy_user_highpage(dst, src, addr, vma);
> +
> + return true;
> }
--
Catalin
Re: [Patch v2 5/7] media: i2c: ov2659: Add powerdown/reset gpio handling
Sakari Ailus wrote on Mon [2019-Sep-23 09:17:32 +0300]: > Hi Benoit, > > On Fri, Sep 20, 2019 at 11:55:29AM -0500, Benoit Parrot wrote: > ... > > > > @@ -1400,6 +1440,18 @@ static int ov2659_probe(struct i2c_client > > > > *client) > > > > ov2659->xvclk_frequency > 2700) > > > > return -EINVAL; > > > > > > > > + /* Optional gpio don't fail if not present */ > > > > + ov2659->pwdn_gpio = devm_gpiod_get_optional(&client->dev, > > > > "powerdown", > > > > + GPIOD_OUT_LOW); > > > > + if (IS_ERR(ov2659->pwdn_gpio)) > > > > + return PTR_ERR(ov2659->pwdn_gpio); > > > > + > > > > + /* Optional gpio don't fail if not present */ > > > > + ov2659->resetb_gpio = devm_gpiod_get_optional(&client->dev, > > > > "reset", > > > > + GPIOD_OUT_HIGH); > > > > + if (IS_ERR(ov2659->resetb_gpio)) > > > > + return PTR_ERR(ov2659->resetb_gpio); > > > > + > > > > v4l2_ctrl_handler_init(&ov2659->ctrls, 2); > > > > ov2659->link_frequency = > > > > v4l2_ctrl_new_std(&ov2659->ctrls, > > > > &ov2659_ctrl_ops, > > > > @@ -1445,6 +1497,9 @@ static int ov2659_probe(struct i2c_client *client) > > > > ov2659->frame_size = &ov2659_framesizes[2]; > > > > ov2659->format_ctrl_regs = ov2659_formats[0].format_ctrl_regs; > > > > > > > > + pm_runtime_enable(&client->dev); > > > > + pm_runtime_get_sync(&client->dev); > > > > > > This makes the driver depend on runtime PM. > > > > Obviously. > > Why? Is that bad? > > Well, if it is, then it should be listed in driver's dependencies in > Kconfig. And I see that most camera driver using pm_runtime calls don't mark it as a dependency in their own Kconfig. There is actually only one that does. > > > > > > > > > See e.g. the smiapp driver for an example how to make it work without. It > > > wasn't trivial. :I You won't need autosuspend. > > > > I took a look at that driver, but I don't get your reference to being able > > to work without runtime pm! > > The driver didn't need runtime PM, so it'd be nice to continue work > without. Ok. > > What smiapp does is that it powers the sensor on first *without* runtime > PM, and then proceeds to set up runtime PM if it's available. The sensor > will only be powered off when the device is unbound with runtime PM > disabled. In that case in your original reply you suggested that I move the content of ov2659_set_power() into the pm_runtime callback, but based on this comments then I should keep ov2659_set_power() as is as I would need to use it for this specific purpose. > > Regarding the smiapp driver, you can replace pm_runtime_get_noresume() and > all the autoidle lines with pm_runtime_idle() call after > pm_runtime_enable() in the ov2659 driver. Ok, I'll study this mechanics a little more, as this is not immediately clear. Benoit > > > That driver looks pretty similar to ov7740.c which I used as a reference > > for this. > > I guess in practice many sensor drivers don't work without it on DT-based > systems I'm afraid. :-( They should be fixed. > > -- > Kind regards, > > Sakari Ailus > sakari.ai...@linux.intel.com
Re: [PATCH 5/5] arm64: dts: imx8mq: add DCSS node
Am Montag, den 23.09.2019, 13:12 -0300 schrieb Fabio Estevam:
> Hi Laurentiu,
>
> On Mon, Sep 23, 2019 at 11:14 AM Laurentiu Palcu
> wrote:
>
> > +
> > + dcss: dcss@0x32e0 {
>
> Node names should be generic, so:
>
> dcss: display-controller@32e0
>
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + compatible = "nxp,imx8mq-dcss";
> > + reg = <0x32e0 0x2D000>,
> > <0x32e2f000 0x1000>;
>
> 0x2d000 for consistency.
>
> > + interrupts = <6>, <8>, <9>;
>
> The interrupts are passed in the
> format.
No, they are not. Those are imx-irqsteer IRQs, this controller has 0
irq cells, so the description in this patch is correct.
Regards,
Lucas
Re: [PATCH RT v3 3/5] sched: migrate_dis/enable: Use rt_invol_sleep
On Tue, 2019-09-17 at 09:06 -0500, Scott Wood wrote: > On Tue, 2019-09-17 at 09:59 +0200, Sebastian Andrzej Siewior wrote: > > On 2019-09-11 17:57:27 [+0100], Scott Wood wrote: > > > diff --git a/kernel/cpu.c b/kernel/cpu.c > > > index 885a195dfbe0..32c6175b63b6 100644 > > > --- a/kernel/cpu.c > > > +++ b/kernel/cpu.c > > > @@ -308,7 +308,9 @@ void pin_current_cpu(void) > > > preempt_lazy_enable(); > > > preempt_enable(); > > > > > > + rt_invol_sleep_inc(); > > > __read_rt_lock(cpuhp_pin); > > > + rt_invol_sleep_dec(); > > > > > > preempt_disable(); > > > preempt_lazy_disable(); > > > > I understand the other one. But now looking at it, both end up in > > rt_spin_lock_slowlock_locked() which would be the proper place to do > > that annotation. Okay. > > FWIW, if my lazy migrate patchset is accepted, then there will be no users > of __read_rt_lock() outside rwlock-rt.c and it'll be moot. I missed the "both" -- which is the "other one" that ends up in rt_spin_lock_slowlock_locked()? stop_one_cpu() doesn't... -Scott
Re: [PATCH v2 3/9] csky: entry: Remove unneeded need_resched() loop
Ok, I'll put in my tree :) On Mon, Sep 23, 2019 at 10:36 PM Valentin Schneider wrote: > > Since the enabling and disabling of IRQs within preempt_schedule_irq() > is contained in a need_resched() loop, we don't need the outer arch > code loop. > > Acked-by: Guo Ren > Signed-off-by: Valentin Schneider > --- > arch/csky/kernel/entry.S | 4 > 1 file changed, 4 deletions(-) > > diff --git a/arch/csky/kernel/entry.S b/arch/csky/kernel/entry.S > index a7e84bd8..679afbcc2001 100644 > --- a/arch/csky/kernel/entry.S > +++ b/arch/csky/kernel/entry.S > @@ -292,11 +292,7 @@ ENTRY(csky_irq) > ldw r8, (r9, TINFO_FLAGS) > btsti r8, TIF_NEED_RESCHED > bf 2f > -1: > jbsrpreempt_schedule_irq/* irq en/disable is done inside */ > - ldw r7, (r9, TINFO_FLAGS) /* get new tasks TI_FLAGS */ > - btsti r7, TIF_NEED_RESCHED > - bt 1b /* go again */ > #endif > 2: > jmpiret_from_exception > -- > 2.22.0 > -- Best Regards Guo Ren ML: https://lore.kernel.org/linux-csky/
Re: [PATCH 5/5] arm64: dts: imx8mq: add DCSS node
Quoting Laurentiu Palcu (2019-09-23 07:13:19)
> diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> index 52aae34..d4aa778 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> @@ -871,6 +871,31 @@
> interrupt-controller;
> #interrupt-cells = <1>;
> };
> +
> + dcss: dcss@0x32e0 {
Drop the 0x prefix on node names.
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "nxp,imx8mq-dcss";
> + reg = <0x32e0 0x2D000>, <0x32e2f000
> 0x1000>;
> + interrupts = <6>, <8>, <9>;
> + interrupt-names = "ctx_ld", "ctxld_kick",
> "vblank";
> + interrupt-parent = <&irqsteer>;
> + clocks = <&clk IMX8MQ_CLK_DISP_APB_ROOT>,
> +<&clk IMX8MQ_CLK_DISP_AXI_ROOT>,
> +<&clk IMX8MQ_CLK_DISP_RTRM_ROOT>,
> +<&clk IMX8MQ_VIDEO2_PLL_OUT>,
> +<&clk IMX8MQ_CLK_DISP_DTRC>;
> + clock-names = "apb", "axi", "rtrm", "pix",
> "dtrc";
> + assigned-clocks = <&clk IMX8MQ_CLK_DISP_AXI>,
> + <&clk IMX8MQ_CLK_DISP_RTRM>,
> + <&clk
> IMX8MQ_VIDEO2_PLL1_REF_SEL>;
> + assigned-clock-parents = <&clk
> IMX8MQ_SYS1_PLL_800M>,
> +<&clk
> IMX8MQ_SYS1_PLL_800M>,
> +<&clk
> IMX8MQ_CLK_27M>;
> + assigned-clock-rates = <8>,
> + <4>;
> + status = "disabled";
> + };
Re: [PATCH 15/17] KVM: retpolines: x86: eliminate retpoline from vmx.c exit handlers
On 23/09/19 18:37, Sean Christopherson wrote: >> Would it be too much if we get rid of >> kvm_vmx_exit_handlers completely replacing this code with one switch()? > Hmm, that'd require redirects for nVMX functions since they are set at > runtime. That isn't necessarily a bad thing. The approach could also be > used if Paolo's idea of making kvm_vmx_max_exit_handlers const allows the > compiler to avoid retpoline. But aren't switch statements also retpolin-ized if they use a jump table? Paolo
Re: [PATCH 02/17] KVM: monolithic: x86: convert the kvm_x86_ops methods to external functions
On 23/09/19 18:13, Sean Christopherson wrote:
> Alternatively, what if we use macros in the call sites, e.g. keep/require
> vmx_ and svm_ prefixes for all functions, renaming VMX and SVM code as
> needed? E.g.:
>
>
> #define X86_OP(name) kvm_x86_vendor##_##name
>
> int kvm_arch_init(void *opaque)
> {
> if (X86_OP(supported_by_cpu())) {
Please no, the extra parentheses would be a mess to review.
Paolo
Re: [PATCH v2 1/5] perf cs-etm: Refactor instruction size handling
Hi Leo,
On 23/09/2019 17:07, Leo Yan wrote:
In cs-etm.c there have several functions need to know instruction size
based on address, e.g. cs_etm__instr_addr() and cs_etm__copy_insn()
these two functions both calculate the instruction size separately.
Furthermore, if we consider to add new features later which also might
require to calculate instruction size.
For this reason, this patch refactors the code to introduce a new
function cs_etm__instr_size(), it will be a central place to calculate
the instruction size based on ISA type and instruction address.
For a neat implementation, cs_etm__instr_addr() will always execute the
loop without checking ISA type, this allows cs_etm__instr_size() and
cs_etm__instr_addr() have no any duplicate code with each other and both
functions can be changed independently later without breaking anything.
As a side effect, cs_etm__instr_addr() will do a few more iterations for
A32/A64 instructions, this would be fine if consider perf tool runs in
the user space.
Signed-off-by: Leo Yan
Your changes look fine to me. However, please see my comment below.
---
tools/perf/util/cs-etm.c | 48 +++-
1 file changed, 28 insertions(+), 20 deletions(-)
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index f87b9c1c9f9a..1de3f9361193 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -917,6 +917,26 @@ static inline int cs_etm__t32_instr_size(struct
cs_etm_queue *etmq,
return ((instrBytes[1] & 0xF8) >= 0xE8) ? 4 : 2;
}
+static inline int cs_etm__instr_size(struct cs_etm_queue *etmq,
+u8 trace_chan_id,
+enum cs_etm_isa isa,
+u64 addr)
+{
+ int insn_len;
+
+ /*
+* T32 instruction size might be 32-bit or 16-bit, decide by calling
+* cs_etm__t32_instr_size().
+*/
+ if (isa == CS_ETM_ISA_T32)
+ insn_len = cs_etm__t32_instr_size(etmq, trace_chan_id, addr);
+ /* Otherwise, A64 and A32 instruction size are always 32-bit. */
+ else
+ insn_len = 4;
+
+ return insn_len;
+}
+
static inline u64 cs_etm__first_executed_instr(struct cs_etm_packet *packet)
{
/* Returns 0 for the CS_ETM_DISCONTINUITY packet */
@@ -941,19 +961,15 @@ static inline u64 cs_etm__instr_addr(struct cs_etm_queue
*etmq,
const struct cs_etm_packet *packet,
u64 offset)
{
- if (packet->isa == CS_ETM_ISA_T32) {
- u64 addr = packet->start_addr;
+ u64 addr = packet->start_addr;
- while (offset > 0) {
- addr += cs_etm__t32_instr_size(etmq,
- trace_chan_id, addr);
- offset--;
- }
- return addr;
+ while (offset > 0) {
Given that offset is u64, the check above is not appropriate. You could either
change it to :
while (offset) // if you are sure (s64)offset always is a postive
integer and we always reduce it by 1.
Otherwise you may switch the offset to a signed type. I understand that this
is not introduced by your changes. But you may fix that up in a separate patch.
Kind regards
Suzuki
[PATCH] Input: atmel_mxt_ts - Disable IRQ across suspend
Across suspend and resume, we are seeing error messages like the following:
atmel_mxt_ts i2c-PRP0001:00: __mxt_read_reg: i2c transfer failed (-121)
atmel_mxt_ts i2c-PRP0001:00: Failed to read T44 and T5 (-121)
This occurs because the driver leaves its IRQ enabled. Upon resume, there
is an IRQ pending, but the interrupt is serviced before both the driver and
the underlying I2C bus have been resumed. This causes EREMOTEIO errors.
Disable the IRQ in suspend, and re-enable it if it was previously enabled
in resume.
Signed-off-by: Evan Green
---
drivers/input/touchscreen/atmel_mxt_ts.c | 33 +++-
1 file changed, 27 insertions(+), 6 deletions(-)
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c
b/drivers/input/touchscreen/atmel_mxt_ts.c
index 24c4b691b1c9..19cbcd9767e2 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -291,6 +291,7 @@ struct mxt_data {
u8 xsize;
u8 ysize;
bool in_bootloader;
+ bool irq_enabled;
u16 mem_size;
u8 t100_aux_ampl;
u8 t100_aux_area;
@@ -1185,11 +1186,23 @@ static int mxt_t6_command(struct mxt_data *data, u16
cmd_offset,
return 0;
}
+static void mxt_enable_irq(struct mxt_data *data)
+{
+ enable_irq(data->irq);
+ data->irq_enabled = true;
+}
+
+static void mxt_disable_irq(struct mxt_data *data)
+{
+ disable_irq(data->irq);
+ data->irq_enabled = false;
+}
+
static int mxt_acquire_irq(struct mxt_data *data)
{
int error;
- enable_irq(data->irq);
+ mxt_enable_irq(data);
error = mxt_process_messages_until_invalid(data);
if (error)
@@ -1205,7 +1218,7 @@ static int mxt_soft_reset(struct mxt_data *data)
dev_info(dev, "Resetting device\n");
- disable_irq(data->irq);
+ mxt_disable_irq(data);
reinit_completion(&data->reset_completion);
@@ -2807,7 +2820,7 @@ static int mxt_load_fw(struct device *dev, const char *fn)
mxt_free_input_device(data);
mxt_free_object_table(data);
} else {
- enable_irq(data->irq);
+ mxt_enable_irq(data);
}
reinit_completion(&data->bl_completion);
@@ -2882,7 +2895,7 @@ static int mxt_load_fw(struct device *dev, const char *fn)
data->in_bootloader = false;
disable_irq:
- disable_irq(data->irq);
+ mxt_disable_irq(data);
release_firmware:
release_firmware(fw);
return ret;
@@ -3101,7 +3114,7 @@ static int mxt_probe(struct i2c_client *client, const
struct i2c_device_id *id)
return error;
}
- disable_irq(client->irq);
+ mxt_disable_irq(data);
if (data->reset_gpio) {
msleep(MXT_RESET_GPIO_TIME);
@@ -3132,7 +3145,7 @@ static int mxt_remove(struct i2c_client *client)
{
struct mxt_data *data = i2c_get_clientdata(client);
- disable_irq(data->irq);
+ mxt_disable_irq(data);
sysfs_remove_group(&client->dev.kobj, &mxt_attr_group);
mxt_free_input_device(data);
mxt_free_object_table(data);
@@ -3156,6 +3169,11 @@ static int __maybe_unused mxt_suspend(struct device *dev)
mutex_unlock(&input_dev->mutex);
+ /*
+* Disable the IRQ directly since the boolean will be used to restore
+* the IRQ state on resume.
+*/
+ disable_irq(data->irq);
return 0;
}
@@ -3168,6 +3186,9 @@ static int __maybe_unused mxt_resume(struct device *dev)
if (!input_dev)
return 0;
+ if (data->irq_enabled)
+ enable_irq(data->irq);
+
mutex_lock(&input_dev->mutex);
if (input_dev->users)
--
2.21.0
Re: [PATCH v6 2/2] EDAC: add EDAC driver for DMC520
On Thu, Sep 19, 2019 at 06:37:18PM +, Lei Wang wrote:
> New driver supports error detection and correction on the devices with ARM
> DMC-520 memory controller.
>
> Signed-off-by: Lei Wang
> Reviewed-by: James Morse
> ---
> Changes in v6:
> - Refactored dmc520_edac_probe to move most hw initialization before
> edac_mc_alloc.
> - Fixed patch format.
> - Addressed several other misc comments from Borislav Petkov.
> ---
> MAINTAINERS| 6 +
> drivers/edac/Kconfig | 7 +
> drivers/edac/Makefile | 1 +
> drivers/edac/dmc520_edac.c | 661 +
> 4 files changed, 675 insertions(+)
> create mode 100644 drivers/edac/dmc520_edac.c
...
> +/* Get the memory data bus width, in number of bytes. */
With the return variable properly named, that comment is useless. You're
returning a "mem_width_in_bytes" - can't be clearer than that.
In any case, I took your patch and did some cleanups ontop:
- align function args on opening braces
- shorten too long member names
- do not break long strings
- why do the loops use the pre-increment "++intr_index" instead of the
usual post-increment "intr_index++"?
Please have a look, integrate them in your patch and redo it ontop of
the edac-for-next branch here:
https://git.kernel.org/pub/scm/linux/kernel/git/ras/ras.git/log/?h=edac-for-next
but *after* the merge window is over and once that branch has been
updated to 4.5-rc1.
Thx.
---
diff --git a/drivers/edac/dmc520_edac.c b/drivers/edac/dmc520_edac.c
index 41c41efaaaf2..ab1ab19890d3 100644
--- a/drivers/edac/dmc520_edac.c
+++ b/drivers/edac/dmc520_edac.c
@@ -110,16 +110,15 @@ struct ecc_error_info {
struct dmc520_edac {
void __iomem *reg_base;
u32 nintr;
- u32 interrupt_mask_all;
+ u32 irq_mask_all;
spinlock_t ecc_lock;
- u32 interrupt_masks[0];
+ u32 irq_masks[0];
};
static int dmc520_mc_idx;
static irqreturn_t
-dmc520_edac_dram_all_isr(
- int irq, struct mem_ctl_info *mci, u32 interrupt_mask);
+dmc520_edac_dram_all_isr(int irq, struct mem_ctl_info *mci, u32
interrupt_mask);
#define DECLARE_ISR(index) \
static irqreturn_t dmc520_isr_##index(int irq, void *data) \
@@ -128,8 +127,7 @@ static irqreturn_t dmc520_isr_##index(int irq, void *data) \
struct dmc520_edac *edac; \
mci = data; \
edac = mci->pvt_info; \
- return dmc520_edac_dram_all_isr( \
- irq, mci, edac->interrupt_masks[index]); \
+ return dmc520_edac_dram_all_isr(irq, mci, edac->irq_masks[index]); \
}
DECLARE_ISR(0)
@@ -235,7 +233,7 @@ static enum scrub_type dmc520_get_scrub_type(struct
dmc520_edac *edac)
scrub_cfg = FIELD_GET(SCRUB_TRIGGER0_NEXT_MASK, reg_val);
if (scrub_cfg == DMC520_SCRUB_TRIGGER_ERR_DETECT ||
- scrub_cfg == DMC520_SCRUB_TRIGGER_IDLE)
+ scrub_cfg == DMC520_SCRUB_TRIGGER_IDLE)
type = SCRUB_HW_PROG;
return type;
@@ -347,7 +345,6 @@ static void dmc520_handle_dram_ecc_errors(struct
mem_ctl_info *mci,
dmc520_get_dram_ecc_error_info(edac, is_ce, &info);
cnt = dmc520_get_dram_ecc_error_count(edac, is_ce);
-
if (!cnt)
return;
@@ -364,8 +361,8 @@ static void dmc520_handle_dram_ecc_errors(struct
mem_ctl_info *mci,
spin_unlock(&edac->ecc_lock);
}
-static irqreturn_t dmc520_edac_dram_ecc_isr(
- int irq, struct mem_ctl_info *mci, bool is_ce)
+static irqreturn_t dmc520_edac_dram_ecc_isr(int irq, struct mem_ctl_info *mci,
+ bool is_ce)
{
struct dmc520_edac *edac;
u32 i_mask;
@@ -381,8 +378,8 @@ static irqreturn_t dmc520_edac_dram_ecc_isr(
return IRQ_HANDLED;
}
-static irqreturn_t dmc520_edac_dram_all_isr(
- int irq, struct mem_ctl_info *mci, u32 interrupt_mask)
+static irqreturn_t dmc520_edac_dram_all_isr(int irq, struct mem_ctl_info *mci,
+ u32 interrupt_mask)
{
irqreturn_t irq_ret = IRQ_NONE;
struct dmc520_edac *edac;
@@ -435,8 +432,8 @@ static void dmc520_init_csrow(struct mem_ctl_info *mci)
static int dmc520_edac_probe(struct platform_device *pdev)
{
- int ret, intr_index, nintr, nintr_registered = 0;
- struct dmc520_edac *edac, *edac_local;
+ int ret, idx, nintr, nintr_registered = 0;
+ struct dmc520_edac *edac, edac_local;
struct mem_ctl_info *mci = NULL;
struct edac_mc_layer layers[1];
void __iomem *reg_base;
@@ -444,22 +441,20 @@ static int dmc520_edac_probe(struct platform_device *pdev)
struct resource *res;
struct device *dev;
- /* Parsing the device node */
+ /* Parse the device node */
dev = &pdev->dev;
nintr = of_property_count_u32_elems(dev->of_node, "interrupt-config");
if (nintr <= 0) {
edac_printk(KERN_ERR, EDAC_MOD_NAME,
-
Re: [PATCH 2/3] KVM: x86: hyper-v: set NoNonArchitecturalCoreSharing CPUID bit when SMT is impossible
On 23/09/19 17:37, Peter Zijlstra wrote: >> This patch reports NoNonArchitecturalCoreSharing bit in to userspace in the >> first case. The second case is outside of KVM's domain of responsibility >> (as vCPU pinning is actually done by someone who manages KVM's userspace - >> e.g. libvirt pinning QEMU threads). > This is purely about guest<->guest MDS, right? Ie. not worse than actual > hardware. Even within the same guest. If vCPU 1 is on virtual core 1 and vCPU 2 is on virtual core 2, but they can share the same physical core, core scheduling in the guest can do nothing about it. Paolo
Re: [PATCH AUTOSEL 5.2 072/185] ALSA: hda: Add codec on bus address table lately
On Mon, Sep 23, 2019 at 03:40:45PM +0200, Takashi Iwai wrote: On Mon, 23 Sep 2019 15:30:25 +0200, Sasha Levin wrote: On Sun, Sep 22, 2019 at 09:06:12PM +0200, Takashi Iwai wrote: >On Sun, 22 Sep 2019 20:47:30 +0200, >Sasha Levin wrote: >> >> From: Takashi Iwai >> >> [ Upstream commit ee5f85d9290fe25d460bd320b7fe073075d72d33 ] >> >> The call of snd_hdac_bus_add_device() is needed only for registering >> the codec onto the bus caddr_tbl[] that is referred essentially only >> in the unsol event handler. That is, the reason of this call and the >> release by the counter-part function snd_hdac_bus_remove_device() is >> just to assure that the unsol event gets notified to the codec. >> >> But the current implementation of the unsol notification wouldn't work >> properly when the codec is still in a premature init state. So this >> patch tries to work around it by delaying the caddr_tbl[] registration >> at the point of snd_hdac_device_register(). >> >> Also, the order of snd_hdac_bus_remove_device() and device_del() calls >> are shuffled to make sure that the unsol event is masked before >> deleting the device. >> >> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204565 >> Signed-off-by: Takashi Iwai >> Signed-off-by: Sasha Levin > >The upstream commit was reverted later by 246bb4aaa4f4, which has even >Fixes tag pointing this. So please drop this. I'll drop it, thank you. >BTW, this is the second time AUTOSEL overlooked the existing revert. >I'm afraid something is missing in the check. Usually it's the case that I check for fixes/reverts once I compile the series, and again right before I queue it up to a stable tree. In between fixes and reverts tend to sneak in just like in this case. In general, I also check the -rcs for fixes and reverts during their review window, so while sometimes we send out mails with patches that have a fix or revert upstream, they rarely make it into a released stable kernel. IMO, it'd be great if you have some check before sending for reviews. The Fixes tag chain can be parsed relatively easily, after all. True. I'll update my scripts to do that. -- Thanks, Sasha
Re: Problems with arm64 compat vdso
On Fri, 20 Sep 2019 at 18:33, Vincenzo Frascino wrote: > > Hi Will, > > thank you for reporting this. > > On 20/09/2019 15:27, Will Deacon wrote: > > Hi Vincenzo, > > > > I've been running into a few issues with the COMPAT vDSO. Please could > > you have a look? > > > > I will be at Linux Recipes next week. I will look at this with priority when I > come back. > Hi all, I noticed another issue: I build out of tree, and the VDSO gets rebuilt every time I build the kernel, even if I haven't made any changes to the source tree at all. Could you please look into that as well? (once you get around to it) Thanks, Ard. > > If I do the following: > > > > $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- defconfig > > [...] > > $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- menuconfig > > [set CONFIG_CROSS_COMPILE_COMPAT_VDSO="arm-linux-gnueabihf-"] > > $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- > > > > Then I see the following warning: > > > > arch/arm64/Makefile:62: CROSS_COMPILE_COMPAT not defined or empty, the > > compat vDSO will not be built > > > > even though the compat vDSO *has* been built: > > > > $ file arch/arm64/kernel/vdso32/vdso.so > > arch/arm64/kernel/vdso32/vdso.so: ELF 32-bit LSB pie executable, ARM, EABI5 > > version 1 (SYSV), dynamically linked, > > BuildID[sha1]=c67f6c786f2d2d6f86c71f708595594aa25247f6, stripped > > > > However, I also get some warnings because arm64 headers are being included > > in the compat vDSO build: > > > > In file included from ./arch/arm64/include/asm/thread_info.h:17:0, > > from ./include/linux/thread_info.h:38, > > from ./arch/arm64/include/asm/preempt.h:5, > > from ./include/linux/preempt.h:78, > > from ./include/linux/spinlock.h:51, > > from ./include/linux/seqlock.h:36, > > from ./include/linux/time.h:6, > > from > > /usr/local/google/home/willdeacon/work/linux/lib/vdso/gettimeofday.c:7, > > from :0: > > ./arch/arm64/include/asm/memory.h: In function ‘__tag_set’: > > ./arch/arm64/include/asm/memory.h:233:15: warning: cast from pointer to > > integer of different size [-Wpointer-to-int-cast] > > u64 __addr = (u64)addr & ~__tag_shifted(0xff); > >^ > > In file included from ./arch/arm64/include/asm/pgtable-hwdef.h:8:0, > > from ./arch/arm64/include/asm/processor.h:34, > > from ./arch/arm64/include/asm/elf.h:118, > > from ./include/linux/elf.h:5, > > from ./include/linux/elfnote.h:62, > > from arch/arm64/kernel/vdso32/note.c:11: > > ./arch/arm64/include/asm/memory.h: In function ‘__tag_set’: > > ./arch/arm64/include/asm/memory.h:233:15: warning: cast from pointer to > > integer of different size [-Wpointer-to-int-cast] > > u64 __addr = (u64)addr & ~__tag_shifted(0xff); > >^ > > Worse, if your compat binutils isn't up-to-date, you'll actually run into > > a build failure: > > > > /tmp/ccFCrjUg.s:80: Error: invalid barrier type -- `dmb ishld' > > /tmp/ccFCrjUg.s:124: Error: invalid barrier type -- `dmb ishld' > > > > There also appears to be a problem getting the toolchain prefix from > > Kconfig. > > If, for example, I do: > > > > $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- defconfig > > [...] > > $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- menuconfig > > [set CONFIG_CROSS_COMPILE_COMPAT_VDSO="vincenzo"] > > $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- > > arch/arm64/Makefile:64: *** vincenzogcc not found, check > > CROSS_COMPILE_COMPAT. Stop. > > $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- menuconfig > > [set CONFIG_CROSS_COMPILE_COMPAT_VDSO="arm-linux-gnueabihf-"] > > $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- > > arch/arm64/Makefile:64: *** vincenzogcc not found, check > > CROSS_COMPILE_COMPAT. Stop. > > $ grep CONFIG_CROSS_COMPILE_COMPAT_VDSO .config > > CONFIG_CROSS_COMPILE_COMPAT_VDSO="arm-linux-gnueabihf-" > > > > which is irritating, because it seems to force a 'mrproper' if you don't > > get the prefix right first time. > > > > Cheers, > > > > Will > > > > -- > Regards, > Vincenzo
Re: [PATCH RT v3 1/5] rcu: Acquire RCU lock when disabling BHs
On 2019-09-17 11:12:48 [-0500], Scott Wood wrote: > > rcu_read_lock() does: > > > __rcu_read_lock(); > > > __acquire(RCU); > > > rcu_lock_acquire(&rcu_lock_map); > > > RCU_LOCKDEP_WARN(!rcu_is_watching(), > > > "rcu_read_lock() used illegally while idle"); > > > > __acquire() is removed removed by cpp. > > That RCU_LOCKDEP_WARN is doing the same thing as above and redundant. > > Am I right to assume that you consider > > rcu_lock_acquire(&rcu_bh_lock_map); > > > > redundant because the only user of that is also checking for > > rcu_lock_map? > Yes. I'm going to drop that hunk. It makes the patch smaller and result more obvious. If the additional lock annotation (rcu_bh_lock_map) is too much then we can still remove it later entirely (for RT) but for now I would like to keep the changes simple and small. > -Scott Sebastian
Re: [PATCH v10 3/6] mm: Introduce Reported pages
On Mon, Sep 23, 2019 at 8:46 AM David Hildenbrand wrote:
>
> On 23.09.19 17:37, Michael S. Tsirkin wrote:
> > On Mon, Sep 23, 2019 at 08:28:00AM -0700, Alexander Duyck wrote:
> >> On Mon, Sep 23, 2019 at 8:00 AM Michael S. Tsirkin wrote:
> >>>
> >>> On Mon, Sep 23, 2019 at 07:50:15AM -0700, Alexander Duyck wrote:
> >> +static inline void
> >> +page_reporting_reset_boundary(struct zone *zone, unsigned int order,
> >> int mt)
> >> +{
> >> + int index;
> >> +
> >> + if (order < PAGE_REPORTING_MIN_ORDER)
> >> + return;
> >> + if (!test_bit(ZONE_PAGE_REPORTING_ACTIVE, &zone->flags))
> >> + return;
> >> +
> >> + index = get_reporting_index(order, mt);
> >> + reported_boundary[index] = &zone->free_area[order].free_list[mt];
> >> +}
> >
> > So this seems to be costly.
> > I'm guessing it's the access to flags:
> >
> >
> > /* zone flags, see below */
> > unsigned long flags;
> >
> > /* Primarily protects free_area */
> > spinlock_t lock;
> >
> >
> >
> > which is in the same cache line as the lock.
>
> I'm not sure what you mean by this being costly?
> >>>
> >>> I've just been wondering why does will it scale report a 1.5% regression
> >>> with this patch.
> >>
> >> Are you talking about data you have collected from a test you have
> >> run, or the data I have run?
> >
> > About the kernel test robot auto report that was sent recently.
>
> https://lkml.org/lkml/2019/9/21/112
>
> And if I'm correct, that regression is observable in case reporting is
> not enabled. (so with this patch applied only, e.g., on a bare-metal system)
Thanks. For whatever reason it looks like my gmail decided to pop it
out of the thread so I hadn't seen it yet this morning.
I'll have to look into it. It doesn't make much sense to me why this
would have this much impact since especially in the disabled case the
changes should be quite small.
- Alex
Re: [PATCH V2 1/2] usb: dwc3: Add node to update cache type setting
On Thu, Jul 25, 2019 at 4:56 PM Rob Herring wrote: > > On Wed, Jul 24, 2019 at 8:29 PM Ran Wang wrote: > > > > Hi Rob, > > > > On Thursday, July 25, 2019 04:42 Rob Herring wrote: > > > > > > On Fri, Jul 12, 2019 at 02:42:05PM +0800, Ran Wang wrote: > > > > Some Layerscape paltforms (such as LS1088A, LS2088A, etc) encounter > > > > USB detect failues when adding dma-coherent to DWC3 node. This is > > > > because the HW default cache type configuration of those SoC are not > > > > right, need to be updated in DTS. > > > > > > > > Signed-off-by: Ran Wang > > > > --- > > > > Change in v2: > > > > - New file. > > > > > > > > Documentation/devicetree/bindings/usb/dwc3.txt | 43 > > > > ++ > > > > 1 file changed, 43 insertions(+) > > > > > > > > diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt > > > > b/Documentation/devicetree/bindings/usb/dwc3.txt > > > > index 8e5265e..7bc1cef 100644 > > > > --- a/Documentation/devicetree/bindings/usb/dwc3.txt > > > > +++ b/Documentation/devicetree/bindings/usb/dwc3.txt > > > > @@ -110,6 +110,43 @@ Optional properties: > > > > - in addition all properties from usb-xhci.txt from the current > > > > directory are > > > > supported as well > > > > > > > > +* Cache type nodes (optional) > > > > + > > > > +The Cache type node is used to tell how to configure cache type on 4 > > > > +different transfer types: Data Read, Desc Read, Data Write and Desc > > > > +write. For each treasfer type, controller has a 4-bit register field > > > > +to enable different cache type. Quoted from DWC3 data book Table 6-5 > > > Cache Type Bit Assignments: > > > > + > > > > +MBUS_TYPE| bit[3] |bit[2] |bit[1] |bit[0] > > > > + > > > > +AHB |Cacheable |Bufferable |Privilegge |Data > > > > +AXI3 |Write Allocate|Read Allocate|Cacheable |Bufferable > > > > +AXI4 |Allocate Other|Allocate |Modifiable |Bufferable > > > > +AXI4 |Other Allocate|Allocate |Modifiable |Bufferable > > > > +Native |Same as AXI |Same as AXI |Same as AXI|Same as AXI > > > > + > > > > +Note: The AHB, AXI3, AXI4, and PCIe busses use different names for > > > > +certain signals, which have the same meaning: > > > > + Bufferable = Posted > > > > + Cacheable = Modifiable = Snoop (negation of No Snoop) > > > > > > This should all be implied from the SoC specific compatible strings. > > > > Did you mean I could implement a soc driver which can be matched by > > compatible of 'fsl,ls1088a-dwc3' which will pass known bus type to DWC3 > > driver? If yes, how to pass? > > Yes. The DT match table can have data associated with that compatible > string. Beyond that, I'm not really familiar with the DWC3 driver. Hi Rob, It looks like that the current dwc3 binding perfers to define general quirks in device tree properties instead of trying to rely on the compatible string to determine quirks. In this case, can we keep following the existing preference instead of choosing the other way? Regards, Leo
Re: [PATCH 15/17] KVM: retpolines: x86: eliminate retpoline from vmx.c exit handlers
On Mon, Sep 23, 2019 at 11:31:58AM +0200, Vitaly Kuznetsov wrote:
> Andrea Arcangeli writes:
>
> > It's enough to check the exit value and issue a direct call to avoid
> > the retpoline for all the common vmexit reasons.
> >
> > Signed-off-by: Andrea Arcangeli
> > ---
> > arch/x86/kvm/vmx/vmx.c | 24 ++--
> > 1 file changed, 22 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> > index a6e597025011..9aa73e216df2 100644
> > --- a/arch/x86/kvm/vmx/vmx.c
> > +++ b/arch/x86/kvm/vmx/vmx.c
> > @@ -5866,9 +5866,29 @@ static int vmx_handle_exit(struct kvm_vcpu *vcpu)
> > }
> >
> > if (exit_reason < kvm_vmx_max_exit_handlers
> > - && kvm_vmx_exit_handlers[exit_reason])
> > + && kvm_vmx_exit_handlers[exit_reason]) {
> > +#ifdef CONFIG_RETPOLINE
> > + if (exit_reason == EXIT_REASON_MSR_WRITE)
> > + return handle_wrmsr(vcpu);
> > + else if (exit_reason == EXIT_REASON_PREEMPTION_TIMER)
> > + return handle_preemption_timer(vcpu);
> > + else if (exit_reason == EXIT_REASON_PENDING_INTERRUPT)
> > + return handle_interrupt_window(vcpu);
> > + else if (exit_reason == EXIT_REASON_EXTERNAL_INTERRUPT)
> > + return handle_external_interrupt(vcpu);
> > + else if (exit_reason == EXIT_REASON_HLT)
> > + return handle_halt(vcpu);
> > + else if (exit_reason == EXIT_REASON_PAUSE_INSTRUCTION)
> > + return handle_pause(vcpu);
> > + else if (exit_reason == EXIT_REASON_MSR_READ)
> > + return handle_rdmsr(vcpu);
> > + else if (exit_reason == EXIT_REASON_CPUID)
> > + return handle_cpuid(vcpu);
> > + else if (exit_reason == EXIT_REASON_EPT_MISCONFIG)
> > + return handle_ept_misconfig(vcpu);
> > +#endif
> > return kvm_vmx_exit_handlers[exit_reason](vcpu);
>
> I agree with the identified set of most common vmexits, however, this
> still looks a bit random. Would it be too much if we get rid of
> kvm_vmx_exit_handlers completely replacing this code with one switch()?
Hmm, that'd require redirects for nVMX functions since they are set at
runtime. That isn't necessarily a bad thing. The approach could also be
used if Paolo's idea of making kvm_vmx_max_exit_handlers const allows the
compiler to avoid retpoline.
E.g.:
static int handle_vmx_instruction(struct kvm_vcpu *vcpu)
{
if (nested)
return nested_vmx_handle_exit(vcpu);
kvm_queue_exception(vcpu, UD_VECTOR);
return 1;
}
Re: [PATCH net-next] tuntap: Fallback to automq on TUNSETSTEERINGEBPF prog negative return
On Sun, Sep 22, 2019 at 10:16 PM Jason Wang wrote: > > > On 2019/9/23 上午11:18, Matt Cover wrote: > > On Sun, Sep 22, 2019 at 7:34 PM Jason Wang wrote: > >> > >> On 2019/9/23 上午9:15, Matt Cover wrote: > >>> On Sun, Sep 22, 2019 at 5:51 PM Jason Wang wrote: > On 2019/9/23 上午6:30, Matt Cover wrote: > > On Sun, Sep 22, 2019 at 1:36 PM Michael S. Tsirkin > > wrote: > >> On Sun, Sep 22, 2019 at 10:43:19AM -0700, Matt Cover wrote: > >>> On Sun, Sep 22, 2019 at 5:37 AM Michael S. Tsirkin > >>> wrote: > On Fri, Sep 20, 2019 at 11:58:43AM -0700, Matthew Cover wrote: > > Treat a negative return from a TUNSETSTEERINGEBPF bpf prog as a > > signal > > to fallback to tun_automq_select_queue() for tx queue selection. > > > > Compilation of this exact patch was tested. > > > > For functional testing 3 additional printk()s were added. > > > > Functional testing results (on 2 txq tap device): > > > > [Fri Sep 20 18:33:27 2019] == tun no prog == > > [Fri Sep 20 18:33:27 2019] tuntap: tun_ebpf_select_queue() > > returned '-1' > > [Fri Sep 20 18:33:27 2019] tuntap: tun_automq_select_queue() > > ran > > [Fri Sep 20 18:33:27 2019] == tun prog -1 == > > [Fri Sep 20 18:33:27 2019] tuntap: bpf_prog_run_clear_cb() > > returned '-1' > > [Fri Sep 20 18:33:27 2019] tuntap: tun_ebpf_select_queue() > > returned '-1' > > [Fri Sep 20 18:33:27 2019] tuntap: tun_automq_select_queue() > > ran > > [Fri Sep 20 18:33:27 2019] == tun prog 0 == > > [Fri Sep 20 18:33:27 2019] tuntap: bpf_prog_run_clear_cb() > > returned '0' > > [Fri Sep 20 18:33:27 2019] tuntap: tun_ebpf_select_queue() > > returned '0' > > [Fri Sep 20 18:33:27 2019] == tun prog 1 == > > [Fri Sep 20 18:33:27 2019] tuntap: bpf_prog_run_clear_cb() > > returned '1' > > [Fri Sep 20 18:33:27 2019] tuntap: tun_ebpf_select_queue() > > returned '1' > > [Fri Sep 20 18:33:27 2019] == tun prog 2 == > > [Fri Sep 20 18:33:27 2019] tuntap: bpf_prog_run_clear_cb() > > returned '2' > > [Fri Sep 20 18:33:27 2019] tuntap: tun_ebpf_select_queue() > > returned '0' > > > > Signed-off-by: Matthew Cover > Could you add a bit more motivation data here? > >>> Thank you for these questions Michael. > >>> > >>> I'll plan on adding the below information to the > >>> commit message and submitting a v2 of this patch > >>> when net-next reopens. In the meantime, it would > >>> be very helpful to know if these answers address > >>> some of your concerns. > >>> > 1. why is this a good idea > >>> This change allows TUNSETSTEERINGEBPF progs to > >>> do any of the following. > >>> 1. implement queue selection for a subset of > >>>traffic (e.g. special queue selection logic > >>>for ipv4, but return negative and use the > >>>default automq logic for ipv6) > >>> 2. determine there isn't sufficient information > >>>to do proper queue selection; return > >>>negative and use the default automq logic > >>>for the unknown > >>> 3. implement a noop prog (e.g. do > >>>bpf_trace_printk() then return negative and > >>>use the default automq logic for everything) > >>> > 2. how do we know existing userspace does not rely on existing > behaviour > >>> Prior to this change a negative return from a > >>> TUNSETSTEERINGEBPF prog would have been cast > >>> into a u16 and traversed netdev_cap_txqueue(). > >>> > >>> In most cases netdev_cap_txqueue() would have > >>> found this value to exceed real_num_tx_queues > >>> and queue_index would be updated to 0. > >>> > >>> It is possible that a TUNSETSTEERINGEBPF prog > >>> return a negative value which when cast into a > >>> u16 results in a positive queue_index less than > >>> real_num_tx_queues. For example, on x86_64, a > >>> return value of -65535 results in a queue_index > >>> of 1; which is a valid queue for any multiqueue > >>> device. > >>> > >>> It seems unlikely, however as stated above is > >>> unfortunately possible, that existing > >>> TUNSETSTEERINGEBPF programs would choose to > >>> return a negative value rather than return the > >>> positive value which holds the same meaning. > >>> > >>> It seems more likely that future > >>> TUNSETSTEERINGEBPF programs would leverage a > >>> negative return and potentially be loaded into > >>> a kernel with the old behavior.
ntp audit spew.
I have some hosts that are constantly spewing audit messages like so:
[46897.591182] audit: type=1333 audit(1569250288.663:220): op=offset
old=2543677901372 new=2980866217213
[46897.591184] audit: type=1333 audit(1569250288.663:221): op=freq
old=-2443166611284 new=-2436281764244
[48850.604005] audit: type=1333 audit(1569252241.675:222): op=offset
old=1850302393317 new=3190241577926
[48850.604008] audit: type=1333 audit(1569252241.675:223): op=freq
old=-2436281764244 new=-2413071187316
[49926.567270] audit: type=1333 audit(1569253317.638:224): op=offset
old=2453141035832 new=2372389610455
[49926.567273] audit: type=1333 audit(1569253317.638:225): op=freq
old=-2413071187316 new=-2403561671476
This gets emitted every time ntp makes an adjustment, which is apparently very
frequent on some hosts.
Audit isn't even enabled on these machines.
# auditctl -l
No rules
# auditctl -s
enabled 0
failure 1
pid 0
rate_limit 0
backlog_limit 64
lost 0
backlog 0
loginuid_immutable 0 unlocked
Asides from the log spew, why is this code doing _anything_ when audit
isn't enabled ?
Something like this:
diff --git a/kernel/audit.c b/kernel/audit.c
index da8dc0db5bd3..1291d826c024 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -2340,6 +2340,9 @@ void audit_log(struct audit_context *ctx, gfp_t gfp_mask,
int type,
struct audit_buffer *ab;
va_list args;
+ if (audit_initialized != AUDIT_INITIALIZED)
+ return;
+
ab = audit_log_start(ctx, gfp_mask, type);
if (ab) {
va_start(args, fmt);
Might silence the spew, but I'm concerned that the amount of work that
audit is doing on an unconfigured machine might warrant further
investigation.
("turn off CONFIG_AUDIT" isn't an option unfortunately, as this is a
one-size-fits-all kernel that runs on some other hosts that /do/ have
audit configured)
Dave
[PATCH v2] ASoC: Intel: kbl_rt5663_rt5514_max98927: Add dmic format constraint
On KBL platform, the microphone is attached to external codec(rt5514) instead of PCH. However, TDM slot between PCH and codec is 16 bits only. In order to avoid setting wrong format, we should add a constraint to force to use 16 bits format forever. Signed-off-by: Yu-Hsuan Hsu --- I have updated the commit message. Please see whether it is clear enough. Thanks. sound/soc/intel/boards/kbl_rt5663_rt5514_max98927.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/sound/soc/intel/boards/kbl_rt5663_rt5514_max98927.c b/sound/soc/intel/boards/kbl_rt5663_rt5514_max98927.c index 74dda8784f1a01..67b276a65a8d2d 100644 --- a/sound/soc/intel/boards/kbl_rt5663_rt5514_max98927.c +++ b/sound/soc/intel/boards/kbl_rt5663_rt5514_max98927.c @@ -400,6 +400,9 @@ static int kabylake_dmic_startup(struct snd_pcm_substream *substream) snd_pcm_hw_constraint_list(runtime, 0, SNDRV_PCM_HW_PARAM_CHANNELS, dmic_constraints); + runtime->hw.formats = SNDRV_PCM_FMTBIT_S16_LE; + snd_pcm_hw_constraint_msbits(runtime, 0, 16, 16); + return snd_pcm_hw_constraint_list(substream->runtime, 0, SNDRV_PCM_HW_PARAM_RATE, &constraints_rates); } -- 2.23.0.351.gc4317032e6-goog
Re: [PATCH 15/17] KVM: retpolines: x86: eliminate retpoline from vmx.c exit handlers
Subject should be something like:
KVM: VMX: Make direct calls to fast path VM-Exit handlers
On Fri, Sep 20, 2019 at 05:25:07PM -0400, Andrea Arcangeli wrote:
> It's enough to check the exit value and issue a direct call to avoid
> the retpoline for all the common vmexit reasons.
>
> Signed-off-by: Andrea Arcangeli
> ---
> arch/x86/kvm/vmx/vmx.c | 24 ++--
> 1 file changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> index a6e597025011..9aa73e216df2 100644
> --- a/arch/x86/kvm/vmx/vmx.c
> +++ b/arch/x86/kvm/vmx/vmx.c
> @@ -5866,9 +5866,29 @@ static int vmx_handle_exit(struct kvm_vcpu *vcpu)
> }
>
> if (exit_reason < kvm_vmx_max_exit_handlers
> - && kvm_vmx_exit_handlers[exit_reason])
> + && kvm_vmx_exit_handlers[exit_reason]) {
> +#ifdef CONFIG_RETPOLINE
I'd strongly prefer to make any optimization of this type unconditional,
i.e. not dependent on CONFIG_RETPOLINE. Today, I'm comfortable testing
KVM only with CONFIG_RETPOLINE=y since the only KVM-specific difference
is additive code in vmx_vmexit. That would no longer be the case if KVM
has non-trivial code differences for retpoline.
> + if (exit_reason == EXIT_REASON_MSR_WRITE)
> + return handle_wrmsr(vcpu);
> + else if (exit_reason == EXIT_REASON_PREEMPTION_TIMER)
> + return handle_preemption_timer(vcpu);
> + else if (exit_reason == EXIT_REASON_PENDING_INTERRUPT)
> + return handle_interrupt_window(vcpu);
> + else if (exit_reason == EXIT_REASON_EXTERNAL_INTERRUPT)
> + return handle_external_interrupt(vcpu);
> + else if (exit_reason == EXIT_REASON_HLT)
> + return handle_halt(vcpu);
> + else if (exit_reason == EXIT_REASON_PAUSE_INSTRUCTION)
> + return handle_pause(vcpu);
> + else if (exit_reason == EXIT_REASON_MSR_READ)
> + return handle_rdmsr(vcpu);
> + else if (exit_reason == EXIT_REASON_CPUID)
> + return handle_cpuid(vcpu);
> + else if (exit_reason == EXIT_REASON_EPT_MISCONFIG)
> + return handle_ept_misconfig(vcpu);
> +#endif
This can be hoisted above the if statement.
> return kvm_vmx_exit_handlers[exit_reason](vcpu);
> - else {
> + } else {
> vcpu_unimpl(vcpu, "vmx: unexpected exit reason 0x%x\n",
> exit_reason);
> dump_vmcs();
Re: [PATCH RT v3 5/5] rcutorture: Avoid problematic critical section nesting on RT
On 2019-09-17 11:32:11 [-0500], Scott Wood wrote:
> Nice! Are the "false positives" real issues from components that are
> currently blacklisted on RT, or something different?
So first a little bit of infrastructure like commit d5096aa65acd0
("sched: Mark hrtimers to expire in hard interrupt context") is required
so lockdep can see it all properly without RT enabled. Then we need
patches to avoid lockdep complaining about things that are not complained
about in RT because the lock is converted to raw_spinlock_t or something
different is applied so we don't have the warning.
> -Scott
Sebastian
Re: [PATCH -next] nfsd: Make nfsd_reset_boot_verifier_locked static
On Mon, Sep 23, 2019 at 01:58:59PM +0800, YueHaibing wrote:
> Fix sparse warning:
>
> fs/nfsd/nfssvc.c:364:6: warning:
> symbol 'nfsd_reset_boot_verifier_locked' was not declared. Should it be
> static?
>
> Reported-by: Hulk Robot
> Signed-off-by: YueHaibing
OK, applied for 5.4.--b.
> ---
> fs/nfsd/nfssvc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/nfsd/nfssvc.c b/fs/nfsd/nfssvc.c
> index 3caaf56..fdf7ed4 100644
> --- a/fs/nfsd/nfssvc.c
> +++ b/fs/nfsd/nfssvc.c
> @@ -361,7 +361,7 @@ void nfsd_copy_boot_verifier(__be32 verf[2], struct
> nfsd_net *nn)
> done_seqretry(&nn->boot_lock, seq);
> }
>
> -void nfsd_reset_boot_verifier_locked(struct nfsd_net *nn)
> +static void nfsd_reset_boot_verifier_locked(struct nfsd_net *nn)
> {
> ktime_get_real_ts64(&nn->nfssvc_boot);
> }
> --
> 2.7.4
>
Re: [PATCH v8 2/3] arm64: mm: implement arch_faults_on_old_pte() on arm64
On Sat, Sep 21, 2019 at 09:50:53PM +0800, Jia He wrote:
> diff --git a/arch/arm64/include/asm/pgtable.h
> b/arch/arm64/include/asm/pgtable.h
> index e09760ece844..4a9939615e41 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -868,6 +868,18 @@ static inline void update_mmu_cache(struct
> vm_area_struct *vma,
> #define phys_to_ttbr(addr) (addr)
> #endif
>
> +/*
> + * On arm64 without hardware Access Flag, copying fromuser will fail because
from user
> + * the pte is old and cannot be marked young. So we always end up with zeroed
> + * page after fork() + CoW for pfn mappings. we don't always have a
^^
We
> + * hardware-managed access flag on arm64.
> + */
> +static inline bool arch_faults_on_old_pte(void)
> +{
> + return !cpu_has_hw_af();
I saw an early incarnation of your patch having a
WARN_ON(preemptible()). I think we need this back just in case this
function will be used elsewhere in the future.
> +}
> +#define arch_faults_on_old_pte arch_faults_on_old_pte
Otherwise,
Reviewed-by: Catalin Marinas
Re: kexec broken with STACKLEAK enabled
On Sun, Sep 22, 2019 at 10:32 AM Arvind Sankar wrote: > > Hi, since commit b059f801a937 (x86/purgatory: Use CFLAGS_REMOVE rather > than reset KBUILD_CFLAGS) kexec is broken if GCC_PLUGIN_STACKLEAK is > enabled, as the purgatory contains undefined references to > stackleak_track_stack. > > Attempting to load a kexec kernel results in an error: > > kexec: Undefined symbol: stackleak_track_stack > kexec-bzImage64: Loading purgatory failed > > Adding $(DISABLE_STACKLEAK_PLUGIN) to PURGATORY_CFLAGS in > arch/x86/purgatory/Makefile fixes this. Hi Arvind, Thanks for the report. That sounds like a straightforward fix. Would you like to send a patch for that? I'd be happy to help review it. > > Not sure if that's the best fix or if other architectures also require a > similar one. The commit you reference should be x86 only. -- Thanks, ~Nick Desaulniers
[RFT v4 5/8] ARM: dts: exynos: Remove MCT subnode for interrupt map on Exynos4412
Multi Core Timer node has interrupts routed to two different parents -
GIC and combiner. This was modeled with a interrupt-map within a
subnode but can be expressed in an easier and more common way, directly
in the node itself.
Tested on Odroid U3 (Exynos4412).
Signed-off-by: Krzysztof Kozlowski
---
Changes since v3:
1. Use interrupts-extended instead of interrupts-map.
---
arch/arm/boot/dts/exynos4412.dtsi | 19 +--
1 file changed, 5 insertions(+), 14 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4412.dtsi
b/arch/arm/boot/dts/exynos4412.dtsi
index 8b6d5875c75d..9b5fb4e54d7c 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -246,22 +246,13 @@
timer@1005 {
compatible = "samsung,exynos4412-mct";
reg = <0x1005 0x800>;
- interrupt-parent = <&mct_map>;
- interrupts = <0>, <1>, <2>, <3>, <4>;
clocks = <&clock CLK_FIN_PLL>, <&clock CLK_MCT>;
clock-names = "fin_pll", "mct";
-
- mct_map: mct-map {
- #interrupt-cells = <1>;
- #address-cells = <0>;
- #size-cells = <0>;
- interrupt-map =
- <0 &gic 0 57 IRQ_TYPE_LEVEL_HIGH>,
- <1 &combiner 12 5>,
- <2 &combiner 12 6>,
- <3 &combiner 12 7>,
- <4 &gic 1 12 IRQ_TYPE_LEVEL_HIGH>;
- };
+ interrupts-extended = <&gic 0 57 IRQ_TYPE_LEVEL_HIGH>,
+ <&combiner 12 5>,
+ <&combiner 12 6>,
+ <&combiner 12 7>,
+ <&gic 1 12 IRQ_TYPE_LEVEL_HIGH>;
};
watchdog: watchdog@1006 {
--
2.17.1
[PATCH v4 8/8] ARM: dts: exynos: Use defines for MCT interrupt GIC SPI/PPI specifier
Replace hard-coded number with appropriate define for GIC SPI or PPI
specifier in interrupt. This makes code easier to read. No expected
functionality change.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos4210.dtsi | 8
arch/arm/boot/dts/exynos4412.dtsi | 4 ++--
arch/arm/boot/dts/exynos5250.dtsi | 4 ++--
arch/arm/boot/dts/exynos54xx.dtsi | 16
4 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index 5fa33d43821e..aac3b7a20a37 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -111,12 +111,12 @@
reg = <0x1005 0x800>;
clocks = <&clock CLK_FIN_PLL>, <&clock CLK_MCT>;
clock-names = "fin_pll", "mct";
- interrupts-extended = <&gic 0 57 IRQ_TYPE_LEVEL_HIGH>,
- <&gic 0 69 IRQ_TYPE_LEVEL_HIGH>,
+ interrupts-extended = <&gic GIC_SPI 57
IRQ_TYPE_LEVEL_HIGH>,
+ <&gic GIC_SPI 69
IRQ_TYPE_LEVEL_HIGH>,
<&combiner 12 6>,
<&combiner 12 7>,
- <&gic 0 42 IRQ_TYPE_LEVEL_HIGH>,
- <&gic 0 48 IRQ_TYPE_LEVEL_HIGH>;
+ <&gic GIC_SPI 42
IRQ_TYPE_LEVEL_HIGH>,
+ <&gic GIC_SPI 48
IRQ_TYPE_LEVEL_HIGH>;
};
watchdog: watchdog@1006 {
diff --git a/arch/arm/boot/dts/exynos4412.dtsi
b/arch/arm/boot/dts/exynos4412.dtsi
index 9b5fb4e54d7c..96a5ef3a2864 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -248,11 +248,11 @@
reg = <0x1005 0x800>;
clocks = <&clock CLK_FIN_PLL>, <&clock CLK_MCT>;
clock-names = "fin_pll", "mct";
- interrupts-extended = <&gic 0 57 IRQ_TYPE_LEVEL_HIGH>,
+ interrupts-extended = <&gic GIC_SPI 57
IRQ_TYPE_LEVEL_HIGH>,
<&combiner 12 5>,
<&combiner 12 6>,
<&combiner 12 7>,
- <&gic 1 12 IRQ_TYPE_LEVEL_HIGH>;
+ <&gic GIC_PPI 12
IRQ_TYPE_LEVEL_HIGH>;
};
watchdog: watchdog@1006 {
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index a549eafd2c64..f01e3156191d 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -242,8 +242,8 @@
<&combiner 23 4>,
<&combiner 25 2>,
<&combiner 25 3>,
- <&gic 0 120 IRQ_TYPE_LEVEL_HIGH>,
- <&gic 0 121 IRQ_TYPE_LEVEL_HIGH>;
+ <&gic GIC_SPI 120
IRQ_TYPE_LEVEL_HIGH>,
+ <&gic GIC_SPI 121
IRQ_TYPE_LEVEL_HIGH>;
};
pinctrl_0: pinctrl@1140 {
diff --git a/arch/arm/boot/dts/exynos54xx.dtsi
b/arch/arm/boot/dts/exynos54xx.dtsi
index aca1b4831e38..06ae40a2f1e9 100644
--- a/arch/arm/boot/dts/exynos54xx.dtsi
+++ b/arch/arm/boot/dts/exynos54xx.dtsi
@@ -71,14 +71,14 @@
<&combiner 23 4>,
<&combiner 25 2>,
<&combiner 25 3>,
- <&gic 0 120 IRQ_TYPE_LEVEL_HIGH>,
- <&gic 0 121 IRQ_TYPE_LEVEL_HIGH>,
- <&gic 0 122 IRQ_TYPE_LEVEL_HIGH>,
- <&gic 0 123 IRQ_TYPE_LEVEL_HIGH>,
- <&gic 0 128 IRQ_TYPE_LEVEL_HIGH>,
- <&gic 0 129 IRQ_TYPE_LEVEL_HIGH>,
- <&gic 0 130 IRQ_TYPE_LEVEL_HIGH>,
- <&gic 0 131 IRQ_TYPE_LEVEL_HIGH>;
+ <&gic GIC_SPI 120
IRQ_TYPE_LEVEL_HIGH>,
+ <&gic GIC_SPI 121
IRQ_TYPE_LEVEL_HIGH>,
+ <&gic GIC_SPI 122
IRQ_TYPE_LEVEL_HIGH>,
+ <&gic GIC_SPI 123
IRQ_TYPE_LEVEL_HIGH>,
+ <&gic GIC_SPI 128
IRQ_TYPE
[PATCH v4 7/8] ARM: dts: exynos: Remove MCT subnode for interrupt map on Exynos54xx
Multi Core Timer node has interrupts routed to two different parents -
GIC and combiner. This was modeled with a interrupt-map within a
subnode but can be expressed in an easier and more common way, directly
in the node itself.
Tested on Odroid XU (Exynos5410), Odroid HC1 (Exynos5422) and Arndale
Octa (Exynos5420).
Signed-off-by: Krzysztof Kozlowski
---
Changes since v3:
1. Use interrupts-extended instead of interrupts-map.
---
arch/arm/boot/dts/exynos54xx.dtsi | 33 +++
1 file changed, 12 insertions(+), 21 deletions(-)
diff --git a/arch/arm/boot/dts/exynos54xx.dtsi
b/arch/arm/boot/dts/exynos54xx.dtsi
index 247d23872384..aca1b4831e38 100644
--- a/arch/arm/boot/dts/exynos54xx.dtsi
+++ b/arch/arm/boot/dts/exynos54xx.dtsi
@@ -67,27 +67,18 @@
mct: timer@101c {
compatible = "samsung,exynos4210-mct";
reg = <0x101c 0xb00>;
- interrupt-parent = <&mct_map>;
- interrupts = <0>, <1>, <2>, <3>, <4>, <5>, <6>, <7>,
- <8>, <9>, <10>, <11>;
-
- mct_map: mct-map {
- #interrupt-cells = <1>;
- #address-cells = <0>;
- #size-cells = <0>;
- interrupt-map = <0 &combiner 23 3>,
- <1 &combiner 23 4>,
- <2 &combiner 25 2>,
- <3 &combiner 25 3>,
- <4 &gic 0 120
IRQ_TYPE_LEVEL_HIGH>,
- <5 &gic 0 121
IRQ_TYPE_LEVEL_HIGH>,
- <6 &gic 0 122
IRQ_TYPE_LEVEL_HIGH>,
- <7 &gic 0 123
IRQ_TYPE_LEVEL_HIGH>,
- <8 &gic 0 128
IRQ_TYPE_LEVEL_HIGH>,
- <9 &gic 0 129
IRQ_TYPE_LEVEL_HIGH>,
- <10 &gic 0 130
IRQ_TYPE_LEVEL_HIGH>,
- <11 &gic 0 131
IRQ_TYPE_LEVEL_HIGH>;
- };
+ interrupts-extended = <&combiner 23 3>,
+ <&combiner 23 4>,
+ <&combiner 25 2>,
+ <&combiner 25 3>,
+ <&gic 0 120 IRQ_TYPE_LEVEL_HIGH>,
+ <&gic 0 121 IRQ_TYPE_LEVEL_HIGH>,
+ <&gic 0 122 IRQ_TYPE_LEVEL_HIGH>,
+ <&gic 0 123 IRQ_TYPE_LEVEL_HIGH>,
+ <&gic 0 128 IRQ_TYPE_LEVEL_HIGH>,
+ <&gic 0 129 IRQ_TYPE_LEVEL_HIGH>,
+ <&gic 0 130 IRQ_TYPE_LEVEL_HIGH>,
+ <&gic 0 131 IRQ_TYPE_LEVEL_HIGH>;
};
watchdog: watchdog@101d {
--
2.17.1
[RFT v4 6/8] ARM: dts: exynos: Remove MCT subnode for interrupt map on Exynos5250
Multi Core Timer node has interrupts routed to two different parents -
GIC and combiner. This was modeled with a interrupt-map within a
subnode but can be expressed in an easier and more common way, directly
in the node itself.
Signed-off-by: Krzysztof Kozlowski
---
Not tested.
Changes since v3:
1. Use interrupts-extended instead of interrupts-map.
---
arch/arm/boot/dts/exynos5250.dtsi | 23 ++-
1 file changed, 6 insertions(+), 17 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 7a01349317a3..a549eafd2c64 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -236,25 +236,14 @@
timer@101c {
compatible = "samsung,exynos4210-mct";
reg = <0x101C 0x800>;
- interrupt-controller;
- #interrupt-cells = <2>;
- interrupt-parent = <&mct_map>;
- interrupts = <0 0>, <1 0>, <2 0>, <3 0>,
-<4 0>, <5 0>;
clocks = <&clock CLK_FIN_PLL>, <&clock CLK_MCT>;
clock-names = "fin_pll", "mct";
-
- mct_map: mct-map {
- #interrupt-cells = <2>;
- #address-cells = <0>;
- #size-cells = <0>;
- interrupt-map = <0x0 0 &combiner 23 3>,
- <0x1 0 &combiner 23 4>,
- <0x2 0 &combiner 25 2>,
- <0x3 0 &combiner 25 3>,
- <0x4 0 &gic 0 120
IRQ_TYPE_LEVEL_HIGH>,
- <0x5 0 &gic 0 121
IRQ_TYPE_LEVEL_HIGH>;
- };
+ interrupts-extended = <&combiner 23 3>,
+ <&combiner 23 4>,
+ <&combiner 25 2>,
+ <&combiner 25 3>,
+ <&gic 0 120 IRQ_TYPE_LEVEL_HIGH>,
+ <&gic 0 121 IRQ_TYPE_LEVEL_HIGH>;
};
pinctrl_0: pinctrl@1140 {
--
2.17.1
[RFT v4 4/8] ARM: dts: exynos: Remove MCT subnode for interrupt map on Exynos4210
Multi Core Timer node has interrupts routed to two different parents -
GIC and combiner. This was modeled with a interrupt-map within a
subnode but can be expressed in an easier and more common way, directly
in the node itself.
Signed-off-by: Krzysztof Kozlowski
---
Not tested.
Changes since v3:
1. Use interrupts-extended instead of interrupts-map.
---
arch/arm/boot/dts/exynos4210.dtsi | 21 ++---
1 file changed, 6 insertions(+), 15 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index 6d3f19562aab..5fa33d43821e 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -109,23 +109,14 @@
mct: timer@1005 {
compatible = "samsung,exynos4210-mct";
reg = <0x1005 0x800>;
- interrupt-parent = <&mct_map>;
- interrupts = <0>, <1>, <2>, <3>, <4>, <5>;
clocks = <&clock CLK_FIN_PLL>, <&clock CLK_MCT>;
clock-names = "fin_pll", "mct";
-
- mct_map: mct-map {
- #interrupt-cells = <1>;
- #address-cells = <0>;
- #size-cells = <0>;
- interrupt-map =
- <0 &gic 0 57 IRQ_TYPE_LEVEL_HIGH>,
- <1 &gic 0 69 IRQ_TYPE_LEVEL_HIGH>,
- <2 &combiner 12 6>,
- <3 &combiner 12 7>,
- <4 &gic 0 42 IRQ_TYPE_LEVEL_HIGH>,
- <5 &gic 0 48 IRQ_TYPE_LEVEL_HIGH>;
- };
+ interrupts-extended = <&gic 0 57 IRQ_TYPE_LEVEL_HIGH>,
+ <&gic 0 69 IRQ_TYPE_LEVEL_HIGH>,
+ <&combiner 12 6>,
+ <&combiner 12 7>,
+ <&gic 0 42 IRQ_TYPE_LEVEL_HIGH>,
+ <&gic 0 48 IRQ_TYPE_LEVEL_HIGH>;
};
watchdog: watchdog@1006 {
--
2.17.1
Re: [PATCH] arm: export memblock_reserve()d regions via /proc/iomem
On Mon, Sep 23, 2019 at 11:42:54PM +0800, Yu Chen wrote: > From: Yu Chen > > On Sat, 21 Sep 2019 15:51:38, Russell King - ARM Linux admin wrote: > > On Sat, Sep 21, 2019 at 09:02:49PM +0800, Yu Chen wrote: > > > From: Yu Chen > > > > > > memblock reserved regions are not reported via /proc/iomem on ARM, kexec's > > > user-space doesn't know about memblock_reserve()d regions and thus > > > possible for kexec to overwrite with the new kernel or initrd. > > > > Many reserved regions come from the kernel allocating memory during > > boot. We don't want to prevent kexec re-using those regions. > > > > > [0.00] Booting Linux on physical CPU 0xf00 > > > [0.00] Linux version 4.9.115-rt93-dirty > > > (yuchen@localhost.localdomain) (gcc version 6.2.0 (ZTE Embsys-TSP V3.07.2 > > > 0) ) #62 SMP PREEMPT Fri Sep 20 10:39:29 CST 2019 > > > [0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), > > > cr=30c5387d > > > [0.00] CPU: div instructions available: patching division code > > > [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing > > > instruction cache > > > [0.00] OF: fdt:Machine model: LS1021A TWR Board > > > [0.00] INITRD: 0x80f7f000+0x03695e40 overlaps in-use memory > > > region - disabling initrd > > > > Is the overlapping region one that is marked as reserved in DT? > > the overlapping region is not reserved in DT. > > > Where is the reserved region that overlaps the initrd coming from? > > I found the reserved region that overlaps the initrd is kernel code & data, > with memblock=debug cmdline start new kerne: > > / # kexec -l uImage-ls1021a --ramdisk=ramdisk-ls1021a --dtb=fdt > --append="root=/ > dev/ram0 rw console=ttyS0,115200 earlyprintk memblock=debug" -d > Try gzip decompression. > Try LZMA decompression. > lzma_decompress_file: read on uImage-ls1021a of 65536 bytes failed > kernel: 0xb6c71008 kernel_size: 0x317ab8 > MEMORY RANGES > 8000-bfff (0) > 80003000-80007fff (1) > 80e0-80ff (1) > 810c45a4-810c4fff (1) > 81ac4000-85159fff (1) > 8515a000-8515 (1) > 8800-8b695fff (1) > 8f00-8f004fff (1) > af709000-af7eafff (1) > af7ed000-afffbfff (1) > afffc000-afffcfff (1) > afffd000-afff (1) > bc00-bfff (1) > zImage header: 0x016f2818 0x 0x00317a78 > zImage size 0x317a78, file size 0x317a78 I see nothing here that suggests either a new kexec or a sufficiently new kernel. Hence, kexec lacks all the information to correctly layout the images in physical memory. The kernel was augmented with additional information around the v4.15 time. See commits: c772568788b5 ARM: add additional table to compressed kernel 429f7a062e3b ARM: decompressor: fix BSS size calculation 99cf8f903148 ARM: better diagnostics with missing/corrupt dtb There may be some others also needed, but I forget now, it was two years ago. For kexec, you need at least 2.0.17 (2.0.16 merged the wrong version of one of my patches.) > kexec_load: entry = 0x80008000 flags = 0x28 > nr_segments = 3 > segment[0].buf = 0xb6c71048 > segment[0].bufsz = 0x317a78 > segment[0].mem = 0x80008000 > segment[0].memsz = 0x318000 > segment[1].buf = 0xb35db048 > segment[1].bufsz = 0x3695e40 > segment[1].mem = 0x80f7f000 > segment[1].memsz = 0x3696000 > segment[2].buf = 0x100b108 > segment[2].bufsz = 0x5090 > segment[2].mem = 0x84615000 > segment[2].memsz = 0x6000 > / # kexec -e > [ 126.583598] kexec_core: Starting new kernel > [ 126.587815] Disabling non-boot CPUs ... > [ 126.626917] CPU1: shutdown > [ 126.656344] Retrying again to check for CPU kill > [ 126.660947] CPU1 killed. > [ 126.687585] Bye! > [0.00] Booting Linux on physical CPU 0xf00 > [0.00] Linux version 4.9.115-rt93-CGEL-V6.02.10.R4-dirty > (yuchen@localhost.localdomain) (gcc version 6.2.0 (ZTE Embsys-TSP V3.07.20) ) > #62 SMP PREEMPT Fri Sep 20 10:39:29 CST 2019 > [0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=30c5387d > [0.00] CPU: div instructions available: patching division code > [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing > instruction cache > [0.00] OF: fdt:Machine model: LS1021A TWR Board > [0.00] memblock_reserve: [0x008020-0x00810c45a3] flags > 0x0 arm_memblock_init+0x44/0x23c > [0.00] INITRD: 0x80f7f000+0x03695e40 overlaps in-use memory region - > disabling initrd > [0.00] memblock_reserve: [0x0080003000-0x0080007fff] flags > 0x0 arm_mm_memblock_reserve+0x2c/0x30 > [0.00] memblock_reserve: [0x0084615000-0x008461a08f] flags > 0x0 early_init_dt_reserve_memory_arch+0x24/0x28 > [0.00] memblock_reserve: [0x008f00-0x008f004fff] flags > 0x0 early_init_dt_reserve_memory_a
[PATCH v4 3/8] arm64: dts: exynos: Rename Multi Core Timer node to "timer"
The device node name should reflect generic class of a device so rename
the Multi Core Timer node from "mct" to "timer". This will be also in
sync with upcoming DT schema. No functional change.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index a76f620f7f35..8baf3c645eae 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -754,7 +754,7 @@
status = "disabled";
};
- mct@101c {
+ timer@101c {
compatible = "samsung,exynos4210-mct";
reg = <0x101c 0x800>;
interrupts = ,
--
2.17.1
[PATCH v4 2/8] ARM: dts: exynos: Rename Multi Core Timer node to "timer"
The device node name should reflect generic class of a device so rename
the Multi Core Timer node from "mct" to "timer". This will be also in
sync with upcoming DT schema. No functional change.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos3250.dtsi | 2 +-
arch/arm/boot/dts/exynos4210.dtsi | 2 +-
arch/arm/boot/dts/exynos4412.dtsi | 2 +-
arch/arm/boot/dts/exynos5250.dtsi | 2 +-
arch/arm/boot/dts/exynos5260.dtsi | 2 +-
arch/arm/boot/dts/exynos54xx.dtsi | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/exynos3250.dtsi
b/arch/arm/boot/dts/exynos3250.dtsi
index 784818490376..d122fb52d3d4 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -265,7 +265,7 @@
(GIC_CPU_MASK_SIMPLE(4) |
IRQ_TYPE_LEVEL_HIGH)>;
};
- mct@1005 {
+ timer@1005 {
compatible = "samsung,exynos4210-mct";
reg = <0x1005 0x800>;
interrupts = ,
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index f220716239db..6d3f19562aab 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -106,7 +106,7 @@
arm,data-latency = <2 2 1>;
};
- mct: mct@1005 {
+ mct: timer@1005 {
compatible = "samsung,exynos4210-mct";
reg = <0x1005 0x800>;
interrupt-parent = <&mct_map>;
diff --git a/arch/arm/boot/dts/exynos4412.dtsi
b/arch/arm/boot/dts/exynos4412.dtsi
index d20db2dfe8e2..8b6d5875c75d 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -243,7 +243,7 @@
clock-names = "aclk200", "aclk400_mcuisp";
};
- mct@1005 {
+ timer@1005 {
compatible = "samsung,exynos4412-mct";
reg = <0x1005 0x800>;
interrupt-parent = <&mct_map>;
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index fc966c10cf49..7a01349317a3 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -233,7 +233,7 @@
power-domains = <&pd_mau>;
};
- mct@101c {
+ timer@101c {
compatible = "samsung,exynos4210-mct";
reg = <0x101C 0x800>;
interrupt-controller;
diff --git a/arch/arm/boot/dts/exynos5260.dtsi
b/arch/arm/boot/dts/exynos5260.dtsi
index 3581b57fbbf7..b0811dbbb362 100644
--- a/arch/arm/boot/dts/exynos5260.dtsi
+++ b/arch/arm/boot/dts/exynos5260.dtsi
@@ -180,7 +180,7 @@
reg = <0x1000 0x100>;
};
- mct: mct@100b {
+ mct: timer@100b {
compatible = "samsung,exynos4210-mct";
reg = <0x100B 0x1000>;
clocks = <&fin_pll>, <&clock_peri PERI_CLK_MCT>;
diff --git a/arch/arm/boot/dts/exynos54xx.dtsi
b/arch/arm/boot/dts/exynos54xx.dtsi
index 9c3b63b7cac6..247d23872384 100644
--- a/arch/arm/boot/dts/exynos54xx.dtsi
+++ b/arch/arm/boot/dts/exynos54xx.dtsi
@@ -64,7 +64,7 @@
};
};
- mct: mct@101c {
+ mct: timer@101c {
compatible = "samsung,exynos4210-mct";
reg = <0x101c 0xb00>;
interrupt-parent = <&mct_map>;
--
2.17.1
[PATCH v4 1/8] dt-bindings: timer: Convert Exynos MCT bindings to json-schema
Convert Samsung Exynos Soc Multi Core Timer bindings to DT schema format
using json-schema.
Signed-off-by: Krzysztof Kozlowski
---
Changes since v3:
1. Use interrupts-extended instead of interrupts-map.
Changes since v1:
1. Indent example with four spaces (more readable),
2. Rename nodes in example to timer,
3. Remove mct-map subnode.
---
.../bindings/timer/samsung,exynos4210-mct.txt | 88
.../timer/samsung,exynos4210-mct.yaml | 125 ++
2 files changed, 125 insertions(+), 88 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
create mode 100644
Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml
diff --git a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
deleted file mode 100644
index 8f78640ad64c..
--- a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
+++ /dev/null
@@ -1,88 +0,0 @@
-Samsung's Multi Core Timer (MCT)
-
-The Samsung's Multi Core Timer (MCT) module includes two main blocks, the
-global timer and CPU local timers. The global timer is a 64-bit free running
-up-counter and can generate 4 interrupts when the counter reaches one of the
-four preset counter values. The CPU local timers are 32-bit free running
-down-counters and generate an interrupt when the counter expires. There is
-one CPU local timer instantiated in MCT for every CPU in the system.
-
-Required properties:
-
-- compatible: should be "samsung,exynos4210-mct".
- (a) "samsung,exynos4210-mct", for mct compatible with Exynos4210 mct.
- (b) "samsung,exynos4412-mct", for mct compatible with Exynos4412 mct.
-
-- reg: base address of the mct controller and length of the address space
- it occupies.
-
-- interrupts: the list of interrupts generated by the controller. The following
- should be the order of the interrupts specified. The local timer interrupts
- should be specified after the four global timer interrupts have been
- specified.
-
- 0: Global Timer Interrupt 0
- 1: Global Timer Interrupt 1
- 2: Global Timer Interrupt 2
- 3: Global Timer Interrupt 3
- 4: Local Timer Interrupt 0
- 5: Local Timer Interrupt 1
- 6: ..
- 7: ..
- i: Local Timer Interrupt n
-
- For MCT block that uses a per-processor interrupt for local timers, such
- as ones compatible with "samsung,exynos4412-mct", only one local timer
- interrupt might be specified, meaning that all local timers use the same
- per processor interrupt.
-
-Example 1: In this example, the IP contains two local timers, using separate
- interrupts, so two local timer interrupts have been specified,
- in addition to four global timer interrupts.
-
- mct@1005 {
- compatible = "samsung,exynos4210-mct";
- reg = <0x1005 0x800>;
- interrupts = <0 57 0>, <0 69 0>, <0 70 0>, <0 71 0>,
-<0 42 0>, <0 48 0>;
- };
-
-Example 2: In this example, the timer interrupts are connected to two separate
- interrupt controllers. Hence, an interrupt-map is created to map
- the interrupts to the respective interrupt controllers.
-
- mct@101c {
- compatible = "samsung,exynos4210-mct";
- reg = <0x101C 0x800>;
- interrupt-parent = <&mct_map>;
- interrupts = <0>, <1>, <2>, <3>, <4>, <5>;
-
- mct_map: mct-map {
- #interrupt-cells = <1>;
- #address-cells = <0>;
- #size-cells = <0>;
- interrupt-map = <0 &gic 0 57 0>,
- <1 &gic 0 69 0>,
- <2 &combiner 12 6>,
- <3 &combiner 12 7>,
- <4 &gic 0 42 0>,
- <5 &gic 0 48 0>;
- };
- };
-
-Example 3: In this example, the IP contains four local timers, but using
- a per-processor interrupt to handle them. Either all the local
- timer interrupts can be specified, with the same interrupt specifier
- value or just the first one.
-
- mct@1005 {
- compatible = "samsung,exynos4412-mct";
- reg = <0x1005 0x800>;
-
- /* Both ways are possible in this case. Either: */
- interrupts = <0 57 0>, <0 69 0>, <0 70 0>, <0 71 0>,
-<0 42 0>;
- /* or: */
- interrupts = <0 57 0>, <0 69 0>, <0 70 0>, <0 71 0>,
-<0 42 0>, <0 42 0>, <0 42 0>, <0 42 0>;
- };
diff --git
a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml
b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml
new file mode 100644
in
Re: [PATCH] rcu/nocb: Fix uninitialized variable in nocb_gp_wait()
On Mon, Sep 23, 2019 at 05:26:34PM +0300, Dan Carpenter wrote:
> We never set this to false. This probably doesn't affect most people's
> runtime because GCC will automatically initialize it to false at certain
> common optimization levels. But that behavior is related to a bug in
> GCC and obviously should not be relied on.
>
> Fixes: 5d6742b37727 ("rcu/nocb: Use rcu_segcblist for no-CBs CPUs")
> Signed-off-by: Dan Carpenter
Good catch! Queued for v5.5, thank you!
Thanx, Paul
> ---
> kernel/rcu/tree_plugin.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
> index 2defc7fe74c3..fa08d55f7040 100644
> --- a/kernel/rcu/tree_plugin.h
> +++ b/kernel/rcu/tree_plugin.h
> @@ -1946,7 +1946,7 @@ static void nocb_gp_wait(struct rcu_data *my_rdp)
> int __maybe_unused cpu = my_rdp->cpu;
> unsigned long cur_gp_seq;
> unsigned long flags;
> - bool gotcbs;
> + bool gotcbs = false;
> unsigned long j = jiffies;
> bool needwait_gp = false; // This prevents actual uninitialized use.
> bool needwake;
> --
> 2.20.1
>
Re: [PATCH 02/17] KVM: monolithic: x86: convert the kvm_x86_ops methods to external functions
On Mon, Sep 23, 2019 at 12:19:30PM +0200, Paolo Bonzini wrote:
> On 20/09/19 23:24, Andrea Arcangeli wrote:
> > diff --git a/arch/x86/kvm/svm_ops.c b/arch/x86/kvm/svm_ops.c
> > new file mode 100644
> > index ..2aaabda92179
> > --- /dev/null
> > +++ b/arch/x86/kvm/svm_ops.c
> > @@ -0,0 +1,672 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * arch/x86/kvm/svm_ops.c
> > + *
> > + * Copyright 2019 Red Hat, Inc.
> > + */
> > +
> > +int kvm_x86_ops_cpu_has_kvm_support(void)
> > +{
> > + return has_svm();
> > +}
>
> Can you just rename all the functions in vmx/ and svm.c, instead of
> adding forwarders?
Yeah, having kvm_x86_ be analogous to kvm_arch_ seems like the obvious
approach. The necessary VMX and SVM renaming can be done in separate
preparatory patches, and the conversion from kvm_x86_ops to direct calls
would be fairly straightforward.
Alternatively, what if we use macros in the call sites, e.g. keep/require
vmx_ and svm_ prefixes for all functions, renaming VMX and SVM code as
needed? E.g.:
cpu_has_vmx_support -> vmx_supported_by_cpu
cpu_has_svm_support -> svm_supported_by_cpu
int vmx_disabled_by_bios(void)
int svm_disabled_by_bios(void)
#define X86_OP(name) kvm_x86_vendor##_##name
int kvm_arch_init(void *opaque)
{
if (X86_OP(supported_by_cpu())) {
printk(KERN_ERR "kvm: no hardware support\n");
r = -EOPNOTSUPP;
goto out;
}
if (X86_OP(disabled_by_bios())) {
printk(KERN_ERR "kvm: disabled by bios\n");
r = -EOPNOTSUPP;
goto out;
}
}
Pros:
- Smaller patches due to less renaming in VMX and SVM
- Calls to vendor code are very obvious
- Stack traces contain vmx vs. svm instead of kvm_x86
Cons:
- Macros
- Annoying development environment, e.g. editors tend to struggle with
macrofied funtion/variable names.
Re: [PATCH 5/5] arm64: dts: imx8mq: add DCSS node
Hi Laurentiu,
On Mon, Sep 23, 2019 at 11:14 AM Laurentiu Palcu
wrote:
> +
> + dcss: dcss@0x32e0 {
Node names should be generic, so:
dcss: display-controller@32e0
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "nxp,imx8mq-dcss";
> + reg = <0x32e0 0x2D000>, <0x32e2f000
> 0x1000>;
0x2d000 for consistency.
> + interrupts = <6>, <8>, <9>;
The interrupts are passed in the format.
Re: [PATCH] thermal: qoriq: add thermal monitor unit version 2 support
On 23/09/2019 11:24, Andy Tang wrote:
> Hi Rui, Edubezval,
>
> Would you please review this patch?
Eduardo,
can you give an update about the thermal maintenance discussion we had
at LPC2019?
Thanks
-- Daniel
>> -Original Message-
>> From: Andy Tang
>> Sent: 2019年8月29日 16:38
>> To: 'edubez...@gmail.com' ; 'rui.zh...@intel.com'
>>
>> Cc: 'daniel.lezc...@linaro.org' ; Leo Li
>> ; 'linux...@vger.kernel.org'
>> ; 'linux-kernel@vger.kernel.org'
>>
>> Subject: RE: [PATCH] thermal: qoriq: add thermal monitor unit version 2
>> support
>>
>> Hi Rui, Edubezval,
>>
>> Almost three monthes passed, I have not got your comments from you.
>> Could you please take a look at this patch?
>>
>> BR,
>> Andy
>>
>>> -Original Message-
>>> From: Andy Tang
>>> Sent: 2019年8月6日 10:57
>>> To: edubez...@gmail.com; rui.zh...@intel.com
>>> Cc: daniel.lezc...@linaro.org; Leo Li ;
>>> linux...@vger.kernel.org; linux-kernel@vger.kernel.org
>>> Subject: RE: [PATCH] thermal: qoriq: add thermal monitor unit version
>>> 2 support
>>>
>>> Any comments?
>>>
>>> BR,
>>> Andy
>>>
-Original Message-
From: Yuantian Tang
Sent: 2019年6月4日 10:51
To: edubez...@gmail.com; rui.zh...@intel.com
Cc: daniel.lezc...@linaro.org; Leo Li ;
linux...@vger.kernel.org; linux-kernel@vger.kernel.org; Andy Tang
Subject: [PATCH] thermal: qoriq: add thermal monitor unit version 2
support
Thermal Monitor Unit v2 is introduced on new Layscape SoC.
Compared to v1, TMUv2 has a little different register layout and
digital output is fairly linear.
Signed-off-by: Yuantian Tang
---
drivers/thermal/qoriq_thermal.c | 122
+---
1 file changed, 98 insertions(+), 24 deletions(-)
diff --git a/drivers/thermal/qoriq_thermal.c
b/drivers/thermal/qoriq_thermal.c index 3b5f5b3fb1bc..0df6dfddf804
100644
--- a/drivers/thermal/qoriq_thermal.c
+++ b/drivers/thermal/qoriq_thermal.c
@@ -13,6 +13,15 @@
#include "thermal_core.h"
#define SITES_MAX 16
+#define TMR_DISABLE 0x0
+#define TMR_ME0x8000
+#define TMR_ALPF 0x0c00
+#define TMR_ALPF_V2 0x0300
+#define TMTMIR_DEFAULT0x000f
+#define TIER_DISABLE 0x0
+#define TEUMR0_V2 0x51009C00
+#define TMU_VER1 0x1
+#define TMU_VER2 0x2
/*
* QorIQ TMU Registers
@@ -23,17 +32,55 @@ struct qoriq_tmu_site_regs {
u8 res0[0x8];
};
-struct qoriq_tmu_regs {
+struct qoriq_tmu_regs_v2 {
+ u32 tmr;/* Mode Register */
+ u32 tsr;/* Status Register */
+ u32 tmsr; /* monitor site register */
+ u32 tmtmir; /* Temperature measurement interval Register
>> */
+ u8 res0[0x10];
+ u32 tier; /* Interrupt Enable Register */
+ u32 tidr; /* Interrupt Detect Register */
+ u8 res1[0x8];
+ u32 tiiscr; /* interrupt immediate site capture register */
+ u32 tiascr; /* interrupt average site capture register */
+ u32 ticscr; /* Interrupt Critical Site Capture Register */
+ u32 res2;
+ u32 tmhtcr; /* monitor high temperature capture register */
+ u32 tmltcr; /* monitor low temperature capture register */
+ u32 tmrtrcr;/* monitor rising temperature rate capture register
>> */
+ u32 tmftrcr;/* monitor falling temperature rate capture register
>> */
+ u32 tmhtitr;/* High Temperature Immediate Threshold */
+ u32 tmhtatr;/* High Temperature Average Threshold */
+ u32 tmhtactr; /* High Temperature Average Crit Threshold */
+ u32 res3;
+ u32 tmltitr;/* monitor low temperature immediate threshold */
+ u32 tmltatr;/* monitor low temperature average threshold
>> register */
+ u32 tmltactr; /* monitor low temperature average critical
>> threshold */
+ u32 res4;
+ u32 tmrtrctr; /* monitor rising temperature rate critical threshold
>> */
+ u32 tmftrctr; /* monitor falling temperature rate critical
>> threshold*/
+ u8 res5[0x8];
+ u32 ttcfgr; /* Temperature Configuration Register */
+ u32 tscfgr; /* Sensor Configuration Register */
+ u8 res6[0x78];
+ struct qoriq_tmu_site_regs site[SITES_MAX];
+ u8 res7[0x9f8];
+ u32 ipbrr0; /* IP Block Revision Register 0 */
+ u32 ipbrr1; /* IP Block Revision Register 1 */
+ u8 res8[0x300];
+ u32 teumr0;
+ u32 teumr1;
+ u32 teumr2;
+ u32 res9;
+ u32 ttrcr[4]; /* Temperature Range Control Register */
+};
+
+struct qoriq_tmu_regs_v1 {
u32 tmr;/* Mode Register */
-#define TMR_DISABLE 0x0
-#define TMR_ME0x8000
Re: [PATCH v6 1/2] dt-bindings: edac: arm-dmc520.txt
On Thu, Sep 19, 2019 at 06:37:00PM +, Lei Wang wrote:
> This is the device tree bindings for new EDAC driver dmc520_edac.c.
>
> Signed-off-by: Lei Wang
> Reviewed-by: James Morse
>
> ---
> No change in v6.
> ---
> .../devicetree/bindings/edac/arm-dmc520.txt | 26 +++
> 1 file changed, 26 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/edac/arm-dmc520.txt
>
> diff --git a/Documentation/devicetree/bindings/edac/arm-dmc520.txt
> b/Documentation/devicetree/bindings/edac/arm-dmc520.txt
> new file mode 100644
> index ..71e7aa32971a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/edac/arm-dmc520.txt
> @@ -0,0 +1,26 @@
> +* ARM DMC-520 EDAC node
> +
> +Required properties:
> +- compatible : "brcm,dmc-520", "arm,dmc-520".
> +- reg: Address range of the DMC-520 registers.
> +- interrupts : DMC-520 interrupt numbers. The example below specifies
> + two interrupt lines for dram_ecc_errc_int and
> + dram_ecc_errd_int.
> +- interrupt-config : This is an array of interrupt masks. For each of the
> + above interrupt line, add one interrupt mask element
> to
> + it. That is, there is a 1:1 mapping from each
> interrupt
> + line to an interrupt mask. An interrupt mask can
> represent
> + multiple interrupts being enabled. Refer to
> interrupt_control
> + register in DMC-520 TRM for interrupt mapping. In the
> example
> + below, the interrupt configuration enables
> dram_ecc_errc_int
> + and dram_ecc_errd_int. And each interrupt is
> connected to
> + a separate interrupt line.
> +
> +Example:
> +
> +dmc0: dmc@20 {
> + compatible = "brcm,dmc-520", "arm,dmc-520";
> + reg = <0x20 0x8>;
> + interrupts = <0x0 0x349 0x4>, <0x0 0x34B 0x4>;
> + interrupt-config = <0x4>, <0x8>;
> +};
> --
Still needs a DT person ACK.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
[PATCH v2 5/5] perf cs-etm: Correct callchain for instruction sample
The synthesized flow use 'tidq->packet' for instruction samples, comparing against the thread stack and the branch samples which are uses the 'tidp->prev_packet', thus the instruction samples result in using an packet ahead than thread stack and branch samples. This leads to an instruction's callchain error as shows in below example: main 1579100 instructions: 10214854 perf_event_update_userpage+0x4c ([kernel.kallsyms]) 10214850 perf_event_update_userpage+0x48 ([kernel.kallsyms]) 10219360 perf_swevent_add+0x88 ([kernel.kallsyms]) 102135f4 event_sched_in.isra.57+0xbc ([kernel.kallsyms]) 102137a0 group_sched_in+0x60 ([kernel.kallsyms]) 10213b84 flexible_sched_in+0xfc ([kernel.kallsyms]) 1020c0b4 visit_groups_merge+0x12c ([kernel.kallsyms]) In the callchain log, for the two continuous lines the up line contains one child function info and the followed line contains the caller function info, and so forth. But the first two lines: perf_event_update_userpage+0x4c => the sampled instruction perf_event_update_userpage+0x48 => the parent function's calling The child function and parent function both are the same function perf_event_update_userpage(), but this isn't a recursive function, thus the sequence for perf_event_update_userpage() calling itself shouldn't never happen. This callchain error is caused by the instruction sample using an ahead packet than the thread stack, the thread stack is deferred to process this packet and missed to pop stack if this is a return packet. To fix this issue, we can simply change to use 'tidq->prev_packet' to generate the instruction samples, this allows the thread stack to push and pop synchronously with instruction sample. Finally, the callchain is displayed as below: main 1579100 instructions: 10214854 perf_event_update_userpage+0x4c ([kernel.kallsyms]) 10219360 perf_swevent_add+0x88 ([kernel.kallsyms]) 102135f4 event_sched_in.isra.57+0xbc ([kernel.kallsyms]) 102137a0 group_sched_in+0x60 ([kernel.kallsyms]) 10213b84 flexible_sched_in+0xfc ([kernel.kallsyms]) 1020c0b4 visit_groups_merge+0x12c ([kernel.kallsyms]) Signed-off-by: Leo Yan --- tools/perf/util/cs-etm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c index bd09254a7208..3f7edfd15124 100644 --- a/tools/perf/util/cs-etm.c +++ b/tools/perf/util/cs-etm.c @@ -1418,7 +1418,7 @@ static int cs_etm__sample(struct cs_etm_queue *etmq, struct cs_etm_packet *tmp; int ret; u8 trace_chan_id = tidq->trace_chan_id; - u64 instrs_executed = tidq->packet->instr_count; + u64 instrs_executed = tidq->prev_packet->instr_count; tidq->period_instructions += instrs_executed; @@ -1449,7 +1449,7 @@ static int cs_etm__sample(struct cs_etm_queue *etmq, */ u64 offset = (instrs_executed - instrs_over - 1); u64 addr = cs_etm__instr_addr(etmq, trace_chan_id, - tidq->packet, offset); + tidq->prev_packet, offset); ret = cs_etm__synth_instruction_sample( etmq, tidq, addr, etm->instructions_sample_period); -- 2.17.1
[PATCH v2 0/5] perf cs-etm: Support thread stack and callchain
This patch series adds support for thread stack and callchain. Patch 01 is to refactor the instruction size calculation and it is a preparation for patch 02. Patch 02 is to add thread stack support, after applying this patch then the option '-F,+callindent' can be used by perf script tool; patch 03 is to add branch filter thus the perf tool can only display function calls and returns after enable the call indentation or call chain related options. Patch 04 is the patch to synthesize call chain for the instruction samples. Patch 05 allows the instruction sample can be handled synchronously with the thread stack, thus it fixes an error for the callchain generation. This patch set has been tested on 96boards Hikey620. Test for option '-F,+callindent': Before: # perf script -F,+callindent main 2808 1 branches: coresight_test1 8634f5c8 coresight_test1+0x3c (/root/coresight_test/libcstest.so) main 2808 1 branches: printf@plt ba8d37ec main+0x28 (/root/coresight_test/main) main 2808 1 branches: printf@plt ba8d36bc printf@plt+0xc (/root/coresight_test/main) main 2808 1 branches: _init ba8d3650 _init+0x30 (/root/coresight_test/main) main 2808 1 branches: _dl_fixup 86373b4c _dl_runtime_resolve+0x40 (/lib/aarch64-linux-gnu/ld-2.28.so) main 2808 1 branches: _dl_lookup_symbol_x 8636e078 _dl_fixup+0xb8 (/lib/aarch64-linux-gnu/ld-2.28.so) [...] After: # perf script -F,+callindent main 2808 1 branches: coresight_test1@plt ba8d37d8 main+0x14 (/root/coresight_test/main) main 2808 1 branches: _dl_fixup86373b4c _dl_runtime_resolve+0x40 (/lib/aarch64-linux-gnu/ld-2.28.s main 2808 1 branches: _dl_lookup_symbol_x 8636e078 _dl_fixup+0xb8 (/lib/aarch64-linux-gnu/ld-2.28.so) main 2808 1 branches: do_lookup_x 8636a49c _dl_lookup_symbol_x+0x104 (/lib/aarch64-linux-gnu/ld-2.28. main 2808 1 branches: check_match 86369bf0 do_lookup_x+0x238 (/lib/aarch64-linux-gnu/ld-2.28.so) main 2808 1 branches: strcmp 86369888 check_match+0x70 (/lib/aarch64-linux-gnu/ld-2.28.so) main 2808 1 branches: printf@plt ba8d37ec main+0x28 (/root/coresight_test/main) main 2808 1 branches: _dl_fixup86373b4c _dl_runtime_resolve+0x40 (/lib/aarch64-linux-gnu/ld-2.28.s main 2808 1 branches: _dl_lookup_symbol_x 8636e078 _dl_fixup+0xb8 (/lib/aarch64-linux-gnu/ld-2.28.so) main 2808 1 branches: do_lookup_x 8636a49c _dl_lookup_symbol_x+0x104 (/lib/aarch64-linux-gnu/ld-2.28. main 2808 1 branches: _dl_name_match_p 86369af0 do_lookup_x+0x138 (/lib/aarch64-linux-gnu/ld-2.28.so) main 2808 1 branches: strcmp 8636f7f0 _dl_name_match_p+0x18 (/lib/aarch64-linux-gnu/ld-2.28.so) [...] Test for option '--itrace=g': Before: # perf script --itrace=g16l64i100 main 1579100 instructions: 102137f0 group_sched_in+0xb0 ([kernel.kallsyms]) main 1579100 instructions: 10213b78 flexible_sched_in+0xf0 ([kernel.kallsyms]) main 1579100 instructions: 102135ac event_sched_in.isra.57+0x74 ([kernel.kallsyms]) main 1579100 instructions: 10219344 perf_swevent_add+0x6c ([kernel.kallsyms]) main 1579100 instructions: 10214854 perf_event_update_userpage+0x4c ([kernel.kallsyms]) [...] After: # perf script --itrace=g16l64i100 main 1579100 instructions: 10213b78 flexible_sched_in+0xf0 ([kernel.kallsyms]) 1020c0b4 visit_groups_merge+0x12c ([kernel.kallsyms]) main 1579100 instructions:
[PATCH v2 3/5] perf cs-etm: Support branch filter
If user specifies options -F,+callindent or call chain related options, it means the user only cares about functions calls and returns; thus in this case it's pointless to generate samples for other types of branches. To output only pairs of calls and returns, this patch introduces branch filter and the filter is set according to synthetic options. Finally, perf can output only for calls and returns and without redundant branches. Before: # perf script -F,+callindent main 2808 1 branches: coresight_test1@plt ba8d37d8 main+0x14 (/root/coresight_test/main) main 2808 1 branches: coresight_test1@plt ba8d367c coresight_test1@plt+0xc (/root/coresight_test/main) main 2808 1 branches: _init ba8d3650 _init+0x30 (/root/coresight_test/main) main 2808 1 branches: _dl_fixup86373b4c _dl_runtime_resolve+0x40 (/lib/aarch64-linux-gnu/ld-2.28.s main 2808 1 branches: _dl_lookup_symbol_x 8636e078 _dl_fixup+0xb8 (/lib/aarch64-linux-gnu/ld-2.28.so) main 2808 1 branches: 8636a3f4 _dl_lookup_symbol_x+0x5c (/lib/aarch64-linux-gnu/ld-2.28.s main 2808 1 branches: 8636a3f4 _dl_lookup_symbol_x+0x5c (/lib/aarch64-linux-gnu/ld-2.28.s main 2808 1 branches: 8636a3f4 _dl_lookup_symbol_x+0x5c (/lib/aarch64-linux-gnu/ld-2.28.s main 2808 1 branches: 8636a3f4 _dl_lookup_symbol_x+0x5c (/lib/aarch64-linux-gnu/ld-2.28.s main 2808 1 branches: 8636a3f4 _dl_lookup_symbol_x+0x5c (/lib/aarch64-linux-gnu/ld-2.28.s [...] After: # perf script -F,+callindent main 2808 1 branches: coresight_test1@plt ba8d37d8 main+0x14 (/root/coresight_test/main) main 2808 1 branches: _dl_fixup86373b4c _dl_runtime_resolve+0x40 (/lib/aarch64-linux-gnu/ld-2.28.s main 2808 1 branches: _dl_lookup_symbol_x 8636e078 _dl_fixup+0xb8 (/lib/aarch64-linux-gnu/ld-2.28.so) main 2808 1 branches: do_lookup_x 8636a49c _dl_lookup_symbol_x+0x104 (/lib/aarch64-linux-gnu/ld-2.28. main 2808 1 branches: check_match 86369bf0 do_lookup_x+0x238 (/lib/aarch64-linux-gnu/ld-2.28.so) main 2808 1 branches: strcmp 86369888 check_match+0x70 (/lib/aarch64-linux-gnu/ld-2.28.so) main 2808 1 branches: printf@plt ba8d37ec main+0x28 (/root/coresight_test/main) main 2808 1 branches: _dl_fixup86373b4c _dl_runtime_resolve+0x40 (/lib/aarch64-linux-gnu/ld-2.28.s main 2808 1 branches: _dl_lookup_symbol_x 8636e078 _dl_fixup+0xb8 (/lib/aarch64-linux-gnu/ld-2.28.so) main 2808 1 branches: do_lookup_x 8636a49c _dl_lookup_symbol_x+0x104 (/lib/aarch64-linux-gnu/ld-2.28. main 2808 1 branches: _dl_name_match_p 86369af0 do_lookup_x+0x138 (/lib/aarch64-linux-gnu/ld-2.28.so) main 2808 1 branches: strcmp 8636f7f0 _dl_name_match_p+0x18 (/lib/aarch64-linux-gnu/ld-2.28.so) [...] Signed-off-by: Leo Yan --- tools/perf/util/cs-etm.c | 12 1 file changed, 12 insertions(+) diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c index 6bdc9cd8293c..018c7e682ded 100644 --- a/tools/perf/util/cs-etm.c +++ b/tools/perf/util/cs-etm.c @@ -55,6
[PATCH v2 4/5] perf cs-etm: Support callchain for instruction sample
CoreSight has supported the thread stack; so based on the thread stack
we can synthesize call chain for the instruction sample; the call chain
can be used by itrace option '--itrace=g'.
Before:
# perf script --itrace=g16l64i100
main 1579100 instructions: 102137f0
group_sched_in+0xb0 ([kernel.kallsyms])
main 1579100 instructions: 10213b78
flexible_sched_in+0xf0 ([kernel.kallsyms])
main 1579100 instructions: 102135ac
event_sched_in.isra.57+0x74 ([kernel.kallsyms])
main 1579100 instructions: 10219344
perf_swevent_add+0x6c ([kernel.kallsyms])
main 1579100 instructions: 10214854
perf_event_update_userpage+0x4c ([kernel.kallsyms])
[...]
After:
# perf script --itrace=g16l64i100
main 1579100 instructions:
10213b78 flexible_sched_in+0xf0 ([kernel.kallsyms])
1020c0b4 visit_groups_merge+0x12c ([kernel.kallsyms])
main 1579100 instructions:
102135ac event_sched_in.isra.57+0x74 ([kernel.kallsyms])
102137a0 group_sched_in+0x60 ([kernel.kallsyms])
10213b84 flexible_sched_in+0xfc ([kernel.kallsyms])
1020c0b4 visit_groups_merge+0x12c ([kernel.kallsyms])
main 1579100 instructions:
10219344 perf_swevent_add+0x6c ([kernel.kallsyms])
102135f4 event_sched_in.isra.57+0xbc ([kernel.kallsyms])
102137a0 group_sched_in+0x60 ([kernel.kallsyms])
10213b84 flexible_sched_in+0xfc ([kernel.kallsyms])
1020c0b4 visit_groups_merge+0x12c ([kernel.kallsyms])
[...]
Signed-off-by: Leo Yan
---
tools/perf/util/cs-etm.c | 35 +--
1 file changed, 33 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 018c7e682ded..bd09254a7208 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -17,6 +17,7 @@
#include
#include "auxtrace.h"
+#include "callchain.h"
#include "color.h"
#include "cs-etm.h"
#include "cs-etm-decoder/cs-etm-decoder.h"
@@ -73,6 +74,7 @@ struct cs_etm_traceid_queue {
size_t last_branch_pos;
union perf_event *event_buf;
struct thread *thread;
+ struct ip_callchain *chain;
struct branch_stack *last_branch;
struct branch_stack *last_branch_rb;
struct cs_etm_packet *prev_packet;
@@ -250,6 +252,16 @@ static int cs_etm__init_traceid_queue(struct cs_etm_queue
*etmq,
if (!tidq->prev_packet)
goto out_free;
+ if (etm->synth_opts.callchain) {
+ size_t sz = sizeof(struct ip_callchain);
+
+ /* Add 1 to callchain_sz for callchain context */
+ sz += (etm->synth_opts.callchain_sz + 1) * sizeof(u64);
+ tidq->chain = zalloc(sz);
+ if (!tidq->chain)
+ goto out_free;
+ }
+
if (etm->synth_opts.last_branch) {
size_t sz = sizeof(struct branch_stack);
@@ -274,6 +286,7 @@ static int cs_etm__init_traceid_queue(struct cs_etm_queue
*etmq,
zfree(&tidq->last_branch);
zfree(&tidq->prev_packet);
zfree(&tidq->packet);
+ zfree(&tidq->chain);
out:
return rc;
}
@@ -545,6 +558,7 @@ static void cs_etm__free_traceid_queues(struct cs_etm_queue
*etmq)
zfree(&tidq->last_branch_rb);
zfree(&tidq->prev_packet);
zfree(&tidq->packet);
+ zfree(&tidq->chain);
zfree(&tidq);
/*
@@ -1125,7 +1139,7 @@ static void cs_etm__add_stack_event(struct cs_etm_queue
*etmq,
int insn_len;
u64 from_ip, to_ip;
- if (etm->synth_opts.thread_stack) {
+ if (etm->synth_opts.callchain || etm->synth_opts.thread_stack) {
from_ip = cs_etm__last_executed_instr(tidq->prev_packet);
to_ip = cs_etm__first_executed_instr(tidq->packet);
@@ -1181,6 +1195,14 @@ static int cs_etm__synth_instruction_sample(struct
cs_etm_queue *etmq,
cs_etm__copy_insn(etmq, tidq->trace_chan_id, tidq->packet, &sample);
+ if (etm->synth_opts.callchain) {
+ thread_stack__sample(tidq->thread, tidq->packet->cpu,
+tidq->chain,
+etm->synth_opts.callchain_sz + 1,
+sample.ip, etm->kernel_start);
+ sample.callchain = tidq->chain;
+ }
+
if (etm->synth_opts.last_branch) {
cs_etm__copy_last_branch_rb(etmq, tidq);
sample.branch_stack = tidq->last_branch;
@@ -1368,6 +1390,8 @@ static int cs_etm__synth_events(struct cs_etm_auxtrace
*etm,
attr.sample_type &= ~(u64)PERF_SAMPLE_ADDR;
}
+
[PATCH v2 2/5] perf cs-etm: Support thread stack
Arm CoreSight doesn't support thread stack, thus the decoding cannot
display the symbol with indented spaces to reflect the stack depth.
This patch adds support thread stack, this allows 'perf script' to
support option '-F,+callindent'.
Before:
# perf script -F,+callindent
main 2808 1 branches: coresight_test1
8634f5c8 coresight_test1+0x3c (/root/coresight_test/libcstest.so)
main 2808 1 branches: printf@plt
ba8d37ec main+0x28 (/root/coresight_test/main)
main 2808 1 branches: printf@plt
ba8d36bc printf@plt+0xc (/root/coresight_test/main)
main 2808 1 branches: _init
ba8d3650 _init+0x30 (/root/coresight_test/main)
main 2808 1 branches: _dl_fixup
86373b4c _dl_runtime_resolve+0x40
(/lib/aarch64-linux-gnu/ld-2.28.so)
main 2808 1 branches: _dl_lookup_symbol_x
8636e078 _dl_fixup+0xb8 (/lib/aarch64-linux-gnu/ld-2.28.so)
[...]
After:
# perf script -F,+callindent
main 2808 1 branches:
coresight_test1 8634f5c8
coresight_test1+0x3c (/root/coresight_test/libcstest.so)
main 2808 1 branches: printf@plt
ba8d37ec main+0x28
(/root/coresight_test/main)
main 2808 1 branches:
printf@plt ba8d36bc printf@plt+0xc
(/root/coresight_test/main)
main 2808 1 branches: _init
ba8d3650 _init+0x30
(/root/coresight_test/main)
main 2808 1 branches:
_dl_fixup86373b4c
_dl_runtime_resolve+0x40 (/lib/aarch64-linux-gnu/ld-2.28.s
main 2808 1 branches:
_dl_lookup_symbol_x 8636e078 _dl_fixup+0xb8
(/lib/aarch64-linux-gnu/ld-2.28.so)
[...]
Signed-off-by: Leo Yan
---
tools/perf/util/cs-etm.c | 44
1 file changed, 44 insertions(+)
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 1de3f9361193..6bdc9cd8293c 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -1116,6 +1116,45 @@ static void cs_etm__copy_insn(struct cs_etm_queue *etmq,
sample->insn_len, (void *)sample->insn);
}
+static void cs_etm__add_stack_event(struct cs_etm_queue *etmq,
+ struct cs_etm_traceid_queue *tidq)
+{
+ struct cs_etm_auxtrace *etm = etmq->etm;
+ u8 trace_chan_id = tidq->trace_chan_id;
+ int insn_len;
+ u64 from_ip, to_ip;
+
+ if (etm->synth_opts.thread_stack) {
+ from_ip = cs_etm__last_executed_instr(tidq->prev_packet);
+ to_ip = cs_etm__first_executed_instr(tidq->packet);
+
+ insn_len = cs_etm__instr_size(etmq, trace_chan_id,
+ tidq->prev_packet->isa, from_ip);
+
+ /*
+* Create thread stacks by keeping track of calls and returns;
+* any call pushes thread stack, return pops the stack, and
+* flush stack when the trace is discontinuous.
+*/
+ thread_stack__event(tidq->thread, tidq->prev_packet->cpu,
+ tidq->prev_packet->flags,
+ from_ip, to_ip, insn_len,
+ etmq->buffer->buffer_nr);
+ } else {
+ /*
+* The thread stack can be output via thread_stack__process();
+* thus the detailed information about paired calls and returns
+* will be facilitated by Python script for the db-export.
+*
+* Need to set trace buffer number and flush thread stack if the
+* trace buffer number has been alternate.
+*/
+ thread_stack__set_trace_nr(tidq->thread,
+ tidq->prev_packet->cpu,
+ etmq->buffer->buffer_nr);
+ }
+}
+
static int cs_etm__synth_instruction_sample(struct cs_etm_queue *etmq,
struct cs_etm_traceid_queue *tidq,
u64 addr, u64 period)
@@ -1392,6 +1431,9 @@ static int cs_etm__sample(struct cs_etm_queue *etmq,
tidq->period_instructions = instrs_over;
}
+ if (tidq->prev_pa
