[PATCH v5 2/6] perf: hisi: Add support for HiSilicon SoC uncore PMU driver
This patch adds support HiSilicon SoC uncore PMU driver framework and
interfaces.
Reviewed-by: Jonathan Cameron
Signed-off-by: Shaokun Zhang
Signed-off-by: Anurup M
---
drivers/perf/Kconfig | 7 +
drivers/perf/Makefile| 1 +
drivers/perf/hisilicon/Makefile | 1 +
drivers/perf/hisilicon/hisi_uncore_pmu.c | 440 +++
drivers/perf/hisilicon/hisi_uncore_pmu.h | 107
5 files changed, 556 insertions(+)
create mode 100644 drivers/perf/hisilicon/Makefile
create mode 100644 drivers/perf/hisilicon/hisi_uncore_pmu.c
create mode 100644 drivers/perf/hisilicon/hisi_uncore_pmu.h
diff --git a/drivers/perf/Kconfig b/drivers/perf/Kconfig
index e5197ff..b1a3894 100644
--- a/drivers/perf/Kconfig
+++ b/drivers/perf/Kconfig
@@ -17,6 +17,13 @@ config ARM_PMU_ACPI
depends on ARM_PMU && ACPI
def_bool y
+config HISI_PMU
+ bool "HiSilicon SoC PMU"
+ depends on ARM64 && ACPI
+ help
+ Support for HiSilicon SoC uncore performance monitoring
+ unit (PMU), such as: L3C, HHA and DDRC.
+
config QCOM_L2_PMU
bool "Qualcomm Technologies L2-cache PMU"
depends on ARCH_QCOM && ARM64 && ACPI
diff --git a/drivers/perf/Makefile b/drivers/perf/Makefile
index 6420bd4..41d3342 100644
--- a/drivers/perf/Makefile
+++ b/drivers/perf/Makefile
@@ -1,5 +1,6 @@
obj-$(CONFIG_ARM_PMU) += arm_pmu.o arm_pmu_platform.o
obj-$(CONFIG_ARM_PMU_ACPI) += arm_pmu_acpi.o
+obj-$(CONFIG_HISI_PMU) += hisilicon/
obj-$(CONFIG_QCOM_L2_PMU) += qcom_l2_pmu.o
obj-$(CONFIG_QCOM_L3_PMU) += qcom_l3_pmu.o
obj-$(CONFIG_XGENE_PMU) += xgene_pmu.o
diff --git a/drivers/perf/hisilicon/Makefile b/drivers/perf/hisilicon/Makefile
new file mode 100644
index 000..2783bb3
--- /dev/null
+++ b/drivers/perf/hisilicon/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_HISI_PMU) += hisi_uncore_pmu.o
diff --git a/drivers/perf/hisilicon/hisi_uncore_pmu.c
b/drivers/perf/hisilicon/hisi_uncore_pmu.c
new file mode 100644
index 000..f7e8ca2
--- /dev/null
+++ b/drivers/perf/hisilicon/hisi_uncore_pmu.c
@@ -0,0 +1,440 @@
+/*
+ * HiSilicon SoC Hardware event counters support
+ *
+ * Copyright (C) 2017 Hisilicon Limited
+ * Author: Anurup M
+ * Shaokun Zhang
+ *
+ * This code is based on the uncore PMUs like arm-cci and arm-ccn.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "hisi_uncore_pmu.h"
+
+#define HISI_GET_EVENTID(ev) (ev->hw.config_base & 0xff)
+#define HISI_MAX_PERIOD(nr) (BIT_ULL(nr) - 1)
+
+/*
+ * PMU format attributes
+ */
+ssize_t hisi_format_sysfs_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct dev_ext_attribute *eattr;
+
+ eattr = container_of(attr, struct dev_ext_attribute, attr);
+
+ return sprintf(buf, "%s\n", (char *)eattr->var);
+}
+
+/*
+ * PMU event attributes
+ */
+ssize_t hisi_event_sysfs_show(struct device *dev,
+ struct device_attribute *attr, char *page)
+{
+ struct dev_ext_attribute *eattr;
+
+ eattr = container_of(attr, struct dev_ext_attribute, attr);
+
+ return sprintf(page, "config=0x%lx\n", (unsigned long)eattr->var);
+}
+
+/*
+ * sysfs cpumask attributes. For uncore PMU, we only have a single CPU to show
+ */
+ssize_t hisi_cpumask_sysfs_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct hisi_pmu *hisi_pmu = to_hisi_pmu(dev_get_drvdata(dev));
+
+ return sprintf(buf, "%d\n", hisi_pmu->on_cpu);
+}
+
+static bool hisi_validate_event_group(struct perf_event *event)
+{
+ struct perf_event *sibling, *leader = event->group_leader;
+ struct hisi_pmu *hisi_pmu = to_hisi_pmu(event->pmu);
+ /* Include count for the event */
+ int counters = 1;
+
+ /*
+* We must NOT create groups containing mixed PMUs, although
+* software events are acceptable
+*/
+ if (leader->pmu != event->pmu && !is_software_event(leader))
+ return false;
+
+ /* Increment counter for the leader */
+ counters++;
+
+ list_for_each_entry(sibling, &event->group_leader->sibling_list,
+ group_entry) {
+ if (is_software_event(sibling))
+ continue;
+ if (sibling->pmu != event->pmu)
+ return false;
+ /* Increment counter for each sibling */
+ counters++;
+ }
+
+ /* The group can not count events more than the counters in the HW */
+ return counters <= hisi_pmu->num_counters;
+}
+
+int hisi_uncore_pmu_counter_valid(struct hisi_pmu *hisi_pmu, int idx)
+{
+ return (idx >= 0 && idx
[PATCH v5 5/6] perf: hisi: Add support for HiSilicon SoC DDRC PMU driver
This patch adds support for DDRC PMU driver in HiSilicon SoC chip, Each
DDRC has own control, counter and interrupt registers and is an separate
PMU. For each DDRC PMU, it has 8-fixed-purpose counters which have been
mapped to 8-events by hardware, it assumes that counter index is equal
to event code (0 - 7) in DDRC PMU driver. Interrupt is supported to
handle counter (32-bits) overflow.
Reviewed-by: Jonathan Cameron
Signed-off-by: Shaokun Zhang
Signed-off-by: Anurup M
---
drivers/perf/hisilicon/Makefile | 2 +-
drivers/perf/hisilicon/hisi_uncore_ddrc_pmu.c | 467 ++
include/linux/cpuhotplug.h| 1 +
3 files changed, 469 insertions(+), 1 deletion(-)
create mode 100644 drivers/perf/hisilicon/hisi_uncore_ddrc_pmu.c
diff --git a/drivers/perf/hisilicon/Makefile b/drivers/perf/hisilicon/Makefile
index a72afe8..2621d51 100644
--- a/drivers/perf/hisilicon/Makefile
+++ b/drivers/perf/hisilicon/Makefile
@@ -1 +1 @@
-obj-$(CONFIG_HISI_PMU) += hisi_uncore_pmu.o hisi_uncore_l3c_pmu.o
hisi_uncore_hha_pmu.o
+obj-$(CONFIG_HISI_PMU) += hisi_uncore_pmu.o hisi_uncore_l3c_pmu.o
hisi_uncore_hha_pmu.o hisi_uncore_ddrc_pmu.o
diff --git a/drivers/perf/hisilicon/hisi_uncore_ddrc_pmu.c
b/drivers/perf/hisilicon/hisi_uncore_ddrc_pmu.c
new file mode 100644
index 000..f7b5568
--- /dev/null
+++ b/drivers/perf/hisilicon/hisi_uncore_ddrc_pmu.c
@@ -0,0 +1,467 @@
+/*
+ * HiSilicon SoC DDRC uncore Hardware event counters support
+ *
+ * Copyright (C) 2017 Hisilicon Limited
+ * Author: Shaokun Zhang
+ * Anurup M
+ *
+ * This code is based on the uncore PMUs like arm-cci and arm-ccn.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "hisi_uncore_pmu.h"
+
+/* DDRC register definition */
+#define DDRC_PERF_CTRL 0x010
+#define DDRC_FLUX_WR 0x380
+#define DDRC_FLUX_RD 0x384
+#define DDRC_FLUX_WCMD 0x388
+#define DDRC_FLUX_RCMD 0x38c
+#define DDRC_PRE_CMD0x3c0
+#define DDRC_ACT_CMD0x3c4
+#define DDRC_BNK_CHG0x3c8
+#define DDRC_RNK_CHG0x3cc
+#define DDRC_EVENT_CTRL 0x6C0
+#define DDRC_INT_MASK 0x6c8
+#define DDRC_INT_STATUS0x6cc
+#define DDRC_INT_CLEAR 0x6d0
+
+/* DDRC has 8-counters */
+#define DDRC_NR_COUNTERS 0x8
+#define DDRC_PERF_CTRL_EN 0x2
+
+/*
+ * For DDRC PMU, there are eight-events and every event has been mapped
+ * to fixed-purpose counters which register offset is not consistent.
+ * Therefore there is no write event type and we assume that event
+ * code (0 to 7) is equal to counter index in PMU driver.
+ */
+#define GET_DDRC_EVENTID(hwc) (hwc->config_base & 0x7)
+
+static const u32 ddrc_reg_off[] = {
+ DDRC_FLUX_WR, DDRC_FLUX_RD, DDRC_FLUX_WCMD, DDRC_FLUX_RCMD,
+ DDRC_PRE_CMD, DDRC_ACT_CMD, DDRC_BNK_CHG, DDRC_RNK_CHG
+};
+
+/*
+ * Select the counter register offset using the counter index.
+ * In DDRC there are no programmable counter, the count
+ * is readed form the statistics counter register itself.
+ */
+static u32 hisi_ddrc_pmu_get_counter_offset(int cntr_idx)
+{
+ return ddrc_reg_off[cntr_idx];
+}
+
+static u64 hisi_ddrc_pmu_read_counter(struct hisi_pmu *ddrc_pmu,
+ struct hw_perf_event *hwc)
+{
+ /* Use event code as counter index */
+ u32 idx = GET_DDRC_EVENTID(hwc);
+
+ if (!hisi_uncore_pmu_counter_valid(ddrc_pmu, idx)) {
+ dev_err(ddrc_pmu->dev, "Unsupported event index:%d!\n", idx);
+ return 0;
+ }
+
+ return readl(ddrc_pmu->base + hisi_ddrc_pmu_get_counter_offset(idx));
+}
+
+static void hisi_ddrc_pmu_write_counter(struct hisi_pmu *ddrc_pmu,
+ struct hw_perf_event *hwc, u64 val)
+{
+ u32 idx = GET_DDRC_EVENTID(hwc);
+
+ if (!hisi_uncore_pmu_counter_valid(ddrc_pmu, idx)) {
+ dev_err(ddrc_pmu->dev, "Unsupported event index:%d!\n", idx);
+ return;
+ }
+
+ writel((u32)val,
+ ddrc_pmu->base + hisi_ddrc_pmu_get_counter_offset(idx));
+}
+
+/*
+ * For DDRC PMU, event has been mapped to fixed-purpose counter by hardware,
+ * so there is no need to write event type.
+ */
+static void hisi_ddrc_pmu_write_evtype(struct hisi_pmu *hha_pmu, int idx,
+ u32 type)
+{
+}
+
+static void hisi_ddrc_pmu_start_counters(struct hisi_pmu *ddrc_pmu)
+{
+ u32 val;
+
+ /* Set perf_enable in DDRC_PERF_CTRL to start event counting */
+ val = readl(ddrc_pmu->base + DDRC_PERF_CTRL);
+ val |= DDRC_PERF_CTRL_EN;
+ writel(val, ddrc_pmu->base + DDRC_PERF_CTRL);
+}
+
+static void hisi_ddrc_pmu_stop_counters(st
[PATCH v5 3/6] perf: hisi: Add support for HiSilicon SoC L3C PMU driver
This patch adds support for L3C PMU driver in HiSilicon SoC chip, Each
L3C has own control, counter and interrupt registers and is an separate
PMU. For each L3C PMU, it has 8-programable counters and each counter
is free-running. Interrupt is supported to handle counter (48-bits)
overflow.
Reviewed-by: Jonathan Cameron
Signed-off-by: Shaokun Zhang
Signed-off-by: Anurup M
---
drivers/perf/hisilicon/Makefile | 2 +-
drivers/perf/hisilicon/hisi_uncore_l3c_pmu.c | 482 +++
include/linux/cpuhotplug.h | 1 +
3 files changed, 484 insertions(+), 1 deletion(-)
create mode 100644 drivers/perf/hisilicon/hisi_uncore_l3c_pmu.c
diff --git a/drivers/perf/hisilicon/Makefile b/drivers/perf/hisilicon/Makefile
index 2783bb3..4a3d3e6 100644
--- a/drivers/perf/hisilicon/Makefile
+++ b/drivers/perf/hisilicon/Makefile
@@ -1 +1 @@
-obj-$(CONFIG_HISI_PMU) += hisi_uncore_pmu.o
+obj-$(CONFIG_HISI_PMU) += hisi_uncore_pmu.o hisi_uncore_l3c_pmu.o
diff --git a/drivers/perf/hisilicon/hisi_uncore_l3c_pmu.c
b/drivers/perf/hisilicon/hisi_uncore_l3c_pmu.c
new file mode 100644
index 000..db96e7c
--- /dev/null
+++ b/drivers/perf/hisilicon/hisi_uncore_l3c_pmu.c
@@ -0,0 +1,482 @@
+/*
+ * HiSilicon SoC L3C uncore Hardware event counters support
+ *
+ * Copyright (C) 2017 Hisilicon Limited
+ * Author: Anurup M
+ * Shaokun Zhang
+ *
+ * This code is based on the uncore PMUs like arm-cci and arm-ccn.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "hisi_uncore_pmu.h"
+
+/* L3C register definition */
+#define L3C_PERF_CTRL 0x0408
+#define L3C_INT_MASK 0x0800
+#define L3C_INT_STATUS 0x0808
+#define L3C_INT_CLEAR 0x080c
+#define L3C_EVENT_CTRL 0x1c00
+#define L3C_EVENT_TYPE00x1d00
+/*
+ * Each counter is 48-bits and [48:63] are reserved
+ * which are Read-As-Zero and Writes-Ignored.
+ */
+#define L3C_CNTR0_LOWER0x1e00
+
+/* L3C has 8-counters */
+#define L3C_NR_COUNTERS0x8
+
+#define L3C_PERF_CTRL_EN 0x2
+#define L3C_EVTYPE_NONE0xff
+
+/*
+ * Select the counter register offset using the counter index
+ */
+static u32 hisi_l3c_pmu_get_counter_offset(int cntr_idx)
+{
+ return (L3C_CNTR0_LOWER + (cntr_idx * 8));
+}
+
+static u64 hisi_l3c_pmu_read_counter(struct hisi_pmu *l3c_pmu,
+struct hw_perf_event *hwc)
+{
+ u32 idx = hwc->idx;
+
+ if (!hisi_uncore_pmu_counter_valid(l3c_pmu, idx)) {
+ dev_err(l3c_pmu->dev, "Unsupported event index:%d!\n", idx);
+ return 0;
+ }
+
+ /* Read 64-bits and the upper 16 bits are RAZ */
+ return readq(l3c_pmu->base + hisi_l3c_pmu_get_counter_offset(idx));
+}
+
+static void hisi_l3c_pmu_write_counter(struct hisi_pmu *l3c_pmu,
+ struct hw_perf_event *hwc, u64 val)
+{
+ u32 idx = hwc->idx;
+
+ if (!hisi_uncore_pmu_counter_valid(l3c_pmu, idx)) {
+ dev_err(l3c_pmu->dev, "Unsupported event index:%d!\n", idx);
+ return;
+ }
+
+ /* Write 64-bits and the upper 16 bits are WI */
+ writeq(val, l3c_pmu->base + hisi_l3c_pmu_get_counter_offset(idx));
+}
+
+static void hisi_l3c_pmu_write_evtype(struct hisi_pmu *l3c_pmu, int idx,
+ u32 type)
+{
+ u32 reg, reg_idx, shift, val;
+
+ /*
+* Select the appropriate event select register(L3C_EVENT_TYPE0/1).
+* There are 2 event select registers for the 8 hardware counters.
+* Event code is 8-bits and for the former 4 hardware counters,
+* L3C_EVENT_TYPE0 is chosen. For the latter 4 hardware counters,
+* L3C_EVENT_TYPE1 is chosen.
+*/
+ reg = L3C_EVENT_TYPE0 + (idx / 4) * 4;
+ reg_idx = idx % 4;
+ shift = 8 * reg_idx;
+
+ /* Write event code to L3C_EVENT_TYPEx Register */
+ val = readl(l3c_pmu->base + reg);
+ val &= ~(L3C_EVTYPE_NONE << shift);
+ val |= (type << shift);
+ writel(val, l3c_pmu->base + reg);
+}
+
+static void hisi_l3c_pmu_start_counters(struct hisi_pmu *l3c_pmu)
+{
+ u32 val;
+
+ /*
+* Set perf_enable bit in L3C_PERF_CTRL register to start counting
+* for all enabled counters.
+*/
+ val = readl(l3c_pmu->base + L3C_PERF_CTRL);
+ val |= L3C_PERF_CTRL_EN;
+ writel(val, l3c_pmu->base + L3C_PERF_CTRL);
+}
+
+static void hisi_l3c_pmu_stop_counters(struct hisi_pmu *l3c_pmu)
+{
+ u32 val;
+
+ /*
+* Clear perf_enable bit in L3C_PERF_CTRL register to stop counting
+* for all enabled counters.
+*/
+ val = readl(l3c_pmu->base + L3
[PATCH v5 6/6] arm64: MAINTAINERS: hisi: Add HiSilicon SoC PMU support
Add support HiSilicon SoC uncore PMU driver. Signed-off-by: Shaokun Zhang --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 1c3feff..9d1ad57 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6147,6 +6147,13 @@ S: Maintained F: drivers/net/ethernet/hisilicon/ F: Documentation/devicetree/bindings/net/hisilicon*.txt +HISILICON PMU DRIVER +M: Shaokun Zhang +W: http://www.hisilicon.com +S: Supported +F: drivers/perf/hisilicon +F: Documentation/perf/hisi-pmu.txt + HISILICON ROCE DRIVER M: Lijun Ou M: Wei Hu(Xavier) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 1/6] Documentation: perf: hisi: Documentation for HiSilicon SoC PMU driver
This patch adds documentation for the uncore PMUs on HiSilicon SoC.
Reviewed-by: Jonathan Cameron
Signed-off-by: Shaokun Zhang
Signed-off-by: Anurup M
---
Documentation/perf/hisi-pmu.txt | 53 +
1 file changed, 53 insertions(+)
create mode 100644 Documentation/perf/hisi-pmu.txt
diff --git a/Documentation/perf/hisi-pmu.txt b/Documentation/perf/hisi-pmu.txt
new file mode 100644
index 000..267a028
--- /dev/null
+++ b/Documentation/perf/hisi-pmu.txt
@@ -0,0 +1,53 @@
+HiSilicon SoC uncore Performance Monitoring Unit (PMU)
+==
+The HiSilicon SoC chip includes various independent system device PMUs
+such as L3 cache (L3C), Hydra Home Agent (HHA) and DDRC. These PMUs are
+independent and have hardware logic to gather statistics and performance
+information.
+
+The HiSilicon SoC encapsulates multiple CPU and IO dies. Each CPU cluster
+(CCL) is made up of 4 cpu cores sharing one L3 cache; each CPU die is
+called Super CPU cluster (SCCL) and is made up of 6 CCLs. Each SCCL has
+two HHAs (0 - 1) and four DDRCs (0 - 3), respectively.
+
+HiSilicon SoC uncore PMU driver
+---
+Each device PMU has separate registers for event counting, control and
+interrupt, and the PMU driver shall register perf PMU drivers like L3C,
+HHA and DDRC etc. The available events and configuration options shall
+be described in the sysfs, see :
+/sys/devices/hisi_sccl{X}_/, or
+/sys/bus/event_source/devices/hisi_sccl{X}_.
+The "perf list" command shall list the available events from sysfs.
+
+Each L3C, HHA and DDRC is registered as a separate PMU with perf. The PMU
+name will appear in event listing as hisi_sccl_module.
+where "sccl-id" is the identifier of the SCCL and "index-id" is the index of
+module.
+e.g. hisi_sccl3_l3c0/rd_hit_cpipe is READ_HIT_CPIPE event of L3C index #0 in
+SCCL ID #3.
+e.g. hisi_sccl1_hha0/rx_operations is RX_OPERATIONS event of HHA index #0 in
+SCCL ID #1.
+
+The driver also provides a "cpumask" sysfs attribute, which shows the CPU core
+ID used to count the uncore PMU event.
+
+Example usage of perf:
+$# perf list
+hisi_sccl3_l3c0/rd_hit_cpipe/ [kernel PMU event]
+--
+hisi_sccl3_l3c0/wr_hit_cpipe/ [kernel PMU event]
+--
+hisi_sccl1_l3c0/rd_hit_cpipe/ [kernel PMU event]
+--
+hisi_sccl1_l3c0/wr_hit_cpipe/ [kernel PMU event]
+--
+
+$# perf stat -a -e hisi_sccl3_l3c0/rd_hit_cpipe/ sleep 5
+$# perf stat -a -e hisi_sccl3_l3c0/config=0x02/ sleep 5
+
+The current driver does not support sampling. So "perf record" is unsupported.
+Also attach to a task is unsupported as the events are all uncore.
+
+Note: Please contact the maintainer for a complete list of events supported for
+the PMU devices in the SoC and its information if needed.
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 0/6] Add HiSilicon SoC uncore Performance Monitoring Unit driver
This patchset adds support for HiSilicon SoC uncore PMUs driver. It includes L3C, Hydra Home Agent (HHA) and DDRC. Changes in v5: * remove unnecessary name/num_events member in hisi_pmu * refactor hisi_pmu_hwevents structure * remove hisi_pmu_alloc function * revise cpuhotplug for L3C PMUs * add cpuhotplug for HHA/DDRC PMUs * fix the name format of uncore PMUs * remove unnecessary variants Changes in v4: * remove redundant code and comments * reverse the functions order in exit function * remove some GPL information * revise including header file * fix Jonathan's other comments Changes in v3: * rebase to 4.13-rc1 * add dev_err if ioremap fails for PMUs Changes in v2: * fix kbuild test robot error * make hisi_uncore_ops static Shaokun Zhang (6): Documentation: perf: hisi: Documentation for HiSilicon SoC PMU driver perf: hisi: Add support for HiSilicon SoC uncore PMU driver perf: hisi: Add support for HiSilicon SoC L3C PMU driver perf: hisi: Add support for HiSilicon SoC HHA PMU driver perf: hisi: Add support for HiSilicon SoC DDRC PMU driver arm64: MAINTAINERS: hisi: Add HiSilicon SoC PMU support Documentation/perf/hisi-pmu.txt | 53 +++ MAINTAINERS | 7 + drivers/perf/Kconfig | 7 + drivers/perf/Makefile | 1 + drivers/perf/hisilicon/Makefile | 1 + drivers/perf/hisilicon/hisi_uncore_ddrc_pmu.c | 467 + drivers/perf/hisilicon/hisi_uncore_hha_pmu.c | 477 + drivers/perf/hisilicon/hisi_uncore_l3c_pmu.c | 482 ++ drivers/perf/hisilicon/hisi_uncore_pmu.c | 440 +++ drivers/perf/hisilicon/hisi_uncore_pmu.h | 107 ++ include/linux/cpuhotplug.h| 3 + 11 files changed, 2045 insertions(+) create mode 100644 Documentation/perf/hisi-pmu.txt create mode 100644 drivers/perf/hisilicon/Makefile create mode 100644 drivers/perf/hisilicon/hisi_uncore_ddrc_pmu.c create mode 100644 drivers/perf/hisilicon/hisi_uncore_hha_pmu.c create mode 100644 drivers/perf/hisilicon/hisi_uncore_l3c_pmu.c create mode 100644 drivers/perf/hisilicon/hisi_uncore_pmu.c create mode 100644 drivers/perf/hisilicon/hisi_uncore_pmu.h -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 4/6] perf: hisi: Add support for HiSilicon SoC HHA PMU driver
L3 cache coherence is maintained by Hydra Home Agent (HHA) in HiSilicon
SoC. This patch adds support for HHA PMU driver, Each HHA has own
control, counter and interrupt registers and is an separate PMU. For
each HHA PMU, it has 16-programable counters and each counter is
free-running. Interrupt is supported to handle counter (48-bits)
overflow.
Reviewed-by: Jonathan Cameron
Signed-off-by: Shaokun Zhang
Signed-off-by: Anurup M
---
drivers/perf/hisilicon/Makefile | 2 +-
drivers/perf/hisilicon/hisi_uncore_hha_pmu.c | 477 +++
include/linux/cpuhotplug.h | 1 +
3 files changed, 479 insertions(+), 1 deletion(-)
create mode 100644 drivers/perf/hisilicon/hisi_uncore_hha_pmu.c
diff --git a/drivers/perf/hisilicon/Makefile b/drivers/perf/hisilicon/Makefile
index 4a3d3e6..a72afe8 100644
--- a/drivers/perf/hisilicon/Makefile
+++ b/drivers/perf/hisilicon/Makefile
@@ -1 +1 @@
-obj-$(CONFIG_HISI_PMU) += hisi_uncore_pmu.o hisi_uncore_l3c_pmu.o
+obj-$(CONFIG_HISI_PMU) += hisi_uncore_pmu.o hisi_uncore_l3c_pmu.o
hisi_uncore_hha_pmu.o
diff --git a/drivers/perf/hisilicon/hisi_uncore_hha_pmu.c
b/drivers/perf/hisilicon/hisi_uncore_hha_pmu.c
new file mode 100644
index 000..4b1ad21
--- /dev/null
+++ b/drivers/perf/hisilicon/hisi_uncore_hha_pmu.c
@@ -0,0 +1,477 @@
+/*
+ * HiSilicon SoC HHA uncore Hardware event counters support
+ *
+ * Copyright (C) 2017 Hisilicon Limited
+ * Author: Shaokun Zhang
+ * Anurup M
+ *
+ * This code is based on the uncore PMUs like arm-cci and arm-ccn.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "hisi_uncore_pmu.h"
+
+/* HHA register definition */
+#define HHA_INT_MASK 0x0804
+#define HHA_INT_STATUS 0x0808
+#define HHA_INT_CLEAR 0x080C
+#define HHA_PERF_CTRL 0x1E00
+#define HHA_EVENT_CTRL 0x1E04
+#define HHA_EVENT_TYPE00x1E80
+/*
+ * Each counter is 48-bits and [48:63] are reserved
+ * which are Read-As-Zero and Writes-Ignored.
+ */
+#define HHA_CNT0_LOWER 0x1F00
+
+/* HHA has 16-counters */
+#define HHA_NR_COUNTERS0x10
+
+#define HHA_PERF_CTRL_EN 0x1
+#define HHA_EVTYPE_NONE0xff
+
+/*
+ * Select the counter register offset using the counter index
+ * each counter is 48-bits.
+ */
+static u32 hisi_hha_pmu_get_counter_offset(int cntr_idx)
+{
+ return (HHA_CNT0_LOWER + (cntr_idx * 8));
+}
+
+static u64 hisi_hha_pmu_read_counter(struct hisi_pmu *hha_pmu,
+struct hw_perf_event *hwc)
+{
+ u32 idx = hwc->idx;
+
+ if (!hisi_uncore_pmu_counter_valid(hha_pmu, idx)) {
+ dev_err(hha_pmu->dev, "Unsupported event index:%d!\n", idx);
+ return 0;
+ }
+
+ /* Read 64 bits and like L3C, top 16 bits are RAZ */
+ return readq(hha_pmu->base + hisi_hha_pmu_get_counter_offset(idx));
+}
+
+static void hisi_hha_pmu_write_counter(struct hisi_pmu *hha_pmu,
+ struct hw_perf_event *hwc, u64 val)
+{
+ u32 idx = hwc->idx;
+
+ if (!hisi_uncore_pmu_counter_valid(hha_pmu, idx)) {
+ dev_err(hha_pmu->dev, "Unsupported event index:%d!\n", idx);
+ return;
+ }
+
+ /* Write 64 bits and like L3C, top 16 bits are WI */
+ writeq(val, hha_pmu->base + hisi_hha_pmu_get_counter_offset(idx));
+}
+
+static void hisi_hha_pmu_write_evtype(struct hisi_pmu *hha_pmu, int idx,
+ u32 type)
+{
+ u32 reg, reg_idx, shift, val;
+
+ /*
+* Select the appropriate event select register(HHA_EVENT_TYPEx).
+* There are 4 event select registers for the 16 hardware counters.
+* Event code is 8-bits and for the first 4 hardware counters,
+* HHA_EVENT_TYPE0 is chosen. For the next 4 hardware counters,
+* HHA_EVENT_TYPE1 is chosen and so on.
+*/
+ reg = HHA_EVENT_TYPE0 + 4 * (idx / 4);
+ reg_idx = idx % 4;
+ shift = 8 * reg_idx;
+
+ /* Write event code to HHA_EVENT_TYPEx register */
+ val = readl(hha_pmu->base + reg);
+ val &= ~(HHA_EVTYPE_NONE << shift);
+ val |= (type << shift);
+ writel(val, hha_pmu->base + reg);
+}
+
+static void hisi_hha_pmu_start_counters(struct hisi_pmu *hha_pmu)
+{
+ u32 val;
+
+ /*
+* Set perf_enable bit in HHA_PERF_CTRL to start event
+* counting for all enabled counters.
+*/
+ val = readl(hha_pmu->base + HHA_PERF_CTRL);
+ val |= HHA_PERF_CTRL_EN;
+ writel(val, hha_pmu->base + HHA_PERF_CTRL);
+}
+
+static void hisi_hha_pmu_stop_counters(struct hisi_pmu *hha_pmu)
+{
+ u32 val;
+
+ /*
+* Clear perf_enable bit
Re: [PATCH 0/2] extend PWM framework to support PWM dead-times
Hi Thierry, I added few other comments below. Please let me know what you think. Thank you, Claudiu On 21.08.2017 14:25, Thierry Reding wrote: > On Mon, Aug 21, 2017 at 01:23:08PM +0300, m18063 wrote: >> Hi Thierry, >> >> Thank you for your response. I added few comments below. >> >> Thank you, >> Claudiu >> >> On 21.08.2017 11:25, Thierry Reding wrote: >>> On Tue, May 09, 2017 at 03:15:51PM +0300, Claudiu Beznea wrote: Hi all, Please give feedback on these patches which extends the PWM framework in order to support multiple PWM signal types. Since I didn't receive any inputs on RFC series I'm resending it as normal patch series. The current patch series add the following PWM signal types: - PWM complementary signals - PWM push-pull signal Definition of PWM complementary mode: For a PWM controllers with more than one outputs per PWM channel, e.g. with 2 outputs per PWM channels, the PWM complementary signals have opposite levels, same duration and same starting times, as in the following diagram: ________ PWMH __| |__| |__| |__| |__ __________ PWML |__| |__| |__| |__| <--T--> Where T is the signal period. Definition of PWM push-pull mode: For PWM controllers with more than one outputs per PWM channel, e.g. with 2 outputs per PWM channel, the PWM push-pull signals have same levels, same duration and are delayed until the begining of the next period, as in the following diagram: __ __ PWMH __| || | __ __ PWML | || |__ <--T--> Where T is the signal period. These output signals could be configured by setting PWM mode (a new input in sysfs has been added in order to support this operation). root@sama5d2-xplained:/sys/devices/platform/ahb/ahb:apb/f802c000.pwm/pwm/pwmchip0/pwm2# ls -l -r--r--r--1 root root 4096 Feb 9 10:54 capture -rw-r--r--1 root root 4096 Feb 9 10:54 duty_cycle -rw-r--r--1 root root 4096 Feb 9 10:54 enable -rw-r--r--1 root root 4096 Feb 9 10:54 mode -rw-r--r--1 root root 4096 Feb 9 10:54 period -rw-r--r--1 root root 4096 Feb 9 10:55 polarity drwxr-xr-x2 root root 0 Feb 9 10:54 power -rw-r--r--1 root root 4096 Feb 9 10:54 uevent The PWM push-pull mode could be usefull in applications like half bridge converters. >>> >>> Sorry for taking an absurdly long time to get back to you on this. >>> >>> One problem I see with this is that the PWM framework is built on the >>> assumption that we have a single output per PWM channel. This becomes >>> important when you start adding features such as this because now the >>> users have no way of determining whether or not the PWM they retrieve >>> will actually be able to do what they want. >> I was thinking that the framework is there to offer support in configuring >> the underlying hardware without taking into account how many outputs per >> PWM channels are actually present. It is true I only worked with >> Atmel/Microchip >> PWM controllers which for instance, SAMA5 SoC has a PWM controller >> with 2 outputs per PWM channel. Taking into account that the driver is >> already mainlined I though that the user is aware of what he is using >> (either a one output per PWM channel controller, or 2 outputs or >> more than 2) and about the underlying hardware support. I understand your >> position on this. I'm just explaining myself on the approach I've chose >> for this implementation. > > So currently we assume that there will be (at least) one output per PWM > channel. However there are currently no drivers that actually use any > output other than the "primary" one. > > That means, even if there are currently PWM controllers that support > multiple outputs per PWM channel, we have no code making assumptions > about it. > > Before we can add code that makes any assumptions about the number of > outputs per PWM channel, we have to add facitilities for such code to > detect capabilities, so that they can deal with PWMs that don't match > what they need. > >>> For example, let's say you have a half bridge converter driver in the >>> kernel and it does a pwm_get() to obtain a PWM to use. There's nothing >>> preventing it from using a simple one-output PWM and there's no way to >>> check that we're actually doing something wrong. >> I understand your position here. I've chose this approach taking into >> account that the user of the PWM will be aware of the capabilities >> of the underlying hardware because I worked on a controller which already >> has a mainlined driver and which has more than one output
Re: [PATCH 0/2] extend PWM framework to support PWM dead-times
2017-08-22 14:11 GMT+02:00 m18063 : > Hi Thierry, > > I added few other comments below. Please let me know what you think. > > Thank you, > Claudiu > > On 21.08.2017 14:25, Thierry Reding wrote: >> On Mon, Aug 21, 2017 at 01:23:08PM +0300, m18063 wrote: >>> Hi Thierry, >>> >>> Thank you for your response. I added few comments below. >>> >>> Thank you, >>> Claudiu >>> >>> On 21.08.2017 11:25, Thierry Reding wrote: On Tue, May 09, 2017 at 03:15:51PM +0300, Claudiu Beznea wrote: > Hi all, > > Please give feedback on these patches which extends the PWM > framework in order to support multiple PWM signal types. > Since I didn't receive any inputs on RFC series I'm resending it as > normal patch series. > > The current patch series add the following PWM signal types: > - PWM complementary signals > - PWM push-pull signal > > Definition of PWM complementary mode: > For a PWM controllers with more than one outputs per PWM channel, > e.g. with 2 outputs per PWM channels, the PWM complementary signals > have opposite levels, same duration and same starting times, > as in the following diagram: > > ________ > PWMH __| |__| |__| |__| |__ > __________ > PWML |__| |__| |__| |__| ><--T--> > Where T is the signal period. > > Definition of PWM push-pull mode: > For PWM controllers with more than one outputs per PWM channel, > e.g. with 2 outputs per PWM channel, the PWM push-pull signals > have same levels, same duration and are delayed until the begining > of the next period, as in the following diagram: > > __ __ > PWMH __| || | > __ __ > PWML | || |__ ><--T--> > > Where T is the signal period. > > These output signals could be configured by setting PWM mode > (a new input in sysfs has been added in order to support this > operation). > > root@sama5d2-xplained:/sys/devices/platform/ahb/ahb:apb/f802c000.pwm/pwm/pwmchip0/pwm2# > ls -l > -r--r--r--1 root root 4096 Feb 9 10:54 capture > -rw-r--r--1 root root 4096 Feb 9 10:54 duty_cycle > -rw-r--r--1 root root 4096 Feb 9 10:54 enable > -rw-r--r--1 root root 4096 Feb 9 10:54 mode > -rw-r--r--1 root root 4096 Feb 9 10:54 period > -rw-r--r--1 root root 4096 Feb 9 10:55 polarity > drwxr-xr-x2 root root 0 Feb 9 10:54 power > -rw-r--r--1 root root 4096 Feb 9 10:54 uevent > > The PWM push-pull mode could be usefull in applications like > half bridge converters. Sorry for taking an absurdly long time to get back to you on this. One problem I see with this is that the PWM framework is built on the assumption that we have a single output per PWM channel. This becomes important when you start adding features such as this because now the users have no way of determining whether or not the PWM they retrieve will actually be able to do what they want. >>> I was thinking that the framework is there to offer support in configuring >>> the underlying hardware without taking into account how many outputs per >>> PWM channels are actually present. It is true I only worked with >>> Atmel/Microchip >>> PWM controllers which for instance, SAMA5 SoC has a PWM controller >>> with 2 outputs per PWM channel. Taking into account that the driver is >>> already mainlined I though that the user is aware of what he is using >>> (either a one output per PWM channel controller, or 2 outputs or >>> more than 2) and about the underlying hardware support. I understand your >>> position on this. I'm just explaining myself on the approach I've chose >>> for this implementation. >> >> So currently we assume that there will be (at least) one output per PWM >> channel. However there are currently no drivers that actually use any >> output other than the "primary" one. >> >> That means, even if there are currently PWM controllers that support >> multiple outputs per PWM channel, we have no code making assumptions >> about it. >> >> Before we can add code that makes any assumptions about the number of >> outputs per PWM channel, we have to add facitilities for such code to >> detect capabilities, so that they can deal with PWMs that don't match >> what they need. >> For example, let's say you have a half bridge converter driver in the kernel and it does a pwm_get() to obtain a PWM to use. There's nothing preventing it from using a simple one-output PWM and there's no way to check that we're actually doing something wrong. >>> I understand your position here. I've chose this approach taking into >>> account that the user of the PWM will be aware of the c
Re: [PATCH 0/2] extend PWM framework to support PWM dead-times
On 22.08.2017 15:24, Benjamin Gaignard wrote: > 2017-08-22 14:11 GMT+02:00 m18063 : >> Hi Thierry, >> >> I added few other comments below. Please let me know what you think. >> >> Thank you, >> Claudiu >> >> On 21.08.2017 14:25, Thierry Reding wrote: >>> On Mon, Aug 21, 2017 at 01:23:08PM +0300, m18063 wrote: Hi Thierry, Thank you for your response. I added few comments below. Thank you, Claudiu On 21.08.2017 11:25, Thierry Reding wrote: > On Tue, May 09, 2017 at 03:15:51PM +0300, Claudiu Beznea wrote: >> Hi all, >> >> Please give feedback on these patches which extends the PWM >> framework in order to support multiple PWM signal types. >> Since I didn't receive any inputs on RFC series I'm resending it as >> normal patch series. >> >> The current patch series add the following PWM signal types: >> - PWM complementary signals >> - PWM push-pull signal >> >> Definition of PWM complementary mode: >> For a PWM controllers with more than one outputs per PWM channel, >> e.g. with 2 outputs per PWM channels, the PWM complementary signals >> have opposite levels, same duration and same starting times, >> as in the following diagram: >> >> ________ >> PWMH __| |__| |__| |__| |__ >> __________ >> PWML |__| |__| |__| |__| >><--T--> >> Where T is the signal period. >> >> Definition of PWM push-pull mode: >> For PWM controllers with more than one outputs per PWM channel, >> e.g. with 2 outputs per PWM channel, the PWM push-pull signals >> have same levels, same duration and are delayed until the begining >> of the next period, as in the following diagram: >> >> __ __ >> PWMH __| || | >> __ __ >> PWML | || |__ >><--T--> >> >> Where T is the signal period. >> >> These output signals could be configured by setting PWM mode >> (a new input in sysfs has been added in order to support this >> operation). >> >> root@sama5d2-xplained:/sys/devices/platform/ahb/ahb:apb/f802c000.pwm/pwm/pwmchip0/pwm2# >> ls -l >> -r--r--r--1 root root 4096 Feb 9 10:54 capture >> -rw-r--r--1 root root 4096 Feb 9 10:54 duty_cycle >> -rw-r--r--1 root root 4096 Feb 9 10:54 enable >> -rw-r--r--1 root root 4096 Feb 9 10:54 mode >> -rw-r--r--1 root root 4096 Feb 9 10:54 period >> -rw-r--r--1 root root 4096 Feb 9 10:55 polarity >> drwxr-xr-x2 root root 0 Feb 9 10:54 power >> -rw-r--r--1 root root 4096 Feb 9 10:54 uevent >> >> The PWM push-pull mode could be usefull in applications like >> half bridge converters. > > Sorry for taking an absurdly long time to get back to you on this. > > One problem I see with this is that the PWM framework is built on the > assumption that we have a single output per PWM channel. This becomes > important when you start adding features such as this because now the > users have no way of determining whether or not the PWM they retrieve > will actually be able to do what they want. I was thinking that the framework is there to offer support in configuring the underlying hardware without taking into account how many outputs per PWM channels are actually present. It is true I only worked with Atmel/Microchip PWM controllers which for instance, SAMA5 SoC has a PWM controller with 2 outputs per PWM channel. Taking into account that the driver is already mainlined I though that the user is aware of what he is using (either a one output per PWM channel controller, or 2 outputs or more than 2) and about the underlying hardware support. I understand your position on this. I'm just explaining myself on the approach I've chose for this implementation. >>> >>> So currently we assume that there will be (at least) one output per PWM >>> channel. However there are currently no drivers that actually use any >>> output other than the "primary" one. >>> >>> That means, even if there are currently PWM controllers that support >>> multiple outputs per PWM channel, we have no code making assumptions >>> about it. >>> >>> Before we can add code that makes any assumptions about the number of >>> outputs per PWM channel, we have to add facitilities for such code to >>> detect capabilities, so that they can deal with PWMs that don't match >>> what they need. >>> > For example, let's say you have a half bridge converter driver in the > kernel and it does a pwm_get() to obtain a PWM to use. There's nothing > preventing it from using a simple one-output PWM and there's no way to > check that we're actua
Re: [PATCH 2/2 v7] printk: Add monotonic, boottime, and realtime timestamps
On 08/17/2017 11:30 AM, Mark Salyzyn wrote: > On 08/17/2017 06:15 AM, Prarit Bhargava wrote: >> printk.time=1/CONFIG_PRINTK_TIME=1 adds a unmodified local hardware clock >> timestamp to printk messages. The local hardware clock loses time each >> day making it difficult to determine exactly when an issue has occurred in >> the kernel log, and making it difficult to determine how kernel and >> hardware issues relate to each other in real time. > Congrats, greatly eases merges into older kernels, and has eliminated the > churn > this could place on all the configured systems out there. > > Sadly, one of my suggestions did not quite go the way I expected ;-} easy to > correct, and fix (I missed a spot in my original suggestion, as code changed > underfoot over the set ;-/). (see bottom) Added. I will send out v8 shortly. > > > > I am not convinced that user space is entirely at a disadvantage with this > 'feature' enabled. Before interpreting it can read > /sys/module/printk/parameters/time, then sniff for the flowing content for > time > breaks (watch for printk: timestamp set to ). Of course, the value in > 'time' is current, so it would be _wrong_ during flow of previous content > until > the first time break shows up if it really was being switched that often. > > (echo local ; echo disabled ; echo boottime ; echo monotonic ; echo realtime ; > echo local ) > /sys/module/printk/parameters/time > > [ 473.589169] printk: timestamp set to local > printk: timestamp set to disabled > [ 473.545384] printk: timestamp set to boottime > [ 473.549924] printk: timestamp set to monotonic > [1502957708.055265] printk: timestamp set to realtime > [ 473.612024] printk: timestamp set to local > > A 'fix' would be to add a letter after the timestamp if not local. For > example: > > [ 473.589169] printk: timestamp set to local > printk: timestamp set to disabled > [ 473.545384b] printk: timestamp set to boottime > [ 473.549924m] printk: timestamp set to monotonic > [1502957708.055265U] printk: timestamp set to realtime > [ 473.612024] printk: timestamp set to local > > (I used U instead of r, because it is actually UTC, and did not add 'l' > because > it is a long standing default) > > But there would be concern over a change in time format API, so maybe it > should > be relegated to a CONFIG_PRINTK_TIME_DEBUG 'feature' only to add the timebase > letters? ... then you wouldn't be able to use dmesg, etc., to get proper timestamp conversions. :( I'm not going to code dmesg for that because, as you point out it is outside of the scope of this patch. Maybe we can do something in future for this? P. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2 v7] printk: Add monotonic, boottime, and realtime timestamps
On Tue 2017-08-22 10:09:40, Prarit Bhargava wrote: > > > On 08/17/2017 11:30 AM, Mark Salyzyn wrote: > > On 08/17/2017 06:15 AM, Prarit Bhargava wrote: > >> printk.time=1/CONFIG_PRINTK_TIME=1 adds a unmodified local hardware clock > >> timestamp to printk messages. The local hardware clock loses time each > >> day making it difficult to determine exactly when an issue has occurred in > >> the kernel log, and making it difficult to determine how kernel and > >> hardware issues relate to each other in real time. > > Congrats, greatly eases merges into older kernels, and has eliminated the > > churn > > this could place on all the configured systems out there. > > > > Sadly, one of my suggestions did not quite go the way I expected ;-} easy to > > correct, and fix (I missed a spot in my original suggestion, as code changed > > underfoot over the set ;-/). (see bottom) > > Added. I will send out v8 shortly. It might make sense to wait a bit. I am in the middle of v7 review and have several comments. I would suggest to slow down this a bit anyway. You sent 7 versions within three weeks. It improved nicely over time. But I think that I am not the only one who has troubles to follow. Best Regards, Petr -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2 v7] printk: Add monotonic, boottime, and realtime timestamps
On 08/22/2017 10:23 AM, Petr Mladek wrote: > On Tue 2017-08-22 10:09:40, Prarit Bhargava wrote: >> >> >> On 08/17/2017 11:30 AM, Mark Salyzyn wrote: >>> On 08/17/2017 06:15 AM, Prarit Bhargava wrote: printk.time=1/CONFIG_PRINTK_TIME=1 adds a unmodified local hardware clock timestamp to printk messages. The local hardware clock loses time each day making it difficult to determine exactly when an issue has occurred in the kernel log, and making it difficult to determine how kernel and hardware issues relate to each other in real time. >>> Congrats, greatly eases merges into older kernels, and has eliminated the >>> churn >>> this could place on all the configured systems out there. >>> >>> Sadly, one of my suggestions did not quite go the way I expected ;-} easy to >>> correct, and fix (I missed a spot in my original suggestion, as code changed >>> underfoot over the set ;-/). (see bottom) >> >> Added. I will send out v8 shortly. > > It might make sense to wait a bit. I am in the middle of v7 review and > have several comments. > > I would suggest to slow down this a bit anyway. You sent 7 versions > within three weeks. It improved nicely over time. But I think that > I am not the only one who has troubles to follow. > np Petr. I will hold off on v8. P. > Best Regards, > Petr > -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fscrypt: add a documentation file for filesystem-level encryption
On 08/22/2017 10:55 AM, Eric Biggers wrote: On Tue, Aug 22, 2017 at 10:22:30AM +0800, Anand Jain wrote: Hi Eric, How about a section on the threat model specific to the file-name ? (Sorry if I am missing something). Thanks, Anand It's already mentioned that filenames are encrypted: "fscrypt protects the confidentiality of file contents and filenames in the event of a single point-in-time permanent offline compromise of the block device content." There's not much more to it than that; all the other points in the "Threat model" section (offline manipulations, timing attacks, access control, key eviction, etc.) are essentially the same between contents and filenames encryption. Do you think if application does not keep the sensitive information in the file-name, would that remove the file-name from the list of items that should be protected ? Thanks, Anand -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fscrypt: add a documentation file for filesystem-level encryption
+fscrypt is not guaranteed to protect confidentiality or authenticity +if an attacker is able to manipulate the filesystem offline prior to +an authorized user later accessing the filesystem. How does fscrypt / Android protect against Evil Maid attack. ? _However_, an "Evil Maid" attacker can probably still do other, perhaps much more effective attacks --- e.g. :: . Or they could attack the actual file contents encryption which is not authenticated. Or they could mess around with filesystem metadata on the userdata partition, which is neither encrypted nor authenticated. In specific, the scenario I had in mind was the above threat. I suppose that dm-integrity could be used to protect against some of those attacks, but of course it would not protect against hardware key loggers, etc. OK. I think AE is the only good solution for this, File-name encryption at this stage won't solve any kind of Evil Maid attack, (as it was quoted somewhere else in ML). Further, below, is define but not used. - #define FS_AES_256_GCM_KEY_SIZE 32 - Yes, authenticated encryption with AES-256-GCM was in an older version of the ext4 encryption design document. But unfortunately it was never really thought through. The primary problem, even ignoring rollback protection, is that there is nowhere to store the per-block metadata (GCM authentication tag and IV) *and* have it updated atomicly with the block contents. Recently, dm-integrity solves this at the block device layer, but it uses data journaling which is very inefficient. This maybe could be implemented more efficiently on a COW filesystem like BTRFS. But even after that, another problem is that authenticated encryption of file contents only would not stop an attacker from swapping around blocks, files, directories, or creating links, etc. Some of the problems to be solved in this area are quite interesting and challenging and IMO BTRFS fits nicely. Per extent AE for BTRFS is drafted, it needs scrutiny and constructive feedback. Thanks, Anand Eric -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Documentation: hw_random: Fix issue related to feeding entropy pool
There is no need to use rng-tools for feeding random data into kernel entropy pool as hw_random core handles it. Documentation suggested that rng-tools is required which is incorrect. So remove it. Signed-off-by: PrasannaKumar Muralidharan --- Documentation/hw_random.txt | 4 1 file changed, 4 deletions(-) diff --git a/Documentation/hw_random.txt b/Documentation/hw_random.txt index 121de96..46b2480 100644 --- a/Documentation/hw_random.txt +++ b/Documentation/hw_random.txt @@ -19,10 +19,6 @@ hw_random driver's official Web site: http://sourceforge.net/projects/gkernel/ -Those tools use /dev/hwrng to fill the kernel entropy pool, -which is used internally and exported by the /dev/urandom and -/dev/random special files. - Theory of operation === -- 2.10.0 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v5 2/4] mm, oom: cgroup-aware OOM killer
Hi Roman,
great work! This looks mostly good to me now. Below are some nitpicks
concerning naming and code layout, but nothing major.
On Mon, Aug 14, 2017 at 07:32:11PM +0100, Roman Gushchin wrote:
> @@ -39,6 +39,7 @@ struct oom_control {
> unsigned long totalpages;
> struct task_struct *chosen;
> unsigned long chosen_points;
> + struct mem_cgroup *chosen_memcg;
> };
Please rename 'chosen' to 'chosen_task' to make the distinction to
chosen_memcg clearer.
The ordering is a little weird too, with chosen_points in between.
chosen_task
chosen_memcg
chosen_points
?
> @@ -2639,6 +2639,181 @@ static inline bool memcg_has_children(struct
> mem_cgroup *memcg)
> return ret;
> }
>
> +static long memcg_oom_badness(struct mem_cgroup *memcg,
> + const nodemask_t *nodemask)
> +{
> + long points = 0;
> + int nid;
> +
> + for_each_node_state(nid, N_MEMORY) {
> + if (nodemask && !node_isset(nid, *nodemask))
> + continue;
> +
> + points += mem_cgroup_node_nr_lru_pages(memcg, nid,
> + LRU_ALL_ANON | BIT(LRU_UNEVICTABLE));
> + }
> +
> + points += memcg_page_state(memcg, MEMCG_KERNEL_STACK_KB) /
> + (PAGE_SIZE / 1024);
> + points += memcg_page_state(memcg, NR_SLAB_UNRECLAIMABLE);
NR_SLAB_UNRECLAIMABLE is now accounted per-lruvec, which takes
nodeness into account, and so would be more accurate here.
You can get it with mem_cgroup_lruvec() and lruvec_page_state().
> + points += memcg_page_state(memcg, MEMCG_SOCK);
> + points += memcg_page_state(memcg, MEMCG_SWAP);
> +
> + return points;
> +}
> +
> +static long oom_evaluate_memcg(struct mem_cgroup *memcg,
> +const nodemask_t *nodemask)
> +{
> + struct css_task_iter it;
> + struct task_struct *task;
> + int elegible = 0;
eligible
> +
> + css_task_iter_start(&memcg->css, 0, &it);
> + while ((task = css_task_iter_next(&it))) {
> + /*
> + * If there are no tasks, or all tasks have oom_score_adj set
> + * to OOM_SCORE_ADJ_MIN and oom_kill_all_tasks is not set,
> + * don't select this memory cgroup.
> + */
> + if (!elegible &&
> + (memcg->oom_kill_all_tasks ||
> + task->signal->oom_score_adj != OOM_SCORE_ADJ_MIN))
> + elegible = 1;
This is a little awkward to read. How about something like this:
/*
* When killing individual tasks, we respect OOM score adjustments:
* at least one task in the group needs to be killable for the group
* to be oomable.
*
* Also check that previous OOM kills have finished, and abort if
* there are any pending OOM victims.
*/
oomable = memcg->oom_kill_all_tasks;
while ((task = css_task_iter_next(&it))) {
if (!oomable && task->signal_oom_score_adj != OOM_SCORE_ADJ_MIN)
oomable = 1;
> + if (tsk_is_oom_victim(task) &&
> + !test_bit(MMF_OOM_SKIP, &task->signal->oom_mm->flags)) {
> + elegible = -1;
> + break;
> + }
> + }
> + css_task_iter_end(&it);
etc.
> +
> + return elegible > 0 ? memcg_oom_badness(memcg, nodemask) : elegible;
I find these much easier to read if broken up, even if it's more LOC:
if (eligible <= 0)
return eligible;
return memcg_oom_badness(memcg, nodemask);
> +static void select_victim_memcg(struct mem_cgroup *root, struct oom_control
> *oc)
> +{
> + struct mem_cgroup *iter, *parent;
> +
> + for_each_mem_cgroup_tree(iter, root) {
> + if (memcg_has_children(iter)) {
> + iter->oom_score = 0;
> + continue;
> + }
> +
> + iter->oom_score = oom_evaluate_memcg(iter, oc->nodemask);
> + if (iter->oom_score == -1) {
Please add comments to document the special returns. Maybe #defines
would be clearer, too.
> + oc->chosen_memcg = (void *)-1UL;
> + mem_cgroup_iter_break(root, iter);
> + return;
> + }
> +
> + if (!iter->oom_score)
> + continue;
Same here.
Maybe a switch would be suitable to handle the abort/no-score cases.
> + for (parent = parent_mem_cgroup(iter); parent && parent != root;
> + parent = parent_mem_cgroup(parent))
> + parent->oom_score += iter->oom_score;
> + }
> +
> + for (;;) {
> + struct cgroup_subsys_state *css;
> + struct mem_cgroup *memcg = NULL;
> + long score = LONG_MIN;
> +
> + css_for_each_child(css, &root->css) {
> + struct mem_cgroup *iter = mem_cgroup_from_css(css);
>
Re: [v5 1/4] mm, oom: refactor the oom_kill_process() function
On Mon, Aug 14, 2017 at 07:32:09PM +0100, Roman Gushchin wrote: > @@ -817,67 +817,12 @@ static bool task_will_free_mem(struct task_struct *task) > return ret; > } > > -static void oom_kill_process(struct oom_control *oc, const char *message) > +static void __oom_kill_process(struct task_struct *victim) oom_kill_task()? -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fscrypt: add a documentation file for filesystem-level encryption
On Tue, Aug 22, 2017 at 11:33:51PM +0800, Anand Jain wrote: > > > On 08/22/2017 10:55 AM, Eric Biggers wrote: > >On Tue, Aug 22, 2017 at 10:22:30AM +0800, Anand Jain wrote: > >> > >>Hi Eric, > >> > >> How about a section on the threat model specific to the file-name ? > >> > >> (Sorry if I am missing something). > >> > >>Thanks, Anand > > > >It's already mentioned that filenames are encrypted: "fscrypt protects the > >confidentiality of file contents and filenames in the event of a single > >point-in-time permanent offline compromise of the block device content." > >There's not much more to it than that; all the other points in the "Threat > >model" section (offline manipulations, timing attacks, access control, key > >eviction, etc.) are essentially the same between contents and filenames > >encryption. > > Do you think if application does not keep the sensitive information > in the file-name, would that remove the file-name from the list of > items that should be protected ? > If *no* applications care whether the filenames are encrypted or not, sure. But are you absolutely sure that no applications care? How do you know? And what is the advantage of not encrypting the filenames anyway? It is better to encrypt by default. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fscrypt: add a documentation file for filesystem-level encryption
On Tue, Aug 22, 2017 at 11:35:20PM +0800, Anand Jain wrote: > >> > >> I think AE is the only good solution for this, File-name encryption at > >>this stage won't solve any kind of Evil Maid attack, (as it was quoted > >>somewhere else in ML). > >> > >> > >> Further, below, is define but not used. > >>- > >> #define FS_AES_256_GCM_KEY_SIZE 32 > >>- > >> > > > >Yes, authenticated encryption with AES-256-GCM was in an older version of the > >ext4 encryption design document. But unfortunately it was never really > >thought > >through. The primary problem, even ignoring rollback protection, is that > >there > >is nowhere to store the per-block metadata (GCM authentication tag and IV) > >*and* > >have it updated atomicly with the block contents. Recently, dm-integrity > >solves > >this at the block device layer, but it uses data journaling which is very > >inefficient. This maybe could be implemented more efficiently on a COW > >filesystem like BTRFS. But even after that, another problem is that > >authenticated encryption of file contents only would not stop an attacker > >from > >swapping around blocks, files, directories, or creating links, etc. > > > Some of the problems to be solved in this area are quite > interesting and challenging and IMO BTRFS fits nicely. Per extent AE > for BTRFS is drafted, it needs scrutiny and constructive feedback. > > Thanks, Anand > > > >Eric > > Where is the code? Is there a design document, and it is it readable by people not as familiar with btrfs? Is the API compatible with ext4, f2fs, and ubifs? Eric -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v6 35/62] powerpc: Deliver SEGV signal on pkey violation
On Sat, Aug 19, 2017 at 02:09:58PM -0500, Eric W. Biederman wrote:
> Ram Pai writes:
>
> > diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
> > index d4e545d..fe1e7c7 100644
> > --- a/arch/powerpc/kernel/traps.c
> > +++ b/arch/powerpc/kernel/traps.c
> > @@ -20,6 +20,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -247,6 +248,15 @@ void user_single_step_siginfo(struct task_struct *tsk,
> > info->si_addr = (void __user *)regs->nip;
> > }
> >
> > +#ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS
> > +static void fill_sig_info_pkey(int si_code, siginfo_t *info, unsigned long
> > addr)
> > +{
> > + if (si_code != SEGV_PKUERR)
> > + return;
>
> Given that SEGV_PKUERR is a signal specific si_code this test is
> insufficient to detect an pkey error. You also need to check
> that signr == SIGSEGV
true. will make it a more precise check.
Thanks
RP
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] assoc_array: fix path to assoc_array documentation
Signed-off-by: Alexander Kuleshov --- lib/assoc_array.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/assoc_array.c b/lib/assoc_array.c index 59fd7c0b119c..155c55d8db5f 100644 --- a/lib/assoc_array.c +++ b/lib/assoc_array.c @@ -1,6 +1,6 @@ /* Generic associative array implementation. * - * See Documentation/assoc_array.txt for information. + * See Documentation/core-api/assoc_array.rst for information. * * Copyright (C) 2013 Red Hat, Inc. All Rights Reserved. * Written by David Howells (dhowe...@redhat.com) -- 2.13.5 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: sunxi: add support for R40 SoC
On Tue, Aug 22, 2017 at 01:14:09PM +0800, icen...@aosc.io wrote: > 在 2017-08-21 17:34，Maxime Ripard 写道： > > Hi, > > > > On Sun, Aug 20, 2017 at 01:29:57PM +0800, Icenowy Zheng wrote: > > > Allwinner R40 is a new SoC, with Quad Core Cortex-A7 and peripherals > > > like A20. > > > > > > Add support for it. > > > > > > Signed-off-by: Icenowy Zheng > > > --- > > > Documentation/arm/sunxi/README | 6 ++ > > > Documentation/devicetree/bindings/arm/sunxi.txt | 1 + > > > arch/arm/mach-sunxi/sunxi.c | 1 + > > > 3 files changed, 8 insertions(+) > > > > > > diff --git a/Documentation/arm/sunxi/README > > > b/Documentation/arm/sunxi/README > > > index d7b1f016bd62..4fa836782e46 100644 > > > --- a/Documentation/arm/sunxi/README > > > +++ b/Documentation/arm/sunxi/README > > > @@ -75,6 +75,12 @@ SunXi family > > > + Datasheet > > > http://linux-sunxi.org/File:Allwinner_V3s_Datasheet_V1.0.pdf > > > > > > + - Allwinner R40 (sun8i) > > > ++ Datasheet > > > + > > > https://github.com/tinalinux/docs/raw/r40-v1.y/R40_Datasheet_V1.0.pdf > > > ++ User Manual > > > + > > > https://github.com/tinalinux/docs/raw/r40-v1.y/Allwinner_R40_User_Manual_V1.0.pdf > > > + > > > > Please sort it by alphabetical order. > > I prefer to sort it by the wafer ID (the number after w in the > official ID). > > The current document can be explained to follow the alphabetical > order or the wafer ID. You should know who your audience is. Whoever is going to end up here to have a list of the SoC names and their datasheet is very likely to not know by heart the wafer IDs, while anyone that can read knows the alphabet. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature
[PATCH] docs-rst: fix pdf build with Spinx 1.6
Sphinx 1.6 generates some LaTeX code before each table,
starting its own environment before calling tabulary,
apparently to improve table layout.
The problem is that such environment is incompatible with
adjustbox. While, in thesis, it should be possible to override
it or to redefine tabulary, I was unable to produce such patch.
Also, that would likely break on some future Sphinx version.
So, instead, let's just change the font size on bigger tables,
in order for them to fit into the page size. That is not as
good as adjustbox, and require some manual work, but it should
be less sensitive to Sphinx changes.
While here, adjust a few other tables whose text is exceeding
the cell boundaries.
Signed-off-by: Mauro Carvalho Chehab
---
Not sure it such patch should be merged via linux-media or via linux-doc
tree. Merging it via linux-media would likely cause less conflicts, although
I guess it won't rise any merge conflicts if merged via linux-doc.
Documentation/conf.py | 3 -
Documentation/doc-guide/sphinx.rst | 4 +-
Documentation/media/uapi/v4l/dev-meta.rst | 2 +
Documentation/media/uapi/v4l/dev-raw-vbi.rst | 2 +-
Documentation/media/uapi/v4l/dev-sliced-vbi.rst| 21 ++-
Documentation/media/uapi/v4l/dev-subdev.rst| 6 +-
Documentation/media/uapi/v4l/extended-controls.rst | 6 +-
Documentation/media/uapi/v4l/pixfmt-inzi.rst | 7 +-
Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst | 30 ++--
Documentation/media/uapi/v4l/pixfmt-packed-rgb.rst | 186 +++--
Documentation/media/uapi/v4l/pixfmt-packed-yuv.rst | 50 +++---
Documentation/media/uapi/v4l/pixfmt-srggb10p.rst | 7 +-
Documentation/media/uapi/v4l/subdev-formats.rst| 13 +-
Documentation/media/uapi/v4l/vidioc-dqevent.rst| 2 +-
.../media/uapi/v4l/vidioc-dv-timings-cap.rst | 2 +-
.../media/uapi/v4l/vidioc-enum-frameintervals.rst | 2 +
Documentation/media/uapi/v4l/vidioc-enumstd.rst| 9 +-
.../media/uapi/v4l/vidioc-g-dv-timings.rst | 4 +-
.../media/uapi/v4l/vidioc-g-enc-index.rst | 2 +-
.../media/uapi/v4l/vidioc-g-ext-ctrls.rst | 2 +-
.../media/uapi/v4l/vidioc-g-sliced-vbi-cap.rst | 6 +-
Documentation/media/uapi/v4l/vidioc-g-tuner.rst| 4 +-
Documentation/media/uapi/v4l/vidioc-queryctrl.rst | 2 +-
scripts/sphinx-pre-install | 1 -
24 files changed, 200 insertions(+), 173 deletions(-)
diff --git a/Documentation/conf.py b/Documentation/conf.py
index 71b032bb44fd..25a58564362f 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -331,9 +331,6 @@ latex_elements = {
\\setromanfont{DejaVu Sans}
\\setmonofont{DejaVu Sans Mono}
- % To allow adjusting table sizes
- \\usepackage{adjustbox}
-
'''
}
diff --git a/Documentation/doc-guide/sphinx.rst
b/Documentation/doc-guide/sphinx.rst
index 8faafb9b2d86..a2417633fdd8 100644
--- a/Documentation/doc-guide/sphinx.rst
+++ b/Documentation/doc-guide/sphinx.rst
@@ -80,9 +80,7 @@ output.
PDF and LaTeX builds
-Such builds are currently supported only with Sphinx versions 1.4 and 1.5.
-
-Currently, it is not possible to do pdf builds with Sphinx version 1.6.
+Such builds are currently supported only with Sphinx versions 1.4 and upper.
For PDF and LaTeX output, you'll also need ``XeLaTeX`` version 3.14159265.
diff --git a/Documentation/media/uapi/v4l/dev-meta.rst
b/Documentation/media/uapi/v4l/dev-meta.rst
index 62518adfe37b..f7ac8d0d3af1 100644
--- a/Documentation/media/uapi/v4l/dev-meta.rst
+++ b/Documentation/media/uapi/v4l/dev-meta.rst
@@ -42,6 +42,8 @@ the :c:type:`v4l2_format` structure to 0.
.. _v4l2-meta-format:
+.. tabularcolumns:: |p{1.4cm}|p{2.2cm}|p{13.9cm}|
+
.. flat-table:: struct v4l2_meta_format
:header-rows: 0
:stub-columns: 0
diff --git a/Documentation/media/uapi/v4l/dev-raw-vbi.rst
b/Documentation/media/uapi/v4l/dev-raw-vbi.rst
index 2e6878b624f6..8d0d93a9a254 100644
--- a/Documentation/media/uapi/v4l/dev-raw-vbi.rst
+++ b/Documentation/media/uapi/v4l/dev-raw-vbi.rst
@@ -183,7 +183,7 @@ and always returns default parameters as :ref:`VIDIOC_G_FMT
` does
applications must set it to zero.
-.. tabularcolumns:: |p{4.0cm}|p{1.5cm}|p{12.0cm}|
+.. .. tabularcolumns:: |p{4.0cm}|p{1.5cm}|p{12.0cm}|
.. _vbifmt-flags:
diff --git a/Documentation/media/uapi/v4l/dev-sliced-vbi.rst
b/Documentation/media/uapi/v4l/dev-sliced-vbi.rst
index 5f6d534ea73b..5eec1f666dd0 100644
--- a/Documentation/media/uapi/v4l/dev-sliced-vbi.rst
+++ b/Documentation/media/uapi/v4l/dev-sliced-vbi.rst
@@ -105,7 +105,13 @@ which may return ``EBUSY`` can be the
struct v4l2_sliced_vbi_format
-
-.. tabularcolumns:: |p{1.0cm}|p{4.5cm}|p{4.0cm}|p{4.0cm}|p{4.0cm}|
+.. raw:: latex
+
+\begingroup
+\scriptsize
+\setlength{\tabcolsep}{2pt}
+
+.. tabularcolumns:: |p{.75cm}
